Re: Trying to understand an error message
by Khaled Blah
Thanks for your reply, Hallvard. Do I understand it correctly that I
can re-use LDAP structures on which a bind has already been done? Do
you know of any other stateful data I would have to look at?
Regards,
Khaled
2010/11/12 Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no>:
> Khaled Blah writes:
>> My application creates LDAP structures (using ldap_init) and re-uses
>> these structures whenever possible so that the least number of LDAP
>> binds have to done. Is there anything I need to do after an LDAP
>> operation has finished or maybe do I have to unbind at some point to
>> make sure the LDAP structure remains in a valid state? I would be
>> happy to receive any insight into this.
>
> With LDAP *ld, call ldap_unbind(ld) when you are finished with ld, and
> not before. ldap_unbind() is actually the destructor for an LDAP*, in
> addition to sending an Unbind message.
>
> --
> Hallvard
>
12 years, 6 months
Out of memory Errors when starting up Slurpd: Openldap-server-2.3.43
by Traiano Welcome
Hi List
We're using openldap-server 2.3.43 on FreeBSD 6.2-RELEASE-p9 #0. When trying
to start up slurpd (/usr/local/etc/rc.d/slurpd start), slurpd runs for a
while then dies at various points during it's replication with error "Out of
memory". The following are various attempts to start slurpd, with the last
messages it dies with before "Out of Memory".
My question is: Is this a known bug? What could be the cause of these out of
memory errors in Slurpd?
Test one:
---
Initializing session to ldap://server.ops.aanet.co.za:389
Error: ldap_initialize(0, ldap://server.ops.aanet.co.za:389) failed: Out of
memory
---
Test two:
---
malloc of 3 bytes failed
Error: ldap_modify_s failed modifying DN
"uid=sherbert.buth,ou=mycast.co.za,ou=AuthSystem,dc=za,dc=oo,dc=com": Out of
memory
---
Test three:
----
Error: ldap operation failed, data written to
"/var/db/openldap-slurp/replica/server.ops.aanet.co.za:389.rej"
----
Test four:
---
Error: ldap_modify_s failed modifying DN
"uid=bruce,ou=fatnet.co.za,ou=AuthSystem,dc=za,dc=uu,dc=net": Out of memory
---
Test 5:
---
Error: ldap operation failed, data written to
"/var/db/openldap-slurp/replica/server.ops.aanet.co.za:389.rej"
---
Test 6:
---
ldif_parse_line: type malloc failed
Error: malformed replog line "replace: sn"
Warning: freeing re (dn:
uid=dericks,ou=anb.co.za,ou=AuthSystem,dc=za,dc=uu,dc=net) with nonzero
refcnt
error: malformed replog entry (begins with "replica:
server.ops.aanet.co.za:389")
Error: ldap_modify_s failed modifying DN
"uid=tyrone,ou=business.net,ou=AuthSystem,dc=za,dc=,dc=net": Out of memory
Error: ldap operation failed, data written to
"/var/db/openldap-slurp/replica/server.ops.aanet.co.za:389.rej"
ldif_parse_line: value malloc failed
Error: malformed replog line "olcPasswordHash: 92XXXXXXXXXXXXXXXXXXXX"
Warning: freeing re (dn:
uid=adi,ou=anb.co.za,ou=AuthSystem,dc=za,dc=oo,dc=net) with nonzero refcnt
error: malformed replog entry (begins with "replica:
server.ops.aanet.co.za:389")
malloc of 12 bytes failed
malloc of 8 bytes failed
---
Thanks in Advance,
Traiano Welcome
12 years, 6 months
Assigning a Member to Multiple Groups
by Anton Chu
Unfortunately there's can only be one GID number per user entry into the
DIT, how can I assign multiple groups to one user? So when that user logs
into a server, he or she will have multiple group IDs.
12 years, 6 months
How to convert Solaris m5 passwords to LDAP?
by Christian Schmidt
Hi all,
we want to switch a server machine from Solaris (credentials stored
in "traditional" passwd and shadow file) to Debian with OpenLDAP for
authentication.
Creating LDIF files from /etc/passwd and /etc/shadow using PADL's
migrationtools is working fine. The only problem is, that many user
passwords on the Solaris machine have been encrypted using Sun's md5 scheme
which results in hashes beginning with the characters "$md5$".
These hashes can be "imported" into our LDAP directory, but
they cannot be used for authentication: Each attempt results in
"access denied" on the client side and LDAP bind errors on the server
side. Even when adding the user information to /etc/passwd and
/etc/shadow on the Linux machine, there's no success.
With CRYPT password hashes, everything works fine.
Do you know any means to "convert" these Solaris-md5-hashed
password strings into something we can use with OpenLDAP?
I appreciate your helpful answers. Thanks in advance!
Gruss/Regards,
Christian Schmidt
--
You have an ability to sense and know higher truth.
12 years, 6 months
Syncrepl from OSX slapd to Centos5 slapd
by Markku Tavasti
Hi!
We have OSX as primary ldap server (slapd 2.3.27). Schema is OSX tuned
schema, with Apple provided extensions.
I'm trying to set up backup-ldap to Centos5 server (slapd 2.3.43).
I have copied schemas from OSX /etc/openldap/schema, and edited &
commented out attributetype 'authAuthority' definition from
apple.schema. OSX is running with configuration from cn=config, so how I
can check if schema it uses is 100% same as in schema files?
Here is my syncrepl config on client side:
syncrepl rid=23
provider=ldap://xxxx.domain.com
type=refreshOnly
interval=00:00:10:00
retry="60 10 300 +"
searchbase="dc=xxxx,dc=domain,dc=com"
scope=sub
schemachecking=off
bindmethod=simple
binddn="uid=replicator,cn=users,dc=xxxx,dc=domain,dc=com"
credentials=secret
Client-slapd starts ok, and replication gets only one entry:
# xxxx, computers, xxxx.domain.com
dn: cn=xxxx,cn=computers,dc=xxxx,dc=domain,dc=com
To log on client side I get only these:
Nov 11 05:31:46 xxxx slapd[13962]: do_syncrep2: rid 023
LDAP_RES_SEARCH_RESULT
Nov 11 05:41:46 xxxx slapd[13962]: daemon: epoll: listen=7
active_threads=0 tvp
=zero
Nov 11 05:41:46 xxxx slapd[13962]: daemon: epoll: listen=8
active_threads=0 tvp
=zero
Any ideas what is problem?
--
M. Tavasti / tavasti(a)tavasti.fi / +358-40-5078254
12 years, 6 months
Trying to understand an error message
by Khaled Blah
Hello all,
I have written an application which uses OpenLDAP and I keep receiving
this error message:
"sasl.c:75: ldap_sasl_bind: Assertion `( (ld)->ld_options.ldo_valid ==
0x2 )' failed."
The code at this position says the following:
"assert( LDAP_VALID( ld ) );"
My application creates LDAP structures (using ldap_init) and re-uses
these structures whenever possible so that the least number of LDAP
binds have to done. Is there anything I need to do after an LDAP
operation has finished or maybe do I have to unbind at some point to
make sure the LDAP structure remains in a valid state? I would be
happy to receive any insight into this.
Regards,
Khaled
12 years, 6 months
German Umlauts are converted and also not accepted
by Götz Reinicke - IT-Koordinator
Hallo,
I'v searched for an answer but did not found one yet.
I do have a openldap-2.3.43 server (centos 5.5.) in test and tried to
add a ldif-file with my data using the apache directory studio (on mac
os x).
As my name contains a german umlaut I do get an error adding 'Götz
Reinicke' for the gecko.
Also for 'displayName', 'cn' and 'givenName' the 'ö' is automatically
replaced by 'oe'.
If I change the entry in the ldap by hand in the apache DS, the 'ö' is
accepted accept for the geckos. An 'ü' in 'o' is manually accepted to.
Any hints, explanations, suggestions?
Thanks and best regards,
Götz
--
Götz Reinicke
IT-Koordinator
Tel. +49 7141 969 420
Fax +49 7141 969 55 420
E-Mail goetz.reinicke(a)filmakademie.de
Filmakademie Baden-Württemberg GmbH
Akademiehof 10
71638 Ludwigsburg
www.filmakademie.de
Eintragung Amtsgericht Stuttgart HRB 205016
Vorsitzende des Aufsichtsrats:
Prof. Dr. Claudia Hübner
Geschäftsführer:
Prof. Thomas Schadt
12 years, 6 months
olcDbURI error
by Jaap Winius
Hi folks,
After applying some changes to a consumer server used for testing
purposes, my attempts to run slapcat result in the following error:
####################################
slapd-chain: first underlying database
"olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config"
cannot contain attribute "olcDbURI".
config error processing
olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config:
slapcat: bad configuration file!
####################################
(Debian squeeze, slapd v2.4.23-6)
After having configure syncrepl on the same host, I used slapcat to
compare its newly replicated database to the one on the provider. At
that point it still worked and the databases proved to be identical.
I then proceeded to configure chaining and a referral. The above
slapcat error appeared after I made the following changes (which
applied successfully):
###########################################################################
# 1.
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcUpdateref
olcUpdateref: ldap://ldaps.example.com
# 2.
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: {1}back_ldap
# 3.
dn: olcOverlay={0}chain,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {0}chain
olcChainReturnError: TRUE
# 4.
dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {0}ldap
olcDbURI: ldap://ldaps.example.com
olcDbRebindAsUser: TRUE
olcDbIDAssertBind: bindmethod=simple
binddn="cn=ldaps2,dc=example,dc=com"
credentials=bilineatus
mode=self
###########################################################################
Afterwards, slapd could no longer be restarted either, with the same
error showing up in the syslog.
I am aware that this is a known bug:
http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6540;selectid=6540
According to the report, a patch was made available on April the 29th,
but I'm not sure if it actually fixed anything. At any rate, my Debian
slapd version is dated from the 23rd of September and still has this
problem.
However, Followup 17 (31 July) in the bug report refers to a "simple
fix". Unfortunately, I haven't yet been able to find what that's
supposed to be.
This seems to me to be a serious bug, but for the time being I'd be
happy with simple workaround. Can anyone help?
Thanks,
Jaap
12 years, 6 months
Asynchronicity
by William Ahern
Excepting DNS, is the latest release of OpenLDAP fully asynchronous-capable,
even with TLS? Perusing the source code I can't find any obvious places
other than DNS where things might block, but it's harder to prove the
negative.
I remember many years ago this wasn't the case, and I had to thread the
connect phase, but the ChangeLog suggests that things have changed
considerably.
12 years, 6 months
number of contextcsn entries per database
by PJunod＠mediageneral.com
I have setup two ldap servers for authentication and access control in a multi-master configuration. I am concerned about the number of contextcsn entries that are supposed to be present in each database. Right now there are two servers participating in the multi-master configuration. From my understanding, there should be one contextCSN entry per database per host. My cn=config database has two contextCSN entries as I would expect. One for each syncrepl rid configured. My bdb database only has one contextCSN entry though, with an rid of just "000". (my rid's are 001, 002, 101, and 102)
Replication seems to work fine on both databases. I can write to either one and the changes are replicated over immediately. I am just curious about this discrepancy in the number of contextCSN entries. Could someone confirm the number of contextCSN entries per database and if it should match the number of hosts participating in the multi-master replication? Here are some relevant settings for the replication:
dn: cn=config
olcServerID: 1 ldap://<server1>
olcServerID: 2 ldap://<server2>
#######################
# module{0}, config
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap2.4
olcModuleLoad: {0}syncprov.la
#######################
# {0}config, config
dn: olcDatabase={0}config,cn=config
olcSyncrepl: {0}rid=001 provider=ldap://<server1> binddn="cn=Ma
nager,cn=config" bindmethod=simple credentials=<password> searchbase="cn=config
" type=refreshAndPersist retry="5 500 5 +" timeout=1 starttls=yes
olcSyncrepl: {1}rid=002 provider=ldap://<server2> binddn="cn=Ma
nager,cn=config" bindmethod=simple credentials=<password> searchbase="cn=config
" type=refreshAndPersist retry="5 500 5 +" timeout=1 starttls=yes
olcMirrorMode: TRUE
#######################
# {0}syncprov, {0}config, config
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
#######################
# {1}bdb, config
dn: olcDatabase={1}bdb,cn=config
olcSyncrepl: {0}rid=101 provider=ldap://<server1> binddn="cn=Ma
nager,dc=mgcorp,dc=net" bindmethod=simple credentials=<password> searchbase="dc
=mgcorp,dc=net" type=refreshAndPersist interval=00:00:00:10 retry="5 500 5 +"
timeout=1 starttls=yes
olcSyncrepl: {1}rid=102 provider=ldap://<server2> binddn="cn=Ma
nager,dc=mgcorp,dc=net" bindmethod=simple credentials=<password> searchbase="dc
=mgcorp,dc=net" type=refreshAndPersist interval=00:00:00:10 retry="5 500 5 +"
timeout=1 starttls=yes
olcMirrorMode: TRUE
##############################
Here are the results of searches for contextCSN in cn=config and dc=mgcorp,dc=net:
ldapsearch -x -W -s base -D "cn=Manager,cn=config" -h "<server2>" -b "cn=config" contextCSN
contextCSN: 20101110214932.998233Z#000000#000#000000
contextCSN: 20101028121213.444193Z#000000#001#000000
ldapsearch -x -W -s base -D "cn=Manager,dc=mgcorp,dc=net" -h "<server2>" -b "dc=mgcorp,dc=net" contextCSN
contextCSN: 20101110213409.736943Z#000000#000#000000
12 years, 6 months
