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