389-admin-1.1.9-1.el5 works fine.

We are working on releasing a new testing build shortly that should fix this issue.  The build will be 389-admin-1.1.10-0.4a4.el5.  It will contain a selinux subpackage with proper policy for the Administration Server.

Created attachment 385810 [details]
patch

To ssh://git.fedorahosted.org/git/389/admin.git
   b195444..491d551  master -> master
 * [new tag]         389-admin-1.1.10 -> 389-admin-1.1.10

commit d86582ef5dc1fd56ce7fd442c446626a3c045b13
Author: Rich Megginson <rmeggins>
Date:   Wed Jan 20 15:53:08 2010 -0700

389-admin-1.1.10-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/389-admin-1.1.10-1.fc11

389-admin-1.1.10-1.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/389-admin-1.1.10-1.el5

389-admin-1.1.10-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/389-admin-1.1.10-1.fc12

Looks good to me.  Thanks.

389-admin-1.1.10-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

389-admin-1.1.10-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

389-admin-1.1.10-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Seems to be back with:

389-admin-1.1.11-0.2.a2.el5
389-admin-selinux-1.1.11-0.2.a2.el5
selinux-policy-2.4.6-277.el5

type=AVC msg=audit(1268173721.982:11): avc:  denied  { name_bind } for  pid=1491 comm="httpd.worker" src=9830 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket

Starting dirsrv-admin: 
(13)Permission denied: make_sock: could not bind to address 0.0.0.0:9830
no listening sockets available, shutting down
Unable to open logs
                                                           [FAILED]

Note that I'm using dwalsh's selinux repo for and updated selinux-policy.  CC'ing him to see if to see if that is causing a conflict.

What does 'semodule -l | grep dirsrv' show?

dirsrv-admin    1.0.0
dirsrv  1.0.0

Was this an upgrade from a previous version of 389-admin that did not have an selinux subpackage?  I think this might be an upgrade bug.

I believe that this could be an issue where the Admin Server port is not labelled properly.  The setup-ds-admin.pl program is supposed to label the chosen port (default of 9830, which is what is being used in your case) with a label of http_port_t.  Please run 'semanage port -l | grep http' and put the output in this bug.

If port 9830 is not labelled, you can label it manually by running 'semanage port -a -t http_port_t -p tcp 9830'.  I would also like a new bug opened on this issue if you find that the port is not labelled, as we need to make upgrade deal with this port labelling.

I should note that updating my current install:

fedora-ds-1.1.2-1.el5
fedora-ds-admin-1.1.6-1.el5
fedora-ds-admin-console-1.1.2-1.el5
fedora-ds-base-1.1.2-1.el5
fedora-ds-console-1.1.2-2.el5
fedora-ds-dsgw-1.1.1-1.el5
fedora-idm-console-1.1.1-2.el5

to:

389-admin-1.1.10-1.el5
389-admin-console-1.1.4-3.el5
389-admin-console-doc-1.1.4-3.el5
389-console-1.1.3-6.el5
389-ds-1.1.3-6.el5
389-ds-base-1.2.5-1.el5
389-ds-console-1.2.0-5.el5
389-ds-console-doc-1.2.0-5.el5
389-dsgw-1.1.4-1.el5

goes fine, so this original bug report is fixed.  We can close and open a new one if desired.

If I then do:

yum -y --enablerepo=epel-testing upgrade

I get:

Updated:
  389-admin.i386 0:1.1.11-0.2.a2.el5         
  389-ds-base.i386 0:1.2.6-0.2.a2.el5            
  jss.i386 0:4.2.6-6.el5    
  python-simplejson.i386 0:2.0.9-1.el5           

Then I run "setup-ds-admin.pl -u"

But then:

# service dirsrv-admin restart
Shutting down dirsrv-admin: 
                                                           [  OK  ]
Starting dirsrv-admin: 
(13)Permission denied: make_sock: could not bind to address 0.0.0.0:9830
no listening sockets available, shutting down
Unable to open logs
                                                           [FAILED]

Note that the update did not bring in the -selinux packages, which I think is a real problem.

(In reply to comment #16)
> I should note that updating my current install:
> 
> fedora-ds-1.1.2-1.el5
> fedora-ds-admin-1.1.6-1.el5
> fedora-ds-admin-console-1.1.2-1.el5
> fedora-ds-base-1.1.2-1.el5
> fedora-ds-console-1.1.2-2.el5
> fedora-ds-dsgw-1.1.1-1.el5
> fedora-idm-console-1.1.1-2.el5
> 
> to:
> 
> 389-admin-1.1.10-1.el5
> 389-admin-console-1.1.4-3.el5
> 389-admin-console-doc-1.1.4-3.el5
> 389-console-1.1.3-6.el5
> 389-ds-1.1.3-6.el5
> 389-ds-base-1.2.5-1.el5
> 389-ds-console-1.2.0-5.el5
> 389-ds-console-doc-1.2.0-5.el5
> 389-dsgw-1.1.4-1.el5
> 
> goes fine, so this original bug report is fixed.  We can close and open a new
> one if desired.
> 
> If I then do:
> 
> yum -y --enablerepo=epel-testing upgrade
> 
> I get:
> 
> Updated:
>   389-admin.i386 0:1.1.11-0.2.a2.el5         
>   389-ds-base.i386 0:1.2.6-0.2.a2.el5            
>   jss.i386 0:4.2.6-6.el5    
>   python-simplejson.i386 0:2.0.9-1.el5           
> 
> Then I run "setup-ds-admin.pl -u"
> 
> But then:
> 
> # service dirsrv-admin restart
> Shutting down dirsrv-admin: 
>                                                            [  OK  ]
> Starting dirsrv-admin: 
> (13)Permission denied: make_sock: could not bind to address 0.0.0.0:9830
> no listening sockets available, shutting down
> Unable to open logs
>                                                            [FAILED]
> 
> Note that the update did not bring in the -selinux packages, which I think is a
> real problem.    

Yes, that is a big problem.  But how to make it bring in the -selinux packages?  Right now, the 389-ds-base-selinux package depends on the 389-ds-base package - should it be the other way around?

Well, the first problem to tackle is that the update script is not labeling the port:

# semanage port -l | grep http_port_t
http_port_t                    tcp      80, 443, 488, 8008, 8009, 8443

which should be happening regardless of the presence of the -selinux package.

More testing tomorrow....

Okay, here's your problem in AdminServer.pm :

sub createAdminServer {
...
    # if we're just doing the update, just register and return
    if ($setup->{update}) {
        if (!registerASWithConfigDS($setup, $configdir)) {
            return 0;
        }
        return 1;
    }
....
    # Update SELinux policy if needed
    updateSelinuxPolicy($setup, $configdir, $securitydir, $logdir, $rundir);


So you aren't setting SELinux policy on updates.  There's some other stuff in there too that may need to run during an update as well.

But after running:

semanage port -a -t http_port_t -p tcp 9830

by hand, it starts up fine without the -selinux package.  So the -selinux is not required.  I'll file a separate bug for issues with that.

(In reply to comment #19)
> Okay, here's your problem in AdminServer.pm :
> 
> sub createAdminServer {
> ...
>     # if we're just doing the update, just register and return
>     if ($setup->{update}) {
>         if (!registerASWithConfigDS($setup, $configdir)) {
>             return 0;
>         }
>         return 1;
>     }
> ....
>     # Update SELinux policy if needed
>     updateSelinuxPolicy($setup, $configdir, $securitydir, $logdir, $rundir);
> 
> 
> So you aren't setting SELinux policy on updates.  There's some other stuff in
> there too that may need to run during an update as well.

Yes, I was looking at this section of code yesterday.  We will need to attempt to update the policy during an update as well instead of simply returning.

> 
> But after running:
> 
> semanage port -a -t http_port_t -p tcp 9830
> 
> by hand, it starts up fine without the -selinux package.  So the -selinux is
> not required.  I'll file a separate bug for issues with that.    

The original idea was to make the -selinux package optional.  I'm not so sure if that can work well or not at this point though.  The start-ds-admin script has logic in it that is supposed to run adminserver as unconfined_t if selinux is not enabled, but that doesn't help in the case where selinux is enabled but the -selinux subpackage is not installed.  Open the new bug for that issue and we can figure out the best approach to take.

Just hit this again with 389-admin-1.1.11-1.el5 on EL 5.5.  Ran

semanage port -a -t http_port_t -p tcp 9830

and all is well.

I have tested it during upgrade testing. hence VERIFIED.