Software, Richtlinien und Co. für verschiedene OU's

Linux Clients
#1

Hallo,

in unserer Schule steht ein UCS Master der momentan zwei DC’s versorgt (Grundschule und Gesamtschule) sowie einen weiteren DC beim Trägerverein. Später kommen noch zwei Grundschulen mit je eigenen DC’s dazu. Für alle Schulen ist es vorgesehen die ManagedClients (UCD’s 3.1) zu verwenden. Dazu ist nicht ganz klar, wie wir vorgehen sollen.

Wir hätten gerne, wenn das so auf diese Weise Sinn macht, für die verschiedenen Standorte die Möglichkeit verschiedene Installationen der Clients zu pflegen, sprich unterschiedliche Pakete. In der Grundschule z.B. andere Pakete als in der Gesamtschule. Das ganze könnte sich noch weiter ausdifferenzieren, falls wir z.B. die Oberstufe von der Mittelstufe trennen wollen. Wir haben verschiedene Computerräume für Lehrer, Schüler (Grundschule, Mittelstufe, Oberstufe). Wir benötigen also einen Mechanismus um zu steuern, welche Software auf den ManagedClients nutzbar ist. Wie sollen wir da vorgehen?

Welche Vorgehensweise sollten wir nutzen, wenn wir weitere Software aus den DebianRepositories nutzen wollen? Wir haben schon mit der Paketpflege experimetiert und versucht ein Verzeichnis selbst zu erstellen und zu pflegen. Wir benötigen die Software aus dem Education-Bereich wie z.B. tuxpaint, gecompris, tuxmath, geogebra, usw… Wir hätten diese Software gerne eingebunden. Erste Experimente zeigten, dass sich aufgrund vieler Abhängigkeiten der ManagedClient sträubt etwas zu installieren. Gibt es hier Erfahrungen was der beste Weg ist? (Wir sollen laut Doku es vermeiden die Repositories von Debian in /etc/apt/soure.list einzutragen).

Liebe Grüße, Gerhard Prade

Lernprogramme in UCD
#2

Sehr geehrter Herr Prade,

um für Ihre Managed Clients verschiedene Paketlisten per Richtlinie zu definieren können Sie grob wie folgt vorgehen:

[ul][li]1. Anlegen der benötigten Paketlisten im UDM
Navigation -> univention -> packages -> Neues Objekt an aktueller Position hinzufügen -> Einstellungen Paketliste
[/li]
[li]2. Anlegen einer Paketrichtlinie
Richtlinien -> Hinzufügen -> Typ auswählen -> Pakete Managed Client
[/li]
[li]3. Anlegen einer Paketpflegerichtlinie
Richtlinien -> Hinzufügen -> Typ auswählen -> Paketpflege[/li][/ul]
Die in Punkt 2 erstellten Paketrichtlinien lassen sich in der Folge dann beispielsweise mit Containern oder einzelnden Recherobjekten verknüpfen.

Die in Punkt 3 erstellte Paketpflegerichtlinie ließe sich mit einem übergeordneten Container verknüpfen und bewirkt letztlich das automatisierte Installieren/Updaten der Pakete auf den unterhalb des Containers liegenden Rechnerobjekten.

Für detailliertere Hinweise sehen Sie bitte auch im aktuellen [sd]UCS 2.4 Handbuch[/sd] das Kapitel 11.3 Paketpflege.

Darüberhinaus können Sie auch eine Einschränkung der im KDE-Menü angezeigten Anwendungen auf UCS-Clients über “KDE-Profile” vornehmen. Sehen Sie hierzu bitte das [sd]UCS 2.4 Handbuch[/sd], Kapitel 4.5.12.6 - “KDE-Profil” bzw. “univention-kde-profile-builder”.

Das direkte Installieren von Debianpaketen ist so in UCS nicht vorgesehen. Um dennoch eigene Pakete auf UCS-Systemen nutzen zu können, müssten Sie diese und eventuelle Abhängigkeiten selbst erstellen. Sehen Sie hierzu bitte den SDB-Artikel “UCS Pakete selbst erstellen”.
Ab UCS 3.0 ist das komplette Debian Repository (Bis auf die Sektion Games) für UCS gebaut und im Online-Repository bereitgestellt.

Um selbst erstellte Pakete im Anschluss innerhalb einer UCS-Umgebung bereitzustellen ist es beispielsweise möglich, ein eigenes lokales Repository hierfür bereitzustellen.
Sehen Sie hierzu bitte die Anregungen aus dem Forum-Thema “Lokales Repository um eigene Ordner erweitern”.

Sollten Sie bereits ein lokales Repository verwenden, so können Sie die neu erstellten Pakete diesem selbstverständlich auch hinzufügen. Verwenden Sie hierzu bitte den Befehl “univention-repository-addpackage”:

univention-repository-addpackage \ --dest /var/lib/univention-repository/mirror/2.4/maintained/2.4-0/ \ --file kde-profiles-test1.deb kde-profiles-test2.deb

Sehen Sie hierzu bitte auch das [sd]Handbuch[/sd] im Kapitel 11.5.2.

Mit freundlichen Grüßen,
Tim Petersen

#3

Hallo

bei einem univention-repository-update net auf dem DC der als Pakete Slave agieren soll, bekomme ich folgende Meldung:

Traceback (most recent call last): File "/usr/sbin/univention-repository-update", line 259, in ? update_net( options ) File "/usr/sbin/univention-repository-update", line 166, in update_net mirror.run() File "/usr/lib/python2.4/site-packages/univention/updater/mirror.py", line 213, in run self.mirror_update_scripts() File "/usr/lib/python2.4/site-packages/univention/updater/mirror.py", line 109, in mirror_update_scripts for server, struct, phase, path, script in UniventionUpdater.get_sh_files(all_repos): File "/usr/lib/python2.4/site-packages/univention/updater/tools.py", line 1343, in get_sh_files for server, struct in repositories: File "/usr/lib/python2.4/site-packages/univention/updater/tools.py", line 913, in _iterate_component_repositories for ver in self._iterate_versions(struct, version, version, parts, archs, server): File "/usr/lib/python2.4/site-packages/univention/updater/tools.py", line 822, in _iterate_versions (ver.major, ver.minor, ver.patchlevel) = (start.major, start.minor, start.patchlevel) AttributeError: 'str' object has no attribute 'major'

Ist irgend etwas falsch eingestellt?

Ziel war es zu testen, inwieweit Pakete in einem selbstangelegtem Repository-Verzeichnis vom Master auf dem Slave landen.

Liebe Grüße, Gerhard Prade

#4

Sehr geehrter Herr Prade,

um die aktuelle Situation beurteilen zu können, ist es notwendig, den von Ihnen angehängten Traceback in einen Kontext zu bringen.

Könnten Sie bitte einmal möglichst konkret beschreiben, wie Sie bis hierher vorgegangen sind?

Mit freundlichen Grüßen,
Tim Petersen

#5

Hallo Herr Petersen,

leider ist bei uns in der Schule gerade der Halbjahresstress eingetreten und ich bin als Lehrer mit den Halbjahreszeugnissen beschäftigt. Deswegen antworte ich leider erst jetzt. Hier nun ein Versuch den Kontext zu beschreiben.

Wir haben in unserer Schule einen UCS Master und derzeit zwei UCS DC’s für die Grundschule und für die Gesamtschule. Diese wurden von unserem Supporter installiert.

Der Master dient als Repo-Server für die DCs und holt sich die Aktualisierungen von apt.univention.de. Die beiden DCs beliefern dann die Desktops der jeweiligen Computerräume. Eine automatische Netzwerkinstallation für die Gesamtschule wurde durch den Supporter eingerichtet und durchgeführt. Eine Neuinstallation eines Desktops haben wir jedoch noch nicht getestet, so dass ich nicht sagen kann, ob die Netzwerkinstallation funktioniert. Eine Besonderheit gibt es bei uns, dass die Desktops im Dualboot Win2k anbieten. Der Bootloader soll also nicht von der Netzwerkinstallation geschrieben werden. Auch dies wurde soweit eingerichtet. Für zwei Computerräume der Gesamtschule haben wir nun die Linuxdesktops in der Grundinstallation fertig und wollten mit der weiteren Anpassung beginnen. Irgendwie klappt leider die Netzwerkinstallation in der Grundschule noch nicht, obwohl laut Supporter die gleichen Einstellungen gemacht wurden und die gleiche Hardware bei den Clients verwendet wird.

Das Repo-Prinzip bei uns ist derzeit (und so auch gewünscht) wie im Handbuch unter 11.5 in Abbildung 11.3 beschrieben eingerichtet. Unser Master soll also sich mit dem Online-Repo syncen, die beiden DCs sollen mit dem Master syncen, die Desktops sollen von den DCs installieren. Die gesamte Pflege der zusätzlichen Pakete (gcompris, tuxmath, geogebra usw.) soll jedoch auf dem master erfolgen, die Verteilung auf die Desktops dann per Richtlinen durch den master gesteuert werden (also im LDAP über den UDM gepflegt werden). dazu waren auch die Container gedacht, um verschiedenen Schulen, verschiedene Richtlinien zuzuweisen und aber dann noch die Möglichkeit zu haben zwischen den Computerräumen zu unterscheiden (Lehrerraum, Schülerraum, Bibliothek, Oberstufenraum usw.). Zum einen benötigen wir die Steuerung zentral der Desktopeinstellungen und evtl. der installierten Pakete. Das wichtige dabei ist es muss zentral gesteuert werden.

Jetzt würden wir gerne weitere Software auf den Desktops installieren. Wir benötigen verschiedene Software für die Schüler wie z.B. gcompris, tuxmath, geogebra usw. die dann im Unterricht verwendet werden. (Dazu die Frage, ob wir die lenny oder squeeze Pakete aus dem Debian-Repo verwenden sollen? Das ganze sollte ja nur auf den Desktops installiert werden, nicht auf den Servern, da sollte es ja nur geringe Probleme mit dem Mischen von Debian und UCS geben). Die Idee war es nun wie unter wiki.univention.de/index.php?tit … cked-Modus) abgelegt werden sollen um diese anschließend auf die Clients zu verteilen. Im Anschluss würden wir gerne dann per Richtlinien die jeweiligen Schulen und die einzelnen Computerräume in der Desktopkonfiguration steuern (Grundschule verschieden zu Gesamtschule, Com1 verschieden zu Com2 usw.). Soweit die Idee.

Wir haben also auf dem master ein solches Verzeichnis angelegt (/var/lib/univention-repository/mirror/2.4/maintained/component/gms-extras)
dann ucr set repository/online/component/gms-extras=enabled
dann ucr set repository/online/component/gms-extras/server=master.xxxxxxxxx.local
dann cd univention-repository/mirror/2.4/maintained/component/gms-extras/
dann apt-ftparchive packages . | gzip > ./Packages.gz
usw. laut Doku

Im master sind folgende Variablen eingestellt (hab nur die Variablen eingefügt, bei denen ich denke,sie sind wichtig):

directory/manager/web/modules/policies/repositoryserver/additional: apt.univention.de directory/manager/web/modules/policies/repositoryserver/search/default: name directory/manager/web/modules/policies/repositorysync/search/default: name local/repository: yes online/repository/clean: <empty> repository/mirror/architectures: <empty> repository/mirror/basepath: /var/lib/univention-repository repository/mirror/httpmethod: <empty> repository/mirror/port: <empty> repository/mirror/prefix: <empty> repository/mirror/recreate_packages: yes repository/mirror/server: apt.univention.de repository/mirror/sources: <empty> repository/mirror/threads: 10 repository/mirror/version/end: <empty> repository/mirror/version/start: 2.3-0 repository/mirror: yes repository/online/architectures: <empty> repository/online/component/gms-extras/server: master.xxxxxxxx.local repository/online/component/gms-extras: enabled repository/online/component/ucd/server: apt.univention.de repository/online/component/ucd/version: current repository/online/component/ucd: enabled repository/online/component/ucsschool/server: apt.univention.de repository/online/component/ucsschool/version: 2.3,2.4 repository/online/component/ucsschool: enabled repository/online/hotfixes: no repository/online/httpmethod: <empty> repository/online/maintained: yes repository/online/port: 80 repository/online/prefix: univention-repository repository/online/server: master.xxxxxx.local repository/online/sources: <empty> repository/online/unmaintained: no repository/online: yes

Auf dem DC der Gesamtschule haben wir nun folgendes eingestellt:

local/repository: true online/repository/clean: <empty> repository/local: no repository/mirror/architectures: <empty> repository/mirror/basepath: /var/lib/univention-repository repository/mirror/httpmethod: <empty> repository/mirror/port: <empty> repository/mirror/prefix: <empty> repository/mirror/recreate_packages: yes repository/mirror/server: master.xxxxxxx.local repository/mirror/sources: <empty> repository/mirror/threads: 10 repository/mirror/version/end: 2.4-2 repository/mirror/version/start: 2.3-0 repository/mirror: yes repository/online/architectures: <empty> repository/online/component/gms-extras/server: master.xxxxxxx.local repository/online/component/gms-extras: enabled repository/online/component/ucd/localmirror: enabled repository/online/component/ucd/server: masterxxxxxx.local repository/online/component/ucd/version: current repository/online/component/ucd: disabled repository/online/component/ucsschool/server: master.xxxxxx.local repository/online/component/ucsschool/version: 2.3,2.4 repository/online/component/ucsschool: enabled repository/online/hotfixes: no repository/online/httpmethod: <empty> repository/online/maintained: yes repository/online/port: 80 repository/online/prefix: univention-repository repository/online/server: dcgesamtschule-xxxxxx-01.xxxxxx.local repository/online/sources: <empty> repository/online/unmaintained: no repository/online: true

(für master und dc jeweils mit ucr search repo erstellt, interne Domain durch xxxxx anonymisiert)

Welche weiteren Einträge benötigen Sie um das Problem einzugrenzen? Welche Richtlinien wären noch sinnvoll hier zu posten?

Liebe Grüße, Gerhard Prade

#6

Sehr geehrter Herr Prade,

der von Ihnen geschilderte Traceback ist vermutlich auf einen Umstand zurückzuführen, welcher bereits in unserem Bugtracking-System dokumentiert und zu UCS Version 2.4-3 behoben wurde ([bug]22530[/bug]).
Demnach konnte es in der Vergangenheit bei der Verwendung der “version”-Variablen für Komponenten zu obigem Traceback kommen.
Sollte ein Update auf 2.4-3 nicht direkt möglich/gewünscht sein, können Sie versuchen, den am Bugeintrag referenzierten Patch gegen den Univention-Updater in Ihrer Umgebung anzuwenden.

Darüberhinaus möchte ich Sie erneut kurz darauf hinweisen, dass die Verwendung von Debian-Paketen auch auf UCS Desktop Systemen nicht zu empfehlen/vorgesehen ist.
Sie sollten die entsprechenden Pakete und deren Abhängigkeiten daher besser wie in SDB-Artikel “UCS Pakete selbst erstellen” beschrieben direkt für UCS paketieren und dann bereitstellen.

Davon abgesehen sieht die Konfiguration der UCR-Variablen soweit in Ordnung aus.

Mit freundlichen Grüßen,
Tim Petersen

#7

Sehr geehrter Herr Petersen,

vielen Dank für Ihre Antwort. Das Update auf die aktuellste 2.4 Version von UCS wird innerhalb der nächsten Zeit durch unseren Supporter ausgeführt. Wir werden dann mit ihm nochmals über die automatische Verteilung von Paketen sprechen (hatte gehofft hierfür die Supportkosten vermeiden zu können). Auch die Einbindung/Paketierung von Extraprogrammen werden wir an dieser Stelle besprechen.

Wird es bei UCD 3.0 möglich sein für den Desktop auf die orginal Debianpakete zurückzugreifen? Ich habe die von uns benötigen Programme (gcompris, geogebra, etc.) in Ihrem Repository nicht gefunden und gehe davon aus, dass Sie diese Pakete unter Games zählen.
Ich fände es schade, wenn Univention gerade die in Debian enthaltenen Lernprogramme nicht unterstützen würde. Es wäre ein großer Verlust für die Schulen, die auf UCS setzt. Evtl. könnten Sie diese Lernprogramme doch mit dem UCS@school 3.0 einbinden/unterstützen. Für den UCD LinuxDesktop wäre es ein großes Plus für jede Schule.

Ich danke Ihnen auf jeden Fall für Ihre Hilfe und Unterstützung.

Liebe Grüße, Gerhard Prade

#8

Hallo,

im die Beiträge hier Thematisch etwas zu trennen, habe ich die weitere Konversation in das neue Thema Lernprogramme in UCD übernommen.

Mit freundlichen Grüßen
Janis Meybohm

#9

Hallo Herr Meybohm,

ich habe nun unterhalb der DC für eine der Schulen in dem Container coputers einen Container clients erstellt und diesem mit dem Atrribut Standard-Rechner-Container versehehn. Das gleiche habe ich dann unterhalb dieses Containers mit weiteren Containern für einzelne Räume getan. Dann habe ich die ManagedClients in die jeweiligen “Räume” verschoben. Positiver Nebeneffekt ist, dass ich nun in manchen PulldownMenues direkt die Räume sehe und eine Auflistung der Computer nur aus diesem Raum bekomme. Das ist die Ordnung und die Struktur, die ich mir gewünscht habe.

Desweiteren habe ich Policecontainer für die Schule angelegt und dem Container Clients diese Policie zugeordnet.

/gesamtschule/policies/update/installation/computers
/gesamtschule/policies/update/repository/computers
/gesamtschule/policies/update/packages/computers

Eigentlich hab ich versucht mich an alle Anweisung der entsprechenden Dokus zu halten. Aber es zeigt keine Wirkung.

Egal ob ich unter /unsere_orga/policies/update/packages oder unter /gesamtschule/policies/update/packages/ etwas an den Paketlisten ändere, die Clients reagieren nicht darauf. Desweiteren kann ich nun nicht mal mehr eine ReInstallation eines Clients auslösen (udm->rechner->einPC->(Re)installation). Der entsprechende PC wurde vom Supporter eingerichtet und jetzt fragt der Client alles ab, sowie wenn ich manuell von CD installieren würde.
Wo habe ich evtl. etwas falsch gemacht?

Liebe Grüße, Gerhard Prade

PS: Eine Strukur würden wir uns auch bei den Usern wünschen, sobald mein Kollege aber die User sortiert, gehen bestimmte Funktionen nicht mehr, auch wenn er die entsprechenden Attribute auf die Container setzt. Das ist aber eine andere Geschichte.

Insgesamt ist es aber unbefriedigend, wenn man Strukturen der Organisation im LDAP abbilden will, um dann später damit zu arbeiten (Richtlinien, Rechte, Gruppen, usw.) und sobald man sich in die Richtung bewegen will, scheitert man am System. So geht das dann weiter mit der Desktopanpassung und Namensgebungen, fehlende Lernsoftware und UCS-Zusatzmodulen (nagios, etc.).

#10

Sehr geehrter Herr Prade,

beim Verschieben von Rechnerobjekten müssten die betroffenen UCS-Systeme im Anschluss neu gejoined werden.
Hierzu können Sie auf dem jeweiligen Managed Client folgenden Befehl auf der Kommandozeile verwenden:

univention-join

Alternativ können Sie hierzu auch die Univention-Management-Console des jeweiligen Systems verwenden:
-> Domänenbeitritt -> Erneuter Domänenbeitritt
Sie benötigen hierzu in beiden Fällen die Credentials des Administrators (auf der Kommandozeile bei Nachfrage und in der UMC bei der Anmeldung).

Mit freundlichen Grüßen,
Tim Petersen

#11

Hallo Herr Petersen,

vielen Dank für den Hinweis. Ich werde die entsprechenden System neu joinen. Erklärt die Notwendigkeit des joinens auch die nicht erfolgreiche Re-Installation der entsprechenden Clients?

Liebe Grüße, Gerhard Prade

PS: Wird sich bei UCS 3.0 etwas an dem Konzept ändern, oder kann ich an der Strategie, die Clients zu sortieren (in unserem Fall nach Schule und dann nach Räumen), festhalten?

PPS: Ich kann die Windows-Rechner-Objekte leider nicht in die entsprechenden angelegten Ordner verschieben. Woran kann das liegen?

#12

Sehr geehrter Herr Prade,

ich würde vermuten, dass der Mechanismus zur Reinstallation über den UDM derzeit vermutlich aufgrund des ausgelassenen Joins nach dem Verschieben der Rechnerobjekte scheitert.

Zum jetztigen Entwicklungsstand von UCS@School ist es nicht geplant, das Konzept bzw. die Struktur des LDAP’s dahingehend zu verändern.

[quote=“gprade”]
PPS: Ich kann die Windows-Rechner-Objekte leider nicht in die entsprechenden angelegten Ordner verschieben. Woran kann das liegen?[/quote]
Prinzipiell sollten sich Rechnerobjekte vom Typ “Windows” auf gleiche Weise verschieben lassen, wie UCS-Clients. Erhalten Sie beim Verschieben eine entsprechende Fehlermeldung im UDM?

Mit freundlichen Grüßen,
Tim Petersen

#13

Hallo Herr Petersen,

[quote] Prinzipiell sollten sich Rechnerobjekte vom Typ “Windows” auf gleiche Weise verschieben lassen, wie UCS-Clients. Erhalten Sie beim Verschieben eine entsprechende Fehlermeldung im UDM?
[/quote]

Ja, ich konnte die LinuxClients verschieben ohne Fehlermeldung. Die WindowsClients jedoch nicht. Die entsprechende Fehlermeldung kam im UDM.

Welche Logs sind für den ganzen Prozess der Paketverwaltung und -verteilung zuständig (auf dem Server (Master und SchulDC) und auf dem Client) bzw. für die ReInstallation. Und in welchen Logs kann ich die Richtlinien und deren Verteilung prüfen. Bisher konnte ich nur ausprobieren und vermuten, würde aber gerne eine genauere Fehleranalyse betreiben.
Die gleiche Frage stellt sich bei dem “Aufräumen” der Richtlinien und Clients in die entsprechenden Container.

Liebe Grüße, Gerhard Prade

PS: Wäre ein VPN-Zugang mit Adminrechten auf unser System für Sie hilfreich? Dann könnten Sie den Prozess evtl. besser begleiten und bei Fragen direkt im Master und den DCs nachschauen.

#14

Sehr geehrter Herr Prade,

die Logdateien der UCS-spezifischen Dienste lassen sich unterhalb von /var/log/univention finden.
Im Falle der Paketverteilung, wird auf den Clients der Befehl “univention-actualise” verwendet. Dessen Ausgaben lassen sich in der Datei “/var/log/univention/actualise.log” finden.
Die Verteilung von Richtlinien können Sie beispielsweise mit dem Befehl "univention-policy-result " prüfen. Hierzu gern ein Beispielaufruf:

univention-policy-result cn=tc1,cn=ThinClients,cn=computers,dc=domain,dc=local

Eine derartige Leistung kann leider über die kostenfreie Unterstützung im Forum nicht erfolgen. Sollten Sie hier weiterführende Analysen/Umsetzungen wünschen, setzen Sie sich bitte mit Ihrem vertrieblichen Ansprechpartner in Verbindung.

Mit freundlichen Grüßen,
Tim Petersen

#15

[quote]Prinzipiell sollten sich Rechnerobjekte vom Typ “Windows” auf gleiche Weise verschieben lassen, wie UCS-Clients. Erhalten Sie beim Verschieben eine entsprechende Fehlermeldung im UDM?
[/quote]

Ich erhalte:

“Das Verschieben von 1/1 Objekten ist fehlgeschlagen: cn=a311-win-st01,cn=computers,ou=gesamtschule,dc=xxxxxx-net,dc=local: LDAP-Fehler Type or value exists”

und jetztz?

Liebe Grüße. Gerhard Prade

#16

Hallo Herr Petersen,

nach dem ich in einem Raum die Clients manuell neu gejoint habe, kann ich über univention-actualise erkennen, dass die jeweiligen Richtlinen, die ich speziell einem “Untercontainer” zugewiesen habe greifen. Jenachdem was ich in der Paketliste und -richtlinie einstelle, reagiert der Client wie gewünscht. Nun fehlen mir noch die gewünschten Pakete. Dieses Problem wäre also gelöst. Ich würde vorschlagen, dies mit in das Handbuch aufzunehmen, falls zukünftig ein User Clients in Untercontainer verschieben will.

Nichts desto trotz reagiert der Client nicht auf eine ReInstalllation (die ich ihm über die UMC zugewiesen habe). Boote ich den PC über PXE läuft keine automatische Installation (obwohl der Mechanismus ansonsten funktioniert, denn ich habe heute einen frischen PC damit installiert). Der Client verhält sich, als ob er nicht wüsste, welches Profil ihm zugewiesen ist und fragt nach sämtlichen Optionen der Installation. Auch wenn ich über Grub boote beginnt keine Installation. Woran kann das liegen.

Liebe Grüße, Gerhard Prade

#17

Sehr geehrter Herr Prade,

Das heißt, der Mechanismus zur (Re-)Installation funktioniert grundlegend? Sie sehen einen Client im UDM zur (Re-)Installation vor, booten den Client per PXE und die Installation beginnt?
Dann dürfte es sich hierbei nur um kleine Unstimmigkeiten in der Konfiguration handeln.
Haben Sie das zu verwendene Profil korrekt am Rechernobjekt eingetragen? Liegt es in dem hierfür vorgesehenen Verzeichnis (/var/lib/univention-repository/profiles)?
Bitten sehen Sie hierzu auch noch einmal die entsprechende Dokumentation [ed]Profilbasierte Installation[/ed].

Die über den UDM eingeleitete (Re-)Installation eines Rechners wird hierbei stets per PXE eingeleitet.

Mit freundlichen Grüßen,
Tim Petersen

#18

Hallo Herr Petersen,

nein, eine Re- bzw. Neuinstallation funktioniert nicht. Das was funktioniert ist, wenn ein Client noch nicht installiert war, dann wird er über PXE installiert. Danach wird er nicht neu installiert. Die Profilbasierte Installation wurde durch den Supporter eingerichtet, jedoch werden bereits installierte Clients nicht neu installiert.

Liebe Grüße, Gerhard Prade

#19

Sehr geehrter Herr Prade,

[quote=“gprade”]
Nichts desto trotz reagiert der Client nicht auf eine ReInstalllation (die ich ihm über die UMC zugewiesen habe). Boote ich den PC über PXE läuft keine automatische Installation (obwohl der Mechanismus ansonsten funktioniert, denn ich habe heute einen frischen PC damit installiert). Der Client verhält sich, als ob er nicht wüsste, welches Profil ihm zugewiesen ist und fragt nach sämtlichen Optionen der Installation.[/quote]

Wenn ich Sie hier richtig verstehe, dann wird die Re-Installation eines Clients nach dem Setzen der entsprechenden Option durchaus initialisiert. Das aktuelle Problem bezieht sich demnach lediglich auf die Tatsache, dass die begonnene Installation nicht automatisiert(profilbasiert) läuft?
Ich würde Sie bitten, einmal Bezug auf die bisher gestellten Fragen zu nehmen, um das Verhalten näher eingrenzen zu können:

[quote=“Petersen”]Haben Sie das zu verwendene Profil korrekt am Rechernobjekt eingetragen?
Liegt es in dem hierfür vorgesehenen Verzeichnis (/var/lib/univention-repository/profiles)?[/quote]
Sehen Sie zum konkreten Vorgehen hierzu bitte die entsprechende Dokumentation: Profilbasierte Installation.

Sie erwähnten, dass eine profilbasierte Neuinstallation über PXE funktioniert. Wird hierbei das gleiche Profil verwendet?

Mit freundlichen Grüßen,
Tim Petersen

#20

Hallo Herr Petersen,

derzeit scheint in den Clients kein Profil zugewiesen zu sein. Im UDM wird unter dem Punkt (Re)installation kein Profil angezeigt (das Handbuch spricht hier von dem Karteikartenreiter Neuinstallation statt von (Re)installation, können Sie das bitte ändern lassen?). Ich denke genau hier liegt das Problem, dass der Client nach dem Booten per PXE auf die Benutzereingaben wartet. Ich habe hierzu unseren Supporter kontaktiert. Das entsprechende Profil liegt auf dem DC im besagten Verzeichnis.
Ich denke das Problem ist damit gelöst und bedanke mich für Ihre Unterstützung. Jetzt geht es weiter mit der Paketverteilung und der Erstellung/Pflege eines eigenen Component für weitere Software und der KDE-Profile. Und dann eben mit der Zuweisung der Richtlinien auf die verschiedenen Container.

Liebe Grüße, Gerhard Prade

PS: Das angesprochene Profil soll auf allen Clients genutzt werden, somit auch auf den neu zu installierenden Clients. Wahrscheinlich ist die Zuweisung der Profile zu den Clients irgendwo verloren gegangen.

Mastodon