Any C coders want to help me with something?

[Mike McGrath]

On Thu, 30 Apr 2009, Stephen John Smoogen wrote:

> On Thu, Apr 30, 2009 at 11:37 AM, Mike McGrath <mmcgrath at redhat.com> wrote:
> > On Thu, 30 Apr 2009, Toshio Kuratomi wrote:
> >
> >> Mike McGrath wrote:
> >> > On Thu, 30 Apr 2009, Ricky Zhou wrote:
> >> >> In some distant future version of FAS, I'd
> >> >> like to play with the idea of storing the data in LDAP while handling
> >> >> our group sponsorship system in postgres.
> >> >>
> >> >
> >> > Ick
> >> >
> >> heh :-)
> >>
> >> I think ricky's approach could work but it would need planning.  The
> >> idea would be to increase the complexity of FAS but decrease the
> >> complexity for everything we deploy that needs authentication.  We'd
> >> want to examine that assumption in the planning phase to make sure it's
> >> actually true for us.
> >>
> >> For instance, there was the thought that having cached credentials on
> >> our servers was preferable to what happens to when the LDAP server goes
> >> down.  Still a concern?
> >>
> >> We currently mask a lot of information for the privacy policy, can we do
> >> that with LDAP?  (Or just not put the information in there?)
> >>
> >> We let third parties (like the hosts to let packagers try building on
> >> ppc, x86_64, etc) use fas to get ssh keys.  Would we let them connect to
> >> and get that information from the LDAP server instead?
> >>
> >> We let people use their normal accounts to get a subset of data for
> >> authenticating to their web apps while they're developing them.  Would
> >> we enable the same setup with LDAP?
> >>
> >
> > I figure we're still very much in the exploritory stage, we should get our
> > requirements together though.  FAS going down is still a real concern, but
> > if we implement a hardware key system, like yubikey, we'll have a similar
> > requirement in that yubikey requires a yubiserver of some kind (or the AES
> > key on every server).
>
> Normally there will need to be a prcedure to deal with such failures.
> Who to contact, how they log it, what methods are used for
> 'all-things-failed' access (usually a one-time-password that is
> changed afterwords), how to log actions and how to set things right
> again. This is more of a person fix versus technological fix.
>

That's the thing that's nice about our current setup though, it's a
technical fix.  FAS could go down right now and lots of services (cvs,
fedorahosted, all shell access, etc) would stay up.  The downside is the
sync times.

	-Mike