PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Probleme beim ersten Einrichten von Ldap #2



tim
25.09.06, 22:00
Hallo.

Sitze an meinem ersten Versuch einen LDAP Verzeichnis Server für Thunderbird einzurichten.
Beim Importieren der ersten LDIF Datei bekomm ich jedoch folgenden Fehler:



hermes:~# slapadd -l /etc/ldap/hermes.ldif
/etc/ldap/slapd.conf: line 102: rootdn is always granted unlimited privileges.
/etc/ldap/slapd.conf: line 124: rootdn is always granted unlimited privileges.
bdb_db_open: database already in use
backend_startup_one: bi_db_open failed! (-1)
slap_startup failed


Meine hermes.ldif hat folgenden Inhalt:



# Eintrag 1: dc=hermes,dc=local
dn:dc=hermes,dc=local
objectClass: dcObject
objectClass: organization
o: hermes
dc: hermes

# Eintrag 2: cn=admin,dc=hermes,dc=local
dn:cn=admin,dc=hermes,dc=local
objectClass: organizationalRole
cn: admin

# Eintrag 3: ou=adressbook,dc=hermes,dc=local
dn:ou=adressbook,dc=hermes,dc=local
ou: adressbook
objectClass: organizationalUnit



Und meine slapd.conf sieht folgendermaßen aus:



# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.

################################################## #####################
# Global Directives:

# Features to permit
#allow bind_v2

# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/mozilla_op20.schema
include /etc/ldap/schema/extension.schema

# Schema check allows for forcing entries to
# match schemas for their objectClasses's
schemacheck on

# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd/slapd.pid

# List of arguments that were passed to the server
argsfile /var/run/slapd/slapd.args

# Read slapd.conf(5) for possible values
loglevel 0

# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_bdb

# The maximum number of entries that is returned for a search operation
sizelimit 500

# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads 1

################################################## #####################
# Specific Backend Directives for bdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend bdb
checkpoint 512 30

################################################## #####################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
#backend <other>

################################################## #####################
# Specific Directives for database #1, of type bdb:
# Database specific directives apply to this databasse until another
# 'backend' directive occurs
#backend <other>

################################################## #####################
# Specific Directives for database #1, of type bdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database bdb

# The base of your directory in database #1
suffix "dc=hermes,dc=local"

# rootdn directive for specifying a superuser on the database. This is needed
# for syncrepl.
rootdn "cn=admin,dc=hermes,dc=local"

# Where the database file are physically stored for database #1
directory "/var/lib/ldap"

# For the Debian package we use 2MB as default but be sure to update this
# value if you have plenty of RAM
dbconfig set_cachesize 0 2097152 0

# Sven Hartge reported that he had to set this value incredibly high
# to get slapd running at all. See http://bugs.debian.org/303057
# for more information.

# Number of objects that can be locked at the same time.
dbconfig set_lk_max_objects 1500
# Number of locks (both requested and granted)
dbconfig set_lk_max_locks 1500
# Number of lockers
dbconfig set_lk_max_lockers 1500

# Indexing options for database #1
index objectClass eq

# Save the time that the entry gets modified, for database #1
lastmod on

# Where to store the replica logs for database #1
# replogfile /var/lib/ldap/replog

# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword,shadowLastChange
by dn="cn=admin,dc=hermes,dc=local" write
# by anonymous auth
by anonymous read
by self write
# by * none
by users write

# Ensure read access to the base for things like
# supportedSASLMechanisms. Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
access to dn.base="" by * read

# The admin dn has full write access, everyone else
# can read everything.
access to *
by dn="cn=admin,dc=hermes,dc=local" write
by * read

# For Netscape Roaming support, each user gets a roaming
# profile for which they have write access to
#access to dn=".*,ou=Roaming,o=morsnet"
# by dn="cn=admin,dc=hermes,dc=local" write
# by dnattr=owner write

################################################## #####################
# Specific Directives for database #2, of type 'other' (can be bdb too):
# Database specific directives apply to this databasse until another
# 'database' directive occurs
#database <other>

# The base of your directory for database #2
#suffix "dc=debian,dc=org"



Vielleicht hat ja einer von Euch eine Idee vodran der Fehler liegen könnte.

Danke Timmi

emwe
26.09.06, 07:01
Hallo,

die folgende Zeile ist die entscheidende:



bdb_db_open: database already in use


Wie man 'man slapadd' bzw. 'man ldapadd' entnehmen kann, fügt slapadd Daten offline hinzu, wohingegen ldapad online arbeitet. Soll heißen:

Wenn Du slapadd benutzt, darf der Server nicht schon laufen. Wenn Du ldapadd benutzt, muss er laufen.

Oder logischer:

Mit slapadd fügst Du die initialen Einträge normalerweise vor dem Betrieb des Servers hinzu. Mit ldapadd fügst Du Einträge im laufenden Betrieb hinzu - das ist der normale Weg. Achte beim Einsatz von ldapadd darauf, dass Du eine dn benutzt, die genügend Schreibrechte hat (z.B. root-dn).

Gruß,

emwe

tim
26.09.06, 19:44
@emwe

da ich slapadd benutze muß er laut Dir aus sein. Das ist er aber leider.
Kann es sein das ein anderes Prog diese DB nutzt ?
Wie könnte man das raus bekommen ?


NACHTRAG !!!!

Wie ich grad gesehen habe, hat sich die Fehlermeldung geändert. Ich weiß nicht genua wieso.
Nun ist es:



hermes:~# slapadd -l /etc/ldap/hermes.ldif
/etc/ldap/slapd.conf: line 102: rootdn is always granted unlimited privileges.
/etc/ldap/slapd.conf: line 124: rootdn is always granted unlimited privileges.
=> bdb_tool_entry_put: id2entry_add failed: DB_KEYEXIST: Key/data pair already exists (-30996)
=> bdb_tool_entry_put: txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30996)
slapadd: could not add entry dn="dc=hermes,dc=local" (line=8): txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30996)

emwe
26.09.06, 22:47
Hallo,

das bedeutet, das der key (also der Eintrag) schon mal eingetragen wurde. Wenn Dir slapcat den Eintrag zeigt, ist er bereits eingetragen.

Schau Dir an, was slapcat zurück liefert.

Gruß,

emwe

tim
26.09.06, 22:51
dann wir das wohl korrekt ausgeführt worden zu sein.
dann werd ich morgen mal das weitere testen.

slapcat zeigt folgendes:



hermes:~# slapcat
/etc/ldap/slapd.conf: line 102: rootdn is always granted unlimited privileges.
/etc/ldap/slapd.conf: line 124: rootdn is always granted unlimited privileges.
dn: dc=hermes,dc=local
objectClass: top
objectClass: dcObject
objectClass: organization
o: hermes.local
dc: hermes
structuralObjectClass: organization
entryUUID: 3e625d8c-e10f-102a-82b4-9184cbe2c3c8
creatorsName:
modifiersName:
createTimestamp: 20060925182728Z
modifyTimestamp: 20060925182728Z
entryCSN: 20060925182728Z#000000#00#000000

dn: cn=admin,dc=hermes,dc=local
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e2NyeXB0fUREZTkwQ2JPZjNJLkE=
structuralObjectClass: organizationalRole
entryUUID: 3e656108-e10f-102a-82b5-9184cbe2c3c8
creatorsName:
modifiersName:
createTimestamp: 20060925182728Z
modifyTimestamp: 20060925182728Z
entryCSN: 20060925182728Z#000001#00#000000

emwe
27.09.06, 06:26
Hallo,

wie du aus der slapcat-Ausgabe sehen kannst, wurde der Eintrag ou=addressbook,dc=hermes,dc=local nicht eingetragen. Der korrespondierende Eintrag aus der hermes.ldif sieht aber auf den ersten Blick korrekt aus (obwohl normalerweise noch ein objectClass: top dazugehoert). Kopiere einfach den letzten Abschnitt in eine neue Datei und importiere die mit slapadd.



# Eintrag 3: ou=adressbook,dc=hermes,dc=local
dn:ou=adressbook,dc=hermes,dc=local
ou: adressbook
objectClass: top
objectClass: organizationalUnit


Noch drei Anmerkungen:

1. Wie Dir auch slapadd versucht mitzuteilen musst Du für die rootdn (cn=admin,dc=...) keine Schreibberechtigung vergeben, da er die sowieso schon hat.

2. Schau Dir doch mal einen graphischen LDAP-Client an - zum Beispiel gq. Das ist etwas komfortabler als mit ldapadd/ldapsearch. Trotzdem solltest Du Dich mit ldapadd/ldapsearch vertraut machen, da man damit meiner Erfahrung nach am besten die Zugriffsrechte testen kann.

3. Auch wenn das userPassword-Attribut in diesem Fall per {crypt} verschlüsselt wurde, würde ich es nirgends posten. John freut sich immer über neue Arbeit... ;).


Gruß,

emwe