Hallo, "Beda Szukics" writes:

Hallo Leute

Wenn ich mit dem New unser druid des Directory administrator einen neuen Nutzer anlegen will, so erscheint am Schluss des Dialogs die Meldung "Object class violation". Was lief da falsch? Die bereits bestehenden (mit Yast eingetragenen) Nutzer erscheinen. Der LDAP-Server läuft und wird fürs Anmelden benutzt. Hab ich ein Schema zu wenig eingebunden: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/yast2userconfig.schema Ich würde gerne meine Nutzer unter verschiedenen Kategorien ablegen (ou=lehrpersonen,ou=nutzer,dc=ksobwalden,dc=ch z.B. oder auch ou=maschinen,dc=ksobw ... für die Maschinenaccounts von Samba), um etwas Ordnung zu haben und das scheint mir mit dem Benutzermodul von Yast nicht möglich zu sein (SuSE 9.0). Oder liege ich da falsch? Gruss Beda

Ich weiß nicht, welche Objektklassen du mit Directory Administrator einrichten möchtest, aber die Fehlermeldung ist eindeutig. Du verletzt mit deiner Objektklassen-Kette die Vererbungslehre (nicht die von Mendel). Jedes Objekt darf nur einer einzigen strukturellen Objektklasse angehören, einschließlich der Objektklassen, die in direkter Vererbungslinie liegen. Zusätzliche auxiliar Objektklassen sind davon unberührt. Du versuchst also deinem Objekt zwei unterschiedliche strukturelle Objektklassen hinzuzufügen. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de

Hallo Beda, "Beda Szukics" writes:

Hallo Dieter

Dieter Kluenter writes:

...

...

Ich würde gerne meine Nutzer unter verschiedenen Kategorien ablegen (ou=lehrpersonen,ou=nutzer,dc=ksobwalden,dc=ch z.B. oder auch ou=maschinen,dc=ksobw ... für die Maschinenaccounts von Samba), um etwas Ordnung zu haben und das scheint mir mit dem Benutzermodul von Yast nicht möglich zu sein (SuSE 9.0). Oder liege ich da falsch? Gruss Beda Ich weiß nicht, welche Objektklassen du mit Directory Administrator einrichten möchtest, aber die Fehlermeldung ist eindeutig. Du verletzt mit deiner Objektklassen-Kette die Vererbungslehre (nicht die von Mendel). Jedes Objekt darf nur einer einzigen strukturellen Objektklasse angehören, einschließlich der Objektklassen, die in direkter Vererbungslinie liegen. Zusätzliche auxiliar Objektklassen sind davon unberührt.

Ich versuche die Benzutzerverwaltung von Directory Administrator zu nutzen, um die Daten verschiedenen Gruppen zuordnen zu können. Dazu habe ich mittels ldapadd neue organizationalUnits erzeugt, so dass das Gerüst jetzt so aussieht: dn: dc=ksobwalden,dc=ch [...] objectClass: inetOrgPerson Ich hätte hier halt gerne dn: uid=mus,ou=lehrpersonen,ou=nutzer,dc=ksobwalden,dc=ch.

...

Du versuchst also deinem Objekt zwei unterschiedliche strukturelle Objektklassen hinzuzufügen. [...]

Die Einträge sehen OK aus. Ich weiß nicht, wie Yast mit LDAP interagiert, ehrlich gesagt, ich habe keine Ahnung von Yast, nutze ich nur zwangsweise, um eine Basisinstallation vorzunehmen, daher kann ich dazu nichts sagen. Aber ich weiß nun, wo der Fehler in directory_administrator liegt, da muß wohl der Quellcode neu übersetzt werden. Directory Administrator versucht, die folgenden Gruppen Objektklassen anzulegen: organizationalPerson inetorgPerson account top posixAccount shadowAccount Die Objektklasse 'account' ist ebenfalls eine strukturelle Klasse und stammt nicht von person' ab, so daß durch account eine Verletzung der Regeln erfolgt. Keines der in account enthaltenen Attribute wird benötigt, so daß die Objektklasse aus dem Quellcode entfernt werden kann. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de

Hallo Dieter Dieter Kluenter writes:

Hi Beda,

Dieter Kluenter writes:

...

Hallo Beda,

"Beda Szukics" writes:

...

Hallo Dieter

Dieter Kluenter writes: [...] Die Objektklasse 'account' ist ebenfalls eine strukturelle Klasse und stammt nicht von person' ab, so daß durch account eine Verletzung der Regeln erfolgt. Keines der in account enthaltenen Attribute wird benötigt, so daß die Objektklasse aus dem Quellcode entfernt werden kann.

Der Autor von Directory Administrator hat mir ein vorläufiges workaround geschrieben um diese Objektklassen-Verletzung zu verhindern.

Im 'New user driud' die Frage nach ' Grant access to all Computers in network' deaktivieren und keinen Host angeben, dann wird die Objektklasse nicht geladen. Ich habe das gerade getestet und es funktioniert.

Das klappt jetzt bestens. Doch jetzt ist mir ein neues Problem aufgetaucht. Ich habe zwei Gruppen definiert. # lehrerIn, ksobwalden.ch dn: cn=lehrerIn,dc=ksobwalden,dc=ch cn: lehrerIn gidNumber: 500 objectClass: top objectClass: posixGroup objectClass: namedObject # student, ksobwalden.ch dn: cn=student,dc=ksobwalden,dc=ch cn: student gidNumber: 501 objectClass: top objectClass: posixGroup objectClass: namedObject student wird angezeigt (in DA und Yast), lehrerIn dagegen nicht (weder im einen noch im andern), ich kann sie aber auch nicht neu anlegen. Yast sagt: schon vorhanden, DA meint Object class violation. Hast Du ne Ahnung weshalb? Das verhalten ist mir aufgefallen, als ich meinen neuesten Testnutzer eintragen wollte, da erschien die Gruppe nicht mehr in der Auswahl. Ich bin ziemlich ratlos. Gruss Beda P.S. Ich bekomme auch mit dem GQ keine vernünftige Verbindung zum LDAP. Doch das kann daran liegen, dass ich ihn noch nicht richtig konfiguriert habe.

Hallo Dieter Dieter Kluenter writes:

Ich weiß nicht woher das Attribut 'namedObject' kommt, spasseshalber habe ich mit Directory Administrator ein Gruppe lehrerIn angelegt, diese wird nur mit objectclass posixGroup angelegt. So sieht das jetzt bei mir aus, einmal die Standardausgabe und dann die operationalen Attribute

,----[ Standard-Suche ] | dieter@marin, 522:~> ldapsearch -b ou=group,o=avci,c=de -s sub cn=lehrerin | [...] | dn: cn=lehrerIn,ou=Group,o=avci,c=de | objectClass: top | objectClass: posixGroup | cn: lehrerIn | gidNumber: 900 `---- ,----[ operationale Attribute ] | # lehrerIn, Group, avci, de | dn: cn=lehrerIn,ou=Group,o=avci,c=de | structuralObjectClass: posixGroup | entryUUID: b62a1456-1798-1028-9c66-9d481eb0205b | creatorsName: cn=admin,o=avci,c=de | createTimestamp: 20040331195240Z | entryCSN: 2004033119:52:40Z#0x0001#0#0000 | modifiersName: cn=admin,o=avci,c=de | modifyTimestamp: 20040331195240Z | subschemaSubentry: cn=Subschema | hasSubordinates: FALSE `----

Beende doch einmal die slapd Prozesse und hole mit slapcat -b <suffix> -l /tmp/mein.ldif den Inhalt deines Verzeichnisdienstes und sieh dir mal die Ausgabe an.

Hab ich gemacht. Mir scheint alles in Ordnung zu sein.

Anderseits, kann es sein, daß durch eine unsafte Beendigung die Datenbank defekt ist? Das könnte man mit db_recover behebe

Dann dürfte doch kein Auslesen mit slapcat möglich sein, oder? Wenn ich auf einen der Nutzer wechsle, die in der Gruppe lehrerIn sind, und dann "groups" aufrufe kommt: id: Es ist kein Name zur Gruppen-ID 500 zu finden 500 Offensichtlich wird zwar die ID 500 benutzt, aber lehrerIn bleibt aussen vor. In /var/log/messages finde ich: Apr 1 08:37:29 schola su: (to bd) beda on /dev/pts/3 Apr 1 08:37:29 schola slapd[1496]: conn=30 fd=23 ACCEPT from IP=192.168.1.3:32825 (IP=0.0.0.0:389) Apr 1 08:37:29 schola slapd[1722]: conn=30 op=1 BIND dn="" method=128 Apr 1 08:37:29 schola slapd[1722]: conn=30 op=1 RESULT tag=97 err=0 text= Apr 1 08:37:29 schola slapd[1735]: conn=30 op=2 SRCH base="dc=ksobwalden,dc=ch" scope=2 filter="(uid=bd)" Apr 1 08:37:29 schola slapd[1735]: <= bdb_equality_candidates: (uid) index_param failed (18) Apr 1 08:37:29 schola slapd[1735]: conn=30 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Apr 1 08:37:29 schola slapd[1722]: conn=30 op=3 SRCH base="dc=ksobwalden,dc=ch" scope=2 filter="(&(objectClass=posixGroup)(|(memberUid=bd)(uniqueMember=uid=bd,dc=ks obwalden,dc=ch)))" Apr 1 08:37:29 schola slapd[1722]: conn=30 op=3 SRCH attr=cn userPassword memberUid uniqueMember gidNumber Apr 1 08:37:29 schola slapd[1722]: <= bdb_equality_candidates: (memberUid) index_param failed (18) Apr 1 08:37:29 schola slapd[1722]: <= bdb_equality_candidates: (uniqueMember) index_param failed (18) Apr 1 08:37:29 schola slapd[1722]: conn=30 op=3 SEARCH RESULT tag=101 err=0 nentries=0 text= Apr 1 08:37:29 schola su: pam_unix2: session started for user bd, service su Apr 1 08:37:29 schola slapd[1735]: conn=29 op=3 UNBIND Apr 1 08:37:29 schola slapd[1735]: conn=29 fd=19 closed Apr 1 08:37:29 schola slapd[1496]: conn=16 fd=21 closed Apr 1 08:37:29 schola slapd[1496]: conn=31 fd=19 ACCEPT from IP=192.168.1.3:32826 (IP=0.0.0.0:389) Apr 1 08:37:29 schola slapd[1735]: conn=31 op=1 BIND dn="" method=128 Apr 1 08:37:29 schola slapd[1735]: conn=31 op=1 RESULT tag=97 err=0 text= Apr 1 08:37:29 schola slapd[1722]: conn=31 op=2 SRCH base="dc=ksobwalden,dc=ch" scope=2 filter="(&(objectClass=posixGroup)(gidNumber=500))" Apr 1 08:37:29 schola slapd[1722]: conn=31 op=2 SRCH attr=cn userPassword memberUid uniqueMember gidNumber Apr 1 08:37:29 schola slapd[1722]: <= bdb_equality_candidates: (gidNumber) index_param failed (18) Apr 1 08:37:29 schola slapd[1722]: conn=31 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= Könnte die Meldung "index_param failed" mir weiterhelfen? Ich habe mal mit google gesucht, dort leider kaum brauchbares gefunden. Gruss Beda

Hallo Dieter

...

Dann dürfte doch kein Auslesen mit slapcat möglich sein, oder?

ja, wenn der Datensatz defekt ist kann slapcat nichts auslesen.

Gut, dann bin ich wenigsten sicher, dass ich die Datenbank nicht versehentlich verschlissen habe.Schon mal beruhigend :-)

...

Apr 1 08:37:29 schola slapd[1722]: <= bdb_equality_candidates: (gidNumber) index_param failed (18) Apr 1 08:37:29 schola slapd[1722]: conn=31 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= Könnte die Meldung "index_param failed" mir weiterhelfen? Ich habe mal mit google gesucht, dort leider kaum brauchbares gefunden.

index_param failed besagt nur, daß für dieses Attribut kein Index erstellt wurde, daher nicht in im Index File gesucht, sondern der gesamte Datenbestand durchsucht wird.

OK Ebenfalls beruhigend. Ich werde mir wohl überlegen, welche Indices ich anzulegen habe.

Ehrlich gesagt, ich verstehe nicht ganz was du machen möchtest. Du hast einen oder mehrere Datensätze, die zwei Objekt Klassen enthalten die jeweils als strukturell deklariert sind (posixgroup und namedObject) wie das zustande gekommen ist vermag ich nicht zu deuten, aber slapd wird sich immer weigern, unstimmige Datensätze zur Kenntnis zu nehmen.

Ich habe diese Gruppen mit der YAST-Benutzerverwaltung erstellt (nachdem ich das Grundgerüst (dcObject Kantonsschule Obwalden, den Manager mit seinem Passwort) mit ldapadd eingegeben hatte). Ich habe zur Probe auch einige Nutzer mit Yast angelegt, die in dc=kosbwalden,dc=ch gelandet sind. Jetzt habe ich wieder mit ldapadd die ou-s für Nutzer, Nutzer-Lehrpersonen, Nutzer-Studierende und Maschinen angelegt und einen neuen Nutzer unter Nutzer-Studierende angelegt und seither wird die Gruppe lehrerIn nicht mehr gefungen. Kann es sein, das mein nicht sehr wählerischer Umgang mit den Mitteln dieses Problem verursacht hat?

Bereinige den Datensatz, du hast ja schon mit slapcat eine Datei erstellt, lösche alle Files im Datenbank-Verzeichnis, definiere in slapd.conf einige Indices und lade den korrigierten Datensatz mittels slapadd erneut.

Ich werde nochmals von vorne beginnen (da ich bis jetzt nur gepröbelt habe, ist das kein Problem, ich weiss jetzt wenigststen, worauf ich achten muss). Ich möchte nur verstehen, was etwa schieff gelaufen ist, um im "Ernstfall" nicht in die gleichen Fallen zu tappen.

Noch etwas zu deinem Group-System. Bedenke, du erstellst Posix-Groups, die eigentlich nur die Rechte im Dateisystem regeln, wenn du durch Gruppen weitere Selektionen steuern möchtest, ist ein anders Gruppenkonstrukt notwendig.

Ich möchte in erster Linie die Nutzerverwaltung von Samba mit LDAP realisieren. Da ich mit Pykota ein auf den ersten Blick brauchbares Mittel gefunden habe, die Druckerbenutzung zu regeln, bzw. abzurechnen und dieses ebenfalls mit LDAP umgehen kann, habe ich mir gedacht, ich versuchs mal. Ich habe übrigens Dein Buch gekauft und mach mich jetzt dahinter, es durchzuarbeiten. Vielleicht senkt sich damit meine Fragenhäufigkeit. :-) Gruss und Dank Beda