client:linux_in_vms - bwLehrpool

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
====== Linux in virtuellen Maschinen ======

Wie bei den Windows-VMs empfehlen wir, unsere bereitgestellte Linux-Vorlage aus dem öffentlichen Austausch zu verwenden. Diese ist für den Poolbetrieb vorbereitet und muss nur noch um die von Ihnen benötigte Software erweitert werden.

Falls Sie dennoch eine eigene Linux-VM von Grund auf neu erstellen wollen, müssen Sie einige Schritte beachten.


===== Poolumfeld =====

Im Poolumfeld sind Dinge wie Abschalten, Sperren, Userwechsel und dergleichen natürlich eher sinnlos, da sie entweder vom Grundsystem zur Verfügung gestellt werden (zB. Sperren des Monitors) oder schlichtweg unerwünscht sind (zB. Userwechsel per Menu der Oberfläche, Schlafmodus, Logout innerhalb der VM). Diese sollten abgestellt werden, sind jedoch von der jeweils verwendeten Oberfläche abhängig.

==== Autologin ====

Da die Authentifizierung in den Pools bereits vorher erfolgt, ist anzuraten, die VM-interne Userkennung direkt anzumelden (Autologin). Dies ist je nach Distribution, genauer gesagt: Je nach verwendetem Displaymanager, unterschiedlich.

<note tip>Es ist empfehlenswert, als Userkennung „student“ mit Paßwort „student“ zu verwenden. Die Linuxskripte erwarten diesen Usernamen.</note>

  * openSuse: Setzen Sie in der Datei /etc/sysconfig/displaymanage den Eintrag DISPLAYMANAGER_AUTOLOGIN="student".
  * KDE/sddm allgemein (Kubuntu ua.): Öffnen Sie die KDE-Systemeinstellungen, dort „Starten und Beenden“. Wählen Sie den Reiter „Erweitert“ oder (Kubuntu) den Schalter „Verhalten“. Unter „Automatisch anmelden“ kann normalerweise die Userkennung gewählt werden; wenn nicht finden Sie dort gewöhnlich versionsspezifische Hinweise.
  * Ubuntu: Gehen Sie zu den Systemeinstellungen, „Benutzer“, klicken auf „Entsperren“ und verschieben dann den Regler bei „Automatische Anmeldung“.

Falls diese Hinweise nicht zielführend sind, können Sie noch die Standardmethoden für den jeweiligen Displaymanager probieren:

=== Generisch sddm ===

Hängen Sie - wenn Eintrag nicht vorhanden, ansonsten editieren - an die Datei /etc/sddm.conf.d/autologin.conf an:

<code>[Autologin]
User=student
</code>

=== Generisch lightdm ===

Fügen Sie an die Datei /etc/lightdm/lightdm.conf an:
<code>[Seat:*]
autologin-user=student
autologin-user-timeout=0
</code>

=== Generisch gdm3 ===

Hängen Sie an /etc/gdm3/custom.conf an:
<code>AutomaticLoginEnable = true
AutomaticLogin = student
</code>


==== Unerwünschte UI-Funktionen ====

Hier schlagen hauptsächlich der Abmelde-Button zu Buche, daneben auch Suspend-Modi, das Öffnen weiterer Session bzw Userwechsel und dergleichen. Diese Aufstellung kann bei der Vielzahl möglicher Desktop-Oberflächen nur schwerlich vollständig sein; bitte lassen sie uns wissen, wenn Sie hier fehlende Lösungen/Möglichkeiten haben!

=== Abmelden-Button ===

== KDE ==

Unter Plasma (KDE 5) finden sich die fraglichen Knöpfe im Anwendungsmenu unter „Energieverwaltung / Sitzung“. In ihrer Funktion erhalten bleiben sollten lediglich „Neustarten“ und „Herunterfahren“.

Das Deaktivieren des Abmelden-Buttons sollte eigentlich mit Polkit funktionieren, scheint jedoch fehlerhaft zu sein (getestet unter openSuse 42.3). Daher wurde der Weg über das Verzeichnis [/home/student/].config/plasma-workspace/shutdown/ genommen, und darin ein einfaches Skript abgelegt((… das Skript können Sie natürlich nennen, wie Sie wollen, z. B. „herunterfahren“)):

<code bash>
#!/bin/sh
sudo -n poweroff
</code>

Vergessen Sie anschließend nicht, das Skript mit ‚chmod +x [Skriptname]‘ ausführbar zu machen. Damit es funktioniert, muß der Befehl ‚poweroff‘ in der sudoers-Liste abgelegt werden (nutzen Sie dazu unbedingt ‚visudo‘):

<code>
student ALL=(ALL) NOPASSWD: /sbin/poweroff
</code>

Anschließend löst ein Druck auf den Abmelden-Knopf einen Shutdown der virt. Maschine aus.

== lightdm ==

Hängen Sie in der /etc/lightdm/lightdm.conf eine Zeile des Inhalts <code>session-cleanup-script = /sbin/poweroff</code> an. Ein sudoers-Eintrag ist hier nicht vonnöten, da lightdm das Skript mit Rootrechten ausführt.

=== Sperren / Benutzerwechsel / Neue Session starten ===

== KDE ==

Fügen Sie der Datei [/home/student/].config/kdeglobals folgenden Abschnitt hinzu:

<code>
[KDE Action Restrictions][$i]
action/lock_screen=false
action/switch_user=false
action/start_new_session=false
</code>

=== Standby-Modi (Suspend/Hibernate) ===

Erstellen Sie im Verzeichnis /etc/polkit-1/rules.d ein Datei namens 10-disable-suspend.rules und füllen sie mit 
<code>
polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.login1.suspend" ||
        action.id == "org.freedesktop.login1.suspend-multiple-sessions" ||
        action.id == "org.freedesktop.login1.hibernate" ||
        action.id == "org.freedesktop.login1.hibernate-multiple-sessions")
    {
        return polkit.Result.NO;
    }
});
</code>

Sollte obiges nicht funktionieren, können Sie folgende Brutalinski-Methode testen: Suchen Sie im Verzeichnisse /usr/share/polkit-1/actions nach Vorkommen des Strings „org.freedesktop.login1.suspend“:

<code>
cd /usr/share/polkit-1
grep -r 'org.freedesktop.login1.suspend'
</code>

Dies wird vermutlich die Datei „org.freedesktop.login1.policy“ im Unterverzeichnis „actions“ zu Tage fördern. Editieren Sie diese so, daß unter den Einträgen „<action id="org.freedesktop.login1.suspend">“ und evtl. „<action id="org.freedesktop.login1.suspend-multiple-sessions">“ bei „<allow_active>“ „no“ steht. Der Nachteil dieser Methode ist, dass in seltenen Fällen auch nach Reboot die Schaltflächen 'Suspend' zwar nicht mehr funktionieren, doch weiterhin angezeigt werden.

== systemd-Targets ==

Ein
<code>systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target</code>
sollte unerwünschte systemd-Targets (sleep, suspend, hibernate) deaktivieren.

==== Automatische Updates ====

Automatische Updates ergeben im Poolumfeld natürlich ebenfalls keinen Sinn. Als Faustregel gilt, alles zu deaktivieren oder zu entfernen, was automatische Updates auslösen kann. Dies ist je nach Distribution durchaus unterschiedlich, so dass hier nur allgemeine Hinweise gegeben werden können.

  * Deaktivieren Sie automatische Updates womöglich auf Systemebene((Debian/Ubuntu: /etc/apt/apt.conf.d/20auto-upgrades)).
  * Prüfen Sie evtl. crontabs auf zeitgesteuerte Updates.
  * Deinstallieren Sie packagekitd.
  * Wenn eine komplette Deinstallation (z.B. packagekit unter (K)ubuntu) nicht möglich ist, deinstallieren Sie lästige 'Pop-up-Programme' (z.B. plasma-discover).


===== Drucken =====

Bitte vergleichen Sie hierzu [[drucken_in_bwlehrpool#druckereinrichtung_in_linux-vm|Druckereinrichtung in Linux-VM]].

===== Hilfsskripte =====

Analog zur "openslx.exe" in Windows-VMs wird ein im Poolbetrieb per systemd zu startendes Skript („openslx“ mit Hilfsskripten) zur Verfügung gestellt. Dieses kümmert sich im Poolbetrieb um
  * die automatische Anpassung der Auflösung,
  * Einbindung von Netzlaufwerken (Homeverzeichnis und weitere Laufwerke),
  * ggf. Ausführung vorgegebener Startskripte.

Das Skript ist im Poolbetrieb auf dem zweiten Floppylaufwerk (/dev/fd1) nach dem Mounten unter /mnt/diskmount((/mnt/diskmount sollten Sie daher in Ihrer VM nicht für andere Zwecke anlegen.)) im Unterverzeichnis 'linux' zu finden; die verwendeten include-Dateien unter 'linux/includes'((Eine Angabe, wie Sie das Floppyabbild im Clientsystem finden, dürfte wenig zielführend sein - das Abbild wird erst beim Start einer VM erstellt.)). Sie finden die jeweils aktuellste Version im Netz [[http://git.openslx.org/openslx-ng/mltk.git/tree/core/modules/run-virt/data/opt/openslx/vmchooser/data/linux|hier]]. Falls Sie die vom System übergebenen Skripte überlagern wollen, können Sie dies satellitenserverseitig mit einem generischen Konfigurationsmodul tun. Bitte betrachten Sie diese Skripte als Vorlagen; an Erweiterungen derselben und anderen Lösungen sind wir sehr interessiert.

Händisches Mounten aus einer im Poolsystem gebooteten VM (es wird angenommen, /mnt sei leer, Rootrechte erforderlich):
<code>mount /dev/fd1 /mnt</code>
… anschließend finden Sie die Skripte unter /mnt/linux und können diese, wenn gewünscht, umkopieren. Bitte lesen Sie in jedem Fall die mitgelieferte Datei linux/LIESMICH bzw. linux/README.

Die Hilfsskripte beziehen ihre Informationen aus den im Grundverzeichnis der Pseudofloppy befindlichen Dateien openslx.ini und shares.dat. Die Datei HOSTRES.TXT wird nur noch aus Kompatibilitätsgründen eine Weile mitgeführt. Stützen Sie sich daher nicht auf HOSTRES.TXT, wenn Sie eigene Skripte schreiben bzw. die vorhandenen erweitern wollen.

Damit sich die Auflösung innerhalb von bwLehrpool automatisch anpassen kann, muss ein entsprechendes Skript automatisch bei der Anmeldung ausgeführt werden, welches die optimale Auflösung des verwendeten Bildschirms ermittelt und diese Auflösung anschließend setzt. Bei den Vorlagen für Windows-VMs ist dafür beispielswiese die 'openslx.exe' im Laufwerk B:\ bereits im Autostart eingetragen. Für Linux-Umgebungen ist die Herangehensweise aufgrund der Distributionsverscheidenheit ein wenig anders.

Zur Auflösungsanpassung stehen bisher zwei Möglichkeiten zur Verfügung:
  * ein Paket mit Auflösungsanpassung und nativem (innerhalb einer Linux-VM) Einhängen von Netzlaufwerken, sowie
  * ein hauptsächlich zu Debugzwecken verwendetes Skript „resolution_standalone“ lediglich zur Auflösungsanpassung, verbunden mit etwas Handarbeit.

<note important>Das Skript resolution_standalone wird nicht mehr gewartet. Es sollte daher generell das systemd-Skriptpaket genutzt werden.</note>


==== Paket Auflösungsanpassung und Netzlaufwerke ====

Es steht weiterhin eine Paketlösung zur Verfügung, die sowohl für die automatische Auflösungsanpassung als auch für die native Einbindung der Netzlaufwerke sorgt. Die hierzu verwendeten Skripte werden zur VM-Laufzeit von der Pseudofloppy nachgeladen; zur lokalen Installation ist nur das Skript 'vm_installer' vonnöten. Unterstützt werden systemd-basierte Distributionen; eine Lösung mit initV-/etc/init.d/-Mechanismus ist zwar teilweise inbegriffen, wird jedoch nicht mehr gewartet.

Der Ablauf stellt sich in diesem Fall wie folgt dar:

  * Das Skript 'vm_installer' erzeugt die systemd-Servicedateien 'openslx-resolution.service', 'openslx-mount.service' sowie 'openslx-umount.service' und verlinkt diese in graphical.target.wants, basic.target.wants und shutdown.target. Diese Servicedateien sorgen für das Mounten der Pseudofloppy unter /mnt/diskmount und starten die betreffenden Skripte resolution, mnt_shares und umnt_shares.

Dies sollte unter den derzeit verbreiteten Distributionen direkt funktionieren, so diese systemd nutzen. Das Installskript finden Sie unter https://git.openslx.org/openslx-ng/mltk.git/plain/core/modules/run-virt/data/opt/openslx/vmchooser/data/linux/vm_installer - ggf. Rechtsklick, „Seite speichern unter“ oder bequem ‚wget [Adresse]‘.

=== Auflösungsanpassung ===

Das vom 'openslx-resolution.service'-Dienst gestartete Skript resolution wartet eine gewisse Zeit auf den X-Server, paßt dessen Auflösung an und prüft noch eine Weile, ob nach dem Userlogin (etwa von Seiten einer Desktopumgebung) evtl. eine andere, unerwünschte Auflösung gesetzt wird. Diese wird dann korrigiert.
  * Anmerkung: IPv6 kann stören. Deaktivieren Sie IPv6 testweise.
  * Sollte die vom 'openslx-resolution.service'-Dienst korrekt eingestellte Auflösung sofort zurückgestellt werden, läuft vermutlich im Hintergrund ein Dienst der betreffenden Oberfläche((Der KDE-Hintergrunddienst kscreen_backend_launcher wird von der neuen Skriptversion Skript erkannt und beendet)). 

=== Native Einbindung Netzlaufwerke ===

Netzlaufwerke (Home und ggf. gemeinsame Netzlaufwerke) werden über die per 'openslx-mount.service'-Dienst gestarteten Linuxskripte nativ innerhalb Linux-VMs ein- und ausgebunden werden, wenn die hierzu notwendigen Angaben vom Grundsystem übermittelt werden.

<note tip>Sie können überprüfen, wie (Home-)Netzlaufwerke eingebunden werden, wenn Sie den Wert "remapMode" in der Datei openslx.ini im Grundverzeichnis der gemounteten Pseudofloppy /dev/fd1 betrachten: 
  * 0 = Nichts tun.
  * 1 = Home nativ, also innerhalb der VM mounten
  * 2 = Fallback, also nativ probieren, bei Fehler VMWare-shared folder nutzen
  * 3 = VMWare-shared folder nutzen.
Bitte beachten Sie, daß Sie für den VMWare-shared folder-Mechanismus entweder die originalen VMWare-Tools benötigen, oder im Falle der open-vm-tools ein hgfs-Kernelmodul kompilieren müssen!

Die Einstellung des "remapMode" erfolgt im Web-Interface (slx-admin) bei der Konfiguration des entsprechenden Auth-Moduls.
</note>

<note important>Die Linux-Skripte erwarten des Standarduser "student". Sollten Sie eine andere Userkennung in Ihren Linux-VMs nutzen, müssen Sie ggf. per [[linux_in_vms#aktualisierte_skripte_per_konfigmodul|generischem Konfigmodul]] den per …/linux/includes/00-vars.inc übergebenen Wert LOCALUSER=student anpassen.</note>


===== bwLehrpool-Suite-Startskript =====

Die bwLehrpool-Suite bietet die Möglichkeit, ein [[bwlehrpool-suite#startskript|Startskript]] auszuführen. Dieses wird vom System auf der (Pseudo-)Diskette /dev/fd1 unter dem Namen runscript(.sh) abgelegt.

Das oben erwähnte „Paket Auflösungsanpassung, native Netzlaufwerke“ mountet diese Pseudodiskette automatisch unter /mnt/diskmount. Sie können das Skript runscript.sh dann beispielsweise einfach per .bashrc, .profile und dergleichen  starten:

''[ -e /mnt/diskmount/runscript.sh ] && /mnt/diskmount/runscript.sh &''

… oder legen Sie einfach ein Link im passenden Autostartverzeichnis Ihrer Linuxoberfläche (Standard: ~/.config/autostart-scripts):

''ln -s /mnt/diskmount/runscript.sh /home/student/.config/autostart-scripts/runscript.sh''

falls Sie sicher etwas Grafisches starten wollen((Da bekanntlich .bashrc usw. nicht immer unter X ausgeführt werden)).
Zuletzt angesehen: • client_hardware • linux_in_vms • qemu • dot_powershell
Suche

Navigation

Drucken/exportieren

Werkzeuge
