[arch-dev-public] Moving openldap to core repo
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. Any objections? Eric
On Fri, Jul 8, 2011 at 2:52 PM, Eric Bélanger <snowmaniscool@gmail.com> 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.
Any objections? Eric
As noone objected , I started work on a splitted PKGBUILD. I also looked at two ldap bugs: FS#14598 - [openldap] enable slapd overlays (slapo) FS#21051 - [libldap] ldapi path never created by install For FS#14598, I'll enable them as they just add libraries (plugins?) to the package. It also adds libtool files which I'll keep as I have a hunch they are needed like it's the case with the imagemagick modules. That is unless someone tell me they are not needed as I don't use that stuff. I'll also change the libexecdir from /usr/sbin to /usr/lib as it seems strange to have a /usr/sbin/openldap/ directory with libraries. With that change however, the slapd binary gets installed in /usr/lib/ but I'll put a symlink in /usr/bin so everything will work fine. As for FS#21051, the current package use --localstatedir=/var/lib/openldap instead of the more usual --localstatedir=/var so we get weird directories like /var/lib/openldap/run. Changing this is easy, but the openldap daemon use ${localstatedir}/openldap-data to store its database. This means that we'll want a post-install message or front page news (or both?) to inform users to move their openldap db to the new location. The problem here is that I'm not familiar with openldap or databases so I don't know what these upgrade instructions should be. The only thing that comes to my mind is the simple stop the daemon then move the db manually with mv (maybe chmod/chown will be needed to keep the perms/ownership) method. Would that work? Is there a better way like an openldap tool or option to accomplish that in a more fool-proof manner? I would rather keep the current location how irregular it is than risk breaking something. I could post my current PKGBUILD and even packages if anyone is interested into looking into this matter. Eric
On Fri, Jul 8, 2011 at 1:52 PM, Eric Bélanger <snowmaniscool@gmail.com> 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
On Fri, Jul 15, 2011 at 7:37 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Fri, Jul 8, 2011 at 1:52 PM, Eric Bélanger <snowmaniscool@gmail.com> 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 7:48 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Fri, Jul 15, 2011 at 7:37 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Fri, Jul 8, 2011 at 1:52 PM, Eric Bélanger <snowmaniscool@gmail.com> 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. -Dan
On Fri, Jul 15, 2011 at 8:55 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Fri, Jul 15, 2011 at 7:48 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Fri, Jul 15, 2011 at 7:37 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Fri, Jul 8, 2011 at 1:52 PM, Eric Bélanger <snowmaniscool@gmail.com> 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 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?
On Sat, Jul 16, 2011 at 4:09 AM, Jan de Groot <jan@jgc.homeip.net> 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 11:40 AM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Sat, Jul 16, 2011 at 4:09 AM, Jan de Groot <jan@jgc.homeip.net> 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). 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). 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? -t
On Sat, Jul 16, 2011 at 6:03 AM, Tom Gundersen <teg@jklm.no> wrote:
On Sat, Jul 16, 2011 at 11:40 AM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Sat, Jul 16, 2011 at 4:09 AM, Jan de Groot <jan@jgc.homeip.net> 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 Sat, 2011-07-16 at 05:40 -0400, Eric Bélanger wrote:
On Sat, Jul 16, 2011 at 4:09 AM, Jan de Groot <jan@jgc.homeip.net> 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.
On Sun, Jul 17, 2011 at 12:27 AM, Jan de Groot <jan@jgc.homeip.net> 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 <jan@jgc.homeip.net> 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 10:43 AM, Eric Bélanger <snowmaniscool@gmail.com> 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.
+1 -t
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
participants (5)
-
Dan McGee
-
Dave Reisner
-
Eric Bélanger
-
Jan de Groot
-
Tom Gundersen