Bug 21711 - Beim Anlegen eines Rechners wird dieser nicht in dessen primäre Gruppe als uniqueMember/memberuid aufgenommen
Summary: Beim Anlegen eines Rechners wird dieser nicht in dessen primäre Gruppe als un...
Status: CLOSED FIXED
Alias: None
Product: UCS
Classification: Unclassified
Component: UMC - Computers
Version: UCS 2.4
Hardware: Other Linux
: P5 normal
Target Milestone: UCS 2.4-2
Assignee: Sönke Schwardt-Krummrich
QA Contact: Felix Botner
URL:
Keywords:
: 21433 (view as bug list)
Depends on:
Blocks: 21746
  Show dependency treegraph
 
Reported: 2011-03-03 15:00 CET by Felix Botner
Modified: 2011-04-04 15:46 CEST (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Customer ID:
Max CVSS v3 score:


Attachments
Patch zum Fixen von Bug 21711 (4.60 KB, patch)
2011-03-08 15:00 CET, Sönke Schwardt-Krummrich
Details | Diff
Skript zum Korrigieren fehlender Gruppenmitgliedschaften (1.53 KB, text/plain)
2011-03-08 15:02 CET, Sönke Schwardt-Krummrich
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Botner univentionstaff 2011-03-03 15:00:55 CET
Wenn man ein Rechnerobjekt (slave) über den udm angelegt, wird zwar die Primäre Gruppe gesetzt, aber in dieser Gruppe selbst wird der Rechner nicht als Mitglied aufgenommen.

-> udm computers/domaincontroller_slave create --set name=test-slave
Object created: cn=test-slave,dc=univention,dc=qa

-> udm computers/domaincontroller_slave list --filter=name=test-slave
name=test-slave
DN: cn=test-slave,dc=univention,dc=qa
ARG: None
  domain: None
  ip: None
  network: None
  service: None
  reinstalloption: None
  unixhome: /dev/null
  instprofile: None
  shell: /bin/bash
  description: None
  inventoryNumber: None
  mac: None
  reinstalltext: None
  primaryGroup: cn=DC Slave Hosts,cn=groups,dc=univention,dc=qa
  password: None
  reinstall: None
  serverRole: slave
  name: test-slave
  dhcpEntryZone: dc=univention,dc=qa 10.200.7.150

-> ldapsearch -x cn=DC\ Slave\ Hosts -LLL uniqueMember
dn: cn=DC Slave Hosts,cn=groups,dc=univention,dc=qa
uniqueMember: cn=DC Backup Hosts,cn=groups,dc=univention,dc=qa
uniqueMember: uid=join-backup,cn=users,dc=univention,dc=qa
uniqueMember: uid=join-slave,cn=users,dc=univention,dc=qa

Das hat bei Bug #21433 zu Problemen geführt, da erwartet wurde, dass die Slaves automatisch in der Gruppe "DC Slave Hosts" landen (als uniqueMember)

So verhält es sich mit 2.4-0 und 2.4-1. 

Mit 2.3-0 jedoch wurden die Gruppen noch aktualisiert.

-> udm computers/domaincontroller_slave create --set name=test-slave

-> udm computers/domaincontroller_slave list --filter=name=test-slave
name=test-slave
DN: cn=test-slave,dc=univention,dc=qa
ARG: None
  domain: None
  ip: None
  network: None
  service: None
  unixhome: /dev/null
  instprofile: None
  shell: /bin/bash
  description: None
  inventoryNumber: None
  mac: None
  reinstalltext: None
  groups: cn=DC Slave Hosts,cn=groups,dc=univention,dc=qa
  primaryGroup: cn=DC Slave Hosts,cn=groups,dc=univention,dc=qa
  password: None
  reinstall: None
  serverRole: slave
  name: test-slave
  dhcpEntryZone: dc=univention,dc=qa 10.200.7.160

-> ldapsearch -x cn=DC\ Slave\ Hosts -LLL uniqueMember
dn: cn=DC Slave Hosts,cn=groups,dc=univention,dc=qa
uniqueMember: uid=join-backup,cn=users,dc=univention,dc=qa
uniqueMember: uid=join-slave,cn=users,dc=univention,dc=qa
uniqueMember: cn=test-slave,dc=univention,dc=qa
uniqueMember: cn=DC Backup Hosts,cn=groups,dc=univention,dc=qa

Für Benutzerobjekten verhält es sich in 2.3-0 bis 2.4-1 korrekt, d.h. die Benutzer werden auch in ihrer primären Gruppen als Mitglieder aufgenommen.
Comment 1 Felix Botner univentionstaff 2011-03-03 15:22:11 CET
*** Bug 21433 has been marked as a duplicate of this bug. ***
Comment 2 Sönke Schwardt-Krummrich univentionstaff 2011-03-08 14:43:20 CET
Im Zuge von Bug #19128 wurde self.save() in der open()-Methode der einzelnen
Rechnermodule aufgerufen. Dadurch wurde die aktuelle/neue primaryGroup nach
self.oldinfo geschrieben, so dass sich aus der Sicht des UDM-Moduls während
eines create() nichts geändert hat.
Diese Änderung wurde wieder zurückgenommen.

In der Klasse simpleComputer wird jetzt in _ldap_post_remove() nicht mehr jedes
Gruppenobjekt geöffnet, sondern das Rechner-Objekt über
grpobj.fast_member_remove() aus Primary Group und sonstigen Gruppen entfernt.

@QA: bitte genau prüfen, ob uniqueMember- und memberUid-Einträge für Gruppen
und die primäre Gruppe beim 
- Anlegen eines Rechners
- Ändern eines Rechner (sowohl primäre Grp als auch sonstige Grp)
- Löschen eines Rechners
korrekt aktualisiert werden.

Da in 2.4-0 und 2.4-1 Rechnerobjekte ohne korrekte Gruppenmitgliedschaft für
die primäre Gruppe angelegt worden sein können, wird im Paket 
univention-directory-manager-tools das Skript fix_primary_group_membership
mitgeliefert, welches in univention-ldap-server.postinst automatisch beim
Update auf 2.4-2 auf dem DC Master aufgerufen wird.
Den Aufruf von fix_primary_group_membership kann über das Setzen der
UCR-Variable update/fix/computer/primarygroupmembership=false deaktiviert 
werden.

Ein Testdurchlauf mit ucs-test war auf meinem Einwicklungssystem erfolgreich.

univention-ldap (7.0.18-1)
univention-directory-manager-modules (6.0.110-1)
Comment 3 Sönke Schwardt-Krummrich univentionstaff 2011-03-08 15:00:11 CET
Created attachment 3094 [details]
Patch zum Fixen von Bug 21711

TEST:
patch --dry-run -p5 -d /usr/share/pyshared/ < /path/to/bug21711-system.patch
EINSPIELEN:
patch -p5 -d /usr/share/pyshared/ < /path/to/bug21711-system.patch


Anschließend UDM-CLI neustarten:
pkill -f "/usr/share/univention-directory-manager-tools/univention-cli-server"
Comment 4 Sönke Schwardt-Krummrich univentionstaff 2011-03-08 15:02:08 CET
Created attachment 3095 [details]
Skript zum Korrigieren fehlender Gruppenmitgliedschaften

Das Skript bug21711-fix.sh wird auch in 2.4-2 als fix_primary_group_membership enthalten sein. Ohne Parameter macht es einen Testlauf. Um die Änderungen durchzuführen, muss der Parameter "-f" angegeben werden.
Comment 5 Jascha Geerds univentionstaff 2011-03-16 14:29:26 CET
1.) Auf einem 2.4-1 Master habe ich update/fix/computer/primarygroupmembership per UCR auf "false" gesetzt. Anschließend habe ich einen 2.4-2 Slave gejoint und dann den Master auch auf 2.4-2 gebracht. Nach dem Update war der Slave in die primäre Grupep aufgenommen. Es scheint so, als wäre der fix trotz der UCR-Variable ausgeführt worden.


2.) Wenn ich per USS den Rechnernamen von z.B: qaslave in qaslave-neu ändere, dann wird die uniqueMember/memberUid in den Gruppen nicht geändert. Es steht dort weiterhin der alte Name - was dazu führt, dass der Rechner gar nicht in dieser Gruppe ist.

3.) Füge ich den Rechner zu einer neuen Gruppe hinzu und lösche ihn anschließend wieder daraus, wird dies korrekt ausgeführt.

4.) Lösche ich den Rechner, wird er korrekt aus allen Gruppen entfernt. Allerdings natürlich auch nur, sofern in den Gruppen noch alles aktuell war. In den Gruppen, wo alte Daten (durch Punkt 2) standen, hat sich natürlich nichts geändert.


Wenn logs o.ä. gewünscht sind, bitte Bescheid sagen.
Comment 6 Sönke Schwardt-Krummrich univentionstaff 2011-03-17 17:46:45 CET
(In reply to comment #5)
> 1.) Auf einem 2.4-1 Master habe ich update/fix/computer/primarygroupmembership
> per UCR auf "false" gesetzt. Anschließend habe ich einen 2.4-2 Slave gejoint
> und dann den Master auch auf 2.4-2 gebracht. Nach dem Update war der Slave in
> die primäre Grupep aufgenommen. Es scheint so, als wäre der fix trotz der
> UCR-Variable ausgeführt worden.

Sollte jetzt gefixt sein. Bitte das Skript nochmal testen, da es in Bug 21782 angepasst wurde.
 
> 2.) Wenn ich per USS den Rechnernamen von z.B: qaslave in qaslave-neu ändere,
> dann wird die uniqueMember/memberUid in den Gruppen nicht geändert. Es steht
> dort weiterhin der alte Name - was dazu führt, dass der Rechner gar nicht in
> dieser Gruppe ist.

Ausgelagert in Bug 21882

> 3.) Füge ich den Rechner zu einer neuen Gruppe hinzu und lösche ihn
> anschließend wieder daraus, wird dies korrekt ausgeführt.
> 
> 4.) Lösche ich den Rechner, wird er korrekt aus allen Gruppen entfernt.
> Allerdings natürlich auch nur, sofern in den Gruppen noch alles aktuell war. 
> In den Gruppen, wo alte Daten (durch Punkt 2) standen, hat sich natürlich 
> nichts geändert.

Bitte Punkte 3) und 4) nochmal ohne Umbenennen des Rechners testen.
Comment 7 Felix Botner univentionstaff 2011-03-28 13:12:02 CEST
Bei Windows Rechner klappt es noch nicht ganz.

-> udm computers/windows create --set name=win2
-> ldapsearch -x cn=win2 gidNumber -LLL
dn: cn=win2,dc=univention,dc=qa
gidNumber: 1005

-> ldapsearch -x '(&(gidNumber=1005)(objectClass=univentionGroup))' \
   memberuid uniqueMember  -LLL
dn: cn=Windows Hosts,cn=groups,dc=univention,dc=qa
uniqueMember: cn=DC Backup Hosts,cn=groups,dc=univention,dc=qa
uniqueMember: cn=win2,dc=univention,dc=qa

Hier wird nur uniqueMember gesetzt?


(1) Rechner anlegen - FAILED (windows, sonst OK)

-> udm computers/domaincontroller_slave create --set name=slave1

-> ldapsearch -x cn=slave1 gidNumber -LLL
dn: cn=slave1,dc=univention,dc=qa
gidNumber: 5006

-> ldapsearch -x '(&(gidNumber=5006)(objectClass=univentionGroup))' \
   memberuid uniqueMember  -LLL
dn: cn=DC Slave Hosts,cn=groups,dc=univention,dc=qa
uniqueMember: uid=join-backup,cn=users,dc=univention,dc=qa
uniqueMember: uid=join-slave,cn=users,dc=univention,dc=qa
uniqueMember: cn=DC Backup Hosts,cn=groups,dc=univention,dc=qa
uniqueMember: cn=slave1,dc=univention,dc=qa
memberUid: join-backup
memberUid: join-slave
memberUid: slave1$

-> udm computers/memberserver create --set name=member1

-> ldapsearch -x cn=member1 gidNumber -LLL
dn: cn=member1,dc=univention,dc=qa
gidNumber: 5007

-> ldapsearch -x '(&(gidNumber=5007)(objectClass=univentionGroup))' \
   memberuid uniqueMember  -LLL
dn: cn=Computers,cn=groups,dc=univention,dc=qa
uniqueMember: cn=DC Backup Hosts,cn=groups,dc=univention,dc=qa
uniqueMember: cn=member1,dc=univention,dc=qa
memberUid: member1$

... master, backup, mobile, managed, ...

(2) Rechner umbenennen - ???

siehe Bug #21882 und #21878

(3) Rechner zu Gruppen hinzufügen/entfernen - OK

-> udm groups/group modify --dn "cn=Users,cn=groups,dc=univention,dc=qa" \
   --append hosts=cn=slave1,dc=univention,dc=qa

-> ldapsearch -x '(&(gidNumber=5011)(objectClass=univentionGroup))' \
   memberuid uniqueMember  -LLL
dn: cn=Users,cn=groups,dc=univention,dc=qa
uniqueMember: cn=slave1,dc=univention,dc=qa
memberUid: slave1$

-> udm groups/group modify --dn "cn=Users,cn=groups,dc=univention,dc=qa" 
   --remove hosts=cn=slave1,dc=univention,dc=qa

-> ldapsearch -x '(&(gidNumber=5011)(objectClass=univentionGroup))' \
   memberuid uniqueMember  -LLL
dn: cn=Users,cn=groups,dc=univention,dc=qa

(4) Rechner löschen - OK

-> udm computers/domaincontroller_slave remove \
   --dn cn=slave1,dc=univention,dc=qa

-> ldapsearch -x '(&(gidNumber=5006)(objectClass=univentionGroup))' \
   memberuid uniqueMember  -LLL
dn: cn=DC Slave Hosts,cn=groups,dc=univention,dc=qa
uniqueMember: uid=join-backup,cn=users,dc=univention,dc=qa
uniqueMember: uid=join-slave,cn=users,dc=univention,dc=qa
uniqueMember: cn=DC Backup Hosts,cn=groups,dc=univention,dc=qa
memberUid: join-backup
memberUid: join-slave

-> ldapsearch -x cn=Computers memberuid uniqueMember  -LLL
dn: cn=Computers,cn=groups,dc=univention,dc=qa
uniqueMember: cn=DC Backup Hosts,cn=groups,dc=univention,dc=qa
uniqueMember: cn=member1,dc=univention,dc=qa
uniqueMember: cn=mac1,dc=univention,dc=qa
uniqueMember: cn=man1,dc=univention,dc=qa
uniqueMember: cn=mo1,dc=univention,dc=qa
memberUid: member1$
memberUid: mac1$
memberUid: man1$
memberUid: mo1$

-> udm computers/macos remove --dn cn=mac1,dc=univention,dc=qa
Object removed: cn=mac1,dc=univention,dc=qa

-> udm computers/managedclient remove --dn cn=man1,dc=univention,dc=qa
Object removed: cn=man1,dc=univention,dc=qa

-> udm computers/mobileclient remove --dn cn=mo1,dc=univention,dc=qa
Object removed: cn=mo1,dc=univention,dc=qa

-> ldapsearch -x cn=Computers memberuid uniqueMember  -LLL
dn: cn=Computers,cn=groups,dc=univention,dc=qa
uniqueMember: cn=DC Backup Hosts,cn=groups,dc=univention,dc=qa
uniqueMember: cn=member1,dc=univention,dc=qa
memberUid: member1$

QA TODO: Skripte testen
Comment 8 Sönke Schwardt-Krummrich univentionstaff 2011-03-28 18:48:30 CEST
Handling der primären Gruppe bei computers/windows korrigiert. Paket baut gerade.
Comment 9 Felix Botner univentionstaff 2011-03-29 11:27:57 CEST
OK, Windows Rechner werden nun auch mit uniqueMember und memberuid an der primären Gruppe gesetzt.

Das "fix" Script läuft beim Update (sofern nicht vorher )update/fix/computer/primarygroupmembership auf no gesetzt wurde) und korrigiert die Einträge.

Das Script kommt auch mit langen DN's zurecht:

-> fix_primary_group_membership  -f -c
*** cn=myslave,cn=myslaves,cn=looooooooooooooooooooooooooooooooooooooooooooooooooooongercn,cn=loooooooooooooooooooooooooooooooooooooooooooooooongcn,cn=dc,cn=computers,dc=univention,dc=qa is missing in group with gidNumber 5006 (cn=DC Slave Hosts,cn=groups,dc=univention,dc=qa)
modifying entry "cn=DC Slave Hosts,cn=groups,dc=univention,dc=qa"

*** myslave$ is missing in group with gidNumber 5006 (cn=DC Slave Hosts,cn=groups,dc=univention,dc=qa)
modifying entry "cn=DC Slave Hosts,cn=groups,dc=univention,dc=qa"

-> ldapsearch -x cn="DC Slave Hosts" uniqueMember memberUid -LLL
dn: cn=DC Slave Hosts,cn=groups,dc=univention,dc=qa
uniqueMember: uid=join-backup,cn=users,dc=univention,dc=qa
uniqueMember: uid=join-slave,cn=users,dc=univention,dc=qa
uniqueMember: cn=DC Backup Hosts,cn=groups,dc=univention,dc=qa
uniqueMember: cn=myslave,cn=myslaves,cn=looooooooooooooooooooooooooooooooooooo
 oooooooooooooooongercn,cn=loooooooooooooooooooooooooooooooooooooooooooooooong
 cn,cn=dc,cn=computers,dc=univention,dc=qa
memberUid: join-backup
memberUid: join-slave
memberUid: qasla1$
memberUid: qasla2$
memberUid: qaslave-test$
memberUid: test1$
memberUid: myslave$

Geschwindigkeit ist ok.

Changelog Eintrag vorhanden.
Comment 10 Sönke Schwardt-Krummrich univentionstaff 2011-04-04 15:46:41 CEST
UCS 2.4-2 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer
neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden:
"Clone This Bug".