ldap-agent is a wrapper around ldap-agent-bin, which is not directly executed by the user. But only the latter has usage info. When ldap-agent is executed directly, it returns non-zero exit code.
ldap-agent
ldap-agent-bin
Hi Viktor,
It behaves as follows for me. Is it different from what you observed? {{{ $ ldap-agent Usage: ldap-agent [-D] configfile -D Enable debug logging $ echo $? 1 $ ldap-agent --help ldap-agent: illegal option - Usage: ldap-agent [-D] configfile -D Enable debug logging $ echo $? 1 $ ldap-agent -h ldap-agent: illegal option h Usage: ldap-agent [-D] configfile -D Enable debug logging $ echo $? 1 }}}
Note: man ldap-agent shows the expected man page.
It seems that the problem is only on RHEL7 and Fedora: {{{
Same script, but named /usr/sbin/ldap-agent-test shows info: {{{ + BIN_DIR=/usr/sbin + COMMAND=ldap-agent-bin + MIBS= + export MIBS + libpath_add /usr/lib64 + '[' -z /usr/lib64 ']' + LD_LIBRARY_PATH=/usr/lib64 + libpath_add '' + '[' -z '' ']' + return + libpath_add '' + '[' -z '' ']' + return + libpath_add '' + '[' -z '' ']' + return + export LD_LIBRARY_PATH + PATH=/usr/sbin + export PATH + ORIGINAL_IFS=' ' + IFS=: + for dir in '${PATH}' + '[' -x /usr/sbin/ldap-agent-bin ']' + IFS=' ' + /usr/sbin/ldap-agent-bin Usage: ldap-agent [-D] configfile -D Enable debug logging + exit 1 }}} So I guess ldap-agent-bin checks if ldap-agent is already running and exits 1 if process is found.
/usr/sbin/ldap-agent-test
So I guess ldap-agent-bin checks if ldap-agent is already running and exits 1 if process is found.
Makes sense. Thanks for the clarification!
Metadata Update from @vashirov: - Issue set to the milestone: 1.3.6.0
My initial guess was wrong, there is an issue with selinux:
time->Thu Mar 2 21:07:54 2017 type=SYSCALL msg=audit(1488485274.419:331): arch=c000003e syscall=59 success=yes exit=0 a0=21e77c0 a1=21e69c0 a2=21e4590 a3=7ffecc977090 items=0 ppid=22451 pid=22452 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="ldap-agent-bin" exe="/usr/sbin/ldap-agent-bin" subj=unconfined_u:system_r:dirsrv_snmp_t:s0 key=(null) type=AVC msg=audit(1488485274.419:331): avc: denied { read append } for pid=22452 comm="ldap-agent-bin" path="/dev/pts/2" dev="devpts" ino=5 scontext=unconfined_u:system_r:dirsrv_snmp_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file type=AVC msg=audit(1488485274.419:331): avc: denied { read append } for pid=22452 comm="ldap-agent-bin" path="/dev/pts/2" dev="devpts" ino=5 scontext=unconfined_u:system_r:dirsrv_snmp_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file type=AVC msg=audit(1488485274.419:331): avc: denied { read append } for pid=22452 comm="ldap-agent-bin" path="/dev/pts/2" dev="devpts" ino=5 scontext=unconfined_u:system_r:dirsrv_snmp_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file type=AVC msg=audit(1488485274.419:331): avc: denied { read write } for pid=22452 comm="ldap-agent-bin" path="/dev/pts/2" dev="devpts" ino=5 scontext=unconfined_u:system_r:dirsrv_snmp_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file
This denial is not logged by default unless dontaudit statements are disabled
dontaudit
semodule --disable_dontaudit --build
In permissive mode ldap-agent shows usage info. I'll file a bug for selinux-policy.
Metadata Update from @vashirov: - Issue close_status updated to: None
https://bugzilla.redhat.com/show_bug.cgi?id=1428568
Metadata Update from @mreynolds: - Issue set to the milestone: 1.3.7 backlog (was: 1.3.6.0)
Metadata Update from @vashirov: - Custom field reviewstatus adjusted to None - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2166
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.