Hide Forgot
Description of problem: /sbin/audispd-zos-remote depends on files in /usr but /usr needs not to be available (mounted) when /sbin binaries are used. From FHS (http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES) "/sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin." There are several options: 1) If audispd-zos-remote is not essential, it should be moved to /usr/sbin 2) If audispd-zos-remote has to stay in /sbin, then it must be able to run without /usr mounted, i.e. the dependencies have to be moved from /usr/lib* to /lib*, or linked statically. 3) If neither of the above is possible (desirable), the exception has to be justified and documented fo further reference (so far I haven't found any relevant docs). Version-Release number of selected component (if applicable): audispd-plugins-2.0.4-1.el6 How reproducible: always Steps to Reproduce: 1. run the test /CoreOS/libtirpc/Sanity/bz558937-sbin-dependencies-in-usr Actual results: :: [ FAIL ] :: File /sbin/audispd-zos-remote (from audispd-plugins-2.0.4-1.el6.x86_64) depends on /usr :: [ INFO ] :: The affected dependencies: :: [ INFO ] :: - /usr/lib64/libldap-2.4.so.2 (from openldap-2.4.19-15.el6_0.2.x86_64) :: [ INFO ] :: - /usr/lib64/liblber-2.4.so.2 (from openldap-2.4.19-15.el6_0.2.x86_64) :: [ INFO ] :: - /usr/lib64/libsasl2.so.2 (from cyrus-sasl-lib-2.1.23-8.el6.x86_64) :: [ INFO ] :: - /usr/lib64/libssl.so.10 (from openssl-1.0.0-10.el6.x86_64) :: [ INFO ] :: - /usr/lib64/libcrypto.so.10 (from openssl-1.0.0-10.el6.x86_64) Expected results: (no such failures) Additional info:
I don't think this is too big of a problem. If the plugin fails to load, audispd will attempt to restart it next time it has an event to distribute. But moving it to /usr/sbin would be a problem because it will think the plugin does not exist and remove it from the configuration.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
(In reply to comment #2) > I don't think this is too big of a problem. If the plugin fails to load, > audispd will attempt to restart it next time it has an event to distribute. now the question is if z/OS SMF users need audit while /usr is unavailable ... > But moving it to /usr/sbin would be a problem because it will think the plugin > does not exist and remove it from the configuration. reading the man page, it says that a configfile under /etc/audisp/plugins.d should specify full path to the plugin, so adding /usr prefix there wouldn't help?
Any plugin to audispd will be restarted when its needed and its dead. So, although there are links to /usr, audispd works around this problem.
Why does auditspd reload plugins after one type of error and not after another? If it would reload the plugin in all cases, there would be no need to workaround it by breaking filesystem hierarchy standard.
Because the one type of error means the program doesn't exist and the other means the child program quit.
And why is "doesn't exist" considered unrecoverable while "doesn't start" is not? I'm still looking for some justification for breaking FSH...
Since RHEL 6.2 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
*** Bug 754109 has been marked as a duplicate of this bug. ***
Did we want to use this bug as a tracker for moving the libraries? Or did you just want to document this per solution #3 in the problem description?
Since RHEL 6.3 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
Ondřej, just a question to your bug #754109 - does the sharedlib test still fail? if there's no interest in fixing this, I guess we could move on and ask for exception
*** Bug 905394 has been marked as a duplicate of this bug. ***
(In reply to Karel Volný from comment #13) > Ondřej, just a question to your bug #754109 - does the sharedlib test still > fail? > > if there's no interest in fixing this, I guess we could move on and ask for > exception Sorry for a delayed answer. bug #754109 was fixed, an exception for audispd-zos-remote was added and sharedlib test is not failing anymore.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
Closing since an exception was added.