[[PageOutline]] = LINBO = Aus der Wikipedia: //Linbo steht für //Linux-based Network Boot Operating System// und ist Teil der Selbstheilungsfunktionalität (Selbstheilende Arbeitsstationen, SheilA) der Serverdistribution [WikipediaDe:paedML] Linux.// ([WikipediaDe:LINBO weiterlesen]) == Aufnehmen neuer Clients == Im Konzept der paedML werden neue Clientrechner am System zu Benutzung aufgenommen, indem der betreffende Rechner per PXE ein Mini-Linux bootet. Von dort aus wird der neue Client am System angemeldet. Dabei geschieht folgendes: - Es wird in der [source:keplertools/etc/trunk/linuxmuster/workstations /etc/linuxmuster/workstations] eine Zeile mit den Daten der Workstation angelegt: {{{ Raumname;Clientname;Clientgruppe;MAC;IP;?;?;?;?;Imaging }}} Imaging: siehe PaedmlAnpassungen Nach einem Durchlauf des Scripts `./import_workstations` wird - ein Samba-Workstation-Account angelegt - ein Samba-Klassenarbeits-Account angelegt - die Firewall für die MAC freigeschaltet Der Client hat damit Internetzugang, ist in der Schulkonsole bekannt und für die normale Schularbeit im Sinne der paedML verwendbar. == Anpassungen == === /usr/share/linuxmuster/scripts/wimport.sh === Wir setzen mehrere LTSP-Server mit dem DHCP/DNS-Server dnsmasq ein. Nach dem Workstation-Import werden aus den Config-Files von linuxmuster.net sowie unseren Config-Files für die LTSP-Server unter /etc/linuxmuster/ltsp_config/ die Konfigurationen für die verschiedenen dnsmasq-Server erstellt, auf die Server hochgeladen und die dnsmasq-Prozesse dort neu gestartet. Dateien: * /etc/linuxmuster/ltsp_config/paedml.template[[BR]] Vorlage für die paedml-dnsmasq-Konfiguration, Script passt DNS, WPAD etc an * /etc/linuxmuster/ltsp_config/ltsp.template[[BR]] Vorlage für die LTSP-dnsmasq-Konfiguration, Script passt die IP-Bereiche, DNS, WPAD etc an * /etc/linuxmuster/ltsp_config/ltspl.template[[BR]] Vorlage für die ltspl-dnsmasq-Konfiguration * /etc/linuxmuster/ltsp_config/paedml[[BR]] Hier lagert die fertig angepasste Konfiguration des paedml-Servers * /etc/linuxmuster/ltsp_config/ltspX/ und /etc/linuxmuster/ltsp_config/ltsplX/[[BR]] Hier lagert die fertig angepasste Konfiguration der LTSP-Server * /etc/linuxmuster/ltsp_config/clients/clients[[BR]] In dieser Datei stehen die getaggten Clients (HWAdresse, IP, Name).[[BR]] Die Tags legen fest, welches Bootmenü ausgeliefert wird, was also letztendlich gebootet wird. * /etc/linuxmuster/ltsp_config/dhcp[[BR]] Vorgesehen für den DHCP-Server Lehrernetz * /etc/linuxmuster/ltsp_config/lehrernetzclients[[BR]] Wahrscheinlich obsolet - muss noch umgesetzt werden * /etc/linuxmuster/ltsp_config/ltspclients[[BR]] Hier werden die LTSP-Clients aufgeführt, da diese keinen Workstation-Account auf der paedml benötigen und somit nicht in die workstations-Datei gehören Am Ende des Scripts wird der Neustart des isc-dhcp-Servers und des bind9 auskommentiert (wir benutzen dnsmasq) und das Kepler-eigene Script make_ltsp_config aufgerufen. === /usr/share/linuxmuster-linbo/update-linbofs.sh === Dieses Script macht ein wenig zuviel und überschreibt in den start.conf.Gruppe-Dateien die ServerIP mit 10.32.1.1, das funktioniert im Lehrernetz so nicht, weshalb ich den Inhalt der Funktion set_serverip() ganz am Anfang auskommentiert habe. Damit beim PXE-Boot aus dem Lehrernetz der Server mit der IP 10.16.112.4 angesprochen wird, habe ich die /var/linbo/start.conf (default) umbenannt, so dass sie nicht mehr gefunden wird - Linbo nimmt dann die aus der linbofs.gz oder linbofs_l.gz (Featurerequest unter http://www.linuxmuster.net/flyspray/task/427). Weiter unten im Script will dieses auch unbedingt die /var/linbo/default.conf patchen und schafft das dann nicht - ich habe es auskommentiert. === /var/linbo/pxelinux.cfg/ === Hier lagern die per TFTP ausgelieferten PXE-Boot-Configs für jede Gruppe. Da wir derzeit per DHCP keinen Dateinamen mit ausliefern wird die IP (in HEX) oder die default genommen. Das passt soweit, da wir keine Besonderheiten an der Hardware haben. * /var/linbo/pxelinux.cfg/0A10[[BR]] Default für das Lehrernetz (0A10 = 10.16), hier steht der APPEND server=10.16.112.4 drin * /var/linbo/pxelinux.cfg/default[[BR]] Default für das Schülernetz, hier steht der APPEND server=10.32.1.1 drin, ansonsten würde LINBO versuchen von dem Server zu booten, von dem es seine IP erhalten hat, das muss schiefgehen :-) * Die anderen Dateien sind für uns unwichtig, da wir per DHCP keinen Dateinamen mitliefern * Clients können hier subnetzweise oder IPweise mit einer eigenen Datei versorgt werden, die Datei muss einfach so heißen wie die IP in HEX === /var/linbo/menu.lst.Gruppe === Für jede Gruppe wurde eine solche Datei angelegt, 3 Sekunden hat man dadurch bei lokalem Boot Zeit, Linbo zu umgehen und stattdessen Edubuntu direkt zu booten. Bei jedem rsync (z.B. Cache aktualisieren) wird die Datei auch auf den Client geholt. == Der Linbo-Boot == Bei uns booten alle Clients per PXE von einem der DHCP-Server (der der am schnellsten ist gewinnt). Bei aufgenommenen Clients bieten alle DHCP-Server die gleiche IP und das gleiche PXE-Bootmenü an. Standardmäßig (erster Eintrag) wird LINBO vom paedml gebootet, man kann aber auch Lokal von der Platte (oder das Booten von einem anderen Server) auswählen. 1. **lokaler Boot[[BR]]** Grub wartet 3 Sekunden, während derer man Edubuntu sofort starten kann - auch Linbo DEBUG steht zur Verfügung. Standard-Boot-Methode ist LINBO zu booten, welches dann auf dem paedml die passende start.conf-IP per rsync holt. 2. **per TFTP vom paedml-Server[[BR]]** Der PXE-Bootmenüeintrag verweist auf den LINBO-Server (10.32.1.1 oder 10.16.112.4) von dort wird per TFTP das passende Config-File geholt (default oder 0A10), welches auf das zu holende /var/linbo/linbofs.gz oder /var/linbo/linbofs_l.gz verweist. In den Configs ist der APPEND server=10.32.1.1 oder server=10.16.112.4 angegeben, so dass LINBO die Datei vom richtigen Server holt, in der start.conf in linbofs.gz bzw. linbofs_l.gz steht die korrekte IP des Servers. Linbo benutzt diese, wenn der Rechner noch nicht aufgenommen ist und findet so den korrekten Server. Ist der Rechner bereits aufgenommen, so findet LINBO per rsync auf dem paedml die passende start.conf-IP Danach geht es so weiter, wie in der aktuellen start.conf auf dem Client eingetragen. Linbo bietet nach dem syncen die Möglichkeit, ein Postsync-Script auszuführen (siehe: http://www.linuxmuster.net/wiki/anwenderwiki:linbo:postsync_scripte:start). Für die Rechner der TGS ist dieses eingerichtet, da auf den Ubuntu-Clients die LDAP-Anbindung und das PAM_mount nicht von paedml.kg-fds.de erfolgen dürfen, sondern von server.kg-fds.de. Das Script /var/linbo/trusty.cloop.postsync fragt ab, ob der Rechnername mit "tgs-" anfängt und kopiert dann die Dateien unter /var/linbo/Patches/ auf den Client.