On Fri, Jul 15, 2011 at 7:37 PM, Dan McGee wrote:

On Fri, Jul 8, 2011 at 1:52 PM, Eric Bélanger wrote:

...

Hi,

I was looking into updating the orphaned libldap and openldap packages and couldn't help to notice that they should be in a splitted PKGBUILD instead of two seperate PKGBUILD.  It will remove duplicate work and probably make the PKGBUILD cleaner especially the build function which currently cd to subdirectories to only build what is needed for its specific package.  As openldap only depends on core packages, I don't see why it couldn't go in core.

Can you change --enable-wrappers to --disable-wrappers and remove the tcp_wrappers dependency when you pick this up again?

-Dan

Sure. I just did it in my WIP PKGBUILD to not forget. As no-one seems to know about the db moving part, I'm leaning into keeping --localstatedir=/var/lib/openldap. I'll wait for a day or two in case someone wants to pipe in, unless you want me to go forward to get the new openladp package done for the tcp_wrappers removal.

On Fri, Jul 15, 2011 at 8:55 PM, Dan McGee wrote:

On Fri, Jul 15, 2011 at 7:48 PM, Eric Bélanger wrote:

...

On Fri, Jul 15, 2011 at 7:37 PM, Dan McGee wrote:

...

On Fri, Jul 8, 2011 at 1:52 PM, Eric Bélanger wrote:

...

Hi,

I was looking into updating the orphaned libldap and openldap packages and couldn't help to notice that they should be in a splitted PKGBUILD instead of two seperate PKGBUILD.  It will remove duplicate work and probably make the PKGBUILD cleaner especially the build function which currently cd to subdirectories to only build what is needed for its specific package.  As openldap only depends on core packages, I don't see why it couldn't go in core.

Can you change --enable-wrappers to --disable-wrappers and remove the tcp_wrappers dependency when you pick this up again?

-Dan

Sure. I just did it in my WIP PKGBUILD to not forget. Thanks!

...

As no-one seems to know about the db moving part, I'm leaning into keeping  --localstatedir=/var/lib/openldap. I'll wait for a day or two in case someone wants to pipe in, unless you want me to go forward to get the new openladp package done for the tcp_wrappers removal. No huge rush to get a rebuilt version in.

As far as the database bit goes, could you have post_upgrade (but only upgrade, not install) install a symlink from the new to old data location if the new location doesn't contain any data, and print a message saying you should move your data directory for real? Of course you can't have the package contain an empty data directory this way.

A DB_CONFIG.example file gets installed in the db directory so symlinking the directories won't work. We could simply use a post-upgrade function to check if there is a db in the old location and, if so, print a message saying to stop the daemon and move their db. If we also post a frontpage news, they should be aware of the change, I guess. Eric

-Dan

On Sat, Jul 16, 2011 at 4:09 AM, Jan de Groot wrote:

On Fri, 2011-07-15 at 20:48 -0400, Eric Bélanger wrote:

...

Sure. I just did it in my WIP PKGBUILD to not forget.

As no-one seems to know about the db moving part, I'm leaning into keeping  --localstatedir=/var/lib/openldap. I'll wait for a day or two in case someone wants to pipe in, unless you want me to go forward to get the new openladp package done for the tcp_wrappers removal.

What db-moving part exactly? Doesn't the current package install the database in /var/lib/openldap, and isn't that the logical place for it?

The current package use the --localstatedir=/var/lib/openldap configure option. That does 2 things: - it creates a /var/lib/openldap/openldap-data/ directory where the db is stored - it creates a /var/lib/openldap/run/ directory where the unix ldapi socket will be located Although this is a reasonnable location for the db, you said in a comment on FS#21051 that /var/lib/openldap/run/ is a weird location and that /var/run would be better. If we want to change the location of the ldapi socket to /var/run, we'll need to use --localstatedir=/var as configure option. However, this will also change the expected location of the db to /var/openldap-data/ hence the db moving business. I guess it all boils down wether the weirdness of having the socket /var/lib/openldap/run/ is important enough to worth the hassle of the db moving. Eric

On Sat, Jul 16, 2011 at 6:03 AM, Tom Gundersen wrote:

On Sat, Jul 16, 2011 at 11:40 AM, Eric Bélanger wrote:

...

On Sat, Jul 16, 2011 at 4:09 AM, Jan de Groot wrote:

...

On Fri, 2011-07-15 at 20:48 -0400, Eric Bélanger wrote:

...

Sure. I just did it in my WIP PKGBUILD to not forget.

As no-one seems to know about the db moving part, I'm leaning into keeping  --localstatedir=/var/lib/openldap. I'll wait for a day or two in case someone wants to pipe in, unless you want me to go forward to get the new openladp package done for the tcp_wrappers removal.

What db-moving part exactly? Doesn't the current package install the database in /var/lib/openldap, and isn't that the logical place for it?

The current package use the --localstatedir=/var/lib/openldap configure option. That does 2 things: - it creates a /var/lib/openldap/openldap-data/ directory where the db is stored - it creates a /var/lib/openldap/run/ directory where the unix ldapi socket will be located

Although this is a reasonnable location for the db, you said in a comment on FS#21051 that /var/lib/openldap/run/ is a weird location and that /var/run would be better. If we want to change the location of the ldapi socket to /var/run, we'll need to use --localstatedir=/var as configure option. However, this will also change the expected location of the db to /var/openldap-data/ hence the db moving business.

I guess it all boils down wether the weirdness of having the socket /var/lib/openldap/run/ is important enough to worth the hassle of the db moving.

My two cents:

It is indeed weird to have /var/lib/openldap/run, but I think it would be weirder to have a /var/openldap-data (as far as I know packages shouldn't really put stuff directly under var).

FTR, /var/openldap-data would be a directory so the stuff won't be directly in /var, e.g.: $ sudo ls /var/lib/openldap/openldap-data/ alock __db.001 __db.002 __db.003 DB_CONFIG.example dn2id.bdb id2entry.bdb log.0000000001 Only DB_CONFIG.example was installed by pacman. The rest is what needs to be moved and what I've been referring to as the db in this thread. There might be more files on systems which actually use openldap. I only started/stopped the daemon with default config.

I suggest keeping this as it is, unless there is a way to only move the run dir. In which case it should be moved to /run (rather than /var/run).

We can't move the run dir without moving the db. Having /run as run dir would imply having the db in /openldap-data which is wierd.

About libexec:

libexecdir is usually meant to contain programs that should only be run by other programs, and not by the user. So in principle it is wrong to symlink from /usr/sbin to /usr/lib/. Maybe this is an upstream bug?

They install a bunch of symlinks in /usr/sbin which call the slapd binary in the libexecdir. Here's the $pkgdir for the new package: $ ls -l pkg/openldap/usr/sbin/ total 0 lrwxrwxrwx 1 eric users 12 Jul 10 05:46 slapacl -> ../lib/slapd lrwxrwxrwx 1 eric users 12 Jul 10 05:46 slapadd -> ../lib/slapd lrwxrwxrwx 1 eric users 12 Jul 10 05:46 slapauth -> ../lib/slapd lrwxrwxrwx 1 eric users 12 Jul 10 05:46 slapcat -> ../lib/slapd lrwxrwxrwx 1 eric users 12 Jul 10 05:47 slapd -> ../lib/slapd lrwxrwxrwx 1 eric users 12 Jul 10 05:46 slapdn -> ../lib/slapd lrwxrwxrwx 1 eric users 12 Jul 10 05:46 slapindex -> ../lib/slapd lrwxrwxrwx 1 eric users 12 Jul 10 05:46 slappasswd -> ../lib/slapd lrwxrwxrwx 1 eric users 12 Jul 10 05:46 slapschema -> ../lib/slapd lrwxrwxrwx 1 eric users 12 Jul 10 05:46 slaptest -> ../lib/slapd The only symlink I added was the slapd one. The rest were installed automatically, so I assume it's intended by upstream. I don't know why they do it this way. Maybe it's done so slapd can find the modules which gets installed in $libexecdir/openldap/

-t

On Sun, Jul 17, 2011 at 12:27 AM, Jan de Groot wrote:

On Sat, 2011-07-16 at 05:40 -0400, Eric Bélanger wrote:

...

On Sat, Jul 16, 2011 at 4:09 AM, Jan de Groot wrote:

...

On Fri, 2011-07-15 at 20:48 -0400, Eric Bélanger wrote:

...

Sure. I just did it in my WIP PKGBUILD to not forget.

As no-one seems to know about the db moving part, I'm leaning into keeping  --localstatedir=/var/lib/openldap. I'll wait for a day or two in case someone wants to pipe in, unless you want me to go forward to get the new openladp package done for the tcp_wrappers removal.

What db-moving part exactly? Doesn't the current package install the database in /var/lib/openldap, and isn't that the logical place for it?

The current package use the --localstatedir=/var/lib/openldap configure option. That does 2 things: - it creates a /var/lib/openldap/openldap-data/ directory where the db is stored - it creates a /var/lib/openldap/run/ directory where the unix ldapi socket will be located

Although this is a reasonnable location for the db, you said in a comment on FS#21051 that /var/lib/openldap/run/ is a weird location and that /var/run would be better. If we want to change the location of the ldapi socket to /var/run, we'll need to use --localstatedir=/var as configure option. However, this will also change the expected location of the db to /var/openldap-data/ hence the db moving business.

I guess it all boils down wether the weirdness of having the socket /var/lib/openldap/run/ is important enough to worth the hassle of the db moving.

What about patching?

http://patch-tracker.debian.org/patch/series/view/openldap/2.4.25-1.1/wrong-...

We're not the only one facing this problem.

Coincidentally, I ran into the Debian patches tonight and was about to mention it here. We could patch to keep the db in the current location and have the socket in /run. Patching would be trivial and low-maintenance. That's probably the best solution unless someone objects. Debian also have a patch to have an errors log file in /var/log instead of /var, I'll apply it regardless. Eric

On Sun, Jul 17, 2011 at 04:43:25AM -0400, Eric Bélanger wrote:

Coincidentally, I ran into the Debian patches tonight and was about to mention it here.

We could patch to keep the db in the current location and have the socket in /run. Patching would be trivial and low-maintenance. That's probably the best solution unless someone objects. Debian also have a patch to have an errors log file in /var/log instead of /var, I'll apply it regardless.

Eric

Makes sense to me. +1. dave