Versuche mit ltsp4 / Probebetrieb ltsp8

[Rüdiger Kupper]

Ursprünglich ging es in diesem Ticket darum, ob das LTSP-Setup-Skript die /etc/network/interfaces richtig anlegt.
Später haben wir hier allgemeine Erfahrungen damit gesammelt, wie der Login am ltsp4 verbessert werden kann.

[bau]

Das ist die Datei

/etc/network/interfaces

dort muss stehen:

        dns-nameservers 10.32.1.251
        dns-search kg-fds.de

[Rüdiger Kupper]

Hach, SVN ist super. Man kann sich zu jeder Zeile einer Datei anschauen, wann und von wem sie eingecheckt wurde:

source:/keplertools/scripts/trunk/LTSP-setup-server?annotate=blame

Daraus sehe ich:

• Die Datei /etc/network/interfaces wird vom Skript angelegt, und zwar bereits seit Revision 8 vom 25.8.2011.
• Die beiden Nameservereinträge werden aber erst seit Revision 603 vom 17.7.2013 eingetragen.

Wenn die Datei also da war, aber die Nameserver-Einträge fehlten, dann hatte ich wohl einen USB-Stick mit einer alten Version. Falls die Datei gar nicht vorhanden war, lag's vermutlich daran, dass ich zuerst den repair-Modus (#953) ausprobiert habe, der aber nicht korrekt funktionierte. Danach habe ich das Skript nochmal im add-Modus durchlaufen lassen. Vielleicht ist dabei die Datei auf der Strecke geblieben.

-> Ich muss den repair-Modus überprüfen, ticket:953 ist ja auch noch offen...

[Rüdiger Kupper]

autsch, ja, da war ein Fehler im Skript, das dazu führte, dass im repair-Modus die maschinenabhängigen Dateien nicht mitkopiert wurden, danach aber auch nicht angelegt -- sehr geschickt!
Das behebe ich grade mal...

[Rüdiger Kupper]

Okay, [762/keplertools]. Das neue Skript muss getestet werden.

[bau]

Heißt das, du hast den Server ltsp4 garnicht neu aufgesetzt sondern nur ein bestehendes System repariert?
Das würde immerhin erklären, warum die Reparatur selbst nach Einbau in die ltsp1-Hardware immernoch nicht funktioniert!

[Rüdiger Kupper]

Ja, so ist es: Die Platte wurde nicht neu formatiert. Es lief nur ein rsync über das gesamte Dateisystem (wobei die serverspezifischen Dateien ausgespart wurden, also alles, wo die IP oder der Hostname drinsteht, und der ssh-Hostkey). Aber das rsync garantiert, dass die Dateien nachher identisch sind.

Beim nachträglichen Neuerzeugen der serverspezifischen Dateien lief dann etwas schief, daher fehlte die /etc/network/interfaces. Es könnte sein, dass aus dem gleichen Grund auch andere serverspezifische Dateien nicht stimmen. -- Das einfachste ist, ich wiederhole den Vorgang nochmal.

Hier kannst Du nachlesen, welche Dateien beim Kopieren übersprungen werden:
source:/keplertools/scripts/trunk/LTSP-setup-server@765:388-416#L375

[bau]

Offensichtlich ist derzeit am ltsp4 was anders, als am ltsp1.
Bevor wir einen Total-Restore vornehmen, möchte ich noch ein wenig am ltsp4 herumspielen.
Ich baue jetzt gleich noch die Platten wieder in die richtign Kisten rein, im Stützpunkt1:

• links ist dann wieder ltsp1
• recht: ltsp4

[Rüdiger Kupper]

Okay. Wenn Du fertig bist, ziehe ich das System nochmal neu rüber (dann am besten mit Plattenformatierung).

[bau]

OK, ich habe den Fehler jetzt letztendlich doch noch gefunden!
Ich habe am ltsp1 und 4 experimentiert und irgendwann mal habe ich oben auch das nm-applet im Panel gehabt und gedacht: Das ist ja vollkommen unnötig! Sowohl auf ltsp4 als auch ltsp2 half:

aptitude purge network-manager-pptp
aptitude purge network-manager-pptp-gnome
aptitude purge network-manager-gnome

Jetzt kommt sogar beim starten wieder das Zahnrad oben rechts :-).

Auf ltspl1 will das Paket lubuntu-Desktop aber das Paket network-manager-gnome haben, ich habe den Starter aus /etc/xdg/autostart/ (nm-applet.desktop) nach /etc/xdg/autostart/autostart-disabled/ verschoben. Die starter an dieser Stelle sollten mal allesamt auf ihre Notwendigkeit geprüft werden!

[Rüdiger Kupper]

Das hab ich schonmal durchexerziert:
Querverweis: #569

Habe schon öfters überlegt, den Network-Manager zu entfernen. Habe immer davon abgesehen, weil er integraler Bestandteil des Pakets ubuntu-desktop ist, und weil er Teil des resolvconf-Mechanismus ist (jedenfalls klinkt er sich da auch ein, und da wollte ich möglichst wenig ändern.)

Bislang hat er allerdings auch kein Problem gemacht -- sobald sich ein "static"-Eintrag in /etc/network/interfaces findet, deaktiviert sich der Network-Manager normalerweise! Klappt das nicht mehr?

Auf ltspl1 will das Paket lubuntu-Desktop aber das Paket network-manager-gnome haben

Ich dachte wie gesagt, dass auch ubuntu-desktop das will...

Jedenfalls werden wir den NM nicht benötigen, da unsere Server statisch verbunden sind. Auf den Notebooks allerdings schon.

[bau]

Ich habe nicht den network-manager deinstalliert, sondern nur die gnome-plugins :-)
Auf dem ltspl1 habe ich das plugin nur am Starten gehindert.

[Rüdiger Kupper]

Oha, okay. Was tun die Plugins denn?

[Rüdiger Kupper]

ruediger@helge:~$ apt-cache show network-manager-pptp
...
Description-en: network management framework (PPTP plugin core)
 NetworkManager is a system network service that manages your network devices
 and connections, attempting to keep active network connectivity when
 available. It manages ethernet, WiFi, mobile broadband (WWAN), and PPPoE
 devices, and provides VPN integration with a variety of different VPN
 services.
 .
 This package provides a VPN plugin for PPTP, commonly used for connecting
 to Microsoft VPN servers.

ruediger@helge:~$ apt-cache show network-manager-pptp-gnome
Package: network-manager-pptp-gnome
...
Description-en: network management framework (PPTP plugin GNOME GUI)
 NetworkManager is a system network service that manages your network devices
 and connections, attempting to keep active network connectivity when
 available. It manages ethernet, WiFi, mobile broadband (WWAN), and PPPoE
 devices, and provides VPN integration with a variety of different VPN
 services.
 .
 This package provides the GNOME bits of NetworkManager's PPTP plugin.

ruediger@helge:~$ apt-cache show network-manager-gnome
...
Description-en: network management framework (GNOME frontend)
 NetworkManager is a system network service that manages your network devices
 and connections, attempting to keep active network connectivity when
 available. It manages ethernet, WiFi, mobile broadband (WWAN), and PPPoE
 devices, and provides VPN integration with a variety of different VPN
 services.
 .
 This package contains a systray applet for GNOME's notification area but it
 also works for other desktop environments which provide a systray like KDE
 or Xfce.
 It displays the available networks and allows users to easily switch between
 them. For encrypted networks it will prompt the user for the key/passphrase
 and it can optionally store them in the gnome-keyring.

[Rüdiger Kupper]

Die ersten beiden sind also Plugins für Microsoft-VPN. Das dritte Paket ist das Indicator-Applet für die Menüzeile.

[bau]

Und das letzte Rätsel ist auch noch gelöst:
Auf ltsp1 war network-manager-gnome nicht installiert :-)

[bau]

Ich habe auf allen ltsp das remmina-plugin-xdmcp installiert

Für die Dokumentation: wie heißt das Installationspaket?

[Rüdiger Kupper]

Sehr cool! Das wollte ich schon immer haben, aber hatte nie Gelegenheit, mich drum zu kümmern!
XDMC ist zwar ein veraltetes Verfahren, das prinzipiell nicht mehr verwendet werden soll. Der Grund ist aber nur die fehlende Verschlüsselung (XDMC macht grundsätzlich eine normale X-Verbindung, ohne jede Option zur Verschlüsselung). Wenn ich allerdings im Schulhaus bin, ist mir das egal, und per VNC ebenfalls.
Schön :-).

Ubuntu bietet seit einigen Versionen übrigens eine Alternative:
Wenn der lightdm feststellt, dass der Rechner bereits am Login-Screen eine Internetverbindung hat, stellt er ein Login-Feld "Remote Login" dar. Klickt man da drauf, wird man mit seinem Ubuntu-Account verbunden (sofern man eins hat, wenn nicht, darf man eins einrichten, was übrigens wirklich nützlich ist: Das erlaubt nämlich Authentifizierung über OpenID -- Auf jeder Site, die OpenID unterstützt, kann man sich dann mit seinem Ubuntu-Account authentifizieren).

Im Ubuntu-Account sind dann Anmeldeinformationen für RDP-Services gespeichert. Mann kann sich also mit diesem Mechanismus an jedem(!) Ubuntu-Rechner mit Netzwerkverbindung an einem RDP-Dienst anmelden. Würde auf unserern LTSP-Servern ein RDP-Dienst laufen, dann könnte man z.B. von jedem Ubunturechner im VPN eine graphische Sitzung auf dem jeweiligen Server starten.

Eigentlich eine geniale Methode, sie sollte nur VNC unterstützen. Aber irgendwie hat dieses Feature noch kein Interesse erregt -- ich frage mich, wieso.

[Rüdiger Kupper]

Replying to bau:

Und das letzte Rätsel ist auch noch gelöst:
Auf ltsp1 war network-manager-gnome nicht installiert :-)

Wie jetzt das? network-manager-gnome hängt von ubuntu-desktop ab! Wenn das nicht installiert war, dann auch nicht das ubuntu-desktop-Metapaket:

kup@reinhold:~$ apt-cache rdepends network-manager-gnome
network-manager-gnome
Reverse Depends:
  network-manager-gnome:i386
 |network-manager-gnome-dbg
  network-manager-gnome:i386
  network-manager:i386
  gnome-bluetooth:i386
  mythbuntu-desktop
  xubuntu-desktop
  ubuntustudio-desktop
  lubuntu-desktop
  gnome-core
  gnome
  unity-greeter
  ubuntu-desktop
 |network-manager-gnome-dbg
  network-manager
 |network-manager
  gnome-bluetooth

[Rüdiger Kupper]

Replying to bau:

Ich habe auf allen ltsp das remmina-plugin-xdmcp installiert
Für die Dokumentation: wie heißt das Installationspaket?

Achso, klar: remmina-plugin-xdmcp. :-)

[Rüdiger Kupper]

Und noch was schönes:
lightdm erlaubt es, dass man sich remote per xdmcp einlogged. Ich habe auf

allen ltsp das remmina-plugin-xdmcp installiert und per lightdm das xdmcp-
Protokoll auf allen Servern gestartet. In meinem Home-VZ befinden sich
unter .remmina acht Remmina-Dateien für die acht Server (einfach bei dir
reinkopieren und dich zum Eigentümer machen )

Startet der XDMCP-Dienst beim lightdm automatisch, oder was muss man dafür tun?

[bau]

Man trägt den Dienst einfach in /etc/lightdm/lightdm.conf ein :-)
Dort kann man auch VNC eintragen, der Spackt aber rum - ich bekomme keine befriedigende Darstellung des lightdm-unity-greeters :-(
Wir haben derzeit tightvnc und vnc4server installiert - beide machen es nicht richtig!
lightdm ruft dann den Xvnc auf (link entweder von tightvnc oder von vnc4server).
Ich denke, da muss ich mal noch recherchieren, welches vnc-Paket da derzeit verwendet werden soll.

[bau]

ich habe einige Versuche mit den Einstellungen unter /usr/local/glibc-2/schemas gemacht, das funktioniert dann aber wohl mit .override-Dateien. Solche gibt es auf ltspl1 nicht, auf den anderen aber teilweise. Jetzt ist mir nicht ganz klar, wer denn nun eigentlich für die Einstllungen zuständig ist - da gibt es dconf und gconf und gsettings und gconftool-2 und glib-compile-schemas.

• Vor allem würde mich zunächst mal interessieren, wo wir damals die Bildschirmsperre haben.
• Desweiteren: Wo haben wir die Herunterfahren und sonstigen Buttons aus dem Menü genommen?
• wie kann man überhaupt das indicator-session-plugin rechts oben anpassen?

[Rüdiger Kupper]

Replying to bau:

ich habe einige Versuche mit den Einstellungen unter /usr/local/glibc-2/schemas gemacht, das funktioniert dann aber wohl mit .override-Dateien. Solche gibt es auf ltspl1 nicht, auf den anderen aber teilweise.

Mit den schemas habe ich noch keine Erfahrungen gemacht. Wozu dienen die? Scheint eher ein ziemlich teifliegender Mechanismus zu sein -- ist das wirklich die Stelle, an der wir manipulieren sollten?

Jetzt ist mir nicht ganz klar, wer denn nun eigentlich für die Einstllungen zuständig ist - da gibt es dconf und gconf und gsettings und gconftool-2 und glib-compile-schemas.

Kurze Antwort:

• gconf ist die alte Methode und wird nach und nach abgeschafft. (Grund: es benutzt ein XML-File als Datenbank, und das ist, angeblich, nicht so effizient.) gconf-tool und gconf-editor sind Userinterfaces, um diese XML-Dateien zu manipulieren.
• gsettings ist die neue Methode. gsettings definiert nur das Interface, wie man Schlüssel liest, setzt und verändert. Die eigentlichen Daten werden in einer binären Datenbank gespeichert, die je nach Betriebssystem anders sein kann: Unter Windows die Registry. Unter Linux wird hierfür dconf verwendet.
• gsettings hat kein grafisches Interface, nur Kommandozeile. Man kann aber den Inhalt der Datenbank auch direkt verändert mit dem dconf-editor.
• dconf bringt auch ein Verfahren mit, wie man Schlüssel mit Defaultwerten versieht oder unveränderbar macht. Das benutze ich inzwischen hier und da.

Das ganze ist beschrieben auf LtspUbuntu. Ist aber nicht mehr ganz aktuell -- inzwischen benutzen wirklich die meisten Programm e das neue gsettings/dconf. Ich glaube, bei uns gibt es gar nichts systemweites mehr, was das alte gconf benutzt, seitem ich Docky durch Plank ersetzt habe.

• Vor allem würde mich zunächst mal interessieren, wo wir damals die Bildschirmsperre haben.

Das intereessiert mich auch! Ich habe keine Ahnung und habe es auch nicht mehr finden können! Auf dem neuaufgesetzten ltsp8 funktioniert derzeit der Screenlock.

• Desweiteren: Wo haben wir die Herunterfahren und sonstigen Buttons aus dem Menü genommen?

Das steht hier: #215. Das ist wahrscheinlich auch der "moderne" Mechanismus, um den Screenlock zu unterbinden, wenn man das will.

• wie kann man überhaupt das indicator-session-plugin rechts oben anpassen?

Siehe LtspUbuntu#Indicators. Ist aber auch nicht mehr ganz aktuell, ich glaube, das Whitelisting funktioniert nicht mehr auf diese Weise.

Fazit: Es ist gut, wenn wir unsere Erkenntnisse im Wiki aufschreiben. Auch wenn sie manchmal veraltet sind, hilft trotzdem.

[Rüdiger Kupper]

Aktuelle Informationen über die derzeitige gconf/gesettings-Konfiguraion der LtspServer gibt's auf der Seite LtspServerAufsetzen:

• LtspServerAufsetzen#VorgabenfürGnome-Settingsdconfeinrichten
• LtspServerAufsetzen#VorgabenfürGConfeinrichten

[Rüdiger Kupper]

Okay, wie man sieht, kann man mittels dconf auch die Restart und Shutdown-Option aus dem Menü entfernen. Blöderweise gibt es keinen Eintrag für Suspend! Ich nehme an, das wird bald nachgeholt, dann braucht man sich nicht mher mit PolicyKit herumzuschlagen...

[bau]

Du schreibst beim Neuaufsetzen:

Zeitgeist deaktivieren(?)

Dieser Schritt scheint nicht weiter benötigt zu werden. Der neu aufgesetzte Server läuft prima mit aktivierterm Zeitgeist**

(Ev. die Datei zeitgeist-datahub.desktop aus /etc/xdg/autostart/ entfernen oder in ein anderes Unterverzeichnis verschieben. 

Die Probleme mit Zeitgeist entstanden immer im laufenden Betrieb, wenn sich die User eingelogged hatten. Das muss gut geprüft werden, wir handeln uns sonst wieder die massiven Netzwerktraffic-Probleme ein!

[Rüdiger Kupper]

Genau so ist es auch gemeint: Ich habe beim Aufsetzen erst einmal alle Schritte ausgelassen, die wir unternommen hatten, um die Loginprobleme zu verringern. Momentan kann ich beim ltsp8 keine Verzögerungen oder probleme feststellen, aber es war ja auch immer nur eine Person eingeloggt.

Der ltsp8 ist jetzt soweit fertig (es fehlt nur noch die Einrichtung der Drucker und ein eigenes Bild für den Loginschirm). Wir können ihn nächste Woche in den Probebetrieb nehmen. Dann beobachten wir, ob Schwierigkeiten auftreten und können bei Bedarf gezielt bestimmte Workarounds wieder aktivieren.

Aber die einzige Maßnahme, die bisher Loginprobleme verursacht hatte (und zwar genau so, wie wir sie von den anderen Servern kennen), war das Policykit-Konfigfile. Wäre natürlich super, wenn das der einzige Grund war.

Also überleg mal, welche Clients wir probeweise auf ltsp8 setzen. Mögliche Szenarien

• nur unsere Rechner im LZ und der Chemie
• erstmal nur Clients im Computerraum
• immer ein gesamtes U auf einmal für bestimmte Zeit
• aus jedem U ein paar Rechner

Außerdem könnten wir die Kollegen jeweils bitten, besonders auf Probleme zu achten, dann bekommen wir möglichst schnell Rückmeldung. (Aber vielleicht ist das auch kontraproduktiv :-).

Frage: Muss ltsp4 heute noch wiederhergestellt werden, oder hat das noch Zeit? (Oder ersetzen wir einfach ltsp4 durch ltsp8?)

[bau]

Ach so, du hattest Loginprobleme verursacht durch das PolicyKit - jetzt verstehe ich das!
Wobei das Network-Manager-Applet den Betrieb ebenfalls massiv gestört hatte (ich habe während des Tests am Dienstag folgendes gehabt: Login dauerte am ltsp2 ewig, habe ich abgebrochen. Dann habe ich das Paket network-manager-gnome deinstalliert und den lightdm neu gestartet: Login ging schnell. Auf ltsp8 habe ich das Paket ebenfalls deinstalliert (wird ja nicht gebraucht - die Anzeige rechts oben zum Netzwerk ist überflüssig auf den Clients aber auch auf dem Server)

ltsp4 hat nach der Umstellung mit dem nm-applet keine Probleme mehr - Login geht schnell (8-10 Sekunden).
Was auch Probleme verursacht hatte, ist die zu niedrige Bildschirmauflösung (1024x768) durch den Umschalter. Ich habe das in den Us nun so gelöst:

• U1: Bildschirm/Tastatur/Maus hängt direkt an Server
• U2: Bildschirm/Tastatur/Maus an Umschalter (wie in den Klassenzimmern / VGA+2xUSB) DVI-Kabel am Bildschirm angebracht, kann evtl direkt am Server angeschlossen werden.
• U3/4: Bildschirm/Tastatur/Maus am alten Umschalter (VGA nur am Windows-PC), Server per DVI-Kabel direkt am Bidschirm, noch ungelöst: wie schaltet man den Bildschirm auf VGA um?
• PCRaum: Neuer 19"-Monitor per VGA an Umschalter angeschlossen. Problem: Erkennt nur 1024x768 statt 1280x1024 - ärgerlich!

Die Drucker muss ich noch in Betrieb nehmen (eventuell morgen früh). Das mache ich dann auf ltsp8 direkt mit.

Zum Testbetrieb:
Ich denke, der Test in einem ganzen U wäre hilfreich. Netzwerktechnisch ist es recht egal, welches U wir nehmen, da der PCRaum per Glasfaser direkt in den Serverraum verbunden ist und von dort der Weg in alle Us gleich weit ist. U4 bietet sich ja geradezu an. Wir sollten es so machen: U4 an ltsp8 hängen, die Räume 5.53,5.54 und 5.55 am ltsp4 lassen. Dann haben wir eigentlich ein optimales Testszenario.

[bau]

Zu lightdm:
Wann stellt der der remote-Login für xdmcp dar?
In der Config gibt es eine Option greeter-show-remote-login=true, die bewirkt aber erstmal nichts.
Damit könnte man sich vor dem Login bereits den Server heraussuchen, mit dem man sich verbinden möchte.
Ist aber eher akademisch, da wir uns ja per Remmina mit dem LoginScreen jedes ltsp-Servers verbinden können, das geht am Server direkt sehr performant, am Client ist es etwas zäh, geht aber auch.

Die VNC-Sache möchte ich noch testen, da gibt es noch einige Einstellungen, die man machen kann.

Zur Virtualisierung habe ich überlegt:
Kann man auf dem ProxMox (debian squeeze oder aktuell: wheezy für ProxMox 3) nicht ein solches X mit dem LDM installieren, dann würde des ProxMox-Server als ltsp-client funktionieren, ein login wäre am Server direkt möglich!

Was auch hilfreich wäre, sind Clients, die neben dem Server stehen.
Das war beim Testen diese Woche extrem hilfreich: Ich hatte die zwei Laptops im U1 einfach als Clients gebootet und konnte parallel ltsp1, ltsp4 und zwei entsprechende Clients an ltsp1 und ltsp4 beobachten.

[Rüdiger Kupper]

Replying to bau:

Wobei das Network-Manager-Applet den Betrieb ebenfalls massiv gestört hatte

[...] Auf ltsp8 habe ich das Paket ebenfalls deinstalliert.

Ah! Dann muss ich das auf LtspServerAufsetzen schreiben. Hast Du sonst noch etwas an ltsp8 verändert?

ltsp4 hat nach der Umstellung mit dem nm-applet keine Probleme mehr - Login geht schnell (8-10 Sekunden).

Hm, wenn's jetzt geht, wissen wir nicht, ob's das Policykit war oder das nm-Applet. Das möchte ich dann noch herausfinden. Aber erstmal schaun, wie die Server sich jetzt machen.

Die Drucker muss ich noch in Betrieb nehmen (eventuell morgen früh). Das mache ich dann auf ltsp8 direkt mit.

Welche Drucker meinst Du jetzt? Die in den Stützpunkten? Auf ltsp8 habe ich noch gar keine Drucker eingerichtet, das ist der letzte Punkt auf der Liste :-).

Wenn Du irgend etwas an ltsp8 machst, dokumentiere das bitte auf LtspServerAufsetzen. Und zwar am besten direkt zeilenweise den einzugebenden Code. Ich will, dass ich zum Schluss ltsp8 plattmachen kann, die Liste auf LtspServerAufsetzen abarbeiten und erhalte ihn exakt genau so wieder.

[Rüdiger Kupper]

Replying to kup:

Hm, wenn's jetzt geht, wissen wir nicht, ob's das Policykit war oder das nm-Applet. Das möchte ich dann noch herausfinden. Aber erstmal schaun, wie die Server sich jetzt machen.

Gerade wird mir klar: Wenn Du auf ltsp8 das nm-Applet entfernt hattest, dann hat das Policy-Kit dennoch den Login-Hänger verursacht. Das habe ich nämlich gestern und vorgestern ausgiebig getestet.

[bau]

Ich habe auf ltsp8 die Pakete

• network-manager-gnome
• network-manager-pptp
• network-manager-pptp-gnome

deinstalliert und die Pakete

• aptitude
• remmina-plugin-xdmcp

installiert.

Die /etc/lightdm/lightdm.conf habe ich vom ltsp1 kopiert (wegen des xdmcp-Starts), an weiteren Tests bin ich dran. (Wo konfiguriert man z.B. die Teilchen, die lightdm und der unity-greeter laden? Wahrscheinlich wird das auch per dconf gemacht, es gibt aber auch die gconf-xml-Dateien, diese müssen aber zuerst per glib-compile-schemas komipliert werden, das ist wohl die Schnitstelle zwischen alt und neu).

[Rüdiger Kupper]

Replying to bau:

Ich habe auf ltsp8 die Pakete

• network-manager-gnome
• network-manager-pptp
• network-manager-pptp-gnome

deinstalliert und die Pakete

• aptitude
• remmina-plugin-xdmcp

installiert.

Okay, hab's dokumentiert.

Die /etc/lightdm/lightdm.conf habe ich vom ltsp1 kopiert

Die Seite LtspServerAufsetzen soll eine Anleitung ergeben, wie man einen LtspServer komplett neu aufsetzt, ohne sich auf einen existierenden Server zu beziehen. Also dort bitte nicht schreiben "die Datei von einem anderen Server rüberkopieren", sondern den Inhalt der Datei explizit angeben (bzw. den Teil, der hinzugefügt werden muss).
Ich will sozusagen eine Anleitung, mit der ich einen LtspServer aufgesetzt kriege, nachdem die Schule abgebrannt ist ;-).

(wegen des xdmcp-Starts), an weiteren Tests bin ich dran. (Wo konfiguriert man z.B. die Teilchen, die lightdm und der unity-greeter laden?

Weiß ich auch nicht, aber schau mal hier nach: ​http://wiki.ubuntuusers.de/LightDM#Konfiguration

Wahrscheinlich wird das auch per dconf gemacht, es gibt aber auch die gconf-xml-Dateien, diese müssen aber zuerst per glib-compile-schemas komipliert werden, das ist wohl die Schnitstelle zwischen alt und neu).

Ich würde mal das alte gconf außer Acht lassen, das wird in Zukunft nicht mehr verwendet. In fünf Wochen kommt die neue LTS-Version von Ubuntu raus, vielleicht haben sie es bis dahin abgeschafft. Was LightDM betrifft, kann ich mir nicht vorstellen, dass das noch das alte gconf nimmt?

Hinweis: Experimente bitte derzeit nicht auf ltsp8, sonst verliere ich da die Übersicht. Wenn Du etwas gefunden hast, bei dem Du sicher bist, dokumentier es auf LtspServerAufsetzen. Die Seite soll zu jeder Zeit den Zustand widerspiegeln, in dem sich ltsp8 befindet.

[Rüdiger Kupper]

Replying to bau:

In der Config gibt es eine Option greeter-show-remote-login=true, die bewirkt aber erstmal nichts.

Ich nehme an, die ist auch default. Bei meinem Ubuntu hier zuhause steht die Option nämlich nicht drin. Das Feld für den Remote-Login erscheint automatisch, sobald der lightdm bemerkt, dass Netzwerkzugang besteht. Das arbeitet offenbar mit dem Network Manager zusammen (womit wir wieder bei dem Thema wären):

Ich habe meine Ethernet-Verbindung und meine WLAN-Verbidnung zuhause als "autmatically connect" und "available for all users" gekennzeichnet. Am Login-Screen sehe ich das NM-Applet. Sobald ich mein Netzwerkkabel anstecke oder das WLAN einschalte, verbindet sich der NM. Sobald die Verbindung steht, erscheint das Loginfeld "Remote Login".

Könnte sein, dass das bei unseren Servern so nicht passiert, weil sich der NM wegen der statischen Verbindung grundsätzlich deaktiviert(?)

[Rüdiger Kupper]

Aber Achtung, das "Remote Login"-Feld des LightDM verbindet über RDP, siehe comment:18 oder ​http://pmeyhoefer.de/blog/ubuntu-12-10-wird-anmeldung-uber-remote-desktop-ermoglichen/

Das ist unabhängig von der XDMCP-Funktionalität (die ist schon älter).