attachment
0001-Ticket-47691-lib389-support-for-RPM-builds-of-389-ds.patch

Is there some way we can do this without having to embed SUDO and SYSTEMCTL into our test suite?

For SUDO, can't we just require whoever runs the test suite to do
{{{
$ sudo py.test ....
}}}
or will that cause problems with everything being run as root, and every file being owned by root?

For SYSTEMCTL, note that we should try to support as many platforms as possible, which means many platforms which do not use SYSTEMCTL. AFAIK, all of the logic for using service or systemctl or etc. is embedded in the /usr/sbin/start-dirsrv, /usr/sbin/stop-dirsrv, etc. scripts.

Thanks for reviewing the fix. I think in both cases (SUDO, SYSTEMCTL) it is feasible to get them out of lib389.

Thanks to /usr/sbin/{start/stop}-dirsrv it would not be too complex to fix the systemctl

Running lib389 being root user, will create instances under 'nobody' user that would be fine (it could be extended to use an environment variable if needed).

So testing on 'prefix' install it would create instances for 'nobody' (if run with sudo) or <userid>. Without 'prefix' install (RPM) it would require root permission and create instance under 'nobody'.

Replying to [comment:4 tbordaz]:

Thanks for reviewing the fix. I think in both cases (SUDO, SYSTEMCTL) it is feasible to get them out of lib389.

Thanks to /usr/sbin/{start/stop}-dirsrv it would not be too complex to fix the systemctl

I think we will want to have tests for systemctl in our test suite, to test to make sure things like systemctl start dirsrv.target or systemctl start dirsrv@instance.service etc. works, but that should not be part of the core library.

Running lib389 being root user, will create instances under 'nobody' user that would be fine (it could be extended to use an environment variable if needed).

Yes, that's fine. We can easily add the ability to specify the user id later.

So testing on 'prefix' install it would create instances for 'nobody' (if run with sudo) or <userid>. Without 'prefix' install (RPM) it would require root permission and create instance under 'nobody'.

Right.

attachment
0001-Ticket-47691-using-lib389-with-RPMs.patch

attachment
0001-Ticket-47691-2-using-lib389-with-RPMs.patch

{{{
44 DEFAULT_USER = "nobody"
44 DEFAULT_USER = "dirsrv"
}}}
Where is the "dirsrv" user created? I know that IPA creates this user, but plain 389 does not afaik.

Hi Rich,

Thanks for reviewing it again.

That is correct, I do not create the user 'dirsrv'.

There was a problem of grabbing the lock file (under /var/lock/dirsrv/).
On my deployement the lock directory belongs to 'dirsrv' and 'nobody' got a permission denied to create its lock.

When I changed the userId from 'nobody' to 'dirsrv' I was then able to start the instance.

thanks
thierry

Then either the test needs to create the "dirsrv" user, or it needs to work with "nobody" and "dirsrv"

attachment
0001-Ticket-47691-3-using-lib389-with-RPMs.patch

Thanks Rich for the reviews

Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 2.22 KiB, done.
Total 6 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/lib389.git/
c05ac0f..e1a132c master -> master

commit e1a132c6ce5271e89c36d1105665e7bf5ce03b8b
Author: Thierry bordaz (tbordaz) tbordaz@redhat.com
Date: Wed Nov 26 12:31:28 2014 +0100

Milestone lib389 1.0 deleted

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/1027

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.