Re: Any C coders want to help me with something?
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 ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
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. -- Axel.Thimm at ATrpms.net pgpHMyoidqSVx.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
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? -- Axel.Thimm at ATrpms.net pgpC66Nluam2r.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
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. -- Axel.Thimm at ATrpms.net pgpsM00AjEuu6.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
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 pgpvQdTH9b2LI.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
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 pgp3CoILF8Md9.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
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 ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
On Thu, Apr 30, 2009 at 11:37 AM, Mike McGrath mmcgr...@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. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. The Merchant of Venice ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
Hello Mike, are you speaking about a Linux PAM module, or CGI? regards, Sascha 2009/4/29 Mike McGrath mmcgr...@redhat.com: On Tue, 28 Apr 2009, Stephen John Smoogen wrote: On Tue, Apr 28, 2009 at 3:57 PM, Mike McGrath mmcgr...@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/ ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
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 sas...@spreitzer.name: Hello Mike, are you speaking about a Linux PAM module, or CGI? regards, Sascha 2009/4/29 Mike McGrath mmcgr...@redhat.com: On Tue, 28 Apr 2009, Stephen John Smoogen wrote: On Tue, Apr 28, 2009 at 3:57 PM, Mike McGrath mmcgr...@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
Re: Any C coders want to help me with something?
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 sas...@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 sas...@spreitzer.name: Hello Mike, are you speaking about a Linux PAM module, or CGI? regards, Sascha 2009/4/29 Mike McGrath mmcgr...@redhat.com: On Tue, 28 Apr 2009, Stephen John Smoogen wrote: On Tue, Apr 28, 2009 at 3:57 PM, Mike McGrath mmcgr...@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 -- --- Neo ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
On Wed, Apr 29, 2009 at 8:27 AM, Mike McGrath mmcgr...@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 'oooh' moment when something doesn't work quite as planned (hey look I can sudo root as apache? how did that happen?) -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. The Merchant of Venice ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
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 mmcgr...@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 'oooh' 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 ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
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. -- Axel.Thimm at ATrpms.net pgpmA3HstfoAY.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
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 ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
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. -- Axel.Thimm at ATrpms.net pgpXSxiyJZ8T6.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
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? -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
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 pgprq6dtkHhNK.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Any C coders want to help me with something?
Any C coders want to help me with a pam module? -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
On 2009-04-28 04:57:33 PM, Mike McGrath wrote: Any C coders want to help me with a pam module? I've been doing some C in school, so if there's no big rush, I wouldn't mind getting some practice :-) Thanks, Ricky pgpWcwE5v5t7S.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
On Tue, Apr 28, 2009 at 3:57 PM, Mike McGrath mmcgr...@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? -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. The Merchant of Venice ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
On Tue, 28 Apr 2009, Stephen John Smoogen wrote: On Tue, Apr 28, 2009 at 3:57 PM, Mike McGrath mmcgr...@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
