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.
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)
>> packages available natively in the distro
We do provide rpm's for rhel
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