sync'ing fails for modrdn
by Steffen Kaiser
Hello,
I have configured a central OpenLDAP, using Debian Etch, version: slapd
2.3.30-5+etch1, which is also a sync provider.
Another Debian Etch box uses the sync:
syncrepl rid=123
provider=ldap://example.com
type=refreshAndPersist
retry="5,2,30,2,60,+"
interval=00:01:00:00
searchbase="basedn"
filter="(objectClass=*)"
scope=sub
attrs="*,+"
sizelimit=0
timelimit=0
schemachecking=on
bindmethod=simple
binddn="someDN"
credentials="somePwd"
starttls=critical
This works fine, but moddn fails:
for testing purpose I ldapadd :
dn: c=testtt,ou=basedn
c: testtt
objectClass: country
then:
ldapmodrdn -r 'c=testtt,ou=basedn' 'c=testww'
It works on the sync provider (schemacheck on)
and the result is:
dn: c=testww,ou=basedn
objectClass: country
c: testww
But on the sync consumer:
: syncrepl_entry: c=testww,ou=basedn
: Entry (c=testww,ou=basedn attribute 'c' cannot have multiple values
: entry failed schema check: attribute 'c' cannot have multiple values
: null_callback : error code 0x13
: syncrepl_entry: be_modrdn (19)
The testtt entry is still present on the secondary box.
If I delete "testww" on the sync provider, the "testt" entry in the
consumere is deleted.
====
Because I trust the sync provider I changed
schemachecking=off
of the syncrepl rid=123 entry
Now I get this in the log:
: syncrepl_entry: c=testww,ou=basedn
: syncrepl_entry: be_modrdn (0)
: syncrepl_entry: be_modify (0)
For me it looks like that because of the sequence of the two operations,
schema checking is not compatible with moddn and this should be noted
in the man page.
Bye,
--
Steffen Kaiser
14 years, 3 months
RE: (ITS#5832) Networking and Replication.
by quanah＠zimbra.com
--On November 27, 2008 2:08:06 PM +0000 Nils.Hammar(a)cybercomgroup.com wrote:
> ------=_NextPart_000_0029_01C950A1.DC1D8A50
> Content-Type: text/plain;
> charset="us-ascii"
> Content-Transfer-Encoding: 7bit
>
> Further investigation into this issue seems to indicate that the problem
> is more related to the Berkeley DB 4.7.25 database than it is related to
> OpenLDAP itself.
>
> Sorry for causing trouble on this issue, I'll stick to 4.6 for the moment.
That makes no sense to me, BDB isn't communicating at the network level...
Everything at that level is LDAP protocol.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 3 months
Re: (ITS#5831) Replication unreliable
by quanah＠zimbra.com
--On November 27, 2008 11:08:43 AM +0000 nils.hammar(a)cybercomgroup.com
wrote:
> Right now I'm using BDB 4.6.21, since I wasn't able at all to make BDB
> 4.7.25 (with patch) to work. Not even "make test" succeded with the first
> test, it just hung. (which is another problem, probably not related to
> this problem)
Did you also patch BDB 4.7 with the patch included in the OpenLDAP/build
directory distributed with the source? It's necessary on some servers. It
would be nice if Oracle would release it.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 3 months
RE: (ITS#5832) Networking and Replication.
by Nils.Hammar＠cybercomgroup.com
------=_NextPart_000_0029_01C950A1.DC1D8A50
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Further investigation into this issue seems to indicate that the problem is
more related to the Berkeley DB 4.7.25 database than it is related to
OpenLDAP itself.
Sorry for causing trouble on this issue, I'll stick to 4.6 for the moment.
------=_NextPart_000_0029_01C950A1.DC1D8A50
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL+jCCAj0w
ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH
mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF
4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d
6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix
3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR
cZQwggTMMIIENaADAgECAhAcrp1rmvTmLyKKo9p0YWweMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNTEwMjgwMDAwMDBaFw0xNTEwMjcy
MzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT
FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0
ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g
RzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ36zn6vj4AxTEAJLVwX42wjzvfHIV
y8CrjD0clc5vHhAsPwDtlybmtsfmrUMdP6SHR0dMPlT4bPjH/LGevTBwvJexAwXqlfGtQMVEeksF
ovJg/Nc6ZWLv/xB7ola7xU5wLdaiHzztsELoXo1XIaymmdkR6dIaB8B0R0IL/MU06v3muiTRHQgV
N6LXc88BQS9jsjo/vqUabvTJSls9laYVuzUCGfnU77yPDnF2WbtLtj7W/FoW9NYOifJJ/mwM7RXp
2Yh1nHnOYCfdua11zi9zlXpAOoV1SbC432i8q80TgoURUKPgPAuuwApTzdcwb4UyRhvkSRDCbOKv
H3n/27S1AgMBAAGjggGEMIIBgDASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZI
AYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNV
HQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2
YXRlTGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8E
KjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDCBgQYDVR0jBHoweKFj
pGEwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFz
cyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5ghEAzbp/VvDf5LxU/iKs
s3KqVTANBgkqhkiG9w0BAQUFAAOBgQCxL9mW4ZKi7oFg5cgqIPvhZyzWAJhTowIb6ZBL+BhEnw9G
9/qg/tMdGKPSvxzs1hmfSk1D+Mq7vhOASQXdIXMzV8JCWr76AJOy5gQxkU5dPPBzBTdj67+DWZj9
Zt7phjKakik8Oq5U2qYSUbGPyMrTR3jm26Uehwbj0RTAwiH2ujCCBOUwggPNoAMCAQICEE2vqtiu
yqYVrOEv8MvOnVMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp
U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy
bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsT
FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlk
dWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wODEwMTQwMDAwMDBaFw0wOTEwMTcyMzU5NTlaMIIB
HDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv
cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBS
ZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UE
CxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEUMBIGA1UEAxQL
TmlscyBIYW1tYXIxLDAqBgkqhkiG9w0BCQEWHW5pbHMuaGFtbWFyQGN5YmVyY29tZ3JvdXAuY29t
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDK9OCvNd7SoeHTv9CAtBkk2O4JDj37AtwYVzyz
IiVvoqHZ9LEF8+WT4w+dUuFgsQfx1+bFd63U4SDuwzRj5KvIVbc+7FR1igcIdLZUU3Sxn4UbdPZT
tcYeyWt5Y8IuJK/k81uAeAo4nPvzwbMrymoIN4mBsB/RuH8fmr7o+00W/QIDAQABo4HiMIHfMAkG
A1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYI
KwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9J
bmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG
9w0BAQUFAAOCAQEAl5Y1KD8GgWQMmy6bFHps9DJqAG4TLPaGkz8IMg6Y9MbZeruhEZIYz5pZBJCs
jjaejgiGIimQkirfVxg9aYl/hBPXDRmsyeruPg6Vx4GyQlS06ww/52ZYIawelQyyjk5tQQyQesJ4
bnfNiTdAXTlujPnCN3POKXIIyjFEkD8MESudFm6Pv4lfFDV4eHAC8qd/AbPnV2WRG+SOL9YDOoYd
N/rxL/X18/zcb8vFdzDuci3StC43LjOIoVAH7JUTFs8LHXi9gJcMyUiYGgDJ8m4eq3P/a4smzKVM
ScHKUwTfX1W8Zs9onmsWDvTzjULkgojba/zs6oBvkdw8yCvYQM4DADGCBHMwggRvAgEBMIHyMIHd
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu
IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV
BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEE2vqtiu
yqYVrOEv8MvOnVMwCQYFKw4DAhoFAKCCAtYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDgxMTI3MTQwNzI2WjAjBgkqhkiG9w0BCQQxFgQUrD6KW0bWJzupmxglkrOq
mpCpvY4wZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI
hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwggED
BgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j
LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl
IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg
Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNj
cmliZXIgQ0EgLSBHMgIQTa+q2K7KphWs4S/wy86dUzCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHd
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu
IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV
BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEE2vqtiu
yqYVrOEv8MvOnVMwDQYJKoZIhvcNAQEBBQAEgYCpBG16o6yJunOIxpD8tXIeMLpr785llp0rSFzi
Bl29rw1EWwsVlU5aRyHlKzZUOwdS/WhPLlAb10aQUcCHv+2QDcWjLId+zOjQiubYHNCyh7inWH+u
0dqDDTAMyVbBd6yDUWWIN7MQ+++vyCBJ0WCSDE2DsYhhg19h9v2C4s49KAAAAAAAAA==
------=_NextPart_000_0029_01C950A1.DC1D8A50--
14 years, 3 months
(ITS#5832) Networking and Replication.
by nils.hammar＠cybercomgroup.com
Full_Name: Nils Hammar
Version: 2.4.13
OS: CentOS 5.2
URL:
Submission from: (NULL) (194.17.253.72)
When running syncrepl between two nodes in MirrorMode the communication works as
it should until there is a disturbance on the network stack on either node.
This is applicable to Linux where iptables is used to filter traffic.
Example:
Node A and B are running and updates on A are replicated to B.
An update is done on iptables on B and the iptables is reloaded through
"/etc/init.d/iptables restart".
Any further updates on A are no longer replicated to B until the slapd service
is restarted on B.
So it seems to me that there is no 'keep alive' or similar functionality in the
networking that catches this kind of situation.
14 years, 3 months
(ITS#5831) Replication unreliable
by nils.hammar＠cybercomgroup.com
Full_Name: Nils Hammar
Version: 2.4.13
OS: CentOS 5.2
URL: http://www.bedug.com/pics/openldap/nils-hammar-081127.tgz
Submission from: (NULL) (194.17.253.72)
OpenLDAP 2.4.13 has caused me some problems.
It doesn't work reliable when I try to set up MirrorMode replication following
the example given in the documentation at
http://www.openldap.org/doc/admin24/replication.html#MirrorMode
What I do is to set up one node first using the setup in files found at:
http://www.bedug.com/pics/openldap/nils-hammar-081127.tgz, then I import an LDIF
file containing the data there. All is well so far, and then I start the second
node (which is having a completely uninitialized database), and it starts to
communicate with the node where I imported the LDIF file, but it soon "hangs"
and no further progress is made. It doesn't seem to replicate any data at all.
Using 2.4.12 everything works as I expect it to - the second node builds a
mirror of the first.
Right now I'm using BDB 4.6.21, since I wasn't able at all to make BDB 4.7.25
(with patch) to work. Not even "make test" succeded with the first test, it just
hung. (which is another problem, probably not related to this problem)
14 years, 3 months
Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr
Howard Chu wrote :
>You said you pulled from HEAD on November 3, and still saw the problem. Either
>your checkout was wrong, or your configuration was wrong, because the fix was
>definitely present in HEAD by then.
Hi Howard,
This time I downloaded the release 2.4.13 and ran several tests with my
collegues. I send the results for your information :
Let two mirror servers A and B. The server A is the main one on which we do
usually the write operations and B is the fail-over mirror.
We initiate the directory at the time t0 and do all write operations on A.
At the time t1 we do only one write on B. Then we resume write operations on A.
At t2 we stop B for a cold backup and do one write operation on A.
After B startup, A scans internally all objects writtent after t1, checking for
the attributes objectclass and entryCSN.
If we do a similar operation (write on A while B stopped) at t3, then after
startup again all objects written after t1 and up to t3 are scanned (so more and
more objects in the directory lifetime).
The behaviour of the server B seems OK (it does not scans objects).
This situation is produced if we set "syncprov-nopresent TRUE" on both servers.
Otherwise (without this directive) the server A scans the objects twice :
1) Once ALL directory objects, checking for their objectclass only,
2) A second time the objects written after t1, checking for objectclass and
entryCSN.
On the other hand the server B scans the objects writtent before t1 !
I do not know slapd and syncprov internals but I think that if at each startup
only the biggest contextCSN values of the servers were compared, the most recent
objects would be checked (only one object in our example).
But may be this is not feasible for technical reasons that I ignore ?
Thanks for your patience
Best Regards
Ali
14 years, 3 months
Re: (ITS#5829) Missing moduleload doc. confusing chain/distproc/slapi.
by hyc＠symas.com
h.b.furuseth(a)usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: HEAD
> OS:
> URL:
> Submission from: (NULL) (129.240.6.233)
> Submitted by: hallvard
>
>
> slapd.conf(5)'s moduleload description should say which filename a
> module has: foo.so or foo.la. (Or worse - is that different on
> different OSes? Windows, anyone?)
"foo.la" will work on all platforms. The actual shared object that the .la
file points to may have different naming conventions on different platforms.
> It should say where the standard installed modules are found.
> Also that is a default modulepath which as far as I can tell from
> strace includes the standard installation directory and the system
> loader's standard load path. And again, is it OS-dependent? It
> uses libtool's lt_dlopenext(), I haven't looked for what it does yet.
I would expect that of course yes, the system loader's standard path is
OS-dependent.
> slapd.plugin(5) should mention that slapi itself is a module which
> may need to be loaded. And that it's "slapi.la", not "plugin.la".
> The chain and distproc overlays are not found in<overlay>.la but in
> back_ldap.la. This should be documented. I suggest a "moduleload
> back_ldap.la" statement before all the other directives, with
> explanation.
>
> However, even if documented, people will miss that. One does't look
> for doc about what one already "knows".
>
> The simplest and maybe most informative fix would be to add dummy
> modules which simply give an error message that the overlays are found
> in the back_ldap module.
When the software knows exactly what must be done, failing with an error
message is just annoying. If we were to do anything here at all, dummy modules
would better be replaced by symlinks to the actual module, so that It Just
Works. But I think just noting the discrepancy in the documentation is sufficient.
> An alternative would be to move them to separate modules which depend on
> back-ldap - and document their dependency on back-ldap. More correct I
> guess, but personally I don't see how it's an improvement. That might
> just be because I have had little to do with maintaining binary
> distributions though.
I don't think it's an improvement either.
> A third would be to store a module registry where module names are
> mapped to one or more module filenames to load. Overkill? More
> general, but also more complex.
Yes, overkill. And there are probably more modules out there than we would
ever know about for a registry, so ultimately not useful.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 3 months
(ITS#5829) Missing moduleload doc. confusing chain/distproc/slapi.
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: HEAD
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
slapd.conf(5)'s moduleload description should say which filename a
module has: foo.so or foo.la. (Or worse - is that different on
different OSes? Windows, anyone?)
It should say where the standard installed modules are found.
Also that is a default modulepath which as far as I can tell from
strace includes the standard installation directory and the system
loader's standard load path. And again, is it OS-dependent? It
uses libtool's lt_dlopenext(), I haven't looked for what it does yet.
slapd.plugin(5) should mention that slapi itself is a module which
may need to be loaded. And that it's "slapi.la", not "plugin.la".
The chain and distproc overlays are not found in <overlay>.la but in
back_ldap.la. This should be documented. I suggest a "moduleload
back_ldap.la" statement before all the other directives, with
explanation.
However, even if documented, people will miss that. One does't look
for doc about what one already "knows".
The simplest and maybe most informative fix would be to add dummy
modules which simply give an error message that the overlays are found
in the back_ldap module.
An alternative would be to move them to separate modules which depend on
back-ldap - and document their dependency on back-ldap. More correct I
guess, but personally I don't see how it's an improvement. That might
just be because I have had little to do with maintaining binary
distributions though.
A third would be to store a module registry where module names are
mapped to one or more module filenames to load. Overkill? More
general, but also more complex.
14 years, 3 months
