Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 08/08/2012 10:05 PM, Ade Lee wrote: > Hi, > > Dogtag 10 is being released on f18, and has a number of changes that > will affect IPA. In particular, the following changes will affect > current IPA code. > > * The directory layout of the dogtag instance has changed. Instead of > using separate tomcat instances to host different subsystems, the > standard dogtag installation will allow one to install a CA. KRA, OCSP > and TKS within the same instance. There have been corresponding changes > in the directory layout, as well as the default instance name > (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead > of pki-cad, pki-krad etc.) > > * The default instance will use only four ports (HTTPS, HTTP, AJP and > tomcat shutdown port) rather than the 6 previously used. The default > ports will be changed to the standard tomcat ports. As these ports are > local to the ipa server machine, this should not cause too much > disruption. > > * There is a new single step installer written in python. > (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. > > * Dogtag 10 runs on tomcat7 - with a new corresponding version of > tomcatjss. > > The attached patch integrates all the above changes in IPA installation > and maintenance code. Once the patch is applied, users will be able to: > > 1. run ipa-server-install to completion on f18 with dogtag 10. > 2. install a new replica on f18 on dogtag 10. > 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag > 10 - and have that old-style dogtag instance continue to run correctly. > This will require the installation of the latest version of tomcatjss as > well as the installation of tomcat6. The old-style instance will > continue to use tomcat6. > 4. in addition, the new cert renewal code has been patched and should > continue to work. > > What is not yet completed / supported: > > 1. Installation with an external CA is not yet completed in the new > installer. We plan to complete this soon. > > 2. There is some IPA upgrade code that has not yet been touched > (install/tools/ipa-upgradeconfig). > > 3. A script needs to be written to allow admins to convert their > old-style dogtag instances to new style instances, as well as code to > periodically prompt admins to do this. > > 4. Installation of old-style instances using pkicreate/pkisilent on > dogtag 10 will no longer be supported, and will be disabled soon. > > 5. The pki-selinux policy has been updated to reflect these changes, > but is still in flux. In fact, it is our intention to place the dogtag > selinux policy in the base selinux policy for f18. In the meantime, it > may be necessary to run installs in permissive mode. > > The dogtag 10 code will be released shortly into f18. Prior to that > though, we have placed the new dogtag 10 and tomcatjss code in a > developer repo that is located at > http://nkinder.fedorapeople.org/dogtag-devel/ > > Testing can be done on both f18 and f17 - although the target platform - > and the only platform for which official builds will be created is f18. > > Thanks, > Ade > Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable? 3) I had installed IPA with dogtag10 on master. Replica had dogtag10 as well and I got the following error: # ipa-ca-install /home/mkosek/replica-info-vm-114.idm.lab.bos.redhat.com.gpg ... Configuring certificate server: Estimated time 3 minutes 30 seconds [1/14]: creating certificate server user [2/14]: configuring certificate server instance Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Unexpected error - see /var/log/ipareplica-ca-install.log for details: IOError: [Errno 2] No such file or directory: '/var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12' Root cause: ... File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 625, in __spawn_instance "/root/cacert.p12") ... 4) What ports does replica need to be open on the master when installing a CA? Currently, ipa-replica-conncheck does a port check and checks only for 7389, i.e. a port of backend LDAP instan
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: > On 08/08/2012 10:05 PM, Ade Lee wrote: > > Hi, > > > > Dogtag 10 is being released on f18, and has a number of changes that > > will affect IPA. In particular, the following changes will affect > > current IPA code. > > > > * The directory layout of the dogtag instance has changed. Instead of > > using separate tomcat instances to host different subsystems, the > > standard dogtag installation will allow one to install a CA. KRA, OCSP > > and TKS within the same instance. There have been corresponding changes > > in the directory layout, as well as the default instance name > > (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead > > of pki-cad, pki-krad etc.) > > > > * The default instance will use only four ports (HTTPS, HTTP, AJP and > > tomcat shutdown port) rather than the 6 previously used. The default > > ports will be changed to the standard tomcat ports. As these ports are > > local to the ipa server machine, this should not cause too much > > disruption. > > > > * There is a new single step installer written in python. > > (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. > > > > * Dogtag 10 runs on tomcat7 - with a new corresponding version of > > tomcatjss. > > > > The attached patch integrates all the above changes in IPA installation > > and maintenance code. Once the patch is applied, users will be able to: > > > > 1. run ipa-server-install to completion on f18 with dogtag 10. > > 2. install a new replica on f18 on dogtag 10. > > 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag > > 10 - and have that old-style dogtag instance continue to run correctly. > > This will require the installation of the latest version of tomcatjss as > > well as the installation of tomcat6. The old-style instance will > > continue to use tomcat6. > > 4. in addition, the new cert renewal code has been patched and should > > continue to work. > > > > What is not yet completed / supported: > > > > 1. Installation with an external CA is not yet completed in the new > > installer. We plan to complete this soon. > > > > 2. There is some IPA upgrade code that has not yet been touched > > (install/tools/ipa-upgradeconfig). > > > > 3. A script needs to be written to allow admins to convert their > > old-style dogtag instances to new style instances, as well as code to > > periodically prompt admins to do this. > > > > 4. Installation of old-style instances using pkicreate/pkisilent on > > dogtag 10 will no longer be supported, and will be disabled soon. > > > > 5. The pki-selinux policy has been updated to reflect these changes, > > but is still in flux. In fact, it is our intention to place the dogtag > > selinux policy in the base selinux policy for f18. In the meantime, it > > may be necessary to run installs in permissive mode. > > > > The dogtag 10 code will be released shortly into f18. Prior to that > > though, we have placed the new dogtag 10 and tomcatjss code in a > > developer repo that is located at > > http://nkinder.fedorapeople.org/dogtag-devel/ > > > > Testing can be done on both f18 and f17 - although the target platform - > > and the only platform for which official builds will be created is f18. > > > > Thanks, > > Ade > > > > Hi Ade, > > Thanks for the patch, I started with review and integration tests (currently > running on Fedora 17 with Nathan's repo). > > Installation on single master was smooth, it worked just fine, even with > enforced SELinux, without any error - kudos to you and the whole dogtag team. > The resulting logs and the structure of your log directory seems improved. I > believe that the brand new Python installers will make it easier to debug > issues with dogtag installation when they come. When I tried our unit tests > or > some simple cert operation, it worked fine as well. > > Now the bad news, or rather few issues and suggestions I found: > > 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on > Fedora 17 when I updated pki-ca, you somewhere miss a Requires. > We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss >=7.0.0 will be required for f17+, rather than f18+ > 2) I had installed IPA with dogtag10 on master. However, CA installation on a > replica (ipa-ca-install) with dogtag9 failed - is this expectable? > Yes. The current IPA patch is designed to work with dogtag 10 only, which will be officially available on f18+. So if you update to dogtag 10, you must have this patch and visa versa. We probably need to add the relevant requires to IPA to enforce this. If you have an existing dogtag 9 instance, and you upgrade to the new dogtag 10 and patched IPA, then that instance will continue to work. But any new instances would be created using dogtag 10. > 3) I had installed IPA with dogtag10 on master. Replica had dogtag10 as well > and I got the following e
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 08/15/2012 03:54 PM, Ade Lee wrote: > On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: >> On 08/08/2012 10:05 PM, Ade Lee wrote: >>> Hi, >>> >>> Dogtag 10 is being released on f18, and has a number of changes that >>> will affect IPA. In particular, the following changes will affect >>> current IPA code. >>> >>> * The directory layout of the dogtag instance has changed. Instead of >>> using separate tomcat instances to host different subsystems, the >>> standard dogtag installation will allow one to install a CA. KRA, OCSP >>> and TKS within the same instance. There have been corresponding changes >>> in the directory layout, as well as the default instance name >>> (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead >>> of pki-cad, pki-krad etc.) >>> >>> * The default instance will use only four ports (HTTPS, HTTP, AJP and >>> tomcat shutdown port) rather than the 6 previously used. The default >>> ports will be changed to the standard tomcat ports. As these ports are >>> local to the ipa server machine, this should not cause too much >>> disruption. >>> >>> * There is a new single step installer written in python. >>> (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. >>> >>> * Dogtag 10 runs on tomcat7 - with a new corresponding version of >>> tomcatjss. >>> >>> The attached patch integrates all the above changes in IPA installation >>> and maintenance code. Once the patch is applied, users will be able to: >>> >>> 1. run ipa-server-install to completion on f18 with dogtag 10. >>> 2. install a new replica on f18 on dogtag 10. >>> 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag >>> 10 - and have that old-style dogtag instance continue to run correctly. >>> This will require the installation of the latest version of tomcatjss as >>> well as the installation of tomcat6. The old-style instance will >>> continue to use tomcat6. >>> 4. in addition, the new cert renewal code has been patched and should >>> continue to work. >>> >>> What is not yet completed / supported: >>> >>> 1. Installation with an external CA is not yet completed in the new >>> installer. We plan to complete this soon. >>> >>> 2. There is some IPA upgrade code that has not yet been touched >>> (install/tools/ipa-upgradeconfig). >>> >>> 3. A script needs to be written to allow admins to convert their >>> old-style dogtag instances to new style instances, as well as code to >>> periodically prompt admins to do this. >>> >>> 4. Installation of old-style instances using pkicreate/pkisilent on >>> dogtag 10 will no longer be supported, and will be disabled soon. >>> >>> 5. The pki-selinux policy has been updated to reflect these changes, >>> but is still in flux. In fact, it is our intention to place the dogtag >>> selinux policy in the base selinux policy for f18. In the meantime, it >>> may be necessary to run installs in permissive mode. >>> >>> The dogtag 10 code will be released shortly into f18. Prior to that >>> though, we have placed the new dogtag 10 and tomcatjss code in a >>> developer repo that is located at >>> http://nkinder.fedorapeople.org/dogtag-devel/ >>> >>> Testing can be done on both f18 and f17 - although the target platform - >>> and the only platform for which official builds will be created is f18. >>> >>> Thanks, >>> Ade >>> >> >> Hi Ade, >> >> Thanks for the patch, I started with review and integration tests (currently >> running on Fedora 17 with Nathan's repo). >> >> Installation on single master was smooth, it worked just fine, even with >> enforced SELinux, without any error - kudos to you and the whole dogtag team. >> The resulting logs and the structure of your log directory seems improved. I >> believe that the brand new Python installers will make it easier to debug >> issues with dogtag installation when they come. When I tried our unit tests >> or >> some simple cert operation, it worked fine as well. >> >> Now the bad news, or rather few issues and suggestions I found: >> >> 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on >> Fedora 17 when I updated pki-ca, you somewhere miss a Requires. >> > We have a dogtag patch that is currently in review that will address > this. Once this is in, tomcatjss >=7.0.0 will be required for f17+, > rather than f18+ > >> 2) I had installed IPA with dogtag10 on master. However, CA installation on a >> replica (ipa-ca-install) with dogtag9 failed - is this expectable? >> > Yes. The current IPA patch is designed to work with dogtag 10 only, > which will be officially available on f18+. So if you update to dogtag > 10, you must have this patch and visa versa. We probably need to add > the relevant requires to IPA to enforce this. > > If you have an existing dogtag 9 instance, and you upgrade to the new > dogtag 10 and patched IPA, then that instance will continue to work. > But any new instances would be created using dogtag 10. > >> 3) I had installed IPA with dogtag10
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: > On 08/15/2012 03:54 PM, Ade Lee wrote: > > On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: > >> On 08/08/2012 10:05 PM, Ade Lee wrote: > >>> Hi, > >>> > >>> Dogtag 10 is being released on f18, and has a number of changes that > >>> will affect IPA. In particular, the following changes will affect > >>> current IPA code. > >>> > >>> * The directory layout of the dogtag instance has changed. Instead of > >>> using separate tomcat instances to host different subsystems, the > >>> standard dogtag installation will allow one to install a CA. KRA, OCSP > >>> and TKS within the same instance. There have been corresponding changes > >>> in the directory layout, as well as the default instance name > >>> (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead > >>> of pki-cad, pki-krad etc.) > >>> > >>> * The default instance will use only four ports (HTTPS, HTTP, AJP and > >>> tomcat shutdown port) rather than the 6 previously used. The default > >>> ports will be changed to the standard tomcat ports. As these ports are > >>> local to the ipa server machine, this should not cause too much > >>> disruption. > >>> > >>> * There is a new single step installer written in python. > >>> (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. > >>> > >>> * Dogtag 10 runs on tomcat7 - with a new corresponding version of > >>> tomcatjss. > >>> > >>> The attached patch integrates all the above changes in IPA installation > >>> and maintenance code. Once the patch is applied, users will be able to: > >>> > >>> 1. run ipa-server-install to completion on f18 with dogtag 10. > >>> 2. install a new replica on f18 on dogtag 10. > >>> 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag > >>> 10 - and have that old-style dogtag instance continue to run correctly. > >>> This will require the installation of the latest version of tomcatjss as > >>> well as the installation of tomcat6. The old-style instance will > >>> continue to use tomcat6. > >>> 4. in addition, the new cert renewal code has been patched and should > >>> continue to work. > >>> > >>> What is not yet completed / supported: > >>> > >>> 1. Installation with an external CA is not yet completed in the new > >>> installer. We plan to complete this soon. > >>> > >>> 2. There is some IPA upgrade code that has not yet been touched > >>> (install/tools/ipa-upgradeconfig). > >>> > >>> 3. A script needs to be written to allow admins to convert their > >>> old-style dogtag instances to new style instances, as well as code to > >>> periodically prompt admins to do this. > >>> > >>> 4. Installation of old-style instances using pkicreate/pkisilent on > >>> dogtag 10 will no longer be supported, and will be disabled soon. > >>> > >>> 5. The pki-selinux policy has been updated to reflect these changes, > >>> but is still in flux. In fact, it is our intention to place the dogtag > >>> selinux policy in the base selinux policy for f18. In the meantime, it > >>> may be necessary to run installs in permissive mode. > >>> > >>> The dogtag 10 code will be released shortly into f18. Prior to that > >>> though, we have placed the new dogtag 10 and tomcatjss code in a > >>> developer repo that is located at > >>> http://nkinder.fedorapeople.org/dogtag-devel/ > >>> > >>> Testing can be done on both f18 and f17 - although the target platform - > >>> and the only platform for which official builds will be created is f18. > >>> > >>> Thanks, > >>> Ade > >>> > >> > >> Hi Ade, > >> > >> Thanks for the patch, I started with review and integration tests > >> (currently > >> running on Fedora 17 with Nathan's repo). > >> > >> Installation on single master was smooth, it worked just fine, even with > >> enforced SELinux, without any error - kudos to you and the whole dogtag > >> team. > >> The resulting logs and the structure of your log directory seems improved. > >> I > >> believe that the brand new Python installers will make it easier to debug > >> issues with dogtag installation when they come. When I tried our unit > >> tests or > >> some simple cert operation, it worked fine as well. > >> > >> Now the bad news, or rather few issues and suggestions I found: > >> > >> 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on > >> Fedora 17 when I updated pki-ca, you somewhere miss a Requires. > >> > > We have a dogtag patch that is currently in review that will address > > this. Once this is in, tomcatjss >=7.0.0 will be required for f17+, > > rather than f18+ > > > >> 2) I had installed IPA with dogtag10 on master. However, CA installation > >> on a > >> replica (ipa-ca-install) with dogtag9 failed - is this expectable? > >> > > Yes. The current IPA patch is designed to work with dogtag 10 only, > > which will be officially available on f18+. So if you update to dogtag > > 10, you must have this patch and visa versa. We probably need to add > > the rele
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: > On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: > > On 08/15/2012 03:54 PM, Ade Lee wrote: > > > On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: > > >> On 08/08/2012 10:05 PM, Ade Lee wrote: > > >>> Hi, > > >>> > > >>> Dogtag 10 is being released on f18, and has a number of changes that > > >>> will affect IPA. In particular, the following changes will affect > > >>> current IPA code. > > >>> > > >>> * The directory layout of the dogtag instance has changed. Instead of > > >>> using separate tomcat instances to host different subsystems, the > > >>> standard dogtag installation will allow one to install a CA. KRA, OCSP > > >>> and TKS within the same instance. There have been corresponding changes > > >>> in the directory layout, as well as the default instance name > > >>> (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead > > >>> of pki-cad, pki-krad etc.) > > >>> > > >>> * The default instance will use only four ports (HTTPS, HTTP, AJP and > > >>> tomcat shutdown port) rather than the 6 previously used. The default > > >>> ports will be changed to the standard tomcat ports. As these ports are > > >>> local to the ipa server machine, this should not cause too much > > >>> disruption. > > >>> > > >>> * There is a new single step installer written in python. > > >>> (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. > > >>> > > >>> * Dogtag 10 runs on tomcat7 - with a new corresponding version of > > >>> tomcatjss. > > >>> > > >>> The attached patch integrates all the above changes in IPA installation > > >>> and maintenance code. Once the patch is applied, users will be able to: > > >>> > > >>> 1. run ipa-server-install to completion on f18 with dogtag 10. > > >>> 2. install a new replica on f18 on dogtag 10. > > >>> 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag > > >>> 10 - and have that old-style dogtag instance continue to run correctly. > > >>> This will require the installation of the latest version of tomcatjss as > > >>> well as the installation of tomcat6. The old-style instance will > > >>> continue to use tomcat6. > > >>> 4. in addition, the new cert renewal code has been patched and should > > >>> continue to work. > > >>> > > >>> What is not yet completed / supported: > > >>> > > >>> 1. Installation with an external CA is not yet completed in the new > > >>> installer. We plan to complete this soon. > > >>> > > >>> 2. There is some IPA upgrade code that has not yet been touched > > >>> (install/tools/ipa-upgradeconfig). > > >>> > > >>> 3. A script needs to be written to allow admins to convert their > > >>> old-style dogtag instances to new style instances, as well as code to > > >>> periodically prompt admins to do this. > > >>> > > >>> 4. Installation of old-style instances using pkicreate/pkisilent on > > >>> dogtag 10 will no longer be supported, and will be disabled soon. > > >>> > > >>> 5. The pki-selinux policy has been updated to reflect these changes, > > >>> but is still in flux. In fact, it is our intention to place the dogtag > > >>> selinux policy in the base selinux policy for f18. In the meantime, it > > >>> may be necessary to run installs in permissive mode. > > >>> > > >>> The dogtag 10 code will be released shortly into f18. Prior to that > > >>> though, we have placed the new dogtag 10 and tomcatjss code in a > > >>> developer repo that is located at > > >>> http://nkinder.fedorapeople.org/dogtag-devel/ > > >>> > > >>> Testing can be done on both f18 and f17 - although the target platform - > > >>> and the only platform for which official builds will be created is f18. > > >>> > > >>> Thanks, > > >>> Ade > > >>> > > >> > > >> Hi Ade, > > >> > > >> Thanks for the patch, I started with review and integration tests > > >> (currently > > >> running on Fedora 17 with Nathan's repo). > > >> > > >> Installation on single master was smooth, it worked just fine, even with > > >> enforced SELinux, without any error - kudos to you and the whole dogtag > > >> team. > > >> The resulting logs and the structure of your log directory seems > > >> improved. I > > >> believe that the brand new Python installers will make it easier to debug > > >> issues with dogtag installation when they come. When I tried our unit > > >> tests or > > >> some simple cert operation, it worked fine as well. > > >> > > >> Now the bad news, or rather few issues and suggestions I found: > > >> > > >> 1) As we already discussed on IRC, tomcat 7 was not pulled automatically > > >> on > > >> Fedora 17 when I updated pki-ca, you somewhere miss a Requires. > > >> > > > We have a dogtag patch that is currently in review that will address > > > this. Once this is in, tomcatjss >=7.0.0 will be required for f17+, > > > rather than f18+ > > > > > >> 2) I had installed IPA with dogtag10 on master. However, CA installation > > >> on a > > >> replica (ipa-ca-install) with dogtag9 faile
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 08/16/2012 05:41 AM, Ade Lee wrote: > On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: .. 3) I had installed IPA with dogtag10 on master. Replica had dogtag10 as well and I got the following error: # ipa-ca-install /home/mkosek/replica-info-vm-114.idm.lab.bos.redhat.com.gpg ... Configuring certificate server: Estimated time 3 minutes 30 seconds [1/14]: creating certificate server user [2/14]: configuring certificate server instance Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Unexpected error - see /var/log/ipareplica-ca-install.log for details: IOError: [Errno 2] No such file or directory: '/var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12' Root cause: ... File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 625, in __spawn_instance "/root/cacert.p12") ... >>> I need to look into this. I had fixed ipa-replica-install, rather than >>> ipa-ca-install to create replicas. I didn't know ipa-ca-install >>> existed! Should not be too bad to fix though - most likely just need to >>> move files to the right place. >> >> Ok, thanks! Btw. CA on replica can be either installed during >> ipa-replica-install time (when --setup-ca option is passed, you probably used >> that one) and the aforementioned ipa-ca-install run after >> ipa-replica-install. >> > I will be testing this out again. As ipa-ca-install uses the same code > as ipa-replica-install, I would have expected it to work. Did you try > it with selinux in permissive mode? I had SELinux en enforcing mode. ipa-server-install with SELinux worked fine, so I thought that replica installation will work fine too. I will re-test with SELinux turned off. ... >> 7) pki-deploy package does not require any other pki-* package, this does not >> look ok. This way I was able to have pki-ca-9.* and pki-deploy-10.* installed >> at one time. I doubt it would work that way. >> > We have opened a dogtag ticket to address this. Some kind of dependency > will be added so that pki-deploy and pki-common-10 are co-dependencies. > >> 8) Did you test upgrade from installed IPA+dogtag9 to patchedIPA+dogtag10? I >> did that on Fedora 17 and pki-ca did not start after upgrade. Attaching logs >> my >> VM after I tried to (re)start pki-ca. >> > I did test this. From the logs though, this looks very much like it is > not starting because of selinux. Can you try to restart with selinux > permissive? I fully expect there to be selinux issues here as some > changes are required in the base policy where the default ports are > defined. > Ok then. I will test it with permissive SELinux as well. Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 08/16/2012 07:53 AM, Ade Lee wrote: > On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: >> On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: >>> On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: > On 08/08/2012 10:05 PM, Ade Lee wrote: >> Hi, >> >> Dogtag 10 is being released on f18, and has a number of changes that >> will affect IPA. In particular, the following changes will affect >> current IPA code. >> >> * The directory layout of the dogtag instance has changed. Instead of >> using separate tomcat instances to host different subsystems, the >> standard dogtag installation will allow one to install a CA. KRA, OCSP >> and TKS within the same instance. There have been corresponding changes >> in the directory layout, as well as the default instance name >> (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead >> of pki-cad, pki-krad etc.) >> >> * The default instance will use only four ports (HTTPS, HTTP, AJP and >> tomcat shutdown port) rather than the 6 previously used. The default >> ports will be changed to the standard tomcat ports. As these ports are >> local to the ipa server machine, this should not cause too much >> disruption. >> >> * There is a new single step installer written in python. >> (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. >> >> * Dogtag 10 runs on tomcat7 - with a new corresponding version of >> tomcatjss. >> >> The attached patch integrates all the above changes in IPA installation >> and maintenance code. Once the patch is applied, users will be able to: >> >> 1. run ipa-server-install to completion on f18 with dogtag 10. >> 2. install a new replica on f18 on dogtag 10. >> 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag >> 10 - and have that old-style dogtag instance continue to run correctly. >> This will require the installation of the latest version of tomcatjss as >> well as the installation of tomcat6. The old-style instance will >> continue to use tomcat6. >> 4. in addition, the new cert renewal code has been patched and should >> continue to work. >> >> What is not yet completed / supported: >> >> 1. Installation with an external CA is not yet completed in the new >> installer. We plan to complete this soon. >> >> 2. There is some IPA upgrade code that has not yet been touched >> (install/tools/ipa-upgradeconfig). >> >> 3. A script needs to be written to allow admins to convert their >> old-style dogtag instances to new style instances, as well as code to >> periodically prompt admins to do this. >> >> 4. Installation of old-style instances using pkicreate/pkisilent on >> dogtag 10 will no longer be supported, and will be disabled soon. >> >> 5. The pki-selinux policy has been updated to reflect these changes, >> but is still in flux. In fact, it is our intention to place the dogtag >> selinux policy in the base selinux policy for f18. In the meantime, it >> may be necessary to run installs in permissive mode. >> >> The dogtag 10 code will be released shortly into f18. Prior to that >> though, we have placed the new dogtag 10 and tomcatjss code in a >> developer repo that is located at >> http://nkinder.fedorapeople.org/dogtag-devel/ >> >> Testing can be done on both f18 and f17 - although the target platform - >> and the only platform for which official builds will be created is f18. >> >> Thanks, >> Ade >> > > Hi Ade, > > Thanks for the patch, I started with review and integration tests > (currently > running on Fedora 17 with Nathan's repo). > > Installation on single master was smooth, it worked just fine, even with > enforced SELinux, without any error - kudos to you and the whole dogtag > team. > The resulting logs and the structure of your log directory seems > improved. I > believe that the brand new Python installers will make it easier to debug > issues with dogtag installation when they come. When I tried our unit > tests or > some simple cert operation, it worked fine as well. > > Now the bad news, or rather few issues and suggestions I found: > > 1) As we already discussed on IRC, tomcat 7 was not pulled automatically > on > Fedora 17 when I updated pki-ca, you somewhere miss a Requires. > We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss >=7.0.0 will be required for f17+, rather than f18+ > 2) I had installed IPA with dogtag10 on master. However, CA installation > on a > replica (ipa-ca-install) with dogtag9 failed - is this expectable? > Yes. The current IPA patc
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Patch attached this time. I should know better than to do this in the middle of the night .. On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: > On 08/16/2012 07:53 AM, Ade Lee wrote: > > On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: > >> On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: > >>> On 08/15/2012 03:54 PM, Ade Lee wrote: > On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: > > On 08/08/2012 10:05 PM, Ade Lee wrote: > >> Hi, > >> > >> Dogtag 10 is being released on f18, and has a number of changes that > >> will affect IPA. In particular, the following changes will affect > >> current IPA code. > >> > >> * The directory layout of the dogtag instance has changed. Instead of > >> using separate tomcat instances to host different subsystems, the > >> standard dogtag installation will allow one to install a CA. KRA, OCSP > >> and TKS within the same instance. There have been corresponding > >> changes > >> in the directory layout, as well as the default instance name > >> (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, > >> instead > >> of pki-cad, pki-krad etc.) > >> > >> * The default instance will use only four ports (HTTPS, HTTP, AJP and > >> tomcat shutdown port) rather than the 6 previously used. The default > >> ports will be changed to the standard tomcat ports. As these ports are > >> local to the ipa server machine, this should not cause too much > >> disruption. > >> > >> * There is a new single step installer written in python. > >> (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. > >> > >> * Dogtag 10 runs on tomcat7 - with a new corresponding version of > >> tomcatjss. > >> > >> The attached patch integrates all the above changes in IPA installation > >> and maintenance code. Once the patch is applied, users will be able > >> to: > >> > >> 1. run ipa-server-install to completion on f18 with dogtag 10. > >> 2. install a new replica on f18 on dogtag 10. > >> 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag > >> 10 - and have that old-style dogtag instance continue to run correctly. > >> This will require the installation of the latest version of tomcatjss > >> as > >> well as the installation of tomcat6. The old-style instance will > >> continue to use tomcat6. > >> 4. in addition, the new cert renewal code has been patched and should > >> continue to work. > >> > >> What is not yet completed / supported: > >> > >> 1. Installation with an external CA is not yet completed in the new > >> installer. We plan to complete this soon. > >> > >> 2. There is some IPA upgrade code that has not yet been touched > >> (install/tools/ipa-upgradeconfig). > >> > >> 3. A script needs to be written to allow admins to convert their > >> old-style dogtag instances to new style instances, as well as code to > >> periodically prompt admins to do this. > >> > >> 4. Installation of old-style instances using pkicreate/pkisilent on > >> dogtag 10 will no longer be supported, and will be disabled soon. > >> > >> 5. The pki-selinux policy has been updated to reflect these changes, > >> but is still in flux. In fact, it is our intention to place the dogtag > >> selinux policy in the base selinux policy for f18. In the meantime, it > >> may be necessary to run installs in permissive mode. > >> > >> The dogtag 10 code will be released shortly into f18. Prior to that > >> though, we have placed the new dogtag 10 and tomcatjss code in a > >> developer repo that is located at > >> http://nkinder.fedorapeople.org/dogtag-devel/ > >> > >> Testing can be done on both f18 and f17 - although the target platform > >> - > >> and the only platform for which official builds will be created is f18. > >> > >> Thanks, > >> Ade > >> > > > > Hi Ade, > > > > Thanks for the patch, I started with review and integration tests > > (currently > > running on Fedora 17 with Nathan's repo). > > > > Installation on single master was smooth, it worked just fine, even with > > enforced SELinux, without any error - kudos to you and the whole dogtag > > team. > > The resulting logs and the structure of your log directory seems > > improved. I > > believe that the brand new Python installers will make it easier to > > debug > > issues with dogtag installation when they come. When I tried our unit > > tests or > > some simple cert operation, it worked fine as well. > > > > Now the bad news, or rather few issues and suggestions I found: > > > > 1) As we already discussed on IRC, tomcat 7 was not pulled > > automatically on > > Fedora 17 when I updated pki-ca, you some
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: > On 08/16/2012 01:28 PM, Ade Lee wrote: > > Patch attached this time. I should know better than to do this in the > > middle of the night .. > > > > On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: > >> On 08/16/2012 07:53 AM, Ade Lee wrote: > >>> On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: > On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: > > On 08/15/2012 03:54 PM, Ade Lee wrote: > >> On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: > >>> On 08/08/2012 10:05 PM, Ade Lee wrote: > Hi, > > Dogtag 10 is being released on f18, and has a number of changes that > will affect IPA. In particular, the following changes will affect > current IPA code. > > * The directory layout of the dogtag instance has changed. Instead > of > using separate tomcat instances to host different subsystems, the > standard dogtag installation will allow one to install a CA. KRA, > OCSP > and TKS within the same instance. There have been corresponding > changes > in the directory layout, as well as the default instance name > (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, > instead > of pki-cad, pki-krad etc.) > > * The default instance will use only four ports (HTTPS, HTTP, AJP and > tomcat shutdown port) rather than the 6 previously used. The default > ports will be changed to the standard tomcat ports. As these ports > are > local to the ipa server machine, this should not cause too much > disruption. > > * There is a new single step installer written in python. > (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. > > * Dogtag 10 runs on tomcat7 - with a new corresponding version of > tomcatjss. > > The attached patch integrates all the above changes in IPA > installation > and maintenance code. Once the patch is applied, users will be able > to: > > 1. run ipa-server-install to completion on f18 with dogtag 10. > 2. install a new replica on f18 on dogtag 10. > 3. upgrade an f17 machine with an existing IPA instance to f18/ > dogtag > 10 - and have that old-style dogtag instance continue to run > correctly. > This will require the installation of the latest version of > tomcatjss as > well as the installation of tomcat6. The old-style instance will > continue to use tomcat6. > 4. in addition, the new cert renewal code has been patched and should > continue to work. > > What is not yet completed / supported: > > 1. Installation with an external CA is not yet completed in the new > installer. We plan to complete this soon. > > 2. There is some IPA upgrade code that has not yet been touched > (install/tools/ipa-upgradeconfig). > > 3. A script needs to be written to allow admins to convert their > old-style dogtag instances to new style instances, as well as code to > periodically prompt admins to do this. > > 4. Installation of old-style instances using pkicreate/pkisilent on > dogtag 10 will no longer be supported, and will be disabled soon. > > 5. The pki-selinux policy has been updated to reflect these changes, > but is still in flux. In fact, it is our intention to place the > dogtag > selinux policy in the base selinux policy for f18. In the meantime, > it > may be necessary to run installs in permissive mode. > > The dogtag 10 code will be released shortly into f18. Prior to that > though, we have placed the new dogtag 10 and tomcatjss code in a > developer repo that is located at > http://nkinder.fedorapeople.org/dogtag-devel/ > > Testing can be done on both f18 and f17 - although the target > platform - > and the only platform for which official builds will be created is > f18. > > Thanks, > Ade > > >>> > >>> Hi Ade, > >>> > >>> Thanks for the patch, I started with review and integration tests > >>> (currently > >>> running on Fedora 17 with Nathan's repo). > >>> > >>> Installation on single master was smooth, it worked just fine, even > >>> with > >>> enforced SELinux, without any error - kudos to you and the whole > >>> dogtag team. > >>> The resulting logs and the structure of your log directory seems > >>> improved. I > >>> believe that the brand new Python installers will
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: > On 08/16/2012 01:28 PM, Ade Lee wrote: > > Patch attached this time. I should know better than to do this in the > > middle of the night .. > > > > On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: > >> On 08/16/2012 07:53 AM, Ade Lee wrote: > >>> On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: > On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: > > On 08/15/2012 03:54 PM, Ade Lee wrote: > >> On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: > >>> On 08/08/2012 10:05 PM, Ade Lee wrote: > Hi, > > Dogtag 10 is being released on f18, and has a number of changes that > will affect IPA. In particular, the following changes will affect > current IPA code. > > * The directory layout of the dogtag instance has changed. Instead > of > using separate tomcat instances to host different subsystems, the > standard dogtag installation will allow one to install a CA. KRA, > OCSP > and TKS within the same instance. There have been corresponding > changes > in the directory layout, as well as the default instance name > (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, > instead > of pki-cad, pki-krad etc.) > > * The default instance will use only four ports (HTTPS, HTTP, AJP and > tomcat shutdown port) rather than the 6 previously used. The default > ports will be changed to the standard tomcat ports. As these ports > are > local to the ipa server machine, this should not cause too much > disruption. > > * There is a new single step installer written in python. > (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. > > * Dogtag 10 runs on tomcat7 - with a new corresponding version of > tomcatjss. > > The attached patch integrates all the above changes in IPA > installation > and maintenance code. Once the patch is applied, users will be able > to: > > 1. run ipa-server-install to completion on f18 with dogtag 10. > 2. install a new replica on f18 on dogtag 10. > 3. upgrade an f17 machine with an existing IPA instance to f18/ > dogtag > 10 - and have that old-style dogtag instance continue to run > correctly. > This will require the installation of the latest version of > tomcatjss as > well as the installation of tomcat6. The old-style instance will > continue to use tomcat6. > 4. in addition, the new cert renewal code has been patched and should > continue to work. > > What is not yet completed / supported: > > 1. Installation with an external CA is not yet completed in the new > installer. We plan to complete this soon. > > 2. There is some IPA upgrade code that has not yet been touched > (install/tools/ipa-upgradeconfig). > > 3. A script needs to be written to allow admins to convert their > old-style dogtag instances to new style instances, as well as code to > periodically prompt admins to do this. > > 4. Installation of old-style instances using pkicreate/pkisilent on > dogtag 10 will no longer be supported, and will be disabled soon. > > 5. The pki-selinux policy has been updated to reflect these changes, > but is still in flux. In fact, it is our intention to place the > dogtag > selinux policy in the base selinux policy for f18. In the meantime, > it > may be necessary to run installs in permissive mode. > > The dogtag 10 code will be released shortly into f18. Prior to that > though, we have placed the new dogtag 10 and tomcatjss code in a > developer repo that is located at > http://nkinder.fedorapeople.org/dogtag-devel/ > > Testing can be done on both f18 and f17 - although the target > platform - > and the only platform for which official builds will be created is > f18. > > Thanks, > Ade > > >>> > >>> Hi Ade, > >>> > >>> Thanks for the patch, I started with review and integration tests > >>> (currently > >>> running on Fedora 17 with Nathan's repo). > >>> > >>> Installation on single master was smooth, it worked just fine, even > >>> with > >>> enforced SELinux, without any error - kudos to you and the whole > >>> dogtag team. > >>> The resulting logs and the structure of your log directory seems > >>> improved. I > >>> believe that the brand new Python installers will
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Fri, 2012-08-17 at 09:34 -0400, Ade Lee wrote: > On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: > > On 08/16/2012 01:28 PM, Ade Lee wrote: > > > Patch attached this time. I should know better than to do this in the > > > middle of the night .. > > > > > > On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: > > >> On 08/16/2012 07:53 AM, Ade Lee wrote: > > >>> On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: > > On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: > > > On 08/15/2012 03:54 PM, Ade Lee wrote: > > >> On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: > > >>> On 08/08/2012 10:05 PM, Ade Lee wrote: > > Hi, > > > > Dogtag 10 is being released on f18, and has a number of changes > > that > > will affect IPA. In particular, the following changes will affect > > current IPA code. > > > > * The directory layout of the dogtag instance has changed. > > Instead of > > using separate tomcat instances to host different subsystems, the > > standard dogtag installation will allow one to install a CA. KRA, > > OCSP > > and TKS within the same instance. There have been corresponding > > changes > > in the directory layout, as well as the default instance name > > (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, > > instead > > of pki-cad, pki-krad etc.) > > > > * The default instance will use only four ports (HTTPS, HTTP, AJP > > and > > tomcat shutdown port) rather than the 6 previously used. The > > default > > ports will be changed to the standard tomcat ports. As these > > ports are > > local to the ipa server machine, this should not cause too much > > disruption. > > > > * There is a new single step installer written in python. > > (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. > > > > * Dogtag 10 runs on tomcat7 - with a new corresponding version of > > tomcatjss. > > > > The attached patch integrates all the above changes in IPA > > installation > > and maintenance code. Once the patch is applied, users will be > > able to: > > > > 1. run ipa-server-install to completion on f18 with dogtag 10. > > 2. install a new replica on f18 on dogtag 10. > > 3. upgrade an f17 machine with an existing IPA instance to f18/ > > dogtag > > 10 - and have that old-style dogtag instance continue to run > > correctly. > > This will require the installation of the latest version of > > tomcatjss as > > well as the installation of tomcat6. The old-style instance will > > continue to use tomcat6. > > 4. in addition, the new cert renewal code has been patched and > > should > > continue to work. > > > > What is not yet completed / supported: > > > > 1. Installation with an external CA is not yet completed in the new > > installer. We plan to complete this soon. > > > > 2. There is some IPA upgrade code that has not yet been touched > > (install/tools/ipa-upgradeconfig). > > > > 3. A script needs to be written to allow admins to convert their > > old-style dogtag instances to new style instances, as well as code > > to > > periodically prompt admins to do this. > > > > 4. Installation of old-style instances using pkicreate/pkisilent on > > dogtag 10 will no longer be supported, and will be disabled soon. > > > > 5. The pki-selinux policy has been updated to reflect these > > changes, > > but is still in flux. In fact, it is our intention to place the > > dogtag > > selinux policy in the base selinux policy for f18. In the > > meantime, it > > may be necessary to run installs in permissive mode. > > > > The dogtag 10 code will be released shortly into f18. Prior to > > that > > though, we have placed the new dogtag 10 and tomcatjss code in a > > developer repo that is located at > > http://nkinder.fedorapeople.org/dogtag-devel/ > > > > Testing can be done on both f18 and f17 - although the target > > platform - > > and the only platform for which official builds will be created is > > f18. > > > > Thanks, > > Ade > > > > >>> > > >>> Hi Ade, > > >>> > > >>> Thanks for the patch, I started with review and integration tests > > >>> (currently > > >>> running on Fedora 17 with Nathan's repo). > > >
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Ade Lee wrote: On Fri, 2012-08-17 at 09:34 -0400, Ade Lee wrote: On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: On 08/16/2012 01:28 PM, Ade Lee wrote: Patch attached this time. I should know better than to do this in the middle of the night .. On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: On 08/16/2012 07:53 AM, Ade Lee wrote: On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss >=7.0.0 will be required for f17+, rather than f18+ 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable? Yes. The current IPA patch is designed to work with dogtag 10 only, which will be officially available on f18+. So if you update to dogtag 10, you must have this patch and visa versa. We probably need to add the relevant requires to IPA to enforce this. If you have an existing dogtag 9 instance, and you upgrade to the new dogtag 10 and patched IPA, then that instance will contin
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 08/17/2012 12:06 PM, Rob Crittenden wrote: > Ade Lee wrote: >> On Fri, 2012-08-17 at 09:34 -0400, Ade Lee wrote: >>> On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: On 08/16/2012 01:28 PM, Ade Lee wrote: > Patch attached this time. I should know better than to do this in > the > middle of the night .. > > On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: >> On 08/16/2012 07:53 AM, Ade Lee wrote: >>> On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: > On 08/15/2012 03:54 PM, Ade Lee wrote: >> On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: >>> On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade >>> >>>
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 08/27/2012 02:39 PM, Dmitri Pal wrote: On 08/17/2012 12:06 PM, Rob Crittenden wrote: Ade Lee wrote: On Fri, 2012-08-17 at 09:34 -0400, Ade Lee wrote: On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: On 08/16/2012 01:28 PM, Ade Lee wrote: Patch attached this time. I should know better than to do this in the middle of the night .. On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: On 08/16/2012 07:53 AM, Ade Lee wrote: On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss >=7.0.0 will be required for f17+, rather than f18+ 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable? Yes. The current IPA patch is designed to work with dogtag 10 only, which will be officially available on f18+. So if you update to dogtag 10, you must have this patch and visa versa. We probably need to add the relevant requires to IPA to enforce this. If you have an existing dogtag 9 instanc
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Petr Viktorin wrote: On 08/27/2012 02:39 PM, Dmitri Pal wrote: On 08/17/2012 12:06 PM, Rob Crittenden wrote: Ade Lee wrote: On Fri, 2012-08-17 at 09:34 -0400, Ade Lee wrote: On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: On 08/16/2012 01:28 PM, Ade Lee wrote: Patch attached this time. I should know better than to do this in the middle of the night .. On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: On 08/16/2012 07:53 AM, Ade Lee wrote: On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss >=7.0.0 will be required for f17+, rather than f18+ 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable? Yes. The current IPA patch is designed to work with dogtag 10 only, which will be officially available on f18+. So if you update to dogtag 10, you must have this patch and visa versa. We probably need to add the relevant requires to IPA to enforce this. If you have an exi
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
I have not opened a certmonger bug, but here is a patch to fix the relevant code in certmonger. Nalin, please review and commit. I tested by renewing one of the dogtag system certs (the ocsp signing cert) Ade On Mon, 2012-08-27 at 09:40 -0400, Rob Crittenden wrote: > Petr Viktorin wrote: > > On 08/27/2012 02:39 PM, Dmitri Pal wrote: > >> On 08/17/2012 12:06 PM, Rob Crittenden wrote: > >>> Ade Lee wrote: > On Fri, 2012-08-17 at 09:34 -0400, Ade Lee wrote: > > On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: > >> On 08/16/2012 01:28 PM, Ade Lee wrote: > >>> Patch attached this time. I should know better than to do this in > >>> the > >>> middle of the night .. > >>> > >>> On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: > On 08/16/2012 07:53 AM, Ade Lee wrote: > > On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: > >> On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: > >>> On 08/15/2012 03:54 PM, Ade Lee wrote: > On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: > > On 08/08/2012 10:05 PM, Ade Lee wrote: > >> Hi, > >> > >> Dogtag 10 is being released on f18, and has a number of > >> changes that > >> will affect IPA. In particular, the following changes will > >> affect > >> current IPA code. > >> > >> * The directory layout of the dogtag instance has changed. > >> Instead of > >> using separate tomcat instances to host different > >> subsystems, the > >> standard dogtag installation will allow one to install a > >> CA. KRA, OCSP > >> and TKS within the same instance. There have been > >> corresponding changes > >> in the directory layout, as well as the default instance name > >> (pki-tomcat instead of pki-ca), and startup daemon > >> (pki-tomcatd, instead > >> of pki-cad, pki-krad etc.) > >> > >> * The default instance will use only four ports (HTTPS, > >> HTTP, AJP and > >> tomcat shutdown port) rather than the 6 previously used. > >> The default > >> ports will be changed to the standard tomcat ports. As > >> these ports are > >> local to the ipa server machine, this should not cause too > >> much > >> disruption. > >> > >> * There is a new single step installer written in python. > >> (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. > >> > >> * Dogtag 10 runs on tomcat7 - with a new corresponding > >> version of > >> tomcatjss. > >> > >> The attached patch integrates all the above changes in IPA > >> installation > >> and maintenance code. Once the patch is applied, users > >> will be able to: > >> > >> 1. run ipa-server-install to completion on f18 with dogtag > >> 10. > >> 2. install a new replica on f18 on dogtag 10. > >> 3. upgrade an f17 machine with an existing IPA instance to > >> f18/ dogtag > >> 10 - and have that old-style dogtag instance continue to > >> run correctly. > >> This will require the installation of the latest version of > >> tomcatjss as > >> well as the installation of tomcat6. The old-style > >> instance will > >> continue to use tomcat6. > >> 4. in addition, the new cert renewal code has been patched > >> and should > >> continue to work. > >> > >> What is not yet completed / supported: > >> > >> 1. Installation with an external CA is not yet completed in > >> the new > >> installer. We plan to complete this soon. > >> > >> 2. There is some IPA upgrade code that has not yet been > >> touched > >> (install/tools/ipa-upgradeconfig). > >> > >> 3. A script needs to be written to allow admins to convert > >> their > >> old-style dogtag instances to new style instances, as well > >> as code to > >> periodically prompt admins to do this. > >> > >> 4. Installation of old-style instances using > >> pkicreate/pkisilent on > >> dogtag 10 will no longer be supported, and will be disabled > >> soon. > >> > >> 5. The pki-selinux policy has been updated to reflect > >> these changes, > >> but is still in flux. In fact, it is our intention to > >> place the dogtag > >
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Incidentally, I ran this in permmissive selinux mode. The following rules are required to be added: #= certmonger_t == corenet_tcp_connect_http_cache_port(certmonger_t) files_read_var_lib_symlinks(certmonger_t) On Tue, 2012-08-28 at 23:53 -0400, Ade Lee wrote: > I have not opened a certmonger bug, but here is a patch to fix the > relevant code in certmonger. > > Nalin, please review and commit. > > I tested by renewing one of the dogtag system certs (the ocsp signing > cert) > > Ade > > On Mon, 2012-08-27 at 09:40 -0400, Rob Crittenden wrote: > > Petr Viktorin wrote: > > > On 08/27/2012 02:39 PM, Dmitri Pal wrote: > > >> On 08/17/2012 12:06 PM, Rob Crittenden wrote: > > >>> Ade Lee wrote: > > On Fri, 2012-08-17 at 09:34 -0400, Ade Lee wrote: > > > On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: > > >> On 08/16/2012 01:28 PM, Ade Lee wrote: > > >>> Patch attached this time. I should know better than to do this in > > >>> the > > >>> middle of the night .. > > >>> > > >>> On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: > > On 08/16/2012 07:53 AM, Ade Lee wrote: > > > On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: > > >> On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: > > >>> On 08/15/2012 03:54 PM, Ade Lee wrote: > > On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: > > > On 08/08/2012 10:05 PM, Ade Lee wrote: > > >> Hi, > > >> > > >> Dogtag 10 is being released on f18, and has a number of > > >> changes that > > >> will affect IPA. In particular, the following changes will > > >> affect > > >> current IPA code. > > >> > > >> * The directory layout of the dogtag instance has changed. > > >> Instead of > > >> using separate tomcat instances to host different > > >> subsystems, the > > >> standard dogtag installation will allow one to install a > > >> CA. KRA, OCSP > > >> and TKS within the same instance. There have been > > >> corresponding changes > > >> in the directory layout, as well as the default instance name > > >> (pki-tomcat instead of pki-ca), and startup daemon > > >> (pki-tomcatd, instead > > >> of pki-cad, pki-krad etc.) > > >> > > >> * The default instance will use only four ports (HTTPS, > > >> HTTP, AJP and > > >> tomcat shutdown port) rather than the 6 previously used. > > >> The default > > >> ports will be changed to the standard tomcat ports. As > > >> these ports are > > >> local to the ipa server machine, this should not cause too > > >> much > > >> disruption. > > >> > > >> * There is a new single step installer written in python. > > >> (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. > > >> > > >> * Dogtag 10 runs on tomcat7 - with a new corresponding > > >> version of > > >> tomcatjss. > > >> > > >> The attached patch integrates all the above changes in IPA > > >> installation > > >> and maintenance code. Once the patch is applied, users > > >> will be able to: > > >> > > >> 1. run ipa-server-install to completion on f18 with dogtag > > >> 10. > > >> 2. install a new replica on f18 on dogtag 10. > > >> 3. upgrade an f17 machine with an existing IPA instance to > > >> f18/ dogtag > > >> 10 - and have that old-style dogtag instance continue to > > >> run correctly. > > >> This will require the installation of the latest version of > > >> tomcatjss as > > >> well as the installation of tomcat6. The old-style > > >> instance will > > >> continue to use tomcat6. > > >> 4. in addition, the new cert renewal code has been patched > > >> and should > > >> continue to work. > > >> > > >> What is not yet completed / supported: > > >> > > >> 1. Installation with an external CA is not yet completed in > > >> the new > > >> installer. We plan to complete this soon. > > >> > > >> 2. There is some IPA upgrade code that has not yet been > > >> touched > > >> (install/tools/ipa-upgradeconfig). > > >> > > >> 3. A script needs to be written to allow admins to convert > > >> their > > >> old-style dogtag instances to new style instances, as well > > >> as code to > > >> pe
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 28.08.2012 16:40, Petr Viktorin wrote: > On 08/17/2012 06:04 PM, Ade Lee wrote: >> On Fri, 2012-08-17 at 09:34 -0400, Ade Lee wrote: >>> On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: On 08/16/2012 01:28 PM, Ade Lee wrote: > Patch attached this time. I should know better than to do this in the > middle of the night .. > > On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: >> On 08/16/2012 07:53 AM, Ade Lee wrote: >>> On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: > On 08/15/2012 03:54 PM, Ade Lee wrote: >> On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: >>> On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade >>> >>> Hi Ade,
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Martin Kosek wrote: On 08/31/2012 04:53 PM, Petr Viktorin wrote: On 08/28/2012 03:40 PM, Petr Viktorin wrote: On 08/17/2012 06:04 PM, Ade Lee wrote: On Fri, 2012-08-17 at 09:34 -0400, Ade Lee wrote: On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: On 08/16/2012 01:28 PM, Ade Lee wrote: Patch attached this time. I should know better than to do this in the middle of the night .. On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: On 08/16/2012 07:53 AM, Ade Lee wrote: On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss >=7.0.0 will be required for f17+, rather than f18+ 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable? Yes. The current IPA patch is designed to work with dogtag 10 only, which will be officially available on f18+. So if you update to dogtag 10, you must have this patch and visa versa. We probably need to add the relevant requires to IPA to enforce
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, Aug 29, 2012 at 08:48:32AM -0400, Ade Lee wrote: > Incidentally, I ran this in permmissive selinux mode. The following > rules are required to be added: > > #= certmonger_t == > corenet_tcp_connect_http_cache_port(certmonger_t) > files_read_var_lib_symlinks(certmonger_t) On my system, "semanage port -l" shows me: http_cache_port_t tcp 8080, 8118, 10001-10010 Are these ports already labeled this way for Dogtag, or is it a coincidental overlap with some other package? If it's an overlap, it might be better to switch to using ports which aren't already labeled for use in policy that applies to some other package. If not, please open a bug against the selinux-policy component to get these accesses added to the set that's allowed by the default policy. Nalin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-09-05 at 16:43 -0400, Nalin Dahyabhai wrote: > On Wed, Aug 29, 2012 at 08:48:32AM -0400, Ade Lee wrote: > > Incidentally, I ran this in permmissive selinux mode. The following > > rules are required to be added: > > > > #= certmonger_t == > > corenet_tcp_connect_http_cache_port(certmonger_t) > > files_read_var_lib_symlinks(certmonger_t) > > On my system, "semanage port -l" shows me: > http_cache_port_t tcp 8080, 8118, 10001-10010 > > Are these ports already labeled this way for Dogtag, or is it a > coincidental overlap with some other package? If it's an overlap, > it might be better to switch to using ports which aren't already labeled > for use in policy that applies to some other package. > We have specifically chosen to use what would be the default ports for tomcat. These ports are already labeled as you have described above. We have adjusted our selinux policy to handle that. In fact, we are now extending a tomcat selinux domain provided by the system policies, and this tomcat domain allows access to those ports. > If not, please open a bug against the selinux-policy component to get > these accesses added to the set that's allowed by the default policy. > I can open a bug. > Nalin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, Sep 05, 2012 at 05:08:12PM -0400, Ade Lee wrote: > On Wed, 2012-09-05 at 16:43 -0400, Nalin Dahyabhai wrote: > > On Wed, Aug 29, 2012 at 08:48:32AM -0400, Ade Lee wrote: > > > Incidentally, I ran this in permmissive selinux mode. The following > > > rules are required to be added: > > > > > > #= certmonger_t == > > > corenet_tcp_connect_http_cache_port(certmonger_t) > > > files_read_var_lib_symlinks(certmonger_t) > > > > On my system, "semanage port -l" shows me: > > http_cache_port_t tcp 8080, 8118, 10001-10010 > > > > Are these ports already labeled this way for Dogtag, or is it a > > coincidental overlap with some other package? If it's an overlap, > > it might be better to switch to using ports which aren't already labeled > > for use in policy that applies to some other package. > > We have specifically chosen to use what would be the default ports for > tomcat. These ports are already labeled as you have described above. > We have adjusted our selinux policy to handle that. In fact, we are now > extending a tomcat selinux domain provided by the system policies, and > this tomcat domain allows access to those ports. My thinking, based on the name, is that the policy expects this set of ports to be used by squid, and actual HTTP caches, rather than arbitrary servlet containers. But then I suppose the policy maintainer will know better. Please CC me on the policy bug so that I can keep an eye on it. Thanks, Nalin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-09-05 at 17:08 -0400, Ade Lee wrote: > On Wed, 2012-09-05 at 16:43 -0400, Nalin Dahyabhai wrote: > > On Wed, Aug 29, 2012 at 08:48:32AM -0400, Ade Lee wrote: > > > Incidentally, I ran this in permmissive selinux mode. The following > > > rules are required to be added: > > > > > > #= certmonger_t == > > > corenet_tcp_connect_http_cache_port(certmonger_t) > > > files_read_var_lib_symlinks(certmonger_t) > > > > On my system, "semanage port -l" shows me: > > http_cache_port_t tcp 8080, 8118, 10001-10010 > > > > Are these ports already labeled this way for Dogtag, or is it a > > coincidental overlap with some other package? If it's an overlap, > > it might be better to switch to using ports which aren't already labeled > > for use in policy that applies to some other package. > > > We have specifically chosen to use what would be the default ports for > tomcat. These ports are already labeled as you have described above. > We have adjusted our selinux policy to handle that. In fact, we are now > extending a tomcat selinux domain provided by the system policies, and > this tomcat domain allows access to those ports. > > > If not, please open a bug against the selinux-policy component to get > > these accesses added to the set that's allowed by the default policy. > > > I can open a bug. Ade, how will the selinux policy be handled in an upgrade scenario ? If I understand correctly you are dropping custom selinux policies from dogtag 10 and relying on system policy going forward, so what will keep the right labels for the old ports in an upgrade scenario ? Or will the rpm upgrade also change ports ? Is this properly handled on the ipa part yet ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-09-05 at 17:44 -0400, Simo Sorce wrote: > On Wed, 2012-09-05 at 17:08 -0400, Ade Lee wrote: > > On Wed, 2012-09-05 at 16:43 -0400, Nalin Dahyabhai wrote: > > > On Wed, Aug 29, 2012 at 08:48:32AM -0400, Ade Lee wrote: > > > > Incidentally, I ran this in permmissive selinux mode. The following > > > > rules are required to be added: > > > > > > > > #= certmonger_t == > > > > corenet_tcp_connect_http_cache_port(certmonger_t) > > > > files_read_var_lib_symlinks(certmonger_t) > > > > > > On my system, "semanage port -l" shows me: > > > http_cache_port_t tcp 8080, 8118, 10001-10010 > > > > > > Are these ports already labeled this way for Dogtag, or is it a > > > coincidental overlap with some other package? If it's an overlap, > > > it might be better to switch to using ports which aren't already labeled > > > for use in policy that applies to some other package. > > > > > We have specifically chosen to use what would be the default ports for > > tomcat. These ports are already labeled as you have described above. > > We have adjusted our selinux policy to handle that. In fact, we are now > > extending a tomcat selinux domain provided by the system policies, and > > this tomcat domain allows access to those ports. > > > > > If not, please open a bug against the selinux-policy component to get > > > these accesses added to the set that's allowed by the default policy. > > > > > I can open a bug. > > Ade, how will the selinux policy be handled in an upgrade scenario ? > If I understand correctly you are dropping custom selinux policies from > dogtag 10 and relying on system policy going forward, so what will keep > the right labels for the old ports in an upgrade scenario ? > Or will the rpm upgrade also change ports ? Is this properly handled on > the ipa part yet ? > > Simo. > To be clear, there will still be a selinux policy for dogtag, but it will be delivered as part of the system policies. The system selinux policy will contain alias definitions for all the old types. So for example, pki_ca_var_lib_t etc. will be aliased to the new type pki_tomcat_var_lib_t. The old ports will continue to be defined in the system policy but they will also be aliased to the ports in the new policy. Its not all defined yet - which is why we still need selinux permissive -- but we're working to get the system policy done soon. Ade ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-09-05 at 16:20 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On 08/31/2012 04:53 PM, Petr Viktorin wrote: > >> On 08/28/2012 03:40 PM, Petr Viktorin wrote: > >>> On 08/17/2012 06:04 PM, Ade Lee wrote: > On Fri, 2012-08-17 at 09:34 -0400, Ade Lee wrote: > > On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: > >> On 08/16/2012 01:28 PM, Ade Lee wrote: > >>> Patch attached this time. I should know better than to do this in the > >>> middle of the night .. > >>> > >>> On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: > On 08/16/2012 07:53 AM, Ade Lee wrote: > > On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: > >> On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: > >>> On 08/15/2012 03:54 PM, Ade Lee wrote: > On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: > > On 08/08/2012 10:05 PM, Ade Lee wrote: > >> Hi, > >> > >> Dogtag 10 is being released on f18, and has a number of > >> changes that > >> will affect IPA. In particular, the following changes will > >> affect > >> current IPA code. > >> > >> * The directory layout of the dogtag instance has changed. > >> Instead of > >> using separate tomcat instances to host different > >> subsystems, the > >> standard dogtag installation will allow one to install a CA. > >> KRA, OCSP > >> and TKS within the same instance. There have been > >> corresponding changes > >> in the directory layout, as well as the default instance name > >> (pki-tomcat instead of pki-ca), and startup daemon > >> (pki-tomcatd, instead > >> of pki-cad, pki-krad etc.) > >> > >> * The default instance will use only four ports (HTTPS, > >> HTTP, AJP and > >> tomcat shutdown port) rather than the 6 previously used. > >> The default > >> ports will be changed to the standard tomcat ports. As > >> these ports are > >> local to the ipa server machine, this should not cause too much > >> disruption. > >> > >> * There is a new single step installer written in python. > >> (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. > >> > >> * Dogtag 10 runs on tomcat7 - with a new corresponding > >> version of > >> tomcatjss. > >> > >> The attached patch integrates all the above changes in IPA > >> installation > >> and maintenance code. Once the patch is applied, users will > >> be able to: > >> > >> 1. run ipa-server-install to completion on f18 with dogtag 10. > >> 2. install a new replica on f18 on dogtag 10. > >> 3. upgrade an f17 machine with an existing IPA instance to > >> f18/ dogtag > >> 10 - and have that old-style dogtag instance continue to run > >> correctly. > >> This will require the installation of the latest version of > >> tomcatjss as > >> well as the installation of tomcat6. The old-style instance > >> will > >> continue to use tomcat6. > >> 4. in addition, the new cert renewal code has been patched > >> and should > >> continue to work. > >> > >> What is not yet completed / supported: > >> > >> 1. Installation with an external CA is not yet completed in > >> the new > >> installer. We plan to complete this soon. > >> > >> 2. There is some IPA upgrade code that has not yet been touched > >> (install/tools/ipa-upgradeconfig). > >> > >> 3. A script needs to be written to allow admins to convert > >> their > >> old-style dogtag instances to new style instances, as well > >> as code to > >> periodically prompt admins to do this. > >> > >> 4. Installation of old-style instances using > >> pkicreate/pkisilent on > >> dogtag 10 will no longer be supported, and will be disabled > >> soon. > >> > >> 5. The pki-selinux policy has been updated to reflect these > >> changes, > >> but is still in flux. In fact, it is our intention to place > >> the dogtag > >> selinux policy in the base selinux policy for f18. In the > >> meantime, it > >> may be necessary to run installs in permissive mode. > >> > >> The dogtag 10 code will be released shortly into f
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Ade Lee wrote: On Wed, 2012-09-05 at 16:20 -0400, Rob Crittenden wrote: Martin Kosek wrote: On 08/31/2012 04:53 PM, Petr Viktorin wrote: On 08/28/2012 03:40 PM, Petr Viktorin wrote: On 08/17/2012 06:04 PM, Ade Lee wrote: On Fri, 2012-08-17 at 09:34 -0400, Ade Lee wrote: On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: On 08/16/2012 01:28 PM, Ade Lee wrote: Patch attached this time. I should know better than to do this in the middle of the night .. On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: On 08/16/2012 07:53 AM, Ade Lee wrote: On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss >=7.0.0 will be required for f17+, rather than f18+ 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable? Yes. The current IPA patch is designed to work with dogtag 10 only, which will be officially available on f18+. So if you update to dogtag 10, you must have this patch and vi
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 09/06/2012 02:35 PM, Rob Crittenden wrote: Ade Lee wrote: On Wed, 2012-09-05 at 16:20 -0400, Rob Crittenden wrote: Martin Kosek wrote: On 08/31/2012 04:53 PM, Petr Viktorin wrote: On 08/28/2012 03:40 PM, Petr Viktorin wrote: On 08/17/2012 06:04 PM, Ade Lee wrote: On Fri, 2012-08-17 at 09:34 -0400, Ade Lee wrote: On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: On 08/16/2012 01:28 PM, Ade Lee wrote: Patch attached this time. I should know better than to do this in the middle of the night .. On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: On 08/16/2012 07:53 AM, Ade Lee wrote: On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss >=7.0.0 will be required for f17+, rather than f18+ 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable? Yes. The current IPA patch is designed to work with dogtag 10 only, which will be officially available on f18+. So if you update
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Petr Viktorin wrote: Attaching rebased and squashed patches. I've done some testing with them but please test some more. Most of these aren't IPA issues, but dogtag issues. I'll try to split them out. IPA: For the configuration files in install/conf to be updated at rpm update time the VERSION needs to be incremented. The ipa package lacks any updated dogtag dependencies, so I abused it. I installed IPA with dogtag 9 and created a replica. I updated the IPA bits, that worked fine. I updated to dogtag 10 and now the CA doesn't work on the master, including starting the dogtag instance. Note that the rpm update process worked, no notice that the CA service didn't restart. Uninstalling failed because it tried to run pkidestroy and not pkiremove. The contents of the file passed to pkispawn should be logged so we can see exactly what was passed in. DOGTAG: When upgrading using the dogtag-devel repo I had to specify pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit versions (and failed). I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64 --enablerepo=dogtag-devel --enablerepo=updates-testing What happens if someone manually upgrades pki-ca without first updating ipa? I think that pki-ca is going to need a Conflicts ipa < 3.0 in it. certificate renewal failed. I spent far too long trying to figure out why tomcat wasn't listening on port 9180 but failed. I think 9180 is actually the old server, right? So another missing dependency on a fixed certmonger? The best I could find was the certmonger error: ca-error: Error 7 connecting to http://edsel.example.com:9180/ca/ee/ca/profileSubmit: Couldn't connect to server. There is no man page for pkispawn/pkidestroy :-( According to the FHS these should not be in /bin but in /usr/sbin (not end-user commands). The output of pkicreate/pkisilent was really terrible and not usable at all so we didn't display it when failures occurred. It looks like that has been addressed, at least for the case where a CA is already configured and you try to install IPA. Perhaps we should capture stderr and display that instead of the command-line of pkispawn? Again, a man page would help with the integration. 2012-09-10T20:51:45Z DEBUG [2/18]: configuring certificate server instance 2012-09-10T20:51:45Z DEBUG args=/bin/pkispawn -s CA -f /tmp/tmp_Urraq 2012-09-10T20:51:45Z DEBUG stdout= 2012-09-10T20:51:45Z DEBUG stderr=pkispawn: ERROR... PKI subsystem 'CA' for instance 'pki-tomcat' already exists! 2012-09-10T20:51:45Z CRITICAL failed to configure ca instance Command '/bin/pkispawn -s CA -f /tmp/tmp_Urraq' returned non-zero exit status 1 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Mon, Sep 10, 2012 at 04:58:40PM -0400, Rob Crittenden wrote: > certificate renewal failed. I spent far too long trying to figure > out why tomcat wasn't listening on port 9180 but failed. I think > 9180 is actually the old server, right? So another missing > dependency on a fixed certmonger? > > The best I could find was the certmonger error: > > ca-error: Error 7 connecting to > http://edsel.example.com:9180/ca/ee/ca/profileSubmit: Couldn't > connect to server. That's the old port, alright, though I thought the upgrade process wasn't going to be converting already-installed Dogtag instances. Anyway, if your IPA configuration says "dogtag_version = 10", certmonger's not going to notice it until version 0.60. I've just set the wheels in motion to push that version to Fedora 17 and later. HTH, Nalin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: > Petr Viktorin wrote: > > Attaching rebased and squashed patches. I've done some testing with them > > but please test some more. > > > > Most of these aren't IPA issues, but dogtag issues. I'll try to split > them out. > > IPA: > > For the configuration files in install/conf to be updated at rpm update > time the VERSION needs to be incremented. > > The ipa package lacks any updated dogtag dependencies, so I abused it. > > I installed IPA with dogtag 9 and created a replica. > > I updated the IPA bits, that worked fine. > > I updated to dogtag 10 and now the CA doesn't work on the master, > including starting the dogtag instance. Note that the rpm update process > worked, no notice that the CA service didn't restart. > Did you try to restart the CA with selinux in permissive mode? This is still required right now until I get the selinux policy all straightened out. There is also a separate dogtag ticket (which is currently being worked on) to restart existing dogtag instances when dogtag is upgraded from 9->10. > Uninstalling failed because it tried to run pkidestroy and not pkiremove. > I'll test this too. > The contents of the file passed to pkispawn should be logged so we can > see exactly what was passed in. > Its a pretty big file. You might want to only log the modifications. Or save the file somewhere. > DOGTAG: > > When upgrading using the dogtag-devel repo I had to specify > pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit > versions (and failed). > > I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64 > --enablerepo=dogtag-devel --enablerepo=updates-testing > We'll look into this. I think I know why this happens. > What happens if someone manually upgrades pki-ca without first updating > ipa? I think that pki-ca is going to need a Conflicts ipa < 3.0 in it. We can add that. > certificate renewal failed. I spent far too long trying to figure out > why tomcat wasn't listening on port 9180 but failed. I think 9180 is > actually the old server, right? So another missing dependency on a fixed > certmonger? > > The best I could find was the certmonger error: > > ca-error: Error 7 connecting to > http://edsel.example.com:9180/ca/ee/ca/profileSubmit: Couldn't connect > to server. > Is this cert renewal on a dogtag 10 instance? Or the upgraded dogtag 9? If its dogtag 10, perhaps you do not have the certmonger version that has the relevant fix? If its dogtag 9, then we need to figure out whats going on. That reminds me - I need to file a bug to allow certmonger to talk to the newly defined dogtag ports. Do you have selinux permissive? > There is no man page for pkispawn/pkidestroy :-( According to the FHS > these should not be in /bin but in /usr/sbin (not end-user commands). > There is a trac ticket open for man pages for pkispawn and pkidestroy. We plan to complete this ticket by the time f18 is released. We'll look into the location of pkispawn/pkicreate. > The output of pkicreate/pkisilent was really terrible and not usable at > all so we didn't display it when failures occurred. It looks like that > has been addressed, at least for the case where a CA is already > configured and you try to install IPA. Perhaps we should capture stderr > and display that instead of the command-line of pkispawn? Again, a man > page would help with the integration. > > 2012-09-10T20:51:45Z DEBUG [2/18]: configuring certificate server instance > 2012-09-10T20:51:45Z DEBUG args=/bin/pkispawn -s CA -f /tmp/tmp_Urraq > 2012-09-10T20:51:45Z DEBUG stdout= > 2012-09-10T20:51:45Z DEBUG stderr=pkispawn: ERROR... PKI > subsystem 'CA' for instance 'pki-tomcat' already exists! > > 2012-09-10T20:51:45Z CRITICAL failed to configure ca instance Command > '/bin/pkispawn -s CA -f /tmp/tmp_Urraq' returned non-zero exit status 1 > That may be a good idea. Of course. thats an IPA thing, right? > rob > ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 09/11/2012 04:04 AM, Ade Lee wrote: On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: Petr Viktorin wrote: Attaching rebased and squashed patches. I've done some testing with them but please test some more. Most of these aren't IPA issues, but dogtag issues. I'll try to split them out. IPA: For the configuration files in install/conf to be updated at rpm update time the VERSION needs to be incremented. These files should stay the same since on upgrade we're still using a Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs. The ipa package lacks any updated dogtag dependencies, so I abused it. What should the updated dependencies be? Since it should work with both dogtag 9 and 10, I don't see how they should change. I installed IPA with dogtag 9 and created a replica. I updated the IPA bits, that worked fine. I updated to dogtag 10 and now the CA doesn't work on the master, including starting the dogtag instance. Note that the rpm update process worked, no notice that the CA service didn't restart. Did you try to restart the CA with selinux in permissive mode? This is still required right now until I get the selinux policy all straightened out. There is also a separate dogtag ticket (which is currently being worked on) to restart existing dogtag instances when dogtag is upgraded from 9->10. In permissive mode, this upgrade works for me. Sometimes I do get this error intermittently: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Temporarily Unavailable) Usually, waiting a couple of minutes clears this up. Perhaps we are not doing startup detection correctly. Ade mentioned that waiting for ports may not be ideal. How do we know if Dogtag is initialized? Uninstalling failed because it tried to run pkidestroy and not pkiremove. I was under the impression that pkidestroy was the correct command to remove an upgraded instance. I'll check with Ade. I'll test this too. The contents of the file passed to pkispawn should be logged so we can see exactly what was passed in. Its a pretty big file. You might want to only log the modifications. Or save the file somewhere. Our logs are pretty verbose, so that shouldn't be a problem. I'll put it in the next version of the patch. DOGTAG: When upgrading using the dogtag-devel repo I had to specify pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit versions (and failed). I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64 --enablerepo=dogtag-devel --enablerepo=updates-testing We'll look into this. I think I know why this happens. What happens if someone manually upgrades pki-ca without first updating ipa? I think that pki-ca is going to need a Conflicts ipa < 3.0 in it. We can add that. certificate renewal failed. I spent far too long trying to figure out why tomcat wasn't listening on port 9180 but failed. I think 9180 is actually the old server, right? So another missing dependency on a fixed certmonger? The best I could find was the certmonger error: ca-error: Error 7 connecting to http://edsel.example.com:9180/ca/ee/ca/profileSubmit: Couldn't connect to server. I'll set the certmonger min version to 0.60 as per Nalin's mail. Is this cert renewal on a dogtag 10 instance? Or the upgraded dogtag 9? If its dogtag 10, perhaps you do not have the certmonger version that has the relevant fix? If its dogtag 9, then we need to figure out whats going on. That reminds me - I need to file a bug to allow certmonger to talk to the newly defined dogtag ports. Do you have selinux permissive? There is no man page for pkispawn/pkidestroy :-( According to the FHS these should not be in /bin but in /usr/sbin (not end-user commands). There is a trac ticket open for man pages for pkispawn and pkidestroy. We plan to complete this ticket by the time f18 is released. We'll look into the location of pkispawn/pkicreate. The output of pkicreate/pkisilent was really terrible and not usable at all so we didn't display it when failures occurred. It looks like that has been addressed, at least for the case where a CA is already configured and you try to install IPA. Perhaps we should capture stderr and display that instead of the command-line of pkispawn? Again, a man page would help with the integration. 2012-09-10T20:51:45Z DEBUG [2/18]: configuring certificate server instance 2012-09-10T20:51:45Z DEBUG args=/bin/pkispawn -s CA -f /tmp/tmp_Urraq 2012-09-10T20:51:45Z DEBUG stdout= 2012-09-10T20:51:45Z DEBUG stderr=pkispawn: ERROR... PKI subsystem 'CA' for instance 'pki-tomcat' already exists! 2012-09-10T20:51:45Z CRITICAL failed to configure ca instance Command '/bin/pkispawn -s CA -f /tmp/tmp_Urraq' returned non-zero exit status 1 That may be a good idea. Of course. thats an IPA thing, right? rob -- Petr³ ___ Freeipa-devel mailing list Fre
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Petr Viktorin wrote: On 09/11/2012 04:04 AM, Ade Lee wrote: On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: Petr Viktorin wrote: Attaching rebased and squashed patches. I've done some testing with them but please test some more. Most of these aren't IPA issues, but dogtag issues. I'll try to split them out. IPA: For the configuration files in install/conf to be updated at rpm update time the VERSION needs to be incremented. These files should stay the same since on upgrade we're still using a Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs. The ipa package lacks any updated dogtag dependencies, so I abused it. What should the updated dependencies be? Since it should work with both dogtag 9 and 10, I don't see how they should change. I don't know either, but we need to prevent people from installing incompatible package combinations. I installed IPA with dogtag 9 and created a replica. I updated the IPA bits, that worked fine. I updated to dogtag 10 and now the CA doesn't work on the master, including starting the dogtag instance. Note that the rpm update process worked, no notice that the CA service didn't restart. Did you try to restart the CA with selinux in permissive mode? This is still required right now until I get the selinux policy all straightened out. There is also a separate dogtag ticket (which is currently being worked on) to restart existing dogtag instances when dogtag is upgraded from 9->10. In permissive mode, this upgrade works for me. I was in enforcing mode but saw no AVCs. What is the ETA on fixing this? Sometimes I do get this error intermittently: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Temporarily Unavailable) Usually, waiting a couple of minutes clears this up. Perhaps we are not doing startup detection correctly. Ade mentioned that waiting for ports may not be ideal. How do we know if Dogtag is initialized? Years ago we had discussed with Andrew and Matt creating a URI that can be queried to determine dogtag status. I don't think that ever went anywhere. Uninstalling failed because it tried to run pkidestroy and not pkiremove. I was under the impression that pkidestroy was the correct command to remove an upgraded instance. I'll check with Ade. I'll test this too. The contents of the file passed to pkispawn should be logged so we can see exactly what was passed in. Its a pretty big file. You might want to only log the modifications. Or save the file somewhere. Our logs are pretty verbose, so that shouldn't be a problem. I'll put it in the next version of the patch. The question to ask is: would you need the contents of this file if all you got were logs and needed to evaluate why installation failed? In most cases this is yes. DOGTAG: When upgrading using the dogtag-devel repo I had to specify pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit versions (and failed). I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64 --enablerepo=dogtag-devel --enablerepo=updates-testing We'll look into this. I think I know why this happens. What happens if someone manually upgrades pki-ca without first updating ipa? I think that pki-ca is going to need a Conflicts ipa < 3.0 in it. We can add that. certificate renewal failed. I spent far too long trying to figure out why tomcat wasn't listening on port 9180 but failed. I think 9180 is actually the old server, right? So another missing dependency on a fixed certmonger? The best I could find was the certmonger error: ca-error: Error 7 connecting to http://edsel.example.com:9180/ca/ee/ca/profileSubmit: Couldn't connect to server. I'll set the certmonger min version to 0.60 as per Nalin's mail. Ok. Is this cert renewal on a dogtag 10 instance? Or the upgraded dogtag 9? If its dogtag 10, perhaps you do not have the certmonger version that has the relevant fix? If its dogtag 9, then we need to figure out whats going on. That reminds me - I need to file a bug to allow certmonger to talk to the newly defined dogtag ports. Do you have selinux permissive? There is no man page for pkispawn/pkidestroy :-( According to the FHS these should not be in /bin but in /usr/sbin (not end-user commands). There is a trac ticket open for man pages for pkispawn and pkidestroy. We plan to complete this ticket by the time f18 is released. We'll look into the location of pkispawn/pkicreate. The output of pkicreate/pkisilent was really terrible and not usable at all so we didn't display it when failures occurred. It looks like that has been addressed, at least for the case where a CA is already configured and you try to install IPA. Perhaps we should capture stderr and display that instead of the command-line of pkispawn? Again, a man page would help with the integration. 2012-09-10T20:51:45Z DEBUG [2/18]: configuring certificate server instance 2012-09-10T20:51
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote: > Petr Viktorin wrote: > > On 09/11/2012 04:04 AM, Ade Lee wrote: > >> On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: > >>> Petr Viktorin wrote: > Attaching rebased and squashed patches. I've done some testing with > them > but please test some more. > > >>> > >>> Most of these aren't IPA issues, but dogtag issues. I'll try to split > >>> them out. > >>> > >>> IPA: > >>> > >>> For the configuration files in install/conf to be updated at rpm update > >>> time the VERSION needs to be incremented. > > > > These files should stay the same since on upgrade we're still using a > > Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs. > > > >>> The ipa package lacks any updated dogtag dependencies, so I abused it. > > > > What should the updated dependencies be? Since it should work with both > > dogtag 9 and 10, I don't see how they should change. > > I don't know either, but we need to prevent people from installing > incompatible package combinations. > Would'nt the Conflicts: ipa < 3.0 in pki-ca mentioned below satisfy this requirement? The main concern is that you must have ipa 3.0 if you have dogtag 10. Given that dogtag is consumed by IPA though, it makes more sense to put the relevant conflicts in IPA rather than in dogtag. So in this case, that would mean putting Conflicts: pki-ca >= 10.0 in IPA 2.x. Recall that dogtag 10 will only be officially available in f18+. > >>> I installed IPA with dogtag 9 and created a replica. > >>> > >>> I updated the IPA bits, that worked fine. > >>> > >>> I updated to dogtag 10 and now the CA doesn't work on the master, > >>> including starting the dogtag instance. Note that the rpm update process > >>> worked, no notice that the CA service didn't restart. > >>> > >> Did you try to restart the CA with selinux in permissive mode? This is > >> still required right now until I get the selinux policy all straightened > >> out. > >> > >> There is also a separate dogtag ticket (which is currently being worked > >> on) to restart existing dogtag instances when dogtag is upgraded from > >> 9->10. > > > > In permissive mode, this upgrade works for me. > > I was in enforcing mode but saw no AVCs. What is the ETA on fixing this? > Within the next week or two, I need to finish the IPA merge database patch first, and then co-ordinate changes with the selinux guys. > > > > > > Sometimes I do get this error intermittently: > > > > ipa: ERROR: Certificate operation cannot be completed: Unable to > > communicate with CMS (Service Temporarily Unavailable) > > > > Usually, waiting a couple of minutes clears this up. Perhaps we are not > > doing startup detection correctly. Ade mentioned that waiting for ports > > may not be ideal. How do we know if Dogtag is initialized? > > Years ago we had discussed with Andrew and Matt creating a URI that can > be queried to determine dogtag status. I don't think that ever went > anywhere. > Petr, this happens only on reboot, right? And not on regular "service ipa restart"? Yeah, I remember this conversation - and even created a bug for it at some point. This went away because the mechanism you were using seemed to be working. The timing may be very different now with tomcat 7 and systemd. I'll open a dogtag trac ticket for this. > > > >>> Uninstalling failed because it tried to run pkidestroy and not > >>> pkiremove. > > > > I was under the impression that pkidestroy was the correct command to > > remove an upgraded instance. I'll check with Ade. > > > >> I'll test this too. > >> > >>> The contents of the file passed to pkispawn should be logged so we can > >>> see exactly what was passed in. > >>> > >> Its a pretty big file. You might want to only log the modifications. > >> Or save the file somewhere. > > > > Our logs are pretty verbose, so that shouldn't be a problem. I'll put it > > in the next version of the patch. > > The question to ask is: would you need the contents of this file if all > you got were logs and needed to evaluate why installation failed? In > most cases this is yes. > Up to you guys. There is a patch I am working on in which I will be logging the object that is being passed to the server from pkispawn. That - and the diffs to the standard config file as I mentioned above - will likely be sufficient to debug almost all cases. Make sure not to log any passwords. > >>> DOGTAG: > >>> > >>> When upgrading using the dogtag-devel repo I had to specify > >>> pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit > >>> versions (and failed). > >>> > >>> I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64 > >>> --enablerepo=dogtag-devel --enablerepo=updates-testing > >>> > >> We'll look into this. I think I know why this happens. > >> > >>> What happens if someone manually upgrades pki-ca without first updating > >>> ipa? I think that pki-ca is going to need a Conflicts ipa <
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Ade Lee wrote: On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:04 AM, Ade Lee wrote: On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: Petr Viktorin wrote: Attaching rebased and squashed patches. I've done some testing with them but please test some more. Most of these aren't IPA issues, but dogtag issues. I'll try to split them out. IPA: For the configuration files in install/conf to be updated at rpm update time the VERSION needs to be incremented. These files should stay the same since on upgrade we're still using a Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs. The ipa package lacks any updated dogtag dependencies, so I abused it. What should the updated dependencies be? Since it should work with both dogtag 9 and 10, I don't see how they should change. I don't know either, but we need to prevent people from installing incompatible package combinations. Would'nt the Conflicts: ipa < 3.0 in pki-ca mentioned below satisfy this requirement? The main concern is that you must have ipa 3.0 if you have dogtag 10. Given that dogtag is consumed by IPA though, it makes more sense to put the relevant conflicts in IPA rather than in dogtag. So in this case, that would mean putting Conflicts: pki-ca >= 10.0 in IPA 2.x. Recall that dogtag 10 will only be officially available in f18+. That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to F-18 they would be able to install dogtag 10 and blow up their IPA server. I installed IPA with dogtag 9 and created a replica. I updated the IPA bits, that worked fine. I updated to dogtag 10 and now the CA doesn't work on the master, including starting the dogtag instance. Note that the rpm update process worked, no notice that the CA service didn't restart. Did you try to restart the CA with selinux in permissive mode? This is still required right now until I get the selinux policy all straightened out. There is also a separate dogtag ticket (which is currently being worked on) to restart existing dogtag instances when dogtag is upgraded from 9->10. In permissive mode, this upgrade works for me. I was in enforcing mode but saw no AVCs. What is the ETA on fixing this? Within the next week or two, I need to finish the IPA merge database patch first, and then co-ordinate changes with the selinux guys. Sometimes I do get this error intermittently: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Temporarily Unavailable) Usually, waiting a couple of minutes clears this up. Perhaps we are not doing startup detection correctly. Ade mentioned that waiting for ports may not be ideal. How do we know if Dogtag is initialized? Years ago we had discussed with Andrew and Matt creating a URI that can be queried to determine dogtag status. I don't think that ever went anywhere. Petr, this happens only on reboot, right? And not on regular "service ipa restart"? Yeah, I remember this conversation - and even created a bug for it at some point. This went away because the mechanism you were using seemed to be working. The timing may be very different now with tomcat 7 and systemd. I'll open a dogtag trac ticket for this. Ok. Uninstalling failed because it tried to run pkidestroy and not pkiremove. I was under the impression that pkidestroy was the correct command to remove an upgraded instance. I'll check with Ade. I'll test this too. The contents of the file passed to pkispawn should be logged so we can see exactly what was passed in. Its a pretty big file. You might want to only log the modifications. Or save the file somewhere. Our logs are pretty verbose, so that shouldn't be a problem. I'll put it in the next version of the patch. The question to ask is: would you need the contents of this file if all you got were logs and needed to evaluate why installation failed? In most cases this is yes. Up to you guys. There is a patch I am working on in which I will be logging the object that is being passed to the server from pkispawn. That - and the diffs to the standard config file as I mentioned above - will likely be sufficient to debug almost all cases. Make sure not to log any passwords. DOGTAG: When upgrading using the dogtag-devel repo I had to specify pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit versions (and failed). I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64 --enablerepo=dogtag-devel --enablerepo=updates-testing We'll look into this. I think I know why this happens. What happens if someone manually upgrades pki-ca without first updating ipa? I think that pki-ca is going to need a Conflicts ipa < 3.0 in it. We can add that. certificate renewal failed. I spent far too long trying to figure out why tomcat wasn't listening on port 9180 but failed. I think 9180 is actually the old server, right? So another missing depe
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Petr Viktorin wrote: On 09/11/2012 04:38 PM, Rob Crittenden wrote: Ade Lee wrote: On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:04 AM, Ade Lee wrote: On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: Petr Viktorin wrote: Attaching rebased and squashed patches. I've done some testing with them but please test some more. Most of these aren't IPA issues, but dogtag issues. I'll try to split them out. IPA: For the configuration files in install/conf to be updated at rpm update time the VERSION needs to be incremented. These files should stay the same since on upgrade we're still using a Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs. The ipa package lacks any updated dogtag dependencies, so I abused it. What should the updated dependencies be? Since it should work with both dogtag 9 and 10, I don't see how they should change. I don't know either, but we need to prevent people from installing incompatible package combinations. Would'nt the Conflicts: ipa < 3.0 in pki-ca mentioned below satisfy this requirement? The main concern is that you must have ipa 3.0 if you have dogtag 10. Given that dogtag is consumed by IPA though, it makes more sense to put the relevant conflicts in IPA rather than in dogtag. So in this case, that would mean putting Conflicts: pki-ca >= 10.0 in IPA 2.x. Recall that dogtag 10 will only be officially available in f18+. That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to F-18 they would be able to install dogtag 10 and blow up their IPA server. I installed IPA with dogtag 9 and created a replica. I updated the IPA bits, that worked fine. I updated to dogtag 10 and now the CA doesn't work on the master, including starting the dogtag instance. Note that the rpm update process worked, no notice that the CA service didn't restart. Did you try to restart the CA with selinux in permissive mode? This is still required right now until I get the selinux policy all straightened out. There is also a separate dogtag ticket (which is currently being worked on) to restart existing dogtag instances when dogtag is upgraded from 9->10. In permissive mode, this upgrade works for me. I was in enforcing mode but saw no AVCs. What is the ETA on fixing this? Within the next week or two, I need to finish the IPA merge database patch first, and then co-ordinate changes with the selinux guys. Sometimes I do get this error intermittently: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Temporarily Unavailable) Usually, waiting a couple of minutes clears this up. Perhaps we are not doing startup detection correctly. Ade mentioned that waiting for ports may not be ideal. How do we know if Dogtag is initialized? Years ago we had discussed with Andrew and Matt creating a URI that can be queried to determine dogtag status. I don't think that ever went anywhere. Petr, this happens only on reboot, right? And not on regular "service ipa restart"? I've now seen it happen right after a 9 → 10 upgrade. Yeah, I remember this conversation - and even created a bug for it at some point. This went away because the mechanism you were using seemed to be working. The timing may be very different now with tomcat 7 and systemd. I'll open a dogtag trac ticket for this. Ok. Uninstalling failed because it tried to run pkidestroy and not pkiremove. I was under the impression that pkidestroy was the correct command to remove an upgraded instance. I'll check with Ade. I'll test this too. The contents of the file passed to pkispawn should be logged so we can see exactly what was passed in. Its a pretty big file. You might want to only log the modifications. Or save the file somewhere. Our logs are pretty verbose, so that shouldn't be a problem. I'll put it in the next version of the patch. The question to ask is: would you need the contents of this file if all you got were logs and needed to evaluate why installation failed? In most cases this is yes. Up to you guys. There is a patch I am working on in which I will be logging the object that is being passed to the server from pkispawn. That - and the diffs to the standard config file as I mentioned above - will likely be sufficient to debug almost all cases. Make sure not to log any passwords. Thanks for the catch. Attaching updated patch that sanitizes the passwords. DOGTAG: When upgrading using the dogtag-devel repo I had to specify pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit versions (and failed). I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64 --enablerepo=dogtag-devel --enablerepo=updates-testing We'll look into this. I think I know why this happens. What happens if someone manually upgrades pki-ca without first updating ipa? I think that pki-ca is going to need a Conflicts ipa < 3.0 in it. We can add
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:38 PM, Rob Crittenden wrote: Ade Lee wrote: On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:04 AM, Ade Lee wrote: On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: Petr Viktorin wrote: Attaching rebased and squashed patches. I've done some testing with them but please test some more. Most of these aren't IPA issues, but dogtag issues. I'll try to split them out. IPA: For the configuration files in install/conf to be updated at rpm update time the VERSION needs to be incremented. These files should stay the same since on upgrade we're still using a Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs. The ipa package lacks any updated dogtag dependencies, so I abused it. What should the updated dependencies be? Since it should work with both dogtag 9 and 10, I don't see how they should change. I don't know either, but we need to prevent people from installing incompatible package combinations. Would'nt the Conflicts: ipa < 3.0 in pki-ca mentioned below satisfy this requirement? The main concern is that you must have ipa 3.0 if you have dogtag 10. Given that dogtag is consumed by IPA though, it makes more sense to put the relevant conflicts in IPA rather than in dogtag. So in this case, that would mean putting Conflicts: pki-ca >= 10.0 in IPA 2.x. Recall that dogtag 10 will only be officially available in f18+. That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to F-18 they would be able to install dogtag 10 and blow up their IPA server. I installed IPA with dogtag 9 and created a replica. I updated the IPA bits, that worked fine. I updated to dogtag 10 and now the CA doesn't work on the master, including starting the dogtag instance. Note that the rpm update process worked, no notice that the CA service didn't restart. Did you try to restart the CA with selinux in permissive mode? This is still required right now until I get the selinux policy all straightened out. There is also a separate dogtag ticket (which is currently being worked on) to restart existing dogtag instances when dogtag is upgraded from 9->10. In permissive mode, this upgrade works for me. I was in enforcing mode but saw no AVCs. What is the ETA on fixing this? Within the next week or two, I need to finish the IPA merge database patch first, and then co-ordinate changes with the selinux guys. Sometimes I do get this error intermittently: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Temporarily Unavailable) Usually, waiting a couple of minutes clears this up. Perhaps we are not doing startup detection correctly. Ade mentioned that waiting for ports may not be ideal. How do we know if Dogtag is initialized? Years ago we had discussed with Andrew and Matt creating a URI that can be queried to determine dogtag status. I don't think that ever went anywhere. Petr, this happens only on reboot, right? And not on regular "service ipa restart"? I've now seen it happen right after a 9 → 10 upgrade. Yeah, I remember this conversation - and even created a bug for it at some point. This went away because the mechanism you were using seemed to be working. The timing may be very different now with tomcat 7 and systemd. I'll open a dogtag trac ticket for this. Ok. Uninstalling failed because it tried to run pkidestroy and not pkiremove. I was under the impression that pkidestroy was the correct command to remove an upgraded instance. I'll check with Ade. I'll test this too. The contents of the file passed to pkispawn should be logged so we can see exactly what was passed in. Its a pretty big file. You might want to only log the modifications. Or save the file somewhere. Our logs are pretty verbose, so that shouldn't be a problem. I'll put it in the next version of the patch. The question to ask is: would you need the contents of this file if all you got were logs and needed to evaluate why installation failed? In most cases this is yes. Up to you guys. There is a patch I am working on in which I will be logging the object that is being passed to the server from pkispawn. That - and the diffs to the standard config file as I mentioned above - will likely be sufficient to debug almost all cases. Make sure not to log any passwords. Thanks for the catch. Attaching updated patch that sanitizes the passwords. DOGTAG: When upgrading using the dogtag-devel repo I had to specify pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit versions (and failed). I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64 --enablerepo=dogtag-devel --enablerepo=updates-testing We'll look into this. I think I know why this happens. What happens if someone manually upgrades pki-ca without first updating ipa? I think that pki-ca is going to need a Conflicts ipa < 3
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:38 PM, Rob Crittenden wrote: Ade Lee wrote: On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:04 AM, Ade Lee wrote: On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: Petr Viktorin wrote: Attaching rebased and squashed patches. I've done some testing with them but please test some more. Most of these aren't IPA issues, but dogtag issues. I'll try to split them out. IPA: For the configuration files in install/conf to be updated at rpm update time the VERSION needs to be incremented. These files should stay the same since on upgrade we're still using a Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs. The ipa package lacks any updated dogtag dependencies, so I abused it. What should the updated dependencies be? Since it should work with both dogtag 9 and 10, I don't see how they should change. I don't know either, but we need to prevent people from installing incompatible package combinations. Would'nt the Conflicts: ipa < 3.0 in pki-ca mentioned below satisfy this requirement? The main concern is that you must have ipa 3.0 if you have dogtag 10. Given that dogtag is consumed by IPA though, it makes more sense to put the relevant conflicts in IPA rather than in dogtag. So in this case, that would mean putting Conflicts: pki-ca >= 10.0 in IPA 2.x. Recall that dogtag 10 will only be officially available in f18+. That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to F-18 they would be able to install dogtag 10 and blow up their IPA server. I installed IPA with dogtag 9 and created a replica. I updated the IPA bits, that worked fine. I updated to dogtag 10 and now the CA doesn't work on the master, including starting the dogtag instance. Note that the rpm update process worked, no notice that the CA service didn't restart. Did you try to restart the CA with selinux in permissive mode? This is still required right now until I get the selinux policy all straightened out. There is also a separate dogtag ticket (which is currently being worked on) to restart existing dogtag instances when dogtag is upgraded from 9->10. In permissive mode, this upgrade works for me. I was in enforcing mode but saw no AVCs. What is the ETA on fixing this? Within the next week or two, I need to finish the IPA merge database patch first, and then co-ordinate changes with the selinux guys. Sometimes I do get this error intermittently: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Temporarily Unavailable) Usually, waiting a couple of minutes clears this up. Perhaps we are not doing startup detection correctly. Ade mentioned that waiting for ports may not be ideal. How do we know if Dogtag is initialized? Years ago we had discussed with Andrew and Matt creating a URI that can be queried to determine dogtag status. I don't think that ever went anywhere. Petr, this happens only on reboot, right? And not on regular "service ipa restart"? I've now seen it happen right after a 9 → 10 upgrade. Yeah, I remember this conversation - and even created a bug for it at some point. This went away because the mechanism you were using seemed to be working. The timing may be very different now with tomcat 7 and systemd. I'll open a dogtag trac ticket for this. Ok. Uninstalling failed because it tried to run pkidestroy and not pkiremove. I was under the impression that pkidestroy was the correct command to remove an upgraded instance. I'll check with Ade. I'll test this too. The contents of the file passed to pkispawn should be logged so we can see exactly what was passed in. Its a pretty big file. You might want to only log the modifications. Or save the file somewhere. Our logs are pretty verbose, so that shouldn't be a problem. I'll put it in the next version of the patch. The question to ask is: would you need the contents of this file if all you got were logs and needed to evaluate why installation failed? In most cases this is yes. Up to you guys. There is a patch I am working on in which I will be logging the object that is being passed to the server from pkispawn. That - and the diffs to the standard config file as I mentioned above - will likely be sufficient to debug almost all cases. Make sure not to log any passwords. Thanks for the catch. Attaching updated patch that sanitizes the passwords. DOGTAG: When upgrading using the dogtag-devel repo I had to specify pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit versions (and failed). I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64 --enablerepo=dogtag-devel --enablerepo=updates-testing We'll look into this. I think I know why this happens. What happens if someone manually upgrades pki-ca without first updating ipa? I think that pki-ca is going to need a Conflicts ipa < 3
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Rob Crittenden wrote: Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:38 PM, Rob Crittenden wrote: Ade Lee wrote: On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:04 AM, Ade Lee wrote: On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: Petr Viktorin wrote: Attaching rebased and squashed patches. I've done some testing with them but please test some more. Most of these aren't IPA issues, but dogtag issues. I'll try to split them out. IPA: For the configuration files in install/conf to be updated at rpm update time the VERSION needs to be incremented. These files should stay the same since on upgrade we're still using a Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs. The ipa package lacks any updated dogtag dependencies, so I abused it. What should the updated dependencies be? Since it should work with both dogtag 9 and 10, I don't see how they should change. I don't know either, but we need to prevent people from installing incompatible package combinations. Would'nt the Conflicts: ipa < 3.0 in pki-ca mentioned below satisfy this requirement? The main concern is that you must have ipa 3.0 if you have dogtag 10. Given that dogtag is consumed by IPA though, it makes more sense to put the relevant conflicts in IPA rather than in dogtag. So in this case, that would mean putting Conflicts: pki-ca >= 10.0 in IPA 2.x. Recall that dogtag 10 will only be officially available in f18+. That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to F-18 they would be able to install dogtag 10 and blow up their IPA server. I installed IPA with dogtag 9 and created a replica. I updated the IPA bits, that worked fine. I updated to dogtag 10 and now the CA doesn't work on the master, including starting the dogtag instance. Note that the rpm update process worked, no notice that the CA service didn't restart. Did you try to restart the CA with selinux in permissive mode? This is still required right now until I get the selinux policy all straightened out. There is also a separate dogtag ticket (which is currently being worked on) to restart existing dogtag instances when dogtag is upgraded from 9->10. In permissive mode, this upgrade works for me. I was in enforcing mode but saw no AVCs. What is the ETA on fixing this? Within the next week or two, I need to finish the IPA merge database patch first, and then co-ordinate changes with the selinux guys. Sometimes I do get this error intermittently: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Temporarily Unavailable) Usually, waiting a couple of minutes clears this up. Perhaps we are not doing startup detection correctly. Ade mentioned that waiting for ports may not be ideal. How do we know if Dogtag is initialized? Years ago we had discussed with Andrew and Matt creating a URI that can be queried to determine dogtag status. I don't think that ever went anywhere. Petr, this happens only on reboot, right? And not on regular "service ipa restart"? I've now seen it happen right after a 9 → 10 upgrade. Yeah, I remember this conversation - and even created a bug for it at some point. This went away because the mechanism you were using seemed to be working. The timing may be very different now with tomcat 7 and systemd. I'll open a dogtag trac ticket for this. Ok. Uninstalling failed because it tried to run pkidestroy and not pkiremove. I was under the impression that pkidestroy was the correct command to remove an upgraded instance. I'll check with Ade. I'll test this too. The contents of the file passed to pkispawn should be logged so we can see exactly what was passed in. Its a pretty big file. You might want to only log the modifications. Or save the file somewhere. Our logs are pretty verbose, so that shouldn't be a problem. I'll put it in the next version of the patch. The question to ask is: would you need the contents of this file if all you got were logs and needed to evaluate why installation failed? In most cases this is yes. Up to you guys. There is a patch I am working on in which I will be logging the object that is being passed to the server from pkispawn. That - and the diffs to the standard config file as I mentioned above - will likely be sufficient to debug almost all cases. Make sure not to log any passwords. Thanks for the catch. Attaching updated patch that sanitizes the passwords. DOGTAG: When upgrading using the dogtag-devel repo I had to specify pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit versions (and failed). I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64 --enablerepo=dogtag-devel --enablerepo=updates-testing We'll look into this. I think I know why this happens. What happens if someone manually upgrades pki-ca without first updating ipa? I think that pki-ca is going to n
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Tue, 2012-09-11 at 14:45 -0400, Rob Crittenden wrote: > Petr Viktorin wrote: > > On 09/11/2012 04:38 PM, Rob Crittenden wrote: > >> Ade Lee wrote: > >>> On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote: > Petr Viktorin wrote: > > On 09/11/2012 04:04 AM, Ade Lee wrote: > >> On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: > >>> Petr Viktorin wrote: > Attaching rebased and squashed patches. I've done some testing with > them > but please test some more. > > >>> > >>> Most of these aren't IPA issues, but dogtag issues. I'll try to > >>> split > >>> them out. > >>> > >>> IPA: > >>> > >>> For the configuration files in install/conf to be updated at rpm > >>> update > >>> time the VERSION needs to be incremented. > > > > These files should stay the same since on upgrade we're still using a > > Dogtag 9 style instance. The Dogtag 10 ports are only used in new > > installs. > > > >>> The ipa package lacks any updated dogtag dependencies, so I abused > >>> it. > > > > What should the updated dependencies be? Since it should work with > > both > > dogtag 9 and 10, I don't see how they should change. > > I don't know either, but we need to prevent people from installing > incompatible package combinations. > > >>> Would'nt the Conflicts: ipa < 3.0 in pki-ca mentioned below satisfy this > >>> requirement? The main concern is that you must have ipa 3.0 if you have > >>> dogtag 10. > >>> > >>> Given that dogtag is consumed by IPA though, it makes more sense to put > >>> the relevant conflicts in IPA rather than in dogtag. So in this case, > >>> that would mean putting Conflicts: pki-ca >= 10.0 in IPA 2.x. > >>> Recall that dogtag 10 will only be officially available in f18+. > >> > >> That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to > >> F-18 they would be able to install dogtag 10 and blow up their IPA > >> server. > >> We can add the Conflicts: freeipa-server < 3.0 to the dogtag packages (likely in pki-base). But we should also add explicit dependencies to ipa. For ipa 2.2, Conflicts: pki-ca >= 10.0, Requires: pki-ca >= 9.x For ipa 3, Requires: pki-ca >= 10.0 This is of course assumes that ipa 3 is only officially released on f18 (which is what will happen for dogtag 10). Just because we can support d9 on ipa 3 does not mean we should. As it is, in this case, we will have to support IPA 3 + d10, IPA 3 + d10 + d9-style instance, IPA 2.x + d9. > >>> > >>> I installed IPA with dogtag 9 and created a replica. > >>> > >>> I updated the IPA bits, that worked fine. > >>> > >>> I updated to dogtag 10 and now the CA doesn't work on the master, > >>> including starting the dogtag instance. Note that the rpm update > >>> process > >>> worked, no notice that the CA service didn't restart. > >>> > >> Did you try to restart the CA with selinux in permissive mode? > >> This is > >> still required right now until I get the selinux policy all > >> straightened > >> out. > >> > >> There is also a separate dogtag ticket (which is currently being > >> worked > >> on) to restart existing dogtag instances when dogtag is upgraded from > >> 9->10. > > > > In permissive mode, this upgrade works for me. > > I was in enforcing mode but saw no AVCs. What is the ETA on fixing > this? > > >>> > >>> Within the next week or two, I need to finish the IPA merge database > >>> patch first, and then co-ordinate changes with the selinux guys. > >>> > > > > > > Sometimes I do get this error intermittently: > > > > ipa: ERROR: Certificate operation cannot be completed: Unable to > > communicate with CMS (Service Temporarily Unavailable) > > > > Usually, waiting a couple of minutes clears this up. Perhaps we are > > not > > doing startup detection correctly. Ade mentioned that waiting for > > ports > > may not be ideal. How do we know if Dogtag is initialized? > > Years ago we had discussed with Andrew and Matt creating a URI that can > be queried to determine dogtag status. I don't think that ever went > anywhere. > > >>> Petr, this happens only on reboot, right? And not on regular "service > >>> ipa restart"? > > > > I've now seen it happen right after a 9 → 10 upgrade. > > > >>> Yeah, I remember this conversation - and even created a bug for it at > >>> some point. This went away because the mechanism you were using seemed > >>> to be working. The timing may be very different now with tomcat 7 and > >>> systemd. I'll open a dogtag trac ticket for this. > >> > >> Ok. > >> > >>> > > > >>> Uninstalling failed because it tried to run pkidestroy and not > >>> pkiremove. > > > > I was under the impression that pkidestroy was the correct command to > > remove
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 09/12/2012 04:42 AM, Ade Lee wrote: On Tue, 2012-09-11 at 14:45 -0400, Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:38 PM, Rob Crittenden wrote: Ade Lee wrote: On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:04 AM, Ade Lee wrote: On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: Petr Viktorin wrote: Attaching rebased and squashed patches. I've done some testing with them but please test some more. Most of these aren't IPA issues, but dogtag issues. I'll try to split them out. IPA: For the configuration files in install/conf to be updated at rpm update time the VERSION needs to be incremented. These files should stay the same since on upgrade we're still using a Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs. The ipa package lacks any updated dogtag dependencies, so I abused it. What should the updated dependencies be? Since it should work with both dogtag 9 and 10, I don't see how they should change. I don't know either, but we need to prevent people from installing incompatible package combinations. Would'nt the Conflicts: ipa < 3.0 in pki-ca mentioned below satisfy this requirement? The main concern is that you must have ipa 3.0 if you have dogtag 10. Given that dogtag is consumed by IPA though, it makes more sense to put the relevant conflicts in IPA rather than in dogtag. So in this case, that would mean putting Conflicts: pki-ca >= 10.0 in IPA 2.x. Recall that dogtag 10 will only be officially available in f18+. That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to F-18 they would be able to install dogtag 10 and blow up their IPA server. We can add the Conflicts: freeipa-server < 3.0 to the dogtag packages (likely in pki-base). But we should also add explicit dependencies to ipa. For ipa 2.2, Conflicts: pki-ca >= 10.0, Requires: pki-ca >= 9.x For ipa 3, Requires: pki-ca >= 10.0 Unfortunately we need to support IPA 3.0 with Dogtag 9. This is of course assumes that ipa 3 is only officially released on f18 (which is what will happen for dogtag 10). Just because we can support d9 on ipa 3 does not mean we should. As it is, in this case, we will have to support IPA 3 + d10, IPA 3 + d10 + d9-style instance, IPA 2.x + d9. We also need to test replication between various combinations of these. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 09/11/2012 09:38 PM, Rob Crittenden wrote: Rob Crittenden wrote: Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:38 PM, Rob Crittenden wrote: Ade Lee wrote: On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:04 AM, Ade Lee wrote: On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: Petr Viktorin wrote: Attaching rebased and squashed patches. I've done some testing with them but please test some more. Most of these aren't IPA issues, but dogtag issues. I'll try to split them out. IPA: For the configuration files in install/conf to be updated at rpm update time the VERSION needs to be incremented. These files should stay the same since on upgrade we're still using a Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs. The ipa package lacks any updated dogtag dependencies, so I abused it. What should the updated dependencies be? Since it should work with both dogtag 9 and 10, I don't see how they should change. I don't know either, but we need to prevent people from installing incompatible package combinations. Would'nt the Conflicts: ipa < 3.0 in pki-ca mentioned below satisfy this requirement? The main concern is that you must have ipa 3.0 if you have dogtag 10. Given that dogtag is consumed by IPA though, it makes more sense to put the relevant conflicts in IPA rather than in dogtag. So in this case, that would mean putting Conflicts: pki-ca >= 10.0 in IPA 2.x. Recall that dogtag 10 will only be officially available in f18+. That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to F-18 they would be able to install dogtag 10 and blow up their IPA server. I installed IPA with dogtag 9 and created a replica. I updated the IPA bits, that worked fine. I updated to dogtag 10 and now the CA doesn't work on the master, including starting the dogtag instance. Note that the rpm update process worked, no notice that the CA service didn't restart. Did you try to restart the CA with selinux in permissive mode? This is still required right now until I get the selinux policy all straightened out. There is also a separate dogtag ticket (which is currently being worked on) to restart existing dogtag instances when dogtag is upgraded from 9->10. In permissive mode, this upgrade works for me. I was in enforcing mode but saw no AVCs. What is the ETA on fixing this? Within the next week or two, I need to finish the IPA merge database patch first, and then co-ordinate changes with the selinux guys. Sometimes I do get this error intermittently: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Temporarily Unavailable) Usually, waiting a couple of minutes clears this up. Perhaps we are not doing startup detection correctly. Ade mentioned that waiting for ports may not be ideal. How do we know if Dogtag is initialized? Years ago we had discussed with Andrew and Matt creating a URI that can be queried to determine dogtag status. I don't think that ever went anywhere. Petr, this happens only on reboot, right? And not on regular "service ipa restart"? I've now seen it happen right after a 9 → 10 upgrade. Yeah, I remember this conversation - and even created a bug for it at some point. This went away because the mechanism you were using seemed to be working. The timing may be very different now with tomcat 7 and systemd. I'll open a dogtag trac ticket for this. Ok. Uninstalling failed because it tried to run pkidestroy and not pkiremove. I was under the impression that pkidestroy was the correct command to remove an upgraded instance. I'll check with Ade. I'll test this too. The contents of the file passed to pkispawn should be logged so we can see exactly what was passed in. Its a pretty big file. You might want to only log the modifications. Or save the file somewhere. Our logs are pretty verbose, so that shouldn't be a problem. I'll put it in the next version of the patch. The question to ask is: would you need the contents of this file if all you got were logs and needed to evaluate why installation failed? In most cases this is yes. Up to you guys. There is a patch I am working on in which I will be logging the object that is being passed to the server from pkispawn. That - and the diffs to the standard config file as I mentioned above - will likely be sufficient to debug almost all cases. Make sure not to log any passwords. Thanks for the catch. Attaching updated patch that sanitizes the passwords. DOGTAG: When upgrading using the dogtag-devel repo I had to specify pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit versions (and failed). I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64 --enablerepo=dogtag-devel --enablerepo=updates-testing We'll look into this. I think I know why this happens. What happens if someone manually upgrades pki-ca without first
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-09-12 at 18:43 +0200, Petr Viktorin wrote: > On 09/11/2012 09:38 PM, Rob Crittenden wrote: > > Rob Crittenden wrote: > >> Rob Crittenden wrote: > >>> Petr Viktorin wrote: > On 09/11/2012 04:38 PM, Rob Crittenden wrote: > > Ade Lee wrote: > >> On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote: > >>> Petr Viktorin wrote: > On 09/11/2012 04:04 AM, Ade Lee wrote: > > On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: > >> Petr Viktorin wrote: > >>> Attaching rebased and squashed patches. I've done some testing > >>> with > >>> them > >>> but please test some more. > >>> > >> > >> Most of these aren't IPA issues, but dogtag issues. I'll try to > >> split > >> them out. > >> > >> IPA: > >> > >> For the configuration files in install/conf to be updated at rpm > >> update > >> time the VERSION needs to be incremented. > > These files should stay the same since on upgrade we're still > using a > Dogtag 9 style instance. The Dogtag 10 ports are only used in new > installs. > > >> The ipa package lacks any updated dogtag dependencies, so I > >> abused > >> it. > > What should the updated dependencies be? Since it should work with > both > dogtag 9 and 10, I don't see how they should change. > >>> > >>> I don't know either, but we need to prevent people from installing > >>> incompatible package combinations. > >>> > >> Would'nt the Conflicts: ipa < 3.0 in pki-ca mentioned below satisfy > >> this > >> requirement? The main concern is that you must have ipa 3.0 if you > >> have > >> dogtag 10. > >> > >> Given that dogtag is consumed by IPA though, it makes more sense to > >> put > >> the relevant conflicts in IPA rather than in dogtag. So in this > >> case, > >> that would mean putting Conflicts: pki-ca >= 10.0 in IPA 2.x. > >> Recall that dogtag 10 will only be officially available in f18+. > > > > That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to > > F-18 they would be able to install dogtag 10 and blow up their IPA > > server. > > > >> > >> I installed IPA with dogtag 9 and created a replica. > >> > >> I updated the IPA bits, that worked fine. > >> > >> I updated to dogtag 10 and now the CA doesn't work on the master, > >> including starting the dogtag instance. Note that the rpm update > >> process > >> worked, no notice that the CA service didn't restart. > >> > > Did you try to restart the CA with selinux in permissive mode? > > This is > > still required right now until I get the selinux policy all > > straightened > > out. > > > > There is also a separate dogtag ticket (which is currently being > > worked > > on) to restart existing dogtag instances when dogtag is upgraded > > from > > 9->10. > > In permissive mode, this upgrade works for me. > >>> > >>> I was in enforcing mode but saw no AVCs. What is the ETA on fixing > >>> this? > >>> > >> > >> Within the next week or two, I need to finish the IPA merge database > >> patch first, and then co-ordinate changes with the selinux guys. > >> > > > Sometimes I do get this error intermittently: > > ipa: ERROR: Certificate operation cannot be completed: Unable to > communicate with CMS (Service Temporarily Unavailable) > > Usually, waiting a couple of minutes clears this up. Perhaps we are > not > doing startup detection correctly. Ade mentioned that waiting for > ports > may not be ideal. How do we know if Dogtag is initialized? > >>> > >>> Years ago we had discussed with Andrew and Matt creating a URI that > >>> can > >>> be queried to determine dogtag status. I don't think that ever went > >>> anywhere. > >>> > >> Petr, this happens only on reboot, right? And not on regular > >> "service > >> ipa restart"? > > I've now seen it happen right after a 9 → 10 upgrade. > > >> Yeah, I remember this conversation - and even created a bug for it at > >> some point. This went away because the mechanism you were using > >> seemed > >> to be working. The timing may be very different now with tomcat 7 > >> and > >> systemd. I'll open a dogtag trac ticket for this. > > > > Ok. > > > >> > > >> Uninstalling failed because it tried to run pkidestroy and not > >> pkiremove. > > I was under the impression that pkidestroy was the corre
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 09/11/2012 09:20 PM, Rob Crittenden wrote: Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:38 PM, Rob Crittenden wrote: Ade Lee wrote: On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:04 AM, Ade Lee wrote: On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: Petr Viktorin wrote: Attaching rebased and squashed patches. I've done some testing with them but please test some more. Most of these aren't IPA issues, but dogtag issues. I'll try to split them out. IPA: For the configuration files in install/conf to be updated at rpm update time the VERSION needs to be incremented. These files should stay the same since on upgrade we're still using a Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs. The ipa package lacks any updated dogtag dependencies, so I abused it. What should the updated dependencies be? Since it should work with both dogtag 9 and 10, I don't see how they should change. I don't know either, but we need to prevent people from installing incompatible package combinations. Would'nt the Conflicts: ipa < 3.0 in pki-ca mentioned below satisfy this requirement? The main concern is that you must have ipa 3.0 if you have dogtag 10. Given that dogtag is consumed by IPA though, it makes more sense to put the relevant conflicts in IPA rather than in dogtag. So in this case, that would mean putting Conflicts: pki-ca >= 10.0 in IPA 2.x. Recall that dogtag 10 will only be officially available in f18+. That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to F-18 they would be able to install dogtag 10 and blow up their IPA server. I installed IPA with dogtag 9 and created a replica. I updated the IPA bits, that worked fine. I updated to dogtag 10 and now the CA doesn't work on the master, including starting the dogtag instance. Note that the rpm update process worked, no notice that the CA service didn't restart. Did you try to restart the CA with selinux in permissive mode? This is still required right now until I get the selinux policy all straightened out. There is also a separate dogtag ticket (which is currently being worked on) to restart existing dogtag instances when dogtag is upgraded from 9->10. In permissive mode, this upgrade works for me. I was in enforcing mode but saw no AVCs. What is the ETA on fixing this? Within the next week or two, I need to finish the IPA merge database patch first, and then co-ordinate changes with the selinux guys. Sometimes I do get this error intermittently: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Temporarily Unavailable) Usually, waiting a couple of minutes clears this up. Perhaps we are not doing startup detection correctly. Ade mentioned that waiting for ports may not be ideal. How do we know if Dogtag is initialized? Years ago we had discussed with Andrew and Matt creating a URI that can be queried to determine dogtag status. I don't think that ever went anywhere. Petr, this happens only on reboot, right? And not on regular "service ipa restart"? I've now seen it happen right after a 9 → 10 upgrade. Yeah, I remember this conversation - and even created a bug for it at some point. This went away because the mechanism you were using seemed to be working. The timing may be very different now with tomcat 7 and systemd. I'll open a dogtag trac ticket for this. Ok. Uninstalling failed because it tried to run pkidestroy and not pkiremove. I was under the impression that pkidestroy was the correct command to remove an upgraded instance. I'll check with Ade. I'll test this too. The contents of the file passed to pkispawn should be logged so we can see exactly what was passed in. Its a pretty big file. You might want to only log the modifications. Or save the file somewhere. Our logs are pretty verbose, so that shouldn't be a problem. I'll put it in the next version of the patch. The question to ask is: would you need the contents of this file if all you got were logs and needed to evaluate why installation failed? In most cases this is yes. Up to you guys. There is a patch I am working on in which I will be logging the object that is being passed to the server from pkispawn. That - and the diffs to the standard config file as I mentioned above - will likely be sufficient to debug almost all cases. Make sure not to log any passwords. Thanks for the catch. Attaching updated patch that sanitizes the passwords. DOGTAG: When upgrading using the dogtag-devel repo I had to specify pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit versions (and failed). I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64 --enablerepo=dogtag-devel --enablerepo=updates-testing We'll look into this. I think I know why this happens. What happens if someone manually upgrades pki-ca without first updating ipa? I think t
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Petr Viktorin wrote:
On 09/12/2012 06:40 PM, Petr Viktorin wrote:
A new Dogtag build with changed pkispawn/pkidestroy locations should be
out later today. The attached patch should work with that build.
Fresh install is failing in F-18.
ki-tools-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.i686
pki-base-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch
pki-server-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch
pki-silent-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch
pki-symkey-9.0.21-1.fc18.x86_64
dogtag-pki-ca-theme-10.0.0-0.1.a1.20120914T0604zgit69c0684.fc18.noarch
pki-selinux-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch
pki-ca-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch
pki-setup-9.0.21-1.fc18.noarch
rob
2012-09-14T21:16:16Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2012-09-14T21:16:16Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index'
2012-09-14T21:16:16Z DEBUG httpd is not configured
2012-09-14T21:16:16Z DEBUG kadmin is not configured
2012-09-14T21:16:16Z DEBUG dirsrv is not configured
2012-09-14T21:16:16Z DEBUG pki-cad is not configured
2012-09-14T21:16:16Z DEBUG pki-tomcatd is not configured
2012-09-14T21:16:16Z DEBUG pkids is not configured
2012-09-14T21:16:16Z DEBUG install is not configured
2012-09-14T21:16:16Z DEBUG krb5kdc is not configured
2012-09-14T21:16:16Z DEBUG ntpd is not configured
2012-09-14T21:16:16Z DEBUG named is not configured
2012-09-14T21:16:16Z DEBUG ipa_memcached is not configured
2012-09-14T21:16:16Z DEBUG filestore is tracking no files
2012-09-14T21:16:16Z DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
2012-09-14T21:16:16Z DEBUG /usr/sbin/ipa-server-install was invoked with options: {'zone_refresh': 0, 'reverse_zone': None, 'setup_pkinit': True, 'realm_name': None, 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, 'subject': None, 'no_forwarders': False, 'persistent_search': True, 'ui_redirect': True, 'domain_name': None, 'idmax': 0, 'hbac_allow': False, 'no_reverse': False, 'dirsrv_pkcs12': None, 'unattended': False, 'pkinit_pkcs12': None, 'selfsign': False, 'trust_sshfp': False, 'external_ca_file': None, 'no_host_dns': False, 'http_pkcs12': None, 'zone_notif': False, 'forwarders': None, 'idstart': 68480, 'external_ca': False, 'ip_address': None, 'conf_ssh': True, 'serial_autoincrement': True, 'zonemgr': None, 'setup_dns': True, 'host_name': None, 'debug': False, 'external_cert_file': None, 'uninstall': False, 'pkinit_pin': None}
2012-09-14T21:16:16Z DEBUG missing options might be asked for interactively later
2012-09-14T21:16:16Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index'
2012-09-14T21:16:16Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2012-09-14T21:16:16Z DEBUG Check if stinky.greyoak.com is a primary hostname for localhost
2012-09-14T21:16:16Z DEBUG Primary hostname for localhost: stinky.greyoak.com
2012-09-14T21:16:16Z DEBUG will use host_name: stinky.greyoak.com
2012-09-14T21:16:16Z DEBUG read domain_name: greyoak.com
2012-09-14T21:16:16Z DEBUG args=/sbin/ip -family inet -oneline address show
2012-09-14T21:16:16Z DEBUG stdout=1: loinet 127.0.0.1/8 scope host lo
2: eth0inet 192.168.196.7/24 brd 192.168.196.255 scope global eth0
2012-09-14T21:16:16Z DEBUG stderr=
2012-09-14T21:16:16Z DEBUG read realm_name: GREYOAK.COM
2012-09-14T21:16:21Z DEBUG will use dns_forwarders: ['192.168.186.1']
2012-09-14T21:16:21Z DEBUG importing all plugin modules in '/usr/lib/python2.7/site-packages/ipalib/plugins'...
2012-09-14T21:16:21Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py'
2012-09-14T21:16:21Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py'
2012-09-14T21:16:21Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py'
2012-09-14T21:16:21Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py'
2012-09-14T21:16:21Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py'
2012-09-14T21:16:21Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py'
2012-09-14T21:16:21Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/config.py'
2012-09-14T21:16:21Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py'
2012-09-14T21:16:21Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py'
2012-09-14T21:16:21Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/entitle.py'
2012-09-14T21:16:22Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/group.py'
2012-09-14T21:16:22Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py'
2012-09-14T21:16:22Z DEBUG importing plugin module '/usr/lib
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 09/14/2012 11:19 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 09/12/2012 06:40 PM, Petr Viktorin wrote: A new Dogtag build with changed pkispawn/pkidestroy locations should be out later today. The attached patch should work with that build. Fresh install is failing in F-18. ki-tools-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.i686 pki-base-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch pki-server-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch pki-silent-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch pki-symkey-9.0.21-1.fc18.x86_64 dogtag-pki-ca-theme-10.0.0-0.1.a1.20120914T0604zgit69c0684.fc18.noarch pki-selinux-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch pki-ca-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch pki-setup-9.0.21-1.fc18.noarch rob Ade, your patch adds a step of moving /var/lib/pki/pki-tomcat/alias/ca_admin_cert.p12 to /root/ca-agent.p12 right after calling pkispawn. It seems the file is not created on f18. Did something change in Dogtag or are we calling it incorrectly? -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Mon, 2012-09-17 at 14:32 +0200, Petr Viktorin wrote: > On 09/14/2012 11:19 PM, Rob Crittenden wrote: > > Petr Viktorin wrote: > >> On 09/12/2012 06:40 PM, Petr Viktorin wrote: > >>> A new Dogtag build with changed pkispawn/pkidestroy locations should be > >>> out later today. The attached patch should work with that build. > > > > Fresh install is failing in F-18. > > > > ki-tools-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.i686 > > pki-base-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch > > pki-server-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch > > pki-silent-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch > > pki-symkey-9.0.21-1.fc18.x86_64 > > dogtag-pki-ca-theme-10.0.0-0.1.a1.20120914T0604zgit69c0684.fc18.noarch > > pki-selinux-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch > > pki-ca-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch > > pki-setup-9.0.21-1.fc18.noarch > > > > > > rob > > > > > > Ade, your patch adds a step of moving > /var/lib/pki/pki-tomcat/alias/ca_admin_cert.p12 to /root/ca-agent.p12 > right after calling pkispawn. > It seems the file is not created on f18. Did something change in Dogtag > or are we calling it incorrectly? > The failure of that step often indicates a failure of the previous configure() step. That is - moving that file fails because it was not created, because configuration fails. Rob's logs seem to indicate some kind of classpath issue with the jython code in pkispawn which calls configure() on the server. I set up an f18 machine and was able to configure an instance (outside of IPA) Will now try with the ipa code (and your patches) to see if I can reproduce. Ade > ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Mon, 2012-09-17 at 14:32 +0200, Petr Viktorin wrote: > On 09/14/2012 11:19 PM, Rob Crittenden wrote: > > Petr Viktorin wrote: > >> On 09/12/2012 06:40 PM, Petr Viktorin wrote: > >>> A new Dogtag build with changed pkispawn/pkidestroy locations should be > >>> out later today. The attached patch should work with that build. > > > > Fresh install is failing in F-18. > > > > ki-tools-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.i686 > > pki-base-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch > > pki-server-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch > > pki-silent-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch > > pki-symkey-9.0.21-1.fc18.x86_64 > > dogtag-pki-ca-theme-10.0.0-0.1.a1.20120914T0604zgit69c0684.fc18.noarch > > pki-selinux-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch > > pki-ca-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch > > pki-setup-9.0.21-1.fc18.noarch > > > > > > rob > > > > > > Ade, your patch adds a step of moving > /var/lib/pki/pki-tomcat/alias/ca_admin_cert.p12 to /root/ca-agent.p12 > right after calling pkispawn. > It seems the file is not created on f18. Did something change in Dogtag > or are we calling it incorrectly? > > Just for the record, as discussed on IRC, the problem is that the latest build of apache-commons-codec (1.6.4) is missing the /usr/share/java/apache-commons-codec.jar symlink. A bug has been filed https://bugzilla.redhat.com/show_bug.cgi?id=857947 and is being addressed. Until a new build of apache-commons-codec is available, you can use the workaround of creating the missing link: ln -s /usr/share/java/commons-codec.jar /usr/share/java/apache-commons-codec.jar Also, there is a bug where pkispawn requires pki-symkey to be installed in order to complete. We will fix pkispawn to not require this - because its only needed for the TKS, and deliver that in a subsequent build. For now though, just make sure pki-symkey is installed. We'll do a new build once you guys have had a chance to try the current build out a bit and report issues. Ade ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
