[Freeipa-users] FreeIPA for Linux desktop deployment

Rob Crittenden rcritten at redhat.com
Mon Jul 25 14:22:03 UTC 2011


nasir nasir wrote:
> Hi Rob,
>
> Thanks indeed for the quick reply! Please see the attached backtrace
> files. I have generated it with the abrt. Is it OK ? please let me know
> if you need anything else.

As I feared this doesn't quite show us whether bind-dyndb-ldap is the 
culprit or not. Knowing that this is a production system is it possible 
to install the bind debuginfo package so we can get a more complete 
backtrace the next time it crashes?

rob

>
> Regards,
> Nasir
>
>
> --- On *Mon, 7/25/11, Rob Crittenden /<rcritten at redhat.com>/* wrote:
>
>
>     From: Rob Crittenden <rcritten at redhat.com>
>     Subject: Re: [Freeipa-users] FreeIPA for Linux desktop deployment
>     To: "nasir nasir" <kollathodi at yahoo.com>
>     Cc: freeipa-users at redhat.com
>     Date: Monday, July 25, 2011, 6:16 AM
>
>     nasir nasir wrote:
>      > Hi,
>      >
>      > Further to the ongoing deployment of Linux clients and servers using
>      > FreeIPA, I was able to successfully get all the requirements like,
>      >
>      > -- complete centralized authentication and administration
>      > -- NFS home share
>      > -- HBAC
>      > -- FreeIPA acting as Integrated DNS server
>      >
>      > Everything was good during the testing period. But when we went to
>      > production since day before yesterday, we are facing a serious issue.
>      > The DNS in IPA is giving out some problems. All of a sudden it
>     becomes
>      > unresponsive. We already noticed this twice in the past 48 hours.
>     Since
>      > this is the name server for the entire network, everything
>     depending on
>      > this for name resolution fails. When I log in to FreeIPA server
>     machine
>      > and tries to see the status of named service(service named
>     status) the
>      > command hangs. Then I need to forcefully kill the named service and
>      > start it again(or alternatively restart ipa service) to get
>     everything
>      > back to normal. I checked all the relevant log files and could
>     see the
>      > following at various point of time in the
>     /var/log/messages(trimmed out
>      > most of the part to show only possible named/sssd/ipa errors)
>      >
>      > Jul 22 05:57:55 openipa named[10135]: semaphore.c:70: fatal error:
>      > Jul 22 05:57:55 openipa named[10135]:
>      > RUNTIME_CHECK(((pthread_mutex_destroy((&sem->mutex)) == 0) ? 0 :
>     34) ==
>      > 0) failed
>      > Jul 22 05:57:55 openipa named[10135]: exiting (due to fatal error in
>      > library)
>      > Jul 22 05:57:55 openipa abrt[12698]: /var/named/core.10135 is not a
>      > regular file with link count 1: Permission denied
>      >
>      >
>      > Jul 22 14:35:56 openipa [sssd[ldap_child[17070]]]: Failed to
>     initialize
>      > credentials using keytab [(null)]: Decrypt integrity check failed.
>      > Unable to create GSSAPI-encrypted LDAP connection.
>      > Jul 22 14:35:56 openipa [sssd[ldap_child[17072]]]: Failed to
>     initialize
>      > credentials using keytab [(null)]: Decrypt integrity check failed.
>      > Unable to create GSSAPI-encrypted LDAP connection.
>      >
>      >
>      > Jul 22 17:54:33 openipa named[15678]: error (network unreachable)
>      > resolving 'snapfiles.com/AAAA/IN': 2001:503:231d::2:30#53
>      >
>      >
>      > Jul 22 20:00:02 openipa python: IPA compliance checking failed: Error
>      > initializing principal host/openipa.hugayet.com at HUGAYET.COM
>     </mc/compose?to=openipa.hugayet.com at HUGAYET.COM> in
>      > /etc/krb5.keytab: (-1765328353, 'Decrypt integrity check failed')
>      >
>      >
>      > Jul 23 09:10:01 openipa abrt[21599]: saved core dump of pid 20934
>      > (/usr/sbin/named) to
>     /var/spool/abrt/ccpp-1311401401-20934.new/coredump
>      > (37900288 bytes)
>      > Jul 23 09:10:01 openipa abrtd: Directory 'ccpp-1311401401-20934'
>      > creation detected
>      > Jul 23 09:10:01 openipa abrtd: Crash is in database already (dup of
>      > /var/spool/abrt/ccpp-1307530903-2297)
>      > Jul 23 09:10:01 openipa abrtd: Deleting crash
>     ccpp-1311401401-20934 (dup
>      > of ccpp-1307530903-2297), sending dbus signal
>      > Jul 23 09:10:03 openipa named[21631]: starting BIND
>      > 9.7.3-RedHat-9.7.3-2.el6 -u named -4
>      >
>      >
>      > Jul 23 15:35:56 openipa [sssd[ldap_child[22297]]]: Failed to
>     initialize
>      > credentials using keytab [(null)]: Decrypt integrity check failed.
>      > Unable to create GSSAPI-encrypted LDAP connection.
>      > Jul 23 15:35:56 openipa [sssd[ldap_child[22298]]]: Failed to
>     initialize
>      > credentials using keytab [(null)]: Decrypt integrity check failed.
>      > Unable to create GSSAPI-encrypted LDAP connection.
>      >
>      > Jul 23 09:10:03 openipa named[21631]: adjusted limit on open
>     files from
>      > 1024 to 1048576
>      >
>      >
>      > Jul 24 03:16:01 openipa [sssd[ldap_child[22964]]]: Failed to
>     initialize
>      > credentials using keytab [(null)]: Decrypt integrity check failed.
>      > Unable to create GSSAPI-encrypted LDAP connection.
>      > Jul 24 04:00:02 openipa python: IPA compliance checking failed: Error
>      > initializing principal host/openipa.hugayet.com at HUGAYET.COM
>     </mc/compose?to=openipa.hugayet.com at HUGAYET.COM> in
>      > /etc/krb5.keytab: (-1765328353, 'Decrypt integrity check failed')
>      > Jul 24 06:17:25 openipa named[21631]: semaphore.c:70: fatal error:
>      > Jul 24 06:17:25 openipa named[21631]:
>      > RUNTIME_CHECK(((pthread_mutex_destroy((&sem->mutex)) == 0) ? 0 :
>     34) ==
>      > 0) failed
>      > Jul 24 06:17:25 openipa named[21631]: exiting (due to fatal error in
>      > library)
>      > Jul 24 06:17:25 openipa abrt[23220]: saved core dump of pid 21631
>      > (/usr/sbin/named) to
>     /var/spool/abrt/ccpp-1311477445-21631.new/coredump
>      > (143396864 bytes)
>      >
>      > Also, I could see the following in my krb5kdc.log,
>      >
>      > ul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](Error): preauth
>     pkinit
>      > failed to initialize: No realms configured correctly for pkinit
>     support
>      > Jul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](info): setting up
>      > network...
>      > Jul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](info):
>     listening on
>      > fd 9: udp 0.0.0.0.88 (pktinfo)
>      > krb5kdc: setsockopt(10,IPV6_V6ONLY,1) worked
>      > krb5kdc: No realms configured correctly for pkinit support - Cannot
>      > request packet info for udp socket address :: port 88
>      > Jul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](info): skipping
>      > unrecognized local address family 17
>      > Jul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](info): skipping
>      > unrecognized local address family 17
>      > krb5kdc: setsockopt(10,IPV6_V6ONLY,1) worked
>      > Jul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](info):
>     listening on
>      > fd 10: udp fe80::6ab5:99ff:fec8:160%eth0.88
>      > krb5kdc: setsockopt(11,IPV6_V6ONLY,1) worked
>      > Jul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](info):
>     listening on
>      > fd 12: tcp 0.0.0.0.88
>      > Jul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](info):
>     listening on
>      > fd 11: tcp ::.88
>      > Jul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](info): set up
>     4 sockets
>      >
>      > Also, please note the following points,
>      >
>      > ---- For the DHCP service, I have a cobbler server running the
>     service
>      > which will use the FreeIPA server's DNS servicee.(with
>      > *ddns-update-style interim; *option in the dhcp configuration file)
>      > ---- After seeing some permission related issues for named, I
>     have given
>      > /var/named sufficient permission to named daemon for the folder.
>      > ---- Disabled ipv6 for named as I don't use it anyway(OPTIONS="-4" in
>      > /etc/sysconfig/named)
>      >
>      > Thanks indeed for for all the help so far and waiting for your
>     valuable
>      > input on this!
>
>     If you can get a backtrace on the named core I think that would be very
>     helpful. It could be a problem in bind or in the bind-dyndb-ldap plugin
>     that we use to LDAP as a backend store for bind.
>
>     rob
>




More information about the Freeipa-users mailing list