[Freeipa-users] ns-slapd hang/segfault

Post by Dan Scott
Hi,
On my Fedora 15 FreeIPA server, I'm having some problems with
stability. The server appears to 'hang' and stops responding to LDAP
Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault
at 17d ip 00007f00dbc0208c sp 00007fff929b7848 error 4 in
libc-2.14.so[7f00dbb87000+18f000]
and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains
[15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial
[WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC
for requested realm)
could not perform interactive bind for id [] mech [GSSAPI]: error -2
(Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
GSS failure. Minor code may provide more information (Credentials
cache file '/tmp/krb5cc_496' not found))
This is happening very frequently, I'm having to restart the dirsrv
process once an hour, otherwise people start complaining.
I experienced similar problems with FreeIPA 1, when I was using Fedora
14 and earlier, and had to regularly (also once per hour) restart the
dirsrv process. Could this be related?
https://bugzilla.redhat.com/show_bug.cgi?id=730387
There are updates in 'updates-testing' which I believe fix the above
issue, but I'm reluctant to install from a testing repo on my
production server, can anyone report any feedback on this?

The above bug does not cause a segfault.
What version of 389-ds-base are you using?
Please enable the collection of core dumps so we can debug the crash -
see http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes

Post by Dan Scott
Can anyone help me out?
Thanks,
Dan
_______________________________________________
Freeipa-users mailing list
https://www.redhat.com/mailman/listinfo/freeipa-users

Dan Scott

2011-12-19 16:01:42 UTC

Hi,

The above bug does not cause a segfault.
What version of 389-ds-base are you using?

389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64
389-ds-base-1.2.10-0.4.a4.fc15.x86_64

a4 is alpha software. Not sure how that got released to stable.

Post by Rich Megginson
Please enable the collection of core dumps so we can debug the crash -
see
http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes

'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install
389-ds-base'

Thanks. Fixed.

I managed to get the core dump (attached - so I only sent this message
to you, not the list as well), but it doesn't contain much
information.

This is https://bugzilla.redhat.com/show_bug.cgi?id=755725
Will be fixed in 1.2.10.a6
But this still doesn't explain your kerberos errors.

An additional problem is also occurring. I've been finding that the:

/etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif

file is empty and prevents dirsrv from starting. I can restore it from
dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP
problems that I'm having?

Thanks,

Dan

Rich Megginson

2011-12-19 16:03:23 UTC

Hi,

The above bug does not cause a segfault.
What version of 389-ds-base are you using?

389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64
389-ds-base-1.2.10-0.4.a4.fc15.x86_64

a4 is alpha software. Not sure how that got released to stable.

Post by Rich Megginson
Please enable the collection of core dumps so we can debug the crash -
see
http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes

'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install
389-ds-base'

Thanks. Fixed.

I managed to get the core dump (attached - so I only sent this message
to you, not the list as well), but it doesn't contain much
information.

This is https://bugzilla.redhat.com/show_bug.cgi?id=755725
Will be fixed in 1.2.10.a6
But this still doesn't explain your kerberos errors.

/etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif
file is empty and prevents dirsrv from starting. I can restore it from
dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP
problems that I'm having?

I don't know. What is the sequence of operations that causes dse.ldif
to become empty?

Post by Dan Scott
Thanks,
Dan

Dan Scott

2011-12-19 16:13:48 UTC

Hi,

The above bug does not cause a segfault.
What version of 389-ds-base are you using?

389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64
389-ds-base-1.2.10-0.4.a4.fc15.x86_64

a4 is alpha software. Not sure how that got released to stable.

Post by Rich Megginson
Please enable the collection of core dumps so we can debug the crash -
see
http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes

'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install
389-ds-base'

Thanks. Fixed.

I managed to get the core dump (attached - so I only sent this message
to you, not the list as well), but it doesn't contain much
information.

This is https://bugzilla.redhat.com/show_bug.cgi?id=755725
Will be fixed in 1.2.10.a6
But this still doesn't explain your kerberos errors.

I don't know. What is the sequence of operations that causes dse.ldif to
become empty?

Can I find this in the logs? The dirsrv process is crashing regularly,
so I have to regularly restart it. Occasionally (seemingly randomly)
it fails to restart because the dse.ldif file is empty.

Rich Megginson

2011-12-19 16:16:27 UTC

Hi,

The above bug does not cause a segfault.
What version of 389-ds-base are you using?

389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64
389-ds-base-1.2.10-0.4.a4.fc15.x86_64

a4 is alpha software. Not sure how that got released to stable.

Post by Rich Megginson
Please enable the collection of core dumps so we can debug the crash -
see
http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes

'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install
389-ds-base'

Thanks. Fixed.

I managed to get the core dump (attached - so I only sent this message
to you, not the list as well), but it doesn't contain much
information.

This is https://bugzilla.redhat.com/show_bug.cgi?id=755725
Will be fixed in 1.2.10.a6
But this still doesn't explain your kerberos errors.

I don't know. What is the sequence of operations that causes dse.ldif to
become empty?

Can I find this in the logs? The dirsrv process is crashing regularly,
so I have to regularly restart it. Occasionally (seemingly randomly)
it fails to restart because the dse.ldif file is empty.

Let me push out the crash fix build to testing and see if that helps.

Simo Sorce

2011-12-19 19:14:57 UTC

Hi,

The above bug does not cause a segfault.
What version of 389-ds-base are you using?

389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64
389-ds-base-1.2.10-0.4.a4.fc15.x86_64

a4 is alpha software. Not sure how that got released to stable.

Post by Rich Megginson
Please enable the collection of core dumps so we can debug the crash -
see
http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes

'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install
389-ds-base'

Thanks. Fixed.

I managed to get the core dump (attached - so I only sent this message
to you, not the list as well), but it doesn't contain much
information.

This is https://bugzilla.redhat.com/show_bug.cgi?id=755725
Will be fixed in 1.2.10.a6
But this still doesn't explain your kerberos errors.

This is an upgrade time problem, it should be fixed in latest packages.
Did you recently upgrade freeipa packages if so from what version to
what version ?

(If you used yum you can use 'yum history' to find out)

Simo.

--
Simo Sorce * Red Hat, Inc * New York

Dan Scott

2011-12-19 20:26:46 UTC

Hi,

The above bug does not cause a segfault.
What version of 389-ds-base are you using?

389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64
389-ds-base-1.2.10-0.4.a4.fc15.x86_64

a4 is alpha software. Not sure how that got released to stable.

Post by Rich Megginson
Please enable the collection of core dumps so we can debug the crash -
see
http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes

'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install
389-ds-base'

Thanks. Fixed.

I managed to get the core dump (attached - so I only sent this message
to you, not the list as well), but it doesn't contain much
information.

This is https://bugzilla.redhat.com/show_bug.cgi?id=755725
Will be fixed in 1.2.10.a6
But this still doesn't explain your kerberos errors.

This is an upgrade time problem, it should be fixed in latest packages.
Did you recently upgrade freeipa packages if so from what version to
what version ?

The 0 length file doesn't appear related to upgrades. Possibly it only
happens on the first service restart after an upgrade?

It's happened at least 4 times since the last freeipa package upgrade
on 4th November, so it seems to be happening too regularly to be the
result of an upgrade.

[***@curie ~]# grep freeipa /var/log/yum.log
Sep 06 16:56:51 Installed: freeipa-python-2.0.1-2.fc15.x86_64
Sep 06 17:00:13 Installed: freeipa-client-2.0.1-2.fc15.x86_64
Sep 06 17:00:14 Installed: freeipa-admintools-2.0.1-2.fc15.x86_64
Sep 06 17:01:52 Installed: freeipa-server-selinux-2.0.1-2.fc15.x86_64
Sep 06 17:01:56 Installed: freeipa-server-2.0.1-2.fc15.x86_64
Sep 08 11:23:35 Updated: freeipa-python-2.1.0-1.fc15.x86_64
Sep 08 11:23:41 Updated: freeipa-client-2.1.0-1.fc15.x86_64
Sep 08 11:23:41 Updated: freeipa-admintools-2.1.0-1.fc15.x86_64
Sep 08 11:25:00 Updated: freeipa-server-selinux-2.1.0-1.fc15.x86_64
Sep 08 11:26:06 Updated: freeipa-server-2.1.0-1.fc15.x86_64
Nov 04 15:46:43 Updated: freeipa-python-2.1.3-2.fc15.x86_64
Nov 04 15:52:48 Updated: freeipa-client-2.1.3-2.fc15.x86_64
Nov 04 15:52:48 Updated: freeipa-admintools-2.1.3-2.fc15.x86_64
Nov 04 15:54:47 Updated: freeipa-server-2.1.3-2.fc15.x86_64
Nov 04 15:56:02 Updated: freeipa-server-selinux-2.1.3-2.fc15.x86_64

Dan

Dan Scott

2011-12-21 19:10:43 UTC

Hi,

The above bug does not cause a segfault.
What version of 389-ds-base are you using?

389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64
389-ds-base-1.2.10-0.4.a4.fc15.x86_64

a4 is alpha software. Not sure how that got released to stable.

Post by Rich Megginson
Please enable the collection of core dumps so we can debug the crash -
see
http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes

'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install
389-ds-base'

Thanks. Fixed.

I managed to get the core dump (attached - so I only sent this message
to you, not the list as well), but it doesn't contain much
information.

This is https://bugzilla.redhat.com/show_bug.cgi?id=755725
Will be fixed in 1.2.10.a6
But this still doesn't explain your kerberos errors.

This is an upgrade time problem, it should be fixed in latest packages.
Did you recently upgrade freeipa packages if so from what version to
what version ?

The 0 length file doesn't appear related to upgrades. Possibly it only
happens on the first service restart after an upgrade?
It's happened at least 4 times since the last freeipa package upgrade
on 4th November, so it seems to be happening too regularly to be the
result of an upgrade.
Sep 06 16:56:51 Installed: freeipa-python-2.0.1-2.fc15.x86_64
Sep 06 17:00:13 Installed: freeipa-client-2.0.1-2.fc15.x86_64
Sep 06 17:00:14 Installed: freeipa-admintools-2.0.1-2.fc15.x86_64
Sep 06 17:01:52 Installed: freeipa-server-selinux-2.0.1-2.fc15.x86_64
Sep 06 17:01:56 Installed: freeipa-server-2.0.1-2.fc15.x86_64
Sep 08 11:23:35 Updated: freeipa-python-2.1.0-1.fc15.x86_64
Sep 08 11:23:41 Updated: freeipa-client-2.1.0-1.fc15.x86_64
Sep 08 11:23:41 Updated: freeipa-admintools-2.1.0-1.fc15.x86_64
Sep 08 11:25:00 Updated: freeipa-server-selinux-2.1.0-1.fc15.x86_64
Sep 08 11:26:06 Updated: freeipa-server-2.1.0-1.fc15.x86_64
Nov 04 15:46:43 Updated: freeipa-python-2.1.3-2.fc15.x86_64
Nov 04 15:52:48 Updated: freeipa-client-2.1.3-2.fc15.x86_64
Nov 04 15:52:48 Updated: freeipa-admintools-2.1.3-2.fc15.x86_64
Nov 04 15:54:47 Updated: freeipa-server-2.1.3-2.fc15.x86_64
Nov 04 15:56:02 Updated: freeipa-server-selinux-2.1.3-2.fc15.x86_64
Dan

I'm still having fairly serious problems. I keep getting:

ipa: ERROR: Kerberos error: Kerberos error: ('Unspecified GSS failure.
Minor code may provide more information', 851968)/('Cannot contact
any KDC for requested realm', -1765328228)/

Whenever I try and run IPA commands on either of my servers, or a
client with the admin tools installed.

The server logs contain:

slapd_ldap_sasl_interactive_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP
server) ((null))
slapi_ldap_bind - Error: could not perform interactive bind for id []
mech [GSSAPI]: error -1 (Can't contact LDAP server)

And I can't create new replicas because they fail with:

2011-12-21 11:25:58,356 DEBUG Failed to start replication
File "/usr/sbin/ipa-replica-install", line 484, in <module>
main()

File "/usr/sbin/ipa-replica-install", line 435, in main
ds = install_replica_ds(config)

File "/usr/sbin/ipa-replica-install", line 137, in install_replica_ds
pkcs12_info)

File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
line 284, in create_replica
self.start_creation("Configuring directory server", 60)

File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 248, in start_creation
method()

File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
line 297, in __setup_replica
r_bindpw=self.dm_password)

File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
line 694, in setup_replication
raise RuntimeError("Failed to start replication")

Can someone help me? This is getting fairly serious because I can't
create/modify anything and I'm worried that there will be problems
with existing users soon as well.

Thanks,

Dan

Simo Sorce

2011-12-21 21:43:02 UTC

Hi,

The above bug does not cause a segfault.
What version of 389-ds-base are you using?

389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64
389-ds-base-1.2.10-0.4.a4.fc15.x86_64

a4 is alpha software. Not sure how that got released to stable.

Post by Rich Megginson
Please enable the collection of core dumps so we can debug the crash -
see
http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes

'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install
389-ds-base'

Thanks. Fixed.

I managed to get the core dump (attached - so I only sent this message
to you, not the list as well), but it doesn't contain much
information.

This is https://bugzilla.redhat.com/show_bug.cgi?id=755725
Will be fixed in 1.2.10.a6
But this still doesn't explain your kerberos errors.

This is an upgrade time problem, it should be fixed in latest packages.
Did you recently upgrade freeipa packages if so from what version to
what version ?

The 0 length file doesn't appear related to upgrades. Possibly it only
happens on the first service restart after an upgrade?
It's happened at least 4 times since the last freeipa package upgrade
on 4th November, so it seems to be happening too regularly to be the
result of an upgrade.
Sep 06 16:56:51 Installed: freeipa-python-2.0.1-2.fc15.x86_64
Sep 06 17:00:13 Installed: freeipa-client-2.0.1-2.fc15.x86_64
Sep 06 17:00:14 Installed: freeipa-admintools-2.0.1-2.fc15.x86_64
Sep 06 17:01:52 Installed: freeipa-server-selinux-2.0.1-2.fc15.x86_64
Sep 06 17:01:56 Installed: freeipa-server-2.0.1-2.fc15.x86_64
Sep 08 11:23:35 Updated: freeipa-python-2.1.0-1.fc15.x86_64
Sep 08 11:23:41 Updated: freeipa-client-2.1.0-1.fc15.x86_64
Sep 08 11:23:41 Updated: freeipa-admintools-2.1.0-1.fc15.x86_64
Sep 08 11:25:00 Updated: freeipa-server-selinux-2.1.0-1.fc15.x86_64
Sep 08 11:26:06 Updated: freeipa-server-2.1.0-1.fc15.x86_64
Nov 04 15:46:43 Updated: freeipa-python-2.1.3-2.fc15.x86_64
Nov 04 15:52:48 Updated: freeipa-client-2.1.3-2.fc15.x86_64
Nov 04 15:52:48 Updated: freeipa-admintools-2.1.3-2.fc15.x86_64
Nov 04 15:54:47 Updated: freeipa-server-2.1.3-2.fc15.x86_64
Nov 04 15:56:02 Updated: freeipa-server-selinux-2.1.3-2.fc15.x86_64
Dan

ipa: ERROR: Kerberos error: Kerberos error: ('Unspecified GSS failure.
Minor code may provide more information', 851968)/('Cannot contact
any KDC for requested realm', -1765328228)/
Whenever I try and run IPA commands on either of my servers, or a
client with the admin tools installed.
slapd_ldap_sasl_interactive_bind - Error: could not perform
interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP
server) ((null))
slapi_ldap_bind - Error: could not perform interactive bind for id []
mech [GSSAPI]: error -1 (Can't contact LDAP server)
2011-12-21 11:25:58,356 DEBUG Failed to start replication
File "/usr/sbin/ipa-replica-install", line 484, in <module>
main()
File "/usr/sbin/ipa-replica-install", line 435, in main
ds = install_replica_ds(config)
File "/usr/sbin/ipa-replica-install", line 137, in install_replica_ds
pkcs12_info)
File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
line 284, in create_replica
self.start_creation("Configuring directory server", 60)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 248, in start_creation
method()
File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
line 297, in __setup_replica
r_bindpw=self.dm_password)
File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
line 694, in setup_replication
raise RuntimeError("Failed to start replication")
Can someone help me? This is getting fairly serious because I can't
create/modify anything and I'm worried that there will be problems
with existing users soon as well.

OK, I think I'm narrowing in on this. It looks like the replication

odd
The PKI instance uses a diffeent set of replication agreementsso you
can't see those agreements with ipa-replica-manage which handles only
the IPA Idm instance.

fileserver1.example.com: master
fileserver1.example.com: master
fileserver2.example.com: master

strange indeed.

unexpected error: list index out of range
Do I need to delete the replication from fileserver2?

You can't remove a replication agreement if it is the only agreement you
have. This is to avoid split-brain situations.

Not sure how to handle a disappeared agreement though it's
theorethically not possible unless you 'inadvertently' ran
ipa-replica-manage --force del fileserver2 on fileserver1 ...

Can you look into cn=config and see if you have references toi
fileserver2 ?
Maybe it is just a bug in displaying actually active replicas.

As an aside, there are some errors in the documentation for
ipa-replica-manage. Some of the examples have 'ipa replica-manage'
instead of 'ipa-replica-manage' (space instead of '-').

Thanks will file a doc bug.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

Dan Scott

2011-12-21 22:39:26 UTC

Hi,

The above bug does not cause a segfault.
What version of 389-ds-base are you using?

389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64
389-ds-base-1.2.10-0.4.a4.fc15.x86_64

a4 is alpha software. Not sure how that got released to stable.

Post by Rich Megginson
Please enable the collection of core dumps so we can debug the crash -
see
http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes

'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install
389-ds-base'

Thanks. Fixed.

I managed to get the core dump (attached - so I only sent this message
to you, not the list as well), but it doesn't contain much
information.

This is https://bugzilla.redhat.com/show_bug.cgi?id=755725
Will be fixed in 1.2.10.a6
But this still doesn't explain your kerberos errors.

This is an upgrade time problem, it should be fixed in latest packages.
Did you recently upgrade freeipa packages if so from what version to
what version ?

The 0 length file doesn't appear related to upgrades. Possibly it only
happens on the first service restart after an upgrade?
It's happened at least 4 times since the last freeipa package upgrade
on 4th November, so it seems to be happening too regularly to be the
result of an upgrade.
Sep 06 16:56:51 Installed: freeipa-python-2.0.1-2.fc15.x86_64
Sep 06 17:00:13 Installed: freeipa-client-2.0.1-2.fc15.x86_64
Sep 06 17:00:14 Installed: freeipa-admintools-2.0.1-2.fc15.x86_64
Sep 06 17:01:52 Installed: freeipa-server-selinux-2.0.1-2.fc15.x86_64
Sep 06 17:01:56 Installed: freeipa-server-2.0.1-2.fc15.x86_64
Sep 08 11:23:35 Updated: freeipa-python-2.1.0-1.fc15.x86_64
Sep 08 11:23:41 Updated: freeipa-client-2.1.0-1.fc15.x86_64
Sep 08 11:23:41 Updated: freeipa-admintools-2.1.0-1.fc15.x86_64
Sep 08 11:25:00 Updated: freeipa-server-selinux-2.1.0-1.fc15.x86_64
Sep 08 11:26:06 Updated: freeipa-server-2.1.0-1.fc15.x86_64
Nov 04 15:46:43 Updated: freeipa-python-2.1.3-2.fc15.x86_64
Nov 04 15:52:48 Updated: freeipa-client-2.1.3-2.fc15.x86_64
Nov 04 15:52:48 Updated: freeipa-admintools-2.1.3-2.fc15.x86_64
Nov 04 15:54:47 Updated: freeipa-server-2.1.3-2.fc15.x86_64
Nov 04 15:56:02 Updated: freeipa-server-selinux-2.1.3-2.fc15.x86_64
Dan

OK, I think I'm narrowing in on this. It looks like the replication

odd
The PKI instance uses a diffeent set of replication agreementsso you
can't see those agreements with ipa-replica-manage which handles only
the IPA Idm instance.

fileserver1.example.com: master
fileserver1.example.com: master
fileserver2.example.com: master

strange indeed.

unexpected error: list index out of range
Do I need to delete the replication from fileserver2?

This is possible... oops. I tried a few times to add another replica
(fileserver3) which failed as I mentioned above. The replication
process got most of the way through and showed up on one of the
servers, but not the other, so I removed the replica. It's possible
that I force removed fileserver2 by mistake.

Post by Simo Sorce
Can you look into cn=config and see if you have references toi
fileserver2 ?
Maybe it is just a bug in displaying actually active replicas.

I'm using 'jxplore' LDAP browser (my command line LDAP skills aren't
very good, I can't seem to get the kerberos authentication working
properly. In any case, I'm having trouble authenticating because of
the problems mentioned above) and did an unauthenticated search for
cn=config on fileserver1, no results.

In cn=ipa,cn=etc there are: cn=masters which contains an entry for
fileserver1 and cn=replicas which is empty.

Thanks,

Dan

Simo Sorce

2011-12-22 15:12:27 UTC

Post by Dan Scott
This is possible... oops. I tried a few times to add another replica
(fileserver3) which failed as I mentioned above. The replication
process got most of the way through and showed up on one of the
servers, but not the other, so I removed the replica. It's possible
that I force removed fileserver2 by mistake.

In this case the only way out is to reinstall fileserver2.

Post by Simo Sorce
Can you look into cn=config and see if you have references toi
fileserver2 ?
Maybe it is just a bug in displaying actually active replicas.

cn=config is a separate tree within DS it is not a subtree of the data
partition, you need to use that as the basedn in jxplore.

Post by Dan Scott
In cn=ipa,cn=etc there are: cn=masters which contains an entry for
fileserver1 and cn=replicas which is empty.

This strongly indicate you force deleted fileserver2, which is very
unfortunate. Be careful with --force we imposed such a flag for a very
good reason.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

Dan Scott

2011-12-22 15:42:14 UTC

In this case the only way out is to reinstall fileserver2.

Which would be fine, if I were confident of being able to create a new
replica. However, my attempts to create new replicas are failing
miserably as explained previously. I'm extremely reluctant to wipe
fileserver2 unless I can get another replica of fileserver1 up and
running first.

If I can get another replica up and running I would be fine. However, the

slapi_ldap_bind - Error: could not perform interactive bind for id []
mech [GSSAPI]: error -1 (Can't contact LDAP server)

error is causing problems during replication.

When a replica is initialised, I guess that it replicates only from
the master server? So I need to figure out the replication problem
first, then I can re-install fileserver2

Post by Simo Sorce
Can you look into cn=config and see if you have references toi
fileserver2 ?
Maybe it is just a bug in displaying actually active replicas.

cn=config is a separate tree within DS it is not a subtree of the data
partition, you need to use that as the basedn in jxplore.

OK, thanks. cn=config only contains a SNMP entry, no references to the
other server.

Thanks,

Dan

Rich Megginson

2011-12-22 17:10:59 UTC

In this case the only way out is to reinstall fileserver2.

Which would be fine, if I were confident of being able to create a new
replica. However, my attempts to create new replicas are failing
miserably as explained previously. I'm extremely reluctant to wipe
fileserver2 unless I can get another replica of fileserver1 up and
running first.
If I can get another replica up and running I would be fine. However, the
slapi_ldap_bind - Error: could not perform interactive bind for id []
mech [GSSAPI]: error -1 (Can't contact LDAP server)
error is causing problems during replication.
When a replica is initialised, I guess that it replicates only from
the master server? So I need to figure out the replication problem
first, then I can re-install fileserver2

Post by Simo Sorce
Can you look into cn=config and see if you have references toi
fileserver2 ?
Maybe it is just a bug in displaying actually active replicas.

cn=config is a separate tree within DS it is not a subtree of the data
partition, you need to use that as the basedn in jxplore.

OK, thanks. cn=config only contains a SNMP entry, no references to the
other server.

That's the only entry that you can view with anonymous credentials.
You'll need to use an authenticated admin user (e.g. cn=Directory
Manager) to see the rest of the tree.

Post by Dan Scott
Thanks,
Dan
_______________________________________________
Freeipa-users mailing list
https://www.redhat.com/mailman/listinfo/freeipa-users

Dan Scott

2011-12-22 17:58:41 UTC

In this case the only way out is to reinstall fileserver2.

Which would be fine, if I were confident of being able to create a new
replica. However, my attempts to create new replicas are failing
miserably as explained previously. I'm extremely reluctant to wipe
fileserver2 unless I can get another replica of fileserver1 up and
running first.
If I can get another replica up and running I would be fine. However, the
slapi_ldap_bind - Error: could not perform interactive bind for id []
mech [GSSAPI]: error -1 (Can't contact LDAP server)
error is causing problems during replication.
When a replica is initialised, I guess that it replicates only from
the master server? So I need to figure out the replication problem
first, then I can re-install fileserver2

Post by Simo Sorce
Can you look into cn=config and see if you have references toi
fileserver2 ?
Maybe it is just a bug in displaying actually active replicas.

cn=config is a separate tree within DS it is not a subtree of the data
partition, you need to use that as the basedn in jxplore.

OK, thanks. cn=config only contains a SNMP entry, no references to the
other server.

That's the only entry that you can view with anonymous credentials. You'll
need to use an authenticated admin user (e.g. cn=Directory Manager) to see
the rest of the tree.

Ahh, OK, thanks. I can see a lot more now. There's no replication
agreement with fileserver2 showing up.

I managed to 'mostly' replicate with a new Fedora 16 IPA fileserver3
(using the updates-testing release of FreeIPA
freeipa-server-2.1.4-2.fc16.x86_64). But it failed with:

2011-12-22 11:37:49,053 DEBUG done configuring dirsrv.
2011-12-22 11:37:52,058 DEBUG args=/bin/systemctl restart dirsrv.target
2011-12-22 11:37:52,059 DEBUG stdout=
2011-12-22 11:37:52,059 DEBUG stderr=
2011-12-22 11:37:52,183 DEBUG args=/bin/systemctl restart krb5kdc.service
2011-12-22 11:37:52,184 DEBUG stdout=
2011-12-22 11:37:52,184 DEBUG stderr=Job failed. See system logs and
'systemctl status' for details.

2011-12-22 11:37:52,188 DEBUG Command '/bin/systemctl restart
krb5kdc.service' returned non-zero exit status 1
File "/usr/sbin/ipa-replica-install", line 484, in <module>
main()

File "/usr/sbin/ipa-replica-install", line 460, in main
ipaservices.knownservices.krb5kdc.restart()

File "/usr/lib/python2.7/site-packages/ipapython/platform/systemd.py",
line 85, in restart
ipautil.run(["/bin/systemctl", "restart",
self.service_instance(instance_name)], capture_output=capture_output)

File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 273, in run
raise CalledProcessError(p.returncode, args)

I can send the full log file directly to someone off list if this would help.

The data seems to be replicating mostly, so I'm less concerned than I
was previously. However there still seem to be a few problems. Is it
dangerous to update my fileserver1 to
freeipa-server-2.1.4-2.fc16.x86_64. I'm a little concerned about the
slapd-PKI-IPA replication now, since I haven't been able to replicate
that properly.

I'm going to try and replicate the PKI directory now, with the 2.1.4
version into fileserver4.

Thanks,

Dan

Alexander Bokovoy

2011-12-22 19:17:40 UTC