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