On Tue, Apr 28, 2009 at 3:57 PM, Mike McGrath mmcgrath@redhat.com wrote:
Any C coders want to help me with a pam module?
I am not a great C coder but I have done some pam stuff. what is the issue?
On Tue, 28 Apr 2009, Stephen John Smoogen wrote:
On Tue, Apr 28, 2009 at 3:57 PM, Mike McGrath mmcgrath@redhat.com wrote:
Any C coders want to help me with a pam module?
I am not a great C coder but I have done some pam stuff. what is the issue?
I'd like someone to write a pam module to auth against fas. I'm not sure it's the way to go but I'd like to have something up and running to test with to see how it behaves, how it deals with some failure scenarios, etc.
-Mike
Hello Mike,
are you speaking about a Linux PAM module, or CGI?
regards, Sascha
2009/4/29 Mike McGrath mmcgrath@redhat.com:
On Tue, 28 Apr 2009, Stephen John Smoogen wrote:
On Tue, Apr 28, 2009 at 3:57 PM, Mike McGrath mmcgrath@redhat.com wrote:
Any C coders want to help me with a pam module?
I am not a great C coder but I have done some pam stuff. what is the issue?
I'd like someone to write a pam module to auth against fas. I'm not sure it's the way to go but I'd like to have something up and running to test with to see how it behaves, how it deals with some failure scenarios, etc.
-Mike
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Hello again,
I'd like someone to write a pam module to auth against fas.
sry, havent read this.
regards, Sascha
2009/4/29 Sascha Thomas Spreitzer sascha@spreitzer.name:
Hello Mike,
are you speaking about a Linux PAM module, or CGI?
regards, Sascha
2009/4/29 Mike McGrath mmcgrath@redhat.com:
On Tue, 28 Apr 2009, Stephen John Smoogen wrote:
On Tue, Apr 28, 2009 at 3:57 PM, Mike McGrath mmcgrath@redhat.com wrote:
Any C coders want to help me with a pam module?
I am not a great C coder but I have done some pam stuff. what is the issue?
I'd like someone to write a pam module to auth against fas. I'm not sure it's the way to go but I'd like to have something up and running to test with to see how it behaves, how it deals with some failure scenarios, etc.
-Mike
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
-- Mit freundlichen Grüßen, / with kind regards, Sascha Thomas Spreitzer http://spreitzer.name/
Hi,
I'm not a hardcore C programmer, but have basic knowledge in C and C++. Can you share some technical details so that we have a better understanding of what needs to be done? Kinda new on this kind of programming, but I'd love to give it a try.
Thnx, Sameeh
On Wed, Apr 29, 2009 at 3:26 PM, Sascha Thomas Spreitzer < sascha@spreitzer.name> wrote:
Hello again,
I'd like someone to write a pam module to auth against fas.
sry, havent read this.
regards, Sascha
2009/4/29 Sascha Thomas Spreitzer sascha@spreitzer.name:
Hello Mike,
are you speaking about a Linux PAM module, or CGI?
regards, Sascha
2009/4/29 Mike McGrath mmcgrath@redhat.com:
On Tue, 28 Apr 2009, Stephen John Smoogen wrote:
On Tue, Apr 28, 2009 at 3:57 PM, Mike McGrath mmcgrath@redhat.com
wrote:
Any C coders want to help me with a pam module?
I am not a great C coder but I have done some pam stuff. what is the
issue?
I'd like someone to write a pam module to auth against fas. I'm not
sure
it's the way to go but I'd like to have something up and running to test with to see how it behaves, how it deals with some failure scenarios,
etc.
-Mike
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
-- Mit freundlichen Grüßen, / with kind regards, Sascha Thomas Spreitzer http://spreitzer.name/
-- Mit freundlichen Grüßen, / with kind regards, Sascha Thomas Spreitzer http://spreitzer.name/
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
On Apr 29, 2009, at 01:38 , Mike McGrath wrote:
I'd like someone to write a pam module to auth against fas. I'm not sure it's the way to go but I'd like to have something up and running to test with to see how it behaves, how it deals with some failure scenarios, etc.
I'm not sure what exactly you want to do, but pam_ldap should do what you want, right? Or at least one could use it as codebase and modify it.
Regards, Stefan.
Stefan Schlesinger \\\\\\\\\\\\\\\\ \\\\ sts@ono.at SS8335-RIPE
On Wed, 29 Apr 2009, Stefan Schlesinger wrote:
On Apr 29, 2009, at 01:38 , Mike McGrath wrote:
I'd like someone to write a pam module to auth against fas. I'm not sure it's the way to go but I'd like to have something up and running to test with to see how it behaves, how it deals with some failure scenarios, etc.
I'm not sure what exactly you want to do, but pam_ldap should do what you want, right? Or at least one could use it as codebase and modify it.
pam_ldap would probably be close to what we want and certainly a good place to look but we don't run an ldap server so it won't auth against fas.
-Mike
On Wed, Apr 29, 2009 at 8:27 AM, Mike McGrath mmcgrath@redhat.com wrote:
On Wed, 29 Apr 2009, Stefan Schlesinger wrote:
On Apr 29, 2009, at 01:38 , Mike McGrath wrote:
I'd like someone to write a pam module to auth against fas. I'm not sure it's the way to go but I'd like to have something up and running to test with to see how it behaves, how it deals with some failure scenarios, etc.
I'm not sure what exactly you want to do, but pam_ldap should do what you want, right? Or at least one could use it as codebase and modify it.
pam_ldap would probably be close to what we want and certainly a good place to look but we don't run an ldap server so it won't auth against fas.
Well normally what I have seen is that the 'FAS' server would export a schema table to LDAP and LDAP would then be what is authenticated to (the same with Kerberos if combined). Or the FAS server has a mysql/postgres background and someone uses pam/mod mysql to do it.
The one problem with custom pam modules is usually the 'oooooooh' moment when something doesn't work quite as planned (hey look I can sudo root as apache? how did that happen?)
On Wed, 29 Apr 2009, Stephen John Smoogen wrote:
On Wed, Apr 29, 2009 at 8:27 AM, Mike McGrath mmcgrath@redhat.com wrote:
On Wed, 29 Apr 2009, Stefan Schlesinger wrote:
On Apr 29, 2009, at 01:38 , Mike McGrath wrote:
I'd like someone to write a pam module to auth against fas. I'm not sure it's the way to go but I'd like to have something up and running to test with to see how it behaves, how it deals with some failure scenarios, etc.
I'm not sure what exactly you want to do, but pam_ldap should do what you want, right? Or at least one could use it as codebase and modify it.
pam_ldap would probably be close to what we want and certainly a good place to look but we don't run an ldap server so it won't auth against fas.
Well normally what I have seen is that the 'FAS' server would export a schema table to LDAP and LDAP would then be what is authenticated to (the same with Kerberos if combined). Or the FAS server has a mysql/postgres background and someone uses pam/mod mysql to do it.
The one problem with custom pam modules is usually the 'oooooooh' moment when something doesn't work quite as planned (hey look I can sudo root as apache? how did that happen?)
This is a legit and good concern. Ricky and I were talking about it last night. Since we're re-thinking things I'm open to suggestions. Might be something as simple as getting an ldap server to communicate with a postgres backend?
-Mike
On Wed, 29 Apr 2009, Mike McGrath wrote:
On Wed, 29 Apr 2009, Stephen John Smoogen wrote:
On Wed, Apr 29, 2009 at 8:27 AM, Mike McGrath mmcgrath@redhat.com wrote:
On Wed, 29 Apr 2009, Stefan Schlesinger wrote:
On Apr 29, 2009, at 01:38 , Mike McGrath wrote:
I'd like someone to write a pam module to auth against fas. I'm not sure it's the way to go but I'd like to have something up and running to test with to see how it behaves, how it deals with some failure scenarios, etc.
I'm not sure what exactly you want to do, but pam_ldap should do what you want, right? Or at least one could use it as codebase and modify it.
pam_ldap would probably be close to what we want and certainly a good place to look but we don't run an ldap server so it won't auth against fas.
Well normally what I have seen is that the 'FAS' server would export a schema table to LDAP and LDAP would then be what is authenticated to (the same with Kerberos if combined). Or the FAS server has a mysql/postgres background and someone uses pam/mod mysql to do it.
The one problem with custom pam modules is usually the 'oooooooh' moment when something doesn't work quite as planned (hey look I can sudo root as apache? how did that happen?)
This is a legit and good concern. Ricky and I were talking about it last night. Since we're re-thinking things I'm open to suggestions. Might be something as simple as getting an ldap server to communicate with a postgres backend?
:: cough cough :: something like
http://www.darold.net/projects/ldap_pg/HOWTO/
-Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/30/2009 12:52 AM, Mike McGrath wrote:
On Wed, 29 Apr 2009, Stephen John Smoogen wrote:
On Wed, Apr 29, 2009 at 8:27 AM, Mike McGrath mmcgrath@redhat.com wrote:
On Wed, 29 Apr 2009, Stefan Schlesinger wrote:
On Apr 29, 2009, at 01:38 , Mike McGrath wrote:
I'd like someone to write a pam module to auth against fas. I'm not sure it's the way to go but I'd like to have something up and running to test with to see how it behaves, how it deals with some failure scenarios, etc.
I'm not sure what exactly you want to do, but pam_ldap should do what you want, right? Or at least one could use it as codebase and modify it.
pam_ldap would probably be close to what we want and certainly a good place to look but we don't run an ldap server so it won't auth against fas.
Well normally what I have seen is that the 'FAS' server would export a schema table to LDAP and LDAP would then be what is authenticated to (the same with Kerberos if combined). Or the FAS server has a mysql/postgres background and someone uses pam/mod mysql to do it.
The one problem with custom pam modules is usually the 'oooooooh' moment when something doesn't work quite as planned (hey look I can sudo root as apache? how did that happen?)
This is a legit and good concern. Ricky and I were talking about it last night. Since we're re-thinking things I'm open to suggestions. Might be something as simple as getting an ldap server to communicate with a postgres backend?
-Mike
Sorry for butting in like this, but I always assumed FAS would use LDAP as a backend, so that 3rd parties, if they wanted to plug in to the system, would utilize LDAP. Is that not the case?
On Thu, 30 Apr 2009, Basil Mohamed Gohar wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/30/2009 12:52 AM, Mike McGrath wrote:
On Wed, 29 Apr 2009, Stephen John Smoogen wrote:
On Wed, Apr 29, 2009 at 8:27 AM, Mike McGrath mmcgrath@redhat.com wrote:
On Wed, 29 Apr 2009, Stefan Schlesinger wrote:
On Apr 29, 2009, at 01:38 , Mike McGrath wrote:
I'd like someone to write a pam module to auth against fas. I'm not sure it's the way to go but I'd like to have something up and running to test with to see how it behaves, how it deals with some failure scenarios, etc.
I'm not sure what exactly you want to do, but pam_ldap should do what you want, right? Or at least one could use it as codebase and modify it.
pam_ldap would probably be close to what we want and certainly a good place to look but we don't run an ldap server so it won't auth against fas.
Well normally what I have seen is that the 'FAS' server would export a schema table to LDAP and LDAP would then be what is authenticated to (the same with Kerberos if combined). Or the FAS server has a mysql/postgres background and someone uses pam/mod mysql to do it.
The one problem with custom pam modules is usually the 'oooooooh' moment when something doesn't work quite as planned (hey look I can sudo root as apache? how did that happen?)
This is a legit and good concern. Ricky and I were talking about it last night. Since we're re-thinking things I'm open to suggestions. Might be something as simple as getting an ldap server to communicate with a postgres backend?
-Mike
Sorry for butting in like this, but I always assumed FAS would use LDAP as a backend, so that 3rd parties, if they wanted to plug in to the system, would utilize LDAP. Is that not the case?
Correct, that's not the case. Instead of LDAP we have a postgres backend and use json to auth, third parties use python-fedora to authenticate. We tried pretty hard to get LDAP working with our account system but ran into many problems and decided to go back to postgres.
-Mike
On Wed, Apr 29, 2009 at 01:03:03PM -0500, Mike McGrath wrote:
Well normally what I have seen is that the 'FAS' server would export a schema table to LDAP and LDAP would then be what is authenticated to (the same with Kerberos if combined). Or the FAS server has a mysql/postgres background and someone uses pam/mod mysql to do it.
Sorry for butting in like this, but I always assumed FAS would use LDAP as a backend, so that 3rd parties, if they wanted to plug in to the system, would utilize LDAP. Is that not the case?
Correct, that's not the case. Instead of LDAP we have a postgres backend and use json to auth, third parties use python-fedora to authenticate. We tried pretty hard to get LDAP working with our account system but ran into many problems and decided to go back to postgres.
I'd third the LDAP love here, e.g. either a read-only cron'd export to LDAP or rewriting the FAS backend for LDAP. Any future tool you may want to attach to FAS will most probably have LDAP support out of the box, but any other kind of authentication would need special coding (like your pam module request), which is both time consuming and a security risk if not written properly.
On Wed, 29 Apr 2009, Axel Thimm wrote:
On Wed, Apr 29, 2009 at 01:03:03PM -0500, Mike McGrath wrote:
Well normally what I have seen is that the 'FAS' server would export a schema table to LDAP and LDAP would then be what is authenticated to (the same with Kerberos if combined). Or the FAS server has a mysql/postgres background and someone uses pam/mod mysql to do it.
Sorry for butting in like this, but I always assumed FAS would use LDAP as a backend, so that 3rd parties, if they wanted to plug in to the system, would utilize LDAP. Is that not the case?
Correct, that's not the case. Instead of LDAP we have a postgres backend and use json to auth, third parties use python-fedora to authenticate. We tried pretty hard to get LDAP working with our account system but ran into many problems and decided to go back to postgres.
I'd third the LDAP love here, e.g. either a read-only cron'd export to LDAP or rewriting the FAS backend for LDAP. Any future tool you may want to attach to FAS will most probably have LDAP support out of the box, but any other kind of authentication would need special coding (like your pam module request), which is both time consuming and a security risk if not written properly.
We worked pretty closely with different LDAP teams and the way FAS works is just not very... ldapian. Although it's only some internal stuff that we need (specifically related to our user/sponsor/admin bits in each group.
As far as actually using FAS to do stuff, it's quite possible that we can use LDAP there for things. I think:
http://www.darold.net/projects/ldap_pg/HOWTO/
Is worth getting up and running to see. If it turns out to be cumbersome, then perhaps a cronned job is all that's available.
-Mike
On Wed, Apr 29, 2009 at 02:03:55PM -0500, Mike McGrath wrote:
We worked pretty closely with different LDAP teams and the way FAS works is just not very... ldapian. Although it's only some internal stuff that we need (specifically related to our user/sponsor/admin bits in each group.
Can't this be implemented with a FAS ldap schema that contains these bits in ldap attributes?
Or rephrased: Can't any SQL field in a table be always mapped onto some (custom) ldap attribute? If you can map a problem onto an SQL database it should be possible to go ldap IMHO.
On Thu, Apr 30, 2009 at 06:44:09AM +0300, Axel Thimm wrote:
On Wed, Apr 29, 2009 at 02:03:55PM -0500, Mike McGrath wrote:
We worked pretty closely with different LDAP teams and the way FAS works is just not very... ldapian. Although it's only some internal stuff that we need (specifically related to our user/sponsor/admin bits in each group.
Can't this be implemented with a FAS ldap schema that contains these bits in ldap attributes?
Can I reverse the question? Instead of a pam_fas module, what about creating a way to export FAS information as LDAP, such that all LDAP-consuming apps would "just work", albeit not able to access the FAS-specific information?
On 2009-04-29 11:23:55 PM, Matt Domsch wrote:
Can I reverse the question? Instead of a pam_fas module, what about creating a way to export FAS information as LDAP, such that all LDAP-consuming apps would "just work", albeit not able to access the FAS-specific information?
I agree with this approach. 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.
Thanks, Ricky
On Thu, 30 Apr 2009, Ricky Zhou wrote:
On 2009-04-29 11:23:55 PM, Matt Domsch wrote:
Can I reverse the question? Instead of a pam_fas module, what about creating a way to export FAS information as LDAP, such that all LDAP-consuming apps would "just work", albeit not able to access the FAS-specific information?
I agree with this approach. 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
-Mike
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?
-Toshio
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).
-Mike
On Thu, Apr 30, 2009 at 11:37 AM, Mike McGrath mmcgrath@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.
On Thu, 30 Apr 2009, Stephen John Smoogen wrote:
On Thu, Apr 30, 2009 at 11:37 AM, Mike McGrath mmcgrath@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
On Thu, Apr 30, 2009 at 09:53:39AM -0700, 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?
You can have slave LDAP servers, of course, and if you don't trust their location, you can have slices of LDAP mirrored differently, e.g. not all attributes, not all trees etc.
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?)
Sure, there are rather fine-coarsed ACL systems in both openldap and ds.
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?
There would be no security downside compared to other retieval solution. Absolute security is to let this be done by a trusted human.
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?
Yes, check out the ACLs in either or the two popular projects.
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
On Wed, Apr 29, 2009 at 11:23:55PM -0500, Matt Domsch wrote:
On Thu, Apr 30, 2009 at 06:44:09AM +0300, Axel Thimm wrote:
On Wed, Apr 29, 2009 at 02:03:55PM -0500, Mike McGrath wrote:
We worked pretty closely with different LDAP teams and the way FAS works is just not very... ldapian. Although it's only some internal stuff that we need (specifically related to our user/sponsor/admin bits in each group.
Can't this be implemented with a FAS ldap schema that contains these bits in ldap attributes?
Can I reverse the question? Instead of a pam_fas module, what about creating a way to export FAS information as LDAP, such that all LDAP-consuming apps would "just work", albeit not able to access the FAS-specific information?
That was further up the thread: One could have FAS export the parts Mike needs in an ldif formated file and cron-import them into a *read only* ldap backend. You would need a sibling ldap instance running for serving ldap requests.
If you mean having an ldap (read-only) interface to FAS coded, then I think that this is quite a lot of work.
On 2009-05-01 09:14:20 AM, Axel Thimm wrote:
That was further up the thread: One could have FAS export the parts Mike needs in an ldif formated file and cron-import them into a *read only* ldap backend. You would need a sibling ldap instance running for serving ldap requests.
If you mean having an ldap (read-only) interface to FAS coded, then I think that this is quite a lot of work.
This would make it easier to have a lot of different authentication methods, but it wouldn't solve the sync problem, unfortunately. I think we can get both of these benefits by storing the data directly in an LDAP directory, which I've been thinking about a bit.
Thanks, Ricky
On Thu, 30 Apr 2009, Axel Thimm wrote:
On Wed, Apr 29, 2009 at 02:03:55PM -0500, Mike McGrath wrote:
We worked pretty closely with different LDAP teams and the way FAS works is just not very... ldapian. Although it's only some internal stuff that we need (specifically related to our user/sponsor/admin bits in each group.
Can't this be implemented with a FAS ldap schema that contains these bits in ldap attributes?
Or rephrased: Can't any SQL field in a table be always mapped onto some (custom) ldap attribute? If you can map a problem onto an SQL database it should be possible to go ldap IMHO.
Seems like it should work that way, and we spent months trying to get it to work right (even working with the fedora-ds people) but it just ended up being very hacky and not very good.
-Mike
On Thu, Apr 30, 2009 at 07:54:42AM -0500, Mike McGrath wrote:
On Thu, 30 Apr 2009, Axel Thimm wrote:
On Wed, Apr 29, 2009 at 02:03:55PM -0500, Mike McGrath wrote:
We worked pretty closely with different LDAP teams and the way FAS works is just not very... ldapian. Although it's only some internal stuff that we need (specifically related to our user/sponsor/admin bits in each group.
Can't this be implemented with a FAS ldap schema that contains these bits in ldap attributes?
Or rephrased: Can't any SQL field in a table be always mapped onto some (custom) ldap attribute? If you can map a problem onto an SQL database it should be possible to go ldap IMHO.
Seems like it should work that way, and we spent months trying to get it to work right (even working with the fedora-ds people) but it just ended up being very hacky and not very good.
Maybe if someone gives some detail on why the LDAP setup looked like too hacky we could find a better solution and use LDAP?
On 2009-05-01 09:11:11 AM, Axel Thimm wrote:
Maybe if someone gives some detail on why the LDAP setup looked like too hacky we could find a better solution and use LDAP?
We were basically trying to use LDAP like a relational DB instead of a directory, so we were trying to force our entire sponsorship system to be totally contained in LDAP. Looking back at this, the best approach with LDAP would probably have been a DB for sponsorship data, and LDAP for holding approved user/group data. As I mentioned, I'd be interested in exploring this approach a bit more in the future.
Thanks, Ricky
On Fri, May 01, 2009 at 02:54:08AM -0400, Ricky Zhou wrote:
On 2009-05-01 09:11:11 AM, Axel Thimm wrote:
Maybe if someone gives some detail on why the LDAP setup looked like too hacky we could find a better solution and use LDAP?
We were basically trying to use LDAP like a relational DB instead of a directory, so we were trying to force our entire sponsorship system to be totally contained in LDAP. Looking back at this, the best approach with LDAP would probably have been a DB for sponsorship data, and LDAP for holding approved user/group data. As I mentioned, I'd be interested in exploring this approach a bit more in the future.
With details I mean something more like what exact bits where not mapping naturally into some LDAP structure, existent or custom schema made.
W/o having in-depth knowledge of FAS I'd start with a typical account LDAP setup and add the extra FAS functionality with a custom schema.
The group mapping should be done via conventional LDAP Posix Account/Group schemas, and I guess most of the extra bits could be converted to group memberships. That way, not only will you be able to map special FAS bits to simple POSIX semantics and thus reduce any special FAS schemes, but also use FAS information in anything that reads nss. E.g. you could use group memberships in filesystem acls to allow provenpackager some access to some files, sponsors other access to other files etc.
On Fri, 1 May 2009, Axel Thimm wrote:
On Fri, May 01, 2009 at 02:54:08AM -0400, Ricky Zhou wrote:
On 2009-05-01 09:11:11 AM, Axel Thimm wrote:
Maybe if someone gives some detail on why the LDAP setup looked like too hacky we could find a better solution and use LDAP?
We were basically trying to use LDAP like a relational DB instead of a directory, so we were trying to force our entire sponsorship system to be totally contained in LDAP. Looking back at this, the best approach with LDAP would probably have been a DB for sponsorship data, and LDAP for holding approved user/group data. As I mentioned, I'd be interested in exploring this approach a bit more in the future.
With details I mean something more like what exact bits where not mapping naturally into some LDAP structure, existent or custom schema made.
Both ldap groups basically suggested to us to have 3 groups for each 'group'. SO if you have a sysadmin group we'd have 'sysadmin' 'sysadmin-sponsors' and 'sysadmin-admins'. Then we'd move people from one group to another.
Then there was the concept of marking who sponsored who in that group. So if Axel joined the sysadmin group and I sponsored him in that group, that I be able to track that information. Those two requirements together make ldap a poor solution in our use case.
-Mike
On Fri, May 01, 2009 at 08:57:22AM -0500, Mike McGrath wrote:
On Fri, 1 May 2009, Axel Thimm wrote:
On Fri, May 01, 2009 at 02:54:08AM -0400, Ricky Zhou wrote:
On 2009-05-01 09:11:11 AM, Axel Thimm wrote:
Maybe if someone gives some detail on why the LDAP setup looked like too hacky we could find a better solution and use LDAP?
We were basically trying to use LDAP like a relational DB instead of a directory, so we were trying to force our entire sponsorship system to be totally contained in LDAP. Looking back at this, the best approach with LDAP would probably have been a DB for sponsorship data, and LDAP for holding approved user/group data. As I mentioned, I'd be interested in exploring this approach a bit more in the future.
With details I mean something more like what exact bits where not mapping naturally into some LDAP structure, existent or custom schema made.
Both ldap groups basically suggested to us to have 3 groups for each 'group'. SO if you have a sysadmin group we'd have 'sysadmin' 'sysadmin-sponsors' and 'sysadmin-admins'. Then we'd move people from one group to another.
Where is the information "*-vanilla" vs "*-sponsors" vs "*-admins" needed? If nothing else outside of FAS needs it, then I'd simply add a custom attribute. If you would need to export this information to say filesystem ACLs to allow different access to sysadmin-sponsors and sysadmin-admins, then you would have to split into these subgroups anyway somewhere in the FAS -> filesystem ACLs process.
Then there was the concept of marking who sponsored who in that group. So if Axel joined the sysadmin group and I sponsored him in that group, that I be able to track that information.
That really sounds like a simple custom attribute, possibly not even needed anywhere else outside of FAS scope.
Those two requirements together make ldap a poor solution in our use case.
Why? Custom schemes are quite often found in LDAP world, and it is really just two attributes you are adding to typical PosixAccounts.
On Sat, 2 May 2009, Axel Thimm wrote:
On Fri, May 01, 2009 at 08:57:22AM -0500, Mike McGrath wrote:
On Fri, 1 May 2009, Axel Thimm wrote:
On Fri, May 01, 2009 at 02:54:08AM -0400, Ricky Zhou wrote:
On 2009-05-01 09:11:11 AM, Axel Thimm wrote:
Maybe if someone gives some detail on why the LDAP setup looked like too hacky we could find a better solution and use LDAP?
We were basically trying to use LDAP like a relational DB instead of a directory, so we were trying to force our entire sponsorship system to be totally contained in LDAP. Looking back at this, the best approach with LDAP would probably have been a DB for sponsorship data, and LDAP for holding approved user/group data. As I mentioned, I'd be interested in exploring this approach a bit more in the future.
With details I mean something more like what exact bits where not mapping naturally into some LDAP structure, existent or custom schema made.
Both ldap groups basically suggested to us to have 3 groups for each 'group'. SO if you have a sysadmin group we'd have 'sysadmin' 'sysadmin-sponsors' and 'sysadmin-admins'. Then we'd move people from one group to another.
Where is the information "*-vanilla" vs "*-sponsors" vs "*-admins" needed? If nothing else outside of FAS needs it, then I'd simply add a custom attribute. If you would need to export this information to say filesystem ACLs to allow different access to sysadmin-sponsors and sysadmin-admins, then you would have to split into these subgroups anyway somewhere in the FAS -> filesystem ACLs process.
Then there was the concept of marking who sponsored who in that group. So if Axel joined the sysadmin group and I sponsored him in that group, that I be able to track that information.
That really sounds like a simple custom attribute, possibly not even needed anywhere else outside of FAS scope.
Those two requirements together make ldap a poor solution in our use case.
Why? Custom schemes are quite often found in LDAP world, and it is really just two attributes you are adding to typical PosixAccounts.
I'm not sure "why" you'd have to ask the fedora-ds and openldap devs. We dropped ldap largly on their recommendation, the comment that did it for me was "what you're trying to do with ldap is not a very ldap way of doing things." Thus why I described what we were trying to do as "hacky"
-Mike
On Fri, 1 May 2009, Ricky Zhou wrote:
On 2009-05-01 09:11:11 AM, Axel Thimm wrote:
Maybe if someone gives some detail on why the LDAP setup looked like too hacky we could find a better solution and use LDAP?
We were basically trying to use LDAP like a relational DB instead of a directory, so we were trying to force our entire sponsorship system to be totally contained in LDAP. Looking back at this, the best approach with LDAP would probably have been a DB for sponsorship data, and LDAP for holding approved user/group data. As I mentioned, I'd be interested in exploring this approach a bit more in the future.
I really hate this idea. Granted we're looking to use ldap as an extension of FAS, but to require them both for base functionality is just nasty to me. In my mind a system that requires both, and where you have to know what information is where in order to query it is a poorly designed system.
-Mike
infrastructure@lists.fedoraproject.org