[bug#52578] [PATCH] updating openldap and adding service definition

[Jean-Francois GUILLAUME <Jean-Francois.Guillaume@univ-nantes.fr>]

Hi,

> A single "--disable-static" should be suficient.

Indeed, copy-paste from our local repository went wrong.


> is this speculation on what's necessary for cross-compilation, or has 
> it been determined these flags are necessary?

These were necessary with the old autoconf in <= 2.5 realeases. It's 
mostly a leftover from the older definition already in guix.

> Why?

Stripping was sometime leading to crash of the build on my side.

> This is the default, no need to mention it.

True, leftover from when i needed the build to be monothread to see 
where it failed.


> You can use ,(cc-for-target) here. Also, CC can be set in #:make-flags.

Ok, i will look into it.


> That's a very terse description --- is it a server, a client 
> application, programming APIs for communicating with a server, or all 
> of these? Also, no need to mention it's free, everything in Guix is 
> free.

I'll be honest, it's a copy-paste from the already defined package. I'll 
update it to be more meaningfull.

> What's the reason for defining multiple versions of openldap? Usually, 
> it is only necessary to keep the latest version of a package (with some 
> rare exceptions).

This is mostly another case of copy-paste from our local repository went 
wrong.


> A copyright + license header is missing, and this file needs to be 
> added to Makefile.am (or local.mk, I'm not sure about the details).

Ok, i will look into it.


> This seems unlikely to compile, what's the space doing here?

Well, we use this in our local guix infrastructure and it doesn't 
complain, nor does our building of ldap server vms with guix system 
build.

> Something I'm missing here, is some documentation. As it is, this 
> openldap service isn't documented anywhere, so nobody would figure out 
> it even exists, unless they search in the source code.

True, forgot about this, my bad. Could you please point me to an example 
?

> As-is, this service would be run as root, which is very suboptimal from 
> a security perspective. Consider running it as a separate user & group, 
> and if feasible in a container (the latter is optional but would be 
> great).

True, i'll try to get it work with it's own user and group.

> I don't see the point in making this customisable. Why would anyone 
> want to change the log locations or location of the pid file? Unless 
> there's some compelling reason otherwise, I'd prefer to keep complexity 
> down by not making this configurable.

This allow us to run multiple instance of this service on the same 
machine (granted you also change the storage directory slapd.conf).

> Allowing writing the configuration with configuration records would be 
> preferred (with an 'extra-content'-style escape hatch, because it would 
> probably be infeasible to support every single configuration option of 
> openldap, but some basic options like ‘which network port to bind 
> to’ should be configurable in Scheme).

Well this is beyond my current abilities.

> This service probably requires a network interface, so loopback might 
> be required. Also, why is user-processes included? I know many services 
> include it, but it doesn't appear to be documented anywhere when 
> user-processes must be added to 'requirement'.

True. From my understanding, when you reach user-processes you're in the 
late stage of booting your system and everything network-wise should be 
available.

> These parentheses are lonely, consider moving the parenthese to right 
> after openldap-service-type, to keep the style consistent in Guix.

Leftovers from our local repo, we rely a bit to much on indentation to 
help us have a better view of where blocks start and stop.

> What do you mean with ‘does not work inside guix’?

For some strange reasons, when the tests are run by guix build they do 
not properly clean after each steps and ends up failing. If you do the 
same inside a guix environment test work properly. And i think some 
tests need some kinds of network connection but that could be on another 
package.

Sorry for the messy patch.

Best,
-- 
Cordialement,
Jean-François GUILLAUME
Plateforme Bioinformatique BiRD

Tél. : +33 (0)2 28 08 00 57
www.pf-bird.univ-nantes.fr

Inserm UMR 1087/CNRS UMR 6291
IRS-UN - 8 quai Moncousu - BP 70721
44007 Nantes Cedex 1