#49107 ldap-agent usage info is not displayed
Closed: wontfix 4 years ago by vashirov. Opened 7 years ago by vashirov.

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.


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:
{{{

ldap-agent

  • 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
  • exit 1
    }}}

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.

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

7 years ago

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

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

7 years ago

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.3.7 backlog (was: 1.3.6.0)

6 years ago

Metadata Update from @vashirov:
- Custom field reviewstatus adjusted to None
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

4 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

3 years ago

Login to comment on this ticket.

Metadata