openldap-software May 2008

openldap-software@openldap.org

64 participants
55 discussions

use of slappasswd -T file and ldappasswd -T file
by Erik Guss 11 May '08

11 May '08

Hi, I have a functional openldap server (2.3.39) compiled and installed on redhat 4. I can use both ldappasswd and slappasswd from the command line with the -s newpassword syntax successfully to either display a value (slappasswd) or modify the directory (ldappasswd). This works. The problem is that both ldappasswd and slappasswd with the -T file syntax do not seem to work. The contents of my file are just newpassword, with no quotes, no newline. Does anyone know if there is some special syntax for the file when using ldappasswd -T file or: slappasswd -T file thanks for any help. Erik

1 0

Migrating from 2.3 to 2.4 branch.
by andylockran 09 May '08

09 May '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Guys, I'm looking to upgrade my system from the 2.3 to the 2.4 branch of openLDAP. I've spent a little time looking at the possible pitfalls. Immediately I've had issues with slapadding the data directly into 2.4 - - so was wondering if there was some documentation on migrating from one to the other? Regards, Andy Loughran -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIIeCIauMjEM4rxIQRAjtKAJ9U2snyYyaO4SPBQqRZd/S3Ex7fqwCeP3FO 4xc8tmCaYpf+AQVFMtZ6PUA= =4zvt -----END PGP SIGNATURE-----

4 6

Re: Migrating from 2.3 to 2.4 branch
by Peter Mogensen 08 May '08

08 May '08

Gavin Henry wrote: ======================================================================== > > Rather than have you guys hold my hand through each step I'd like to > > find some documentation as to what changes I can expect to have to > > make (noting there is a ppolicy and a ppolicy-2.4). Well, if the docs aren't there, that's my job. We have: http://www.openldap.org/doc/admin24/appendix-changes.html And http://www.openldap.org/doc/admin24/appendix-upgrading.html Needs to have more info in it. ========================================================================== It seems these docs doesn't mention the change to ACL search semantics mentioned in ITS #5400. It has bitten me a a few others when upgrading from 2.3 to 2.4 It also seems that the debian/ubuntu packages of 2.4 aren't aware of this change. I've not dug deeper into this after I found the cause and fixed my ACLs though... Peter

2 1

OpenLDAP replication 'credentials'
by Mark W Apperson 08 May '08

08 May '08

We will be using OpenLDAP with TLS, and also plan to use the OpenLDAP replication as well. I would like to keep plain text passwords out of config files. We are using the '{SSHA}' configuration option for the 'rootdn' configuration variable. Is there something similar that I can use for the replication 'credentials'? I considered using SASL, but SASL passwords are stored in plain text in the SASL password database, so that would just move the problem to a different file. I unsuccessfully tried using the '{SSHA}' configuration option for the replication 'credentials'. Is there a way to hash or encrypt the replication credentials without using SASL? Thanks in advance of any replies, Mark

5 7

Schemas and back-config
by Daniel Durgin 07 May '08

07 May '08

Hello, What is the best way to convert .schema files into schema.ldif files? Thank you, Dan

2 1

slapd seg faults
by Mike Johnston 06 May '08

06 May '08

Hi again, Ok, so I successfully added my attribute however when adding a new AUXILIARY objectclass (not an entry but new olcObjectClasses attribute to the cn=config schema) slapd seg faults. Any ideas? The last few lines from slapd -d 99 >>> dnPrettyNormal: <cn={5}plas,cn=schema,cn=config> <<< dnPrettyNormal: <cn={5}plas,cn=schema,cn=config>, <cn={5}plas,cn=schema,cn=config> oc_check_required entry (cn={5}plas,cn=schema,cn=config), objectClass "olcSchemaConfig" oc_check_allowed type "objectClass" oc_check_allowed type "cn" oc_check_allowed type "olcObjectIdentifier" oc_check_allowed type "olcAttributeTypes" oc_check_allowed type "olcObjectClasses" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" Segmentation fault (core dumped) Many thanks for assistance --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

3 4

cn=config
by Mike Johnston 06 May '08

06 May '08

Hi, When adding olcObjectClasses & olcAttributeTypes to my schema in cn=config, what are the requirements if any for the values? I see when I imported from slapd.conf, Openldap auto generated numbers in braces {0} {1} {2} {3} {4} with the proper syntax for the value being assigned. Must I use the numbers in braces or can I just toss in the syntax correct string for my new attribute and/or objectclass? Thanks --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

3 2

smbk5pwd: unable to initialize krb5 admin context: failed to open /var/lib/heimdal-kdc/m-key: Permission denied (13).
by Bill Baird 06 May '08

06 May '08

After many struggles getting smbk5pwd to work on CentOS, I have switched to Ubuntu LTS 8.04. I have heimdal-kdc installed as well as slapd. I was able to compile smbk5pwd and install it, but once I add the overlay to my config...I get this error when I try to start it. *.... config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" config_build_entry: "olcDatabase={1}bdb" config_build_entry: "olcOverlay={0}smbk5pwd" backend_startup_one: starting "dc=phoenixmi,dc=com" bdb_db_open: DB_CONFIG for suffix "dc=phoenixmi,dc=com" has changed. Performing database recovery to activate new settings. bdb_db_open: database "dc=phoenixmi,dc=com": dbenv_open(/var/lib/ldap). smbk5pwd: unable to initialize krb5 admin context: failed to open /var/lib/heimdal-kdc/m-key: Permission denied (13). backend_startup_one: bi_db_open failed! (-1) slapd shutdown: initiated ====> bdb_cache_release_all slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy.* *I have made sure the /var/lib/heimdal-kdc/m-key file exists, and even made the file and directory have 777 permissions. Any ideas? Below is my slapd.conf config.* *include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/samba.schema include /etc/ldap/schema/hdb.schema modulepath /usr/lib/ldap moduleload back_bdb moduleload smbk5pwd pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args database bdb suffix "dc=phoenixmi,dc=com" rootdn "cn=manager,dc=phoenixmi,dc=com" rootpw {SSHA}xxxxxxxxxx directory /var/lib/ldap overlay smbk5pwd ##just for testing access to * by * write * Thank you, any help would be greatly appreciated! --Bill

2 1

slapd segfault with error 4
by Patrice 05 May '08

05 May '08

Hello, I have some little troubles with my slapd. version: slapd 2.3.38 (compiled from sources) server: Suse Enterprise v9 x86_64 I add 2 segfault of this kind: kernel: slapd[28934]: segfault at 000000000000001a rip 0000000000471edf rsp 0000000040e7fbe0 error 4 (see log below) This slapd is not used at this time , then, only syncrepl update the slave from the provider. I have another slave server which uses the same provider, but no slapd segfault on this one. here is the log file from the 2 times I add this problem: Apr 17 12:44:23 server2 slapd[28932]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 17 12:44:23 server2 slapd[28932]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 17 12:44:23 server2 slapd[28932]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 17 12:44:23 server2 slapd[28932]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 17 12:44:23 server2 slapd[28932]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 17 12:44:23 server2 slapd[28932]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 17 12:44:23 server2 slapd[28932]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 17 12:44:23 server2 slapd[28932]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 17 12:44:23 server2 slapd[28932]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 17 12:44:23 server2 slapd[28932]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 17 12:44:23 server2 slapd[28932]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 17 12:44:23 server2 slapd[28932]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 17 12:44:23 server2 slapd[28932]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 17 12:44:23 server2 slapd[28932]: syncrepl_entry: rid 102 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Apr 17 12:44:23 server2 slapd[28932]: syncrepl_entry: rid 102 be_search (0) Apr 17 12:44:23 server2 slapd[28932]: syncrepl_entry: rid 102 uid=dhilto,ou=people,o=mydomain Apr 17 12:44:23 server2 slapd[28932]: syncrepl_entry: rid 102 be_modrdn (0) Apr 17 12:44:23 server2 slapd[28932]: syncrepl_entry: rid 102 be_modify (0) Apr 17 12:44:23 server2 slapd[28932]: do_syncrep2: rid 102 LDAP_RES_SEARCH_RESULT Apr 17 12:44:23 server2 kernel: slapd[28934]: segfault at 000000000000001a rip 0000000000471edf rsp 0000000040e7fbe0 error 4 Apr 23 08:48:00 server2 slapd[4327]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 23 08:48:00 server2 slapd[4327]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 23 08:48:00 server2 slapd[4327]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 23 08:48:00 server2 slapd[4327]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 23 08:48:00 server2 slapd[4327]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 23 08:48:00 server2 slapd[4327]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 23 08:48:00 server2 slapd[4327]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 23 08:48:00 server2 slapd[4327]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 23 08:48:00 server2 slapd[4327]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 23 08:48:00 server2 slapd[4327]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 23 08:48:00 server2 slapd[4327]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 23 08:48:00 server2 slapd[4327]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 23 08:48:00 server2 slapd[4327]: do_syncrep2: rid 102 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 23 08:48:00 server2 slapd[4327]: syncrepl_entry: rid 102 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Apr 23 08:48:00 server2 slapd[4327]: syncrepl_entry: rid 102 be_search (0) Apr 23 08:48:00 server2 slapd[4327]: syncrepl_entry: rid 102 uid=jondoe,ou=people,o=mydomain Apr 23 08:48:00 server2 slapd[4327]: syncrepl_entry: rid 102 be_modrdn (0) Apr 23 08:48:01 server2 slapd[4327]: syncrepl_entry: rid 102 be_modify (0) Apr 23 08:48:01 server2 slapd[4327]: do_syncrep2: rid 102 LDAP_RES_SEARCH_RESULT Apr 23 08:48:01 server2 kernel: slapd[8183]: segfault at 000000000000001c rip 0000000000471edf rsp 0000000041680be0 error 4 How can I find what is giving me the segfault ?? Thanks in advance. Patrice

2 2

delta-syncrepl contextCSN update timing, schema checking
by John Morrissey 05 May '08

05 May '08

Recently, a fluke in our configuration distribution system caused one of our consumers (running 2.3.41) to have stale schema information. slapd at debuglevel 16384 emitted: syncrepl_message_to_op: rid 001 mods check (objectClass: value #0 invalid per syntax) We had *not* specified schemachecking in this syncrepl stanza, and slapd.conf(5) says: The schema checking can be enforced at the LDAP Sync consumer site by turning on the schemachecking parameter. The default is off. Should this error have been raised in this case? I tried explicitly disabling schemachecking ("schemachecking=off" in the syncrepl stanza), but this error was still raised. Once the schema was updated appropriately, I started slapd (again at debuglevel 16384) and saw syncrepl operations being successfully executed: syncrepl_message_to_op: rid 001 be_modify uid=example,[...],o=org (0) Thinking all was well, I ^C'd slapd, and slapd shut itself down successfully. I restarted slapd using an init script, but the backend's contextCSN didn't start incrementing. Once again at debuglevel 16384: null_callback: error code 0x10 syncrepl_message_to_op: rid 001 be_modify uid=bad-objectclass,[...],o=org (16) do_syncrepl: rid 001 retrying (29 retries left) uid=bad-objectclass is the same entry that triggered the schemachecking error in the first place. Error 0x10 is LDAP_NO_SUCH_ATTRIBUTE, and this seems a lot like the symptoms described in this thread: http://www.openldap.org/lists/openldap-software/200801/msg00126.html To make a long story short, it seems that syncrepl doesn't update the backend's contextCSN until it's processed its backlog? To check, I stopped another consumer and let a backlog build, then started it at debuglevel 16384 and watched the backend's contextCSN with ldapsearch(1). contextCSN didn't increment until the backlog was completely processed, even though I could see the changes it was processing with ldapsearch(1) as soon as they were processed. If a consumer processes replication without updating the backend's contextCSN, it will try to re-process the same replication entries when it starts up again, which will generally fail. This seems to leave one in a bind, either having to manually determine the correct value for contextCSN and update it manually, or remove the backend's data files and let syncrepl rebuild them from scratch. If this assessment is correct, this behavior doesn't seem desirable. john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

3 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software May 2008