Dynamically unloading a module
by Jaap Winius
Hi folks,
With cn=config (OpenLDAP 2.4.23-6 on Debian squeeze), dynamically
loading a module is straightforward. E.g., create an LDIF to add the
the attribute "olcModuleLoad: {1}syncprov" to the cn=module{0} entry,
apply it and as a result the configuration will be changed and the
module loaded.
However, when attempting to do the reverse -- applying an LDIF to
delete that same attribute and unload the module -- this error appears:
modifying entry "cn=module{0},cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)
additional info: cannot delete olcModuleLoad
Of course, it is still possible to stop slapd, remove the unwanted
attribute directly from /etc/ldap/slapd.d/cn=config/cn=module{0}.ldif
and start slapd again, but surely that is not the preferred method.
Can anyone explain what the correct method is for dynamically removing
a module, or does this not work due to a bug in the aforementioned
version of OpenLDAP?
Thanks,
Jaap
13 years, 1 month
Multimaster "cluster" + Regular Slaves (consumers?)
by Ciro Iriarte
Hi, I've done some Master/Slave replication in the 2.2 era. Right
now I'm looking to setup a multimaster replication with 2.4 on a main
office (2 node pacemaker cluster) and at least 6 slaves (only
"consumers" this days) on different branches.
This LDAP directories will be used as samba backends. A PDC/BDC pair
on the main office and BDCs on the branches.
Should this work with the "only slaves" pointing to a clustered IP
that could move between the two clustered nodes?. This resource can be
for "load balancing" or failover only.
Should regular replication work?, what about delta replication?
Anybody has done something like this?.
Regards,
--
Ciro Iriarte
http://cyruspy.wordpress.com
--
13 years, 1 month
tag=97 error in openLDAP
by Tim Dunphy
Hello,
I recently had a "knowledgeable" friend work on my openldap server.
he made some
changes to the cofigs without backing them up and now users are unable
to authenticate against this openldap 2.4 server where previously they
could. I am running on FreeBSD 8.1. I am a student trying to learn and
be comfortable with openLDAP.
when a user ssh's to any machine on the network that is configured to
listen to this ldap server now gets an error in the LDAP logs:
Oct 29 22:49:41 LBSD2 slapd[1085]: <= bdb_equality_candidates: (uid) not indexed
Oct 29 22:49:41 LBSD2 slapd[1085]: conn=1001 op=7 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Oct 29 22:49:41 LBSD2 slapd[1085]: conn=1002 op=4 BIND
dn="uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com"
method=128
Oct 29 22:49:41 LBSD2 slapd[1085]: conn=1002 op=4 RESULT tag=97 err=49 text=
Oct 29 22:49:41 LBSD2 slapd[1085]: conn=1002 op=5 BIND dn="" method=128
Oct 29 22:49:41 LBSD2 slapd[1085]: conn=1002 op=5 RESULT tag=97 err=0 text=
it looks like it's failing to bind:
conn=1003 op=3 BIND dn="" method=128
and I think this error may be key but I am unsure of it's meaning:
tag=97
my ldap.conf reads as so:
host ldap.summitnjhome.com
base dc=summitnjhome,dc=com
scope sub
pam_password exop
nss_base_passwd ou=staff,dc=summitnjhome,dc=com
nss_base_shadow ou=staff,dc=summitnjhome,dc=com
sudoers_base ou=sudoers,ou=Services,dc=summitnjhome,dc=com
And why would the uid not be indexed?
and this is the user id in LDAP:
[root@LBSD2:/home/bluethundr/txt/ldif]#cat bluethundr.ldif
dn: uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com
uid: bluethundr
cn: Timothy P.
givenName: Timothy P.
sn:
mail: bluethundr(a)blah.com
mailRoutingAddress: bluethundr(a)mail.blah.com
mailHost: mail.blah.com
objectClass: inetLocalMailRecipient
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
userPassword: {CRYPT}secret
loginShell: /usr/local/bin/bash
uidNumber: 1001
gidNumber: 1002
homeDirectory: /home/bluethundr
gecos: Timothy P.
and these are my ACL's in slapd.conf:
access to *
by read
access to attrs=userPassword by self write
by anonymous auth
access to * by self write
by dn.children="ou=summitnjops,ou=staff,dc=summitnjhome,dc=com"
write
by users read
by anonymous auth
access to * by self write
I would certainly appreciate any help to get this working again!
thank you
--
Here's my RSA Public key:
gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9
Share and enjoy!!
13 years, 1 month
