Bug 21746 - 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 Test
Classification: Unclassified
Component: UDM
Version: unspecified
Hardware: Other Linux
: P5 normal
Target Milestone: ---
Assignee: Sönke Schwardt-Krummrich
QA Contact:
URL:
Keywords:
Depends on: 21711
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-07 15:51 CET by Sönke Schwardt-Krummrich
Modified: 2023-03-25 06:44 CET (History)
0 users

See Also:
What kind of report is it?: Development Internal
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

Note You need to log in before you can comment on or make changes to this bug.
Description Sönke Schwardt-Krummrich univentionstaff 2011-03-07 15:51:15 CET
Zum Testen der primären Gruppenmitgliedschaften sollte es ein Testskript geben.

+++ This bug was initially created as a clone of Bug #21711 +++

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 Sönke Schwardt-Krummrich univentionstaff 2011-03-07 15:59:39 CET
scripts-66_udm-computers/50_check_primary_groups wurde hinzugefügt, welches uniqueMember und memberUid-Einträge an der primären Gruppe überprüft.
Comment 2 Stefan Gohmann univentionstaff 2016-10-12 07:48:17 CEST
For this bug is no separate QA needed.