From freeipa at voidembraced.net Wed Apr 7 11:12:21 2010 From: freeipa at voidembraced.net (root) Date: Wed, 07 Apr 2010 04:12:21 -0700 Subject: [Freeipa-users] freeipa master server disaster recovery In-Reply-To: <4B4D3265.2020400@redhat.com> References: <20100112224238.5A5A362D5E@IronClad.SEA.voidembraced.net> <4B4D3265.2020400@redhat.com> Message-ID: <20100407111221.E60D763253@IronClad.SEA.voidembraced.net> >> Greetings FreeIPA mailing list: >> I have an FC11 environment setup for testing the FreeIPA implementation >> of kerberos+ldap w/admin utils. Our primary purpose for kerberos right >> now is to provide auth services for coda. However, once that gnat is >> squished, we'll of course be using kerberos for various other >> authentication services as well, and possibly using ldap for all manner >> of things (top of the list is basic server configuration information). >> So far, FreeIPA is a wonderful product and has very much simplified our >> deployment. >> My only real disappointment with FreeIPA, in fact, was seeing the notion >> of a "master server". Moreover, I have not been able to determine what >> configuration or crucial data is stored on the master server -- of utmost >> importance, is _where_ said crucial configuration/data is stored so that >> we may suitably back it up. >> This of course raises disaster recovery questions. Such as, in the event >> of a disaster, is it possible (and advisable?) to somehow "promote" a >> FreeIPA slave/peer server to "master" status? Or must we deploy a new >> server with the same name as the old and then somehow sync up the >> non-master data from the slave/peer(s)? Obviously, the best scenario >> would be that we could do either, as the decision on whether to promote >> or re-deploy will depend heavily on circumstances surrounding the >> failure. >> >> I am assuming the following scenario: >> *) master server goes down >> *) slave/peer(s) continue taking updates, the only exception being no >> FreeIPA servers may be deployed (correct??) >> *) several days pass >> *) master server is determined irreparable >> At which point, what should we have done prior to this failure, to give >> us the most options for recovery? >> >> Are there worse scenarios we can plan for? Any other actions we can take >> that might save our bacon down the road? > > Glad to hear the freeIPA is filling your needs. > > See this bug on promoting a new master: > https://bugzilla.redhat.com/show_bug.cgi?id=486950 > > Each IPA server is in fact a complete standalone server. The only > distinctions about the "master" are: > - It was the first one installed > - It owns the CA private key so only it can generate replicas > - It is the hub for replication > > The MMR we set up has each replica talking to this initial master. So if > it goes down all communication between other replicas is hosed. > > All is not lost though. You can use ipa-replica-manage to set up > additional communication links between your replicas. I don't think I'd > get too carried away with this though and make each replica talk to every > other replica. > > We just don't set up these additional links by default. How can these links be established after the master is down for the count? For that matter, how do we "convert" one of the non-master servers to a new master (assuming we've got the CA backed-up, of course)? > It all depends on your needs, paranoia, etc. Critically though you should > back up the CA cert and key and stick it in a vault somewhere, the > kerberos master key too if you're really paranoid (but it exists on the > replicas too, unlike the CA key). Where is this crucial data stored? I think I had this all sorted, but then my laptop crashed. Regardless, I can't seem to find it on my free-ipa server. Regards, -Don {void} From rcritten at redhat.com Wed Apr 7 17:30:02 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Apr 2010 13:30:02 -0400 Subject: [Freeipa-users] freeipa master server disaster recovery In-Reply-To: <20100407111221.E60D763253@IronClad.SEA.voidembraced.net> References: <20100112224238.5A5A362D5E@IronClad.SEA.voidembraced.net> <4B4D3265.2020400@redhat.com> <20100407111221.E60D763253@IronClad.SEA.voidembraced.net> Message-ID: <4BBCC11A.9020502@redhat.com> root wrote: >>> Greetings FreeIPA mailing list: >>> I have an FC11 environment setup for testing the FreeIPA >>> implementation of kerberos+ldap w/admin utils. Our primary purpose >>> for kerberos right now is to provide auth services for coda. >>> However, once that gnat is squished, we'll of course be using >>> kerberos for various other authentication services as well, and >>> possibly using ldap for all manner of things (top of the list is >>> basic server configuration information). >>> So far, FreeIPA is a wonderful product and has very much simplified >>> our deployment. >>> My only real disappointment with FreeIPA, in fact, was seeing the >>> notion of a "master server". Moreover, I have not been able to >>> determine what configuration or crucial data is stored on the master >>> server -- of utmost importance, is _where_ said crucial >>> configuration/data is stored so that we may suitably back it up. >>> This of course raises disaster recovery questions. Such as, in the >>> event of a disaster, is it possible (and advisable?) to somehow >>> "promote" a FreeIPA slave/peer server to "master" status? Or must we >>> deploy a new server with the same name as the old and then somehow >>> sync up the non-master data from the slave/peer(s)? Obviously, the >>> best scenario would be that we could do either, as the decision on >>> whether to promote or re-deploy will depend heavily on circumstances >>> surrounding the failure. >>> I am assuming the following scenario: >>> *) master server goes down >>> *) slave/peer(s) continue taking updates, the only exception being no >>> FreeIPA servers may be deployed (correct??) >>> *) several days pass >>> *) master server is determined irreparable >>> At which point, what should we have done prior to this failure, to >>> give us the most options for recovery? >>> Are there worse scenarios we can plan for? Any other actions we can >>> take that might save our bacon down the road? >> >> Glad to hear the freeIPA is filling your needs. >> See this bug on promoting a new master: >> https://bugzilla.redhat.com/show_bug.cgi?id=486950 >> Each IPA server is in fact a complete standalone server. The only >> distinctions about the "master" are: >> - It was the first one installed >> - It owns the CA private key so only it can generate replicas >> - It is the hub for replication >> The MMR we set up has each replica talking to this initial master. So >> if it goes down all communication between other replicas is hosed. >> All is not lost though. You can use ipa-replica-manage to set up >> additional communication links between your replicas. I don't think >> I'd get too carried away with this though and make each replica talk >> to every other replica. >> We just don't set up these additional links by default. > > How can these links be established after the master is down for the count? > For that matter, how do we "convert" one of the non-master servers to a > new master (assuming we've got the CA backed-up, of course)? The bug outlines how to promote a replica to be the primary "master". You basically just need to import the CA and setup the serial number file. So lets say you had a master and 2 replicas. In reality the only thing that differentiates the first master is that it was installed first so has the CA. As far as data replication goes there is no distinction, they are all equal. So in this case your replication topology looks like: A /\ B C So all changes route through master A, the first installed server. If A has died and won't be replaced then you need to tell B about C (or vice versa) and tell it to forget about A. First you want to create an agreement from B to C: # ipa-replica-manage add C Wait a bit to be sure all pending updates get flushed out, then delete the agreement to A on both B and C: # ipa-replica-manage del C >> It all depends on your needs, paranoia, etc. Critically though you >> should back up the CA cert and key and stick it in a vault somewhere, >> the kerberos master key too if you're really paranoid (but it exists >> on the replicas too, unlike the CA key). > > Where is this crucial data stored? IPA is basically in the job of herding cats so important information is spread in a lot of places: - the CA private key is in /etc/dirsrv/slapd-INSTANCE - The file containing the last serial number issued by the CA is in /var/lib/ipa/ca_serialno - The KDC still has important configuration in /var/kerberos - The DS itself is configured in /etc/dirsrv/slapd-INSTACE. This is where all your data is stored - The configuration of Apache is important, that is in /etc/httpd/conf.d/ipa.conf, /etc/httpd.conf/ipa-rewrite.conf - The Apache SSL database is probably reproducable in a pinch but it is in /etc/httpd/alias - You might want the host keytabs in /etc/dirsrv/ds.keytab, /etc/httpd/conf/ipa.keytab and perhaps the host keytab in /etc/krb5.keytab. - If you've configured bind you'll probably want that configuration too. This may not be a an exhaustive list but it gives youa basic idea. > I think I had this all sorted, but then my laptop crashed. Regardless, > I can't seem to find it on my free-ipa server. > rob From james.roman at ssaihq.com Thu Apr 8 12:44:53 2010 From: james.roman at ssaihq.com (James Roman) Date: Thu, 08 Apr 2010 08:44:53 -0400 Subject: [Freeipa-users] freeipa master server disaster recovery In-Reply-To: <4BBCC11A.9020502@redhat.com> References: <20100112224238.5A5A362D5E@IronClad.SEA.voidembraced.net> <4B4D3265.2020400@redhat.com> <20100407111221.E60D763253@IronClad.SEA.voidembraced.net> <4BBCC11A.9020502@redhat.com> Message-ID: <4BBDCFC5.7090707@ssaihq.com> > The bug outlines how to promote a replica to be the primary "master". > You basically just need to import the CA and setup the serial number > file. > > So lets say you had a master and 2 replicas. In reality the only thing > that differentiates the first master is that it was installed first so > has the CA. As far as data replication goes there is no distinction, > they are all equal. > Along these lines, does this mean if I have imported certificates signed by a third party CA on all my freeipa servers, that all I would need to do is update the replication agreements (in my case for freeIPA and AD)? From rcritten at redhat.com Thu Apr 8 17:28:08 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Apr 2010 13:28:08 -0400 Subject: [Freeipa-users] freeipa master server disaster recovery In-Reply-To: <4BBDCFC5.7090707@ssaihq.com> References: <20100112224238.5A5A362D5E@IronClad.SEA.voidembraced.net> <4B4D3265.2020400@redhat.com> <20100407111221.E60D763253@IronClad.SEA.voidembraced.net> <4BBCC11A.9020502@redhat.com> <4BBDCFC5.7090707@ssaihq.com> Message-ID: <4BBE1228.5040403@redhat.com> James Roman wrote: > >> The bug outlines how to promote a replica to be the primary "master". >> You basically just need to import the CA and setup the serial number >> file. >> >> So lets say you had a master and 2 replicas. In reality the only thing >> that differentiates the first master is that it was installed first so >> has the CA. As far as data replication goes there is no distinction, >> they are all equal. >> > Along these lines, does this mean if I have imported certificates signed > by a third party CA on all my freeipa servers, that all I would need to > do is update the replication agreements (in my case for freeIPA and AD)? For IPA servers yes. If the IPA server that dies is running the AD connection then yes, you'd have to set that up again as well. AD replication is not MMR-safe so you should have only one IPA server set up with AD replication. rob From freeipa at voidembraced.net Fri Apr 9 01:49:18 2010 From: freeipa at voidembraced.net (root) Date: Thu, 08 Apr 2010 18:49:18 -0700 Subject: [Freeipa-users] freeipa master server disaster recovery In-Reply-To: <4BBCC11A.9020502@redhat.com> References: <20100112224238.5A5A362D5E@IronClad.SEA.voidembraced.net> <4B4D3265.2020400@redhat.com> <20100407111221.E60D763253@IronClad.SEA.voidembraced.net> <4BBCC11A.9020502@redhat.com> Message-ID: <20100409014918.5DA9263253@IronClad.SEA.voidembraced.net> Rob Crittenden writes: > root wrote: >>>> Greetings FreeIPA mailing list: >>>> I have an FC11 environment setup for testing the FreeIPA implementation >>>> of kerberos+ldap w/admin utils. Our primary purpose for kerberos right >>>> now is to provide auth services for coda. However, once that gnat is >>>> squished, we'll of course be using kerberos for various other >>>> authentication services as well, and possibly using ldap for all manner >>>> of things (top of the list is basic server configuration information). >>>> So far, FreeIPA is a wonderful product and has very much simplified our >>>> deployment. >>>> My only real disappointment with FreeIPA, in fact, was seeing the >>>> notion of a "master server". Moreover, I have not been able to >>>> determine what configuration or crucial data is stored on the master >>>> server -- of utmost importance, is _where_ said crucial >>>> configuration/data is stored so that we may suitably back it up. >>>> This of course raises disaster recovery questions. Such as, in the >>>> event of a disaster, is it possible (and advisable?) to somehow >>>> "promote" a FreeIPA slave/peer server to "master" status? Or must we >>>> deploy a new server with the same name as the old and then somehow sync >>>> up the non-master data from the slave/peer(s)? Obviously, the best >>>> scenario would be that we could do either, as the decision on whether >>>> to promote or re-deploy will depend heavily on circumstances >>>> surrounding the failure. >>>> I am assuming the following scenario: >>>> *) master server goes down >>>> *) slave/peer(s) continue taking updates, the only exception being no >>>> F>> I think I had this all sorted, but then my laptop crashed. Regardless, I >> can't seem to find it on my free-ipa server. >> > > rob reeIPA servers may be deployed (correct??) >>>> *) several days pass >>>> *) master server is determined irreparable >>>> At which point, what should we have done prior to this failure, to give >>>> us the most options for recovery? >>>> Are there worse scenarios we can plan for? Any other actions we can >>>> take that might save our bacon down the road? >>> >>> Glad to hear the freeIPA is filling your needs. >>> See this bug on promoting a new master: >>> https://bugzilla.redhat.com/show_bug.cgi?id=486950 >>> Each IPA server is in fact a complete standalone server. The only >>> distinctions about the "master" are: >>> - It was the first one installed >>> - It owns the CA private key so only it can generate replicas >>> - It is the hub for replication >>> The MMR we set up has each replica talking to this initial master. So if >>> it goes down all communication between other replicas is hosed. >>> All is not lost though. You can use ipa-replica-manage to set up >>> additional communication links between your replicas. I don't think I'd >>> get too carried away with this though and make each replica talk to >>> every other replica. >>> We just don't set up these additional links by default. >> >> How can these links be established after the master is down for the >> count? >> For that matter, how do we "convert" one of the non-master servers to a >> new master (assuming we've got the CA backed-up, of course)? > > The bug outlines how to promote a replica to be the primary "master". You > basically just need to import the CA and setup the serial number file. > > So lets say you had a master and 2 replicas. In reality the only thing > that differentiates the first master is that it was installed first so has > the CA. As far as data replication goes there is no distinction, they are > all equal. > > So in this case your replication topology looks like: > > A > /\ > B C > > So all changes route through master A, the first installed server. If A > has died and won't be replaced then you need to tell B about C (or vice > versa) and tell it to forget about A. > > First you want to create an agreement from B to C: > >> I think I had this all sorted, but then my laptop crashed. Regardless, I >> can't seem to find it on my free-ipa server. >> > > rob > # ipa-replica-manage add C > > Wait a bit to be sure all pending updates get flushed out, then delete the > agreement to A on both B and C: > > # ipa-replica-manage del C Wow, thanks for the hand holding. That's so easy it's embarrassing. >>> It all depends on your needs, paranoia, etc. Critically though you >>> should back up the CA cert and key and stick it in a vault somewhere, >>> the kerberos master key too if you're really paranoid (but it exists on >>> the replicas too, unlike the CA key). >> >> Where is this crucial data stored? > > IPA is basically in the job of herding cats so important information is > spread in a lot of places: > > - the CA private key is in /etc/dirsrv/slapd-INSTANCE > - The file containing the last serial number issued by the CA is in > /var/lib/ipa/ca_serialno > - The KDC still has important configuration in /var/kerberos > - The DS itself is configured in /etc/dirsrv/slapd-INSTACE. This is where > all your data is stored > - The configuration of Apache is important, that is in > /etc/httpd/conf.d/ipa.conf, /etc/httpd.conf/ipa-rewrite.conf > - The Apache SSL database is probably reproducable in a pinch but it is in > /etc/httpd/alias > - You might want the host keytabs in /etc/dirsrv/ds.keytab, > /etc/httpd/conf/ipa.keytab and perhaps the host keytab in > /etc/krb5.keytab. > - If you've configured bind you'll probably want that configuration too. > > This may not be a an exhaustive list but it gives youa basic idea. Certainly! Question is, of the above data, assuming we're just rolling these servers out cookie cutter like and not futzing with each one individually, which files have irretrievable data (such as the CA private key and perhaps the CA serial). We handle the keytab(s) already as we do extensive keytab based auth. Most of the files listed seem like they are simply static config files, so I'm just double checking. Thanks! -Don {void} From o.burtchen at gmx.de Fri Apr 9 19:50:56 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Fri, 9 Apr 2010 21:50:56 +0200 Subject: [Freeipa-users] Using already running dogtag-instance possible? Message-ID: <201004092150.57003.o.burtchen@gmx.de> Hi @all, is it possible to use an already configured und running dogtag-instance for freeipa V2 in the installation process? I would like to give ipa-server- install just the params for the dogtag-instance/server to use, and skip its own creation-process (pkisilence ...). Or are there arguments for an extra CA used by freeipa? Background: I customized dogtag for my needs (using SHA256, default to 10 year validity of ca-SigningCert, organization and location defaults, etc. ). Best regards, Oli -- Oliver Burtchen, Berlin From rcritten at redhat.com Fri Apr 9 21:42:54 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Apr 2010 17:42:54 -0400 Subject: [Freeipa-users] Using already running dogtag-instance possible? In-Reply-To: <201004092150.57003.o.burtchen@gmx.de> References: <201004092150.57003.o.burtchen@gmx.de> Message-ID: <4BBF9F5E.7050104@redhat.com> Oliver Burtchen wrote: > Hi @all, > > is it possible to use an already configured und running dogtag-instance for > freeipa V2 in the installation process? I would like to give ipa-server- > install just the params for the dogtag-instance/server to use, and skip its > own creation-process (pkisilence ...). > > Or are there arguments for an extra CA used by freeipa? > > Background: I customized dogtag for my needs (using SHA256, default to 10 year > validity of ca-SigningCert, organization and location defaults, etc. ). > > Best regards, > Oli Probably the best way to do it would be to use the external CA install option (--external-ca). This is a two-step installation process. The first step generates a CSR for the IPA CA. You take this CSR to your existing CA and issue a subordinate CA certificate that will be used by IPA. Then you continue the IPA Installation and it sets up a separate dogtag instance with this subordinate CA. It might be possible to wedge in an existing dogtag install into IPA in another way but I haven't yet tried it. rob From o.burtchen at gmx.de Fri Apr 9 23:29:40 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Sat, 10 Apr 2010 01:29:40 +0200 Subject: [Freeipa-users] Using already running dogtag-instance possible? In-Reply-To: <4BBF9F5E.7050104@redhat.com> References: <201004092150.57003.o.burtchen@gmx.de> <4BBF9F5E.7050104@redhat.com> Message-ID: <201004100129.40874.o.burtchen@gmx.de> Hi Rob, thanks for the answer. I know about the externel CA-Cert possibility of ipa- server- install. But it does not what I want. I did setup a dogtag ca and a fedora-ds (389). It would be nice, if freeipa could just use them. I find it a little bit inconsitent that dogtag tries to be a central service, and freeipa claims to be the same, setting up a new one. BTW.: Freeipa setup tells me, that it should be the only 389-instance, and exist gracefully. Well, my dogtag and bind setup with 389-backend works quiet well, i just want freeipa to use them. Is there a possibility to setup freeipa this way? Thanks for the all in one setup, but it means I cannot run an other ldap (389) server(-instance) on a machine where freeipa is running. Is this right? Best regards, Oli Am Freitag, 9. April 2010 23:42:54 schrieb Rob Crittenden: > Oliver Burtchen wrote: > > Hi @all, > > > > is it possible to use an already configured und running dogtag-instance > > for freeipa V2 in the installation process? I would like to give > > ipa-server- install just the params for the dogtag-instance/server to > > use, and skip its own creation-process (pkisilence ...). > > > > Or are there arguments for an extra CA used by freeipa? > > > > Background: I customized dogtag for my needs (using SHA256, default to 10 > > year validity of ca-SigningCert, organization and location defaults, etc. > > ). > > > > Best regards, > > Oli > > Probably the best way to do it would be to use the external CA install > option (--external-ca). This is a two-step installation process. The > first step generates a CSR for the IPA CA. You take this CSR to your > existing CA and issue a subordinate CA certificate that will be used by > IPA. Then you continue the IPA Installation and it sets up a separate > dogtag instance with this subordinate CA. > > It might be possible to wedge in an existing dogtag install into IPA in > another way but I haven't yet tried it. > > rob > -- Oliver Burtchen, Berlin From dpal at redhat.com Mon Apr 12 13:47:12 2010 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 12 Apr 2010 09:47:12 -0400 Subject: [Freeipa-users] Using already running dogtag-instance possible? In-Reply-To: <201004100129.40874.o.burtchen@gmx.de> References: <201004092150.57003.o.burtchen@gmx.de> <4BBF9F5E.7050104@redhat.com> <201004100129.40874.o.burtchen@gmx.de> Message-ID: <4BC32460.60009@redhat.com> Oliver Burtchen wrote: > Hi Rob, > > thanks for the answer. I know about the externel CA-Cert possibility of ipa- > server- install. But it does not what I want. > > I did setup a dogtag ca and a fedora-ds (389). It would be nice, if freeipa > could just use them. I find it a little bit inconsitent that dogtag tries to be > a central service, and freeipa claims to be the same, setting up a new one. > > BTW.: Freeipa setup tells me, that it should be the only 389-instance, and > exist gracefully. Well, my dogtag and bind setup with 389-backend works quiet > well, i just want freeipa to use them. > > Is there a possibility to setup freeipa this way? Thanks for the all in one > setup, but it means I cannot run an other ldap (389) server(-instance) on a > machine where freeipa is running. Is this right? > > The whole point of freeIPA is to make things simple for less sophisticated setups than you have. I am not sure something like what you are asking is possible with freeIPA but I will defer to Rob to confirm. I think you would have to effectively redo the freeIPA installer to make things work the way you need. There is no contradiction between what you observe. The freeIPA is in a long term coming as a replacement of just stand alone CA, DS, KDC, DNS etc. This is the vision. And as far as I remember you are maintaining a separate instance of CA just because of the lack functionality in the upstream CA. I remember seeing some thread about it on the Dogtag list. For us it would be a higher priority to address your original issue that causes you to maintain a separate instance rather than move freeIPA into the direction of supporting external instances. Can you give a me a summary of the issues that force you to maintain a separate instance? I will see what can be done about it. Thanks Dmitri > Best regards, > Oli > > > > > Am Freitag, 9. April 2010 23:42:54 schrieb Rob Crittenden: > >> Oliver Burtchen wrote: >> >>> Hi @all, >>> >>> is it possible to use an already configured und running dogtag-instance >>> for freeipa V2 in the installation process? I would like to give >>> ipa-server- install just the params for the dogtag-instance/server to >>> use, and skip its own creation-process (pkisilence ...). >>> >>> Or are there arguments for an extra CA used by freeipa? >>> >>> Background: I customized dogtag for my needs (using SHA256, default to 10 >>> year validity of ca-SigningCert, organization and location defaults, etc. >>> ). >>> >>> Best regards, >>> Oli >>> >> Probably the best way to do it would be to use the external CA install >> option (--external-ca). This is a two-step installation process. The >> first step generates a CSR for the IPA CA. You take this CSR to your >> existing CA and issue a subordinate CA certificate that will be used by >> IPA. Then you continue the IPA Installation and it sets up a separate >> dogtag instance with this subordinate CA. >> >> It might be possible to wedge in an existing dogtag install into IPA in >> another way but I haven't yet tried it. >> >> rob >> >> > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Tue Apr 13 17:58:23 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Apr 2010 13:58:23 -0400 Subject: [Freeipa-users] Using already running dogtag-instance possible? In-Reply-To: <201004100129.40874.o.burtchen@gmx.de> References: <201004092150.57003.o.burtchen@gmx.de> <4BBF9F5E.7050104@redhat.com> <201004100129.40874.o.burtchen@gmx.de> Message-ID: <4BC4B0BF.7070802@redhat.com> Oliver Burtchen wrote: > Hi Rob, > > thanks for the answer. I know about the externel CA-Cert possibility of ipa- > server- install. But it does not what I want. > > I did setup a dogtag ca and a fedora-ds (389). It would be nice, if freeipa > could just use them. I find it a little bit inconsitent that dogtag tries to be > a central service, and freeipa claims to be the same, setting up a new one. Well, it gets tricky because we need an RA certificate in IPA and there is no automated way to get this with an existing dogtag installation. This is why making IPA a subordinate CA is suggested, so you can continue with your existing central authority. I'm sure it's possible to wedge in an existing dogtag instance, it would just take a bit of work and lots of code reading. Among the things you'd have to do are: - change the dogtag ports in IPA - have your CA issue an RA certificate and trust that user in the existing CA - load that RA cert and private key into /etc/httpd/alias using the right nickname - set the right CA type in /etc/ipa/default.conf on the IPA server Perhaps some other things I'm missing. I'm not sure how cloning will work in this case. > BTW.: Freeipa setup tells me, that it should be the only 389-instance, and > exist gracefully. Well, my dogtag and bind setup with 389-backend works quiet > well, i just want freeipa to use them. IPA is really geared for configuration on a fresh install. We have to touch so many things the installation is difficult as it is. Having to integrate with a lot of existing services makes this doubly more difficult. You can always disable the check (only via code now, no arguments for this). > Is there a possibility to setup freeipa this way? Thanks for the all in one > setup, but it means I cannot run an other ldap (389) server(-instance) on a > machine where freeipa is running. Is this right? You can't if it is already installed, at least not without a small code change. We have to use the 80/20 rule here and try to have some control over the initial environment before trying the installation. It is probably possible to do what you want given time and patience but we are unlikely to do this in the near future. rob > > Best regards, > Oli > > > > > Am Freitag, 9. April 2010 23:42:54 schrieb Rob Crittenden: >> Oliver Burtchen wrote: >>> Hi @all, >>> >>> is it possible to use an already configured und running dogtag-instance >>> for freeipa V2 in the installation process? I would like to give >>> ipa-server- install just the params for the dogtag-instance/server to >>> use, and skip its own creation-process (pkisilence ...). >>> >>> Or are there arguments for an extra CA used by freeipa? >>> >>> Background: I customized dogtag for my needs (using SHA256, default to 10 >>> year validity of ca-SigningCert, organization and location defaults, etc. >>> ). >>> >>> Best regards, >>> Oli >> Probably the best way to do it would be to use the external CA install >> option (--external-ca). This is a two-step installation process. The >> first step generates a CSR for the IPA CA. You take this CSR to your >> existing CA and issue a subordinate CA certificate that will be used by >> IPA. Then you continue the IPA Installation and it sets up a separate >> dogtag instance with this subordinate CA. >> >> It might be possible to wedge in an existing dogtag install into IPA in >> another way but I haven't yet tried it. >> >> rob >> > From tom at ng23.net Thu Apr 15 11:58:46 2010 From: tom at ng23.net (Tom Brown) Date: Thu, 15 Apr 2010 12:58:46 +0100 Subject: [Freeipa-users] ipa-useradd - setting gid using cli Message-ID: <4BC6FF76.7050803@ng23.net> Hi I need to bulk insert a bunch of users, and i need to create them with certain gid's but i dont see where i can do that using the cli. Are there any pointers here? thanks From rcritten at redhat.com Thu Apr 15 13:26:30 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Apr 2010 09:26:30 -0400 Subject: [Freeipa-users] ipa-useradd - setting gid using cli In-Reply-To: <4BC6FF76.7050803@ng23.net> References: <4BC6FF76.7050803@ng23.net> Message-ID: <4BC71406.5010509@redhat.com> Tom Brown wrote: > Hi > > I need to bulk insert a bunch of users, and i need to create them with > certain gid's but i dont see where i can do that using the cli. Are > there any pointers here? > There is currently not a way to directly set the user's gidnumber other than the default group for all users (currently ipausers). Can you provide more details on what your requirements are? I should add that we're investigating adding support for user private groups. rob From tom at ng23.net Thu Apr 15 13:34:48 2010 From: tom at ng23.net (Tom Brown) Date: Thu, 15 Apr 2010 14:34:48 +0100 Subject: [Freeipa-users] ipa-useradd - setting gid using cli In-Reply-To: <4BC71406.5010509@redhat.com> References: <4BC6FF76.7050803@ng23.net> <4BC71406.5010509@redhat.com> Message-ID: <4BC715F8.5060100@ng23.net> > > There is currently not a way to directly set the user's gidnumber > other than the default group for all users (currently ipausers). > > Can you provide more details on what your requirements are? > > I should add that we're investigating adding support for user private > groups. > > Hi - Well use case here is that we currently have users who have specific uid's that are the same over all boxes, this is managed by distributing password files basically. Now we'd like to bring IPA into the mix to replace this user administration method but we want to keep uid's the same across IPA'd and non IPA'd hosts at the moment. I can achieve that with ipa-adduser brownb -p Password01 --addattr uidnumber=7296 -f Bobby -l Brown ?? thanks ah seems i wrote gui in my inital mail rather than uid - my bad From tom at ng23.net Thu Apr 15 17:51:28 2010 From: tom at ng23.net (Tom Brown) Date: Thu, 15 Apr 2010 18:51:28 +0100 Subject: [Freeipa-users] freeipa - f12 - web gui logon issues Message-ID: <4BC75220.3040703@ng23.net> Hi I have seemingly followed the howto on getting this running and i have made the changes required as noted in about:config but i do not seem to be able to get to the GUI admin screen. No matter what i seem to do all i am presented with is 'Kerberos Authentication Failed' Any clues as to what causes this or where to look for logs as i cant see anything obvious anywhere thanks From rcritten at redhat.com Thu Apr 15 18:16:56 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Apr 2010 14:16:56 -0400 Subject: [Freeipa-users] freeipa - f12 - web gui logon issues In-Reply-To: <4BC75220.3040703@ng23.net> References: <4BC75220.3040703@ng23.net> Message-ID: <4BC75818.3080705@redhat.com> Tom Brown wrote: > Hi > > I have seemingly followed the howto on getting this running and i have > made the changes required as noted in about:config but i do not seem to > be able to get to the GUI admin screen. No matter what i seem to do all > i am presented with is 'Kerberos Authentication Failed' > > Any clues as to what causes this or where to look for logs as i cant see > anything obvious anywhere Not sure which howto you referred to but this covers it pretty well http://freeipa.org/docs/1.2/Client_Setup_Guide/en-US/html/chap-Client_Configuration_Guide-Configuring_Your_Browser.html For troubleshooting the client side see http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_the_IPA_Server-Configuring_Your_Browser.html#sect-Installation_and_Deployment_Guide-Configuring_Your_Browser-Troubleshooting The logs to look at are: /var/log/httpd/error_log (you'll probably want to set LogLevel debug in /etc/httpd/conf/httpd.conf and restart the httpd service first). The KDC log might be interesting, /var/log/krb5kdc.log I assume that you have a kerberos ticket? Sometimes quiting Firefox, doing a kdestroy, kinit, restart Firefox helps. rob From tom at ng23.net Thu Apr 15 19:11:26 2010 From: tom at ng23.net (Tom Brown) Date: Thu, 15 Apr 2010 20:11:26 +0100 Subject: [Freeipa-users] freeipa - f12 - web gui logon issues In-Reply-To: <4BC75818.3080705@redhat.com> References: <4BC75220.3040703@ng23.net> <4BC75818.3080705@redhat.com> Message-ID: <4BC764DE.9090009@ng23.net> > > Not sure which howto you referred to but this covers it pretty well > http://freeipa.org/docs/1.2/Client_Setup_Guide/en-US/html/chap-Client_Configuration_Guide-Configuring_Your_Browser.html > > > For troubleshooting the client side see > http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_the_IPA_Server-Configuring_Your_Browser.html#sect-Installation_and_Deployment_Guide-Configuring_Your_Browser-Troubleshooting > > > The logs to look at are: > > /var/log/httpd/error_log (you'll probably want to set LogLevel debug > in /etc/httpd/conf/httpd.conf and restart the httpd service first). > > The KDC log might be interesting, /var/log/krb5kdc.log > > I assume that you have a kerberos ticket? Sometimes quiting Firefox, > doing a kdestroy, kinit, restart Firefox helps. > > ok seems my mistake was not doing the kinit admin as the user using firefox, doing that seems to have made me able to get into the GUI. I am now presented with a different issue though - the GUI seemed to work but now it just hangs loading and i see this in the logs [Thu Apr 15 20:05:40 2010] [error] [client 192.168.10.14] proxy: Error reading from remote server returned by /ipa/ui/topsearch, referer: https://ipa-server.ng23.net/ipa/ui [Thu Apr 15 20:07:53 2010] [error] [client 192.168.10.14] (70007)The timeout specified has expired: proxy: error reading status line from remote server localhost [Thu Apr 15 20:07:53 2010] [error] [client 192.168.10.14] proxy: Error reading from remote server returned by /ipa/ui/topsearch [Thu Apr 15 20:08:30 2010] [error] [client 192.168.10.14] (70007)The timeout specified has expired: proxy: error reading status line from remote server localhost [Thu Apr 15 20:08:30 2010] [error] [client 192.168.10.14] proxy: Error reading from remote server returned by /ipa/ui/topsearch [Thu Apr 15 20:09:37 2010] [error] [client 192.168.10.14] (70007)The timeout specified has expired: proxy: error reading status line from remote server localhost [Thu Apr 15 20:09:37 2010] [error] [client 192.168.10.14] proxy: Error reading from remote server returned by /ipa/ui/topsearch [Thu Apr 15 20:09:45 2010] [error] [client 192.168.10.14] (70007)The timeout specified has expired: proxy: error reading status line from remote thanks From rcritten at redhat.com Thu Apr 15 20:38:49 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Apr 2010 16:38:49 -0400 Subject: [Freeipa-users] freeipa - f12 - web gui logon issues In-Reply-To: <4BC764DE.9090009@ng23.net> References: <4BC75220.3040703@ng23.net> <4BC75818.3080705@redhat.com> <4BC764DE.9090009@ng23.net> Message-ID: <4BC77959.7010406@redhat.com> Tom Brown wrote: > >> >> Not sure which howto you referred to but this covers it pretty well >> http://freeipa.org/docs/1.2/Client_Setup_Guide/en-US/html/chap-Client_Configuration_Guide-Configuring_Your_Browser.html >> >> >> For troubleshooting the client side see >> http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_the_IPA_Server-Configuring_Your_Browser.html#sect-Installation_and_Deployment_Guide-Configuring_Your_Browser-Troubleshooting >> >> >> The logs to look at are: >> >> /var/log/httpd/error_log (you'll probably want to set LogLevel debug >> in /etc/httpd/conf/httpd.conf and restart the httpd service first). >> >> The KDC log might be interesting, /var/log/krb5kdc.log >> >> I assume that you have a kerberos ticket? Sometimes quiting Firefox, >> doing a kdestroy, kinit, restart Firefox helps. >> >> > > ok seems my mistake was not doing the kinit admin as the user using > firefox, doing that seems to have made me able to get into the GUI. > > I am now presented with a different issue though - the GUI seemed to > work but now it just hangs loading and i see this in the logs > > [Thu Apr 15 20:05:40 2010] [error] [client 192.168.10.14] proxy: Error > reading from remote server returned by /ipa/ui/topsearch, referer: > https://ipa-server.ng23.net/ipa/ui > [Thu Apr 15 20:07:53 2010] [error] [client 192.168.10.14] (70007)The > timeout specified has expired: proxy: error reading status line from > remote server localhost > [Thu Apr 15 20:07:53 2010] [error] [client 192.168.10.14] proxy: Error > reading from remote server returned by /ipa/ui/topsearch > [Thu Apr 15 20:08:30 2010] [error] [client 192.168.10.14] (70007)The > timeout specified has expired: proxy: error reading status line from > remote server localhost > [Thu Apr 15 20:08:30 2010] [error] [client 192.168.10.14] proxy: Error > reading from remote server returned by /ipa/ui/topsearch > [Thu Apr 15 20:09:37 2010] [error] [client 192.168.10.14] (70007)The > timeout specified has expired: proxy: error reading status line from > remote server localhost > [Thu Apr 15 20:09:37 2010] [error] [client 192.168.10.14] proxy: Error > reading from remote server returned by /ipa/ui/topsearch > [Thu Apr 15 20:09:45 2010] [error] [client 192.168.10.14] (70007)The > timeout specified has expired: proxy: error reading status line from remote > > thanks > > > This is IPA v1.2 I gather? Try looking in /var/log/ipa_error.log, that is the UI log. In V1 we use TurboGears to create the UI pages. Apache handles the authentication using mod_auth_kerb and once the user is authenticated mod_proxy sends the request to the TurboGears process (ipa_webgui). Perhaps the TurboGears process died or is otherwise some sort of bad shape. rob From tom at ng23.net Thu Apr 15 22:13:43 2010 From: tom at ng23.net (Tom Brown) Date: Thu, 15 Apr 2010 23:13:43 +0100 Subject: [Freeipa-users] freeipa - f12 - web gui logon issues In-Reply-To: <4BC77959.7010406@redhat.com> References: <4BC75220.3040703@ng23.net> <4BC75818.3080705@redhat.com> <4BC764DE.9090009@ng23.net> <4BC77959.7010406@redhat.com> Message-ID: <4BC78F97.9070904@ng23.net> > > This is IPA v1.2 I gather? Try looking in /var/log/ipa_error.log, that > is the UI log. > > In V1 we use TurboGears to create the UI pages. Apache handles the > authentication using mod_auth_kerb and once the user is authenticated > mod_proxy sends the request to the TurboGears process (ipa_webgui). > Perhaps the TurboGears process died or is otherwise some sort of bad > shape. > > yes - its on 1.2.2. Seemingly it was a gears issue. There was nothing in ipa_error.log but restarting the gui component brought it back many thanks tom From o.burtchen at gmx.de Fri Apr 16 02:01:29 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Fri, 16 Apr 2010 04:01:29 +0200 Subject: [Freeipa-users] Using already running dogtag-instance possible? In-Reply-To: <4BC4B0BF.7070802@redhat.com> References: <201004092150.57003.o.burtchen@gmx.de> <201004100129.40874.o.burtchen@gmx.de> <4BC4B0BF.7070802@redhat.com> Message-ID: <201004160401.29488.o.burtchen@gmx.de> Hi Dmitri, hi Rob, first of all, thanks for your support and the detailed answers. It makes it clearer to me what the goal of freeipa is. I think it would fit exactly my needs for a new soho installation (managing round about 20 clients, some laptops and often changing employees), if some issues can be solved. I'll try to answer to you both together. Just to remember, I'm using the latest IPA V2 from the repository http://jdennis.fedorapeople.org/ipa-devel/fedora/12/... I found that in the docs and hope its the best source. And I'm using a clean F12 installation with all updates. I started to fiddle around with the installation process, because it breaks by bug a) after solving it I saw bug b), and so on.. ;-) After that, I came to the conclusion it would be better to setup dns and dogtag by hand. But it would be great just to use ipa-server-install. So here are my observations with hopefully helpful solution-hints, as I wrote them down for myself. By the way, thanks for the great work to the FreeIPA-Team so far. Bugs and solution-hints: a) The installation-process of pki/dogtag (pkicreate/pkisilent) throws an exception and breaks down documented in the logs, if the locale is different from ?en?. This is not because of missing translations, but because of a wrong use of java-load-resources (filenames) in the pki-sources, so it does not find the english fallbacks (which are the only ones for now, what is okay). As I described in this bugreport https://bugzilla.redhat.com/show_bug.cgi?id=441974#c34 it is very obviously and easy to fix, but now pending for 2 years. And the dogtag Known Issues: Problems and Solutions ? page http://pki.fedoraproject.org/wiki/PKI_Known_Issues just says: ?Change LC_CTYPE to en_US before starting and everything will work?. Okay, I understand. Sounds a little bit like what I heard often: Change OS_TYPE to MS before starting and everything will work. Just kidding. ;-) But it should not be difficult to change a handfull of filenames, so this great peace of software would work all over the world, not just in the english locale. I don't want to comment this any further. ;-) b) Using ?ipa-server-install --setup-dns?, the SOA Records in DNS are wrong. There are missing trailing dots for server-name und email, at reverse-zone also in the zone-name. To look at this, just use dig and dig -x on domain, changing it directly in ldap corrects it.. Should be easy to fix in ipaserver/install/bindinstance.py c) manpage ipa-server-install(1): there is no short-option -U for --uninstall, it's bogus with --unattended Thoughts and wishes which could be realized with no big effort: d) Email for zone-manager in bind-setup should be asked/customizeable (root at domain.name is IMHO not a good choice). Maybe this option/answer should also be used as ?o=IPA,e=manager at domain.name? in base-subject for certificates, when ?subject is not set by user. e) To me, ipa is more an organisational unit, not the organisation of an individual soho ipa installation. IMHO a better choice for the default subject (if not given by option) used by certificates would be ?o=Local Security Domain,ou=IPA,e=manager at domain.name". This could be academic ;-) , but it's easier to find the certs in an certificate manager (firefox for example), and it is clearer that there is no official/global IPA CA or trust center with the name IPA. f) The default valid-range in dogtag for ca-signing cert is 2 years, others are a half year. This is a little bit short. Signing certs for a ca are normaly good for 10 years, and if I think about the release-schedule und updates of fedora, the cert for clients/servers should be valid for at least 1 ? year in this context. Currently pkicreate nor pkisilent offer an option to change this. My workaround is to alter the profile-files between the runs of pkicreate and pkisilent/wizard. Maybe it could be asked for the validity in ipa-server- install. Here is my bash-cli-script for 10 years validity: PKINAME=pki-ca; \ ORIGPWD=${PWD}; \ pkicreate -pki_instance_root=/var/lib -pki_instance_name=${PKINAME} \ -subsystem_type=ca -agent_secure_port=9443 -ee_secure_port=9444 \ -admin_secure_port=9445 -unsecure_port=9180 -tomcat_server_port=9701 \ -user=pkiuser -group=pkiuser -redirect conf=/etc/${PKINAME} \ -redirect logs=/var/log/${PKINAME} -verbose; \ \ cd /etc/${PKINAME}; \ \ cp caCert.profile caCert.profile.orig; \ sed 's/2.default.params.range=[0-9]*/2.default.params.range=3650/g' \ < caCert.profile.orig > caCert.profile; \ rm -f caCert.profile.orig; \ \ cd /var/lib/${PKINAME}/profiles/ca; \ \ cp caCACert.cfg caCACert.cfg.orig; \ sed 's/policyset.caCertSet.2.constraint.params.range=[0-9]*/policyset.caCertSet.2.constraint.params.range=3650/g' \ < caCACert.cfg.orig > caCACert.cfg.tmp; \ sed 's/policyset.caCertSet.2.default.params.range=[0-9]*/policyset.caCertSet.2.default.params.range=3650/g' \ < caCACert.cfg.tmp > caCACert.cfg ; \ rm -f caCACert.cfg.tmp; \ rm -f caCACert.cfg.orig; \ \ cd ${ORIGPWD}; \ service pki-cad restart ${PKINAME} Thoughts and wishes for the future: g) Currently only SHA1withRSA is used/supported by the pkisilent installation, but it is a little bit outdated. Despite this, the dogtag-system supports the successors like SHA256, etc. out of the box. There was a discussion about it here: https://www.redhat.com/archives/pki-users/2010-April/msg00007.html Currently you have to renewal your initial certs with dogtag by hand, to get this modern hash-alg. It would be nice, if ipa-server-install would give an option to choose the hash-alg as soon, as pkisilent does. Okay, hope it was not to much for one posting, best regards, Oli Am Dienstag, 13. April 2010 19:58:23 schrieb Rob Crittenden: > Oliver Burtchen wrote: > > Hi Rob, > > > > thanks for the answer. I know about the externel CA-Cert possibility of > > ipa- server- install. But it does not what I want. > > > > I did setup a dogtag ca and a fedora-ds (389). It would be nice, if > > freeipa could just use them. I find it a little bit inconsitent that > > dogtag tries to be a central service, and freeipa claims to be the same, > > setting up a new one. > > Well, it gets tricky because we need an RA certificate in IPA and there > is no automated way to get this with an existing dogtag installation. > This is why making IPA a subordinate CA is suggested, so you can > continue with your existing central authority. > > I'm sure it's possible to wedge in an existing dogtag instance, it would > just take a bit of work and lots of code reading. Among the things you'd > have to do are: > > - change the dogtag ports in IPA > - have your CA issue an RA certificate and trust that user in the > existing CA > - load that RA cert and private key into /etc/httpd/alias using the > right nickname > - set the right CA type in /etc/ipa/default.conf on the IPA server > > Perhaps some other things I'm missing. I'm not sure how cloning will > work in this case. > > > BTW.: Freeipa setup tells me, that it should be the only 389-instance, > > and exist gracefully. Well, my dogtag and bind setup with 389-backend > > works quiet well, i just want freeipa to use them. > > IPA is really geared for configuration on a fresh install. We have to > touch so many things the installation is difficult as it is. Having to > integrate with a lot of existing services makes this doubly more > difficult. You can always disable the check (only via code now, no > arguments for this). > > > Is there a possibility to setup freeipa this way? Thanks for the all in > > one setup, but it means I cannot run an other ldap (389) > > server(-instance) on a machine where freeipa is running. Is this right? > > You can't if it is already installed, at least not without a small code > change. > > We have to use the 80/20 rule here and try to have some control over the > initial environment before trying the installation. It is probably > possible to do what you want given time and patience but we are unlikely > to do this in the near future. > > rob > > > Best regards, > > Oli > > > > Am Freitag, 9. April 2010 23:42:54 schrieb Rob Crittenden: > >> Oliver Burtchen wrote: > >>> Hi @all, > >>> > >>> is it possible to use an already configured und running dogtag-instance > >>> for freeipa V2 in the installation process? I would like to give > >>> ipa-server- install just the params for the dogtag-instance/server to > >>> use, and skip its own creation-process (pkisilence ...). > >>> > >>> Or are there arguments for an extra CA used by freeipa? > >>> > >>> Background: I customized dogtag for my needs (using SHA256, default to > >>> 10 year validity of ca-SigningCert, organization and location defaults, > >>> etc. ). > >>> > >>> Best regards, > >>> Oli > >> > >> Probably the best way to do it would be to use the external CA install > >> option (--external-ca). This is a two-step installation process. The > >> first step generates a CSR for the IPA CA. You take this CSR to your > >> existing CA and issue a subordinate CA certificate that will be used by > >> IPA. Then you continue the IPA Installation and it sets up a separate > >> dogtag instance with this subordinate CA. > >> > >> It might be possible to wedge in an existing dogtag install into IPA in > >> another way but I haven't yet tried it. > >> > >> rob > -- Oliver Burtchen, Berlin From rcritten at redhat.com Fri Apr 16 13:43:52 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Apr 2010 09:43:52 -0400 Subject: [Freeipa-users] Using already running dogtag-instance possible? In-Reply-To: <201004160401.29488.o.burtchen@gmx.de> References: <201004092150.57003.o.burtchen@gmx.de> <201004100129.40874.o.burtchen@gmx.de> <4BC4B0BF.7070802@redhat.com> <201004160401.29488.o.burtchen@gmx.de> Message-ID: <4BC86998.8020408@redhat.com> Oliver Burtchen wrote: > Hi Dmitri, > hi Rob, > > first of all, thanks for your support and the detailed answers. It makes it > clearer to me what the goal of freeipa is. I think it would fit exactly my > needs for a new soho installation (managing round about 20 clients, some > laptops and often changing employees), if some issues can be solved. I'll try > to answer to you both together. > > Just to remember, I'm using the latest IPA V2 from the repository > http://jdennis.fedorapeople.org/ipa-devel/fedora/12/... I found that in the > docs and hope its the best source. And I'm using a clean F12 installation with > all updates. I don't know about "best" but it is basically our daily builds. So buyer beware :-) > I started to fiddle around with the installation process, because it breaks by > bug a) after solving it I saw bug b), and so on.. ;-) After that, I came to > the conclusion it would be better to setup dns and dogtag by hand. But it > would be great just to use ipa-server-install. So here are my observations > with hopefully helpful solution-hints, as I wrote them down for myself. > > By the way, thanks for the great work to the FreeIPA-Team so far. > > > Bugs and solution-hints: > > a) > The installation-process of pki/dogtag (pkicreate/pkisilent) throws an > exception and breaks down documented in the logs, if the locale is different > from ?en?. This is not because of missing translations, but because of a wrong > use of java-load-resources (filenames) in the pki-sources, so it does not find > the english fallbacks (which are the only ones for now, what is okay). As I > described in this bugreport > https://bugzilla.redhat.com/show_bug.cgi?id=441974#c34 it is very obviously > and easy to fix, but now pending for 2 years. Hmm, it seems like this should have been fixed in https://bugzilla.redhat.com/show_bug.cgi?id=442310 . I think the best thing to do would be to open a new bug and reference this old one. Bug 441974 is currently closed so is likely not on anyone's radar. > > And the dogtag > Known Issues: Problems and Solutions ? page > > http://pki.fedoraproject.org/wiki/PKI_Known_Issues > > just says: ?Change LC_CTYPE to en_US before starting and everything will > work?. > > Okay, I understand. Sounds a little bit like what I heard often: Change > OS_TYPE to MS before starting and everything will work. Just kidding. ;-) > > But it should not be difficult to change a handfull of filenames, so this great > peace of software would work all over the world, not just in the english > locale. I don't want to comment this any further. ;-) Yes, I wasn't aware of this restriction myself. I think it is definitely something that should be addressed. We are trying to be UTF-8 friendly in v2 and currently have 8 or 9 translations of the IPA management framework (though no German translation yet). For a short-term fix would it be acceptable if we set LC_CTYPE to en_US when installing dogtag? > > b) > Using ?ipa-server-install --setup-dns?, the SOA Records in DNS are wrong. > > There are missing trailing dots for server-name und email, at reverse-zone > also in the zone-name. To look at this, just use dig and dig -x on domain, > changing it directly in ldap corrects it.. > > Should be easy to fix in ipaserver/install/bindinstance.py Martin, can you look into this? I filed https://bugzilla.redhat.com/show_bug.cgi?id=583023 > > c) > manpage ipa-server-install(1): there is no short-option -U for --uninstall, > it's bogus with --unattended > Gah, good catch. I pushed this as a one-liner fix. > > > > Thoughts and wishes which could be realized with no big effort: > > d) > Email for zone-manager in bind-setup should be asked/customizeable > (root at domain.name is IMHO not a good choice). Maybe this option/answer should > also be used as ?o=IPA,e=manager at domain.name? in base-subject for certificates, > when ?subject is not set by user. We do something similar when installing dogtag. We set -admin_email to root at localhost. I filed https://bugzilla.redhat.com/show_bug.cgi?id=583027 > e) > To me, ipa is more an organisational unit, not the organisation of an > individual soho ipa installation. IMHO a better choice for the default subject > (if not given by option) used by certificates would be ?o=Local Security > Domain,ou=IPA,e=manager at domain.name". This could be academic ;-) , but it's > easier to find the certs in an certificate manager (firefox for example), and it > is clearer that there is no official/global IPA CA or trust center with the name > IPA. Yeah, my picking o=IPA was truly arbitrary. I'm open to further suggestions. By "Local Security Domain" do you mean substitute the domain name for this or literally use that string? > f) > The default valid-range in dogtag for ca-signing cert is 2 years, others are a > half year. This is a little bit short. Signing certs for a ca are normaly good > for 10 years, and if I think about the release-schedule und updates of fedora, > the cert for clients/servers should be valid for at least 1 ? year in this > context. I'll let the dogtag guys comment on this. I agree that 2 years for a CA sounds a bit short. > Thoughts and wishes for the future: > > g) > Currently only SHA1withRSA is used/supported by the pkisilent installation, > but it is a little bit outdated. Despite this, the dogtag-system supports the > successors like SHA256, etc. out of the box. There was a discussion about it > here: > > https://www.redhat.com/archives/pki-users/2010-April/msg00007.html > > Currently you have to renewal your initial certs with dogtag by hand, to get > this modern hash-alg. It would be nice, if ipa-server-install would give an > option to choose the hash-alg as soon, as pkisilent does. Yes, I think that if they add this capability we would want to take advantage of it. > Okay, hope it was not to much for one posting, > best regards, > Oli This is great feedback, thanks! rob > > > > > > Am Dienstag, 13. April 2010 19:58:23 schrieb Rob Crittenden: >> Oliver Burtchen wrote: >>> Hi Rob, >>> >>> thanks for the answer. I know about the externel CA-Cert possibility of >>> ipa- server- install. But it does not what I want. >>> >>> I did setup a dogtag ca and a fedora-ds (389). It would be nice, if >>> freeipa could just use them. I find it a little bit inconsitent that >>> dogtag tries to be a central service, and freeipa claims to be the same, >>> setting up a new one. >> Well, it gets tricky because we need an RA certificate in IPA and there >> is no automated way to get this with an existing dogtag installation. >> This is why making IPA a subordinate CA is suggested, so you can >> continue with your existing central authority. >> >> I'm sure it's possible to wedge in an existing dogtag instance, it would >> just take a bit of work and lots of code reading. Among the things you'd >> have to do are: >> >> - change the dogtag ports in IPA >> - have your CA issue an RA certificate and trust that user in the >> existing CA >> - load that RA cert and private key into /etc/httpd/alias using the >> right nickname >> - set the right CA type in /etc/ipa/default.conf on the IPA server >> >> Perhaps some other things I'm missing. I'm not sure how cloning will >> work in this case. >> >>> BTW.: Freeipa setup tells me, that it should be the only 389-instance, >>> and exist gracefully. Well, my dogtag and bind setup with 389-backend >>> works quiet well, i just want freeipa to use them. >> IPA is really geared for configuration on a fresh install. We have to >> touch so many things the installation is difficult as it is. Having to >> integrate with a lot of existing services makes this doubly more >> difficult. You can always disable the check (only via code now, no >> arguments for this). >> >>> Is there a possibility to setup freeipa this way? Thanks for the all in >>> one setup, but it means I cannot run an other ldap (389) >>> server(-instance) on a machine where freeipa is running. Is this right? >> You can't if it is already installed, at least not without a small code >> change. >> >> We have to use the 80/20 rule here and try to have some control over the >> initial environment before trying the installation. It is probably >> possible to do what you want given time and patience but we are unlikely >> to do this in the near future. >> >> rob >> >>> Best regards, >>> Oli >>> >>> Am Freitag, 9. April 2010 23:42:54 schrieb Rob Crittenden: >>>> Oliver Burtchen wrote: >>>>> Hi @all, >>>>> >>>>> is it possible to use an already configured und running dogtag-instance >>>>> for freeipa V2 in the installation process? I would like to give >>>>> ipa-server- install just the params for the dogtag-instance/server to >>>>> use, and skip its own creation-process (pkisilence ...). >>>>> >>>>> Or are there arguments for an extra CA used by freeipa? >>>>> >>>>> Background: I customized dogtag for my needs (using SHA256, default to >>>>> 10 year validity of ca-SigningCert, organization and location defaults, >>>>> etc. ). >>>>> >>>>> Best regards, >>>>> Oli >>>> Probably the best way to do it would be to use the external CA install >>>> option (--external-ca). This is a two-step installation process. The >>>> first step generates a CSR for the IPA CA. You take this CSR to your >>>> existing CA and issue a subordinate CA certificate that will be used by >>>> IPA. Then you continue the IPA Installation and it sets up a separate >>>> dogtag instance with this subordinate CA. >>>> >>>> It might be possible to wedge in an existing dogtag install into IPA in >>>> another way but I haven't yet tried it. >>>> >>>> rob > From o.burtchen at gmx.de Fri Apr 16 22:34:00 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Sat, 17 Apr 2010 00:34:00 +0200 Subject: [Freeipa-users] Using already running dogtag-instance possible? In-Reply-To: <4BC86998.8020408@redhat.com> References: <201004092150.57003.o.burtchen@gmx.de> <201004160401.29488.o.burtchen@gmx.de> <4BC86998.8020408@redhat.com> Message-ID: <201004170034.01243.o.burtchen@gmx.de> Am Freitag, 16. April 2010 15:43:52 schrieb Rob Crittenden: > ... > > Just to remember, I'm using the latest IPA V2 from the repository > > http://jdennis.fedorapeople.org/ipa-devel/fedora/12/... I found that in > > the docs and hope its the best source. And I'm using a clean F12 > > installation with all updates. > > I don't know about "best" but it is basically our daily builds. So buyer > beware :-) I'm aware of this. ;-) > ... > Hmm, it seems like this should have been fixed in > https://bugzilla.redhat.com/show_bug.cgi?id=442310 . > I think the best thing to do would be to open a new bug and reference > this old one. Bug 441974 is currently closed so is likely not on > anyone's radar. Okay, I reported a new one: https://bugzilla.redhat.com/show_bug.cgi?id=583177 It's just I'm not a fan of flooding bugzilla with same reports. > ... > Yes, I wasn't aware of this restriction myself. I think it is definitely > something that should be addressed. We are trying to be UTF-8 friendly > in v2 and currently have 8 or 9 translations of the IPA management > framework (though no German translation yet). > > For a short-term fix would it be acceptable if we set LC_CTYPE to en_US > when installing dogtag? I agree with it as a work around. Best practice IMHO would be: Insert a "LANG=en_US" at top in /etc/init.d/pki-cad an run pkicreate/pkisilent/pkiremove/... as # LANG=en_US pkicreate ... in ipa-server-install and friends. > > > b) > > Using ?ipa-server-install --setup-dns?, the SOA Records in DNS are wrong. > > > > There are missing trailing dots for server-name und email, at > > reverse-zone also in the zone-name. To look at this, just use dig and dig > > -x on domain, changing it directly in ldap corrects it.. > > > > Should be easy to fix in ipaserver/install/bindinstance.py > > Martin, can you look into this? I filed > https://bugzilla.redhat.com/show_bug.cgi?id=583023 > ... > > c) > > manpage ipa-server-install(1): there is no short-option -U for > > --uninstall, it's bogus with --unattended > > Gah, good catch. I pushed this as a one-liner fix. Great, thanks. Btw, is it better to report such things in bugzilla, here on the list, or both? As I said, I'm not a fan of flooding bugzilla. > > > Thoughts and wishes which could be realized with no big effort: > > > > d) > > Email for zone-manager in bind-setup should be asked/customizeable > > (root at domain.name is IMHO not a good choice). Maybe this option/answer > > should also be used as ?o=IPA,e=manager at domain.name? in base-subject for > > certificates, when ?subject is not set by user. > > We do something similar when installing dogtag. We set -admin_email to > root at localhost. > > I filed https://bugzilla.redhat.com/show_bug.cgi?id=583027 Thanks! > > > e) > > To me, ipa is more an organisational unit, not the organisation of an > > individual soho ipa installation. IMHO a better choice for the default > > subject (if not given by option) used by certificates would be ?o=Local > > Security Domain,ou=IPA,e=manager at domain.name". This could be academic > > ;-) , but it's easier to find the certs in an certificate manager > > (firefox for example), and it is clearer that there is no official/global > > IPA CA or trust center with the name IPA. > > Yeah, my picking o=IPA was truly arbitrary. I'm open to further > suggestions. By "Local Security Domain" do you mean substitute the > domain name for this or literally use that string? Well, I looked around a little bit, there seams no reserved or common dn/subject-name or something like this for local/private installs of a ca. I only found a rfc about reserved domain names for local installs: http://tools.ietf.org/html/rfc2606 So my best guesses, if we don't want to ask the user for the organization name (but asking would be great): literally use "o=Local Security Domain,ou=FreeIPA,e=..." or literally use "o=Localhost Security Domain,ou=FreeIPA,e=..." or "o= Security Domain,ou=FreeIPA,e=..." where in the last example should be replaced with the FQDN (without server) or the uppercase kerberos realm. Best regards, Oli > > > f) > > The default valid-range in dogtag for ca-signing cert is 2 years, others > > are a half year. This is a little bit short. Signing certs for a ca are > > normaly good for 10 years, and if I think about the release-schedule und > > updates of fedora, the cert for clients/servers should be valid for at > > least 1 ? year in this context. > > I'll let the dogtag guys comment on this. I agree that 2 years for a CA > sounds a bit short. > > > Thoughts and wishes for the future: > > > > g) > > Currently only SHA1withRSA is used/supported by the pkisilent > > installation, but it is a little bit outdated. Despite this, the > > dogtag-system supports the successors like SHA256, etc. out of the box. > > There was a discussion about it here: > > > > https://www.redhat.com/archives/pki-users/2010-April/msg00007.html > > > > Currently you have to renewal your initial certs with dogtag by hand, to > > get this modern hash-alg. It would be nice, if ipa-server-install would > > give an option to choose the hash-alg as soon, as pkisilent does. > > Yes, I think that if they add this capability we would want to take > advantage of it. > > > Okay, hope it was not to much for one posting, > > best regards, > > Oli > > This is great feedback, thanks! > > rob > > > Am Dienstag, 13. April 2010 19:58:23 schrieb Rob Crittenden: > >> Oliver Burtchen wrote: > >>> Hi Rob, > >>> > >>> thanks for the answer. I know about the externel CA-Cert possibility of > >>> ipa- server- install. But it does not what I want. > >>> > >>> I did setup a dogtag ca and a fedora-ds (389). It would be nice, if > >>> freeipa could just use them. I find it a little bit inconsitent that > >>> dogtag tries to be a central service, and freeipa claims to be the > >>> same, setting up a new one. > >> > >> Well, it gets tricky because we need an RA certificate in IPA and there > >> is no automated way to get this with an existing dogtag installation. > >> This is why making IPA a subordinate CA is suggested, so you can > >> continue with your existing central authority. > >> > >> I'm sure it's possible to wedge in an existing dogtag instance, it would > >> just take a bit of work and lots of code reading. Among the things you'd > >> have to do are: > >> > >> - change the dogtag ports in IPA > >> - have your CA issue an RA certificate and trust that user in the > >> existing CA > >> - load that RA cert and private key into /etc/httpd/alias using the > >> right nickname > >> - set the right CA type in /etc/ipa/default.conf on the IPA server > >> > >> Perhaps some other things I'm missing. I'm not sure how cloning will > >> work in this case. > >> > >>> BTW.: Freeipa setup tells me, that it should be the only 389-instance, > >>> and exist gracefully. Well, my dogtag and bind setup with 389-backend > >>> works quiet well, i just want freeipa to use them. > >> > >> IPA is really geared for configuration on a fresh install. We have to > >> touch so many things the installation is difficult as it is. Having to > >> integrate with a lot of existing services makes this doubly more > >> difficult. You can always disable the check (only via code now, no > >> arguments for this). > >> > >>> Is there a possibility to setup freeipa this way? Thanks for the all in > >>> one setup, but it means I cannot run an other ldap (389) > >>> server(-instance) on a machine where freeipa is running. Is this right? > >> > >> You can't if it is already installed, at least not without a small code > >> change. > >> > >> We have to use the 80/20 rule here and try to have some control over the > >> initial environment before trying the installation. It is probably > >> possible to do what you want given time and patience but we are unlikely > >> to do this in the near future. > >> > >> rob > >> > >>> Best regards, > >>> Oli > >>> > >>> Am Freitag, 9. April 2010 23:42:54 schrieb Rob Crittenden: > >>>> Oliver Burtchen wrote: > >>>>> Hi @all, > >>>>> > >>>>> is it possible to use an already configured und running > >>>>> dogtag-instance for freeipa V2 in the installation process? I would > >>>>> like to give ipa-server- install just the params for the > >>>>> dogtag-instance/server to use, and skip its own creation-process > >>>>> (pkisilence ...). > >>>>> > >>>>> Or are there arguments for an extra CA used by freeipa? > >>>>> > >>>>> Background: I customized dogtag for my needs (using SHA256, default > >>>>> to 10 year validity of ca-SigningCert, organization and location > >>>>> defaults, etc. ). > >>>>> > >>>>> Best regards, > >>>>> Oli > >>>> > >>>> Probably the best way to do it would be to use the external CA install > >>>> option (--external-ca). This is a two-step installation process. The > >>>> first step generates a CSR for the IPA CA. You take this CSR to your > >>>> existing CA and issue a subordinate CA certificate that will be used > >>>> by IPA. Then you continue the IPA Installation and it sets up a > >>>> separate dogtag instance with this subordinate CA. > >>>> > >>>> It might be possible to wedge in an existing dogtag install into IPA > >>>> in another way but I haven't yet tried it. > >>>> > >>>> rob > -- Oliver Burtchen, Berlin From rcritten at redhat.com Sat Apr 17 03:43:15 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Apr 2010 23:43:15 -0400 Subject: [Freeipa-users] Using already running dogtag-instance possible? In-Reply-To: <201004170034.01243.o.burtchen@gmx.de> References: <201004092150.57003.o.burtchen@gmx.de> <201004160401.29488.o.burtchen@gmx.de> <4BC86998.8020408@redhat.com> <201004170034.01243.o.burtchen@gmx.de> Message-ID: <4BC92E53.2020803@redhat.com> Oliver Burtchen wrote: > Am Freitag, 16. April 2010 15:43:52 schrieb Rob Crittenden: >> ... >>> Just to remember, I'm using the latest IPA V2 from the repository >>> http://jdennis.fedorapeople.org/ipa-devel/fedora/12/... I found that in >>> the docs and hope its the best source. And I'm using a clean F12 >>> installation with all updates. >> I don't know about "best" but it is basically our daily builds. So buyer >> beware :-) > > I'm aware of this. ;-) > >> ... >> Hmm, it seems like this should have been fixed in >> https://bugzilla.redhat.com/show_bug.cgi?id=442310 . >> I think the best thing to do would be to open a new bug and reference >> this old one. Bug 441974 is currently closed so is likely not on >> anyone's radar. > > Okay, I reported a new one: > > https://bugzilla.redhat.com/show_bug.cgi?id=583177 > > It's just I'm not a fan of flooding bugzilla with same reports. I completely understand. We can do this via the mailing or IRC until we nail individual problems down enough to file a bug, I'm ok with that. > >> ... >> Yes, I wasn't aware of this restriction myself. I think it is definitely >> something that should be addressed. We are trying to be UTF-8 friendly >> in v2 and currently have 8 or 9 translations of the IPA management >> framework (though no German translation yet). >> >> For a short-term fix would it be acceptable if we set LC_CTYPE to en_US >> when installing dogtag? > > I agree with it as a work around. Best practice IMHO would be: > > Insert a "LANG=en_US" at top in /etc/init.d/pki-cad > > an run pkicreate/pkisilent/pkiremove/... as > > # LANG=en_US pkicreate ... > > in ipa-server-install and friends. Well, I can easily control what IPA does. I can influence what dogtag does, I'll see what the best resolution is. > >>> b) >>> Using ?ipa-server-install --setup-dns?, the SOA Records in DNS are wrong. >>> >>> There are missing trailing dots for server-name und email, at >>> reverse-zone also in the zone-name. To look at this, just use dig and dig >>> -x on domain, changing it directly in ldap corrects it.. >>> >>> Should be easy to fix in ipaserver/install/bindinstance.py >> Martin, can you look into this? I filed >> https://bugzilla.redhat.com/show_bug.cgi?id=583023 >> ... >>> c) >>> manpage ipa-server-install(1): there is no short-option -U for >>> --uninstall, it's bogus with --unattended >> Gah, good catch. I pushed this as a one-liner fix. > > Great, thanks. Btw, is it better to report such things in bugzilla, here on > the list, or both? As I said, I'm not a fan of flooding bugzilla. I'm not worried about extraneous bug reports. The advantage of a bugzilla is it doesn't let me forget things to fix. If you want to be cautious you can always report problems on the list and we can address them as they come up, either with 1-liner fixes, explanations or bug filings. I'm fine with reporting problems on the list as long as real problems eventually end up as bugs. > >>> Thoughts and wishes which could be realized with no big effort: >>> >>> d) >>> Email for zone-manager in bind-setup should be asked/customizeable >>> (root at domain.name is IMHO not a good choice). Maybe this option/answer >>> should also be used as ?o=IPA,e=manager at domain.name? in base-subject for >>> certificates, when ?subject is not set by user. >> We do something similar when installing dogtag. We set -admin_email to >> root at localhost. >> >> I filed https://bugzilla.redhat.com/show_bug.cgi?id=583027 > > Thanks! > >>> e) >>> To me, ipa is more an organisational unit, not the organisation of an >>> individual soho ipa installation. IMHO a better choice for the default >>> subject (if not given by option) used by certificates would be ?o=Local >>> Security Domain,ou=IPA,e=manager at domain.name". This could be academic >>> ;-) , but it's easier to find the certs in an certificate manager >>> (firefox for example), and it is clearer that there is no official/global >>> IPA CA or trust center with the name IPA. >> Yeah, my picking o=IPA was truly arbitrary. I'm open to further >> suggestions. By "Local Security Domain" do you mean substitute the >> domain name for this or literally use that string? > > Well, I looked around a little bit, there seams no reserved or common > dn/subject-name or something like this for local/private installs of a ca. I > only found a rfc about reserved domain names for local installs: > > http://tools.ietf.org/html/rfc2606 > > So my best guesses, if we don't want to ask the user for the organization name > (but asking would be great): > > literally use "o=Local Security Domain,ou=FreeIPA,e=..." or > literally use "o=Localhost Security Domain,ou=FreeIPA,e=..." or > > "o= Security Domain,ou=FreeIPA,e=..." > > where in the last example should be replaced with the FQDN (without > server) or the uppercase kerberos realm. Ok, I'll chat with the dogtag team and see if they have any suggestions on best practices. I suspect it will end up very similar to your ideas. I'm not too keen on asking too many more questions during the installation, the biggest problem being if a user decides against using dogtag. If one uses dogtag we set the subject in a way that regardless of the subject in the CSR we just use the CN value. So we have ultimate control over the issued subject. With the self-signed CA we can only reject certificates that don't match what we allow. This isn't very user friendly but is the best we can do using the current NSS command-line tools we use for issuing certs. The NSS tools provide sort of a poor-man's CA so we do the best we can, it just isn't that flexible. Ideally we make the framework configurable enough so someone could plug in their own cA (tinyCA, OpenSSL, whatever). The backend is more flexible than the front-end (installer) at this point. The tricky part for anyone that wants to bolt on another CA is how to handle replication. But that's another story... > Best regards, > Oli Thanks again for the testing and feedback. cheers rob > > >>> f) >>> The default valid-range in dogtag for ca-signing cert is 2 years, others >>> are a half year. This is a little bit short. Signing certs for a ca are >>> normaly good for 10 years, and if I think about the release-schedule und >>> updates of fedora, the cert for clients/servers should be valid for at >>> least 1 ? year in this context. >> I'll let the dogtag guys comment on this. I agree that 2 years for a CA >> sounds a bit short. >> >>> Thoughts and wishes for the future: >>> >>> g) >>> Currently only SHA1withRSA is used/supported by the pkisilent >>> installation, but it is a little bit outdated. Despite this, the >>> dogtag-system supports the successors like SHA256, etc. out of the box. >>> There was a discussion about it here: >>> >>> https://www.redhat.com/archives/pki-users/2010-April/msg00007.html >>> >>> Currently you have to renewal your initial certs with dogtag by hand, to >>> get this modern hash-alg. It would be nice, if ipa-server-install would >>> give an option to choose the hash-alg as soon, as pkisilent does. >> Yes, I think that if they add this capability we would want to take >> advantage of it. >> >>> Okay, hope it was not to much for one posting, >>> best regards, >>> Oli >> This is great feedback, thanks! >> >> rob >> >>> Am Dienstag, 13. April 2010 19:58:23 schrieb Rob Crittenden: >>>> Oliver Burtchen wrote: >>>>> Hi Rob, >>>>> >>>>> thanks for the answer. I know about the externel CA-Cert possibility of >>>>> ipa- server- install. But it does not what I want. >>>>> >>>>> I did setup a dogtag ca and a fedora-ds (389). It would be nice, if >>>>> freeipa could just use them. I find it a little bit inconsitent that >>>>> dogtag tries to be a central service, and freeipa claims to be the >>>>> same, setting up a new one. >>>> Well, it gets tricky because we need an RA certificate in IPA and there >>>> is no automated way to get this with an existing dogtag installation. >>>> This is why making IPA a subordinate CA is suggested, so you can >>>> continue with your existing central authority. >>>> >>>> I'm sure it's possible to wedge in an existing dogtag instance, it would >>>> just take a bit of work and lots of code reading. Among the things you'd >>>> have to do are: >>>> >>>> - change the dogtag ports in IPA >>>> - have your CA issue an RA certificate and trust that user in the >>>> existing CA >>>> - load that RA cert and private key into /etc/httpd/alias using the >>>> right nickname >>>> - set the right CA type in /etc/ipa/default.conf on the IPA server >>>> >>>> Perhaps some other things I'm missing. I'm not sure how cloning will >>>> work in this case. >>>> >>>>> BTW.: Freeipa setup tells me, that it should be the only 389-instance, >>>>> and exist gracefully. Well, my dogtag and bind setup with 389-backend >>>>> works quiet well, i just want freeipa to use them. >>>> IPA is really geared for configuration on a fresh install. We have to >>>> touch so many things the installation is difficult as it is. Having to >>>> integrate with a lot of existing services makes this doubly more >>>> difficult. You can always disable the check (only via code now, no >>>> arguments for this). >>>> >>>>> Is there a possibility to setup freeipa this way? Thanks for the all in >>>>> one setup, but it means I cannot run an other ldap (389) >>>>> server(-instance) on a machine where freeipa is running. Is this right? >>>> You can't if it is already installed, at least not without a small code >>>> change. >>>> >>>> We have to use the 80/20 rule here and try to have some control over the >>>> initial environment before trying the installation. It is probably >>>> possible to do what you want given time and patience but we are unlikely >>>> to do this in the near future. >>>> >>>> rob >>>> >>>>> Best regards, >>>>> Oli >>>>> >>>>> Am Freitag, 9. April 2010 23:42:54 schrieb Rob Crittenden: >>>>>> Oliver Burtchen wrote: >>>>>>> Hi @all, >>>>>>> >>>>>>> is it possible to use an already configured und running >>>>>>> dogtag-instance for freeipa V2 in the installation process? I would >>>>>>> like to give ipa-server- install just the params for the >>>>>>> dogtag-instance/server to use, and skip its own creation-process >>>>>>> (pkisilence ...). >>>>>>> >>>>>>> Or are there arguments for an extra CA used by freeipa? >>>>>>> >>>>>>> Background: I customized dogtag for my needs (using SHA256, default >>>>>>> to 10 year validity of ca-SigningCert, organization and location >>>>>>> defaults, etc. ). >>>>>>> >>>>>>> Best regards, >>>>>>> Oli >>>>>> Probably the best way to do it would be to use the external CA install >>>>>> option (--external-ca). This is a two-step installation process. The >>>>>> first step generates a CSR for the IPA CA. You take this CSR to your >>>>>> existing CA and issue a subordinate CA certificate that will be used >>>>>> by IPA. Then you continue the IPA Installation and it sets up a >>>>>> separate dogtag instance with this subordinate CA. >>>>>> >>>>>> It might be possible to wedge in an existing dogtag install into IPA >>>>>> in another way but I haven't yet tried it. >>>>>> >>>>>> rob > From o.burtchen at gmx.de Mon Apr 19 02:29:57 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Mon, 19 Apr 2010 04:29:57 +0200 Subject: [Freeipa-users] Using already running dogtag-instance possible? In-Reply-To: <4BC92E53.2020803@redhat.com> References: <201004092150.57003.o.burtchen@gmx.de> <201004170034.01243.o.burtchen@gmx.de> <4BC92E53.2020803@redhat.com> Message-ID: <201004190429.57292.o.burtchen@gmx.de> Hi Rob, Am Samstag, 17. April 2010 05:43:15 schrieb Rob Crittenden: > ... > I'm not worried about extraneous bug reports. The advantage of a > bugzilla is it doesn't let me forget things to fix. If you want to be > cautious you can always report problems on the list and we can address > them as they come up, either with 1-liner fixes, explanations or bug > filings. I'm fine with reporting problems on the list as long as real > problems eventually end up as bugs. > Great. So I'll continue to post my observations here on the list. And if you say it's worth a bug report, I'll open one. > ... > I'm not too keen on asking too many more questions during the > installation, the biggest problem being if a user decides against using > dogtag. Well, I understand the point. But someone can always just press return, if the defaults are good. Other method would be to ask for an "express" or "expert/custom" installation. So all the boring questions for experts could be hidden from the "normal" user, but the installation is open to be used by more sophisticated users. > > If one uses dogtag we set the subject in a way that regardless of the > subject in the CSR we just use the CN value. So we have ultimate control > over the issued subject. > > With the self-signed CA we can only reject certificates that don't match > what we allow. This isn't very user friendly but is the best we can do > using the current NSS command-line tools we use for issuing certs. The > NSS tools provide sort of a poor-man's CA so we do the best we can, it > just isn't that flexible. > I think it's a well chosen tradeoff for an "all in one system" like freeIPA to use the cn-value for internal things, and let the rest (o, ou, e, st, etc.) left to the user. Maybe it could be a goal for v3 or v4 to make cn customizeable, so every foreign ca could be used. Best regards, Oli -- Oliver Burtchen, Berlin From o.burtchen at gmx.de Mon Apr 19 02:41:51 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Mon, 19 Apr 2010 04:41:51 +0200 Subject: [Freeipa-users] Unable to join a client Message-ID: <201004190441.51383.o.burtchen@gmx.de> Hi, using clean F12 installtion with all updates and ipa 1.91-0.2010041617git671bb9c.fc12 on server and client: Currently I'm unable to join a client, debug of ipa-client-install attached. Seems, there was a change in the protocol, and ipa-join gives to many arguments.. Best regards, Oli [root at testclient ~]# ipa-client-install -d root : DEBUG Loading Index file from '/var/lib/ipa- client/sysrestore/sysrestore.index' root : DEBUG [ipadnssearchldap(example.com)] root : DEBUG [ipadnssearchkrb] root : DEBUG [ipacheckldap] root : DEBUG Init ldap with: ldap://services.example.com:389 root : DEBUG Search rootdse root : DEBUG Search for (info=*) in dc=example.com(base) root : DEBUG Found: [('dc=example.com', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainObject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['example.com'], 'dc': ['example.com'], 'nisDomain': ['example.com']})] root : DEBUG Search for (objectClass=krbRealmContainer) in dc=example.com(sub) root : DEBUG Found: [('cn=EXAMPLE.COM,cn=kerberos,dc=example.com', {'krbSubTrees': ['dc=example.com'], 'cn': ['EXAMPLE.COM'], 'krbDefaultEncSaltTypes': ['aes256-cts:normal', 'aes128-cts:normal', 'des3- hmac-sha1:normal', 'arcfour-hmac:normal', 'des-hmac-sha1:normal', 'des-cbc- md5:normal'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes128-cts:normal', 'des3-hmac-sha1:normal', 'arcfour- hmac:normal', 'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc- crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMaxRenewableAge': ['604800']})] Discovery was successful! Realm: EXAMPLE.COM DNS Domain: example.com IPA Server: services.example.com BaseDN: dc=example.com Continue to configure the system with these values? [no]: y Principal: admin Password for admin at EXAMPLE.COM: root : INFO args=/usr/kerberos/bin/kinit admin at EXAMPLE.COM root : INFO stdout=Password for admin at EXAMPLE.COM: root : INFO stderr= root : INFO args=/usr/sbin/ipa-join -s services.example.com -d root : INFO stdout= root : INFO stderr=cannot open configuration file /etc/ipa/default.conf XML-RPC CALL: \r\n \r\n join\r\n \r\n testclient.example.com\r\n \r\n nsosversion\r\n 2.6.32.11-99.fc12.i686.PAE\r\n nshardwareplatform\r\n i686\r\n \r\n \r\n \r\n XML-RPC RESPONSE: \n \n \n \n \n faultCode\n 3004\n \n \n faultString\n command 'join' takes at most 1 argument\n \n \n \n \n RPC failed at server. command 'join' takes at most 1 argument Joining realm failed: cannot open configuration file /etc/ipa/default.conf XML-RPC CALL: \r\n \r\n join\r\n \r\n testclient.example.com\r\n \r\n nsosversion\r\n 2.6.32.11-99.fc12.i686.PAE\r\n nshardwareplatform\r\n i686\r\n \r\n \r\n \r\n XML-RPC RESPONSE: \n \n \n \n \n faultCode\n 3004\n \n \n faultString\n command 'join' takes at most 1 argument\n \n \n \n \n RPC failed at server. command 'join' takes at most 1 argument root : INFO args=/usr/kerberos/bin/kdestroy root : INFO stdout= root : INFO stderr= -- Oliver Burtchen, Berlin From mnagy at redhat.com Mon Apr 19 13:16:06 2010 From: mnagy at redhat.com (Martin Nagy) Date: Mon, 19 Apr 2010 15:16:06 +0200 Subject: [Freeipa-users] Using already running dogtag-instance possible? In-Reply-To: <4BC86998.8020408@redhat.com> References: <201004092150.57003.o.burtchen@gmx.de> <201004100129.40874.o.burtchen@gmx.de> <4BC4B0BF.7070802@redhat.com> <201004160401.29488.o.burtchen@gmx.de> <4BC86998.8020408@redhat.com> Message-ID: <1271682966.7366.445.camel@wolverine.englab.brq.redhat.com> On Fri, 2010-04-16 at 09:43 -0400, Rob Crittenden wrote: > Oliver Burtchen wrote: > > Hi Dmitri, > > b) > > Using ?ipa-server-install --setup-dns?, the SOA Records in DNS are wrong. > > > > There are missing trailing dots for server-name und email, at reverse-zone > > also in the zone-name. To look at this, just use dig and dig -x on domain, > > changing it directly in ldap corrects it.. > > > > Should be easy to fix in ipaserver/install/bindinstance.py > > Martin, can you look into this? I filed > https://bugzilla.redhat.com/show_bug.cgi?id=583023 I just posted a patch, thanks for reporting this: https://www.redhat.com/archives/freeipa-devel/2010-April/msg00045.html > > d) > > Email for zone-manager in bind-setup should be asked/customizeable > > (root at domain.name is IMHO not a good choice). Maybe this option/answer should > > also be used as ?o=IPA,e=manager at domain.name? in base-subject for certificates, > > when ?subject is not set by user. > > We do something similar when installing dogtag. We set -admin_email to > root at localhost. > > I filed https://bugzilla.redhat.com/show_bug.cgi?id=583027 Not still sure about this one, it'd probably be a good idea, we'll see.. Martin From rcritten at redhat.com Mon Apr 19 13:30:24 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Apr 2010 09:30:24 -0400 Subject: [Freeipa-users] Unable to join a client In-Reply-To: <201004190441.51383.o.burtchen@gmx.de> References: <201004190441.51383.o.burtchen@gmx.de> Message-ID: <4BCC5AF0.8080408@redhat.com> Oliver Burtchen wrote: > Hi, > > using clean F12 installtion with all updates and ipa > 1.91-0.2010041617git671bb9c.fc12 on server and client: > > Currently I'm unable to join a client, debug of ipa-client-install attached. > Seems, there was a change in the protocol, and ipa-join gives to many > arguments.. > > Best regards, > Oli > > > > > [root at testclient ~]# ipa-client-install -d > root : DEBUG Loading Index file from '/var/lib/ipa- > client/sysrestore/sysrestore.index' > root : DEBUG [ipadnssearchldap(example.com)] > root : DEBUG [ipadnssearchkrb] > root : DEBUG [ipacheckldap] > root : DEBUG Init ldap with: ldap://services.example.com:389 > root : DEBUG Search rootdse > root : DEBUG Search for (info=*) in dc=example.com(base) > root : DEBUG Found: [('dc=example.com', {'objectClass': ['top', > 'domain', 'pilotObject', 'nisDomainObject', 'domainRelatedObject'], 'info': > ['IPA V2.0'], 'associatedDomain': ['example.com'], 'dc': ['example.com'], > 'nisDomain': ['example.com']})] > root : DEBUG Search for (objectClass=krbRealmContainer) in > dc=example.com(sub) > root : DEBUG Found: [('cn=EXAMPLE.COM,cn=kerberos,dc=example.com', > {'krbSubTrees': ['dc=example.com'], 'cn': ['EXAMPLE.COM'], > 'krbDefaultEncSaltTypes': ['aes256-cts:normal', 'aes128-cts:normal', 'des3- > hmac-sha1:normal', 'arcfour-hmac:normal', 'des-hmac-sha1:normal', 'des-cbc- > md5:normal'], 'objectClass': ['top', 'krbrealmcontainer', > 'krbticketpolicyaux'], 'krbSearchScope': ['2'], 'krbSupportedEncSaltTypes': > ['aes256-cts:normal', 'aes128-cts:normal', 'des3-hmac-sha1:normal', 'arcfour- > hmac:normal', 'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc- > crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': > ['86400'], 'krbMaxRenewableAge': ['604800']})] > Discovery was successful! > Realm: EXAMPLE.COM > DNS Domain: example.com > IPA Server: services.example.com > BaseDN: dc=example.com > > > Continue to configure the system with these values? [no]: y > Principal: admin > Password for admin at EXAMPLE.COM: root : INFO > args=/usr/kerberos/bin/kinit admin at EXAMPLE.COM > root : INFO stdout=Password for admin at EXAMPLE.COM: > > root : INFO stderr= > > root : INFO args=/usr/sbin/ipa-join -s services.example.com -d > root : INFO stdout= > root : INFO stderr=cannot open configuration file > /etc/ipa/default.conf > XML-RPC CALL: > > \r\n > \r\n > join\r\n > \r\n > testclient.example.com\r\n > \r\n > nsosversion\r\n > 2.6.32.11-99.fc12.i686.PAE\r\n > nshardwareplatform\r\n > i686\r\n > \r\n > \r\n > \r\n > > XML-RPC RESPONSE: > > \n > \n > \n > \n > \n > faultCode\n > 3004\n > \n > \n > faultString\n > command 'join' takes at most 1 argument\n > \n > \n > \n > \n > > RPC failed at server. command 'join' takes at most 1 argument > > Joining realm failed: cannot open configuration file /etc/ipa/default.conf > XML-RPC CALL: > > \r\n > \r\n > join\r\n > \r\n > testclient.example.com\r\n > \r\n > nsosversion\r\n > 2.6.32.11-99.fc12.i686.PAE\r\n > nshardwareplatform\r\n > i686\r\n > \r\n > \r\n > \r\n > > XML-RPC RESPONSE: > > \n > \n > \n > \n > \n > faultCode\n > 3004\n > \n > \n > faultString\n > command 'join' takes at most 1 argument\n > \n > \n > \n > \n > > RPC failed at server. command 'join' takes at most 1 argument > root : INFO args=/usr/kerberos/bin/kdestroy > root : INFO stdout= > root : INFO stderr= I have a fix for this awaiting peer review on freeipa-devel titled "Use the certificate subject base in IPA when requesting certs in certmonger." rob From afkkir at gmail.com Mon Apr 19 14:22:14 2010 From: afkkir at gmail.com (ALAHYANE Rachid) Date: Mon, 19 Apr 2010 16:22:14 +0200 Subject: [Freeipa-users] call implemented methods via xml-rpc Message-ID: Hi, Using F12 with the alpha version of ipa, I want to know if there is some ways to call implemented methods like user_show() with my own script python. My goal is to call these methods with a client xml-rpc that I will to developpe later. On my client, I tried this but it does not work :( ---------------------------------------------------------------------------- >>> from ipalib import api >>> api.bootstrap_with_global_options() (, []) >>> api.load_plugins() >>> api.finalize() >>> api.Method.user_show.__doc__ '\n Display user.\n ' >>> api.Method.user_show(u'raca') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 398, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 667, in run return self.forward(*args, **options) File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 688, in forward return self.Backend.xmlclient.forward(self.name, *args, **kw) File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 403, in forward command = getattr(self.conn, name) File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 96, in __get_conn self.id, threading.currentThread().getName()) AttributeError: no context.xmlclient in thread 'MainThread' ---------------------------------------------------------------------------- Have you any idea ? or some pertinent docs Sorry for my bad English :) -- Meilleures salutations / Best Regards Rachid ALAHYANE -------------- next part -------------- An HTML attachment was scrubbed... URL: From jderose at redhat.com Mon Apr 19 15:09:30 2010 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 19 Apr 2010 09:09:30 -0600 Subject: [Freeipa-users] call implemented methods via xml-rpc In-Reply-To: References: Message-ID: <1271689770.7607.8.camel@jgd-dsk> On Mon, 2010-04-19 at 16:22 +0200, ALAHYANE Rachid wrote: > Hi, > > > Using F12 with the alpha version of ipa, I want to know if there is > some ways to call implemented methods like user_show() with my own > script python. My goal is to call these methods with a client xml-rpc > that I will to developpe later. > > > On my client, I tried this but it does not work :( It needs more documentation, but see doc/examples/python-api.py Let me know if that doesn't work or if you get stuck. You will need to do a kinit first. > ---------------------------------------------------------------------------- > >>> from ipalib import api > >>> api.bootstrap_with_global_options() > ( 'verbose': None}>, []) > >>> api.load_plugins() > >>> api.finalize() > >>> api.Method.user_show.__doc__ > '\n Display user.\n ' > >>> api.Method.user_show(u'raca') > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line > 398, in __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line > 667, in run > return self.forward(*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line > 688, in forward > return self.Backend.xmlclient.forward(self.name, *args, **kw) > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 403, in > forward > command = getattr(self.conn, name) > File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 96, > in __get_conn > self.id, threading.currentThread().getName()) > AttributeError: no context.xmlclient in thread 'MainThread' > > > ---------------------------------------------------------------------------- > > > Have you any idea ? or some pertinent docs > > > Sorry for my bad English :) > > > -- > Meilleures salutations / Best Regards > > Rachid ALAHYANE > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From afkkir at gmail.com Mon Apr 19 15:27:32 2010 From: afkkir at gmail.com (ALAHYANE Rachid) Date: Mon, 19 Apr 2010 17:27:32 +0200 Subject: [Freeipa-users] call implemented methods via xml-rpc In-Reply-To: <1271689770.7607.8.camel@jgd-dsk> References: <1271689770.7607.8.camel@jgd-dsk> Message-ID: Thank you for your answer, it works ! 2010/4/19 Jason Gerard DeRose > On Mon, 2010-04-19 at 16:22 +0200, ALAHYANE Rachid wrote: > > Hi, > > > > > > Using F12 with the alpha version of ipa, I want to know if there is > > some ways to call implemented methods like user_show() with my own > > script python. My goal is to call these methods with a client xml-rpc > > that I will to developpe later. > > > > > > On my client, I tried this but it does not work :( > > It needs more documentation, but see doc/examples/python-api.py > > Let me know if that doesn't work or if you get stuck. You will need to > do a kinit first. > > > > ---------------------------------------------------------------------------- > > >>> from ipalib import api > > >>> api.bootstrap_with_global_options() > > ( > 'verbose': None}>, []) > > >>> api.load_plugins() > > >>> api.finalize() > > >>> api.Method.user_show.__doc__ > > '\n Display user.\n ' > > >>> api.Method.user_show(u'raca') > > Traceback (most recent call last): > > File "", line 1, in > > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line > > 398, in __call__ > > ret = self.run(*args, **options) > > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line > > 667, in run > > return self.forward(*args, **options) > > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line > > 688, in forward > > return self.Backend.xmlclient.forward(self.name, *args, **kw) > > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 403, in > > forward > > command = getattr(self.conn, name) > > File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 96, > > in __get_conn > > self.id, threading.currentThread().getName()) > > AttributeError: no context.xmlclient in thread 'MainThread' > > > > > > > ---------------------------------------------------------------------------- > > > > > > Have you any idea ? or some pertinent docs > > > > > > Sorry for my bad English :) > > > > > > -- > > Meilleures salutations / Best Regards > > > > Rachid ALAHYANE > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Meilleures salutations / Best Regards Rachid ALAHYANE -------------- next part -------------- An HTML attachment was scrubbed... URL: From o.burtchen at gmx.de Mon Apr 19 20:52:45 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Mon, 19 Apr 2010 22:52:45 +0200 Subject: [Freeipa-users] Unable to join a client In-Reply-To: <4BCC5AF0.8080408@redhat.com> References: <201004190441.51383.o.burtchen@gmx.de> <4BCC5AF0.8080408@redhat.com> Message-ID: <201004192252.46054.o.burtchen@gmx.de> Am Montag, 19. April 2010 15:30:24 schrieb Rob Crittenden: > Oliver Burtchen wrote: > > Hi, > > > > using clean F12 installtion with all updates and ipa > > 1.91-0.2010041617git671bb9c.fc12 on server and client: > > > > Currently I'm unable to join a client, debug of ipa-client-install > > attached. Seems, there was a change in the protocol, and ipa-join gives > > to many arguments.. > > I have a fix for this awaiting peer review on freeipa-devel titled "Use > the certificate subject base in IPA when requesting certs in certmonger." I tested the patch against 1.91-0.2010041914gitcc336cf. Found no problems and joining a client is working. Thanks! Best regards, Oli -- Oliver Burtchen, Berlin From afkkir at gmail.com Tue Apr 20 11:03:22 2010 From: afkkir at gmail.com (ALAHYANE Rachid) Date: Tue, 20 Apr 2010 13:03:22 +0200 Subject: [Freeipa-users] call implemented methods via xml-rpc In-Reply-To: References: <1271689770.7607.8.camel@jgd-dsk> Message-ID: Hi, Now I have another error. When I use the code of doc/examples/python-api.py inside my server XML-RPC (not the ipa server) that configured like this : == Server == --------- httpd conf ------------ ## python conf # .... SetHandler python-program PythonHandler xmlrpchandler PythonDebug on ------------------------------------ the handler xmlrpchandler calls the following method when the client requests for the remote method getUserInfos(). --------- account.py ------------ def getUserInfos(user_name, env=None): from ipalib import api api.bootstrap_with_global_options(context='webservices') api.finalize() api.Backend.xmlclient.connect() return api.Command.user_show(user_name) ------------------------------------ == Client == Now when I call this method from my client, I get this exception : ------------------------------------ : API.bootstrap() already called"> ------------------------------------ I don't know why it does not work, any ideas ?? Thanks, 2010/4/19 ALAHYANE Rachid > Thank you for your answer, it works ! > > 2010/4/19 Jason Gerard DeRose > > On Mon, 2010-04-19 at 16:22 +0200, ALAHYANE Rachid wrote: >> > Hi, >> > >> > >> > Using F12 with the alpha version of ipa, I want to know if there is >> > some ways to call implemented methods like user_show() with my own >> > script python. My goal is to call these methods with a client xml-rpc >> > that I will to developpe later. >> > >> > >> > On my client, I tried this but it does not work :( >> >> It needs more documentation, but see doc/examples/python-api.py >> >> Let me know if that doesn't work or if you get stuck. You will need to >> do a kinit first. >> >> > >> ---------------------------------------------------------------------------- >> > >>> from ipalib import api >> > >>> api.bootstrap_with_global_options() >> > (> > 'verbose': None}>, []) >> > >>> api.load_plugins() >> > >>> api.finalize() >> > >>> api.Method.user_show.__doc__ >> > '\n Display user.\n ' >> > >>> api.Method.user_show(u'raca') >> > Traceback (most recent call last): >> > File "", line 1, in >> > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line >> > 398, in __call__ >> > ret = self.run(*args, **options) >> > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line >> > 667, in run >> > return self.forward(*args, **options) >> > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line >> > 688, in forward >> > return self.Backend.xmlclient.forward(self.name, *args, **kw) >> > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 403, in >> > forward >> > command = getattr(self.conn, name) >> > File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 96, >> > in __get_conn >> > self.id, threading.currentThread().getName()) >> > AttributeError: no context.xmlclient in thread 'MainThread' >> > >> > >> > >> ---------------------------------------------------------------------------- >> > >> > >> > Have you any idea ? or some pertinent docs >> > >> > >> > Sorry for my bad English :) >> > >> > >> > -- >> > Meilleures salutations / Best Regards >> > >> > Rachid ALAHYANE >> > >> > >> > _______________________________________________ >> > Freeipa-users mailing list >> > Freeipa-users at redhat.com >> > https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > > -- > Meilleures salutations / Best Regards > > Rachid ALAHYANE > > -- Meilleures salutations / Best Regards Rachid ALAHYANE -------------- next part -------------- An HTML attachment was scrubbed... URL: From jderose at redhat.com Tue Apr 20 12:49:24 2010 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 20 Apr 2010 06:49:24 -0600 Subject: [Freeipa-users] call implemented methods via xml-rpc In-Reply-To: References: <1271689770.7607.8.camel@jgd-dsk> Message-ID: <1271767764.27603.49.camel@jgd-dsk> On Tue, 2010-04-20 at 13:03 +0200, ALAHYANE Rachid wrote: > Hi, > > > Now I have another error. When I use the code > of doc/examples/python-api.py inside my server XML-RPC (not the ipa > server) that configured like this : > > > == Server == > --------- httpd conf ------------ > > ## python conf > > > # .... > SetHandler python-program > PythonHandler xmlrpchandler > PythonDebug on > > ------------------------------------ > > > the handler xmlrpchandler calls the following method when the client > requests for the remote method getUserInfos(). > > > --------- account.py ------------ > def getUserInfos(user_name, env=None): > > > from ipalib import api > > > api.bootstrap_with_global_options(context='webservices') > api.finalize() > api.Backend.xmlclient.connect() > return api.Command.user_show(user_name) > ------------------------------------ > > > > > == Client == > Now when I call this method from my client, I get this exception : > > > ------------------------------------ > : > API.bootstrap() already called"> > ------------------------------------ > > > I don't know why it does not work, any ideas ?? > Initializing ipalib is a somewhat expensive operation, so we only initialize it once when the process starts. If you're implementing a new XML-RPC server that calls ipalib, you will need to slightly modify the code in the python-api.py example, which I'll explain. ipalib has 2 modes of operation: client and server. In client mode, only plugins in ipalib/plugins/ are loaded. In server mode, plugins in ipaserver/plugins/ are also loaded. In a nutshell, client mode will do some sanity checks and the forward the call to the server. In server mode, the same sanity checks are performed, and then the command is executed, which usually means creating/modifying LDAP entries. So assuming you want to initialize ipalib in server mode (sounds like you do), you will need to do something like this (when the process starts): from ipalib import api api.bootstrap(context='example', in_server=True) api.finalize() Note the `in_server=True` that I added. Then in your handler, you will need to create a context for the request, something like this: def getUserInfos(user_name, env=None): # Where are you getting Kerberos credentials? api.Backend.ldap2.connect( ccache=api.Backend.krb.default_ccname() ) return api.Command.user_show(user_name) So the recipe is 1) initialize ipalib once at startup, and 2) create a context (LDAP connection) at each request. To see how we do this is our RPC server, look at the ipaserver/rpcserver.py file. Hope that helps. I'm glad to see someone wanting to use the Python API. ;) > Thanks, > > > 2010/4/19 ALAHYANE Rachid > Thank you for your answer, it works ! > > 2010/4/19 Jason Gerard DeRose > > > On Mon, 2010-04-19 at 16:22 +0200, ALAHYANE Rachid > wrote: > > Hi, > > > > > > Using F12 with the alpha version of ipa, I want to > know if there is > > some ways to call implemented methods like > user_show() with my own > > script python. My goal is to call these methods with > a client xml-rpc > > that I will to developpe later. > > > > > > On my client, I tried this but it does not work :( > > > It needs more documentation, but see > doc/examples/python-api.py > > Let me know if that doesn't work or if you get stuck. > You will need to > do a kinit first. > > > > > ---------------------------------------------------------------------------- > > >>> from ipalib import api > > >>> api.bootstrap_with_global_options() > > ( None, 'env': None, > > 'verbose': None}>, []) > > >>> api.load_plugins() > > >>> api.finalize() > > >>> api.Method.user_show.__doc__ > > '\n Display user.\n ' > > >>> api.Method.user_show(u'raca') > > Traceback (most recent call last): > > File "", line 1, in > > File > "/usr/lib/python2.6/site-packages/ipalib/frontend.py", > line > > 398, in __call__ > > ret = self.run(*args, **options) > > File > "/usr/lib/python2.6/site-packages/ipalib/frontend.py", > line > > 667, in run > > return self.forward(*args, **options) > > File > "/usr/lib/python2.6/site-packages/ipalib/frontend.py", > line > > 688, in forward > > return self.Backend.xmlclient.forward(self.name, > *args, **kw) > > File > "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line > 403, in > > forward > > command = getattr(self.conn, name) > > File > "/usr/lib/python2.6/site-packages/ipalib/backend.py", > line 96, > > in __get_conn > > self.id, threading.currentThread().getName()) > > AttributeError: no context.xmlclient in thread > 'MainThread' > > > > > > > ---------------------------------------------------------------------------- > > > > > > Have you any idea ? or some pertinent docs > > > > > > Sorry for my bad English :) > > > > > > -- > > Meilleures salutations / Best Regards > > > > Rachid ALAHYANE > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- > Meilleures salutations / Best Regards > > Rachid ALAHYANE > > > > > > -- > Meilleures salutations / Best Regards > > Rachid ALAHYANE > > From afkkir at gmail.com Tue Apr 20 15:25:21 2010 From: afkkir at gmail.com (ALAHYANE Rachid) Date: Tue, 20 Apr 2010 17:25:21 +0200 Subject: [Freeipa-users] call implemented methods via xml-rpc In-Reply-To: <1271767764.27603.49.camel@jgd-dsk> References: <1271689770.7607.8.camel@jgd-dsk> <1271767764.27603.49.camel@jgd-dsk> Message-ID: Thanks for your answer, but I think that I don't explained my problem very clearly. Lets take this simple situation. I have two hosts: my client with apache+mod_python and my ipa server. This is the apache configuration on client : --------------------------------------------------------- ## python conf PythonPath "['/usr/lib/python2.6/site-packages/webservices']+sys.path" SetHandler python-program PythonHandler my_script PythonDebug on --------------------------------------------------------- and this the code of `my_script` --------------------------------------------------------- from mod_python import apache def handler(req): req.content_type = "text/plain" req.send_http_header() from ipalib import api # I am on the client host => mode server is False # I also tested this with api.bootstrap(context='example', in_server=False) but it doesn't work too api.bootstrap_with_global_options(context='example') api.finalize() api.Backend.xmlclient.connect() res = api.Command.user_show(user_name) req.write(str(res)) return apache.OK --------------------------------------------------------- when I access to client.domain.org/test on my browser I get this error : --------------------------------------------------------- MOD_PYTHON ERROR ProcessId: 12393 Interpreter: 'client.domain.org' ServerName: 'client.domain.org' DocumentRoot: '/var/www/html' URI: '/test' Location: None Directory: None Filename: '/var/www/html/test' PathInfo: '' Phase: 'PythonHandler' Handler: 'my_script' Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/mod_python/importer.py", line 1537, in HandlerDispatch default=default_handler, arg=req, silent=hlist.silent) File "/usr/lib/python2.6/site-packages/mod_python/importer.py", line 1229, in _process_target result = _execute_target(config, req, object, arg) File "/usr/lib/python2.6/site-packages/mod_python/importer.py", line 1128, in _execute_target result = object(arg) File "/usr/lib/python2.6/site-packages/webservices/my_script.py", line 7, in handler api.bootstrap(context='example', in_server=False) File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 380, in bootstrap self.__doing('bootstrap') File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 365, in __doing '%s.%s() already called' % (self.__class__.__name__, name) StandardError: API.bootstrap() already called --------------------------------------------------------- I don't know where API.bootstrap() was called. Thanks, 2010/4/20 Jason Gerard DeRose > On Tue, 2010-04-20 at 13:03 +0200, ALAHYANE Rachid wrote: > > Hi, > > > > > > Now I have another error. When I use the code > > of doc/examples/python-api.py inside my server XML-RPC (not the ipa > > server) that configured like this : > > > > > > == Server == > > --------- httpd conf ------------ > > > > ## python conf > > > > > > # .... > > SetHandler python-program > > PythonHandler xmlrpchandler > > PythonDebug on > > > > ------------------------------------ > > > > > > the handler xmlrpchandler calls the following method when the client > > requests for the remote method getUserInfos(). > > > > > > --------- account.py ------------ > > def getUserInfos(user_name, env=None): > > > > > > from ipalib import api > > > > > > api.bootstrap_with_global_options(context='webservices') > > api.finalize() > > api.Backend.xmlclient.connect() > > return api.Command.user_show(user_name) > > ------------------------------------ > > > > > > > > > > == Client == > > Now when I call this method from my client, I get this exception : > > > > > > ------------------------------------ > > : > > API.bootstrap() already called"> > > ------------------------------------ > > > > > > I don't know why it does not work, any ideas ?? > > > > Initializing ipalib is a somewhat expensive operation, so we only > initialize it once when the process starts. If you're implementing a > new XML-RPC server that calls ipalib, you will need to slightly modify > the code in the python-api.py example, which I'll explain. > > ipalib has 2 modes of operation: client and server. In client mode, > only plugins in ipalib/plugins/ are loaded. In server mode, plugins in > ipaserver/plugins/ are also loaded. > > In a nutshell, client mode will do some sanity checks and the forward > the call to the server. In server mode, the same sanity checks are > performed, and then the command is executed, which usually means > creating/modifying LDAP entries. > > So assuming you want to initialize ipalib in server mode (sounds like > you do), you will need to do something like this (when the process > starts): > > from ipalib import api > api.bootstrap(context='example', in_server=True) > api.finalize() > > Note the `in_server=True` that I added. Then in your handler, you will > need to create a context for the request, something like this: > > def getUserInfos(user_name, env=None): > # Where are you getting Kerberos credentials? > api.Backend.ldap2.connect( > ccache=api.Backend.krb.default_ccname() > ) > return api.Command.user_show(user_name) > > So the recipe is 1) initialize ipalib once at startup, and 2) create a > context (LDAP connection) at each request. To see how we do this is our > RPC server, look at the ipaserver/rpcserver.py file. > > Hope that helps. I'm glad to see someone wanting to use the Python > API. ;) > > > Thanks, > > > > > > 2010/4/19 ALAHYANE Rachid > > Thank you for your answer, it works ! > > > > 2010/4/19 Jason Gerard DeRose > > > > > > On Mon, 2010-04-19 at 16:22 +0200, ALAHYANE Rachid > > wrote: > > > Hi, > > > > > > > > > Using F12 with the alpha version of ipa, I want to > > know if there is > > > some ways to call implemented methods like > > user_show() with my own > > > script python. My goal is to call these methods with > > a client xml-rpc > > > that I will to developpe later. > > > > > > > > > On my client, I tried this but it does not work :( > > > > > > It needs more documentation, but see > > doc/examples/python-api.py > > > > Let me know if that doesn't work or if you get stuck. > > You will need to > > do a kinit first. > > > > > > > > > > ---------------------------------------------------------------------------- > > > >>> from ipalib import api > > > >>> api.bootstrap_with_global_options() > > > ( > None, 'env': None, > > > 'verbose': None}>, []) > > > >>> api.load_plugins() > > > >>> api.finalize() > > > >>> api.Method.user_show.__doc__ > > > '\n Display user.\n ' > > > >>> api.Method.user_show(u'raca') > > > Traceback (most recent call last): > > > File "", line 1, in > > > File > > "/usr/lib/python2.6/site-packages/ipalib/frontend.py", > > line > > > 398, in __call__ > > > ret = self.run(*args, **options) > > > File > > "/usr/lib/python2.6/site-packages/ipalib/frontend.py", > > line > > > 667, in run > > > return self.forward(*args, **options) > > > File > > "/usr/lib/python2.6/site-packages/ipalib/frontend.py", > > line > > > 688, in forward > > > return self.Backend.xmlclient.forward(self.name, > > *args, **kw) > > > File > > "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line > > 403, in > > > forward > > > command = getattr(self.conn, name) > > > File > > "/usr/lib/python2.6/site-packages/ipalib/backend.py", > > line 96, > > > in __get_conn > > > self.id, threading.currentThread().getName()) > > > AttributeError: no context.xmlclient in thread > > 'MainThread' > > > > > > > > > > > > ---------------------------------------------------------------------------- > > > > > > > > > Have you any idea ? or some pertinent docs > > > > > > > > > Sorry for my bad English :) > > > > > > > > > -- > > > Meilleures salutations / Best Regards > > > > > > Rachid ALAHYANE > > > > > > > > > > > _______________________________________________ > > > Freeipa-users mailing list > > > Freeipa-users at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > > > > > > > -- > > Meilleures salutations / Best Regards > > > > Rachid ALAHYANE > > > > > > > > > > > > -- > > Meilleures salutations / Best Regards > > > > Rachid ALAHYANE > > > > > > -- Meilleures salutations / Best Regards Rachid ALAHYANE -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ng23.net Tue Apr 20 15:27:52 2010 From: tom at ng23.net (Tom Brown) Date: Tue, 20 Apr 2010 16:27:52 +0100 Subject: [Freeipa-users] IPA roadmap Message-ID: Can i ask what the future of (free-)IPA is please - I am very keen to get it in the door here and i thought that it was being actively but i have heard that there are no full time developers working on this at RH. Is this a product thats going to go away or is it something that is worth us investing our time in ? thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Tue Apr 20 15:40:20 2010 From: jdennis at redhat.com (John Dennis) Date: Tue, 20 Apr 2010 11:40:20 -0400 Subject: [Freeipa-users] IPA roadmap In-Reply-To: References: Message-ID: <4BCDCAE4.2080706@redhat.com> On 04/20/2010 11:27 AM, Tom Brown wrote: > Can i ask what the future of (free-)IPA is please - I am very keen to > get it in the door here and i thought that it was being actively but i > have heard that there are no full time developers working on this at RH. > Is this a product thats going to go away or is it something that is > worth us investing our time in ? As Mark Twain said ""The reports of my death are greatly exaggerated". Any assertion that IPA is dead, dying, or in ill health are completely fallacious. We have about half a dozen RH developers working full time on IPA. We are currently working on version 2.0 of FreeIPA and we've been releasing test releases. IPA 2.0 is due to ship in RHEL 6.1. We are alive, well, and very much kicking :-) -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From brad.lodgen at centurytel.net Tue Apr 20 17:01:50 2010 From: brad.lodgen at centurytel.net (Brad Lodgen) Date: Tue, 20 Apr 2010 12:01:50 -0500 Subject: [Freeipa-users] Apache Error Immediately After Install Message-ID: <0c8e01cae0ab$2c4f89c0$84ee9d40$@lodgen@centurytel.net> I have a fresh install. All I've done is kinit admin and added a single user. I browse to my ipa web server, log in, then get a blank page in IE and in Firefox I get the page at /usr/share/ipa/html/unauthorized.html. I checked the source code for the IE page and it's actually taking me to the same page, just not showing any text. I changed to compatibility mode, same thing. I did all the recommended changes in Firefox, but have the same result. This is in the Apache error log [Tue Apr 20 11:48:54 2010] [error] [client X.X.X.X] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error) I tried logging in as admin and as a user I added. No luck. Any ideas for things to try? Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Apr 20 17:25:58 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Apr 2010 13:25:58 -0400 Subject: [Freeipa-users] Apache Error Immediately After Install In-Reply-To: <0c8e01cae0ab$2c4f89c0$84ee9d40$@lodgen@centurytel.net> References: <0c8e01cae0ab$2c4f89c0$84ee9d40$@lodgen@centurytel.net> Message-ID: <4BCDE3A6.5040102@redhat.com> Brad Lodgen wrote: > I have a fresh install. All I?ve done is kinit admin and added a single > user. > > > > I browse to my ipa web server, log in, then get a blank page in IE and > in Firefox I get the page at /usr/share/ipa/html/unauthorized.html. I > checked the source code for the IE page and it?s actually taking me to > the same page, just not showing any text. I changed to compatibility > mode, same thing. I did all the recommended changes in Firefox, but have > the same result. > > > > This is in the Apache error log > > > > [Tue Apr 20 11:48:54 2010] [error] [client X.X.X.X] > gss_accept_sec_context() failed: An unsupported mechanism was requested > (, Unknown error) > > > > I tried logging in as admin and as a user I added. No luck. > > > > Any ideas for things to try? What OS are you running Firefox from? The underlying problem is that you need to do kerberos authentication from within the browser. This is possible in Windows if you install the MIT kerberos client software. For it to work natively in Windows you'd have to get a ticket as part of a domain login which we don't support (and probably won't for a while). rob From afkkir at gmail.com Wed Apr 21 10:43:01 2010 From: afkkir at gmail.com (ALAHYANE Rachid) Date: Wed, 21 Apr 2010 12:43:01 +0200 Subject: [Freeipa-users] call implemented methods via xml-rpc In-Reply-To: References: <1271689770.7607.8.camel@jgd-dsk> <1271767764.27603.49.camel@jgd-dsk> Message-ID: Any ideas ? I can provide further explanations if it is not clear ;) Sorry for this mail bombing. 2010/4/20 ALAHYANE Rachid > Thanks for your answer, but I think that I don't explained my problem very > clearly. Lets take this simple situation. I have two hosts: my client with > apache+mod_python and my ipa server. > > This is the apache configuration on client : > > --------------------------------------------------------- > > ## python conf > > > PythonPath "['/usr/lib/python2.6/site-packages/webservices']+sys.path" > SetHandler python-program > PythonHandler my_script > PythonDebug on > > --------------------------------------------------------- > > and this the code of `my_script` > > --------------------------------------------------------- > from mod_python import apache > > def handler(req): > req.content_type = "text/plain" > req.send_http_header() > from ipalib import api > # I am on the client host => mode server is False > # I also tested this with api.bootstrap(context='example', > in_server=False) but it doesn't work too > api.bootstrap_with_global_options(context='example') > api.finalize() > api.Backend.xmlclient.connect() > res = api.Command.user_show(user_name) > req.write(str(res)) > > return apache.OK > --------------------------------------------------------- > > when I access to client.domain.org/test on my browser I get this error : > > --------------------------------------------------------- > MOD_PYTHON ERROR > > ProcessId: 12393 > Interpreter: 'client.domain.org' > > ServerName: 'client.domain.org' > DocumentRoot: '/var/www/html' > > URI: '/test' > Location: None > Directory: None > Filename: '/var/www/html/test' > PathInfo: '' > > Phase: 'PythonHandler' > Handler: 'my_script' > > Traceback (most recent call last): > > File "/usr/lib/python2.6/site-packages/mod_python/importer.py", line > 1537, in HandlerDispatch > default=default_handler, arg=req, silent=hlist.silent) > > File "/usr/lib/python2.6/site-packages/mod_python/importer.py", line > 1229, in _process_target > result = _execute_target(config, req, object, arg) > > File "/usr/lib/python2.6/site-packages/mod_python/importer.py", line > 1128, in _execute_target > result = object(arg) > > File "/usr/lib/python2.6/site-packages/webservices/my_script.py", line 7, > in handler > api.bootstrap(context='example', in_server=False) > > File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 380, in > bootstrap > self.__doing('bootstrap') > > File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 365, in > __doing > '%s.%s() already called' % (self.__class__.__name__, name) > > StandardError: API.bootstrap() already called > --------------------------------------------------------- > > I don't know where API.bootstrap() was called. > > Thanks, > > 2010/4/20 Jason Gerard DeRose > > On Tue, 2010-04-20 at 13:03 +0200, ALAHYANE Rachid wrote: >> > Hi, >> > >> > >> > Now I have another error. When I use the code >> > of doc/examples/python-api.py inside my server XML-RPC (not the ipa >> > server) that configured like this : >> > >> > >> > == Server == >> > --------- httpd conf ------------ >> > >> > ## python conf >> > >> > >> > # .... >> > SetHandler python-program >> > PythonHandler xmlrpchandler >> > PythonDebug on >> > >> > ------------------------------------ >> > >> > >> > the handler xmlrpchandler calls the following method when the client >> > requests for the remote method getUserInfos(). >> > >> > >> > --------- account.py ------------ >> > def getUserInfos(user_name, env=None): >> > >> > >> > from ipalib import api >> > >> > >> > api.bootstrap_with_global_options(context='webservices') >> > api.finalize() >> > api.Backend.xmlclient.connect() >> > return api.Command.user_show(user_name) >> > ------------------------------------ >> > >> > >> > >> > >> > == Client == >> > Now when I call this method from my client, I get this exception : >> > >> > >> > ------------------------------------ >> > : >> > API.bootstrap() already called"> >> > ------------------------------------ >> > >> > >> > I don't know why it does not work, any ideas ?? >> > >> >> Initializing ipalib is a somewhat expensive operation, so we only >> initialize it once when the process starts. If you're implementing a >> new XML-RPC server that calls ipalib, you will need to slightly modify >> the code in the python-api.py example, which I'll explain. >> >> ipalib has 2 modes of operation: client and server. In client mode, >> only plugins in ipalib/plugins/ are loaded. In server mode, plugins in >> ipaserver/plugins/ are also loaded. >> >> In a nutshell, client mode will do some sanity checks and the forward >> the call to the server. In server mode, the same sanity checks are >> performed, and then the command is executed, which usually means >> creating/modifying LDAP entries. >> >> So assuming you want to initialize ipalib in server mode (sounds like >> you do), you will need to do something like this (when the process >> starts): >> >> from ipalib import api >> api.bootstrap(context='example', in_server=True) >> api.finalize() >> >> Note the `in_server=True` that I added. Then in your handler, you will >> need to create a context for the request, something like this: >> >> def getUserInfos(user_name, env=None): >> # Where are you getting Kerberos credentials? >> api.Backend.ldap2.connect( >> ccache=api.Backend.krb.default_ccname() >> ) >> return api.Command.user_show(user_name) >> >> So the recipe is 1) initialize ipalib once at startup, and 2) create a >> context (LDAP connection) at each request. To see how we do this is our >> RPC server, look at the ipaserver/rpcserver.py file. >> >> Hope that helps. I'm glad to see someone wanting to use the Python >> API. ;) >> >> > Thanks, >> > >> > >> > 2010/4/19 ALAHYANE Rachid >> > Thank you for your answer, it works ! >> > >> > 2010/4/19 Jason Gerard DeRose >> > >> > >> > On Mon, 2010-04-19 at 16:22 +0200, ALAHYANE Rachid >> > wrote: >> > > Hi, >> > > >> > > >> > > Using F12 with the alpha version of ipa, I want to >> > know if there is >> > > some ways to call implemented methods like >> > user_show() with my own >> > > script python. My goal is to call these methods with >> > a client xml-rpc >> > > that I will to developpe later. >> > > >> > > >> > > On my client, I tried this but it does not work :( >> > >> > >> > It needs more documentation, but see >> > doc/examples/python-api.py >> > >> > Let me know if that doesn't work or if you get stuck. >> > You will need to >> > do a kinit first. >> > >> > >> > > >> > >> ---------------------------------------------------------------------------- >> > > >>> from ipalib import api >> > > >>> api.bootstrap_with_global_options() >> > > (> > None, 'env': None, >> > > 'verbose': None}>, []) >> > > >>> api.load_plugins() >> > > >>> api.finalize() >> > > >>> api.Method.user_show.__doc__ >> > > '\n Display user.\n ' >> > > >>> api.Method.user_show(u'raca') >> > > Traceback (most recent call last): >> > > File "", line 1, in >> > > File >> > "/usr/lib/python2.6/site-packages/ipalib/frontend.py", >> > line >> > > 398, in __call__ >> > > ret = self.run(*args, **options) >> > > File >> > "/usr/lib/python2.6/site-packages/ipalib/frontend.py", >> > line >> > > 667, in run >> > > return self.forward(*args, **options) >> > > File >> > "/usr/lib/python2.6/site-packages/ipalib/frontend.py", >> > line >> > > 688, in forward >> > > return self.Backend.xmlclient.forward(self.name, >> > *args, **kw) >> > > File >> > "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line >> > 403, in >> > > forward >> > > command = getattr(self.conn, name) >> > > File >> > "/usr/lib/python2.6/site-packages/ipalib/backend.py", >> > line 96, >> > > in __get_conn >> > > self.id, threading.currentThread().getName()) >> > > AttributeError: no context.xmlclient in thread >> > 'MainThread' >> > > >> > > >> > > >> > >> ---------------------------------------------------------------------------- >> > > >> > > >> > > Have you any idea ? or some pertinent docs >> > > >> > > >> > > Sorry for my bad English :) >> > > >> > > >> > > -- >> > > Meilleures salutations / Best Regards >> > > >> > > Rachid ALAHYANE >> > > >> > > >> > >> > > _______________________________________________ >> > > Freeipa-users mailing list >> > > Freeipa-users at redhat.com >> > > >> > https://www.redhat.com/mailman/listinfo/freeipa-users >> > >> > >> > >> > >> > >> > -- >> > Meilleures salutations / Best Regards >> > >> > Rachid ALAHYANE >> > >> > >> > >> > >> > >> > -- >> > Meilleures salutations / Best Regards >> > >> > Rachid ALAHYANE >> > >> > >> >> > > > -- > Meilleures salutations / Best Regards > > Rachid ALAHYANE > > -- Meilleures salutations / Best Regards Rachid ALAHYANE -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Apr 21 15:08:35 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 21 Apr 2010 11:08:35 -0400 Subject: [Freeipa-users] call implemented methods via xml-rpc In-Reply-To: References: <1271689770.7607.8.camel@jgd-dsk> <1271767764.27603.49.camel@jgd-dsk> Message-ID: <4BCF14F3.6020606@redhat.com> ALAHYANE Rachid wrote: > Any ideas ? I can provide further explanations if it is not clear ;) I think that will be needed. You are doing server->server communication if you are running within Apache. It would be helpful if you would describe what your end goal is. rob > > Sorry for this mail bombing. > > 2010/4/20 ALAHYANE Rachid > > > Thanks for your answer, but I think that I don't explained my > problem very clearly. Lets take this simple situation. I have two > hosts: my client with apache+mod_python and my ipa server. > > This is the apache configuration on client : > > --------------------------------------------------------- > > ## python conf > > > PythonPath "['/usr/lib/python2.6/site-packages/webservices']+sys.path" > SetHandler python-program > PythonHandler my_script > PythonDebug on > > --------------------------------------------------------- > > and this the code of `my_script` > > --------------------------------------------------------- > from mod_python import apache > > def handler(req): > req.content_type = "text/plain" > req.send_http_header() > from ipalib import api > # I am on the client host => mode server is False > # I also tested this with api.bootstrap(context='example', > in_server=False) but it doesn't work too > api.bootstrap_with_global_options(context='example') > api.finalize() > api.Backend.xmlclient.connect() > res = api.Command.user_show(user_name) > req.write(str(res)) > > return apache.OK > --------------------------------------------------------- > > when I access to client.domain.org/test > on my browser I get this error : > > --------------------------------------------------------- > MOD_PYTHON ERROR > > ProcessId: 12393 > Interpreter: 'client.domain.org ' > > ServerName: 'client.domain.org ' > DocumentRoot: '/var/www/html' > > URI: '/test' > Location: None > Directory: None > Filename: '/var/www/html/test' > PathInfo: '' > > Phase: 'PythonHandler' > Handler: 'my_script' > > Traceback (most recent call last): > > File "/usr/lib/python2.6/site-packages/mod_python/importer.py", > line 1537, in HandlerDispatch > default=default_handler, arg=req, silent=hlist.silent) > > File "/usr/lib/python2.6/site-packages/mod_python/importer.py", > line 1229, in _process_target > result = _execute_target(config, req, object, arg) > > File "/usr/lib/python2.6/site-packages/mod_python/importer.py", > line 1128, in _execute_target > result = object(arg) > > File "/usr/lib/python2.6/site-packages/webservices/my_script.py", > line 7, in handler > api.bootstrap(context='example', in_server=False) > > File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line > 380, in bootstrap > self.__doing('bootstrap') > > File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line > 365, in __doing > '%s.%s() already called' % (self.__class__.__name__, name) > > StandardError: API.bootstrap() already called > --------------------------------------------------------- > > I don't know where API.bootstrap() was called. > > Thanks, > > 2010/4/20 Jason Gerard DeRose > > > On Tue, 2010-04-20 at 13:03 +0200, ALAHYANE Rachid wrote: > > Hi, > > > > > > Now I have another error. When I use the code > > of doc/examples/python-api.py inside my server XML-RPC (not > the ipa > > server) that configured like this : > > > > > > == Server == > > --------- httpd conf ------------ > > > > ## python conf > > > > > > # .... > > SetHandler python-program > > PythonHandler xmlrpchandler > > PythonDebug on > > > > ------------------------------------ > > > > > > the handler xmlrpchandler calls the following method when the > client > > requests for the remote method getUserInfos(). > > > > > > --------- account.py ------------ > > def getUserInfos(user_name, env=None): > > > > > > from ipalib import api > > > > > > api.bootstrap_with_global_options(context='webservices') > > api.finalize() > > api.Backend.xmlclient.connect() > > return api.Command.user_show(user_name) > > ------------------------------------ > > > > > > > > > > == Client == > > Now when I call this method from my client, I get this > exception : > > > > > > ------------------------------------ > > 'exceptions.StandardError'>: > > API.bootstrap() already called"> > > ------------------------------------ > > > > > > I don't know why it does not work, any ideas ?? > > > > Initializing ipalib is a somewhat expensive operation, so we only > initialize it once when the process starts. If you're > implementing a > new XML-RPC server that calls ipalib, you will need to slightly > modify > the code in the python-api.py example, which I'll explain. > > ipalib has 2 modes of operation: client and server. In client mode, > only plugins in ipalib/plugins/ are loaded. In server mode, > plugins in > ipaserver/plugins/ are also loaded. > > In a nutshell, client mode will do some sanity checks and the > forward > the call to the server. In server mode, the same sanity checks are > performed, and then the command is executed, which usually means > creating/modifying LDAP entries. > > So assuming you want to initialize ipalib in server mode (sounds > like > you do), you will need to do something like this (when the process > starts): > > from ipalib import api > api.bootstrap(context='example', in_server=True) > api.finalize() > > Note the `in_server=True` that I added. Then in your handler, > you will > need to create a context for the request, something like this: > > def getUserInfos(user_name, env=None): > # Where are you getting Kerberos credentials? > api.Backend.ldap2.connect( > ccache=api.Backend.krb.default_ccname() > ) > return api.Command.user_show(user_name) > > So the recipe is 1) initialize ipalib once at startup, and 2) > create a > context (LDAP connection) at each request. To see how we do > this is our > RPC server, look at the ipaserver/rpcserver.py file. > > Hope that helps. I'm glad to see someone wanting to use the Python > API. ;) > > > Thanks, > > > > > > 2010/4/19 ALAHYANE Rachid > > > Thank you for your answer, it works ! > > > > 2010/4/19 Jason Gerard DeRose > > > > > > > On Mon, 2010-04-19 at 16:22 +0200, ALAHYANE > Rachid > > wrote: > > > Hi, > > > > > > > > > Using F12 with the alpha version of ipa, I > want to > > know if there is > > > some ways to call implemented methods like > > user_show() with my own > > > script python. My goal is to call these > methods with > > a client xml-rpc > > > that I will to developpe later. > > > > > > > > > On my client, I tried this but it does not > work :( > > > > > > It needs more documentation, but see > > doc/examples/python-api.py > > > > Let me know if that doesn't work or if you > get stuck. > > You will need to > > do a kinit first. > > > > > > > > > > ---------------------------------------------------------------------------- > > > >>> from ipalib import api > > > >>> api.bootstrap_with_global_options() > > > ( > None, 'env': None, > > > 'verbose': None}>, []) > > > >>> api.load_plugins() > > > >>> api.finalize() > > > >>> api.Method.user_show.__doc__ > > > '\n Display user.\n ' > > > >>> api.Method.user_show(u'raca') > > > Traceback (most recent call last): > > > File "", line 1, in > > > File > > > "/usr/lib/python2.6/site-packages/ipalib/frontend.py", > > line > > > 398, in __call__ > > > ret = self.run(*args, **options) > > > File > > > "/usr/lib/python2.6/site-packages/ipalib/frontend.py", > > line > > > 667, in run > > > return self.forward(*args, **options) > > > File > > > "/usr/lib/python2.6/site-packages/ipalib/frontend.py", > > line > > > 688, in forward > > > return > self.Backend.xmlclient.forward(self.name , > > *args, **kw) > > > File > > > "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line > > 403, in > > > forward > > > command = getattr(self.conn, name) > > > File > > > "/usr/lib/python2.6/site-packages/ipalib/backend.py", > > line 96, > > > in __get_conn > > > self.id , > threading.currentThread().getName()) > > > AttributeError: no context.xmlclient in thread > > 'MainThread' > > > > > > > > > > > > ---------------------------------------------------------------------------- > > > > > > > > > Have you any idea ? or some pertinent docs > > > > > > > > > Sorry for my bad English :) > > > > > > > > > -- > > > Meilleures salutations / Best Regards > > > > > > Rachid ALAHYANE > > > > > > > > > > > _______________________________________________ > > > Freeipa-users mailing list > > > Freeipa-users at redhat.com > > > > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > > > > > > > -- > > Meilleures salutations / Best Regards > > > > Rachid ALAHYANE > > > > > > > > > > > > -- > > Meilleures salutations / Best Regards > > > > Rachid ALAHYANE > > > > > > > > > -- > Meilleures salutations / Best Regards > > Rachid ALAHYANE > > > > > -- > Meilleures salutations / Best Regards > > Rachid ALAHYANE > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From o.burtchen at gmx.de Wed Apr 21 17:34:53 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Wed, 21 Apr 2010 19:34:53 +0200 Subject: [Freeipa-users] Is sssd currently useable with freeipa v2 ? Message-ID: <201004211934.54063.o.burtchen@gmx.de> Hi, just a short question. I'm using/testing the latest git build from jdennis repository of freeipa v2, and also the sssd version from there. Could it be, that they are currently not working together? Or should they and I have to investigate my problem further? I tried to use ssh with kerberos/gssapi auth, no luck. Best regards, Oli -- Oliver Burtchen, Berlin From rcritten at redhat.com Wed Apr 21 17:41:28 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 21 Apr 2010 13:41:28 -0400 Subject: [Freeipa-users] call implemented methods via xml-rpc In-Reply-To: References: <1271689770.7607.8.camel@jgd-dsk> <1271767764.27603.49.camel@jgd-dsk> <4BCF14F3.6020606@redhat.com> Message-ID: <4BCF38C8.5000400@redhat.com> ALAHYANE Rachid wrote: > Ok so, my end goal is to use the ipa methods with xml-rpc as following, > > * ipaServer : my ipa server, used to authenticate users and serves > response for xml-rpc calls from rpcServer > * rpcServer : this host is my xml-rpc server, I installed freeipa > libraires on it, and an apache server with mod_python and mod_auth_kerb. > This hosts will be used as a client ipa, It is for these reasons that i > used `account.py` from within apache. > * myClient : this host is the one which will make the rpc calls to > rpcServer. > > NB : 'account.py' is called by xmlrpchandler (it is my python handler) > when getUserInfos is called by myclient . Can you set LogLevel debug on the rpcServer web server and see if you get a backtrace (or look in /var/log/httpd/error_log, you may already have one). What is strange is that this code works fine standalone. Can you show us all the code in your xmlrpchandler? BTW, your English is fine :-) rob > > > Example : > myClient calls the remote.account.getUserInfos(u'admin'), rpcServer (in > mode client) intercepts this call and forwards it to the ipaServer. This > last one sends the response to rpcServer (via xml-rpc) and then > rpcServer responds to myClient. > > > this is my configurations : > > == On rpcServer == > --------- httpd conf ------------ > > ## python conf > > > # .... > SetHandler python-program > PythonHandler xmlrpchandler > PythonDebug on > > ------------------------------------ > > the handler xmlrpchandler calls the following method when the client > requests for the remote method getUserInfos(). > > --------- account.py ------------ > def getUserInfos(user_name, env=None): > > from ipalib import api > > api.bootstrap_with_global_options(context='webservices') > api.finalize() > # mode Server is False. I am not on the server ipa > api.Backend.xmlclient.connect() > return api.Command.user_show(user_name) > ------------------------------------ > > > == On myClient == > When I call this method from my client, I get this exception : > > ------------------------------------ > 'exceptions.StandardError'>: API.bootstrap() already called"> > ------------------------------------ > > > I hope that is clearer now, despite my bad English ;) > > > --- > Meilleures salutations / Best Regards > > Rachid ALAHYANE > > > From rcritten at redhat.com Wed Apr 21 17:44:52 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 21 Apr 2010 13:44:52 -0400 Subject: [Freeipa-users] Apache Error Immediately After Install In-Reply-To: <0ed201cae171$c9ec6fb0$5dc54f10$@lodgen@centurytel.net> References: <0c8e01cae0ab$2c4f89c0$84ee9d40$@lodgen@centurytel.net> <4BCDE3A6.5040102@redhat.com> <0ed201cae171$c9ec6fb0$5dc54f10$@lodgen@centurytel.net> Message-ID: <4BCF3994.4060001@redhat.com> Brad Lodgen wrote: > Rob, > > Thanks for your reply. I'm not sure if it makes much difference, but I > forgot to say I'm using the 2.0 Alpha latest release. > > I am using Windows 7. I downloaded the MIT Kerberos Client for Windows, > added my realm/domain, got my ticket, but I still get the same result. I > used the admin user and the user I added, both same results. I ran kinit on > both before trying, same result. I ran ipa user-find on both, both exist. > > Same error message in Firefox, same blank page in IE, same error message on > /var/log/httpd/error_log. > > Any suggestions to move forward? Did you set this in about:config on your browser? network.auth.use-sspi false You might walso want to try this, though I'm not 100% sure if the environment variables work the same way in Windows. http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_the_IPA_Server-Configuring_Your_Browser.html#sect-Installation_and_Deployment_Guide-Configuring_Your_Browser-Troubleshooting This should give us a client-side view of what the request is doing. Do you have a Linux machine you can try from as a baseline test? rob > > > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Tuesday, April 20, 2010 12:26 PM > To: Brad Lodgen > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Apache Error Immediately After Install > > Brad Lodgen wrote: >> I have a fresh install. All I've done is kinit admin and added a single >> user. >> >> >> >> I browse to my ipa web server, log in, then get a blank page in IE and >> in Firefox I get the page at /usr/share/ipa/html/unauthorized.html. I >> checked the source code for the IE page and it's actually taking me to >> the same page, just not showing any text. I changed to compatibility >> mode, same thing. I did all the recommended changes in Firefox, but have >> the same result. >> >> >> >> This is in the Apache error log >> >> >> >> [Tue Apr 20 11:48:54 2010] [error] [client X.X.X.X] >> gss_accept_sec_context() failed: An unsupported mechanism was requested >> (, Unknown error) >> >> >> >> I tried logging in as admin and as a user I added. No luck. >> >> >> >> Any ideas for things to try? > > What OS are you running Firefox from? > > The underlying problem is that you need to do kerberos authentication > from within the browser. This is possible in Windows if you install the > MIT kerberos client software. > > For it to work natively in Windows you'd have to get a ticket as part of > a domain login which we don't support (and probably won't for a while). > > rob > From sgallagh at redhat.com Wed Apr 21 17:54:03 2010 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 21 Apr 2010 13:54:03 -0400 Subject: [Freeipa-users] Is sssd currently useable with freeipa v2 ? In-Reply-To: <201004211934.54063.o.burtchen@gmx.de> References: <201004211934.54063.o.burtchen@gmx.de> Message-ID: <4BCF3BBB.3030906@redhat.com> On 04/21/2010 01:34 PM, Oliver Burtchen wrote: > Hi, > > just a short question. I'm using/testing the latest git build from jdennis > repository of freeipa v2, and also the sssd version from there. Could it be, > that they are currently not working together? Or should they and I have to > investigate my problem further? > > I tried to use ssh with kerberos/gssapi auth, no luck. > > Best regards, > Oli > > To the best of my knowledge, they should be working together, provided that you configured SSSD by using the ipa-client-install tool. -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ From afkkir at gmail.com Wed Apr 21 18:23:30 2010 From: afkkir at gmail.com (ALAHYANE Rachid) Date: Wed, 21 Apr 2010 20:23:30 +0200 Subject: [Freeipa-users] call implemented methods via xml-rpc In-Reply-To: <4BCF38C8.5000400@redhat.com> References: <1271689770.7607.8.camel@jgd-dsk> <1271767764.27603.49.camel@jgd-dsk> <4BCF14F3.6020606@redhat.com> <4BCF38C8.5000400@redhat.com> Message-ID: Here is my apache logs : ------------------------------------------------------------------------------------------------ ==> /var/log/httpd/error_log <== [Wed Apr 21 20:02:51 2010] [warn] mod_python (pid=1529, interpreter=' rpcserver.domain.org'): Module directory listed in "sys.path". This may cause problems. Please check code. File being imported is "/usr/lib/python2.6/site-packages/webservices/account.py". [Wed Apr 21 20:02:51 2010] [notice] mod_python (pid=1529, interpreter=' rpcserver.domain.org'): Importing module '/usr/lib/python2.6/site-packages/webservices/account.py' /usr/lib/python2.6/site-packages/mod_python/importer.py:32: DeprecationWarning: the md5 module is deprecated; use hashlib instead import md5 ipa: ERROR: Could not create log_dir '/root/.ipa/log' ipa: ERROR: could not load plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 533, in import_plugins __import__(fullname) File "/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py", line 33, in from ipaserver.plugins.ldap2 import ldap2 File "/usr/lib/python2.6/site-packages/ipaserver/__init__.py", line 33, in api.bootstrap(context='server', debug=True, log=None) File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 380, in bootstrap self.__doing('bootstrap') File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 365, in __doing '%s.%s() already called' % (self.__class__.__name__, name) StandardError: API.bootstrap() already called ==> /var/log/httpd/access_log <== 172.30.0.135 - - [21/Apr/2010:20:02:51 +0200] "POST /xmlrpc HTTP/1.0" 200 348 "-" "xmlrpclib.py/1.0.1 (by www.pythonware.com)" ------------------------------------------------------------------------------------------------ And here my xmlrpchandler ------------------------------------------------------------------------------------------------ import sys import os from mod_python import apache import xmlrpclib import types import imp import re # Functions we want callable via XML-RPC __all__ = ['listMethods', 'methodSignature', 'methodHelp', 'multicall'] # For method signatures INT = 'int' STRING = 'string' BOOLEAN = 'boolean' DOUBLE = 'double' DATETIME = 'dateTime.iso8601' BASE64 = 'base64' ARRAY = 'array' STRUCT = 'struct' # Saw this done in mod_python's apache.py. I just fixed it up a little... _suffixes = map(lambda x: x[0].replace('.', '\\.'), imp.get_suffixes()) _exp = '(' + '|'.join(_suffixes) + ')$' _suffix_re = re.compile(_exp) _environ = {} def listMethods(env=None): """Enumerates all available XML-RPC methods.""" __xmlrpc_signature = '[[ARRAY]]' method_list = [] # scan the directory which this module resides in path = os.path.dirname(sys.modules[__name__].__file__) try: module_list = [] files = os.listdir(path) for f in files: # does it have a module suffix? if not _suffix_re.search(f): continue # strip module suffix module_name = _suffix_re.sub('', f) # ensure it's not private or this module if module_name[0] == '_' or module_name == __name__: continue if module_name not in module_list: module_list.append(module_name) for module_name in module_list: try: module = apache.import_module(module_name, path=[path]) except: pass else: # scan module for non-private functions func_list = getattr(module, '__all__', dir(module)) for func_name in func_list: if func_name[0] != '_' and \ callable(getattr(module, func_name, None)): method_list.append('%s.%s' % (module_name, func_name)) except: pass # add system methods method_list.extend(map(lambda x: 'system.%s' % x, __all__)) method_list.sort() return method_list def methodSignature(method, env=None): """Returns an XML-RPC method's signature.""" __xmlrpc_signature = '[[ARRAY, STRING]]' func = _map_methodName(method) if not func: return xmlrpclib.Fault(1, '%s: not implemented' % method) return _get_signature(func) def methodHelp(method, env=None): """Returns an XML-RPC method's help string.""" __xmlrpc_signature = '[[STRING, STRING]]' func = _map_methodName(method) if not func: return xmlrpclib.Fault(1, '%s: not implemented' % method) if func.__doc__: help = _strip_docstring(func.__doc__) else: help = '' return help def multicall(call_params, env=None): """Executes multiple method calls with a single request.""" __xmlrpc_signature = '[[ARRAY, ARRAY]]' result_list = [] for param in call_params: if type(param) != dict: result_list.append(_fault_struct(1, 'struct expected')) continue if not param.has_key('methodName') or \ not param.has_key('params'): result_list.append(_fault_struct(1, 'methodName/params members ' \ 'missing')) continue method, params = param['methodName'], param['params'] if method == 'system.multicall': result_list.append(_fault_struct(1, 'system.multicall: ' \ 'recursion forbidden')) continue try: result = _dispatch(method, params) if isinstance(result, xmlrpclib.Fault): result = _fault_struct(result.faultCode, result.faultString) else: result = (result,) except: result_list.append(_fault_struct(2, '%s: %s: %s' % (method, sys.exc_type, sys.exc_value))) else: result_list.append(result) return result_list def _expand_tabs(s, width=8): """Expands tabs to spaces, assuming tabs are of the specified width.""" o = '' col = 0 for c in s: if c == '\t': next = width - (col % width) o += ' '[:next] col += next else: o += c col += 1 return o def _strip_docstring(s): """Takes a docstring and removes any extraneous indentation.""" # Break into lines and expand tabs. s = s.split('\n') s = map(_expand_tabs, s) # Convert lines with only spaces to empty strings. for i in range(len(s)): if s[i] and not s[i].strip(): s[i] = '' # Single line or empty docstring. if len(s) == 1: return s[0] # Take care of the first line. o = '' o += s[0] + '\n' # Go through each line. The first non-blank line determines the indent for # the entire docstring. Unindent each line. indent = 0 for line in s[1:]: if line: if not indent: indent = len(line) - len(line.lstrip()) if line.startswith(' '*indent): line = line[indent:] else: # Indent was short. Strip as much as we can anyway. line = line.lstrip() o += line + '\n' else: o += '\n' # If docstring ends with two linefeeds, remove one of them. if o[-2:] == '\n\n': o = o[:-1] return o def _get_func_const(func, name, default=None): """Get the value of a constant variable defined in a function.""" func_code = getattr(func, 'func_code', None) if func_code: if name in func_code.co_names: i = list(func_code.co_names).index(name) + 1 return func_code.co_consts[i] return default def _get_signature(func): """Return the parameter signature of a function. Will first check func.__xmlrpc_signature, expecting it to be a list of signatures. Otherwise, it will check a constant variable called __xmlrpc_signature defined within the function. The variable MUST be a string and must evaluate to a list of signatures. Returns an empty list if none neither are a valid signature list. """ if hasattr(func, '__xmlrpc_signature'): sig = func.__xmlrpc_signature else: sig_str = _get_func_const(func, '__xmlrpc_signature') sig = [] if sig_str: try: sig = eval(sig_str) # need to validate the signature someday... except: pass return sig _type_map = { types.IntType: INT, types.LongType: INT, types.StringType: STRING, types.FloatType: DOUBLE, types.TupleType: ARRAY, types.ListType: ARRAY, types.DictType: STRUCT } def _xmlrpc_type(v): """Returns an XML-RPC type for a given value.""" t = type(v) if _type_map.has_key(t): return _type_map[t] if t is types.InstanceType: if isinstance(v, xmlrpclib.DateTime): return DATETIME elif isinstance(v, xmlrpclib.Binary): return BASE64 elif isinstance(v, xmlrpclib.Boolean): return BOOLEAN # Huh?! return STRING def _match_signature(params, sig_list): """Matches an argument list with a signature list. If signature list is empty, any sort of argument list is accepted. """ param_types = map(_xmlrpc_type, params) empty_sig = 1 for sig in sig_list: empty_sig = 0 # skip return type sig = sig[1:] if len(param_types) == len(sig) and param_types == sig: return 1 return empty_sig def _fault_struct(faultCode, faultString): """Returns a Fault as a dictionary.""" return { 'faultCode': faultCode, 'faultString': faultString } def _map_methodName(method): """Maps a methodName in the form of module.function to a function.""" # parse methodName as module.function method = method.split('.') if len(method) != 2: return None module_name, func_name = method if module_name == 'system': # reserved functions are implemented in this module module = sys.modules[__name__] else: # attempt to load module from the same directory as this module path = os.path.dirname(sys.modules[__name__].__file__) module = None # ensure it is not private if module_name[0] != '_' and module_name != __name__: try: module = apache.import_module(module_name, path=[path]) except: pass if module is None: return None # now see if module has callable function named func_name if hasattr(module, '__all__') and func_name not in module.__all__: return None if func_name[0] != '_' and hasattr(module, func_name): func = getattr(module, func_name) if callable(func): return func return None def _dispatch(method, params): """Calls an XML-RPC method.""" global _environ func = _map_methodName(method) if func is None: return xmlrpclib.Fault(1, '%s: not implemented' % method) # check arguments sig_list = _get_signature(func) if not _match_signature(params, sig_list): return xmlrpclib.Fault(1, '%s: bad arguments' % method ) # call the function result = apply(func, params, {'env':_environ}) # if result is None, set it to False if result is None: result = xmlrpclib.False return result # These HTTP headers are required according to the XML-RPC spec _required_headers = ['Host', 'User-Agent', 'Content-Type', 'Content-Length'] def handler(req): """mod_python handler.""" global _environ _environ = dict(apache.build_cgi_env(req)) # only accept POST requests if req.method != 'POST': # We set this even though it doesn't seem to do anything... req.err_headers_out['Allow'] = 'POST' return apache.HTTP_METHOD_NOT_ALLOWED # check that all required headers are present for h in _required_headers: if not req.headers_in.has_key(h): return apache.HTTP_BAD_REQUEST if not req.headers_in['Content-Type'].startswith('text/xml'): return apache.HTTP_UNSUPPORTED_MEDIA_TYPE # The structure of the following was inspired by Brian Quinlan's # SimpleXMLRPCServer.py (which was inspired by Fredrik Lundh's code). try: length = int(req.headers_in['Content-Length']) # read and parse request data = req.read(length) params, method = xmlrpclib.loads(data) try: # dispatch the method response = _dispatch(method, params) # convert response to singleton, if necessary if not isinstance(response, xmlrpclib.Fault): response = (response,) except: # caught an exception, return it as our fault response response = xmlrpclib.Fault(2, '%s: %s: %s' % (method, sys.exc_type, sys.exc_value)) # convert response to xml response = xmlrpclib.dumps(response, methodresponse=1) except: # eh?! return apache.HTTP_BAD_REQUEST else: # send response req.content_type = 'text/xml' req.headers_out['Content-Length'] = str(len(response)) req.send_http_header() req.write(response) return apache.OK ------------------------------------------------------------------------------------------------ And here my code of client ------------------------------------------------------------------------------------------------ #!/usr/bin/python import xmlrpclib as rpc remote = rpc.ServerProxy('http://rpcserver.domain.org/xmlrpc ') print "+++++++ remote.account.getUserInfos(u'admin')" print remote.account.getUserInfos(u'admin') ------------------------------------------------------------------------------------------------ --- Meilleures salutations / Best Regards Rachid ALAHYANE 2010/4/21 Rob Crittenden > ALAHYANE Rachid wrote: > >> Ok so, my end goal is to use the ipa methods with xml-rpc as following, >> >> * ipaServer : my ipa server, used to authenticate users and serves >> response for xml-rpc calls from rpcServer >> * rpcServer : this host is my xml-rpc server, I installed freeipa >> libraires on it, and an apache server with mod_python and mod_auth_kerb. >> This hosts will be used as a client ipa, It is for these reasons that i used >> `account.py` from within apache. >> * myClient : this host is the one which will make the rpc calls to >> rpcServer. >> >> NB : 'account.py' is called by xmlrpchandler (it is my python handler) >> when getUserInfos is called by myclient . >> > > Can you set LogLevel debug on the rpcServer web server and see if you get a > backtrace (or look in /var/log/httpd/error_log, you may already have one). > > What is strange is that this code works fine standalone. Can you show us > all the code in your xmlrpchandler? > > BTW, your English is fine :-) > > rob > > > >> >> Example : >> myClient calls the remote.account.getUserInfos(u'admin'), rpcServer (in >> mode client) intercepts this call and forwards it to the ipaServer. This >> last one sends the response to rpcServer (via xml-rpc) and then rpcServer >> responds to myClient. >> >> >> this is my configurations : >> >> == On rpcServer == >> --------- httpd conf ------------ >> >> ## python conf >> >> # .... >> SetHandler python-program >> PythonHandler xmlrpchandler >> PythonDebug on >> >> ------------------------------------ >> >> the handler xmlrpchandler calls the following method when the client >> requests for the remote method getUserInfos(). >> >> --------- account.py ------------ >> def getUserInfos(user_name, env=None): >> >> from ipalib import api >> >> api.bootstrap_with_global_options(context='webservices') >> api.finalize() >> # mode Server is False. I am not on the server ipa >> api.Backend.xmlclient.connect() >> return api.Command.user_show(user_name) >> ------------------------------------ >> >> >> == On myClient == >> When I call this method from my client, I get this exception : >> ------------------------------------ >> : >> API.bootstrap() already called"> >> ------------------------------------ >> >> >> I hope that is clearer now, despite my bad English ;) >> >> >> --- >> Meilleures salutations / Best Regards >> >> Rachid ALAHYANE >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Apr 21 19:21:51 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 21 Apr 2010 15:21:51 -0400 Subject: [Freeipa-users] call implemented methods via xml-rpc In-Reply-To: References: <1271689770.7607.8.camel@jgd-dsk> <1271767764.27603.49.camel@jgd-dsk> <4BCF14F3.6020606@redhat.com> <4BCF38C8.5000400@redhat.com> Message-ID: <4BCF504F.9090809@redhat.com> ALAHYANE Rachid wrote: > Here is my apache logs : > ------------------------------------------------------------------------------------------------ > ==> /var/log/httpd/error_log <== > [Wed Apr 21 20:02:51 2010] [warn] mod_python (pid=1529, > interpreter='rpcserver.domain.org '): > Module directory listed in "sys.path". This may cause problems. Please > check code. File being imported is > "/usr/lib/python2.6/site-packages/webservices/account.py". > [Wed Apr 21 20:02:51 2010] [notice] mod_python (pid=1529, > interpreter='rpcserver.domain.org '): > Importing module '/usr/lib/python2.6/site-packages/webservices/account.py' > /usr/lib/python2.6/site-packages/mod_python/importer.py:32: > DeprecationWarning: the md5 module is deprecated; use hashlib instead > import md5 > ipa: ERROR: Could not create log_dir '/root/.ipa/log' > ipa: ERROR: could not load plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' > Traceback (most recent call last): > File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 533, > in import_plugins > __import__(fullname) > File "/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py", > line 33, in > from ipaserver.plugins.ldap2 import ldap2 > File "/usr/lib/python2.6/site-packages/ipaserver/__init__.py", line > 33, in > api.bootstrap(context='server', debug=True, log=None) > File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 380, > in bootstrap > self.__doing('bootstrap') > File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 365, > in __doing > '%s.%s() already called' % (self.__class__.__name__, name) > StandardError: API.bootstrap() already called Very strange. You explicitly set the context to 'webservices' and this backtrace shows it as 'server' which is why migration.py is trying to load ldap2 (and blowing up). Jason, any ideas? rob > > > ==> /var/log/httpd/access_log <== > 172.30.0.135 - - [21/Apr/2010:20:02:51 +0200] "POST /xmlrpc HTTP/1.0" > 200 348 "-" "xmlrpclib.py/1.0.1 (by > www.pythonware.com )" > > ------------------------------------------------------------------------------------------------ > > > And here my xmlrpchandler > ------------------------------------------------------------------------------------------------ > import sys > import os > from mod_python import apache > import xmlrpclib > import types > > import imp > import re > > > # Functions we want callable via XML-RPC > __all__ = ['listMethods', 'methodSignature', 'methodHelp', 'multicall'] > > # For method signatures > INT = 'int' > STRING = 'string' > BOOLEAN = 'boolean' > DOUBLE = 'double' > DATETIME = 'dateTime.iso8601' > BASE64 = 'base64' > ARRAY = 'array' > STRUCT = 'struct' > > # Saw this done in mod_python's apache.py. I just fixed it up a little... > _suffixes = map(lambda x: x[0].replace('.', '\\.'), imp.get_suffixes()) > _exp = '(' + '|'.join(_suffixes) + ')$' > _suffix_re = re.compile(_exp) > > _environ = {} > > > > > def listMethods(env=None): > """Enumerates all available XML-RPC methods.""" > __xmlrpc_signature = '[[ARRAY]]' > > method_list = [] > > # scan the directory which this module resides in > path = os.path.dirname(sys.modules[__name__].__file__) > try: > module_list = [] > > files = os.listdir(path) > for f in files: > # does it have a module suffix? > if not _suffix_re.search(f): > continue > # strip module suffix > module_name = _suffix_re.sub('', f) > # ensure it's not private or this module > if module_name[0] == '_' or module_name == __name__: > continue > if module_name not in module_list: > module_list.append(module_name) > > for module_name in module_list: > try: > module = apache.import_module(module_name, path=[path]) > except: > pass > else: > # scan module for non-private functions > func_list = getattr(module, '__all__', dir(module)) > for func_name in func_list: > if func_name[0] != '_' and \ > callable(getattr(module, func_name, None)): > method_list.append('%s.%s' % (module_name, > func_name)) > except: > pass > > # add system methods > method_list.extend(map(lambda x: 'system.%s' % x, __all__)) > > method_list.sort() > return method_list > > def methodSignature(method, env=None): > """Returns an XML-RPC method's signature.""" > __xmlrpc_signature = '[[ARRAY, STRING]]' > > func = _map_methodName(method) > if not func: > return xmlrpclib.Fault(1, '%s: not implemented' % method) > > return _get_signature(func) > > def methodHelp(method, env=None): > """Returns an XML-RPC method's help string.""" > __xmlrpc_signature = '[[STRING, STRING]]' > > func = _map_methodName(method) > if not func: > return xmlrpclib.Fault(1, '%s: not implemented' % method) > > if func.__doc__: > help = _strip_docstring(func.__doc__) > else: > help = '' > > return help > > def multicall(call_params, env=None): > """Executes multiple method calls with a single request.""" > __xmlrpc_signature = '[[ARRAY, ARRAY]]' > > result_list = [] > > for param in call_params: > if type(param) != dict: > result_list.append(_fault_struct(1, 'struct expected')) > continue > > if not param.has_key('methodName') or \ > not param.has_key('params'): > result_list.append(_fault_struct(1, 'methodName/params > members ' \ > 'missing')) > continue > > method, params = param['methodName'], param['params'] > > if method == 'system.multicall': > result_list.append(_fault_struct(1, 'system.multicall: ' \ > 'recursion forbidden')) > continue > > try: > result = _dispatch(method, params) > if isinstance(result, xmlrpclib.Fault): > result = _fault_struct(result.faultCode, result.faultString) > else: > result = (result,) > except: > result_list.append(_fault_struct(2, '%s: %s: %s' % > (method, sys.exc_type, > sys.exc_value))) > else: > result_list.append(result) > > return result_list > > def _expand_tabs(s, width=8): > """Expands tabs to spaces, assuming tabs are of the specified width.""" > > o = '' > col = 0 > for c in s: > if c == '\t': > next = width - (col % width) > o += ' '[:next] > col += next > else: > o += c > col += 1 > return o > > def _strip_docstring(s): > """Takes a docstring and removes any extraneous indentation.""" > > # Break into lines and expand tabs. > s = s.split('\n') > s = map(_expand_tabs, s) > > # Convert lines with only spaces to empty strings. > for i in range(len(s)): > if s[i] and not s[i].strip(): > s[i] = '' > > # Single line or empty docstring. > if len(s) == 1: > return s[0] > > # Take care of the first line. > o = '' > o += s[0] + '\n' > > # Go through each line. The first non-blank line determines the > indent for > # the entire docstring. Unindent each line. > indent = 0 > for line in s[1:]: > if line: > if not indent: > indent = len(line) - len(line.lstrip()) > if line.startswith(' '*indent): > line = line[indent:] > else: > # Indent was short. Strip as much as we can anyway. > line = line.lstrip() > o += line + '\n' > else: > o += '\n' > > # If docstring ends with two linefeeds, remove one of them. > if o[-2:] == '\n\n': > o = o[:-1] > > return o > > def _get_func_const(func, name, default=None): > """Get the value of a constant variable defined in a function.""" > > func_code = getattr(func, 'func_code', None) > if func_code: > if name in func_code.co_names: > i = list(func_code.co_names).index(name) + 1 > return func_code.co_consts[i] > return default > > def _get_signature(func): > """Return the parameter signature of a function. > > Will first check func.__xmlrpc_signature, expecting it to be a list > of signatures. Otherwise, it will check a constant variable called > __xmlrpc_signature defined within the function. The variable MUST > be a string and must evaluate to a list of signatures. > > Returns an empty list if none neither are a valid signature list. > """ > > if hasattr(func, '__xmlrpc_signature'): > sig = func.__xmlrpc_signature > else: > sig_str = _get_func_const(func, '__xmlrpc_signature') > sig = [] > if sig_str: > try: > sig = eval(sig_str) > # need to validate the signature someday... > except: > pass > > return sig > > _type_map = { > types.IntType: INT, > types.LongType: INT, > types.StringType: STRING, > types.FloatType: DOUBLE, > types.TupleType: ARRAY, > types.ListType: ARRAY, > types.DictType: STRUCT > } > > def _xmlrpc_type(v): > """Returns an XML-RPC type for a given value.""" > > t = type(v) > if _type_map.has_key(t): > return _type_map[t] > if t is types.InstanceType: > if isinstance(v, xmlrpclib.DateTime): > return DATETIME > elif isinstance(v, xmlrpclib.Binary): > return BASE64 > elif isinstance(v, xmlrpclib.Boolean): > return BOOLEAN > # Huh?! > return STRING > > def _match_signature(params, sig_list): > """Matches an argument list with a signature list. > > If signature list is empty, any sort of argument list is accepted. > """ > > param_types = map(_xmlrpc_type, params) > empty_sig = 1 > for sig in sig_list: > empty_sig = 0 > > # skip return type > sig = sig[1:] > > if len(param_types) == len(sig) and param_types == sig: > return 1 > > return empty_sig > > def _fault_struct(faultCode, faultString): > """Returns a Fault as a dictionary.""" > > return { 'faultCode': faultCode, 'faultString': faultString } > > def _map_methodName(method): > """Maps a methodName in the form of module.function to a function.""" > > # parse methodName as module.function > method = method.split('.') > if len(method) != 2: > return None > > module_name, func_name = method > > if module_name == 'system': > # reserved functions are implemented in this module > module = sys.modules[__name__] > else: > # attempt to load module from the same directory as this module > path = os.path.dirname(sys.modules[__name__].__file__) > > module = None > # ensure it is not private > if module_name[0] != '_' and module_name != __name__: > try: > module = apache.import_module(module_name, path=[path]) > except: > pass > > if module is None: > return None > > # now see if module has callable function named func_name > if hasattr(module, '__all__') and func_name not in module.__all__: > return None > > if func_name[0] != '_' and hasattr(module, func_name): > func = getattr(module, func_name) > > if callable(func): > return func > > return None > > def _dispatch(method, params): > """Calls an XML-RPC method.""" > global _environ > > func = _map_methodName(method) > if func is None: > return xmlrpclib.Fault(1, '%s: not implemented' % method) > > # check arguments > sig_list = _get_signature(func) > if not _match_signature(params, sig_list): > return xmlrpclib.Fault(1, '%s: bad arguments' % method ) > > # call the function > result = apply(func, params, {'env':_environ}) > > # if result is None, set it to False > if result is None: > result = xmlrpclib.False > > return result > > # These HTTP headers are required according to the XML-RPC spec > _required_headers = ['Host', 'User-Agent', 'Content-Type', 'Content-Length'] > > def handler(req): > """mod_python handler.""" > global _environ > _environ = dict(apache.build_cgi_env(req)) > # only accept POST requests > if req.method != 'POST': > # We set this even though it doesn't seem to do anything... > req.err_headers_out['Allow'] = 'POST' > return apache.HTTP_METHOD_NOT_ALLOWED > > # check that all required headers are present > for h in _required_headers: > if not req.headers_in.has_key(h): > return apache.HTTP_BAD_REQUEST > > if not req.headers_in['Content-Type'].startswith('text/xml'): > return apache.HTTP_UNSUPPORTED_MEDIA_TYPE > > # The structure of the following was inspired by Brian Quinlan's > # SimpleXMLRPCServer.py (which was inspired by Fredrik Lundh's code). > try: > length = int(req.headers_in['Content-Length']) > > # read and parse request > data = req.read(length) > params, method = xmlrpclib.loads(data) > > try: > # dispatch the method > response = _dispatch(method, params) > > # convert response to singleton, if necessary > if not isinstance(response, xmlrpclib.Fault): > response = (response,) > except: > # caught an exception, return it as our fault response > response = xmlrpclib.Fault(2, '%s: %s: %s' % > (method, sys.exc_type, > sys.exc_value)) > > # convert response to xml > response = xmlrpclib.dumps(response, methodresponse=1) > except: > # eh?! > return apache.HTTP_BAD_REQUEST > else: > # send response > req.content_type = 'text/xml' > req.headers_out['Content-Length'] = str(len(response)) > req.send_http_header() > req.write(response) > return apache.OK > ------------------------------------------------------------------------------------------------ > > > And here my code of client > ------------------------------------------------------------------------------------------------ > #!/usr/bin/python > > > > import xmlrpclib as rpc > remote = rpc.ServerProxy('http://rpcserver.domain.org/xmlrpc > ') > print "+++++++ remote.account.getUserInfos(u'admin')" > print remote.account.getUserInfos(u'admin') > ------------------------------------------------------------------------------------------------ > > > > --- > Meilleures salutations / Best Regards > > Rachid ALAHYANE > > > > 2010/4/21 Rob Crittenden > > > ALAHYANE Rachid wrote: > > Ok so, my end goal is to use the ipa methods with xml-rpc as > following, > > * ipaServer : my ipa server, used to authenticate users and > serves response for xml-rpc calls from rpcServer > * rpcServer : this host is my xml-rpc server, I installed > freeipa libraires on it, and an apache server with mod_python > and mod_auth_kerb. This hosts will be used as a client ipa, It > is for these reasons that i used `account.py` from within apache. > * myClient : this host is the one which will make the rpc calls > to rpcServer. > > NB : 'account.py' is called by xmlrpchandler (it is my python > handler) when getUserInfos is called by myclient . > > > Can you set LogLevel debug on the rpcServer web server and see if > you get a backtrace (or look in /var/log/httpd/error_log, you may > already have one). > > What is strange is that this code works fine standalone. Can you > show us all the code in your xmlrpchandler? > > BTW, your English is fine :-) > > rob > > > > > Example : > myClient calls the remote.account.getUserInfos(u'admin'), > rpcServer (in mode client) intercepts this call and forwards it > to the ipaServer. This last one sends the response to rpcServer > (via xml-rpc) and then rpcServer responds to myClient. > > > this is my configurations : > > == On rpcServer == > --------- httpd conf ------------ > > ## python conf > > # .... > SetHandler python-program > PythonHandler xmlrpchandler > PythonDebug on > > ------------------------------------ > > the handler xmlrpchandler calls the following method when the > client requests for the remote method getUserInfos(). > > --------- account.py ------------ > def getUserInfos(user_name, env=None): > > from ipalib import api > > api.bootstrap_with_global_options(context='webservices') > api.finalize() > # mode Server is False. I am not on the server ipa > api.Backend.xmlclient.connect() > return api.Command.user_show(user_name) > ------------------------------------ > > > == On myClient == > When I call this method from my client, I get this exception : > ------------------------------------ > 'exceptions.StandardError'>: API.bootstrap() already called"> > ------------------------------------ > > > I hope that is clearer now, despite my bad English ;) > > > --- > Meilleures salutations / Best Regards > > Rachid ALAHYANE > > > > > From o.burtchen at gmx.de Wed Apr 21 18:53:10 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Wed, 21 Apr 2010 20:53:10 +0200 Subject: [Freeipa-users] Is sssd currently useable with freeipa v2 ? In-Reply-To: <4BCF3BBB.3030906@redhat.com> References: <201004211934.54063.o.burtchen@gmx.de> <4BCF3BBB.3030906@redhat.com> Message-ID: <201004212053.10969.o.burtchen@gmx.de> Hi Stephen, thanks for the answer. Yes, I used the ipa-client-install tool. But I had first patched in this fix https://www.redhat.com/archives/freeipa-devel/2010-April/msg00004.html from Rob to get 'join' working again. Well, living at the bleeding edge. ;-) I'll see if I can nail the problem down. Btw., what's the difference between the sssd and sssd12 repos at jdennis? What is the most recent one, whats best to use with the ipa-devel repo? Best regards, Oli Am Mittwoch, 21. April 2010 19:54:03 schrieb Stephen Gallagher: > On 04/21/2010 01:34 PM, Oliver Burtchen wrote: > > Hi, > > > > just a short question. I'm using/testing the latest git build from > > jdennis repository of freeipa v2, and also the sssd version from there. > > Could it be, that they are currently not working together? Or should they > > and I have to investigate my problem further? > > > > I tried to use ssh with kerberos/gssapi auth, no luck. > > > > Best regards, > > Oli > > To the best of my knowledge, they should be working together, provided > that you configured SSSD by using the ipa-client-install tool. > -- Oliver Burtchen, Berlin From sgallagh at redhat.com Wed Apr 21 20:41:53 2010 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 21 Apr 2010 16:41:53 -0400 Subject: [Freeipa-users] Is sssd currently useable with freeipa v2 ? In-Reply-To: <201004212053.10969.o.burtchen@gmx.de> References: <201004211934.54063.o.burtchen@gmx.de> <4BCF3BBB.3030906@redhat.com> <201004212053.10969.o.burtchen@gmx.de> Message-ID: <4BCF6311.5030902@redhat.com> On 04/21/2010 02:53 PM, Oliver Burtchen wrote: > Hi Stephen, > > thanks for the answer. Yes, I used the ipa-client-install tool. But I had first > patched in this fix > > https://www.redhat.com/archives/freeipa-devel/2010-April/msg00004.html > > from Rob to get 'join' working again. Well, living at the bleeding edge. ;-) > > I'll see if I can nail the problem down. You may find the debug logs in /var/log/sssd/. At their default settings (level 0) these logs will display only critical errors. But if you need more information, you can turn up the debug_level in the /etc/sssd/sssd.conf file and restart the SSSD. Then your debug logs will fill up fairly quickly. Btw., what's the difference between > the sssd and sssd12 repos at jdennis? What is the most recent one, whats best > to use with the ipa-devel repo? > We split the development of 1.2 off into it's own branch. Builds from that branch are put into the sssd12 repo. We're aiming to release 1.2.0 at the beginning of May. So that's the branch targeted towards our next public release. We did this so we could put the finishing touches on SSSD 1.2 while those of us who have completed their 1.2 tasks can move ahead. The sssd repo contains our more experimental changes (for example, the internal cache interface was completely rewritten). These are the changes that will be forthcoming in sssd 1.3 sometime this summer. So your choices are: sssd12: Stabilizing towards release sssd: Hang on for dear life(*) (*) I usually run on this branch - eating my own dogfood, as it were - though we make no guarantees that it won't break. From jderose at redhat.com Thu Apr 22 10:58:51 2010 From: jderose at redhat.com (Jason Gerard DeRose) Date: Thu, 22 Apr 2010 04:58:51 -0600 Subject: [Freeipa-users] call implemented methods via xml-rpc In-Reply-To: <4BCF504F.9090809@redhat.com> References: <1271689770.7607.8.camel@jgd-dsk> <1271767764.27603.49.camel@jgd-dsk> <4BCF14F3.6020606@redhat.com> <4BCF38C8.5000400@redhat.com> <4BCF504F.9090809@redhat.com> Message-ID: <1271933931.28383.25.camel@jgd-dsk> On Wed, 2010-04-21 at 15:21 -0400, Rob Crittenden wrote: > ALAHYANE Rachid wrote: > > Here is my apache logs : > > ------------------------------------------------------------------------------------------------ > > ==> /var/log/httpd/error_log <== > > [Wed Apr 21 20:02:51 2010] [warn] mod_python (pid=1529, > > interpreter='rpcserver.domain.org '): > > Module directory listed in "sys.path". This may cause problems. Please > > check code. File being imported is > > "/usr/lib/python2.6/site-packages/webservices/account.py". > > [Wed Apr 21 20:02:51 2010] [notice] mod_python (pid=1529, > > interpreter='rpcserver.domain.org '): > > Importing module '/usr/lib/python2.6/site-packages/webservices/account.py' > > /usr/lib/python2.6/site-packages/mod_python/importer.py:32: > > DeprecationWarning: the md5 module is deprecated; use hashlib instead > > import md5 > > ipa: ERROR: Could not create log_dir '/root/.ipa/log' > > ipa: ERROR: could not load plugin module > > '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' > > Traceback (most recent call last): > > File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 533, > > in import_plugins > > __import__(fullname) > > File "/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py", > > line 33, in > > from ipaserver.plugins.ldap2 import ldap2 > > File "/usr/lib/python2.6/site-packages/ipaserver/__init__.py", line > > 33, in > > api.bootstrap(context='server', debug=True, log=None) > > File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 380, > > in bootstrap > > self.__doing('bootstrap') > > File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 365, > > in __doing > > '%s.%s() already called' % (self.__class__.__name__, name) > > StandardError: API.bootstrap() already called > > Very strange. You explicitly set the context to 'webservices' and this > backtrace shows it as 'server' which is why migration.py is trying to > load ldap2 (and blowing up). > > Jason, any ideas? Okay, took me a while to realize what's going on... in alpha2 we were still running the server under mod_python (we have since switched to mod_wsgi). In alpha2, when ipaserver is imported, ipaserver/__init__.py tries to import mod_python (which would indicate we are running under the Apache process). When mod_python could be imported, we always initialized IPA for use in the server. The worked fine for us at the time, but it obviously causes problems when trying to use the library from another mod_python handler. I recommend you try working with the current code from git, where this implied initialization has been removed: git clone git://git.fedorahosted.org/git/freeipa.git I attached a script that I use to install a bunch of dependencies for building the rpm (or srpm). After you have these dependencies installed, you can then build and install ipa doing something like this: cd freeipa make rpms yum install --nogpgcheck dist/rpms/*.rpm ipa-server-install Hope this helps! > rob -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa-buildrequires.sh Type: application/x-shellscript Size: 606 bytes Desc: not available URL: From afkkir at gmail.com Thu Apr 22 15:18:26 2010 From: afkkir at gmail.com (ALAHYANE Rachid) Date: Thu, 22 Apr 2010 17:18:26 +0200 Subject: [Freeipa-users] call implemented methods via xml-rpc In-Reply-To: <1271933931.28383.25.camel@jgd-dsk> References: <1271767764.27603.49.camel@jgd-dsk> <4BCF14F3.6020606@redhat.com> <4BCF38C8.5000400@redhat.com> <4BCF504F.9090809@redhat.com> <1271933931.28383.25.camel@jgd-dsk> Message-ID: Thank you for answer, now I get this error : ----------------------------------------------------- NetworkError: cannot connect to u'http://localhost:8888/ipa/xml': Permission denied ----------------------------------------------------- How can I specify my ipa server address. Can I do this in the api.bootstrap() method ? What is the difference between api.bootstrap() and api.bootstrap_with_global_options() ? --- Meilleures salutations / Best Regards Rachid ALAHYANE 2010/4/22 Jason Gerard DeRose > On Wed, 2010-04-21 at 15:21 -0400, Rob Crittenden wrote: > > ALAHYANE Rachid wrote: > > > Here is my apache logs : > > > > ------------------------------------------------------------------------------------------------ > > > ==> /var/log/httpd/error_log <== > > > [Wed Apr 21 20:02:51 2010] [warn] mod_python (pid=1529, > > > interpreter='rpcserver.domain.org '): > > > Module directory listed in "sys.path". This may cause problems. Please > > > check code. File being imported is > > > "/usr/lib/python2.6/site-packages/webservices/account.py". > > > [Wed Apr 21 20:02:51 2010] [notice] mod_python (pid=1529, > > > interpreter='rpcserver.domain.org '): > > > Importing module > '/usr/lib/python2.6/site-packages/webservices/account.py' > > > /usr/lib/python2.6/site-packages/mod_python/importer.py:32: > > > DeprecationWarning: the md5 module is deprecated; use hashlib instead > > > import md5 > > > ipa: ERROR: Could not create log_dir '/root/.ipa/log' > > > ipa: ERROR: could not load plugin module > > > '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' > > > Traceback (most recent call last): > > > File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 533, > > > in import_plugins > > > __import__(fullname) > > > File "/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py", > > > line 33, in > > > from ipaserver.plugins.ldap2 import ldap2 > > > File "/usr/lib/python2.6/site-packages/ipaserver/__init__.py", line > > > 33, in > > > api.bootstrap(context='server', debug=True, log=None) > > > File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 380, > > > in bootstrap > > > self.__doing('bootstrap') > > > File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 365, > > > in __doing > > > '%s.%s() already called' % (self.__class__.__name__, name) > > > StandardError: API.bootstrap() already called > > > > Very strange. You explicitly set the context to 'webservices' and this > > backtrace shows it as 'server' which is why migration.py is trying to > > load ldap2 (and blowing up). > > > > Jason, any ideas? > > Okay, took me a while to realize what's going on... in alpha2 we were > still running the server under mod_python (we have since switched to > mod_wsgi). > > In alpha2, when ipaserver is imported, ipaserver/__init__.py tries to > import mod_python (which would indicate we are running under the Apache > process). When mod_python could be imported, we always initialized IPA > for use in the server. The worked fine for us at the time, but it > obviously causes problems when trying to use the library from another > mod_python handler. > > I recommend you try working with the current code from git, where this > implied initialization has been removed: > > git clone git://git.fedorahosted.org/git/freeipa.git > > I attached a script that I use to install a bunch of dependencies for > building the rpm (or srpm). > > After you have these dependencies installed, you can then build and > install ipa doing something like this: > > cd freeipa > make rpms > yum install --nogpgcheck dist/rpms/*.rpm > ipa-server-install > > > Hope this helps! > > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From afkkir at gmail.com Thu Apr 22 16:39:10 2010 From: afkkir at gmail.com (ALAHYANE Rachid) Date: Thu, 22 Apr 2010 18:39:10 +0200 Subject: [Freeipa-users] call implemented methods via xml-rpc In-Reply-To: References: <4BCF14F3.6020606@redhat.com> <4BCF38C8.5000400@redhat.com> <4BCF504F.9090809@redhat.com> <1271933931.28383.25.camel@jgd-dsk> Message-ID: Hi, As I don't know how to specify the xmlrpc_uri in the bootstrap() method, I modified this file /usr/lib/python2.6/site-packages/ipalib/constants.py. I put this line ('xmlrpc_uri', 'https://server.domain.org/ipa/xml') instead ('xmlrpc_uri', 'http://localhost:8888/ipa/xml') Here is the execution of my_script inside the ipython console --------------------------------------------------------------- In [1]: from ipalib import api In [2]: api.bootstrap_with_global_options(context='webservices') Out[2]: (, []) In [3]: api.finalize() In [4]: api.env.xmlrpc_uri Out[4]: u'https://server.domain.org/ipa/xml' In [5]: api.Backend.xmlclient.connect() In [6]: api.Command.user_show(u'admin') --------------------------------------------------------------------------- ConversionError Traceback (most recent call last) /var/www/ in () /usr/lib/python2.6/site-packages/ipalib/frontend.pyc in __call__(self, *args, **options) 399 self.validate(**params) 400 (args, options) = self.params_2_args_options(**params) --> 401 ret = self.run(*args, **options) 402 if ( 403 isinstance(ret, dict) /usr/lib/python2.6/site-packages/ipalib/frontend.pyc in run(self, *args, **options) 668 if self.api.env.in_server: 669 return self.execute(*args, **options) --> 670 return self.forward(*args, **options) 671 672 def execute(self, *args, **kw): /usr/lib/python2.6/site-packages/ipalib/frontend.pyc in forward(self, *args, **kw) 689 Forward call over XML-RPC to this same command on server. 690 """ --> 691 return self.Backend.xmlclient.forward(self.name, *args, **kw) 692 693 def finalize(self): /usr/lib/python2.6/site-packages/ipalib/rpc.pyc in forward(self, name, *args, **kw) 412 if e.faultCode in self.__errors: 413 error = self.__errors[e.faultCode] --> 414 raise error(message=e.faultString) 415 raise UnknownError( 416 code=e.faultCode, ConversionError: invalid 'uid': Only one value is allowed --------------------------------------------------------------- Hem, Yet another problem :( --- Meilleures salutations / Best Regards Rachid ALAHYANE 2010/4/22 ALAHYANE Rachid > Thank you for answer, now I get this error : > ----------------------------------------------------- > NetworkError: cannot connect to u'http://localhost:8888/ipa/xml': > Permission denied > ----------------------------------------------------- > > How can I specify my ipa server address. Can I do this in the > api.bootstrap() method ? > What is the difference between api.bootstrap() > and api.bootstrap_with_global_options() ? > > --- > Meilleures salutations / Best Regards > > Rachid ALAHYANE > > > > 2010/4/22 Jason Gerard DeRose > > On Wed, 2010-04-21 at 15:21 -0400, Rob Crittenden wrote: >> > ALAHYANE Rachid wrote: >> > > Here is my apache logs : >> > > >> ------------------------------------------------------------------------------------------------ >> > > ==> /var/log/httpd/error_log <== >> > > [Wed Apr 21 20:02:51 2010] [warn] mod_python (pid=1529, >> > > interpreter='rpcserver.domain.org '): >> > > Module directory listed in "sys.path". This may cause problems. Please >> > > check code. File being imported is >> > > "/usr/lib/python2.6/site-packages/webservices/account.py". >> > > [Wed Apr 21 20:02:51 2010] [notice] mod_python (pid=1529, >> > > interpreter='rpcserver.domain.org '): >> > > Importing module >> '/usr/lib/python2.6/site-packages/webservices/account.py' >> > > /usr/lib/python2.6/site-packages/mod_python/importer.py:32: >> > > DeprecationWarning: the md5 module is deprecated; use hashlib instead >> > > import md5 >> > > ipa: ERROR: Could not create log_dir '/root/.ipa/log' >> > > ipa: ERROR: could not load plugin module >> > > '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' >> > > Traceback (most recent call last): >> > > File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line >> 533, >> > > in import_plugins >> > > __import__(fullname) >> > > File "/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py", >> > > line 33, in >> > > from ipaserver.plugins.ldap2 import ldap2 >> > > File "/usr/lib/python2.6/site-packages/ipaserver/__init__.py", line >> > > 33, in >> > > api.bootstrap(context='server', debug=True, log=None) >> > > File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line >> 380, >> > > in bootstrap >> > > self.__doing('bootstrap') >> > > File "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line >> 365, >> > > in __doing >> > > '%s.%s() already called' % (self.__class__.__name__, name) >> > > StandardError: API.bootstrap() already called >> > >> > Very strange. You explicitly set the context to 'webservices' and this >> > backtrace shows it as 'server' which is why migration.py is trying to >> > load ldap2 (and blowing up). >> > >> > Jason, any ideas? >> >> Okay, took me a while to realize what's going on... in alpha2 we were >> still running the server under mod_python (we have since switched to >> mod_wsgi). >> >> In alpha2, when ipaserver is imported, ipaserver/__init__.py tries to >> import mod_python (which would indicate we are running under the Apache >> process). When mod_python could be imported, we always initialized IPA >> for use in the server. The worked fine for us at the time, but it >> obviously causes problems when trying to use the library from another >> mod_python handler. >> >> I recommend you try working with the current code from git, where this >> implied initialization has been removed: >> >> git clone git://git.fedorahosted.org/git/freeipa.git >> >> I attached a script that I use to install a bunch of dependencies for >> building the rpm (or srpm). >> >> After you have these dependencies installed, you can then build and >> install ipa doing something like this: >> >> cd freeipa >> make rpms >> yum install --nogpgcheck dist/rpms/*.rpm >> ipa-server-install >> >> >> Hope this helps! >> >> > rob >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Apr 22 17:56:21 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 22 Apr 2010 13:56:21 -0400 Subject: [Freeipa-users] call implemented methods via xml-rpc In-Reply-To: References: <4BCF14F3.6020606@redhat.com> <4BCF38C8.5000400@redhat.com> <4BCF504F.9090809@redhat.com> <1271933931.28383.25.camel@jgd-dsk> Message-ID: <4BD08DC5.2050203@redhat.com> ALAHYANE Rachid wrote: > Hi, > > As I don't know how to specify the xmlrpc_uri in the bootstrap() method, > I modified this file /usr/lib/python2.6/site-packages/ipalib/constants.py. > > I put this line > ('xmlrpc_uri', 'https://server.domain.org/ipa/xml') > instead > ('xmlrpc_uri', 'http://localhost:8888/ipa/xml') How about: api.bootstrap(context='webservices', debug=True, xmlrpc_uri='https://luna.greyoak.com/ipa/xml') > Here is the execution of my_script inside the ipython console > > --------------------------------------------------------------- > In [1]: from ipalib import api > > In [2]: api.bootstrap_with_global_options(context='webservices') > Out[2]: > ( 'verbose': None}>, > []) > > In [3]: api.finalize() > > In [4]: api.env.xmlrpc_uri > Out[4]: u'https://server.domain.org/ipa/xml' > > In [5]: api.Backend.xmlclient.connect() > > In [6]: api.Command.user_show(u'admin') > --------------------------------------------------------------------------- > ConversionError Traceback (most recent call last) > > /var/www/ in () > > /usr/lib/python2.6/site-packages/ipalib/frontend.pyc in __call__(self, > *args, **options) > 399 self.validate(**params) > 400 (args, options) = self.params_2_args_options(**params) > --> 401 ret = self.run(*args, **options) > 402 if ( > 403 isinstance(ret, dict) > > /usr/lib/python2.6/site-packages/ipalib/frontend.pyc in run(self, *args, > **options) > 668 if self.api.env.in_server: > 669 return self.execute(*args, **options) > --> 670 return self.forward(*args, **options) > 671 > 672 def execute(self, *args, **kw): > > /usr/lib/python2.6/site-packages/ipalib/frontend.pyc in forward(self, > *args, **kw) > 689 Forward call over XML-RPC to this same command on server. > 690 """ > --> 691 return self.Backend.xmlclient.forward(self.name > , *args, **kw) > 692 > 693 def finalize(self): > > /usr/lib/python2.6/site-packages/ipalib/rpc.pyc in forward(self, name, > *args, **kw) > 412 if e.faultCode in self.__errors: > 413 error = self.__errors[e.faultCode] > --> 414 raise error(message=e.faultString) > 415 raise UnknownError( > 416 code=e.faultCode, > > ConversionError: invalid 'uid': Only one value is allowed Is there anything interesting logged on the server? With debug=True you get a lot more output, might show something as well. rob > > --------------------------------------------------------------- > > Hem, Yet another problem :( Well, thanks for your continued patience with this. You're the first one out of our group to be using ipalib independently. Hopefully at the end of this we'll have another example of a way to use it. cheers rob > > --- > Meilleures salutations / Best Regards > > Rachid ALAHYANE > > > > 2010/4/22 ALAHYANE Rachid > > > Thank you for answer, now I get this error : > ----------------------------------------------------- > NetworkError: cannot connect to u'http://localhost:8888/ipa/xml': > Permission denied > ----------------------------------------------------- > > How can I specify my ipa server address. Can I do this in the > api.bootstrap() method ? > What is the difference between api.bootstrap() > and api.bootstrap_with_global_options() ? > > --- > Meilleures salutations / Best Regards > > Rachid ALAHYANE > > > > 2010/4/22 Jason Gerard DeRose > > > On Wed, 2010-04-21 at 15:21 -0400, Rob Crittenden wrote: > > ALAHYANE Rachid wrote: > > > Here is my apache logs : > > > > ------------------------------------------------------------------------------------------------ > > > ==> /var/log/httpd/error_log <== > > > [Wed Apr 21 20:02:51 2010] [warn] mod_python (pid=1529, > > > interpreter='rpcserver.domain.org > '): > > > Module directory listed in "sys.path". This may cause > problems. Please > > > check code. File being imported is > > > "/usr/lib/python2.6/site-packages/webservices/account.py". > > > [Wed Apr 21 20:02:51 2010] [notice] mod_python (pid=1529, > > > interpreter='rpcserver.domain.org > '): > > > Importing module > '/usr/lib/python2.6/site-packages/webservices/account.py' > > > /usr/lib/python2.6/site-packages/mod_python/importer.py:32: > > > DeprecationWarning: the md5 module is deprecated; use > hashlib instead > > > import md5 > > > ipa: ERROR: Could not create log_dir '/root/.ipa/log' > > > ipa: ERROR: could not load plugin module > > > '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' > > > Traceback (most recent call last): > > > File > "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 533, > > > in import_plugins > > > __import__(fullname) > > > File > "/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py", > > > line 33, in > > > from ipaserver.plugins.ldap2 import ldap2 > > > File > "/usr/lib/python2.6/site-packages/ipaserver/__init__.py", line > > > 33, in > > > api.bootstrap(context='server', debug=True, log=None) > > > File > "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 380, > > > in bootstrap > > > self.__doing('bootstrap') > > > File > "/usr/lib/python2.6/site-packages/ipalib/plugable.py", line 365, > > > in __doing > > > '%s.%s() already called' % (self.__class__.__name__, name) > > > StandardError: API.bootstrap() already called > > > > Very strange. You explicitly set the context to 'webservices' > and this > > backtrace shows it as 'server' which is why migration.py is > trying to > > load ldap2 (and blowing up). > > > > Jason, any ideas? > > Okay, took me a while to realize what's going on... in alpha2 we > were > still running the server under mod_python (we have since switched to > mod_wsgi). > > In alpha2, when ipaserver is imported, ipaserver/__init__.py > tries to > import mod_python (which would indicate we are running under the > Apache > process). When mod_python could be imported, we always > initialized IPA > for use in the server. The worked fine for us at the time, but it > obviously causes problems when trying to use the library from > another > mod_python handler. > > I recommend you try working with the current code from git, > where this > implied initialization has been removed: > > git clone git://git.fedorahosted.org/git/freeipa.git > > > I attached a script that I use to install a bunch of > dependencies for > building the rpm (or srpm). > > After you have these dependencies installed, you can then build and > install ipa doing something like this: > > cd freeipa > make rpms > yum install --nogpgcheck dist/rpms/*.rpm > ipa-server-install > > > Hope this helps! > > > rob > > > From afkkir at gmail.com Fri Apr 23 17:12:22 2010 From: afkkir at gmail.com (ALAHYANE Rachid) Date: Fri, 23 Apr 2010 19:12:22 +0200 Subject: [Freeipa-users] call implemented methods via xml-rpc In-Reply-To: <4BD08DC5.2050203@redhat.com> References: <4BCF14F3.6020606@redhat.com> <4BCF38C8.5000400@redhat.com> <4BCF504F.9090809@redhat.com> <1271933931.28383.25.camel@jgd-dsk> <4BD08DC5.2050203@redhat.com> Message-ID: Hi, > How about: > > api.bootstrap(context='webservices', debug=True, xmlrpc_uri=' > https://luna.greyoak.com/ipa/xml') > when I do this, I get these messages --------------------------------------------------------------------- In [1]: from ipalib import api In [2]: api.bootstrap(context='webservices', debug=True, xmlrpc_uri=' https://server.domain.org/ipa/xml') In [3]: api.env.xmlrpc_uri Out[3]: u'https://server.domain.org/ipa/xml' In [4]: api.env.realm Out[4]: u'EXAMPLE.COM' In [5]: api.finalize() ipa: DEBUG: importing all plugin modules in '/usr/lib/python2.6/site-packages/ipalib/plugins'... ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py' ipa: INFO: skipping plugin module ipalib.plugins.cert: env.enable_ra is not True ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hbac.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/rolegroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/taskgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py' In [6]: api.Backend.xmlclient.connect() ipa: INFO: Created connection context.xmlclient In [7]: api.Command.user_show(u'admin') ipa: DEBUG: raw: user_show(u'admin') ipa: INFO: user_show(u'admin', all=False, raw=False) ipa: INFO: Forwarding 'user_show' to server u' https://server.domain.org/ipa/xml' ipa: DEBUG: Caught fault 3008 from server https://server.domain.org/ipa/xml: invalid 'uid': Only one value is allowed --------------------------------------------------------------------------- ConversionError Traceback (most recent call last) /root/ in () /usr/lib/python2.6/site-packages/ipalib/frontend.pyc in __call__(self, *args, **options) 399 self.validate(**params) 400 (args, options) = self.params_2_args_options(**params) --> 401 ret = self.run(*args, **options) 402 if ( 403 isinstance(ret, dict) /usr/lib/python2.6/site-packages/ipalib/frontend.pyc in run(self, *args, **options) 668 if self.api.env.in_server: 669 return self.execute(*args, **options) --> 670 return self.forward(*args, **options) 671 672 def execute(self, *args, **kw): /usr/lib/python2.6/site-packages/ipalib/frontend.pyc in forward(self, *args, **kw) 689 Forward call over XML-RPC to this same command on server. 690 """ --> 691 return self.Backend.xmlclient.forward(self.name, *args, **kw) 692 693 def finalize(self): /usr/lib/python2.6/site-packages/ipalib/rpc.pyc in forward(self, name, *args, **kw) 412 if e.faultCode in self.__errors: 413 error = self.__errors[e.faultCode] --> 414 raise error(message=e.faultString) 415 raise UnknownError( 416 code=e.faultCode, ConversionError: invalid 'uid': Only one value is allowed --------------------------------------------------------------------- For api.env.realm, u'DOMAIN.ORG' is expected value. it seems that api.env was not initialized correctly. Is there anything interesting logged on the server? > > With debug=True you get a lot more output, might show something as well. > You are right, here the logs on the ipa server --------------------------------------------------------------------- ==> /var/log/httpd/error_log <== ipa: INFO: Created connection context.ldap2 ipa: DEBUG: raw: user_show((u'admin',), all=False, raw=False) ipa: INFO: Destroyed connection context.ldap2 ==> /var/log/httpd/access_log <== 172.30.0.137 - raca at DOMAIN.ORG [23/Apr/2010:18:06:16 +0200] "POST /ipa/xml HTTP/1.0" 200 315 ==> /var/log/httpd/error_log <== ipa: INFO: Created connection context.ldap2 ipa: DEBUG: raw: user_show((u'admin',), all=False, raw=False) ipa: INFO: Destroyed connection context.ldap2 ==> /var/log/httpd/access_log <== 172.30.0.137 - raca at DOMAIN.ORG [23/Apr/2010:18:11:53 +0200] "POST /ipa/xml HTTP/1.0" 200 315 --------------------------------------------------------------------- I think, I have this problem because I use two different versions of freeipa. In the one hand, I have an old version (1.9.0GIT28d8bd6-0.fc12.i686 that I generated there was a time) of freeipa on the ipa server, on the other hand I have the last version of freeIPA on the client. So, I generated new rpms from the last version of git repository and I installed them on the client and server. But when I start ipa-server-install on the server, I get an error (hem I think that I must to post a new mail on the mailing list) ---------------------------------------------------------------------- .... .... The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring directory server for the CA: [1/4]: creating directory server user [2/4]: creating directory server instance [3/4]: configuring directory to start on boot [4/4]: restarting directory server done configuring pkids. Configuring certificate server: [1/14]: creating certificate server user [2/14]: configuring certificate server instance root : CRITICAL failed to restart ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname server.domain.org -cs_port 9445 -client_certdb_dir /tmp/tmp-Li3Uhg -client_certdb_pwd XXXXXXXX -preop_pin cYUmg5JpkmRm3xBAlTqg -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject "CN=ipa-ca-agent,O=IPA" -ldap_host server.domain.org -ldap_port 7389 -bind_dn "cn=Directory Manager" -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name "CN=CA Subsystem,O=IPA" -ca_ocsp_cert_subject_name "CN=OCSP Subsystem,O=IPA" -ca_server_cert_subject_name "CN=server.domain.org,O=IPA" -ca_audit_signing_cert_subject_name "CN=CA Audit,O=IPA" -ca_sign_cert_subject_name "CN=Certificate Authority,O=IPA" -external false -clone false' returned non-zero exit status 255 [3/14]: creating CA agent PKCS#12 file in /root Unexpected error - see ipaserver-install.log for details: Command '/usr/bin/pk12util -n ipa-ca-agent -o /root/ca-agent.p12 -d /tmp/tmp-Li3Uhg -k /tmp/tmphMeDU3 -w /tmp/tmphMeDU3' returned non-zero exit status 24 ---------------------------------------------------------------------- In the logs of installation i found these errors : ---------------------------------------------------------------------- .... Attempting to connect to: server.domain.org:9445 ERROR: unable to set Cipher List ERROR: Exception = org.mozilla.jss.ssl.SSLSocketException: Failed to enable cipher 0xc001 : (-12266) An unknown SSL cipher suite has been requested. in TestCertApprovalCallback.approve() .... .... ERROR: unable to parse xml ERROR XML = ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ####################################################################### 2010-04-23 18:57:01,648 INFO stderr=[Fatal Error] :1:947: The element type "HR" must be terminated by the matching end-tag "". org.xml.sax.SAXParseException: The element type "HR" must be terminated by the matching end-tag "". at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:239) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:283) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) at ParseXML.parse(ParseXML.java:43) at ConfigureCA.LoginPanel(ConfigureCA.java:199) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1138) at ConfigureCA.main(ConfigureCA.java:1595) ... ---------------------------------------------------------------------- I can provide you other informations if needed. Thank you for your help ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Apr 23 17:28:05 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 23 Apr 2010 13:28:05 -0400 Subject: [Freeipa-users] call implemented methods via xml-rpc In-Reply-To: References: <4BCF14F3.6020606@redhat.com> <4BCF38C8.5000400@redhat.com> <4BCF504F.9090809@redhat.com> <1271933931.28383.25.camel@jgd-dsk> <4BD08DC5.2050203@redhat.com> Message-ID: <4BD1D8A5.1060309@redhat.com> Lots of embedded comments... ALAHYANE Rachid wrote: > Hi, > > > How about: > > api.bootstrap(context='webservices', debug=True, > xmlrpc_uri='https://luna.greyoak.com/ipa/xml') > > > when I do this, I get these messages > > --------------------------------------------------------------------- > In [1]: from ipalib import api > > In [2]: api.bootstrap(context='webservices', debug=True, > xmlrpc_uri='https://server.domain.org/ipa/xml') > > In [3]: api.env.xmlrpc_uri > Out[3]: u'https://server.domain.org/ipa/xml' > > In [4]: api.env.realm > Out[4]: u'EXAMPLE.COM ' > > In [5]: api.finalize() > ipa: DEBUG: importing all plugin modules in > '/usr/lib/python2.6/site-packages/ipalib/plugins'... > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py' > ipa: INFO: skipping plugin module ipalib.plugins.cert: env.enable_ra is > not True > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/hbac.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/rolegroup.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/taskgroup.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py' > > In [6]: api.Backend.xmlclient.connect() > ipa: INFO: Created connection context.xmlclient > > In [7]: api.Command.user_show(u'admin') > ipa: DEBUG: raw: user_show(u'admin') > ipa: INFO: user_show(u'admin', all=False, raw=False) > ipa: INFO: Forwarding 'user_show' to server > u'https://server.domain.org/ipa/xml' > ipa: DEBUG: Caught fault 3008 from server > https://server.domain.org/ipa/xml: invalid 'uid': Only one value is allowed > --------------------------------------------------------------------------- > ConversionError Traceback (most recent call last) > > /root/ in () > > /usr/lib/python2.6/site-packages/ipalib/frontend.pyc in __call__(self, > *args, **options) > 399 self.validate(**params) > 400 (args, options) = self.params_2_args_options(**params) > --> 401 ret = self.run(*args, **options) > 402 if ( > 403 isinstance(ret, dict) > > /usr/lib/python2.6/site-packages/ipalib/frontend.pyc in run(self, *args, > **options) > 668 if self.api.env.in_server: > 669 return self.execute(*args, **options) > --> 670 return self.forward(*args, **options) > 671 > 672 def execute(self, *args, **kw): > > /usr/lib/python2.6/site-packages/ipalib/frontend.pyc in forward(self, > *args, **kw) > 689 Forward call over XML-RPC to this same command on server. > 690 """ > --> 691 return self.Backend.xmlclient.forward(self.name > , *args, **kw) > 692 > 693 def finalize(self): > > /usr/lib/python2.6/site-packages/ipalib/rpc.pyc in forward(self, name, > *args, **kw) > 412 if e.faultCode in self.__errors: > 413 error = self.__errors[e.faultCode] > --> 414 raise error(message=e.faultString) > 415 raise UnknownError( > 416 code=e.faultCode, > > ConversionError: invalid 'uid': Only one value is allowed > --------------------------------------------------------------------- > > For api.env.realm, u'DOMAIN.ORG ' is expected value. > it seems that api.env was not initialized correctly. I suspect is isn't reading the configuration file. Try adding 'in_tree=False' to your bootstrap call. This should force it to read /etc/ipa/default.conf (which I assume you have configured). > > Is there anything interesting logged on the server? > > With debug=True you get a lot more output, might show something as well. > > > You are right, here the logs on the ipa server > > --------------------------------------------------------------------- > ==> /var/log/httpd/error_log <== > ipa: INFO: Created connection context.ldap2 > ipa: DEBUG: raw: user_show((u'admin',), all=False, raw=False) > ipa: INFO: Destroyed connection context.ldap2 > > ==> /var/log/httpd/access_log <== > 172.30.0.137 - raca at DOMAIN.ORG > [23/Apr/2010:18:06:16 +0200] "POST /ipa/xml HTTP/1.0" 200 315 > > ==> /var/log/httpd/error_log <== > ipa: INFO: Created connection context.ldap2 > ipa: DEBUG: raw: user_show((u'admin',), all=False, raw=False) > ipa: INFO: Destroyed connection context.ldap2 > > ==> /var/log/httpd/access_log <== > 172.30.0.137 - raca at DOMAIN.ORG > [23/Apr/2010:18:11:53 +0200] "POST /ipa/xml HTTP/1.0" 200 315 > > --------------------------------------------------------------------- > > I think, I have this problem because I use two different versions of > freeipa. In the one hand, I have an old version > (1.9.0GIT28d8bd6-0.fc12.i686 that I generated there was a time) of > freeipa on the ipa server, on the other hand I have the last version of > freeIPA on the client. So, I generated new rpms from the last version of > git repository and I installed them on the client and server. Yes, I think you're right here. The multiple value error is because admin is being converted into a tuple at some point. Looks ok in the client log though we'd have to enable more XML-RPC debugging to see what it is sent as on the wire. We did some recent API changes so I'm going to guess this is what the problem is, updating (or using the same version of IPA on both sides) is the right way to go. > > But when I start ipa-server-install on the server, I get an error (hem I > think that I must to post a new mail on the mailing list) > > ---------------------------------------------------------------------- > .... > .... > The following operations may take some minutes to complete. > Please wait until the prompt is returned. > > Configuring directory server for the CA: > [1/4]: creating directory server user > [2/4]: creating directory server instance > [3/4]: configuring directory to start on boot > [4/4]: restarting directory server > done configuring pkids. > Configuring certificate server: > [1/14]: creating certificate server user > [2/14]: configuring certificate server instance > root : CRITICAL failed to restart ca instance Command > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > server.domain.org -cs_port 9445 > -client_certdb_dir /tmp/tmp-Li3Uhg -client_certdb_pwd XXXXXXXX > -preop_pin cYUmg5JpkmRm3xBAlTqg -domain_name IPA -admin_user admin > -admin_email root at localhost -admin_password XXXXXXXX -agent_name > ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa > -agent_cert_subject "CN=ipa-ca-agent,O=IPA" -ldap_host server.domain.org > -ldap_port 7389 -bind_dn "cn=Directory > Manager" -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca > -key_size 2048 -key_type rsa -save_p12 true -backup_pwd XXXXXXXX > -subsystem_name pki-cad -token_name internal > -ca_subsystem_cert_subject_name "CN=CA Subsystem,O=IPA" > -ca_ocsp_cert_subject_name "CN=OCSP Subsystem,O=IPA" > -ca_server_cert_subject_name "CN=server.domain.org > ,O=IPA" -ca_audit_signing_cert_subject_name > "CN=CA Audit,O=IPA" -ca_sign_cert_subject_name "CN=Certificate > Authority,O=IPA" -external false -clone false' returned non-zero exit > status 255 > [3/14]: creating CA agent PKCS#12 file in /root > Unexpected error - see ipaserver-install.log for details: > Command '/usr/bin/pk12util -n ipa-ca-agent -o /root/ca-agent.p12 -d > /tmp/tmp-Li3Uhg -k /tmp/tmphMeDU3 -w /tmp/tmphMeDU3' returned non-zero > exit status 24 Yeah, mismatch in dogtag. You have two choices: 1. If you don't care about the CA at this point you can install the IPA server with --selfsign which will install a simpler, self-signed CA that uses the NSS command-line utilities for certificates. Not really the best choice for a production installation but adequate for testing. 2. Enable the updates-testing repo and update dogtag. I think that this should do it: yum --enablerepo=updates-testing update pki-* dogtag-* The problem is dogtag has pretty weak dependencies right now and at least one package is still lingering in updates-testing (pki-common). rob From afkkir at gmail.com Fri Apr 23 19:35:02 2010 From: afkkir at gmail.com (ALAHYANE Rachid) Date: Fri, 23 Apr 2010 21:35:02 +0200 Subject: [Freeipa-users] call implemented methods via xml-rpc In-Reply-To: <4BD1D8A5.1060309@redhat.com> References: <4BCF38C8.5000400@redhat.com> <4BCF504F.9090809@redhat.com> <1271933931.28383.25.camel@jgd-dsk> <4BD08DC5.2050203@redhat.com> <4BD1D8A5.1060309@redhat.com> Message-ID: It works !!! I installed my server with --selfsign and i added in_tree=False in my api.bootstrap() method and it runs very well. Thank you guys ^^ -- Meilleures salutations / Best Regards Rachid ALAHYANE 2010/4/23 Rob Crittenden > Lots of embedded comments... > > ALAHYANE Rachid wrote: > >> Hi, >> >> >> How about: >> >> api.bootstrap(context='webservices', debug=True, >> xmlrpc_uri='https://luna.greyoak.com/ipa/xml') >> >> >> when I do this, I get these messages >> >> --------------------------------------------------------------------- >> In [1]: from ipalib import api >> >> In [2]: api.bootstrap(context='webservices', debug=True, xmlrpc_uri=' >> https://server.domain.org/ipa/xml') >> >> In [3]: api.env.xmlrpc_uri Out[3]: u'https://server.domain.org/ipa/xml' >> >> In [4]: api.env.realm Out[4]: u'EXAMPLE.COM ' >> >> >> In [5]: api.finalize() >> ipa: DEBUG: importing all plugin modules in >> '/usr/lib/python2.6/site-packages/ipalib/plugins'... >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py' >> ipa: INFO: skipping plugin module ipalib.plugins.cert: env.enable_ra is >> not True >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/hbac.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/pwpolicy.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/rolegroup.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/service.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/taskgroup.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/user.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/virtual.py' >> ipa: DEBUG: importing plugin module >> '/usr/lib/python2.6/site-packages/ipalib/plugins/xmlclient.py' >> >> In [6]: api.Backend.xmlclient.connect() >> ipa: INFO: Created connection context.xmlclient >> >> In [7]: api.Command.user_show(u'admin') >> ipa: DEBUG: raw: user_show(u'admin') >> ipa: INFO: user_show(u'admin', all=False, raw=False) >> ipa: INFO: Forwarding 'user_show' to server u' >> https://server.domain.org/ipa/xml' >> ipa: DEBUG: Caught fault 3008 from server >> https://server.domain.org/ipa/xml: invalid 'uid': Only one value is >> allowed >> >> --------------------------------------------------------------------------- >> ConversionError Traceback (most recent call >> last) >> >> /root/ in () >> >> /usr/lib/python2.6/site-packages/ipalib/frontend.pyc in __call__(self, >> *args, **options) >> 399 self.validate(**params) >> 400 (args, options) = self.params_2_args_options(**params) >> --> 401 ret = self.run(*args, **options) >> 402 if ( >> 403 isinstance(ret, dict) >> >> /usr/lib/python2.6/site-packages/ipalib/frontend.pyc in run(self, *args, >> **options) >> 668 if self.api.env.in_server: >> 669 return self.execute(*args, **options) >> --> 670 return self.forward(*args, **options) >> 671 672 def execute(self, *args, **kw): >> >> /usr/lib/python2.6/site-packages/ipalib/frontend.pyc in forward(self, >> *args, **kw) >> 689 Forward call over XML-RPC to this same command on server. >> 690 """ >> --> 691 return self.Backend.xmlclient.forward(self.name < >> http://self.name>, *args, **kw) >> >> 692 693 def finalize(self): >> >> /usr/lib/python2.6/site-packages/ipalib/rpc.pyc in forward(self, name, >> *args, **kw) >> 412 if e.faultCode in self.__errors: >> 413 error = self.__errors[e.faultCode] >> --> 414 raise error(message=e.faultString) >> 415 raise UnknownError( >> 416 code=e.faultCode, >> >> ConversionError: invalid 'uid': Only one value is allowed >> --------------------------------------------------------------------- >> >> For api.env.realm, u'DOMAIN.ORG ' is expected value. >> it seems that api.env was not initialized correctly. >> > > I suspect is isn't reading the configuration file. Try adding > 'in_tree=False' to your bootstrap call. This should force it to read > /etc/ipa/default.conf (which I assume you have configured). > > >> Is there anything interesting logged on the server? >> >> With debug=True you get a lot more output, might show something as >> well. >> >> >> You are right, here the logs on the ipa server >> >> --------------------------------------------------------------------- >> ==> /var/log/httpd/error_log <== >> ipa: INFO: Created connection context.ldap2 >> ipa: DEBUG: raw: user_show((u'admin',), all=False, raw=False) >> ipa: INFO: Destroyed connection context.ldap2 >> >> ==> /var/log/httpd/access_log <== >> 172.30.0.137 - raca at DOMAIN.ORG >> [23/Apr/2010:18:06:16 +0200] "POST /ipa/xml HTTP/1.0" 200 315 >> >> >> ==> /var/log/httpd/error_log <== >> ipa: INFO: Created connection context.ldap2 >> ipa: DEBUG: raw: user_show((u'admin',), all=False, raw=False) >> ipa: INFO: Destroyed connection context.ldap2 >> >> ==> /var/log/httpd/access_log <== >> 172.30.0.137 - raca at DOMAIN.ORG >> [23/Apr/2010:18:11:53 +0200] "POST /ipa/xml HTTP/1.0" 200 315 >> >> >> --------------------------------------------------------------------- >> >> I think, I have this problem because I use two different versions of >> freeipa. In the one hand, I have an old version (1.9.0GIT28d8bd6-0.fc12.i686 >> that I generated there was a time) of freeipa on the ipa server, on the >> other hand I have the last version of freeIPA on the client. So, I generated >> new rpms from the last version of git repository and I installed them on the >> client and server. >> > > Yes, I think you're right here. The multiple value error is because admin > is being converted into a tuple at some point. Looks ok in the client log > though we'd have to enable more XML-RPC debugging to see what it is sent as > on the wire. We did some recent API changes so I'm going to guess this is > what the problem is, updating (or using the same version of IPA on both > sides) is the right way to go. > > >> But when I start ipa-server-install on the server, I get an error (hem I >> think that I must to post a new mail on the mailing list) >> >> ---------------------------------------------------------------------- >> .... >> .... >> The following operations may take some minutes to complete. >> Please wait until the prompt is returned. >> >> Configuring directory server for the CA: >> [1/4]: creating directory server user >> [2/4]: creating directory server instance >> [3/4]: configuring directory to start on boot >> [4/4]: restarting directory server >> done configuring pkids. >> Configuring certificate server: >> [1/14]: creating certificate server user >> [2/14]: configuring certificate server instance >> root : CRITICAL failed to restart ca instance Command >> '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >> server.domain.org -cs_port 9445 >> -client_certdb_dir /tmp/tmp-Li3Uhg -client_certdb_pwd XXXXXXXX -preop_pin >> cYUmg5JpkmRm3xBAlTqg -domain_name IPA -admin_user admin -admin_email >> root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent >> -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject >> "CN=ipa-ca-agent,O=IPA" -ldap_host server.domain.org < >> http://server.domain.org> -ldap_port 7389 -bind_dn "cn=Directory Manager" >> -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 >> -key_type rsa -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad >> -token_name internal -ca_subsystem_cert_subject_name "CN=CA Subsystem,O=IPA" >> -ca_ocsp_cert_subject_name "CN=OCSP Subsystem,O=IPA" >> -ca_server_cert_subject_name "CN=server.domain.org < >> http://server.domain.org>,O=IPA" -ca_audit_signing_cert_subject_name >> "CN=CA Audit,O=IPA" -ca_sign_cert_subject_name "CN=Certificate >> Authority,O=IPA" -external false -clone false' returned non-zero exit status >> 255 >> >> [3/14]: creating CA agent PKCS#12 file in /root >> Unexpected error - see ipaserver-install.log for details: >> Command '/usr/bin/pk12util -n ipa-ca-agent -o /root/ca-agent.p12 -d >> /tmp/tmp-Li3Uhg -k /tmp/tmphMeDU3 -w /tmp/tmphMeDU3' returned non-zero exit >> status 24 >> > > Yeah, mismatch in dogtag. You have two choices: > > 1. If you don't care about the CA at this point you can install the IPA > server with --selfsign which will install a simpler, self-signed CA that > uses the NSS command-line utilities for certificates. Not really the best > choice for a production installation but adequate for testing. > > 2. Enable the updates-testing repo and update dogtag. I think that this > should do it: yum --enablerepo=updates-testing update pki-* dogtag-* > > The problem is dogtag has pretty weak dependencies right now and at least > one package is still lingering in updates-testing (pki-common). > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From o.burtchen at gmx.de Fri Apr 30 22:33:38 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Sat, 1 May 2010 00:33:38 +0200 Subject: [Freeipa-users] ERROR: unable to set Cipher List Message-ID: <201005010033.38299.o.burtchen@gmx.de> Hi @all, I did a clean, minimum F-12 install with all updates, and used freeipa and sssd12 from http://jdennis.fedorapeople.org/ Everything seems to work fine when I do a ipa-server-install --setup-dns But what does it mean what I see in ipaserver-install.log (attached)? Is this hamfull, or just a missing, unused cipher-library? Or missing dependency when installing? As I said, pki-ca, dogtag and freeipa seem to work. Best regards and thanks for answers, Oli --- snip --- Attempting to connect to: test.example.com:9445 ERROR: unable to set Cipher List ERROR: Exception = org.mozilla.jss.ssl.SSLSocketException: Failed to enable cipher 0xc001 : (-12266) An unknown SSL cipher suite has been requested. in TestCertApprovalCallback.approve() Peer cert details: subject: CN=test.example.com,O=2010-04-30 23:48:30 issuer: CN=test.example.com,O=2010-04-30 23:48:30 serial: 0 item 1 reason=-8156 depth=1 cert details: subject: CN=test.example.com,O=2010-04-30 23:48:30 issuer: CN=test.example.com,O=2010-04-30 23:48:30 serial: 0 item 2 reason=-8172 depth=1 cert details: subject: CN=test.example.com,O=2010-04-30 23:48:30 issuer: CN=test.example.com,O=2010-04-30 23:48:30 serial: 0 importing certificate. Connected. Posting Query = https://test.example.com:9445//ca/admin/console/config/login?pin=jJMsl21Np7mk6aHPOzm0&xml=true RESPONSE STATUS: HTTP/1.1 302 Moved Temporarily RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Set-Cookie: JSESSIONID=BED7F647B4BFC9FC8BD9F7BCA4A5BF92; Path=/ca; Secure RESPONSE HEADER: Location: https://test.example.com:9445/ca/admin/console/config/wizard RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 RESPONSE HEADER: Content-Length: 0 RESPONSE HEADER: Date: Fri, 30 Apr 2010 21:51:43 GMT RESPONSE HEADER: Connection: keep-alive xml returned: cookie list: JSESSIONID=BED7F647B4BFC9FC8BD9F7BCA4A5BF92; Path=/ca; Secure --- snip --- -- Oliver Burtchen, Berlin