The condition is set at the building/packaging time.

This is the snippet of the source code:
---------------------------------------
sub updateSelinuxPolicy {
    my $inf = shift;

    # if selinux is not available, do nothing
    if ("@with_selinux@") {
        my $localstatedir = $inf->{slapd}->{localstatedir};
---------------------------------------
When we build 389-ds-base, we run configure with "--with-selinux"
> %configure --enable-autobind --with-selinux

then, the variable @with_selinux@ is replaced as follows in the build.
> -e 's,@with_selinux\@,yes,g'

That is, we don't support without selinux.

eventual change with yet another system command (as there is apparently no semanage bindings nor module to perl):

(note: I removed the absolute path to egrep, as it is different on RHEL 6 and RHEL 7)


diff -u /usr/lib64/dirsrv/perl/DSCreate.pm.orig /usr/lib64/dirsrv/perl/DSCreate.pm
--- /usr/lib64/dirsrv/perl/DSCreate.pm.orig     2015-06-09 10:42:34.000000000 -0700
+++ /usr/lib64/dirsrv/perl/DSCreate.pm  2015-09-03 19:32:54.268000072 -0700
@@ -971,7 +971,8 @@
     my $inf = shift;
 
     # if selinux is not available, do nothing
-    if ("yes") {
+#    if ("yes") {
+if (!system ("/usr/sbin/sestatus | egrep \"SELinux status:\s*enabled\"")) {
         my $localstatedir = $inf->{slapd}->{localstatedir};
 
         # run restorecon on all of the parent directories we
@@ -1375,7 +1376,8 @@
     }
 
     # remove the selinux label from the ports if needed
-    if ("yes") {
+#    if ("yes") {
+if (!system ("/usr/sbin/sestatus | egrep \"SELinux status:\s*enabled\"")) {
         foreach my $port (@{$entry->{"nsslapd-port"}}) 
         {
             my $semanage_err = `semanage port -d -t ldap_port_t -p tcp $port 2>&1`;

one small though:

there could be a warning msg when SELinux is disabled, similar to those:

+++no tmpfiles.d - skipping
+++no systemd - skipping

about the comment 2

> That is, we don't support without selinux.

I was wondering about this, but could not find any requirement about SELinux in the release notes and in the installation guide (https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/10/pdf/Installation_Guide/Red_Hat_Directory_Server-10-Installation_Guide-en-US.pdf)

there is one reference in the deployment guide
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Deployment_Guide/selinux.html
"
 By default, the Directory Server runs confined by SELinux policies. 
"
but no hard requirement, that could be an issue for some customers.

I am trying to provision a docker container running on Centos 7 and selinux isn't functional inside the container so the setup script is failing (it keeps trying to register a port with selinux every 5 seconds). It would be nice if the calls to updateSelinuxPolicy were done in way that allowed them to be turned off via command-line option or by checking the status of selinux. I have seen other people that seem to have built containers that install 389-ds on Centos 6 and I am not sure why that worked.

(In reply to Hal Deadman from comment #7)
> I am trying to provision a docker container running on Centos 7 and selinux
> isn't functional inside the container

Why?

> so the setup script is failing (it
> keeps trying to register a port with selinux every 5 seconds). It would be
> nice if the calls to updateSelinuxPolicy were done in way that allowed them
> to be turned off via command-line option or by checking the status of
> selinux. I have seen other people that seem to have built containers that
> install 389-ds on Centos 6 and I am not sure why that worked.

I assume you are asking why isn't selinux functioning inside the container (as opposed to why am installing 389 in a container).

I am relatively new to containers and selinux but I thought that selinux was operating on the host and that container couldn't have its own selinux policies. Since I am building a container that will run on a different host I don't want to modify the hosts selinux policies so I am not running the container in privileged mode. The centos7 image has the selinux packages installed and semanage is installed (presumably as dependency of 389 or by the puppet module I am using to install 389) but when semanage is run it can't modify the policies. 

For example:

[vagrant@ldap-container ~]$ sudo semanage port -a -t ldap_port_t -p tcp 389
ValueError: SELinux policy is not managed or store cannot be accessed.

I assume where ever selinux stores its policies is mounted to the container read-only or docker is otherwise preventing the container from updating the hosts policies.

(In reply to Hal Deadman from comment #9)
> I assume you are asking why isn't selinux functioning inside the container
> (as opposed to why am installing 389 in a container).

Yes.

> 
> I am relatively new to containers and selinux but I thought that selinux was
> operating on the host and that container couldn't have its own selinux
> policies. Since I am building a container that will run on a different host
> I don't want to modify the hosts selinux policies so I am not running the
> container in privileged mode. The centos7 image has the selinux packages
> installed and semanage is installed (presumably as dependency of 389 or by
> the puppet module I am using to install 389) but when semanage is run it
> can't modify the policies. 
> 
> For example:
> 
> [vagrant@ldap-container ~]$ sudo semanage port -a -t ldap_port_t -p tcp 389
> ValueError: SELinux policy is not managed or store cannot be accessed.
> 
> I assume where ever selinux stores its policies is mounted to the container
> read-only or docker is otherwise preventing the container from updating the
> hosts policies.

I'm not sure.  Jan, you have 389 running in docker, correct?  With selinux policy enforcement?

(In reply to Rich Megginson from comment #10)
> 
> I'm not sure.  Jan, you have 389 running in docker, correct?  With selinux
> policy enforcement?

389 as part of FreeIPA. Yes, with SELinux enforcing but it does not use the standard SELinux types -- all proceses in that container run as system_u:system_r:svirt_lxc_net_t:s0:c886,c998 (the MLS values are generated, providing separatation of containers from each other).

What is the exact Dockerfile which you attempt to use?

I am using puppet to provision the container (using Packer, but Vagrant for developing the Puppet module) so I don't have a Dockerfile but the Puppet module I am using is running the setup-ds-admin.pl script. To bypass the updateSelinuxPolicy function I used sed to make it return immediately. I would prefer not to have to do that. If you are able to run setup-ds-admin.pl in a container and have a Dockerfile you could point me to then I can look at it and see what you are doing differently that makes updateSelinuxPolicy work. 


#sed hack
      if $disable_selinux_config {
        exec { "disable selinux with sed":
          path      => [ '/bin', '/sbin', '/usr/bin', '/usr/sbin' ],
          command   => "sed -i 's/sub updateSelinuxPolicy {/& return;/' /usr/lib64/dirsrv/perl/*.pm",
          unless    => 'grep "sub updateSelinuxPolicy { return; /usr/lib64/dirsrv/perl/*.pm' ,
          logoutput => true,
          before    => Exec["setup-ds-admin.pl_${title}"],
          require   => Package['389-admin'],
        }
      }

I doubt Jan is running setup-ds-admin.pl since that is applicable to the 389 admin server / console setup only.  But ipa setup will run setup-ds.pl, which also requires selinux policy.  And the sed/grep commands above would apply to setup-ds.pl and setup-ds-admin.pl.  ipa-server-install runs setup-ds.pl.

So Jan, same question applies - are you running the ipa-server-install in the container?

I suppose I should be running setup-ds.pl. I got setup-ds-admin.pl to work in a container (with my sed hack) but the base container had ssh and systemd setup so that vagrant could connect to it and run puppet. When I try to provision the ldap container with Packer I only have fakesystemd in the base container so I need to tell setup-ds.pl not to start the server (since it tries to use systemctl that doesn't work). There are inf options that let me turn off starting the server so that shouldn't be a problem.

(In reply to Rich Megginson from comment #13)
> 
> So Jan, same question applies - are you running the ipa-server-install in
> the container?

Yes:

https://github.com/adelton/docker-freeipa/blob/master/ipa-server-configure-first#L163

I think the reason selinux wasn't working in the base centos7 container was that the selinux-policy and selinux-policy-targeted packages were not installed. The docker-freeipa project installs those on the fedora image they use which is one of the reasons why the setup works there. I can add those packages to get the farther in the setup script but the next place that I get an error in the container is when it tries to updateSystemD in the setup script. If a container is just running a single ldap server it should be able to run it without systemd but updateSystemD can't be turned off via a setup script parameter or inf item. The IPA container is running lots of services and has a fully functional systemd installation which is why they don't have a problem. 

I understand that the systemd parts of the setup script can also be turned off at compile time (just like selinux) but it would be nice if they could also be turned off at runtime.

(In reply to Hal Deadman from comment #16)
> I think the reason selinux wasn't working in the base centos7 container was
> that the selinux-policy and selinux-policy-targeted packages were not
> installed. The docker-freeipa project installs those on the fedora image
> they use which is one of the reasons why the setup works there. I can add
> those packages to get the farther in the setup script but the next place
> that I get an error in the container is when it tries to updateSystemD in
> the setup script. If a container is just running a single ldap server it
> should be able to run it without systemd but updateSystemD can't be turned
> off via a setup script parameter or inf item. The IPA container is running
> lots of services and has a fully functional systemd installation which is
> why they don't have a problem. 
> 
> I understand that the systemd parts of the setup script can also be turned
> off at compile time (just like selinux) but it would be nice if they could
> also be turned off at runtime.

A lot of the directory server management scripts assume that you are using systemd.  So those won't work either.  That is, you might be able to get past setup-ds.pl, but find that you can't use several of the management scripts after that.

I think the next step with the container-ization of 389 is getting systemd to work inside the container.

If you just want "gimme the bits, I don't care about any of this selinux/systemd jazz, I'll handle security and service management by myself" then we will need to figure out how to support this use case upstream.

Yes, I should probably run 389 in a container that looks similar to the server it was designed to run on. When I run in a container with systemd working (according to the instructions on the docker hub - https://hub.docker.com/_/centos/) then everything works without me having to change setup-ds.pl (assuming I add the selinux-policy packages to the centos7 base container). By works I mean it installs and the 389 server is started by systemd when the container is run, and I am able to provision the server with schema customizations and ldif imports - I haven't used the container much yet.

Upstream ticket:
https://fedorahosted.org/389/ticket/48305

The -f /dev/null test does not work.  Reopening.  https://bugzilla.redhat.com/show_bug.cgi?id=1287547 is a duplicate of this bug.

*** Bug 1287547 has been marked as a duplicate of this bug. ***

1). Disable selinux and reboot the system.
[root@iceman ~]# perl -pi -e 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config
2). [root@iceman ~]# Reboot
3). [root@iceman ~]# getenforce
Disabled
4). Remove selinux targeted rpm
root@iceman ~]# yum -y remove selinux-policy-targeted
[root@iceman ~]# echo $?
0
5). [root@iceman ~]# mv  /etc/selinux/targeted/policy  /etc/selinux/targeted/policy-1
mv: cannot stat `/etc/selinux/targeted/policy': No such file or directory
6). Create instance using setup-ds-admin.pl with verbose log.
/usr/sbin/setup-ds-admin.pl -ddddddd --silent --file=/export/silent.inf

7). Semanage error from setup-ds-admin.pl script
NMC_Status: 0

libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/policy.kern to /etc/selinux/targeted/policy/policy.24. (No such file or directory).
libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/policy.kern to /etc/selinux/targeted/policy/policy.24. (No such file or directory).
/usr/sbin/semanage: Could not commit semanage transaction
Starting admin server . . .
+Changing the owner of /var/log/dirsrv/admin-serv/access to (99, 99)
+Changing the owner of /var/log/dirsrv/admin-serv/error to (99, 99)
output: Starting dirsrv-admin: 
output: [  OK  ]
The admin server was successfully started.
Admin server was successfully created, configured, and started.
Exiting . . .
Log file is '/tmp/setupjRcEW9.log'


[root@iceman ~]# semanage port -a -t ldap_port_t -p tcp 1389
libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/policy.kern to /etc/selinux/targeted/policy/policy.24. (No such file or directory).
libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/policy.kern to /etc/selinux/targeted/policy/policy.24. (No such file or directory).
/usr/sbin/semanage: Could not commit semanage transaction


I am still seeing errors from selinux. Is this expected?

This is a bug against 389-ds-base, which does not include the admin server.

Note that this upstream is opened for the admin server (RHDS), which is not touched yet.
https://fedorahosted.org/389/ticket/48306

That said, instead of setup-ds-admin.pl, please use setup-ds.pl for testing.
6). Create instance using setup-ds-admin.pl with verbose log.
/usr/sbin/setup-ds-admin.pl -ddddddd --silent --file=/export/silent.inf

Thanks.

Thanks Noriko for the clarification. I re-ran the setup-ds.pl with verbose option. This time I didn't see any errors for selinux. Hence, marking the bug as Verified.

/usr/sbin/setup-ds.pl -ddddddd --silent --file=/export/silent.inf

+[29/Mar/2016:06:14:17 -0400] - All database threads now stopped
+[29/Mar/2016:06:14:17 -0400] - import userRoot: Import complete.  Processed 9 entries in 2 seconds. (4.50 entries/sec)
+[29/Mar/2016:06:14:17 -0400] - 389-Directory/1.2.11.15 B2016.063.2110 starting up
+[29/Mar/2016:06:14:17 -0400] - Db home directory is not set. Possibly nsslapd-directory (optinally nsslapd-db-home-directory) is missing in the config file.
+[29/Mar/2016:06:14:17 -0400] - resizing db cache size: 3300933632 -> 8000000
+[29/Mar/2016:06:14:18 -0400] - slapd started.  Listening on All Interfaces port 1289 for LDAP requests
+Your new directory server has been started.
Your new DS instance 'testinst2' was successfully created.
Exiting . . .
Log file is '/tmp/setup4Bc2Ln.log'

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0737.html