Univention Bugzilla – Bug 20992
UDM: in Thin Client Richtlinie werden keine ererbten Werte angezeigt, Änderungen schlagen teilweise fehl
Last modified: 2011-04-04 15:48:13 CEST
Nachstellen: - in UDM einen Thin Client anlegen - am Container eine "Thin Client Konfiguration"-Richtlinie mit Werten z.B. für File-, Auth- und UCS-Terminalserver erstellen - den Thin Client wieder öffnen und auf den "Thin Client Konfiguration"-Tab wechseln, die Werte werden dort nicht angezeigt Im Kundenszenario (Ticket 2010091510016321) kommt es zusätzlich zu dem Problem, dass eine Einstellung für den Windows Terminalserver (hier ist nichts "ererbt") nicht als neue Richtlinie übernommen wird, das kann ich bisher unter 2.4 nicht nachstellen.
Das Problem betrifft auch das nicht-Multivalue-Feld "Windows Domäne", auch hier wird der ererbte Inhalt nicht angezeigt.
Gleiches Phänomen bei folgenden Richtlinien: Autostart Univention Configuration Registry Wird die Richtlinie am Objekt dabei nochmal explizit ausgewählt wird zudem fälschlicher Weise eine Kopie der Richtlinie erzeugt und unter dem Namen des Objektes gespeichert (also, Verhalten wie beim Ändern einer bereits zugeordneten Richtlinie am Objekt. Das ganze lässt sich durch Wiederholung weiter treiben mit den bekannten Namensergänzungen $object_uv_0 $object_uc_1, ...)
Der Fehler konnte auf einem 2.4-1er System reproduziert werden, das Problem scheint mit der Installation der Thin Client Services zusammenzuhängen: (1) Installation von Thin Client Services: univention-config-registry set repository/online/component/tcs=yes apt-get update univention-install univention-thin-client-schema univention-install univention-thin-client (2) Anlegen eines Thin-Clients mit Richtilinie: eval "$(ucr shell)" # create backup, slave computer udm computers/domaincontroller_backup create --set name=qabackup udm computers/domaincontroller_slave create --set name=qaslave # policies for thin clients udm policies/thinclient create --position \ "cn=thinclient,cn=policies,$ldap_base" \ --set name="thinclient1" \ --set fileServer="qamaster.$domainname" \ --set fileServer="slave.$domainname" \ --set linuxTerminalServer="qaslave.$domainname" \ --set windowsDomain="UNIVENTION" # link policies udm container/cn modify --dn "cn=computers,$ldap_base" \ --policy-reference "cn=thinclient1,cn=thinclient,cn=policies,$ldap_base" # create thin clients udm computers/thinclient create --position "cn=computers,$ldap_base" \ --set name=thinclient1 \ --set mac=52:54:00:9b:e5:01 \ --set network="cn=default,cn=networks,$ldap_base" (3) Im Web-UDM werden ist der Tab [Thin-Client-Konfiguration] leer, und univention-policy-results sagt über den Thin-Client: [...] univentionDesktopServer="qaslave.univention.qa" univentionWindowsDomain="UNIVENTION" univentionFileServer="qamaster.univention.qa" univentionFileServer="slave.univention.qa"
Das erste Problem mit Thin-Client-Richtlinien konnte soweit in univention-thin-client (6.0.3-1) behoben werden. Der Fehler lag an einer falschen Zuweisung des Moduls policies/thinclient_user.py zu der entsprechenden LDAP-Objektklasse: policy_oc='univentionPolicyThinClient' anstelle von: policy_oc='univentionPolicyThinClientUser'
(In reply to comment #2) > Gleiches Phänomen bei folgenden Richtlinien: > [...] > Univention Configuration Registry Stimmt, das Verhalten konnte nachvollzogen werden. Der Fehler scheint genau dann aufzutreten, wenn die gegebene Policy nicht irgendwo unter cn=policies,$ldap_base (oder Subverzeichnis) liegt: #!/bin/bash eval "$(ucr shell)" policy_base=( "$ldap_base" "cn=policies,$ldap_base" "cn=myPolicies,cn=policies,$ldap_base" ) # create containers udm container/cn create --set name=myPolicies \ --position "cn=policies,$ldap_base" # create containers, policies, and thin clients for i in {0..2}; do udm policies/registry create --set name="policyUcr$i" \ --position "${policy_base[i]}" \ --set registry="test/variable$i=value$i" udm container/cn create --set name=myComputers$i \ --position "cn=computers,$ldap_base" udm container/cn modify --dn "cn=myComputers$i,cn=computers,$ldap_base" \ --policy-reference "cn=policyUcr$i,${policy_base[i]}" udm computers/thinclient create \ --position "cn=myComputers$i,cn=computers,$ldap_base" \ --set name=thinclient$i --set mac=52:54:00:9b:e5:0$i \ --set network="cn=default,cn=networks,$ldap_base" done
(In reply to comment #2) > Gleiches Phänomen bei folgenden Richtlinien: > [...] > Univention Configuration Registry Der Fehler ist nachvollziehbar auf einem nackten 2.4-1er System (also ohne TCS).
(In reply to comment #2) > Gleiches Phänomen bei folgenden Richtlinien: > [...] > Univention Configuration Registry Dieses Problem wurde in univention-directory-manager (8.0.66-1) behoben. Das Problem trat auf, da nur Policy-Objekte gesucht wurden, die in einem registrierten Container (also Container in "dc=default containers,cn=univention,...") existierten. Das neue Verhalten berücksichtigt alle existierende Policy-Objekte. Mit dieser Änderung werde jetzt generell alle existierende Policy-Objekte (des entsprechenden Typs) im Drop-Down Menu oben links des Policy-Tabs angezeigt. Zuvor waren Objekte in nicht-registrierten Containern nicht sichtbar. In der Bearbeitung dieses Bugs vielen desweiteren falsche Werte für die Variable 'policy_oc' in den Modulen autostart.py und share_userquota.py auf. Welche Seiteneffekte diese Fehler hatten, lässt sich nicht genau sagen. In jedem Fall sind die Werte nun richtig gesetzt in Paket univention-directory-manager-modules (6.0.101-1).
(In reply to comment #7) > Dieses Problem wurde in univention-directory-manager (8.0.66-1) behoben. Das > Problem trat auf, da nur Policy-Objekte gesucht wurden, die in einem > registrierten Container (also Container in "dc=default > containers,cn=univention,...") existierten. Das neue Verhalten berücksichtigt > alle existierende Policy-Objekte. Für die QA: Bitte das neue Verhalten auch in einer größeren Umgebung testen, damit es nicht zu unerwarteten bottlenecks kommt bspw. in UCS@school-Umgebungen.
(In reply to comment #2) > Gleiches Phänomen bei folgenden Richtlinien: > > Autostart > [...] > Wird die Richtlinie am Objekt dabei nochmal explizit ausgewählt wird zudem > fälschlicher Weise eine Kopie der Richtlinie erzeugt und unter dem Namen des > Objektes gespeichert (also, Verhalten wie beim Ändern einer bereits > zugeordneten Richtlinie am Objekt. Das ganze lässt sich durch Wiederholung > weiter treiben mit den bekannten Namensergänzungen $object_uv_0 $object_uc_1, > ...) Der Fehler konnte wie folgt auf einem 2.4-1er System mit installiertem TCS nachgestellt werden: (1) Anlegen eines neuen Thinclients mit ererbten Richtlinien #!/bin/bash eval "$(ucr shell)" # create backup, slave computer udm computers/domaincontroller_backup create --set name=qabackup udm computers/domaincontroller_slave create --set name=qaslave # create autostart options for i in 1 2; do udm settings/thinclient_autostart create --set name=autostart$i \ --position "$ldap_base" \ --set command=autostart$i done # create policies udm policies/thinclient create --set name="myThinclientPol" \ --position "cn=policies,$ldap_base" \ --set fileServer="qamaster.$domainname" \ --set fileServer="slave.$domainname" \ --set linuxTerminalServer="qaslave.$domainname" \ --set windowsDomain="UNIVENTION" udm policies/autostart create --set name="myAutostartPol" \ --position "cn=policies,$ldap_base" \ --set autostartScript="autostart1" # link policies udm container/cn modify --dn "cn=computers,$ldap_base" \ --policy-reference "cn=myThinclientPol,cn=policies,$ldap_base" \ --policy-reference "cn=myAutostartPol,cn=policies,$ldap_base" # create thin client udm computers/thinclient create --set name=myThinclient \ --position "cn=computers,$ldap_base" \ --set mac=52:54:00:9b:e5:01 \ --set network="cn=default,cn=networks,$ldap_base" (2) Bug kann nachvollzogen werden im Web-UDM: Im Thinclient-Objekt, Reiter "[Autostart]" auswählen; die Autostart-Richtlinie "autostart1" sollte vererbt sein, es wird aber "Windows Terminal Server (RDP)" angezeigt; die Ausgabe von univention-policy-result zeigt: [...] univentionAutoStartScript="autostart1" [...] Nun als neue Konfiguration "univention.qa:/policies/myAutostartPol" auswählen, bestätigen mit ok; anschließend wieder den thinclient und Reiter "[Autostart]" auswählen; die Konfiguration wieder auf "ererbt" setzen; bestätigen mit ok; wieder thinclient, "[Autostart]" auswählen, wo jetzt die neue Richtline "univention.qa:/policies/thinclient/myThinclient" angelegt wurde; durch wiederholtes setzen auf "ererbt" werden abermals neue RL angelegt. (3) Nach einem Update der Pakete (Scopes ucs2.4-2 und uts), die bereits geändert wurden, und erneuter Anmeldung am UDM tritt der Fehler nicht mehr auf: vim /etc/apt/sources.list ... apt-get update apt-get install \ python-univention-directory-manager \ univention-directory-manager \ univention-thin-client Der Fehler konnte soweit noch nicht reproduziert werden für UCR- und ThinCient-Richtlinien.
(In reply to comment #9) > [...] > apt-get install \ > python-univention-directory-manager \ > univention-directory-manager \ > univention-thin-client > [...] Um auch den ersten Fehlerfall abzudecken, müssen folgende Pakete installiert werden: apt-get install \ python-univention-directory-manager \ univention-directory-manager \ univention-thin-client \ python-univention-directory-manager-thin-client
*** Bug 20944 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > Nachstellen: > > - in UDM einen Thin Client anlegen > - am Container eine "Thin Client Konfiguration"-Richtlinie mit Werten z.B. für > File-, Auth- und UCS-Terminalserver erstellen > - den Thin Client wieder öffnen und auf den "Thin Client Konfiguration"-Tab > wechseln, die Werte werden dort nicht angezeigt Das Problem wird in Bug #21681 gelöst. (In reply to comment #2) > Gleiches Phänomen bei folgenden Richtlinien: > > Autostart > Univention Configuration Registry Die Probleme konnten mit 2.4-1 reproduziert werden. Mit UCS 2.4-2 nicht mehr. Es werden nur Index-Suchen durchgeführt.
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".