[Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Ade Lee
alee at redhat.com
Wed Aug 29 12:48:32 UTC 2012
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
> > >>>>>>>>>>>>>> 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 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?
> > >>>>>>>>>>
> > >>>>>>>>> OK -- I tested this out and realized that between the time I
> > >>>>>>>>> initially
> > >>>>>>>>> tested this and your tests, we had changed a URL
> > >>>>>>>>> from /ca/pki/installer/installToken to
> > >>>>>>>>> /ca/rest/installer/installToken,
> > >>>>>>>>> but I forgot to update ipa-pki-proxy.conf.
> > >>>>>>>>>
> > >>>>>>>>> The new patch has been rebased and changes the relevant patch.
> > >>>>>>>>> With
> > >>>>>>>>> this, the CA replica installs correctly.
> > >>>>>>>>
> > >>>>>>>> Umh, where can I find the new rebased patch? :-)
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> There was one issue that I encountered. I have seen this once
> > >>>>>>>>> before
> > >>>>>>>>> and will need to investigate further. IPA sometimes restarts
> > >>>>>>>>> the dogtag
> > >>>>>>>>> instance by doing systemctl stop pki-tomcatd.target. and then
> > >>>>>>>>> systemctl
> > >>>>>>>>> start pki-tomcatd.target. I have noticed that occasionally the
> > >>>>>>>>> start
> > >>>>>>>>> invocation fails, while the stop and restart invocations succeed
> > >>>>>>>>> just
> > >>>>>>>>> fine. This makes absolutely no sense because restart is
> > >>>>>>>>> essentially
> > >>>>>>>>> just stop and then start.
> > >>>>>>>>>
> > >>>>>>>>> I think this is actually a bug in systemd. If I reboot the
> > >>>>>>>>> machine, it
> > >>>>>>>>> all works perfectly. If we can't figure out whats going on with
> > >>>>>>>>> systemd, we can always replace this start/stop with
> > >>>>>>>>> starting/stopping
> > >>>>>>>>> the service directly. (pki-tomcatd at pki-tomcat.service). That
> > >>>>>>>>> seems to
> > >>>>>>>>> work all the time with no problems.
> > >>>>>>>>>
> > >>>>>>>>> I suggest we leave this fix (if needed) for a separate patch.
> > >>>>>>>>
> > >>>>>>>> Ok, I will see if I hit this issue again. Btw. is it recommended
> > >>>>>>>> in systemd to
> > >>>>>>>> use target units this way? I thought that only service files are
> > >>>>>>>> meant to be
> > >>>>>>>> used for manipulation with a service. As you said yourself, using
> > >>>>>>>> service unit
> > >>>>>>>> file for restart worked every time.
> > >>>>>>>>
> > >>>>>>>> Martin
> > >>>>>>>
> > >>>>>>
> > >>>>>> Now, I tested the rebased patch with VMs with permissive SELinux.
> > >>>>>> IPA server
> > >>>>>> install was OK, as always, but replica installation ended up with
> > >>>>>> error.
> > >>>>>> Although it got much further than before:
> > >>>>>>
> > >>>>>> # ipa-ca-install
> > >>>>>> /home/mkosek/replica-info-vm-114.idm.lab.bos.redhat.com.gpg
> > >>>>>> ...
> > >>>>>> [3/3]: restarting directory server
> > >>>>>> done configuring pkids.
> > >>>>>> Configuring certificate server: Estimated time 3 minutes 30 seconds
> > >>>>>> [1/14]: creating certificate server user
> > >>>>>> [2/14]: configuring certificate server instance
> > >>>>>> [3/14]: disabling nonces
> > >>>>>> [4/14]: importing CA chain to RA certificate database
> > >>>>>> [5/14]: fixing RA database permissions
> > >>>>>> [6/14]: setting up signing cert profile
> > >>>>>> [7/14]: set up CRL publishing
> > >>>>>> [8/14]: set certificate subject base
> > >>>>>> [9/14]: enabling Subject Key Identifier
> > >>>>>> [10/14]: configuring certificate server to start on boot
> > >>>>>> [11/14]: configure certmonger for renewals
> > >>>>>> [12/14]: configure clone certificate renewals
> > >>>>>> [13/14]: configure Server-Cert certificate renewal
> > >>>>>> [14/14]: Configure HTTP to proxy connections
> > >>>>>> done configuring pki-tomcatd.
> > >>>>>> Restarting the directory and certificate servers
> > >>>>>>
> > >>>>>> Your system may be partly configured.
> > >>>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
> > >>>>>>
> > >>>>>> It seems like that CA on a replica did not start and so a check for
> > >>>>>> port 8080
> > >>>>>> failed. Attached logs (pki-ca-logs.tgz) may provide more
> > >>>>>> information to this issue.
> > >>>>>>
> > >>>>> This is the systemd issue I mentioned before. I will submit a patch
> > >>>>> which will change the restart mechanism to restart the service and not
> > >>>>> the target.
> > >>>>>>
> > >>>>
> > >>>> Patch attached. This patch should be applied on top of the large patch
> > >>>> (being reviewed).
> > >>>>
> > >>>>>> Now I am also testing upgrade from IPA+dogtag9 to PatchedIPA+dogtag10
> > >>>>>> (permissive SELinux). Now, the service was upgraded smoothly, CA
> > >>>>>> service
> > >>>>>> could be restarted without failure. However, certificate operations
> > >>>>>> now
> > >>>>>> did not work:
> > >>>>>>
> > >>>>>> # ipactl restart
> > >>>>>> Restarting Directory Service
> > >>>>>> Restarting KDC Service
> > >>>>>> Restarting KPASSWD Service
> > >>>>>> Restarting MEMCACHE Service
> > >>>>>> Restarting HTTP Service
> > >>>>>> Restarting CA Service
> > >>>>>> # ipactl status
> > >>>>>> Directory Service: RUNNING
> > >>>>>> KDC Service: RUNNING
> > >>>>>> KPASSWD Service: RUNNING
> > >>>>>> MEMCACHE Service: RUNNING
> > >>>>>> HTTP Service: RUNNING
> > >>>>>> CA Service: RUNNING
> > >>>>>> # ipa cert-show 1
> > >>>>>> ipa: ERROR: Certificate operation cannot be completed: Unable to
> > >>>>>> communicate with CMS (Internal Server Error)
> > >>>>>>
> > >>>>>> Attaching logs for this case as well (ipa-ca-logs-upgrade.tgz).
> > >>>>>>
> > >>>>> The reason for this is that the old dogtag instances are missing:
> > >>>>> 1. a new parameter in CS.cfg
> > >>>>> 2. a couple of symlinks
> > >>>>>
> > >>>>> I plan to fix this in the dogtag code. Specifically,
> > >>>>> 1. I will modify the dogtag code to provide a default value in the
> > >>>>> case
> > >>>>> where the parameter does not exist.
> > >>>>> 2. I plan to add a function to the dogtag startup scripts to check and
> > >>>>> remake any required symlinks.
> > >>>>>
> > >>>>> Both of these changes are in the dogtag code, and do not affect this
> > >>>>> patch. As a workaround, to confirm that the upgrade actually
> > >>>>> works, do
> > >>>>> the following manual steps on your upgraded instance:
> > >>>>>
> > >>>>> 1. Add the following parameter to CS.cfg
> > >>>>> pidDir=/var/run
> > >>>>>
> > >>>>> 2. Add the following links;
> > >>>>> cd /var/lib/pki-ca/common/lib
> > >>>>> ln -s /usr/share/java/apache-commons-codec.jar
> > >>>>> apache-commons-codec.jar
> > >>>>> ln -s /usr/share/java/log4j.jar log4j.jar
> > >>>>>
> > >>>>> 3 Restart the dogtag instance
> > >>>>
> > >>>
> > >>> To throw a little twist in here, we should make sure that the
> > >>> certmonger restart scripts still work as well.
> > >>>
> > >>> rob
> > >>>
> > >>> _______________________________________________
> > >>> Freeipa-devel mailing list
> > >>> Freeipa-devel at redhat.com
> > >>> https://www.redhat.com/mailman/listinfo/freeipa-devel
> > >>
> > >> What is the situation with this patch? Was it commited? Or is it in
> > >> works/review? Was is superseded by another patch (that I have not got to
> > >> yet and thus asking)?
> > >>
> > >
> > > I am finishing and testing a patch to apply on top, which will make it
> > > possible to use either Dogtag 9 or 10 depending on what's installed.
> > >
> >
> > I don't know if the CA renewal issue has been addressed yet. It may
> > impact certmonger because the ports are hardcoded in the certmonger
> > source. I was under the impression Ade was looking into this and would
> > open a certmonger bug as needed.
> >
> > rob
> >
> > _______________________________________________
> > Freeipa-devel mailing list
> > Freeipa-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-devel
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
More information about the Freeipa-devel
mailing list