Any C coders want to help me with something?

Ricky Zhou ricky at fedoraproject.org
Fri May 1 06:59:55 UTC 2009


On 2009-04-30 09:53:39 AM, Toshio Kuratomi wrote:
> 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?
My suggested solution to this would be to continue having local cached
data using nss_db.  One benefit to having this backed by LDAP instead of
SQL is that reading/generating these local caches should be far faster.

> 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?)
Yes, we can restrict access to this information.

> 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?
That is certainly an option.  I don't think OpenSSH has built in support
for reading public keys from an LDAP server without recompiling it with
third party patches, so we'd still need something for creating home
directories with authorized_key files.  

> 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?
With LDAP, authentication should be possible without having separate
special credentials. 

Thanks,
Ricky
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-infrastructure-list/attachments/20090501/72a08524/attachment.sig>


More information about the Fedora-infrastructure-list mailing list