#4084 ipa-client-install part of ipa-server-install fails on reinstall
Closed: Fixed None Opened 10 years ago by pviktori.

Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 1044994

Description of problem:

The second installation of IPA on the same server (after the first one has been
removed using ipa-server-install --uninstall) fails with:

<DEBUG>: Done configuring the web interface (httpd).
<DEBUG>: Applying LDAP updates
<DEBUG>: Restarting the directory server
<DEBUG>: Restarting the KDC
<DEBUG>: Configuring DNS (named)
<DEBUG>:   [1/11]: adding DNS container
<DEBUG>:   [2/11]: setting up our zone
<DEBUG>:   [3/11]: setting up reverse zone
<DEBUG>:   [4/11]: setting up our own record
<DEBUG>:   [5/11]: setting up records for other masters
<DEBUG>:   [6/11]: setting up CA record
<DEBUG>:   [7/11]: setting up kerberos principal
<DEBUG>:   [8/11]: setting up named.conf
<DEBUG>:   [9/11]: restarting named
<DEBUG>:   [10/11]: configuring named to start on boot
<DEBUG>:   [11/11]: changing resolv.conf to point to ourselves
<DEBUG>: Done configuring DNS (named).
<DEBUG>:
<DEBUG>: Global DNS configuration in LDAP server is empty
<DEBUG>: You can use 'dnsconfig-mod' command to set global DNS options that
<DEBUG>: would override settings in local named.conf files
<DEBUG>:
<DEBUG>: Restarting the web server
<DEBUG>: Configuration of client side components failed!
<DEBUG>: ipa-client-install returned: Command '/usr/sbin/ipa-client-install
--on-master --unattended --domain dom227.jenkinsad.idm.lab.eng.brq.redhat.com
--server vm-227.dom227.jenkinsad.idm.lab.eng.brq.redhat.com --realm
DOM227.JENKINSAD.IDM.LAB.ENG.BRQ.REDHAT.COM --hostname
vm-227.dom227.jenkinsad.idm.lab.eng.brq.redhat.com' returned non-zero exit
status 1

Version-Release number of selected component (if applicable):

master

How reproducible:

always

Steps to Reproduce:
1. Install IPA
2. Uninstall IPA
3. Install IPA

Actual results:

Second IPA installation fails with:

ipa-client-install returned: Command '/usr/sbin/ipa-client-install --on-master
--unattended --domain dom227.jenkinsad.idm.lab.eng.brq.redhat.com --server
vm-227.dom227.jenkinsad.idm.lab.eng.brq.redhat.com --realm
DOM227.JENKINSAD.IDM.LAB.ENG.BRQ.REDHAT.COM --hostname
vm-227.dom227.jenkinsad.idm.lab.eng.brq.redhat.com' returned non-zero exit
status 1


Expected results:

Second IPA installation succeeds.

Additional info:

There's nothing interesting in the journalctl at the time of the failure, all
services are up and running.

The actual failure happens in our wsgi.py script:

(from httpd's error_log)
GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information
(Decrypt integrity check failed)

wsgi.py uses /etc/httpd/conf/ipa.keytab and by the timestamp this comes from
the second installation.

This looks similiar to https://fedorahosted.org/freeipa/ticket/2395, but adding
a call to clean httpd's cache on uninstall (along the lines of https://git.fedo
rahosted.org/cgit/freeipa.git/commit/?id=08413612d485b02294c3bf570fd167a340f11a
c9) makes no difference. Additionaly, there are no non-empty ccache files in
/tmp or /tmp/systemd-httpd.service-*/


(from dirsrv's access log)

[19/Dec/2013:00:17:58 +0100] conn=13 fd=69 slot=69 connection from 10.34.47.227
to 10.34.47.227
[19/Dec/2013:00:17:58 +0100] conn=2 op=38 SRCH
base="dc=dom227,dc=jenkinsad,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com"
scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(kr
bPrincipalName=krbtgt/DOM227.JENKINSAD.IDM.LAB.ENG.BRQ.REDHAT.COM@DOM227.JENKIN
SAD.IDM.LAB.ENG.BRQ.REDHAT.COM))" attrs="krbPrincipalName krbCanonicalName
ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference
krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference
krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases
krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData
krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife
krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData
ipaUserAuthType objectClass"
[19/Dec/2013:00:17:58 +0100] conn=2 op=38 RESULT err=0 tag=101 nentries=1
etime=0
[19/Dec/2013:00:17:58 +0100] conn=2 op=39 SRCH
base="dc=dom227,dc=jenkinsad,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com"
scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(kr
bPrincipalName=krbtgt/DOM227.JENKINSAD.IDM.LAB.ENG.BRQ.REDHAT.COM@DOM227.JENKIN
SAD.IDM.LAB.ENG.BRQ.REDHAT.COM))" attrs="krbPrincipalName krbCanonicalName
ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference
krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference
krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases
krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData
krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife
krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData
ipaUserAuthType objectClass"
[19/Dec/2013:00:17:58 +0100] conn=2 op=39 RESULT err=0 tag=101 nentries=1
etime=0
[19/Dec/2013:00:17:58 +0100] conn=13 op=0 UNBIND
[19/Dec/2013:00:17:58 +0100] conn=13 op=0 fd=69 closed - U1

Note that this seems to only happen in this specific environment (which is thankfully repeatable and Red Hat IPA team has access to it). Whe I re-install by hand on my testing VM, everything is fine.

Tomas, if you have access to the machine, can you please work on this one?

I have a patch ready. It simply lets ipa to avoid using custom CCACHE for HTTPD process, but rather allows it to use the default one. It is then always cleared during installation to avoid stale keyring ccache issue.

This patch is also needed:

master: f49c26d

One more improvement based on Simo's recommendation:[[BR]]
master: b7f1531

Metadata Update from @pviktori:
- Issue assigned to mkosek
- Issue set to the milestone: FreeIPA 4.0 - 2014/01

7 years ago

Login to comment on this ticket.

Metadata