use of slappasswd -T file and ldappasswd -T file
by Erik Guss
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
12 years, 8 months
Migrating from 2.3 to 2.4 branch.
by andylockran
-----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-----
12 years, 8 months
Re: Migrating from 2.3 to 2.4 branch
by Peter Mogensen
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
12 years, 8 months
OpenLDAP replication 'credentials'
by Mark W Apperson
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
12 years, 8 months
Schemas and back-config
by Daniel Durgin
Hello,
What is the best way to convert .schema files into schema.ldif files?
Thank you,
Dan
12 years, 8 months
slapd seg faults
by Mike Johnston
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.
12 years, 8 months
cn=config
by Mike Johnston
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.
12 years, 8 months
smbk5pwd: unable to initialize krb5 admin context: failed to open /var/lib/heimdal-kdc/m-key: Permission denied (13).
by Bill Baird
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
12 years, 8 months
slapd segfault with error 4
by Patrice
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
12 years, 8 months
delta-syncrepl contextCSN update timing, schema checking
by John Morrissey
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/ __(_)/_(_)________/ \_______(_) /_(_)__
12 years, 8 months
