#8347 Several replica installations without reboot
Opened 3 years ago by slev. Modified 3 years ago

My test case:
1) install master
2) install replica
3) do tests
4) uninstall replica and master
5) don't reboot machines
6) install master - OK
7) install replica - FAIL

Error message (logs are attached):

ldap.LOCAL_ERROR: {'desc': 'Local error', 'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Decrypt integrity check failed)'}

Diff ok/fail:

2020-06-03T06:34:33Z DEBUG KRB5CCNAME set to None
2020-06-03T06:34:33Z DEBUG Failed to find default ccache: Major (851968): Unspecified GSS failure.  Minor code may provide more information, Minor (2529639053): No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_0)

-------------------------------------------------------------------------------------------------------------------------

2020-06-03T06:51:24Z DEBUG KRB5CCNAME set to None
2020-06-03T06:51:24Z DEBUG Destroyed connection context.ldap2_140516079436608
2020-06-03T06:51:24Z DEBUG Traceback (most recent call last):
  File "/usr/lib64/python3/site-packages/ipapython/ipaldap.py", line 1076, in error_handler
    yield
  File "/usr/lib64/python3/site-packages/ipapython/ipaldap.py", line 1247, in gssapi_bind
    self.conn.sasl_interactive_bind_s(
  File "/usr/lib64/python3/site-packages/ldap/ldapobject.py", line 467, in sasl_interactive_bind_s
    return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags)
  File "/usr/lib64/python3/site-packages/ldap/ldapobject.py", line 331, in _ldap_call
    reraise(exc_type, exc_value, exc_traceback)
  File "/usr/lib64/python3/site-packages/ldap/compat.py", line 44, in reraise
    raise exc_value
  File "/usr/lib64/python3/site-packages/ldap/ldapobject.py", line 315, in _ldap_call
    result = func(*args,**kwargs)
ldap.LOCAL_ERROR: {'desc': 'Local error', 'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Decrypt integrity check failed)'}

kdc log:

Jun 03 06:51:24 master1.ipa.test krb5kdc[56122](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 172.18.0.4: PROCESS_TGS: authtime 0,  <unknown client> for ldap/master1.ipa.test@IPA.TEST, Decrypt integrity check failed
Jun 03 06:51:24 master1.ipa.test krb5kdc[56122](info): closing down fd 11
Jun 03 06:51:24 master1.ipa.test krb5kdc[56122](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 172.18.0.4: PROCESS_TGS: authtime 0,  <unknown client> for ldap/master1.ipa.test@IPA.TEST, Decrypt integrity check failed
Jun 03 06:51:24 master1.ipa.test krb5kdc[56122](info): closing down fd 11

I guess there already was ccache /tmp/krb5cc_0 (retained after the first installation), which has been passed
ipaserver/install/installutils.py:check_creds

1) Is this mode of operation supported or reboot is the strict requirement?
2) should check_creds be fixed?


reboot is not required. kdestroy -A would do it. The reboot is wiping /tmp which is doing effectively the same thing (though why FILE and not KCM or keyring is being used I'm not sure).

The problem is that on replica install it can be ok to have a pre-existing ccache so it can't be cleaned automatically. The ticket was probably even still valid (for the previous incarnation).

I'd have sworn we had a ticket on cleaning ccaches on uninstall. We could alternatively do a kdestroy -p < princ> on uninstall for the realm going away.

Which commands did you use the install the replica? Did you ipa-client-install and then upgraded the server to a replica? Or did you run ipa-replica-install with username and password?

tasks.install_replica(..., promote=False)

Login to comment on this ticket.

Metadata
Attachments 3
Attached 3 years ago View Comment