Greetings folks,
As the principal FAS upstream, I would like to help you guys out making - as much as possible - (the right?) move by having the right information.
First of all, let's start by a short FAS introduction.
FAS has been designed to be community oriented by providing to the community a way to operate by itself through teams management (i.e group membership/management). As a result, our web interface has to be more than just an administrative interface to manage users & groups like other does. I recommend to go read more about it at https://admin.fedoraproject.org/accounts/about before go further.
While keeping the openness, we also added: 1. A plugin Interface which let you add any new feature Plugin we had developed: * asterisk (no longer in prod however the plugin still is maintain) * yubikey (some of our group requires their members to have a key to access bound hosts) * OTP 2 factor auth (in a branch)
2. A non-standard API (current master) which let registered people and/or 3rd parties (from login mechanism) to read-only from FAS.
Next is, my feedback after reviewed the wiki page and previous msg:
project URL
The project is mainly active on github (fedorahosted.org has been set as backup) v2: https://github.com/fedora-infra/fas v3.0: https://github.com/fedora-infra/fas/tree/FAS_3.0
packages available natively in the distro
We do provide rpm's for rhel (e.g. http://infrastructure.fedoraproject.org/6Server/x86_64/fas-0.10.0-5.el6.noar... ) FAS v3 package will be in distro as it will be no Fedora project specific.
multi-master replication
Is this our we can replicate FAS from a master image? I really didn't get that one. If someone could explain it to me, that would be great.
kerberos support:
Not supported at this time. We do think of it for a v3.xx though. But it's not in my priority list unless someone is interesting to work on it.
LDAP support:
FAS v2: no. FAS v3.2: yes however, the LDAP support will be for group and people management. We will keep the DB as FAS is not about user and group management only.
It's more or less a "Users CMDB" and cron jobs/scripts are
creating/removing/modifying users/groups locally on each managed system.
Naa, we have a fas-client which actually does the job to synchronize accounts on hosts. fas-client has been cron'd as the v2 is a non-daemon tools. We do have a daemon option though that listen to fedmsg and update hosts on demand. However, we set up a push-mode into Fedora infra.
Mainly written to discuss with the fedmsg bus, and so targetting all
Fedora Applications
FAS has not been written to talk to 3rd parties (as stated in introduction). fedmsg cames few years after FASv2 launch. fedmsg is for FAS just another notification mechanism.
Written for one project
It has been the case for quite a while before I started work on FAS. For the record, I maintain the RPM Fusion infra and are using FAS there as well. even though this is related to fedora project, RPM Fusion are not providing the same level of services and doesn't have the same team structure (we don't use license agreement feature, nor asterisk's one, nor bugzilla feature atm).
but we are working on a new fas 3 version that will use flask.
Naa.. FAS 3 is a pyramid app.
I guess it would be easier for everybody too, as just for today I've
read that FAS3 would be in fact based on IPA so not on the actual FAS setup
Nope, it will not rely on FreeIPA as FreeIPA doesn't comply with our need as stated in introduction. However, we may look at their kerberos and directory server implementation as a plugin for FAS.
If you have any question which are not answered here, please feel free to ask. Also, as Kevin said, the v3 is being writing and will come up with lot of features so question here are much appreciate ;)
- Xavier
On 11/19/2014 07:29 AM, Xavier Lamien wrote:
Nope, it will not rely on FreeIPA as FreeIPA doesn't comply with our need as stated in introduction. However, we may look at their kerberos and directory server implementation as a plugin for FAS.
Okay, this is somewhat different than the conversation I had with Stephen Gallagher at LISA last week then. After that discussion I was under the impression that FAS3 was to be written leveraging the distro FreeIPA packages as a base, and then building the needed functionality on top.
If you have any question which are not answered here, please feel free to ask. Also, as Kevin said, the v3 is being writing and will come up with lot of features so question here are much appreciate ;)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 19/11/14 14:29, Xavier Lamien wrote:
Greetings folks,
As the principal FAS upstream, I would like to help you guys out making - as much as possible - (the right?) move by having the right information.
First of all, let's start by a short FAS introduction.
FAS has been designed to be community oriented by providing to the community a way to operate by itself through teams management (i.e group membership/management). As a result, our web interface has to be more than just an administrative interface to manage users & groups like other does. I recommend to go read more about it at https://admin.fedoraproject.org/accounts/about before go further.
While keeping the openness, we also added: 1. A plugin Interface which let you add any new feature Plugin we had developed: * asterisk (no longer in prod however the plugin still is maintain) * yubikey (some of our group requires their members to have a key to access bound hosts) * OTP 2 factor auth (in a branch)
- A non-standard API (current master) which let registered people
and/or 3rd parties (from login mechanism) to read-only from FAS.
Next is, my feedback after reviewed the wiki page and previous msg:
project URL
The project is mainly active on github (fedorahosted.org http://fedorahosted.org has been set as backup) v2: https://github.com/fedora-infra/fas v3.0: https://github.com/fedora-infra/fas/tree/FAS_3.0
packages available natively in the distro
We do provide rpm's for rhel (e.g. http://infrastructure.fedoraproject.org/6Server/x86_64/fas-0.10.0-5.el6.noar...)
FAS v3 package will be in distro as it will be no Fedora project specific.
multi-master replication
Is this our we can replicate FAS from a master image? I really didn't get that one. If someone could explain it to me, that would be great.
kerberos support:
Not supported at this time. We do think of it for a v3.xx though. But it's not in my priority list unless someone is interesting to work on it.
LDAP support:
FAS v2: no. FAS v3.2: yes however, the LDAP support will be for group and people management. We will keep the DB as FAS is not about user and group management only.
It's more or less a "Users CMDB" and cron jobs/scripts are
creating/removing/modifying users/groups locally on each managed system.
Naa, we have a fas-client which actually does the job to synchronize accounts on hosts. fas-client has been cron'd as the v2 is a non-daemon tools. We do have a daemon option though that listen to fedmsg and update hosts on demand. However, we set up a push-mode into Fedora infra.
Mainly written to discuss with the fedmsg bus, and so targetting all
Fedora Applications
FAS has not been written to talk to 3rd parties (as stated in introduction). fedmsg cames few years after FASv2 launch. fedmsg is for FAS just another notification mechanism.
Written for one project
It has been the case for quite a while before I started work on FAS. For the record, I maintain the RPM Fusion infra and are using FAS there as well. even though this is related to fedora project, RPM Fusion are not providing the same level of services and doesn't have the same team structure (we don't use license agreement feature, nor asterisk's one, nor bugzilla feature atm).
but we are working on a new fas 3 version that will use flask.
Naa.. FAS 3 is a pyramid app.
I guess it would be easier for everybody too, as just for today I've
read that FAS3 would be in fact based on IPA so not on the actual FAS setup
Nope, it will not rely on FreeIPA as FreeIPA doesn't comply with our need as stated in introduction. However, we may look at their kerberos and directory server implementation as a plugin for FAS.
If you have any question which are not answered here, please feel free to ask. Also, as Kevin said, the v3 is being writing and will come up with lot of features so question here are much appreciate ;)
- Xavier
(trying to resurrect that thread, as no real momentum/traction at the moment it seems)
So, the major request is for SIGs developers to get access to our Community Builders (http://cbs.centosr.org). We currently use a custom wrapper/script using an internal CA to create keys/certs and have those distributed to SIGs people having access to koji. It's not clear if FAs provides an easy way to retrieve such key/cert easily : as an example, I don't see any automatically created key/cert in my FAS account when logged on https://admin.fedoraproject.org/accounts (or is that hidden and only available to people in certain groups ?)
To also be clear : we'll *not* switch all centos.org nodes auth to that centralized authentication (there is no current need for that, and especially for nodes that are just mirrors/rsync targets, on which user accounts with rights are already managed by puppet)
So, using a centralized auth is for new apps (and then why not considering merging existing ones to use that solution too) : * koji (we need the central tool to let people auto-register themselves and retrieve their keys/signed x509 certs) * Git authentication : gitblit (backend for git.centos.org) supports multiple auth mechanisms, including x509 so we'll reuse that (actually it's only using embedded localdb for users/groups)
For the future, it would be good to see if we can centralize other solutions to use that central auth : * Wiki (actually moin) * Forums (phpbb so probably better to not use ldap, but try to use OAuth)
- --
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
On Tue Dec 02 2014 at 9:09:15 AM Fabian Arrotin arrfab@centos.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 19/11/14 14:29, Xavier Lamien wrote:
Greetings folks,
As the principal FAS upstream, I would like to help you guys out making - as much as possible - (the right?) move by having the right information.
First of all, let's start by a short FAS introduction.
FAS has been designed to be community oriented by providing to the community a way to operate by itself through teams management (i.e group membership/management). As a result, our web interface has to be more than just an administrative interface to manage users & groups like other does. I recommend to go read more about it at https://admin.fedoraproject.org/accounts/about before go further.
While keeping the openness, we also added: 1. A plugin Interface which let you add any new feature Plugin we had developed: * asterisk (no longer in prod however the plugin still is maintain) * yubikey (some of our group requires their members to have a key to access bound hosts) * OTP 2 factor auth (in a branch)
- A non-standard API (current master) which let registered people
and/or 3rd parties (from login mechanism) to read-only from FAS.
Next is, my feedback after reviewed the wiki page and previous msg:
project URL
The project is mainly active on github (fedorahosted.org http://fedorahosted.org has been set as backup) v2: https://github.com/fedora-infra/fas v3.0: https://github.com/fedora-infra/fas/tree/FAS_3.0
packages available natively in the distro
We do provide rpm's for rhel (e.g. http://infrastructure.fedoraproject.org/6Server/x86_
64/fas-0.10.0-5.el6.noarch.rpm)
FAS v3 package will be in distro as it will be no Fedora project specific.
multi-master replication
Is this our we can replicate FAS from a master image? I really didn't get that one. If someone could explain it to me, that would be great.
kerberos support:
Not supported at this time. We do think of it for a v3.xx though. But it's not in my priority list unless someone is interesting to work on it.
LDAP support:
FAS v2: no. FAS v3.2: yes however, the LDAP support will be for group and people management. We will keep the DB as FAS is not about user and group management only.
It's more or less a "Users CMDB" and cron jobs/scripts are
creating/removing/modifying users/groups locally on each managed system.
Naa, we have a fas-client which actually does the job to synchronize accounts on hosts. fas-client has been cron'd as the v2 is a non-daemon tools. We do have a daemon option though that listen to fedmsg and update hosts on demand. However, we set up a push-mode into Fedora infra.
Mainly written to discuss with the fedmsg bus, and so targetting all
Fedora Applications
FAS has not been written to talk to 3rd parties (as stated in introduction). fedmsg cames few years after FASv2 launch. fedmsg is for FAS just another notification mechanism.
Written for one project
It has been the case for quite a while before I started work on FAS. For the record, I maintain the RPM Fusion infra and are using FAS there as well. even though this is related to fedora project, RPM Fusion are not providing the same level of services and doesn't have the same team structure (we don't use license agreement feature, nor asterisk's one, nor bugzilla feature atm).
but we are working on a new fas 3 version that will use flask.
Naa.. FAS 3 is a pyramid app.
I guess it would be easier for everybody too, as just for today I've
read that FAS3 would be in fact based on IPA so not on the actual FAS setup
Nope, it will not rely on FreeIPA as FreeIPA doesn't comply with our need as stated in introduction. However, we may look at their kerberos and directory server implementation as a plugin for FAS.
If you have any question which are not answered here, please feel free to ask. Also, as Kevin said, the v3 is being writing and will come up with lot of features so question here are much appreciate ;)
- Xavier
(trying to resurrect that thread, as no real momentum/traction at the moment it seems)
So, the major request is for SIGs developers to get access to our Community Builders (http://cbs.centosr.org). We currently use a custom wrapper/script using an internal CA to create keys/certs and have those distributed to SIGs people having access to koji. It's not clear if FAs provides an easy way to retrieve such key/cert
Yes, users used to get them at https://admin.fedoraproject.org/accounts/ user/dogencert. However, this key only work for the buildsys atm.
easily : as an example, I don't see any automatically created key/cert in my FAS account when logged on https://admin.fedoraproject.org/accounts (or is that hidden and only available to people in certain groups ?)
Yeah, we disabled it from the UI and recommend our contributors to use the tool "fedora-cert". This can be re-enabled.
To also be clear : we'll *not* switch all centos.org nodes auth to that centralized authentication (there is no current need for that, and especially for nodes that are just mirrors/rsync targets, on which user accounts with rights are already managed by puppet)
So, using a centralized auth is for new apps (and then why not considering merging existing ones to use that solution too) :
- koji (we need the central tool to let people auto-register
themselves and retrieve their keys/signed x509 certs)
- Git authentication : gitblit (backend for git.centos.org) supports
multiple auth mechanisms, including x509 so we'll reuse that (actually it's only using embedded localdb for users/groups)
For the future, it would be good to see if we can centralize other solutions to use that central auth :
- Wiki (actually moin)
- Forums (phpbb so probably better to not use ldap, but try to use OAuth)
-
Fabian Arrotin -
Jim Perrin -
Xavier Lamien