#47691 lib389 support for RPM builds of 389-ds
Closed: Fixed None Opened 5 years ago by mkubik.

At the moment, the framework runs only with directory server built from source code and installed under user specified path. Every file of directory server is owned by the user who installed it.

In a case of RPM package, root privileges are required to write some files/directories. This is the reason why the lib389 isn't able to run with RPM installed 389-ds at the moment.

In QE we must be able to be able to run the tests on RPM builds.

During my experiments with lib389 I was able to create an instance by adding sudo to the call to setup-ds.pl. However, the test crashed little bit later on other problem with access rights.

What I think we need is to identify all the places in code where some call needs root access to some resource and fix those.
I also think it would be useful to have some kind of a switch/config option for this so 'sudo' is only invoked when needed (not needed when built from source).


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.

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

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

Metadata Update from @tbordaz:
- Issue assigned to tbordaz

2 years ago

Login to comment on this ticket.

Metadata