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
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!
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
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…
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