Bug 1259959 - perl module conditional test is not conditional when checking SELinux policies
Summary: perl module conditional test is not conditional when checking SELinux policies
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.7
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
Petr Bokoc
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-04 00:04 UTC by Marc Sauton
Modified: 2020-09-13 21:33 UTC (History)
8 users (show)

Fixed In Version: 389-ds-base-1.2.11.15-70.el6
Doc Type: Bug Fix
Doc Text:
Cause: Install/Uninstall scripts always call SELinux commands such as semanage and restorecon. Consequence: If sestatus reports SELinux is disabled, SELinux commands such as semanage and restorecon fail. Fix: Code to check the status of SELinux and it calls the SELinux commandsonly if SELinux is enabled. Result: There is no more install/uninstall script failures even if SELinux is disabled.
Clone Of:
Environment:
Last Closed: 2016-05-10 19:21:12 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 1636 None closed perl module conditional test is not conditional when checking SELinux policies 2020-09-25 17:48:14 UTC
Github 389ds 389-ds-base issues 1637 None closed Admin Server -- perl module conditional test is not conditional when checking SELinux policies 2020-09-25 17:48:09 UTC
Red Hat Product Errata RHBA-2016:0737 normal SHIPPED_LIVE 389-ds-base bug fix and enhancement update 2016-05-10 22:29:13 UTC

Description Marc Sauton 2015-09-04 00:04:24 UTC
Description of problem:

this kind of a corner case, may be minor, but the following conditional tests are not really conditional, they are *always* true:

In /usr/lib64/dirsrv/perl/DSCreate.pm

There is a test to use or not use semanage for setup-ds-admin.pl calling createDSInstance which calls updateSelinuxPolicy.

The test is supposed to do nothing if SELinux is disabled, but we have this:

...snip...
sub updateSelinuxPolicy {
    my $inf = shift;

    # if selinux is not available, do nothing
    if ("yes") {
...snip...


Same test with remove-ds-admin.pl calling removeDSInstance in the perl module DSCreate.pm
It will try to access policy files that do not exist when SELinux is disabled on a system:

...snip...
    # remove the selinux label from the ports if needed
    if ("yes") {
        foreach my $port (@{$entry->{"nsslapd-port"}}) 
        {
            my $semanage_err = `semanage port -d -t ldap_port_t -p tcp $port 2>&1`;
...snip...


The actions with
   if ("yes") {
are very ironic.

The "problem" is there are systems configured without SELInux out there, and when some admin do not want SELinux, they just do not want it, the perception is "wrong", and opposite of what we want.


Version-Release number of selected component (if applicable):

RHEL 6.7
389-ds-base-1.2.11.15-60.el6.x86_64
RHEL7.1
389-ds-base-1.3.3.1-20.el7_1.x86_64

How reproducible:
always


Steps to Reproduce:

0. have a RHEL 6.7 or RHEL 7.1 system with 389-ds-base installed

1. Disable SELinux
cp -p /etc/sysconfig/selinux /etc/sysconfig/selinux.orig
perl -pi -e 's/^SELINUX=.*/SELINUX=disabled/' /etc/sysconfig/selinux
diff -u /etc/sysconfig/selinux.orig /etc/sysconfig/selinux 
...
-SELINUX=permissive
+SELINUX=disabled
...

2. reboot

note: I had an "unexpected" problem on my test RHEL 7.1 VM: SELINUX staid enabled even though I followed the usual simple steps as confirmed in the guide Red_Hat_Enterprise_Linux-7-SELinux_Users_and_Administrators_Guide-en-US.pdf
I do not know if SELinux can be disabled on 7.1, so after several re-check and reboots, so I only tested with a RHEL 6.7 VM, like a customer report in SF case number 01501498

getenforce 
Disabled

sestatus
SELinux status:                 disabled


3. now, to mimic the fact some users do not want SELinux at all, remove the package selinux-policy-targeted and delete left over policy:

rpm -e selinux-policy-targeted
mv  /etc/selinux/targeted/policy  /etc/selinux/targeted/policy-1


4. create an instance with verbose log

cat > /root/test.inf << EOF
[General]
AdminDomain = example.com
ConfigDirectoryAdminID = uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot
ConfigDirectoryAdminPwd = password
ConfigDirectoryLdapURL = ldap://m1.example.com:389/o=NetscapeRoot
FullMachineName = m1.example.com
ServerRoot = /usr/lib64/dirsrv
SuiteSpotGroup = nobody
SuiteSpotUserID = nobody
[admin]
Port = 8888
ServerAdminID = admin
ServerAdminPwd = {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
ServerIpAddress = 0.0.0.0
SysUser = nobody
[slapd]
AddOrgEntries = Yes
AddSampleEntries = No
HashedRootDNPwd = {SSHA}hYlIdKA3Ln3LrzZrd8mWSycaYnfIJw4TK70iOg==
InstallLdifFile = suggest
RootDN = cn=Directory Manager
RootDNPwd = password
ServerIdentifier = m1bis
ServerPort = 31081
Suffix = dc=example,dc=com
UseExistingMC = 1
bak_dir = /var/lib/dirsrv/slapd-m1bis/bak
bindir = /usr/bin
cert_dir = /etc/dirsrv/slapd-m1bis
config_dir = /etc/dirsrv/slapd-m1bis
datadir = /usr/share
db_dir = /var/lib/dirsrv/slapd-m1bis/db
ds_bename = userRoot
inst_dir = /usr/lib64/dirsrv/slapd-m1bis
ldif_dir = /var/lib/dirsrv/slapd-m1bis/ldif
localstatedir = /var
lock_dir = /var/lock/dirsrv/slapd-m1bis
log_dir = /var/log/dirsrv/slapd-m1bis
naming_value = example
run_dir = /var/run/dirsrv
sbindir = /usr/sbin
schema_dir = /etc/dirsrv/slapd-m1bis/schema
sysconfdir = /etc
tmp_dir = /tmp
EOF


/usr/sbin/setup-ds-admin.pl -ddddddd --silent --file=/root/test.inf 2>&1 | tee  ~/log.setup-ds-admin.pl.ddddddd.m1bis.selinux.disabled.no.rpm.selinux-policy-targeted.and.no.etc.selinux.targeted.policy.directory.txt



Actual results:

...
[03/Sep/2015:17:31:10 -0700] - import userRoot: Import complete.  Processed 9 entries in 1 seconds. (9.00 entries/sec)
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
+++no tmpfiles.d - skipping
+++no systemd - skipping
++Found brand specific inf file/usr/share/dirsrv/inf/redhat-slapd.inf
...


Expected results:

So of course there is no such file
/etc/selinux/targeted/policy/policy.24
because I removed it, but:

As SELinux is disabled, even if this is a corner case, the install call to createDSInstance in  /usr/lib64/dirsrv/perl/DSCreate.pm should not attempt to use the semanage tool in updateSelinuxPolicy
There should be no libsemanage or semanage related calls or trace.
The tests with 
   if ("yes") {
are wrong.


Additional info:

to verify the error:
semanage port -a -t ldap_port_t -p tcp 31081
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




less /usr/lib64/dirsrv/perl/DSCreate.pm
...
sub updateSelinuxPolicy {
    my $inf = shift;

    # if selinux is not available, do nothing
    if ("yes") {
...
...
            if ($need_label == 1) {
                system("semanage port -a -t ldap_port_t -p tcp $inf->{slapd}->{ServerPort}");
            }
        }
    }
}

...
sub createDSInstance {
    my $inf = shift;
    my @errs;
...
    if (@errs = initDatabase($inf)) {
        return @errs;
    }

    updateSelinuxPolicy($inf);

    if (@errs = updateTmpfilesDotD($inf)) {
        return @errs;
    }

    if (@errs = updateSystemD($inf)) {
        return @errs;
...

Comment 2 Noriko Hosoi 2015-09-04 00:23:58 UTC
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.

Comment 3 Marc Sauton 2015-09-04 01:41:10 UTC
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`;

Comment 4 Marc Sauton 2015-09-04 01:45:50 UTC
one small though:

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

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

Comment 5 Marc Sauton 2015-09-04 05:01:10 UTC
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)

Comment 6 Marc Sauton 2015-09-04 05:05:06 UTC
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.

Comment 7 Hal Deadman 2015-09-24 17:48:05 UTC
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.

Comment 8 Rich Megginson 2015-09-24 18:00:24 UTC
(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.

Comment 9 Hal Deadman 2015-09-24 20:33:49 UTC
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.

Comment 10 Rich Megginson 2015-09-24 20:42:47 UTC
(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?

Comment 11 Jan Pazdziora 2015-09-25 06:59:00 UTC
(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?

Comment 12 Hal Deadman 2015-09-25 15:10:59 UTC
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'],
        }
      }

Comment 13 Rich Megginson 2015-09-25 16:31:14 UTC
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?

Comment 14 Hal Deadman 2015-09-25 21:38:12 UTC
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.

Comment 15 Jan Pazdziora 2015-09-26 14:36:46 UTC
(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

Comment 16 Hal Deadman 2015-09-28 22:13:16 UTC
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.

Comment 17 Rich Megginson 2015-09-28 22:23:35 UTC
(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.

Comment 18 Hal Deadman 2015-09-30 13:26:35 UTC
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.

Comment 21 Noriko Hosoi 2015-10-08 01:18:00 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/48305

Comment 23 Rich Megginson 2015-12-02 15:49:00 UTC
The -f /dev/null test does not work.  Reopening.  https://bugzilla.redhat.com/show_bug.cgi?id=1287547 is a duplicate of this bug.

Comment 24 Rich Megginson 2015-12-02 15:49:44 UTC
*** Bug 1287547 has been marked as a duplicate of this bug. ***

Comment 25 Sankar Ramalingam 2016-03-28 14:32:21 UTC
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?

Comment 26 Noriko Hosoi 2016-03-28 17:06:50 UTC
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.

Comment 27 Sankar Ramalingam 2016-03-29 10:19:50 UTC
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'

Comment 29 errata-xmlrpc 2016-05-10 19:21:12 UTC
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


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