<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="generator" content="Osso Notes"> <title></title></head> <body> Hi, i solved the problem by downgrading the 389-ds-base from the one that comes with F17 - 1.2.11.3-1 to the one that comes with F16. I essentially did a rpmbuild --rebuild of the 1.2.10.8-1 srpm. Right now everything seems fine. It seems freeipa doesn't work ok with the 1.2.11 tree of 389-ds. Br, --ilf On Fri May 18 2012 05:04:20 PM EEST, Rob Crittenden <<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a>> wrote: > Rich Megginson wrote: > > On 05/17/2012 03:13 PM, Iliyan Stoyanov wrote: > > > Hello, > > > > > > I'm running latest (as of today) F17 with FreeIPA v.2.2.0. After > > > running ipa-server-install everything runs alright and IPA is running > > > fine. 389, kerberos and the rest of the components start up fine. > > > However after reboot of the machine IPA doesn't want to start, > > > systemctl status ipa.service reports: > > > > > > ipa.service - Identity, Policy, Audit > > > Loaded: loaded (/usr/lib/systemd/system/ipa.service; enabled) > > > Active: failed (Result: exit-code) since Thu, 17 May 2012 23:17:42 > > > +0300; 6min ago > > > Process: 567 ExecStart=/usr/sbin/ipactl start (code=exited, > > > status=1/FAILURE) > > > CGroup: name=systemd:/system/ipa.service > > > > > > May 17 23:17:40 cerberus.intra.evilpuppy.bg ipactl[567]: Failed to > > > read data from Directory Service: Unknown error when retrieving list > > > of services from LDAP: [Errno 111] Connection refused > > > May 17 23:17:40 cerberus.intra.evilpuppy.bg ipactl[567]: Shutting > > > down May 17 23:17:41 cerberus.intra.evilpuppy.bg ipactl[567]: > > > Starting Directory Service > > > > > > and ipactl start just repeats the error: > > > > > > ipactl start > > > Starting Directory Service > > > Failed to read data from Directory Service: Unknown error when > > > retrieving list of services from LDAP: [Errno 111] Connection refused > > > Shutting down > > > > > > If I start ns-slapd by hand with ns-slapd -D > > > /etc/dirsrv/slapd-PKI-IPA && ns-slapd -D /etc/dirsrv/slapd-MYREALM, > > > slapd starts, however the MYREALM instance throws > > > > > > etc/dirsrv/slapd-MYREALM/dse.ldif: nsslapd-maxdescriptors: > > > nsslapd-maxdescriptors: invalid value "8192", maximum file > > > descriptors must range from 1 to 4096 (the current process limit). > > > Server will use a setting of 4096. > > > [17/May/2012:23:25:29 +0300] - Config Warning: - > > > nsslapd-maxdescriptors: invalid value "8192", maximum file > > > descriptors must range from 1 to 4096 (the current process limit). > > > Server will use a setting of 4096. > > > > > > which however is not a big problem, but it seems ns-slapd doesn't > > > care about the limits that are setup in the limits.conf. > > > > It cares, but the systemd conf file must also specify NOFILES=8192 > > > > > > > > after starting the directory server I again try with systemctl start > > > ipa.service and the result this time is: > > > > > > ipa.service - Identity, Policy, Audit > > > Loaded: loaded (/usr/lib/systemd/system/ipa.service; enabled) > > > Active: failed (Result: exit-code) since Thu, 17 May 2012 23:28:02 > > > +0300; 25s ago > > > Process: 942 ExecStart=/usr/sbin/ipactl start (code=exited, > > > status=1/FAILURE) > > > CGroup: name=systemd:/system/ipa.service > > > > > > May 17 23:28:02 cerberus.intra.evilpuppy.bg ipactl[942]: Job failed. > > > See system journal and 'systemctl status' for details. > > > May 17 23:28:02 cerberus.intra.evilpuppy.bg ipactl[942]: Failed to > > > start KDC Service > > > May 17 23:28:02 cerberus.intra.evilpuppy.bg ipactl[942]: Shutting > > > down May 17 23:28:02 cerberus.intra.evilpuppy.bg ipactl[942]: > > > Aborting ipactl May 17 23:28:02 cerberus.intra.evilpuppy.bg > > > ipactl[942]: Starting Directory Service > > > May 17 23:28:02 cerberus.intra.evilpuppy.bg ipactl[942]: Starting KDC > > > Service > > > > > > the /var/log/krb5kdc.log reports: > > > > > > rb5kdc: Server error - while fetching master key K/M for realm > > > MYREALM May 17 23:14:25 cerberus.--redacted-- krb5kdc[3275](debug): > > > Got signal to request exit > > > May 17 23:14:25 cerberus.--redacted-- krb5kdc[3275](info): closing > > > down fd 9 > > > May 17 23:14:25 cerberus.--redacted-- krb5kdc[3275](info): closing > > > down fd 10 > > > May 17 23:14:25 cerberus.--redacted-- krb5kdc[3275](info): closing > > > down fd 8 > > > May 17 23:14:25 cerberus.--redacted-- krb5kdc[3275](info): closing > > > down fd 7 > > > May 17 23:14:25 cerberus.--redacted-- krb5kdc[3275](info): shutting > > > down krb5kdc: Server error - while fetching master key K/M for realm > > > MYREALM > > > > > > > From what I get from the kdc.conf file in /var/kerberos/krb5kdc it > > > seems like the files > > > pkinit_identity = FILE:/var/kerberos/krb5kdc/kdc.pem > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem > > > are missing in that path, however I don't really know what should > > > generate those pem certs. From my very basic understanding of how IPA > > > works I assume that is dogtag's job, and again I assume ipactl > > > start/systemctl start ipa.service probably should take care of that, > > > however this doesn't happen. > > > > > > So any help with this issue is welcome. I can go for LDAP/KRB setup > > > to use on my virtual/physical machines, however if going down the > > > krb/LDAP route I think IPA would be far better to support in the > > > long run. > > > > > > If that might be some help, I'm running x86_64 F17 inside Xen domU. > > > The host is Fedora 17 Dom0 with a bunch of other CentOS6.2 and > > > NetBSD6 DomU. > > > > > > I have the exact same situation also with FreeIPA built from git. The > > > packages from git are version 2.99: > > > > > > freeipa-server-selinux-2.99.0GIT46c6ff6-0.fc17.x86_64 > > > freeipa-python-2.99.0GIT46c6ff6-0.fc17.x86_64 > > > freeipa-admintools-2.99.0GIT46c6ff6-0.fc17.x86_64 > > > freeipa-server-2.99.0GIT46c6ff6-0.fc17.x86_64 > > > freeipa-client-2.99.0GIT46c6ff6-0.fc17.x86_64 > > > > > > the 2.2.0 version I also ran was the one in F17. > > > > > > Thanks in advance, > > > BR > > > ilf > > It could be a timeout problem. ipactl starts the dirsrv instance to get > the list of services it needs to start. If this connect fails it would > behave this way. If you look in /usr/sbin/ipactl you'll see a 6 second > timeout. I'd try bumping that up to a higher value. > > rob </body> </html>