This is going to be a 2-step bug. The first step is to handle the exception that is being raised and the second is to handle the cause of that exception.

https://fedorahosted.org/freeipa/ticket/249

The underlying problem appears to be SELinux-related. The DS instance for dogtag isn't running so dogtag can't really do anything. I'm seeing these AVCs (on qe-blade-05):

type=AVC msg=audit(1285003795.282:83): avc:  denied  { name_bind } for  pid=31772 comm="ns-slapd" src=7389 scontext=unconfined_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1285003795.282:83): arch=c000003e syscall=49 success=no exit=-13 a0=6 a1=7fffbb729290 a2=1c a3=0 items=0 ppid=31771 pid=31772 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=7 comm="ns-slapd" exe="/usr/sbin/ns-slapd" subj=unconfined_u:system_r:dirsrv_t:s0 key=(null)
type=AVC msg=audit(1285003801.233:84): avc:  denied  { name_bind } for  pid=31799 comm="ns-slapd" src=7389 scontext=unconfined_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1285003801.233:84): arch=c000003e syscall=49 success=no exit=-13 a0=6 a1=7fff3704aa80 a2=1c a3=0 items=0 ppid=31798 pid=31799 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=7 comm="ns-slapd" exe="/usr/sbin/ns-slapd" subj=unconfined_u:system_r:dirsrv_t:s0 key=(null)

I'm not sure what changed as I don't see this in F-12. audit2allow says the following rule should be added:

allow dirsrv_t port_t:tcp_socket name_bind;

Nathan, have you seen anything like this? It's really strange because the other instance is up and running fine.

We use the following macro to allow ns-slapd to bind to LDAP ports (ldap_port_t):

  corenet_tcp_bind_ldap_port(dirsrv_t)

My guess is that the port that this instance is configured to run on was never labelled correctly.  What ports are configured for this problem DS instance?  Is this instance configured for LDAPS?  The setup-ds.pl script labels the plain LDAP port that is selected at install time, but one must manually label the LDAPS port if it is configured later.  The default ports of 389 and 636 are already labelled on the system, but anything else needs to be labelled manually for LDAPS.

The port is 7389

What does this command show?

    semanage port -l | grep ldap_port_t

If 7389 does not show up, it needs to be labelled with these commands:

    semanage port -a -t ldap_port_t -p tcp 7389
    semanage port -a -t ldap_port_t -p udp 7389

The machine I was looking at was re-installed so I can't be sure exactly what the state was but clearly 7389 wasn't allowed. Right now it reports:

# semanage port -l | grep ldap_port_t
ldap_port_t                    tcp      389, 636, 3268
ldap_port_t                    udp      389, 636

It is not configured to use SSL. The only port configured is 7389 which is done with setup-ds.pl with this inf:

[General]
FullMachineName=   test.example.com
SuiteSpotUserID=   admin
ServerRoot=    /usr/lib64/dirsrv
[slapd]
ServerPort=   7389
ServerIdentifier=   PKI-IPA
Suffix=   dc=testrealm
RootDN=   cn=Directory Manager

I gather I'm going to need to modify the IPA installer to always allow 7389? If so I'm going to need to add a Requires on policycoreutils-python.

This is 389-ds-base-1.2.6-1.fc13.x86_64

The setup-ds.pl script should be running semanage to label the port for you.  Does it fail to label the port every time?  Removing an instance also removes the port label, so I wouldn't expect to see 7389 listed after you ran remove-ds.pl.

Nathan, we don't use remove-ds.pl to remove a DS instance. We do it manually (our removal process predates remove-ds.pl).

Michael, can you set enforcing and do a fresh install an then run 'semanage port -l | grep ldap_port_t' to see what ports are open?

semanage is provided by policycoreutils-python. 

I doesn't appear to be on some of these systems. That is, ipa-server does not require policycoreutils-python

It doesn't look like that's a problem though, I installed semanage, and get this as a result:

[root@qe-blade-12 ~]# semanage port -l | grep ldap_port_t
ldap_port_t                    tcp      389, 636, 3268
ldap_port_t                    udp      389, 636

I'll try running things again, maybe there is something that I'm missing. 

Should I open a ticket to get policycoreutils-python added to the deps of ipa-server?

No need for a ticket just yet. If it turns out IPA will be responsible for adding the SELinux port then that's what we'll do.

The 389-ds-base package requires policycoreutils-python, so semanage should have been on the system already.

389-ds-base doesn't seem to require policycoreutils-python.

Could I have a bad build?

[root@qe-blade-12 ~]# rpm -q --requires 389-ds-base | grep python
[root@qe-blade-12 ~]# echo $?
1

policycoreutils is in there though:
[root@qe-blade-12 ~]# rpm -q --requires 389-ds-base | grep policycoreutils
policycoreutils  
policycoreutils  
policycoreutils  
policycoreutils  
[root@qe-blade-12 ~]# 

Version:
[root@qe-blade-12 ~]# rpm -qa 389-ds-base 
389-ds-base-1.2.6-1.fc13.i686

It turns out that the dependency on policycoreutils-python was dropped accidentally when the spec files were moved from cvs to git.  We will get a new 389-ds-base-1.2.6 package out that fixes this.

Michael, can you try manually installing policycoreutils-python and then the IPA installer to see if things work?

Should a bug be opened against 389-ds to check the return value of semanage and raise an issue if it fails (or doesn't exist)?

I added back the correct dependencies to the 389-ds-base.spec for F-13 - this problem will be fixed by version 1.2.6-2