On Tue, 19 Jan 2016, Simpson Lachlan wrote:
-----Original Message-----
From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-

Iā€™m coming back to this thread for consistency, but is a result of me
running ipactl on the system we got working a couple of hours ago. See
email titled "idoverride-add gives incorrect, inconsistant results?"
for leadup.

Anyway, ipactl restart fails, again.

[root@vmts-linuxidm ~]# ipactl restart
Stopping pki-tomcatd Service
Restarting Directory Service
Restarting krb5kdc Service
Restarting kadmin Service
Restarting ipa_memcached Service
Restarting httpd Service
Restarting pki-tomcatd Service
inconsistRestarting winbind Service
Restarting ipa-otpd Service
Starting smb Service
Job for smb.service failed because the control process exited with error code. See "systemctl 
status smb.service" and "journalctl -xe" for details.
Failed to start smb Service
Shutting down
Aborting ipactl

Gah. Look in the samba log, and it's exactly the same issue.


[root@vmts-linuxidm ~]# ipa-adtrust-install --netbios-name=UNIX -a xxxxxxx

The log file for this installation can be found in 
This program will setup components needed to establish trust to AD domains for
the IPA Server.

This includes:
 * Configure Samba
 * Add trust related objects to IPA LDAP server

To accept the default shown in brackets, press the Enter key.

IPA generated smb.conf detected.
Overwrite smb.conf? [no]: yes
Do you want to enable support for trusted domains in Schema Compatibility 
This will allow clients older than SSSD 1.9 and non-Linux clients to work with 
trusted users.

Enable trusted domains support in slapi-nis? [no]: yes

There was error to automatically re-kinit your admin user ticket.
Proceeding with credentials that existed before
Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket


[root@vmts-linuxidm ~]# kdestroy
[root@vmts-linuxidm ~]# kinit admin
kinit: Cannot contact any KDC for realm 'UNIX.CO.ORG.AU' while getting initial 

I check, and sure enough, dir...@unix.co.org.au has stopped again
(should I call it 389, dirsrv, ldap or slapd? They are all the same
thing, right?).

I restart dirsrv, and try restarting smb, no joy. I try running
ipa-adtrust-install again, without luck. I restart krb5kdc manually (sc
start krb5kdc), and try all the above again, with no luck.

kdestroy has a lovely little pause, but kinit admin fails.

Some of the other errors I've received:


There was error to automatically re-kinit your admin user ticket.
Proceeding with credentials that existed before
Must have Kerberos credentials to setup AD trusts on serve

klist: Credentials cache keyring 'persistent:0:0' not found

Ok, so I try sc start krb5kdc and that works. Now klist still returns
the above error, but kinit admin works. And ipa-adtrust-install works
as it did this AM (output at end for reference).


- I can now browse the IPA server via a web browser.
- I can retrieve credentials for those that I've already retrieved credentials 
for (id testu...@co.org.au works)
- I can't retrieve new credentials (id testuser_...@co.org.au does not work ("no 
such user")
- if I sc --failed:

ā— ipa.service     loaded    failed failed Identity, Policy, Audit
ā— kadmin.service  loaded    failed failed Kerberos 5 Password-changing and 
ā— smb.service     loaded    failed failed Samba SMB Daemon

- None of these will start on their own (with sc start <name>.service)

- trying to start ipa fails with the added bonus of shutting down
krb5kdc / kadmin / dir...@domain.org.au as well? I'm finding I'm
needing to restart these services after attempting an ipa start. Which
is failing on smb still.

- krb5kdc also doesn't start.

I am so confused. Earlier in the day when it was "working", I noticed
that there was a service running called ipa.memchached - I presume
that's why I can get some id's and not others and can browse via web
(well, that just means tomcat started correctly, right?). ipa.memcached
has disappeared from the list of running services when I sc now.

So. How can I create a situation where when I restart ipa, for whatever
reason, this doesn't happen again?

Secondary question: given that I have missed something seemingly
integral, is there a document that describes the post install setup
process I should go through to stop this error from re-occurring?
Let's start from the beginning:

- What distribution you are running?
- What IPA packages are installed?
- What 389-ds-base package is installed?
- What slapi-nis package is installed?

It looks like if things are working for "few hours" and then stop, this
means 389-ds did crash somehow. There were several cases where it might
crash but they were fixed and latest releases have no known crashes,
either with RHEL 6.7 or RHEL 7.2 and their off-springs.

/ Alexander Bokovoy

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to