Moin,
hast du dir den Beitrag hier mal durchgelesen .. ein paar Tage erst her
viewtopic.php?f=7&t=73&sid=91a126cc21ae ... 406f90d49d
Oder hast du nicht 3.3. im Einsatz ?
Grüße
Anakim
OPSI 3.3, OpenLDAP und debian 4 (etch)
Re: OPSI 3.3, OpenLDAP und debian 4 (etch)
Mein Opsi 4.0.5.15 läuft derzeitig auf ESX 5.5 in der jeweils aktuellsten Version. (hoffe ich zumindestens )
- j.schneider
- uib-Team
- Beiträge: 1812
- Registriert: 29 Mai 2008, 15:14
Re: OPSI 3.3, OpenLDAP und debian 4 (etch)
Es gibt zwei verschiedene Schema-Dateien (opsi.schema, opsi-standalone.schema), die je nach Einsatzszenario verwendet werden müssen.fmat hat geschrieben: Bei der LDAP Integration gibt es anscheinend ein LDAP Schema Fehler. Sowohl der Client als auch Opsi-Configed generieren/melden den Fehler:
Re: OPSI 3.3, OpenLDAP und debian 4 (etch)
Also, in den alten Schemas waren die Beschreibung DESC öfter zu finden. Sind die im Schema einfach nicht drin oder fehlt einfach die Definition? Weil IMHO stammt DESC aus dem CORE Schema (Bin jetzt aber gerade bei LDAP nicht so 100% firm drin).
Mit freundlichen Gruß
Kai Dietrich
Kai Dietrich
Re: OPSI 3.3, OpenLDAP und debian 4 (etch)
Hast recht. Sage ja, bin in LDAP nicht mehr so drin. DESC ist ja eine LDAP Definition für ein Attribut.
Also, unter OPSI 3.1 sah das SCHEMA noch so aus:
Habe eben mal auf unseren Server nachgeschaut und dort steht im CORE Schema auch:
Daraus lässt sich in meinen Augen schließen, das description augenscheinlich direkt zu LDAP gehört und nicht separat definiert werden muss.
Aber, Du schreibst doch:
Also, unter OPSI 3.1 sah das SCHEMA noch so aus:
Code: Alles auswählen
objectclass ( 1.3.6.1.4.1.23807.1.2.1
NAME 'opsiHost'
SUP top
ABSTRACT
DESC 'Opsi host'
MUST ( cn )
MAY ( description $ opsiNotes $ opsiHostKey $ opsiPcpatchPassword $ opsiLastSeenTimestamp ) )
objectclass ( 1.3.6.1.4.1.23807.1.2.2
NAME 'opsiServer'
SUP opsiHost
STRUCTURAL
DESC 'Opsi server' )
objectclass ( 1.3.6.1.4.1.23807.1.2.3
NAME 'opsiClient'
SUP opsiHost
STRUCTURAL
DESC 'Opsi client' )
Code: Alles auswählen
:#attributetype ( 2.5.4.13 NAME 'description'
Aber, Du schreibst doch:
Daraus würde ich nun schließen (nachdem ich mal ein wenig nachgdacht habe, das bei Dir opsiClient nicht 'STRUCTURAL' ist. Wir haben bei uns den opsiClient damals auf 'AUXILIARY' geändert, da wir das Flag opsiClient an die Machine im SAMBA Baum hängen wollten.fmat hat geschrieben:Die Fehlermeldung bleibt erhalten:
(2) Jul 22 11:37:47 {'info': 'no structuralObjectClass operational attribute', 'desc': 'Internal (implementation specific) error'} (opsiconfd|529)
Mit freundlichen Gruß
Kai Dietrich
Kai Dietrich
Re: OPSI 3.3, OpenLDAP und debian 4 (etch)
Das Bedeutet dann, das UIB eigentlich das gemacht hatt, was wir bei uns auch machen (wir hatten das Schema damals selber verändert). Mann muss nun ein OPSI Client an einen Bestehenden Machinen Datensatz hängen (wie er z.B. für SAMBA auch benötigt wird). Wobei das, wenn wirklich zwei Schema Dateien dabei sind bei 'Standalone' in meinen Augen keinen Sinn macht, weil ich 'Standalone' als Einzelserver interpretieren würde.fmat hat geschrieben:Hallo,
Im Opsi 3.3 beiden Opsi-Schemen steht dort statt STRUCTURAL bereits AUXILIARY.heuft_kdi hat geschrieben:Code: Alles auswählen
objectclass ( 1.3.6.1.4.1.23807.1.2.3 NAME 'opsiClient' SUP opsiHost STRUCTURAL DESC 'Opsi client' )
So Interpretiere ich das inzwischen auch.fmat hat geschrieben:Ich denke mittlerweile, das mein Interpretation der obigen Fehlermeldung falsch ist. Eine alternative Interpreation ist:heuft_kdi hat geschrieben: Aber, Du schreibst doch:fmat hat geschrieben:Die Fehlermeldung bleibt erhalten:
(2) Jul 22 11:37:47 {'info': 'no structuralObjectClass operational attribute', 'desc': 'Internal (implementation specific) error'} (opsiconfd|529)
Fehlermeldung.info = 'no structuralObjectClass operational attribute'
Fehlermeldung.desc = 'Internal (implementation specific) error'
Fehlermeldung.modul = (opsiconfd|529)
Dann ist 'desc' fehlinterpretiert.
Mit freundlichen Gruß
Kai Dietrich
Kai Dietrich