#48983 ds: generate install path info from autotools scripts
Closed: wontfix None Opened 4 years ago by firstyear.

The only time that we "know" all the paths for an install of ds is an ./configure time. However, other tools need to be able to read and act on these paths be it due to a prefix, a different platform, or even custom arguments to configure.

During configure we should create a "defaults.inf" which contains a set of default paths able to be parser by other tools. This MUST be exported to a well known location. I propose that the locations where this could be exported to are:

/usr/share/dirsrv/inf/defaults.inf
/usr/local/share/dirsrv/inf/defaults.inf
/opt/dirsrv/share/dirsrv/inf/defaults.inf
/opt/local/share/dirsrv/inf/defaults.inf
/opt/share/dirsrv/inf/defaults.inf

They should be searched in this order by the consuming tools. Without this, we need to resort to some pretty nasty hacks or assumptions by programs trying to interact with DS.


Hi William,

The idea/patch looks great but something is not clear to me. The values in defaults.inf are not really looking as default values but as actual values DS will run with but it already exists some files storing some of those values (in /etc/sysconfig/dirsrv, ~/.dirsrv/dirsrv- and dse.ldif) what will be their relation with default.inf.
So far some of the instance config value (logs, dbdir..) were accessed by lib389 only when the instance was running, allowing remote access. Do we need for lib389 access to those info when the instance is down ?
So why not using dse.ldif ?

thanks
thierry

Okay, so here is the reason why I felt this was needed.

First, we have a machine, freshly installed. We have no instances of ds. The machine could be RHEL, it could be a build from git master prefix to /opt/dirsrv, it could even be freebsd which uses /usr/local.

With the new lib389 installer we need to find where our instance configurations are. In the above it could be:

  • /etc/dirsrv
  • /opt/dirsrv/etc/dirsrv
  • /usr/local/etc/dirsrv

So, by having the defaults.inf file, we can scan those "well known" locations, and from it read the location. In this case, we'll go with RHEL, so we know instances are in /etc/dirsrv

Now we use the lib389 tools to install an instance. We need to know where all the files need to go. lib389 doesn't know all the paths, and they can be changed at ./configure time in ds during the rpm build process. So again, we can read from the defaults.inf and do substitutions to {instance_name} to create the "template" of where files should go in an install.

If we go back to our tools, we are administering the server. Say we want to list backups taken by db2bak. Well, lib389 will start up, parse the defaults.inf to find the etc path, then from there we can parse dse.ldif to find that instances backup directory.

Imagine how this process would work on a git master build with say /opt/dirsrv now. We can't assume that the instance configuration is in /etc. This way you can have the tools "just work" to find the install ds files, and instances will be installed to the correct /opt/dirsrv locations now.

So this file is to bootstrap installations and allow discovery of the instance configuration directory.

As well with the installations an issue I was hitting was that when you install from the rpm, the python environment prefix is set to /, when I install from git master, it's set to /opt/dirsrv. This was the only way to find the $PREFIX/etc/dirsrv folder. But, during the install, it would break, because from rpm the prefix is actually /usr, it's that ./configure with fhs overrides the etc dir. This means that the data_dir is in /usr/share, whereas on a git master build it's in /opt/dirsrv/share.

So either I could have lib389 work with the git master build (/opt/dirsrv/etc/dirsrv and /opt/dirsrv/share) and break on rpm (//etc/dirsrv and //share) OR I could have it break git master (/opt/dirsrv/etc/dirsrv and /opt/dirsrv/usr/share) and work on rpm (//etc/dirsrv and //usr/share).

Instead of hacking around the problem, because lib389 is full of filesystem path hacks, I decided to just clean it up. Lets define all our paths at ./configure time (when we know them all), and make it possible for lib389 to consume them on all platforms and configurations.

To summarise, the goal in lib389 will be:

  • Read the defaults.inf
  • If we are installing an instance, use it as the base paths for the install
  • If the instance exists, use this to find /etc/dirsrv/slapd-instance/dse.ldif, then parse that.

See #48984

I hope that helps explain where this is going.

You get my ack, but let's wait for Thierry.

Hi William,

Thanks for your detailed explanations. This brings simplification and helps lib389 to be the main tool for administration. You get a big ack also from me.

thanks

William, are you planning to check in the auto-generated files, too? Thanks!

Yes, I'll add the autogenerated files also. With this change, and #48984 it affects many tests, so there is an update to fix lots of the dirsrvtests here. I will add the autotools files in that commit perhaps.

Probably okay to just commit / push these changes, but will wait for ack anyway.

commit 2d48aab
commit bb3937a
Compressing objects: 100% (11/11), done.
Writing objects: 100% (12/12), 2.31 KiB | 0 bytes/s, done.
Total 12 (delta 9), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
def469a..bb3937a master -> master

Reopening for backport to 1.2.11 and 1.3.5 branches

commit 9669464
commit 52605fd
commit 8f6cce1
Compressing objects: 100% (16/16), done.
Writing objects: 100% (18/18), 3.08 KiB | 0 bytes/s, done.
Total 18 (delta 13), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
21f1b61..9669464 389-ds-base-1.3.5 -> 389-ds-base-1.3.5

commit 9034668
Compressing objects: 100% (7/7), done.
Writing objects: 100% (8/8), 1.70 KiB | 0 bytes/s, done.
Total 8 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
40d0054..9034668 389-ds-base-1.2.11 -> 389-ds-base-1.2.11

Metadata Update from @nhosoi:
- Issue assigned to firstyear
- Issue set to the milestone: 1.2.11.33

3 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/2042

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)

2 months ago

Login to comment on this ticket.

Metadata