Bug 552419 - 389-admin-1.1.10-0.2.a2.el5 fails to start
Summary: 389-admin-1.1.10-0.2.a2.el5 fails to start
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Admin
Version: 1.2.1
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 434915 389_1.2.6
TreeView+ depends on / blocked
 
Reported: 2010-01-04 23:34 UTC by Orion Poplawski
Modified: 2015-12-07 17:11 UTC (History)
4 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-12-07 17:11:12 UTC


Attachments (Terms of Use)
patch (1.30 KB, patch)
2010-01-20 23:18 UTC, Rich Megginson
nkinder: review+
Details | Diff

Description Orion Poplawski 2010-01-04 23:34:23 UTC
Description of problem:

fedora-ds-admin-1.1.6 was previously installed and working fine.  Update to epel-testing and:

# service dirsrv-admin start
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]

/var/log/audit/audit.log shows:

type=AVC msg=audit(1262648027.976:112): avc:  denied  { name_bind } for  pid=5043 comm="httpd.worker" src=9830 scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1262648027.976:112): arch=40000003 syscall=102 success=no exit=-13 a0=2 a1=bff527f0 a2=14f988 a3=8199a18 items=0 ppid=5035 pid=5043 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="httpd.worker" exe="/usr/sbin/httpd.worker" subj=root:system_r:httpd_t:s0 key=(null)

Version-Release number of selected component (if applicable):
389-admin-1.1.10-0.2.a2.el5

Comment 1 Orion Poplawski 2010-01-04 23:39:21 UTC
389-admin-1.1.9-1.el5 works fine.

Comment 2 Nathan Kinder 2010-01-20 19:34:59 UTC
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.

Comment 3 Rich Megginson 2010-01-20 23:18:22 UTC
Created attachment 385810 [details]
patch

Comment 4 Rich Megginson 2010-01-21 00:07:26 UTC
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@redhat.com>
Date:   Wed Jan 20 15:53:08 2010 -0700

Comment 5 Fedora Update System 2010-01-21 02:12:53 UTC
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

Comment 6 Fedora Update System 2010-01-21 02:12:57 UTC
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

Comment 7 Fedora Update System 2010-01-21 02:13:02 UTC
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

Comment 8 Orion Poplawski 2010-01-25 22:30:21 UTC
Looks good to me.  Thanks.

Comment 9 Fedora Update System 2010-01-27 01:08:59 UTC
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.

Comment 10 Fedora Update System 2010-01-27 01:10:09 UTC
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.

Comment 11 Fedora Update System 2010-01-28 21:15:49 UTC
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.

Comment 12 Orion Poplawski 2010-03-09 22:45:36 UTC
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.

Comment 13 Nathan Kinder 2010-03-09 23:33:43 UTC
What does 'semodule -l | grep dirsrv' show?

Comment 14 Orion Poplawski 2010-03-09 23:35:47 UTC
dirsrv-admin    1.0.0
dirsrv  1.0.0

Comment 15 Nathan Kinder 2010-03-09 23:50:00 UTC
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.

Comment 16 Orion Poplawski 2010-03-10 22:53:04 UTC
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.

Comment 17 Rich Megginson 2010-03-10 23:27:28 UTC
(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?

Comment 18 Orion Poplawski 2010-03-11 00:09:18 UTC
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....

Comment 19 Orion Poplawski 2010-03-11 22:57:37 UTC
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.

Comment 20 Nathan Kinder 2010-03-12 00:16:11 UTC
(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.

Comment 21 Orion Poplawski 2010-09-24 14:32:21 UTC
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.

Comment 23 Amita Sharma 2011-09-12 10:13:23 UTC
I have tested it during upgrade testing. hence VERIFIED.


Note You need to log in before you can comment on or make changes to this bug.