Re: [Freeipa-users] freeipa server upgrade from fedora 20 to fedora 22 glitches
On 06/04/2015 04:33 PM, Rob Crittenden wrote:
Thomas Sailer wrote:
I have now managed to upgrade the replica as well.
I stumbled over a few additional problems:
1) whenever a user becomes member of a group with +nsuniqueid= in its
name, the user can no longer login. The reason is that ldb_dn_validate
doesn't like the + character, thus returns false, which causes
get_ipa_groupname to return EINVAL, which causes the loop in
hbac_eval_user_element to abort and return an error.
This seems to be quite draconian. Does it have to be like this? If so it
would be nice if a clearer error message would be left somewhere more
obvious than sssd -d 0x...
An entry with nsuniqueid is a replication conflict entry. You want to
resolve this.
See
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
Yes I know, and I have already fixed that.
The question is is it justified if the presence of such a group breaks
login. If yes, shouldn't there be a more obvious error message than ssh
telling you that login failed for UNKNOWN reasons...
If login would still work, it would buy you time for fixing the problem.
The way it is now, you have people filling your office complaining login
doesn't work anymore while you frantically try to figure out why.
My biggest wish for IPA is for it to become more robust. It consists of
many software components with complex interdependencies, so some
fragility is to be expected. But still, it would be nice if it was as
robust as possible and if it fails that it fails in more obvious ways...
2) I cannot change ssh keys, neither in the web gui nor on the cli.
# ipa -vv user-mod myuserid --sshpubkey= --all
ipa: INFO: trying https://xserver.x.com/ipa/json
ipa: INFO: Request: {
id: 0,
method: ping,
params: [
[],
{}
]
}
ipa: INFO: Response: {
error: null,
id: 0,
principal: ad...@x.com,
result: {
messages: [
{
code: 13001,
message: API Version number was not sent, forward
compatibility not guaranteed. Assuming server's API version, 2.114,
name: VersionMissing,
type: warning
}
],
summary: IPA server version 4.1.4. API version 2.114
},
version: 4.1.4
}
ipa: INFO: Forwarding 'user_mod' to json server
'https://xserver.x.com/ipa/json'
ipa: INFO: Request: {
id: 0,
method: user_mod,
params: [
[
t.sailer
],
{
all: true,
ipasshpubkey: null,
no_members: false,
random: false,
raw: false,
rights: false,
version: 2.114
}
]
}
ipa: INFO: Response: {
error: {
code: 4203,
message: Type or value exists: ,
name: DatabaseError
},
id: 0,
principal: ad...@x.com,
result: null,
version: 4.1.4
}
ipa: ERROR: Type or value exists:
I cannot find any more information in /var/log/httpd/error_log. But I
can change the SSH keys directly talking to slapd...
Hmm, curious. What is the current state of the entry? The 389-ds
access log might have more details (though I'm stretching here).
[04/Jun/2015:17:43:21 +0200] conn=3391 fd=70 slot=70 connection from
a.b.c.d to a.b.c.d
[04/Jun/2015:17:43:21 +0200] conn=3391 op=0 BIND dn= method=sasl
version=3 mech=GSSAPI
[04/Jun/2015:17:43:21 +0200] conn=3391 op=1 BIND dn= method=sasl
version=3 mech=GSSAPI
[04/Jun/2015:17:43:21 +0200] conn=3391 op=0 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[04/Jun/2015:17:43:21 +0200] conn=3391 op=1 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[04/Jun/2015:17:43:21 +0200] conn=3391 op=2 BIND dn= method=sasl
version=3 mech=GSSAPI
[04/Jun/2015:17:43:21 +0200] conn=3391 op=2 RESULT err=0 tag=97
nentries=0 etime=0 dn=uid=t.sailer,cn=users,cn=accounts,dc=x,dc=com
[04/Jun/2015:17:43:21 +0200] conn=3391 op=3 SRCH
base=cn=ipaconfig,cn=etc,dc=x,dc=com scope=0
filter=(objectClass=*) attrs=ALL
[04/Jun/2015:17:43:21 +0200] conn=3391 op=3 RESULT err=0 tag=101
nentries=1 etime=0
[04/Jun/2015:17:43:21 +0200] conn=3391 op=4 SRCH
base=uid=t.sailer,cn=users,cn=accounts,dc=x,dc=com scope=0
filter=(objectClass=*) attrs=objectClass
[04/Jun/2015:17:43:21 +0200] conn=3391 op=4 RESULT err=0 tag=101
nentries=1 etime=0
[04/Jun/2015:17:43:21 +0200] conn=3391 op=5 SRCH
base=uid=t.sailer,cn=users,cn=accounts,dc=x,dc=com scope=0
filter=(objectClass=*) attrs=objectClass ipaSshPubKey
[04/Jun/2015:17:43:21 +0200] conn=3391 op=5 RESULT err=0 tag=101
nentries=1 etime=0
[04/Jun/2015:17:43:21 +0200] conn=3391 op=6 MOD
dn=uid=t.sailer,cn=users,cn=accounts,dc=x,dc=com
[04/Jun/2015:17:43:22 +0200] conn=3391 op=6 RESULT err=20 tag=103
nentries=0 etime=1
Re: [Freeipa-users] freeipa server upgrade from fedora 20 to fedora 22 glitches
Thomas Sailer wrote:
I have now managed to upgrade the replica as well.
I stumbled over a few additional problems:
1) whenever a user becomes member of a group with +nsuniqueid= in its
name, the user can no longer login. The reason is that ldb_dn_validate
doesn't like the + character, thus returns false, which causes
get_ipa_groupname to return EINVAL, which causes the loop in
hbac_eval_user_element to abort and return an error.
This seems to be quite draconian. Does it have to be like this? If so it
would be nice if a clearer error message would be left somewhere more
obvious than sssd -d 0x...
An entry with nsuniqueid is a replication conflict entry. You want to
resolve this.
See
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
2) I cannot change ssh keys, neither in the web gui nor on the cli.
# ipa -vv user-mod myuserid --sshpubkey= --all
ipa: INFO: trying https://xserver.x.com/ipa/json
ipa: INFO: Request: {
id: 0,
method: ping,
params: [
[],
{}
]
}
ipa: INFO: Response: {
error: null,
id: 0,
principal: ad...@x.com,
result: {
messages: [
{
code: 13001,
message: API Version number was not sent, forward
compatibility not guaranteed. Assuming server's API version, 2.114,
name: VersionMissing,
type: warning
}
],
summary: IPA server version 4.1.4. API version 2.114
},
version: 4.1.4
}
ipa: INFO: Forwarding 'user_mod' to json server
'https://xserver.x.com/ipa/json'
ipa: INFO: Request: {
id: 0,
method: user_mod,
params: [
[
t.sailer
],
{
all: true,
ipasshpubkey: null,
no_members: false,
random: false,
raw: false,
rights: false,
version: 2.114
}
]
}
ipa: INFO: Response: {
error: {
code: 4203,
message: Type or value exists: ,
name: DatabaseError
},
id: 0,
principal: ad...@x.com,
result: null,
version: 4.1.4
}
ipa: ERROR: Type or value exists:
I cannot find any more information in /var/log/httpd/error_log. But I
can change the SSH keys directly talking to slapd...
Hmm, curious. What is the current state of the entry? The 389-ds access
log might have more details (though I'm stretching here).
3) Is
[global]
debug=True
in /etc/ipa/ipa.conf supposed to change /var/log/httpd/error_log output?
I cannot see any change...
No, there is no /etc/ipa/ipa.conf.
You can create /etc/ipa/server.conf to only change configuration for the
server, or /etc/ipa/client.conf to only change configuration for the client.
default.conf is loaded first, then server/client.conf is loaded and
changes override the default.
rob
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa server upgrade from fedora 20 to fedora 22 glitches
I have now managed to upgrade the replica as well.
I stumbled over a few additional problems:
1) whenever a user becomes member of a group with +nsuniqueid= in its
name, the user can no longer login. The reason is that ldb_dn_validate
doesn't like the + character, thus returns false, which causes
get_ipa_groupname to return EINVAL, which causes the loop in
hbac_eval_user_element to abort and return an error.
This seems to be quite draconian. Does it have to be like this? If so it
would be nice if a clearer error message would be left somewhere more
obvious than sssd -d 0x...
2) I cannot change ssh keys, neither in the web gui nor on the cli.
# ipa -vv user-mod myuserid --sshpubkey= --all
ipa: INFO: trying https://xserver.x.com/ipa/json
ipa: INFO: Request: {
id: 0,
method: ping,
params: [
[],
{}
]
}
ipa: INFO: Response: {
error: null,
id: 0,
principal: ad...@x.com,
result: {
messages: [
{
code: 13001,
message: API Version number was not sent, forward
compatibility not guaranteed. Assuming server's API version, 2.114,
name: VersionMissing,
type: warning
}
],
summary: IPA server version 4.1.4. API version 2.114
},
version: 4.1.4
}
ipa: INFO: Forwarding 'user_mod' to json server
'https://xserver.x.com/ipa/json'
ipa: INFO: Request: {
id: 0,
method: user_mod,
params: [
[
t.sailer
],
{
all: true,
ipasshpubkey: null,
no_members: false,
random: false,
raw: false,
rights: false,
version: 2.114
}
]
}
ipa: INFO: Response: {
error: {
code: 4203,
message: Type or value exists: ,
name: DatabaseError
},
id: 0,
principal: ad...@x.com,
result: null,
version: 4.1.4
}
ipa: ERROR: Type or value exists:
I cannot find any more information in /var/log/httpd/error_log. But I
can change the SSH keys directly talking to slapd...
3) Is
[global]
debug=True
in /etc/ipa/ipa.conf supposed to change /var/log/httpd/error_log output?
I cannot see any change...
Thomas
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa server upgrade from fedora 20 to fedora 22 glitches
On 01/06/15 19:48, Jan Pazdziora wrote: On Fri, May 29, 2015 at 06:57:33PM +0200, Thomas Sailer wrote: I upgraded a freeipa server from fedora 20 to fedora 22. It mostly worked ok, but there are a few issues: - pki-tomcat didn't start after the upgrade, and that in turn made ipa-upgradeconfig fail, because /var/lib/pki/pki-tomcat/conf/ca/CS.cfg had the wrong owner (root). I saw this issue in containers as well, when upgrading from Fedora 21 to 22. Do we have a bugzilla / ticket filed? Do we need one? I don't think so, please file a ticket. -- Martin Basti -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa server upgrade from fedora 20 to fedora 22 glitches
On 29/05/15 18:57, Thomas Sailer wrote: Hello everyone. I upgraded a freeipa server from fedora 20 to fedora 22. It mostly worked ok, but there are a few issues: - pki-tomcat didn't start after the upgrade, and that in turn made ipa-upgradeconfig fail, because /var/lib/pki/pki-tomcat/conf/ca/CS.cfg had the wrong owner (root). - ipa-ldap-updater stumbles over two problems: - Pre schema upgrade failed - when trying to modify cn=encryption,cn=config, it stumbles over allowWeakCipher not allowed Does anyone know how to fix this? Is the pre schema upgrade failure spurious? what bits am I missing about the allowWeakCipher issue? Thomas 2015-05-28T13:04:55Z DEBUG [4/10]: starting directory server 2015-05-28T13:04:55Z DEBUG Starting external process 2015-05-28T13:04:55Z DEBUG args='/bin/systemctl' 'start' 'dirsrv@X-COM.service' 2015-05-28T13:04:55Z DEBUG Process finished, return code=0 2015-05-28T13:04:55Z DEBUG stdout= 2015-05-28T13:04:55Z DEBUG stderr=Running in chroot, ignoring request. 2015-05-28T13:04:55Z DEBUG duration: 0 seconds 2015-05-28T13:04:55Z DEBUG [5/10]: preparing server upgrade 2015-05-28T13:05:36Z ERROR Pre schema upgrade failed with [Errno 2] No such file or directory 2015-05-28T13:05:36Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py, line 128, in __pre_schema_upgrade ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True, live_run=self.live_run, plugins=True) File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 220, in __init__ self.create_connection() File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 783, in create_connection dm_password=self.dm_password, pw_name=self.pw_name) File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 65, in connect conn.do_external_bind(pw_name) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 1183, in wait_for_open_socket raise e error: [Errno 2] No such file or directory 2015-05-28T13:05:36Z DEBUG duration: 40 seconds 2015-05-28T13:05:36Z DEBUG [6/10]: updating schema 2015-05-28T13:05:46Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 388, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 378, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py, line 145, in __update_schema dm_password='', ldapi=True, live_run=self.live_run) or self.modified File /usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py, line 112, in update_schema fqdn=installutils.get_fqdn()) File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 65, in connect conn.do_external_bind(pw_name) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 1183, in wait_for_open_socket raise e error: [Errno 2] No such file or directory 2015-05-28T13:05:46Z DEBUG [error] error: [Errno 2] No such file or directory 2015-05-28T13:05:46Z DEBUG [cleanup]: stopping directory server 2015-05-28T13:05:46Z DEBUG Starting external process 2015-05-28T13:05:46Z DEBUG args='/bin/systemctl' 'stop' 'dirsrv@X-COM.service' 2015-05-28T13:05:46Z DEBUG Process finished, return code=0 2015-05-28T13:05:46Z DEBUG stdout= 2015-05-28T13:05:46Z DEBUG stderr=Running in chroot, ignoring request. 2015-05-28T13:05:46Z DEBUG duration: 0 seconds 2015-05-28T13:05:46Z DEBUG [cleanup]: restoring configuration 2015-05-28T13:05:46Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-28T13:05:46Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-28T13:05:46Z DEBUG duration: 0 seconds 2015-05-28T13:05:46Z DEBUG File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 171, in execute return_value = self.run() File
Re: [Freeipa-users] freeipa server upgrade from fedora 20 to fedora 22 glitches
Martin, Rob, thanks for your answers! On 06/01/2015 09:52 AM, Martin Basti wrote: Could DS in chroot, cause the ipa-ldap-updater --upgrade cannot locate the DS socket? 2015-05-28T13:04:55Z DEBUG stderr=Running in chroot, ignoring request. I used fedup for the distro upgrade, so yes initially it ran in a chroot. However, the log excerpts were from a second run I manually initiated, after the machine rebooted after the update. I am pretty sure I ensured that enough of freeipa ran to successfully run ipa user-status and kinit. 2) Allow weak ciphers. can you check objectclass definitions in /etc/dirsrv/slapd-X-COM/schema # grep 'allowWeakCipher' * If you find more than on objectclass definition, please remove the old from the ldif files and restart DS. (Probably there will be old in 99user.ldif) I indeed had a file named 99user.ldif with a date from yesterday (even newer than 01core389.ldif). I removed this. Now ipa-ldap-updater --upgrade completes successfully, on one machine. On the other replica, /usr/sbin/ipa-upgradeconfig fails. There's something wrong with pki-tomcatd: access_log: a.b.c.d - - [01/Jun/2015:18:22:35 +0200] GET /ca/admin/ca/getStatus HTTP/1.1 500 2108 Jun 01 18:47:03 server2.x.com server[9651]: Jun 01, 2015 6:47:03 PM org.apache.catalina.core.ContainerBase backgroundProcess Jun 01 18:47:03 server2.x.com server[9651]: WARNING: Exception processing realm com.netscape.cms.tomcat.ProxyRealm@548d946f background process Jun 01 18:47:03 server2.x.com server[9651]: java.lang.NullPointerException Jun 01 18:47:03 server2.x.com server[9651]: at com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:108) Jun 01 18:47:03 server2.x.com server[9651]: at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1360) Jun 01 18:47:03 server2.x.com server[9651]: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1546) Jun 01 18:47:03 server2.x.com server[9651]: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1556) Jun 01 18:47:03 server2.x.com server[9651]: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1556) Jun 01 18:47:03 server2.x.com server[9651]: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1524) Jun 01 18:47:03 server2.x.com server[9651]: at java.lang.Thread.run(Thread.java:745) Apparently, I'm not the only one :) http://pastebin.com/CtsW0GAt -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa server upgrade from fedora 20 to fedora 22 glitches
Thomas Sailer wrote: Hello everyone. I upgraded a freeipa server from fedora 20 to fedora 22. It mostly worked ok, but there are a few issues: - pki-tomcat didn't start after the upgrade, and that in turn made ipa-upgradeconfig fail, because /var/lib/pki/pki-tomcat/conf/ca/CS.cfg had the wrong owner (root). - ipa-ldap-updater stumbles over two problems: - Pre schema upgrade failed - when trying to modify cn=encryption,cn=config, it stumbles over allowWeakCipher not allowed Does anyone know how to fix this? Is the pre schema upgrade failure spurious? what bits am I missing about the allowWeakCipher issue? I think the issue was that the upgrade was done in a chroot, so systemd couldn't start 389-ds. I'm guessing, but I'll bet the No such file or directory is the ldapi socket. You can safely re-run the upgrade scripts: # /usr/sbin/ipa-ldap-updater --upgrade # /usr/sbin/ipa-upgradeconfig I'd re-run those and see if the errors change, or hopefully, go away completely. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa server upgrade from fedora 20 to fedora 22 glitches
On Fri, May 29, 2015 at 06:57:33PM +0200, Thomas Sailer wrote: I upgraded a freeipa server from fedora 20 to fedora 22. It mostly worked ok, but there are a few issues: - pki-tomcat didn't start after the upgrade, and that in turn made ipa-upgradeconfig fail, because /var/lib/pki/pki-tomcat/conf/ca/CS.cfg had the wrong owner (root). I saw this issue in containers as well, when upgrading from Fedora 21 to 22. Do we have a bugzilla / ticket filed? Do we need one? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] freeipa server upgrade from fedora 20 to fedora 22 glitches
Hello everyone. I upgraded a freeipa server from fedora 20 to fedora 22. It mostly worked ok, but there are a few issues: - pki-tomcat didn't start after the upgrade, and that in turn made ipa-upgradeconfig fail, because /var/lib/pki/pki-tomcat/conf/ca/CS.cfg had the wrong owner (root). - ipa-ldap-updater stumbles over two problems: - Pre schema upgrade failed - when trying to modify cn=encryption,cn=config, it stumbles over allowWeakCipher not allowed Does anyone know how to fix this? Is the pre schema upgrade failure spurious? what bits am I missing about the allowWeakCipher issue? Thomas 2015-05-28T13:04:55Z DEBUG [4/10]: starting directory server 2015-05-28T13:04:55Z DEBUG Starting external process 2015-05-28T13:04:55Z DEBUG args='/bin/systemctl' 'start' 'dirsrv@X-COM.service' 2015-05-28T13:04:55Z DEBUG Process finished, return code=0 2015-05-28T13:04:55Z DEBUG stdout= 2015-05-28T13:04:55Z DEBUG stderr=Running in chroot, ignoring request. 2015-05-28T13:04:55Z DEBUG duration: 0 seconds 2015-05-28T13:04:55Z DEBUG [5/10]: preparing server upgrade 2015-05-28T13:05:36Z ERROR Pre schema upgrade failed with [Errno 2] No such file or directory 2015-05-28T13:05:36Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py, line 128, in __pre_schema_upgrade ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True, live_run=self.live_run, plugins=True) File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 220, in __init__ self.create_connection() File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 783, in create_connection dm_password=self.dm_password, pw_name=self.pw_name) File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 65, in connect conn.do_external_bind(pw_name) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 1183, in wait_for_open_socket raise e error: [Errno 2] No such file or directory 2015-05-28T13:05:36Z DEBUG duration: 40 seconds 2015-05-28T13:05:36Z DEBUG [6/10]: updating schema 2015-05-28T13:05:46Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 388, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 378, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py, line 145, in __update_schema dm_password='', ldapi=True, live_run=self.live_run) or self.modified File /usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py, line 112, in update_schema fqdn=installutils.get_fqdn()) File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 65, in connect conn.do_external_bind(pw_name) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 1183, in wait_for_open_socket raise e error: [Errno 2] No such file or directory 2015-05-28T13:05:46Z DEBUG [error] error: [Errno 2] No such file or directory 2015-05-28T13:05:46Z DEBUG [cleanup]: stopping directory server 2015-05-28T13:05:46Z DEBUG Starting external process 2015-05-28T13:05:46Z DEBUG args='/bin/systemctl' 'stop' 'dirsrv@X-COM.service' 2015-05-28T13:05:46Z DEBUG Process finished, return code=0 2015-05-28T13:05:46Z DEBUG stdout= 2015-05-28T13:05:46Z DEBUG stderr=Running in chroot, ignoring request. 2015-05-28T13:05:46Z DEBUG duration: 0 seconds 2015-05-28T13:05:46Z DEBUG [cleanup]: restoring configuration 2015-05-28T13:05:46Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-28T13:05:46Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-28T13:05:46Z DEBUG duration: 0 seconds 2015-05-28T13:05:46Z DEBUG File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 171, in execute return_value = self.run() File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py, line 144, in run
