Description of problem: I'm trying to create an instance under non-root user. When bin_dir contains a trailing slash, dscreate fails to find it in $PATH. Version-Release number of selected component (if applicable): 389-ds-base-2.2.4-1.module+el9dsrv+17401+48b1309a.x86_64 How reproducible: always Steps to Reproduce: $ mkdir -p bin $ dscreate ds-root $HOME/test $HOME/bin/ Actual results: $ dscreate ds-root $HOME/test $HOME/bin/ bin_dir argument should be before /usr/sbin in PATH $ echo $? 1 If I remove the trailing slash, it succeeds: $ dscreate ds-root $HOME/test $HOME/bin $ echo $? 0 Expected results: dscreate should normalize paths Additional info:
I agree: We should use os.path.samefile to compare the paths
Not only that, but we should actually normalize the paths (os.path.normpath). User input can't be trusted. Right now dscreate gladly takes this: $ dscreate -v ds-root $HOME/test/// $HOME/bin DEBUG: The 389 Directory Server Creation Tool DEBUG: Inspired by works of: ITS, The University of Adelaide DEBUG: Called with: Namespace(verbose=True, json=False, root_dir='/home/user/test///', bin_dir='/home/user/bin', func=<function prepare_ds_root at 0x7f03b769faf0>) DEBUG: Creating /home/user/bin/dsconf wrapper DEBUG: Creating /home/user/bin/dscreate wrapper DEBUG: Creating /home/user/bin/dsctl wrapper DEBUG: Creating /home/user/bin/dsidm wrapper DEBUG: Copying /usr/share/dirsrv/ into /home/user/test////share/dirsrv/ DEBUG: Copying /etc/dirsrv/config into /home/user/test/////etc/dirsrv/config DEBUG: Copying /etc/dirsrv/schema into /home/user/test/////etc/dirsrv/schema DEBUG: Creating directory /home/user/test/////tmp DEBUG: Copying /usr/sbin/ns-slapd into /home/user/test////sbin/ns-slapd DEBUG: Update /home/user/test////share/dirsrv/data/template-dse-minimal.ldif from /usr/share/dirsrv/data/template-dse-minimal.ldif DEBUG: Update /home/user/test////share/dirsrv/data/template-dse.ldif from /usr/share/dirsrv/data/template-dse.ldif DEBUG: Update /home/user/test////share/dirsrv/inf/defaults.inf from /usr/share/dirsrv/inf/defaults.inf Or this: $ dscreate -v ds-root test $HOME/bin DEBUG: The 389 Directory Server Creation Tool DEBUG: Inspired by works of: ITS, The University of Adelaide DEBUG: Called with: Namespace(verbose=True, json=False, root_dir='test', bin_dir='/home/user/bin', func=<function prepare_ds_root at 0x7f48dc5eaaf0>) DEBUG: Creating /home/user/bin/dsconf wrapper DEBUG: Creating /home/user/bin/dscreate wrapper DEBUG: Creating /home/user/bin/dsctl wrapper DEBUG: Creating /home/user/bin/dsidm wrapper DEBUG: Copying /usr/share/dirsrv/ into test/share/dirsrv/ DEBUG: Copying /etc/dirsrv/config into test//etc/dirsrv/config DEBUG: Copying /etc/dirsrv/schema into test//etc/dirsrv/schema DEBUG: Creating directory test//tmp DEBUG: Copying /usr/sbin/ns-slapd into test/sbin/ns-slapd DEBUG: Update test/share/dirsrv/data/template-dse-minimal.ldif from /usr/share/dirsrv/data/template-dse-minimal.ldif DEBUG: Update test/share/dirsrv/data/template-dse.ldif from /usr/share/dirsrv/data/template-dse.ldif DEBUG: Update test/share/dirsrv/inf/defaults.inf from /usr/share/dirsrv/inf/defaults.inf And then fails with dscreate, because socket path is $ grep socket test/share/dirsrv/inf/defaults.inf ldapi = test/run/slapd-{instance_name}.socket So we should check if it's an absolute path too.
Build tested: 389-ds-base-2.3.5-1.module+el9dsrv+19320+04706864.x86_64 Last test case (relative path instead of absolute) fails: $ dscreate ds-root test $HOME/bin $ grep socket test/share/dirsrv/inf/defaults.inf ldapi = test/run/slapd-{instance_name}.socket It writes relative paths to defaults.inf. Moving to ASSIGNED.
For the remaining problem I opened https://bugzilla.redhat.com/show_bug.cgi?id=2233176 Marking this one as VERIFIED.
RN text passed all reviews
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 (redhat-ds:12 bug fix and enhancement update), 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://access.redhat.com/errata/RHEA-2023:7429