OPSI 3.3, OpenLDAP und debian 4 (etch)

[Anakim]

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

[j.schneider]

Bei der LDAP Integration gibt es anscheinend ein LDAP Schema Fehler. Sowohl der Client als auch Opsi-Configed generieren/melden den Fehler:

Es gibt zwei verschiedene Schema-Dateien (opsi.schema, opsi-standalone.schema), die je nach Einsatzszenario verwendet werden müssen.

[heuft_kdi]

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).

[heuft_kdi]

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:

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' )

Habe eben mal auf unseren Server nachgeschaut und dort steht im CORE Schema auch:

Code: Alles auswählen

:#attributetype ( 2.5.4.13 NAME 'description'

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:

Die Fehlermeldung bleibt erhalten:
(2) Jul 22 11:37:47 {'info': 'no structuralObjectClass operational attribute', 'desc': 'Internal (implementation specific) error'} (opsiconfd|529)

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.

[heuft_kdi]

Hallo,

Code: Alles auswählen

objectclass ( 1.3.6.1.4.1.23807.1.2.3
        NAME 'opsiClient'
        SUP opsiHost
        STRUCTURAL
        DESC 'Opsi client' )

Im Opsi 3.3 beiden Opsi-Schemen steht dort statt STRUCTURAL bereits AUXILIARY.

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.

Aber, Du schreibst doch:

Die Fehlermeldung bleibt erhalten:
(2) Jul 22 11:37:47 {'info': 'no structuralObjectClass operational attribute', 'desc': 'Internal (implementation specific) error'} (opsiconfd|529)

Ich denke mittlerweile, das mein Interpretation der obigen Fehlermeldung falsch ist. Eine alternative Interpreation ist:

Fehlermeldung.info = 'no structuralObjectClass operational attribute'
Fehlermeldung.desc = 'Internal (implementation specific) error'
Fehlermeldung.modul = (opsiconfd|529)

Dann ist 'desc' fehlinterpretiert.

So Interpretiere ich das inzwischen auch.