creatorsName empty

UCS - Univention Corporate Server
#1

Hallo,

bei uns intern schlägt der join eines Systems fehl. Es wird ein failed.ldif erzeugt mit rund ~100 Einträgen:

# Error: Invalid syntax (21), additional info: creatorsName: value #0 invalid per syntax dn: cn=dns,dc=siedl,dc=local changetype: add entryCSN: 20130411120217.430003Z#000000#000#000000 description: Containing all DNS Objects as per default Setti ngs objectClass: organizationalRole objectClass: univentionObject creatorsName: entryUUID: 2909b050-abcd-1030-885f-37845adf7494 modifyTimestamp: 20130411120217Z modifiersName: cn=admin,dc=siedl,dc=local createTimestamp: 20111125162040Z structuralObjectClass: organizationalRole univentionObjectType: container/cn cn: dns

Wie zu sehen ist, haben diese alle keinen “creatorsName:”, weitere 700 Einträge besitzen aber einen.

Am mastersrv sieht ein slapcat vom Eintrag wie folgt aus:

dn: cn=dns,dc=siedl,dc=local description: Containing all DNS Objects as per default Settings creatorsName: entryUUID: 2909b050-abcd-1030-885f-37845adf7494 createTimestamp: 20111125162040Z structuralObjectClass: organizationalRole cn: dns objectClass: organizationalRole objectClass: univentionObject univentionObjectType: container/cn entryCSN: 20130411120217.430003Z#000000#000#000000 modifiersName: cn=admin,dc=siedl,dc=local modifyTimestamp: 20130411120217Z

Wie zu sehen ist, wird am Weg zum listener der Zeilenumbruch nach creatorsName gelöscht, warum?

Bug? cn=dns,dc=siedl,dc=local
description

#2

Habe am UCSMaster nun ein slapcat gemacht, via script alle creatorsName befüllt, slapadd gemacht, und den Backup erneut gejoint.

Der join ist nun durchgelaufen!

#3

Hallo,

wir habe das bereits beobachtet, konnten aber bisher nie nachvollziehen oder reproduzieren wie es dazu kommt.
Generell sollte creatorsName auf dem DC-Master natürlich nie leer sein, können Sie evtl. nachvollziehen wie es dazu gekommen ist? Evtl. haben Sie in der Vergangenheit mal ein ldif per slapadd zurück gesichert o.ä.?

Mit freundlichen Grüßen
Janis Meybohm

#4 
root@mastersrv:/var/univention-backup# zgrep "^creatorsName:$" *

liefert:

ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: ldap-backup_20130411.ldif.gz:creatorsName: .. ... ..

An diesem Datum haben wir alle Server von UCS2.4 auf UCS3.1-1 hochgezogen…
Scheint also durch das Update entstanden zu sein…

Seit 11.4.2003 besteht also das Problem…

#5

Hallo,

ich kann die Situation in keiner meiner aktualisierten Umgebungen beobachten. Gab es beim Update des slapd evtl. Probleme (die updater.log sollte hier Hinweise liefern)?
Evtl. lässt sich auch anhand des während des Updates angelegten LDAP-Backup nachvollziehen ob die Informationen während im slapd Update-Prozess entfernt wurden, ich nehme an Sie haben anhand der LDAP-Backups auch verifiziert dass die Attribute vor dem 11.04. tatsächlich vorhanden waren?

Mit freundlichen Grüßen
Janis Meybohm

Mastodon