Knowledgebase - Benutzerbeiträge [de]

Input/Output-Verhalten bei HPE Microserver Gen10

2026-04-11T22:56:36Z

PoC: /* Lösung */ Stimmt nicht

Der '''HPE Microserver Gen 10'''<ref>Nicht Gen10+!</ref> ist mit einem Massenspeichercontroller Marvell 88SE9230 ausgerüstet, der sich im Tagesbetrieb etwas merkwürdig im '''I/O-Verhalten''' gezeigt hat.

__TOC__

<blockquote>'''Hinweis:''' Es geht hier nicht um den Betrieb des Chipsatzes im RAID-Modus, sondern mit einzelnen Disks.<ref>Das RAID selbst läuft mit ''mdraid''.</ref></blockquote>

== Problembeschreibung ==
Mit Festplatten<ref>WD Green 2 TB</ref> aber auch SSDs<ref>Samsung 870 QVO 2 TB.</ref> konnte ich unter Linux<ref>Debian 12, Kernel Version 6.1.0.</ref> stellenweise Ruckler und Hakler beobachten, die hart an der Grenze zu ''es nervt'' waren, ich aber in Anbetracht der doch eher schwachbrüstigen CPU als gegeben hinnahm. Allerdings trat das Problem beim Vorgängersystem, einem HP Microserver N54L mit ansonsten gleicher Software nicht auf.

Für mich war das insbesondere spürbar…
* beim Editieren von Textdateien in ''vim''.
** Beim Wechsel von Einfüge- nach Kommandomodus ließ sich der Cursor nicht mehr instant bewegen, sondern brauchte eine knappe halbe Sekunde Bedenkzeit.
** Beim Scrollen durch längere Texte ruckelte und stockte die Darstellung immer mal wieder.
** Speichern einer wenige KiB großen Datei hat eine knappe halbe Sekunde Verzögerung bis zum Prompt nach sich gezogen.
* beim Aufrufen von eher kleinen Programmen wie <code>cat</code>, <code>grep</code>, <code>sed</code>, u. Ä. bei denen ebenfalls nach dem Beenden der Funktion der Shell-Prompt im Vergleich zum Vorgängersystem dann doch einen Ticken zu lange brauchte bis er wieder erschien.

== Analyse ==
Dank eines guten Freundes, der dies auf dem gegebenen System ebenfalls beobachten konnte, ließ sich das Problem eingrenzen. Das temporäre Verzeichnis <code>/tmp</code> ist auf meinem System eine RAM-Disk. Forciert man das Anlegen der ''vim''-Recoverydateien dort drin, war das Ruckeln im Editor komplett verschwunden. Es konnte sich somit nur um ein I/O-Problem handeln.

Meine Recherchen haben ergeben, dass der Marvell-Chipsatz sich als [[wikipedia:Advanced Host Controller Interface|AHCI]] am System meldet, und das Kernelmodul ''ahci.ko'' noch zwei Parameter beherrscht:
* <code>marvell_enable</code> soll dazu da sein, manche Marvell-Chipsätze in den SATA-Mode zu zwingen.
* <code>mobile_lpm_policy</code><ref>Dies soll ''demnächst'' in ''lpm_policy'' umbenannt werden, weil es nicht nur Notebooks betrifft.</ref> zur Konfiguration des Standard-Stromsparmodus, der in <code>/sys/class/scsi_host/host''n''/link_power_management_policy</code> eingesehen werden kann.

Da die Ports standardmäßig im Sysfs auf ''max_performance'' standen, habe ich diesen Parameter nicht weiter getestet.

== Lösung ==
<s>Der Test mit ''marvell_enable=1'' verlief positiv. Das Ruckelproblem war damit verschwunden.

<syntaxhighlight lang="shell">
echo "options ahci marvell_enable=1" > /etc/modprobe.d/ahci.conf
update-initramfs -u
reboot
</syntaxhighlight></s>
Korrelation bedingt nicht zwingend Kausalität. Der Fehler wurde im Laufe der Zeit wieder sichtbar. Es scheint also einen Zusammenhang mit der Laufzeit des Systems zu geben.

== Fußnoten ==
<references />

[[Kategorie: Hardware]]
[[Kategorie: Linux]]
[[Kategorie: Storage]]

Input/Output-Verhalten bei HPE Microserver Gen10

2026-04-07T20:16:09Z

PoC: Genauer

Der '''HPE Microserver Gen 10'''<ref>Nicht Gen10+!</ref> ist mit einem Massenspeichercontroller Marvell 88SE9230 ausgerüstet, der sich im Tagesbetrieb etwas merkwürdig im '''I/O-Verhalten''' gezeigt hat.

__TOC__

<blockquote>'''Hinweis:''' Es geht hier nicht um den Betrieb des Chipsatzes im RAID-Modus, sondern mit einzelnen Disks.<ref>Das RAID selbst läuft mit ''mdraid''.</ref></blockquote>

== Problembeschreibung ==
Mit Festplatten<ref>WD Green 2 TB</ref> aber auch SSDs<ref>Samsung 870 QVO 2 TB.</ref> konnte ich unter Linux<ref>Debian 12, Kernel Version 6.1.0.</ref> stellenweise Ruckler und Hakler beobachten, die hart an der Grenze zu ''es nervt'' waren, ich aber in Anbetracht der doch eher schwachbrüstigen CPU als gegeben hinnahm. Allerdings trat das Problem beim Vorgängersystem, einem HP Microserver N54L mit ansonsten gleicher Software nicht auf.

Für mich war das insbesondere spürbar…
* beim Editieren von Textdateien in ''vim''.
** Beim Wechsel von Einfüge- nach Kommandomodus ließ sich der Cursor nicht mehr instant bewegen, sondern brauchte eine knappe halbe Sekunde Bedenkzeit.
** Beim Scrollen durch längere Texte ruckelte und stockte die Darstellung immer mal wieder.
** Speichern einer wenige KiB großen Datei hat eine knappe halbe Sekunde Verzögerung bis zum Prompt nach sich gezogen.
* beim Aufrufen von eher kleinen Programmen wie <code>cat</code>, <code>grep</code>, <code>sed</code>, u. Ä. bei denen ebenfalls nach dem Beenden der Funktion der Shell-Prompt im Vergleich zum Vorgängersystem dann doch einen Ticken zu lange brauchte bis er wieder erschien.

== Analyse ==
Dank eines guten Freundes, der dies auf dem gegebenen System ebenfalls beobachten konnte, ließ sich das Problem eingrenzen. Das temporäre Verzeichnis <code>/tmp</code> ist auf meinem System eine RAM-Disk. Forciert man das Anlegen der ''vim''-Recoverydateien dort drin, war das Ruckeln im Editor komplett verschwunden. Es konnte sich somit nur um ein I/O-Problem handeln.

Meine Recherchen haben ergeben, dass der Marvell-Chipsatz sich als [[wikipedia:Advanced Host Controller Interface|AHCI]] am System meldet, und das Kernelmodul ''ahci.ko'' noch zwei Parameter beherrscht:
* <code>marvell_enable</code> soll dazu da sein, manche Marvell-Chipsätze in den SATA-Mode zu zwingen.
* <code>mobile_lpm_policy</code><ref>Dies soll ''demnächst'' in ''lpm_policy'' umbenannt werden, weil es nicht nur Notebooks betrifft.</ref> zur Konfiguration des Standard-Stromsparmodus, der in <code>/sys/class/scsi_host/host''n''/link_power_management_policy</code> eingesehen werden kann.

Da die Ports standardmäßig im Sysfs auf ''max_performance'' standen, habe ich diesen Parameter nicht weiter getestet.

== Lösung ==
Der Test mit ''marvell_enable=1'' verlief positiv. Das Ruckelproblem war damit verschwunden.

<syntaxhighlight lang="shell">
echo "options ahci marvell_enable=1" > /etc/modprobe.d/ahci.conf
update-initramfs -u
reboot
</syntaxhighlight>

== Fußnoten ==
<references />

[[Kategorie: Hardware]]
[[Kategorie: Linux]]
[[Kategorie: Storage]]

Input/Output-Verhalten bei HPE Microserver Gen10

2026-04-06T22:10:22Z

PoC: Typo

Der '''HPE Microserver Gen 10'''<ref>Nicht Gen10+!</ref> ist mit einem Massenspeichercontroller Marvell 88SE9230 ausgerüstet, der sich nach einer Analyse etwas merkwürdig im '''I/O-Verhalten''' gezeigt hat.

__TOC__

<blockquote>'''Hinweis:''' Es geht hier nicht um den Betrieb des Chipsatzes im RAID-Modus, sondern mit einzelnen Disks.<ref>Das RAID selbst läuft mit ''mdraid''.</ref></blockquote>

== Problembeschreibung ==
Mit Festplatten<ref>WD Green 2 TB</ref> aber auch SSDs<ref>Samsung 870 QVO 2 TB.</ref> konnte ich unter Linux<ref>Debian 12, Kernel Version 6.1.0.</ref> stellenweise Ruckler und Hakler beobachten, die hart an der Grenze zu ''es nervt'' waren, ich aber in Anbetracht der doch eher schwachbrüstigen CPU als gegeben hinnahm. Allerdings trat das Problem beim Vorgängersystem, einem HP Microserver N54L mit ansonsten gleicher Software nicht auf.

Für mich war das insbesondere spürbar…
* beim Editieren von Textdateien in ''vim''.
** Beim Wechsel von Einfüge- nach Kommandomodus ließ sich der Cursor nicht mehr instant bewegen, sondern brauchte eine knappe halbe Sekunde Bedenkzeit.
** Beim Scrollen durch längere Texte ruckelte und stockte die Darstellung immer mal wieder.
** Speichern einer wenige KiB großen Datei hat eine knappe halbe Sekunde Verzögerung bis zum Prompt nach sich gezogen.
* beim Aufrufen von eher kleinen Programmen wie <code>cat</code>, <code>grep</code>, <code>sed</code>, u. Ä. bei denen ebenfalls nach dem Beenden der Funktion der Shell-Prompt im Vergleich zum Vorgängersystem dann doch einen Ticken zu lange brauchte bis er wieder erschien.

== Analyse ==
Dank eines guten Freundes, der dies auf dem gegebenen System ebenfalls beobachten konnte, ließ sich das Problem eingrenzen. Das temporäre Verzeichnis <code>/tmp</code> ist auf meinem System eine RAM-Disk. Forciert man das Anlegen der ''vim''-Recoverydateien dort drin, war das Ruckeln im Editor komplett verschwunden. Es konnte sich somit nur um ein I/O-Problem handeln.

Meine Recherchen haben ergeben, dass der Marvell-Chipsatz sich als [[wikipedia:Advanced Host Controller Interface|AHCI]] am System meldet, und das Kernelmodul ''ahci.ko'' noch zwei Parameter beherrscht:
* <code>marvell_enable</code> soll dazu da sein, manche Marvell-Chipsätze in den SATA-Mode zu zwingen.
* <code>mobile_lpm_policy</code><ref>Dies soll ''demnächst'' in ''lpm_policy'' umbenannt werden, weil es nicht nur Notebooks betrifft.</ref> zur Konfiguration des Standard-Stromsparmodus, der in <code>/sys/class/scsi_host/host''n''/link_power_management_policy</code> eingesehen werden kann.

Da die Ports standardmäßig im Sysfs auf ''max_performance'' standen, habe ich diesen Parameter nicht weiter getestet.

== Lösung ==
Der Test mit ''marvell_enable=1'' verlief positiv. Das Ruckelproblem war damit verschwunden.

<syntaxhighlight lang="shell">
echo "options ahci marvell_enable=1" > /etc/modprobe.d/ahci.conf
update-initramfs -u
reboot
</syntaxhighlight>

== Fußnoten ==
<references />

[[Kategorie: Hardware]]
[[Kategorie: Linux]]
[[Kategorie: Storage]]

Input/Output-Verhalten bei HPE Microserver Gen10

2026-04-06T22:09:51Z

PoC: New

Der '''HPE Microserver Gen 10'''<ref>Nicht Gen10+!</ref> ist mit einem Massenspeichercontroller Marvell 88SE9230 ausgerüstet, der sich nach einer Analyse etwas merkwürdig im '''I/O-Verhalten''' gezeigt hat.

__TOC__

<blockquote>'''Hinweis:''' Es geht hier nicht um den Betrieb des Chipsatzes im RAID-Modus, sondern mit einzelnen Disks.<ref>Das RAID selbst läuft mit ''mdraid''.</ref>

== Problembeschreibung ==
Mit Festplatten<ref>WD Green 2 TB</ref> aber auch SSDs<ref>Samsung 870 QVO 2 TB.</ref> konnte ich unter Linux<ref>Debian 12, Kernel Version 6.1.0.</ref> stellenweise Ruckler und Hakler beobachten, die hart an der Grenze zu ''es nervt'' waren, ich aber in Anbetracht der doch eher schwachbrüstigen CPU als gegeben hinnahm. Allerdings trat das Problem beim Vorgängersystem, einem HP Microserver N54L mit ansonsten gleicher Software nicht auf.

Für mich war das insbesondere spürbar…
* beim Editieren von Textdateien in ''vim''.
** Beim Wechsel von Einfüge- nach Kommandomodus ließ sich der Cursor nicht mehr instant bewegen, sondern brauchte eine knappe halbe Sekunde Bedenkzeit.
** Beim Scrollen durch längere Texte ruckelte und stockte die Darstellung immer mal wieder.
** Speichern einer wenige KiB großen Datei hat eine knappe halbe Sekunde Verzögerung bis zum Prompt nach sich gezogen.
* beim Aufrufen von eher kleinen Programmen wie <code>cat</code>, <code>grep</code>, <code>sed</code>, u. Ä. bei denen ebenfalls nach dem Beenden der Funktion der Shell-Prompt im Vergleich zum Vorgängersystem dann doch einen Ticken zu lange brauchte bis er wieder erschien.

== Analyse ==
Dank eines guten Freundes, der dies auf dem gegebenen System ebenfalls beobachten konnte, ließ sich das Problem eingrenzen. Das temporäre Verzeichnis <code>/tmp</code> ist auf meinem System eine RAM-Disk. Forciert man das Anlegen der ''vim''-Recoverydateien dort drin, war das Ruckeln im Editor komplett verschwunden. Es konnte sich somit nur um ein I/O-Problem handeln.

Meine Recherchen haben ergeben, dass der Marvell-Chipsatz sich als [[wikipedia:Advanced Host Controller Interface|AHCI]] am System meldet, und das Kernelmodul ''ahci.ko'' noch zwei Parameter beherrscht:
* <code>marvell_enable</code> soll dazu da sein, manche Marvell-Chipsätze in den SATA-Mode zu zwingen.
* <code>mobile_lpm_policy</code><ref>Dies soll ''demnächst'' in ''lpm_policy'' umbenannt werden, weil es nicht nur Notebooks betrifft.</ref> zur Konfiguration des Standard-Stromsparmodus, der in <code>/sys/class/scsi_host/host''n''/link_power_management_policy</code> eingesehen werden kann.

Da die Ports standardmäßig im Sysfs auf ''max_performance'' standen, habe ich diesen Parameter nicht weiter getestet.

== Lösung ==
Der Test mit ''marvell_enable=1'' verlief positiv. Das Ruckelproblem war damit verschwunden.

<syntaxhighlight lang="shell">
echo "options ahci marvell_enable=1" > /etc/modprobe.d/ahci.conf
update-initramfs -u
reboot
</syntaxhighlight>

== Fußnoten ==
<references />

[[Kategorie: Hardware]]
[[Kategorie: Linux]]
[[Kategorie: Storage]]

Kategorie:AS/400

2026-03-13T19:24:05Z

PoC: +Link

Alles über AS/400 und OS/400 bzw. deren Nachfolgesysteme. Innerhalb dieser KB werden
* IBM AS/400
* IBM System i
* IBM i
synonym verwendet. Ein einzelnen Foren ist zu lesen, dies wäre falsch, allerdings ist der grundlegende Aufbau der Systemarchitektur seit der Einführung der S/38 im Jahre 1978 unverändert, wenn auch wesentlich erweitert.

Die aufgeführten Artikel beziehen sich, soweit nicht anders angegeben, auf OS/400 V4R4 bzw. V4R5.

Weitere Inhalte in Englischer Sprache finden sich in [https://try-as400.pocnet.net/ try-as400.pocnet.net].

== Weblinks ==
* [http://www.astradyne.net/manuals.php AS/400 Manuals], Spiegel/Archiv bei Astradyne.net.

[[Kategorie:Hardware]]
[[Kategorie:Software]]
[[Kategorie:IBM i]]
[[Kategorie:System i]]

Cisco-Router als Konsolenserver konfigurieren

2026-03-12T16:34:33Z

PoC: Querverlinkung

Einige '''Cisco-Router''', wie z. B. 2511 oder neuere Modelle mit entsprechenden Multiseriellkarten (siehe [[#Weblinks|Weblinks]] lassen sich prima als Konsoleserver einrichten. Dies stellt quasi den umgekehrten Fall eines [[Cisco-Router als Terminalserver konfigurieren|Terminalservers]] dar: Per ''telnet'' (oder je nach IOS/Gerätekombination auch ''ssh'' oder exotischere Protokolle wie DEC ''MOP'') lässt sich ein Seriellport am Gerät ansprechen. 
Die notwendigen Octal-Breakoutkabel haben an ihrem anderen Ende einen normalen RJ45 (genauer 8P8C)-Stecker mit der passenden Pinbelegung für den Konsolenport der Cisco-Geräte.

Mit dem nachfolgenden Konfigurationsauschnitt genügt ein ''telnet'' auf die jeweilige IP-Adresse, die unten als ''ip alias'' hinterlegt ist, damit die Sitzung ohne weiteres zutun auf den entsprechenden Seriellport verbunden wird. Ich habe hier bewusst auf eine vorherige Passwortabfrage verzichtet, da die dahinterliegenden Geräte selbst auf der Konsole geschützt sein sollten.

Einsatzszenarien sind z. B. Notzugänge via Konsoleport auf beim GAU ansonsten unerreichbare zentrale Infrastrukturkomponenten oder falls mehrere Geräte zeitsparend gleichzeitig konfiguriert werden sollen.

aaa new-model
!
aaa authentication login default local
aaa authentication login serial-lines none
aaa authorization exec default local
aaa authorization commands 0 serial-lines none
no aaa authorization console
!
ip alias 172.24.25.91 2001
ip alias 172.24.25.92 2002
ip alias 172.24.25.93 2003
ip alias 172.24.25.94 2004
ip alias 172.24.25.95 2005
ip alias 172.24.25.96 2006
ip alias 172.24.25.97 2007
ip alias 172.24.25.98 2008
!
line 1 8
no motd-banner
no exec
authorization commands 0 serial-lines
login authentication serial-lines
modem Host
international
transport input all
transport output all
escape-character 3
flowcontrol hardware

Dieser Vorgang nennt sich ''reverse-telnet''. Die TCP-Portnummer ergibt sich aus der Line-Nummer + 2000. Ein ''show line'' auf der Kommandozeile gibt hier genauer Auskunft.

== Siehe auch ==
* [[Cisco-Router als Terminalserver konfigurieren]]

== Weblinks ==
* [http://www.cisco.com/c/en/us/td/docs/ios/12_2/dial/configuration/guide/fdial_c.html Cisco IOS Dial Technologies Configuration Guide, Release 12.2] auf www.cisco.com
* [http://www.cisco.com/c/en/us/support/docs/routers/3600-series-multiservice-platforms/7260-hw-as.html Understanding 4-Port and 8-Port Async/Sync Network Modules] auf www.cisco.com
* [http://www.cisco.com/c/en/us/support/docs/routers/3600-series-multiservice-platforms/7258-hw-async.html Understanding 16- and 32-Port Async Network Modules] auf www.cisco.com
* [http://ciscofaq.blogspot.de/2005/05/how-to-i-reverse-telnet-out-my-aux.html How do I reverse telnet out my aux port?] auf Ciscofaq.blogspot.de.

[[Kategorie:Cisco]]
[[Kategorie:Netzwerk]]

Cisco-Router als Terminalserver konfigurieren

2026-03-12T16:34:29Z

PoC: Querverlinkung

Für einige '''Cisco-Router''', wie z. B. 801/803er ISDN-Router existiert heutzutage fast keine sinnvolle Anwendungsmöglichkeit mehr. Die Geräte lassen sich aber gut als Terminalserver rekonfigurieren: An den Konsole-Port lässt sich ein serielles Terminal wie z. B. das [[MAI DT4315A Serielles Terminal|MAI DT4315A]] anschliessen.

Mit dem nachfolgenden Konfigurationsauschnitt genügt dann auf dem Terminal ein Return und eine Telnet-Verbindung auf den angegebenen Host wird geöffnet. Diese Konfiguration kann sogar seriell vorgenommen werden, ohne dass man aus der Konsolensitzung rausfliegt.

aaa new-model
!
aaa authentication login default local
aaa authentication login serial-lines none
aaa authorization exec default local
aaa authorization commands 0 serial-lines none
no aaa authorization console
!
line con 0
no motd-banner
exec-timeout 0 0
authorization commands 0 serial-lines
login authentication serial-lines
autocommand telnet 192.168.1.100
international
transport output telnet
stopbits 1
flowcontrol software

Leider sind diese Geräte relativ langsam, mit XON/XOFF-Flusssteuerung gibt es mit Geschwindigkeiten > 9600 Bps verlorene Zeichen, insbesondere bei Curses-Applikationen. Falls das Terminal Hardwareflusssteuerung beherrscht, ist es sicher eine gute Idee, diese auch einzusetzen.

Falls nach der Konfiguration und abmelden aus dem EXEC nach einem Return wieder der EXEC-Prompt erscheint, muss in der Konfiguration noch ein vorhandenes <code>aaa authorization console</code> entfernt werden (mit ''no'').

== Siehe auch ==
* [[Cisco-Router als Konsolenserver konfigurieren]]

[[Kategorie:Cisco]]
[[Kategorie:Netzwerk]]

Linux von BIOS- auf UEFI-Boot umstellen

2026-03-05T17:23:16Z

PoC: /* Checkliste */ Besser mit Prüfung

Ohne zu wissen, was es mit EFI auf sich hat, ist das '''Umstellen von Linux von BIOS- auf EFI-Boot''' auf echter Serverhardware (die meistens minutenlang in der internen Firmware rumhängt) zeitraubend und frustrierend. In Kürze Erklärung und Wichtiges:

== Grundlagen ==
(U)EFI ((Unified) Extensible Firmware Interface) ist mit neuerer Hardware unvermeidbar. Eigentlich ist das Thema sehr einfach: Es gibt keinen binären Bootblock mehr, sondern eine kleine FAT32-Partition zu Beginn der Boot-Disk (ggfs. HW-RAID-Array). Die Bootloader der verschiedenen Betriebssysteme erzeugen eine Verzeichnisstruktur, in welcher dann das eigentliche Startprogramm hinterlegt wird. Die Firmware sammelt beim Systemstart eine Liste der gefundenen ausführbaren Binaries (PE32+ executable) und bietet diese dann zum Start an (bzw. der Standardeintrag wird gestartet).

== Vorbereitungen ==
* Ohne Repartitionieren geht es nicht. Da die Umstellung auf EFI durch einem Hardwaretausch mit anschließender Kopie der vorhandenen Installation durchgeführt wird, ist das aber kein Beinbruch.
* Der initiale Boot (CD, ISO-Image, PXE, USB-Stick, usw.) muss zwingend im EFI-Modus mit einem dementsprechend EFI-fähigen Bootmedium durchgeführt werden. Das Debian-Live-Image von Debian 8 oder älter ist nicht geeignet! Erst ab 9 gibt es EFI-Support, z. B. [https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.2.0-amd64-standard.iso debian-live-12.2.0-amd64-standard.iso]. Ohne Boot im EFI-Modus sind die EFI-Hooks in der Firmware unsichtbar und Grub-EFI wird mit Fehlern um sich werfen.

== Checkliste ==
* Neues System vorbereiten (FW-Updates, BIOS-Settings, usw.),
* Bootmedium vorbereiten (siehe oben),
* Boot via EFI-Bootmenü von diesem Medium,
* Ggfs. manuelle Netzwerkkonfiguration,
* Nachinstallation von benötigten Systemkomponenten,
apt-get install gdisk mdadm dosfstools dump
* Vorbereiten der Platten für das OS:
** Partitionieren (''gdisk''), dabei (eine) z. B. 5 MB große EFI-Partition(en) anlegen, Typ EF00,<ref>Tatsächlich benötigt werden vom Grub-Loader einige 100 KBytes.</ref>
** Ggfs. Erzeugen der gewünschten Arrays mit ''mdadm'',
** Dateisysteme erzeugen, dabei die EFI-Partition(en) mit einem FAT32-Dateisystem versehen,
mkfs.fat /dev/sda1,
** Mounten des OS-Dateisystems nach z. B. ''/mnt'', <code>cd /mnt</code>,
** Kopieren der Installation vom Quellsystem, wie gehabt mit
ssh ''srcsys'' "dump -0a -b 256 -f - /dev/sda1" |restore -r -b 256 -f -
** Vorbereitungen für ''chroot'': <code>mount -o bind /dev dev/</code>,
* <code>chroot /mnt</code>,
* Nachmounten von Kernel-Pseudo-Dateisystemen:
mount -t proc none /proc; mount -t sysfs none /sys; mount -t devpts none /dev/pts
* Anpassen der ''/etc/fstab'', dabei Eintragen der EFI-Partition(en),
/dev/sda1 /boot/efi vfat defaults 0 0
* Anlegen des EFI-Bootverzeichnisses,
mkdir /boot/efi
* Anpassen der ''/etc/fstab'', dabei Eintragen von ''efivars'':
none /sys/firmware/efi/efivars efivarfs defaults 0 0
* Mounten der EFI-Partition(en),
mount -a
* Nachinstallation von auf dem später laufenden System benötigten Systemkomponenten (mdadm),
* Ggfs. schreiben der RAID-Konfiguration mit <code>/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf; update-initramfs -u</code>,
* Austauschen von Grub,
apt-get install grub-efi-amd64 grub-efi-amd64-bin
* Sichern der Grub-Defaults,
cp -a /etc/default/grub /etc/default/grub~
* Löschen von altem Grub-PC-Kram, die Frage nach Löschen vom alten Bootloader bejahen,
dpkg -P grub-pc grub-pc-bin
* Restore der Grub-Defaults,
mv /etc/default/grub~ /etc/default/grub
* Restore von gemeinsamen Grub-Dateien durch Reinstallation,
apt-get install --reinstall grub-efi-amd64 grub-efi-amd64-bin

Grub-EFI erfordert keine Platte mehr als Parameter beim beim Grub-Install:
grub-install
update-grub

* Raus aus der chroot: <code>exit</code>,
* Unmounten:
umount boot/efi* dev/pts dev proc sys/firmware/efi/efivars sys && cd .. && umount mnt

Nach einem Reboot muss die Installation dann wieder sauber hochkommen. Weitere Schritte wie Netzwerkkonfigurationsanpassungen an die neue Hardware sind nicht beschrieben.

=== Mögliche Fehler ===
Aus der Praxis…

==== Meldung: EFI variables are not supported on this system ====
grub-install: warning: EFI variables are not supported on this system.

Dieser Fehler kann zum einen bedeuten, dass das System selbst im BIOS-Modus gestartet wurde. Allerdings scheint es ab Debian 11 notwendig zu sein, einen weiteren Mountpoint zu setzen:

none /sys/firmware/efi/efivars efivarfs defaults 0 0

Damit funktioniert dann auch ein <code>grub-install</code> fehlerfrei.

==== Nach Reboot erscheint nur die Grub-Kommandozeile ====
Falls das alte BIOS-Grub-Paket mit <code>--purge</code> gelöscht wurde, hätte '''unbedingt''' danach ein
grub-install
update-grub
abgesetzt werden müssen, da das Purge des BIOS-Paketes auch die Konfiguration und weitere Dateien löscht.

Lösung: Die Schritte von oben nochmal wiederholen:
* Boot von externem Medium,
* <code>chroot</code>,
* Mounten der benötigten Partitionen,
* Grub-Konfiguration neu schreiben:
grub-install
update-grub
* <code>umount</code>,
* Reboot.

=== Redundanz ===
Beim Booten kann dann statt einem möglicherweise wechselnden Gerät, eine Boot-Konfiguration aus dem genannten Verzeichnis eines beliebigen Gerätes gestartet werden. Vorbei sind die Tage, in denen in einem Software-RAID die erste Platte ausfällt, die zweite Platte dann an die erste Stelle rückt, der Bootblock ist aber nicht auf die erste Platte konfiguriert, sondern entweder überhaupt nicht<ref>Schlampiger Admin…</ref> oder das BIOS kommt mit der neuen BIOS-ID (0x80 statt 0x81) nicht zurecht und verweigert den Boot.

EFI hat allerdings eine konzeptionelle Schwachstelle: Die Einfachhheit eine ''/boot''-Partition per Software-RAID zu spiegeln ist nicht vorgesehen. Man kann sich was basteln über ''mdadm'' mit nicht persistentem Superblock (damit keine Daten überschrieben werden), aber das ist letztlich alles Gebastel. 
Am Einfachsten ist es, manuell die Verzeichnisstruktur auf die zuvor manuell identisch partitionierten und in ''/boot/efi2'', ''/boot/efi3'', usw. gemounteten FAT32-Partitionen zu kopieren.

Für Debian muss eine Datei angelegt und als ausführbar markiert werden: ''/etc/grub.d/42_update-hook'':
#!/bin/sh
# Dirty hack: If there are multiple FA32-mountpoints in /boot/efi, sync
# contents manually to provide poor man's redundancy.
if mount -t vfat |awk '{print $3}' |grep -q '^/boot/efi$'; then
cat /dev/null > /var/log/update-grub.log
for MP in `mount -t vfat |awk '{print $3}' |grep -v '^/boot/efi$'`; do
rsync -av --delete /boot/efi/ ${MP}/ >> /var/log/update-grub.log
done
else
echo "No EFI Mount Point detected." > /var/log/update-grub.log
fi

# --EOF--

Bei jedem Aufruf, der die Grub-Konfiguration neu erzeugt, wird somit auch die Struktur kopiert. Das beinhaltet auch Updates von Kernel und Grub selbst. Fire and forget.

== Weblinks ==
* [https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/ UEFI booting and RAID1]
* [https://www.heise.de/newsticker/meldung/Was-Linux-Anwender-ueber-UEFI-wissen-muessen-4204725.html Was Linux-Anwender über UEFI wissen müssen]
* [https://packages.debian.org/stable/bootcd Run your system from cd without need for disks]<ref>Ob das EFI kompatible Images herstellt, ist derzeit nicht bekannt.</ref>
* [https://wiki.debian.org/EFIStub …it is possible to load the kernel directly, without any additional bootloader]

== Fußnoten ==
<references />

[[Kategorie: Linux]]

Debian-Live Netzbootsystem

2025-11-06T09:28:08Z

PoC: /* Weblinks */ +link

Die Möglichkeit, hinreichend aktuelle Maschinen (allgemein, also VMs oder auch Blech) über das LAN zu booten ist eine feine Sache. Bare Metal Restore, oder auch die Offline-Korrektur von Fehlern wie z. B. zu kleinen Partitionen, etc. wird damit zum Kinderspiel.

Das '''Debian-Live'''-Projekt hat für Wiederherstellungszwecke eine Live-Boot CD-Serie bereitgestellt. Allerdings haben diese Images ein paar (teils subjektive) Nachteile:
* Gewohnte Konfigurationstools wurden durch modernere Varianten mit eigener Syntax abgelöst; ein Paradebeispiel ist das Fehlen von <code>ifconfig</code>.
* Hardware welche proprietäre Firmware-Binärdateien benötigt ist — vor allem wenn es um Netzwerkkarten geht — außen vor; ein Booten vom Netz geht spätestens nach dem Starten des Kernels schief.
* Viele weitere Pakete mit fast immer benötigten Tools fehlen und müssen immer und immer wieder per Hand nachinstalliert werden.
* Ssh-Zugriff ist standardmäßig erstmal nicht möglich. Das ist besonders schmerzhaft für Server mit wackeligem und bocklahmem Remote-Management, die dann Textmode über VNC-ähnliche Protokolle übertragen. Von den Schwierigkeiten mit Sonderzeichen auf der Tastatur ganz zu schweigen.

Der Artikel beschreibt die notwendigen Schritte, dieses Netzbootsystem auf einem existierenden Debian Linux 12 (Bookworm) aufzusetzen. Ob die zu startende Maschine ein älteres BIOS-basiertes System ist oder ein neueres EFI-System, ist egal: Beides wird dynamisch anhand von DHCP-Optionen passend konfiguriert. Danach kann zum Bootzeitpunkt ausgewählt werden, ob ein 32- oder ein 64-Bit-System gestartet werden soll.

Es ist selbstverständlich möglich, weitere via PXE zu startende Betriebssysteme einzubinden. Wichtig ist zu beachten, dass die via TFTP bereitgestellten Dateien in den entsprechenden Unterverzeichnissen für die verschiedenen "Architekturen" zu hinterlegen sind (bios, efi32, efi64).

<blockquote>'''Hinweis''': Das von mir benutzte System ist traditionell mit ''SysV-init'' ausgerüstet. ''Systemd'' wird nicht benutzt. Die hier aufgeführten Schritte sind ansonsten so generisch wie möglich gehalten.</blockquote>

== Benötigte Komponenten ==
* ''DHCP-Server'' für die Zuweisung grundlegender Netzwerkparameter,
* ''TFTP-Server'' für den initialen Download von Bootloader, Menü und anschließend Kernel und Initrd,
* ''NFS-Server'' für den Zugriff auf das komprimierte Root-Dateisystem,
* ''Scripte'' zur Erstellung des übers Netz geladenen Root-Dateisystems.

Installation:
apt-get install debootstrap genisoimage isc-dhcp-server isolinux nfs-kernel-server openbsd-inetd pxelinux squashfs-tools syslinux-common syslinux-efi tftp-hpa tftpd-hpa

== DHCP-Konfiguration ==
<blockquote>'''Hinweis''': Im lokalen Netzwerksegment soll nur '''ein''' DHCP-Server aktiv sein. Sind es mehrere, ist es mehr oder weniger Zufall, welches Antwortpaket der anfragende Client zuerst bearbeitet. Sollte also schon ein DHCP-Server existieren, muss die gezeigte Konfiguration in die Konfiguration des bestehenden Servers mit eingebaut werden. Durch die Benutzung von DHCP-Klassen ("class") ist dies im Regelfall aber sehr einfach möglich.</blockquote>

Der erste Start des noch nicht unkonfigurierten DHCP-Servers geht erfahrungsgemäß schief, dies kann ignoriert werden.

Weil hier nur IPv4 berücksichtigt wird, muss in ''/etc/default/isc-dhcp-server die Zeile ''INTERFACESv6'' gelöscht werden. Ebenso muss in ''INTERFACESv4'' das für DHCP zu verwendenden Netzwerkinterface eingetragen werden. Beispiel:
INTERFACESv4="eth0"

Dies ist ein '''Beispiel''' für eine DHCP-Konfiguration! Insbesondere der ''group''-Abschnitt muss auf die lokalen Gegebenheiten angepasst werden!
<syntaxhighlight lang="shell">
authoritative;
ddns-updates off;
default-lease-time 3600;
log-facility daemon;
max-lease-time 86400;
min-lease-time 300;
min-secs 0;

option architecture-type code 93 = unsigned integer 16; # RFC4578

# Route different kinds of requesting clients to distinct PXE bootloaders.
class "pxeclients" {
match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";

if option architecture-type = 00:00 {
filename "/var/tftpboot/bios/lpxelinux.0";
} elsif option architecture-type = 00:06 {
filename "/var/tftpboot/efi32/syslinux.efi";
} elsif option architecture-type = 00:07 {
filename "/var/tftpboot/efi64/syslinux.efi";
} elsif option architecture-type = 00:09 {
filename "/var/tftpboot/efi64/syslinux.efi";
}

# This is the TFTP server's IP address.
next-server 192.168.111.10;
}

# Ethernet
group {
option broadcast-address 192.168.111.255;
option domain-name "pocnet.net";
option domain-name-servers 192.168.111.10;
option ntp-servers 192.168.111.10;
option routers 192.168.111.1;
option subnet-mask 255.255.255.0;

subnet 192.168.111.0 netmask 255.255.255.0 {
range 192.168.111.120 192.168.111.126;
}
}
</syntaxhighlight>

Nun kann der DHCP-Server gestartet werden:
service isc-dhcp-server start

== TFTP-Server ==
Die Konfiguration des Servers findet sich in ''/etc/default/tftpd-hpa''. Dort müssen folgende Änderungen durchgeführt werden:
* Ändern des Pfades ''/srv/tftp'' nach ''/var/tftpboot'',<ref>Ist kein Muss, aber in dieser Anleitung wird dieser Pfad vorausgesetzt.</ref>
* Ändern der ''TFTP_OPTIONS'':<ref>Dies ist notwendig, damit die später angelegten Symlinks auch aufgelöst werden.</ref>
** Löschen von <code>--secure</code>,
** Hinzufügen von <code>--permissive -v</code>.

Nun kann der alte Pfad gelöscht werden und der neue angelegt:
rmdir /srv/tftp
mkdir /var/tftpboot

Als letztes sollte der TFTP-Server neu gestartet werden:
service tftpd-hpa restart

=== Inhalte für <code>/var/tftpboot</code> ===
Zuerst werden ein paar grundlegende Verzeichnisse für die benötigten Dateien angelegt:
cd /var/tftpboot
mkdir -p deb-live/amd64 deb-live/i686 bios efi32 efi64 pxelinux.cfg

Für die einzelnen Architekturen werden nun die benötigten Bootdateien über Symlinks bereit gestellt. Symlinks brauchen weniger Speicher und wenn das Original (wegen Aktualisierungen) ausgetauscht wird, braucht man nicht manuell nachbessern.

<syntaxhighlight lang="shell">
# BIOS-Loaders
cd bios
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/bios/ldlinux.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/pxechn.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/vesamenu.c32 .
ln -s ../../../usr/lib/PXELINUX/lpxelinux.0 .

# EFI32-Loaders
cd ../efi32
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/efi32/ldlinux.e32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/vesamenu.c32 .
ln -s ../../../usr/lib/SYSLINUX.EFI/efi32/syslinux.efi .

# EFI64-Loaders
cd ../efi64
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/efi64/ldlinux.e64 .
ln -s ../../../usr/lib/syslinux/modules/efi64/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/vesamenu.c32 .
ln -s ../../../usr/lib/SYSLINUX.EFI/efi64/syslinux.efi .
</syntaxhighlight>

Um die Pflege des PXE-Bootmenüs zu vereinfachen, wird eine "globale" Konfiguration in ''/var/tftpboot/pxelinux.cfg'' (der Standardname, mit dem die PXE-Loader nach der Konfiguration suchen) für alle Architekturen via Symlinks zugänglich gemacht.

Die eigentliche Konfiguration für das Bootmenü findet sich in der Datei ''/var/tftpboot/pxelinux.cfg/default'':
menu title Boot menu
menu tabmsg Press ENTER to boot or TAB to edit a menu entry
prompt 0
timeout 600

label deblive64
menu label Debian Live ^amd64
kernel deb-live/amd64/vmlinuz
append initrd=deb-live/amd64/initrd.img net.ifnames=0 biosdevname=0 ip=:::::eth0:dhcp boot=live netboot=nfs root=/dev/nfs nfsroot=192.168.1.10:/var/nfsboot/deb-live/amd64 live-media-path=/ consoleblank=0 nfsrootdebug

label deblive32
menu label Debian Live ^i686
kernel deb-live/i686/vmlinuz
append initrd=deb-live/i686/initrd.img net.ifnames=0 biosdevname=0 ip=:::::eth0:dhcp boot=live netboot=nfs root=/dev/nfs nfsroot=192.168.1.10:/var/nfsboot/deb-live/amd64 live-media-path=/ consoleblank=0 nfsrootdebug

label bootlocal
menu label Boot ^local disk
menu default
localboot 0

ui menu.c32

Anmerkungen:
* <code>net.ifnames=0 biosdevname=0</code> stellt die ursprüngliche Netzwerkinterfacebenennung vom Kernel wieder her, damit die Netzwerkschnittstelle überall wieder ''eth0''heißt und diese wiederum in der <code>ip=</code>-Konfigurationszeile statisch referenziert werden kann.<ref>Früher hat die Autokonfiguration bei mehreren vorhandenen Netzwerkschnittstellen nicht zuverlässig funktioniert, deswegen der gezeigte Workaround.</ref>
* Das Zirkumflex (<code>^</code>) dient als Hervorhebung für einen Buchstaben im Menü. Dieser Buchstabe auf der Tastatur eingegeben aktiviert diesen Menüeintrag.

== NFS-Server ==
In der Datei ''/etc/exports'' wird definiert, welche Hosts auf welche Verzeichnisse Zugriff haben:
/var/nfsboot 192.168.1.0/24(ro,no_root_squash,insecure,no_subtree_check)

Nun müssen die Verzeichnisse für das Rootdateisystem noch angelegt werden:
mkdir -p /var/nfsboot/deb-live/amd64 /var/nfsboot/deb-live/i686

Damit die Änderungen ziehen, einmal den (mangels gültiger Einträge in ''exports'' sowieso nicht gestarteten) NFS-Server starten:
service nfs-kernel-server start

== Root-Dateisystem ==
Dies wird über eine "frische" Installation von Debian jeweils von Grund auf neu erzeugt:
* Debootstrap,
* Konfigurationsanpassungen,
* Squashfs-Build.

Das folgende Script kann mit den Parametern ''amd64'' oder ''i686'' aufgerufen werden und erzeugt jeweils ein Squashfs in den zuvor angelegten Verzeichnissen in ''/var/nfsboot''.

<syntaxhighlight lang="shell">
#!/bin/bash

# Must run as root.
if ! id |grep -Fq 'uid=0(root) gid=0(root) groups=0(root)'; then
echo "Must run as root."
exit 1
fi

# Must supply what to build.
if [ -z "${1}" ]; then
echo "Give arch as argument: amd64 or i686."
exit 0
fi

# Check what to build.
if [ "${1}" == "amd64" ]; then
DST_ARCH="amd64"
elif [ "${1}" == "i686" ] || [ "${1}" == "i386" ]; then
DST_ARCH="i686"
else
echo "Give arch as argument: amd64 or i686."
exit 0
fi

# Automatically clean up when we terminate.
trap '{ umount ${TMPMNT} && rmdir ${TMPMNT}; rm -f ${TMPIMG}; }' EXIT

# Terminate on error.
set -e

# Temporary image file and mount point to work within.
TMPIMG=$(mktemp --tmpdir=/var/tmp live-image.XXXXXXXXXX)
TMPMNT=$(mktemp -d --tmpdir=/var/tmp live-root.XXXXXXXXXX)

# Prepare image file and mount.
fallocate -v -l 4GiB "${TMPIMG}"
mke2fs -t ext4 -E lazy_itable_init=0 -O ^has_journal -i 16384 -L live-build -F "${TMPIMG}"
tune2fs -r0 -c0 -i12m -o '^acl,nobarrier' -e remount-ro -f "${TMPIMG}"
mount -o loop "${TMPIMG}" "${TMPMNT}"

# Install system.
if [ "${DST_ARCH}" == "amd64" ]; then
ARCH_ARG="--arch=amd64"
PKGLIST="console-setup, \
dosfstools, \
dump, \
firmware-amd-graphics, \
firmware-bnx2, \
firmware-bnx2x, \
firmware-linux-free, \
firmware-misc-nonfree, \
gdisk, \
ifupdown, \
isc-dhcp-client, \
kbd, \
keyboard-configuration, \
linux-image-amd64, \
live-boot, \
locales, \
lsscsi, \
lvm2, \
mdadm, \
mt-st, \
net-tools, \
nfs-common, \
openssh-client, \
openssh-server, \
orphan-sysvinit-scripts, \
pciutils, \
pv, \
sg3-utils, \
sysvinit-core"
elif [ "${DST_ARCH}" == "i686" ]; then
ARCH_ARG="--arch=i386"
PKGLIST="console-setup, \
dump, \
firmware-linux-free, \
ifupdown, \
isc-dhcp-client, \
kbd, \
keyboard-configuration, \
linux-image-686-pae, \
live-boot, \
locales, \
lsscsi, \
lvm2, \
mdadm, \
mt-st, \
net-tools, \
nfs-common, \
openssh-client, \
openssh-server, \
orphan-sysvinit-scripts, \
pciutils, \
pv, \
sg3-utils, \
sysvinit-core"
fi

# Parameter strings for debootstrap must not include blanks.
PKGLIST_CLEAN="$(echo "${PKGLIST}" |tr -d ' ')"
debootstrap "${ARCH_ARG}" --components=main,non-free,non-free-firmware,contrib \
--include "${PKGLIST_CLEAN}" \
--exclude nano,systemd-sysv,tasksel,tasksel-data \
bookworm "${TMPMNT}" https://debian.inf.tu-dresden.de/debian/

# Prepare system.
echo "debian-live" > "${TMPMNT}"/etc/hostname
cat > "${TMPMNT}"/etc/default/keyboard <<-EOF
# Check /usr/share/doc/keyboard-configuration/README.Debian for
# documentation on what to do after having modified this file.

# The following variables describe your keyboard and can have the same
# values as the XkbModel, XkbLayout, XkbVariant and XkbOptions options
# in /etc/X11/xorg.conf.

XKBMODEL="pc105"
XKBLAYOUT="de"
XKBVARIANT=""
XKBOPTIONS=""

# If you don't want to use the XKB layout on the console, you can
# specify an alternative keymap. Make sure it will be accessible
# before /usr is mounted.
# KMAP=/etc/console-setup/defkeymap.kmap.gz
BACKSPACE="guess"
EOF

# Clean apt lists to save space. They might be outdated anyway and need to be retransferred.
rm -f "${TMPMNT}"/var/lib/apt/lists/* 2>/dev/null || true

# Set default locale.
echo "LANG=en_US.UTF-8" > "${TMPMNT}"/etc/environment

# Add default password entry.
sed '/^root:/ d' "${TMPMNT}"/etc/shadow > "${TMPMNT}"/etc/shadow~
echo 'root::17852:0:99999:7:::' > "${TMPMNT}"/etc/shadow
cat "${TMPMNT}"/etc/shadow~ >> "${TMPMNT}"/etc/shadow

# Help with ssh-remote-logins.
echo "PermitRootLogin yes" >> "${TMPMNT}"/etc/ssh/sshd_config
echo "PermitEmptyPasswords yes" >> "${TMPMNT}"/etc/ssh/sshd_config

# Switch initrd to gzip.
sed -Ei 's/^COMPRESS=zstd$/COMPRESS=gzip/' "${TMPMNT}"/etc/initramfs-tools/initramfs.conf

# Prepare system to rebuild initramfs
mount -o bind /dev "${TMPMNT}"/dev
mount -o bind /dev/pts "${TMPMNT}"/dev/pts
mount -t proc none "${TMPMNT}"/proc
mount -t sysfs none "${TMPMNT}"/sys
echo "Please run these commands:"
# FIXME: How to automate this manual process?
echo ' echo "locales locales/default_environment_locale select en_US.UTF-8" |debconf-set-selections'
echo ' echo "locales locales/locales_to_be_generated multiselect en_US.UTF-8 UTF-8" |debconf-set-selections'
echo " dpkg-reconfigure locales"
echo " update-initramfs -u"
echo "then exit chroot."
chroot "${TMPMNT}"

# Script resumes after chroot exit.
umount "${TMPMNT}"/dev/pts "${TMPMNT}"/dev "${TMPMNT}"/proc "${TMPMNT}"/sys

# Copy Kernel and initramfs for TFTP.
cp -v "${TMPMNT}"/vmlinuz "${TMPMNT}"/initrd.img /var/tftpboot/deb-live/"${DST_ARCH}"

# Compress into a file for NFS serving.
mksquashfs "${TMPMNT}" /var/nfsboot/deb-live/"${DST_ARCH}"/filesystem.squashfs -noappend

# Generate ISO image for booting.
# Note: This currently works only for BIOS.
#genisoimage -rational-rock -cache-inodes -joliet -full-iso9660-filenames \
# -input-charset UTF-8 -f -b isolinux/isolinux.bin -c isolinux/boot.cat \
# -no-emul-boot -boot-load-size 4 -boot-info-table \
# -o /var/tmp/debian-boot-"${DST_ARCH}".iso /var/nfsboot/deb-live/"${DST_ARCH}"

# vim: tabstop=4 shiftwidth=4 autoindent expandtab
</syntaxhighlight>

* Die Paketliste in ''$PKGLIST'' ist darauf zugeschnitten, die für eine schnelle Wiederherstellung notwendigen Komponenten zu beinhalten.

== Test ==
Wenn nichts falsch gemacht wurde, so bezieht der Client nun beim Netzboot eine IP-Adresse vom DHCP-Server und lädt die PXE-Dateien, um im Anschluss ein Menü anzuzeigen, was denn nun gestartet werden soll. Nach der Auswahl eines Punktes werden Kernel und Initrd per TFTP übermittelt und der Kernel gestartet. Per erneuter DHCP-Anfrage erhält der Kernel gültige Netzparameter und mountet nun das per NFS zugängliche Squashfs als ''root''. Ab dann ist das Debian-Live-System aktiv.

In ''/var/log/daemon.log'' finden sich Meldungen vom TFTP-Server, was hilfreich bei der Fehlersuche sein kann.

== Anpassungen für ISO-Generation ==
Als quasi "Abfallprodukt" kann aus dem sowieso schon vorhandenen Squashfs ein ISO-Image erzeugt werden, als zweiter Weg zum Booten von einem System. Falls das gewünscht ist, muss der entsprechende Aufruf von ''genisoimage'' im weiter oben gezeigten Script einkommentiert werden.

Die hierzu notwendigen Pakete ''genisoimage'' und ''isolinux'' wurden bereits oben installiert. Im Endeffekt fehlen eine Handvoll Dateien (Symlinks) und eine Konfigurationsdatei für Isolinux.

Die Konfiguration für das Bootmenü beim Boot vom ISO-Image muss in der Datei ''/var/nfsboot/deb-live/isolinux.cfg'' gespeichert werden:
prompt 0
menu title Boot Menu
menu tabmsg Press ENTER to boot or TAB to edit a menu entry
timeout 20

label linux
menu label ^Debian Live
kernel /boot/vmlinuz
append initrd=/boot/initrd.img net.ifnames=0 biosdevname=0 boot=live live-media-path=/ consoleblank=0
menu default

label bootlocal
menu label Boot ^local disk
localboot 0

ui menu.c32

Danach werden noch ein paar zum Booten notwendige Verzeichnisse und Symlinks zu Dateien angelegt. Symlinks brauchen weniger Speicher und wenn das Original (wegen Aktualisierungen) ausgetauscht wird, braucht man nicht manuell nachbessern. Da ''genisoimage'' mit dem Parameter <code>-f</code> aufgerufen wird, landen im Image keine Symlinks, sondern die eigentlichen Dateien (dereference).

<syntaxhighlight lang="shell">
cd /var/nfsboot/deb-live
mkdir amd64/boot amd64/isolinux i686/boot i686/isolinux

# Symlinks für Kernel und Initrd.
cd amd64/boot
ln -sf ../../../../tftpboot/deb-live/amd64/* .
cd ../../i686/boot
ln -sf ../../../../tftpboot/deb-live/i686/* .

# Boot-Dateien von Isolinux und Syslinux (Menü!) einbauen.
cd ../../amd64/isolinux
ln -s ../../isolinux.cfg .
ln -s ../../../../../usr/lib/ISOLINUX/isolinux.bin .
ln -s ../../../../../usr/lib/syslinux/modules/bios/ldlinux.c32 .
ln -s ../../../../../usr/lib/syslinux/modules/bios/libutil.c32 .
ln -s ../../../../../usr/lib/syslinux/modules/bios/menu.c32 .

# Boot-Dateien von Isolinux und Syslinux (Menü!) einbauen.
cd ../../i686/isolinux
ln -s ../../isolinux.cfg .
ln -s ../../../../../usr/lib/ISOLINUX/isolinux.bin .
ln -s ../../../../../usr/lib/syslinux/modules/bios/ldlinux.c32 .
ln -s ../../../../../usr/lib/syslinux/modules/bios/libutil.c32 .
ln -s ../../../../../usr/lib/syslinux/modules/bios/menu.c32 .
</syntaxhighlight>

== Weblinks ==
* [https://kb.isc.org/docs/aa-00333 Where to find ISC DHCP documentation?], ISC.org
* [https://forum.tinycorelinux.net/index.php/topic,22863.0.html Topic: How To HTTP PXE Boot], Tiny Core Linux

== Fußnoten ==
<references />

[[Kategorie:Linux]]

Benutzer:PoC

2025-10-01T19:16:59Z

PoC: /* Von mir verfaßte bzw. überarbeitete Artikel */ -lin

== Begriffserklärung ==
PoC steht in meinem Falle für die genauere Beschreibung meines Vornamens: '''P'''atrik '''o'''hne '''C''' - man schreibt mich Patrik.

== Links ==
* [http://www.pocnet.net/ Offizielle Heimseite von mir]

== Von mir verfaßte bzw. überarbeitete Artikel ==
Können [[Spezial:Beiträge/PoC|hier]] nachgelesen werden. Ansonsten finden sich hier auch weniger computerzentrierte Artikel.

* [[Benutzer:PoC/Ursachen von Brummstörungen in Röhrenverstärkern]]

== Was später mal wird ==
* [[Benutzer:PoC/Solarheizung]]
* [[Benutzer:PoC/DCF77-Nixie-Röhrenuhr]]
* [[Benutzer:PoC/Stromversorgungsautarkie]]
* [[Benutzer:PoC/Mausefalle-Archive mit modernen Mitteln verfügbar machen]]
* [[Benutzer:PoC/Schlüssel und Zertifikat für AppleMail bereitstellen]]
* [[Benutzer:PoC/PostScript von LaserWriter 6 konvertieren]]
* [[Benutzer:PoC/Apple IIgs Netzwerk-Boot]]

Debian-Live Netzbootsystem

2025-09-02T21:47:40Z

PoC: /* Anpassungen für ISO-Generation */ Typo

Die Möglichkeit, hinreichend aktuelle Maschinen (allgemein, also VMs oder auch Blech) über das LAN zu booten ist eine feine Sache. Bare Metal Restore, oder auch die Offline-Korrektur von Fehlern wie z. B. zu kleinen Partitionen, etc. wird damit zum Kinderspiel.

Das '''Debian-Live'''-Projekt hat für Wiederherstellungszwecke eine Live-Boot CD-Serie bereitgestellt. Allerdings haben diese Images ein paar (teils subjektive) Nachteile:
* Gewohnte Konfigurationstools wurden durch modernere Varianten mit eigener Syntax abgelöst; ein Paradebeispiel ist das Fehlen von <code>ifconfig</code>.
* Hardware welche proprietäre Firmware-Binärdateien benötigt ist — vor allem wenn es um Netzwerkkarten geht — außen vor; ein Booten vom Netz geht spätestens nach dem Starten des Kernels schief.
* Viele weitere Pakete mit fast immer benötigten Tools fehlen und müssen immer und immer wieder per Hand nachinstalliert werden.
* Ssh-Zugriff ist standardmäßig erstmal nicht möglich. Das ist besonders schmerzhaft für Server mit wackeligem und bocklahmem Remote-Management, die dann Textmode über VNC-ähnliche Protokolle übertragen. Von den Schwierigkeiten mit Sonderzeichen auf der Tastatur ganz zu schweigen.

Der Artikel beschreibt die notwendigen Schritte, dieses Netzbootsystem auf einem existierenden Debian Linux 12 (Bookworm) aufzusetzen. Ob die zu startende Maschine ein älteres BIOS-basiertes System ist oder ein neueres EFI-System, ist egal: Beides wird dynamisch anhand von DHCP-Optionen passend konfiguriert. Danach kann zum Bootzeitpunkt ausgewählt werden, ob ein 32- oder ein 64-Bit-System gestartet werden soll.

Es ist selbstverständlich möglich, weitere via PXE zu startende Betriebssysteme einzubinden. Wichtig ist zu beachten, dass die via TFTP bereitgestellten Dateien in den entsprechenden Unterverzeichnissen für die verschiedenen "Architekturen" zu hinterlegen sind (bios, efi32, efi64).

<blockquote>'''Hinweis''': Das von mir benutzte System ist traditionell mit ''SysV-init'' ausgerüstet. ''Systemd'' wird nicht benutzt. Die hier aufgeführten Schritte sind ansonsten so generisch wie möglich gehalten.</blockquote>

== Benötigte Komponenten ==
* ''DHCP-Server'' für die Zuweisung grundlegender Netzwerkparameter,
* ''TFTP-Server'' für den initialen Download von Bootloader, Menü und anschließend Kernel und Initrd,
* ''NFS-Server'' für den Zugriff auf das komprimierte Root-Dateisystem,
* ''Scripte'' zur Erstellung des übers Netz geladenen Root-Dateisystems.

Installation:
apt-get install debootstrap genisoimage isc-dhcp-server isolinux nfs-kernel-server openbsd-inetd pxelinux squashfs-tools syslinux-common syslinux-efi tftp-hpa tftpd-hpa

== DHCP-Konfiguration ==
<blockquote>'''Hinweis''': Im lokalen Netzwerksegment soll nur '''ein''' DHCP-Server aktiv sein. Sind es mehrere, ist es mehr oder weniger Zufall, welches Antwortpaket der anfragende Client zuerst bearbeitet. Sollte also schon ein DHCP-Server existieren, muss die gezeigte Konfiguration in die Konfiguration des bestehenden Servers mit eingebaut werden. Durch die Benutzung von DHCP-Klassen ("class") ist dies im Regelfall aber sehr einfach möglich.</blockquote>

Der erste Start des noch nicht unkonfigurierten DHCP-Servers geht erfahrungsgemäß schief, dies kann ignoriert werden.

Weil hier nur IPv4 berücksichtigt wird, muss in ''/etc/default/isc-dhcp-server die Zeile ''INTERFACESv6'' gelöscht werden. Ebenso muss in ''INTERFACESv4'' das für DHCP zu verwendenden Netzwerkinterface eingetragen werden. Beispiel:
INTERFACESv4="eth0"

Dies ist ein '''Beispiel''' für eine DHCP-Konfiguration! Insbesondere der ''group''-Abschnitt muss auf die lokalen Gegebenheiten angepasst werden!
<syntaxhighlight lang="shell">
authoritative;
ddns-updates off;
default-lease-time 3600;
log-facility daemon;
max-lease-time 86400;
min-lease-time 300;
min-secs 0;

option architecture-type code 93 = unsigned integer 16; # RFC4578

# Route different kinds of requesting clients to distinct PXE bootloaders.
class "pxeclients" {
match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";

if option architecture-type = 00:00 {
filename "/var/tftpboot/bios/lpxelinux.0";
} elsif option architecture-type = 00:06 {
filename "/var/tftpboot/efi32/syslinux.efi";
} elsif option architecture-type = 00:07 {
filename "/var/tftpboot/efi64/syslinux.efi";
} elsif option architecture-type = 00:09 {
filename "/var/tftpboot/efi64/syslinux.efi";
}

# This is the TFTP server's IP address.
next-server 192.168.111.10;
}

# Ethernet
group {
option broadcast-address 192.168.111.255;
option domain-name "pocnet.net";
option domain-name-servers 192.168.111.10;
option ntp-servers 192.168.111.10;
option routers 192.168.111.1;
option subnet-mask 255.255.255.0;

subnet 192.168.111.0 netmask 255.255.255.0 {
range 192.168.111.120 192.168.111.126;
}
}
</syntaxhighlight>

Nun kann der DHCP-Server gestartet werden:
service isc-dhcp-server start

== TFTP-Server ==
Die Konfiguration des Servers findet sich in ''/etc/default/tftpd-hpa''. Dort müssen folgende Änderungen durchgeführt werden:
* Ändern des Pfades ''/srv/tftp'' nach ''/var/tftpboot'',<ref>Ist kein Muss, aber in dieser Anleitung wird dieser Pfad vorausgesetzt.</ref>
* Ändern der ''TFTP_OPTIONS'':<ref>Dies ist notwendig, damit die später angelegten Symlinks auch aufgelöst werden.</ref>
** Löschen von <code>--secure</code>,
** Hinzufügen von <code>--permissive -v</code>.

Nun kann der alte Pfad gelöscht werden und der neue angelegt:
rmdir /srv/tftp
mkdir /var/tftpboot

Als letztes sollte der TFTP-Server neu gestartet werden:
service tftpd-hpa restart

=== Inhalte für <code>/var/tftpboot</code> ===
Zuerst werden ein paar grundlegende Verzeichnisse für die benötigten Dateien angelegt:
cd /var/tftpboot
mkdir -p deb-live/amd64 deb-live/i686 bios efi32 efi64 pxelinux.cfg

Für die einzelnen Architekturen werden nun die benötigten Bootdateien über Symlinks bereit gestellt. Symlinks brauchen weniger Speicher und wenn das Original (wegen Aktualisierungen) ausgetauscht wird, braucht man nicht manuell nachbessern.

<syntaxhighlight lang="shell">
# BIOS-Loaders
cd bios
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/bios/ldlinux.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/pxechn.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/vesamenu.c32 .
ln -s ../../../usr/lib/PXELINUX/lpxelinux.0 .

# EFI32-Loaders
cd ../efi32
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/efi32/ldlinux.e32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/vesamenu.c32 .
ln -s ../../../usr/lib/SYSLINUX.EFI/efi32/syslinux.efi .

# EFI64-Loaders
cd ../efi64
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/efi64/ldlinux.e64 .
ln -s ../../../usr/lib/syslinux/modules/efi64/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/vesamenu.c32 .
ln -s ../../../usr/lib/SYSLINUX.EFI/efi64/syslinux.efi .
</syntaxhighlight>

Um die Pflege des PXE-Bootmenüs zu vereinfachen, wird eine "globale" Konfiguration in ''/var/tftpboot/pxelinux.cfg'' (der Standardname, mit dem die PXE-Loader nach der Konfiguration suchen) für alle Architekturen via Symlinks zugänglich gemacht.

Die eigentliche Konfiguration für das Bootmenü findet sich in der Datei ''/var/tftpboot/pxelinux.cfg/default'':
menu title Boot menu
menu tabmsg Press ENTER to boot or TAB to edit a menu entry
prompt 0
timeout 600

label deblive64
menu label Debian Live ^amd64
kernel deb-live/amd64/vmlinuz
append initrd=deb-live/amd64/initrd.img net.ifnames=0 biosdevname=0 ip=:::::eth0:dhcp boot=live netboot=nfs root=/dev/nfs nfsroot=192.168.1.10:/var/nfsboot/deb-live/amd64 live-media-path=/ consoleblank=0 nfsrootdebug

label deblive32
menu label Debian Live ^i686
kernel deb-live/i686/vmlinuz
append initrd=deb-live/i686/initrd.img net.ifnames=0 biosdevname=0 ip=:::::eth0:dhcp boot=live netboot=nfs root=/dev/nfs nfsroot=192.168.1.10:/var/nfsboot/deb-live/amd64 live-media-path=/ consoleblank=0 nfsrootdebug

label bootlocal
menu label Boot ^local disk
menu default
localboot 0

ui menu.c32

Anmerkungen:
* <code>net.ifnames=0 biosdevname=0</code> stellt die ursprüngliche Netzwerkinterfacebenennung vom Kernel wieder her, damit die Netzwerkschnittstelle überall wieder ''eth0''heißt und diese wiederum in der <code>ip=</code>-Konfigurationszeile statisch referenziert werden kann.<ref>Früher hat die Autokonfiguration bei mehreren vorhandenen Netzwerkschnittstellen nicht zuverlässig funktioniert, deswegen der gezeigte Workaround.</ref>
* Das Zirkumflex (<code>^</code>) dient als Hervorhebung für einen Buchstaben im Menü. Dieser Buchstabe auf der Tastatur eingegeben aktiviert diesen Menüeintrag.

== NFS-Server ==
In der Datei ''/etc/exports'' wird definiert, welche Hosts auf welche Verzeichnisse Zugriff haben:
/var/nfsboot 192.168.1.0/24(ro,no_root_squash,insecure,no_subtree_check)

Nun müssen die Verzeichnisse für das Rootdateisystem noch angelegt werden:
mkdir -p /var/nfsboot/deb-live/amd64 /var/nfsboot/deb-live/i686

Damit die Änderungen ziehen, einmal den (mangels gültiger Einträge in ''exports'' sowieso nicht gestarteten) NFS-Server starten:
service nfs-kernel-server start

== Root-Dateisystem ==
Dies wird über eine "frische" Installation von Debian jeweils von Grund auf neu erzeugt:
* Debootstrap,
* Konfigurationsanpassungen,
* Squashfs-Build.

Das folgende Script kann mit den Parametern ''amd64'' oder ''i686'' aufgerufen werden und erzeugt jeweils ein Squashfs in den zuvor angelegten Verzeichnissen in ''/var/nfsboot''.

<syntaxhighlight lang="shell">
#!/bin/bash

# Must run as root.
if ! id |grep -Fq 'uid=0(root) gid=0(root) groups=0(root)'; then
echo "Must run as root."
exit 1
fi

# Must supply what to build.
if [ -z "${1}" ]; then
echo "Give arch as argument: amd64 or i686."
exit 0
fi

# Check what to build.
if [ "${1}" == "amd64" ]; then
DST_ARCH="amd64"
elif [ "${1}" == "i686" ] || [ "${1}" == "i386" ]; then
DST_ARCH="i686"
else
echo "Give arch as argument: amd64 or i686."
exit 0
fi

# Automatically clean up when we terminate.
trap '{ umount ${TMPMNT} && rmdir ${TMPMNT}; rm -f ${TMPIMG}; }' EXIT

# Terminate on error.
set -e

# Temporary image file and mount point to work within.
TMPIMG=$(mktemp --tmpdir=/var/tmp live-image.XXXXXXXXXX)
TMPMNT=$(mktemp -d --tmpdir=/var/tmp live-root.XXXXXXXXXX)

# Prepare image file and mount.
fallocate -v -l 4GiB "${TMPIMG}"
mke2fs -t ext4 -E lazy_itable_init=0 -O ^has_journal -i 16384 -L live-build -F "${TMPIMG}"
tune2fs -r0 -c0 -i12m -o '^acl,nobarrier' -e remount-ro -f "${TMPIMG}"
mount -o loop "${TMPIMG}" "${TMPMNT}"

# Install system.
if [ "${DST_ARCH}" == "amd64" ]; then
ARCH_ARG="--arch=amd64"
PKGLIST="console-setup, \
dosfstools, \
dump, \
firmware-amd-graphics, \
firmware-bnx2, \
firmware-bnx2x, \
firmware-linux-free, \
firmware-misc-nonfree, \
gdisk, \
ifupdown, \
isc-dhcp-client, \
kbd, \
keyboard-configuration, \
linux-image-amd64, \
live-boot, \
locales, \
lsscsi, \
lvm2, \
mdadm, \
mt-st, \
net-tools, \
nfs-common, \
openssh-client, \
openssh-server, \
orphan-sysvinit-scripts, \
pciutils, \
pv, \
sg3-utils, \
sysvinit-core"
elif [ "${DST_ARCH}" == "i686" ]; then
ARCH_ARG="--arch=i386"
PKGLIST="console-setup, \
dump, \
firmware-linux-free, \
ifupdown, \
isc-dhcp-client, \
kbd, \
keyboard-configuration, \
linux-image-686-pae, \
live-boot, \
locales, \
lsscsi, \
lvm2, \
mdadm, \
mt-st, \
net-tools, \
nfs-common, \
openssh-client, \
openssh-server, \
orphan-sysvinit-scripts, \
pciutils, \
pv, \
sg3-utils, \
sysvinit-core"
fi

# Parameter strings for debootstrap must not include blanks.
PKGLIST_CLEAN="$(echo "${PKGLIST}" |tr -d ' ')"
debootstrap "${ARCH_ARG}" --components=main,non-free,non-free-firmware,contrib \
--include "${PKGLIST_CLEAN}" \
--exclude nano,systemd-sysv,tasksel,tasksel-data \
bookworm "${TMPMNT}" https://debian.inf.tu-dresden.de/debian/

# Prepare system.
echo "debian-live" > "${TMPMNT}"/etc/hostname
cat > "${TMPMNT}"/etc/default/keyboard <<-EOF
# Check /usr/share/doc/keyboard-configuration/README.Debian for
# documentation on what to do after having modified this file.

# The following variables describe your keyboard and can have the same
# values as the XkbModel, XkbLayout, XkbVariant and XkbOptions options
# in /etc/X11/xorg.conf.

XKBMODEL="pc105"
XKBLAYOUT="de"
XKBVARIANT=""
XKBOPTIONS=""

# If you don't want to use the XKB layout on the console, you can
# specify an alternative keymap. Make sure it will be accessible
# before /usr is mounted.
# KMAP=/etc/console-setup/defkeymap.kmap.gz
BACKSPACE="guess"
EOF

# Clean apt lists to save space. They might be outdated anyway and need to be retransferred.
rm -f "${TMPMNT}"/var/lib/apt/lists/* 2>/dev/null || true

# Set default locale.
echo "LANG=en_US.UTF-8" > "${TMPMNT}"/etc/environment

# Add default password entry.
sed '/^root:/ d' "${TMPMNT}"/etc/shadow > "${TMPMNT}"/etc/shadow~
echo 'root::17852:0:99999:7:::' > "${TMPMNT}"/etc/shadow
cat "${TMPMNT}"/etc/shadow~ >> "${TMPMNT}"/etc/shadow

# Help with ssh-remote-logins.
echo "PermitRootLogin yes" >> "${TMPMNT}"/etc/ssh/sshd_config
echo "PermitEmptyPasswords yes" >> "${TMPMNT}"/etc/ssh/sshd_config

# Switch initrd to gzip.
sed -Ei 's/^COMPRESS=zstd$/COMPRESS=gzip/' "${TMPMNT}"/etc/initramfs-tools/initramfs.conf

# Prepare system to rebuild initramfs
mount -o bind /dev "${TMPMNT}"/dev
mount -o bind /dev/pts "${TMPMNT}"/dev/pts
mount -t proc none "${TMPMNT}"/proc
mount -t sysfs none "${TMPMNT}"/sys
echo "Please run these commands:"
# FIXME: How to automate this manual process?
echo ' echo "locales locales/default_environment_locale select en_US.UTF-8" |debconf-set-selections'
echo ' echo "locales locales/locales_to_be_generated multiselect en_US.UTF-8 UTF-8" |debconf-set-selections'
echo " dpkg-reconfigure locales"
echo " update-initramfs -u"
echo "then exit chroot."
chroot "${TMPMNT}"

# Script resumes after chroot exit.
umount "${TMPMNT}"/dev/pts "${TMPMNT}"/dev "${TMPMNT}"/proc "${TMPMNT}"/sys

# Copy Kernel and initramfs for TFTP.
cp -v "${TMPMNT}"/vmlinuz "${TMPMNT}"/initrd.img /var/tftpboot/deb-live/"${DST_ARCH}"

# Compress into a file for NFS serving.
mksquashfs "${TMPMNT}" /var/nfsboot/deb-live/"${DST_ARCH}"/filesystem.squashfs -noappend

# Generate ISO image for booting.
# Note: This currently works only for BIOS.
#genisoimage -rational-rock -cache-inodes -joliet -full-iso9660-filenames \
# -input-charset UTF-8 -f -b isolinux/isolinux.bin -c isolinux/boot.cat \
# -no-emul-boot -boot-load-size 4 -boot-info-table \
# -o /var/tmp/debian-boot-"${DST_ARCH}".iso /var/nfsboot/deb-live/"${DST_ARCH}"

# vim: tabstop=4 shiftwidth=4 autoindent expandtab
</syntaxhighlight>

* Die Paketliste in ''$PKGLIST'' ist darauf zugeschnitten, die für eine schnelle Wiederherstellung notwendigen Komponenten zu beinhalten.

== Test ==
Wenn nichts falsch gemacht wurde, so bezieht der Client nun beim Netzboot eine IP-Adresse vom DHCP-Server und lädt die PXE-Dateien, um im Anschluss ein Menü anzuzeigen, was denn nun gestartet werden soll. Nach der Auswahl eines Punktes werden Kernel und Initrd per TFTP übermittelt und der Kernel gestartet. Per erneuter DHCP-Anfrage erhält der Kernel gültige Netzparameter und mountet nun das per NFS zugängliche Squashfs als ''root''. Ab dann ist das Debian-Live-System aktiv.

In ''/var/log/daemon.log'' finden sich Meldungen vom TFTP-Server, was hilfreich bei der Fehlersuche sein kann.

== Anpassungen für ISO-Generation ==
Als quasi "Abfallprodukt" kann aus dem sowieso schon vorhandenen Squashfs ein ISO-Image erzeugt werden, als zweiter Weg zum Booten von einem System. Falls das gewünscht ist, muss der entsprechende Aufruf von ''genisoimage'' im weiter oben gezeigten Script einkommentiert werden.

Die hierzu notwendigen Pakete ''genisoimage'' und ''isolinux'' wurden bereits oben installiert. Im Endeffekt fehlen eine Handvoll Dateien (Symlinks) und eine Konfigurationsdatei für Isolinux.

Die Konfiguration für das Bootmenü beim Boot vom ISO-Image muss in der Datei ''/var/nfsboot/deb-live/isolinux.cfg'' gespeichert werden:
prompt 0
menu title Boot Menu
menu tabmsg Press ENTER to boot or TAB to edit a menu entry
timeout 20

label linux
menu label ^Debian Live
kernel /boot/vmlinuz
append initrd=/boot/initrd.img net.ifnames=0 biosdevname=0 boot=live live-media-path=/ consoleblank=0
menu default

label bootlocal
menu label Boot ^local disk
localboot 0

ui menu.c32

Danach werden noch ein paar zum Booten notwendige Verzeichnisse und Symlinks zu Dateien angelegt. Symlinks brauchen weniger Speicher und wenn das Original (wegen Aktualisierungen) ausgetauscht wird, braucht man nicht manuell nachbessern. Da ''genisoimage'' mit dem Parameter <code>-f</code> aufgerufen wird, landen im Image keine Symlinks, sondern die eigentlichen Dateien (dereference).

<syntaxhighlight lang="shell">
cd /var/nfsboot/deb-live
mkdir amd64/boot amd64/isolinux i686/boot i686/isolinux

# Symlinks für Kernel und Initrd.
cd amd64/boot
ln -sf ../../../../tftpboot/deb-live/amd64/* .
cd ../../i686/boot
ln -sf ../../../../tftpboot/deb-live/i686/* .

# Boot-Dateien von Isolinux und Syslinux (Menü!) einbauen.
cd ../../amd64/isolinux
ln -s ../../isolinux.cfg .
ln -s ../../../../../usr/lib/ISOLINUX/isolinux.bin .
ln -s ../../../../../usr/lib/syslinux/modules/bios/ldlinux.c32 .
ln -s ../../../../../usr/lib/syslinux/modules/bios/libutil.c32 .
ln -s ../../../../../usr/lib/syslinux/modules/bios/menu.c32 .

# Boot-Dateien von Isolinux und Syslinux (Menü!) einbauen.
cd ../../i686/isolinux
ln -s ../../isolinux.cfg .
ln -s ../../../../../usr/lib/ISOLINUX/isolinux.bin .
ln -s ../../../../../usr/lib/syslinux/modules/bios/ldlinux.c32 .
ln -s ../../../../../usr/lib/syslinux/modules/bios/libutil.c32 .
ln -s ../../../../../usr/lib/syslinux/modules/bios/menu.c32 .
</syntaxhighlight>

== Weblinks ==
* [https://kb.isc.org/docs/aa-00333 Where to find ISC DHCP documentation?], ISC.org

== Fußnoten ==
<references />

[[Kategorie:Linux]]

Debian-Live Netzbootsystem

2025-09-02T21:46:42Z

PoC: Überarbeitet, ISO-Image

Die Möglichkeit, hinreichend aktuelle Maschinen (allgemein, also VMs oder auch Blech) über das LAN zu booten ist eine feine Sache. Bare Metal Restore, oder auch die Offline-Korrektur von Fehlern wie z. B. zu kleinen Partitionen, etc. wird damit zum Kinderspiel.

Das '''Debian-Live'''-Projekt hat für Wiederherstellungszwecke eine Live-Boot CD-Serie bereitgestellt. Allerdings haben diese Images ein paar (teils subjektive) Nachteile:
* Gewohnte Konfigurationstools wurden durch modernere Varianten mit eigener Syntax abgelöst; ein Paradebeispiel ist das Fehlen von <code>ifconfig</code>.
* Hardware welche proprietäre Firmware-Binärdateien benötigt ist — vor allem wenn es um Netzwerkkarten geht — außen vor; ein Booten vom Netz geht spätestens nach dem Starten des Kernels schief.
* Viele weitere Pakete mit fast immer benötigten Tools fehlen und müssen immer und immer wieder per Hand nachinstalliert werden.
* Ssh-Zugriff ist standardmäßig erstmal nicht möglich. Das ist besonders schmerzhaft für Server mit wackeligem und bocklahmem Remote-Management, die dann Textmode über VNC-ähnliche Protokolle übertragen. Von den Schwierigkeiten mit Sonderzeichen auf der Tastatur ganz zu schweigen.

Der Artikel beschreibt die notwendigen Schritte, dieses Netzbootsystem auf einem existierenden Debian Linux 12 (Bookworm) aufzusetzen. Ob die zu startende Maschine ein älteres BIOS-basiertes System ist oder ein neueres EFI-System, ist egal: Beides wird dynamisch anhand von DHCP-Optionen passend konfiguriert. Danach kann zum Bootzeitpunkt ausgewählt werden, ob ein 32- oder ein 64-Bit-System gestartet werden soll.

Es ist selbstverständlich möglich, weitere via PXE zu startende Betriebssysteme einzubinden. Wichtig ist zu beachten, dass die via TFTP bereitgestellten Dateien in den entsprechenden Unterverzeichnissen für die verschiedenen "Architekturen" zu hinterlegen sind (bios, efi32, efi64).

<blockquote>'''Hinweis''': Das von mir benutzte System ist traditionell mit ''SysV-init'' ausgerüstet. ''Systemd'' wird nicht benutzt. Die hier aufgeführten Schritte sind ansonsten so generisch wie möglich gehalten.</blockquote>

== Benötigte Komponenten ==
* ''DHCP-Server'' für die Zuweisung grundlegender Netzwerkparameter,
* ''TFTP-Server'' für den initialen Download von Bootloader, Menü und anschließend Kernel und Initrd,
* ''NFS-Server'' für den Zugriff auf das komprimierte Root-Dateisystem,
* ''Scripte'' zur Erstellung des übers Netz geladenen Root-Dateisystems.

Installation:
apt-get install debootstrap genisoimage isc-dhcp-server isolinux nfs-kernel-server openbsd-inetd pxelinux squashfs-tools syslinux-common syslinux-efi tftp-hpa tftpd-hpa

== DHCP-Konfiguration ==
<blockquote>'''Hinweis''': Im lokalen Netzwerksegment soll nur '''ein''' DHCP-Server aktiv sein. Sind es mehrere, ist es mehr oder weniger Zufall, welches Antwortpaket der anfragende Client zuerst bearbeitet. Sollte also schon ein DHCP-Server existieren, muss die gezeigte Konfiguration in die Konfiguration des bestehenden Servers mit eingebaut werden. Durch die Benutzung von DHCP-Klassen ("class") ist dies im Regelfall aber sehr einfach möglich.</blockquote>

Der erste Start des noch nicht unkonfigurierten DHCP-Servers geht erfahrungsgemäß schief, dies kann ignoriert werden.

Weil hier nur IPv4 berücksichtigt wird, muss in ''/etc/default/isc-dhcp-server die Zeile ''INTERFACESv6'' gelöscht werden. Ebenso muss in ''INTERFACESv4'' das für DHCP zu verwendenden Netzwerkinterface eingetragen werden. Beispiel:
INTERFACESv4="eth0"

Dies ist ein '''Beispiel''' für eine DHCP-Konfiguration! Insbesondere der ''group''-Abschnitt muss auf die lokalen Gegebenheiten angepasst werden!
<syntaxhighlight lang="shell">
authoritative;
ddns-updates off;
default-lease-time 3600;
log-facility daemon;
max-lease-time 86400;
min-lease-time 300;
min-secs 0;

option architecture-type code 93 = unsigned integer 16; # RFC4578

# Route different kinds of requesting clients to distinct PXE bootloaders.
class "pxeclients" {
match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";

if option architecture-type = 00:00 {
filename "/var/tftpboot/bios/lpxelinux.0";
} elsif option architecture-type = 00:06 {
filename "/var/tftpboot/efi32/syslinux.efi";
} elsif option architecture-type = 00:07 {
filename "/var/tftpboot/efi64/syslinux.efi";
} elsif option architecture-type = 00:09 {
filename "/var/tftpboot/efi64/syslinux.efi";
}

# This is the TFTP server's IP address.
next-server 192.168.111.10;
}

# Ethernet
group {
option broadcast-address 192.168.111.255;
option domain-name "pocnet.net";
option domain-name-servers 192.168.111.10;
option ntp-servers 192.168.111.10;
option routers 192.168.111.1;
option subnet-mask 255.255.255.0;

subnet 192.168.111.0 netmask 255.255.255.0 {
range 192.168.111.120 192.168.111.126;
}
}
</syntaxhighlight>

Nun kann der DHCP-Server gestartet werden:
service isc-dhcp-server start

== TFTP-Server ==
Die Konfiguration des Servers findet sich in ''/etc/default/tftpd-hpa''. Dort müssen folgende Änderungen durchgeführt werden:
* Ändern des Pfades ''/srv/tftp'' nach ''/var/tftpboot'',<ref>Ist kein Muss, aber in dieser Anleitung wird dieser Pfad vorausgesetzt.</ref>
* Ändern der ''TFTP_OPTIONS'':<ref>Dies ist notwendig, damit die später angelegten Symlinks auch aufgelöst werden.</ref>
** Löschen von <code>--secure</code>,
** Hinzufügen von <code>--permissive -v</code>.

Nun kann der alte Pfad gelöscht werden und der neue angelegt:
rmdir /srv/tftp
mkdir /var/tftpboot

Als letztes sollte der TFTP-Server neu gestartet werden:
service tftpd-hpa restart

=== Inhalte für <code>/var/tftpboot</code> ===
Zuerst werden ein paar grundlegende Verzeichnisse für die benötigten Dateien angelegt:
cd /var/tftpboot
mkdir -p deb-live/amd64 deb-live/i686 bios efi32 efi64 pxelinux.cfg

Für die einzelnen Architekturen werden nun die benötigten Bootdateien über Symlinks bereit gestellt. Symlinks brauchen weniger Speicher und wenn das Original (wegen Aktualisierungen) ausgetauscht wird, braucht man nicht manuell nachbessern.

<syntaxhighlight lang="shell">
# BIOS-Loaders
cd bios
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/bios/ldlinux.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/pxechn.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/vesamenu.c32 .
ln -s ../../../usr/lib/PXELINUX/lpxelinux.0 .

# EFI32-Loaders
cd ../efi32
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/efi32/ldlinux.e32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/vesamenu.c32 .
ln -s ../../../usr/lib/SYSLINUX.EFI/efi32/syslinux.efi .

# EFI64-Loaders
cd ../efi64
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/efi64/ldlinux.e64 .
ln -s ../../../usr/lib/syslinux/modules/efi64/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/vesamenu.c32 .
ln -s ../../../usr/lib/SYSLINUX.EFI/efi64/syslinux.efi .
</syntaxhighlight>

Um die Pflege des PXE-Bootmenüs zu vereinfachen, wird eine "globale" Konfiguration in ''/var/tftpboot/pxelinux.cfg'' (der Standardname, mit dem die PXE-Loader nach der Konfiguration suchen) für alle Architekturen via Symlinks zugänglich gemacht.

Die eigentliche Konfiguration für das Bootmenü findet sich in der Datei ''/var/tftpboot/pxelinux.cfg/default'':
menu title Boot menu
menu tabmsg Press ENTER to boot or TAB to edit a menu entry
prompt 0
timeout 600

label deblive64
menu label Debian Live ^amd64
kernel deb-live/amd64/vmlinuz
append initrd=deb-live/amd64/initrd.img net.ifnames=0 biosdevname=0 ip=:::::eth0:dhcp boot=live netboot=nfs root=/dev/nfs nfsroot=192.168.1.10:/var/nfsboot/deb-live/amd64 live-media-path=/ consoleblank=0 nfsrootdebug

label deblive32
menu label Debian Live ^i686
kernel deb-live/i686/vmlinuz
append initrd=deb-live/i686/initrd.img net.ifnames=0 biosdevname=0 ip=:::::eth0:dhcp boot=live netboot=nfs root=/dev/nfs nfsroot=192.168.1.10:/var/nfsboot/deb-live/amd64 live-media-path=/ consoleblank=0 nfsrootdebug

label bootlocal
menu label Boot ^local disk
menu default
localboot 0

ui menu.c32

Anmerkungen:
* <code>net.ifnames=0 biosdevname=0</code> stellt die ursprüngliche Netzwerkinterfacebenennung vom Kernel wieder her, damit die Netzwerkschnittstelle überall wieder ''eth0''heißt und diese wiederum in der <code>ip=</code>-Konfigurationszeile statisch referenziert werden kann.<ref>Früher hat die Autokonfiguration bei mehreren vorhandenen Netzwerkschnittstellen nicht zuverlässig funktioniert, deswegen der gezeigte Workaround.</ref>
* Das Zirkumflex (<code>^</code>) dient als Hervorhebung für einen Buchstaben im Menü. Dieser Buchstabe auf der Tastatur eingegeben aktiviert diesen Menüeintrag.

== NFS-Server ==
In der Datei ''/etc/exports'' wird definiert, welche Hosts auf welche Verzeichnisse Zugriff haben:
/var/nfsboot 192.168.1.0/24(ro,no_root_squash,insecure,no_subtree_check)

Nun müssen die Verzeichnisse für das Rootdateisystem noch angelegt werden:
mkdir -p /var/nfsboot/deb-live/amd64 /var/nfsboot/deb-live/i686

Damit die Änderungen ziehen, einmal den (mangels gültiger Einträge in ''exports'' sowieso nicht gestarteten) NFS-Server starten:
service nfs-kernel-server start

== Root-Dateisystem ==
Dies wird über eine "frische" Installation von Debian jeweils von Grund auf neu erzeugt:
* Debootstrap,
* Konfigurationsanpassungen,
* Squashfs-Build.

Das folgende Script kann mit den Parametern ''amd64'' oder ''i686'' aufgerufen werden und erzeugt jeweils ein Squashfs in den zuvor angelegten Verzeichnissen in ''/var/nfsboot''.

<syntaxhighlight lang="shell">
#!/bin/bash

# Must run as root.
if ! id |grep -Fq 'uid=0(root) gid=0(root) groups=0(root)'; then
echo "Must run as root."
exit 1
fi

# Must supply what to build.
if [ -z "${1}" ]; then
echo "Give arch as argument: amd64 or i686."
exit 0
fi

# Check what to build.
if [ "${1}" == "amd64" ]; then
DST_ARCH="amd64"
elif [ "${1}" == "i686" ] || [ "${1}" == "i386" ]; then
DST_ARCH="i686"
else
echo "Give arch as argument: amd64 or i686."
exit 0
fi

# Automatically clean up when we terminate.
trap '{ umount ${TMPMNT} && rmdir ${TMPMNT}; rm -f ${TMPIMG}; }' EXIT

# Terminate on error.
set -e

# Temporary image file and mount point to work within.
TMPIMG=$(mktemp --tmpdir=/var/tmp live-image.XXXXXXXXXX)
TMPMNT=$(mktemp -d --tmpdir=/var/tmp live-root.XXXXXXXXXX)

# Prepare image file and mount.
fallocate -v -l 4GiB "${TMPIMG}"
mke2fs -t ext4 -E lazy_itable_init=0 -O ^has_journal -i 16384 -L live-build -F "${TMPIMG}"
tune2fs -r0 -c0 -i12m -o '^acl,nobarrier' -e remount-ro -f "${TMPIMG}"
mount -o loop "${TMPIMG}" "${TMPMNT}"

# Install system.
if [ "${DST_ARCH}" == "amd64" ]; then
ARCH_ARG="--arch=amd64"
PKGLIST="console-setup, \
dosfstools, \
dump, \
firmware-amd-graphics, \
firmware-bnx2, \
firmware-bnx2x, \
firmware-linux-free, \
firmware-misc-nonfree, \
gdisk, \
ifupdown, \
isc-dhcp-client, \
kbd, \
keyboard-configuration, \
linux-image-amd64, \
live-boot, \
locales, \
lsscsi, \
lvm2, \
mdadm, \
mt-st, \
net-tools, \
nfs-common, \
openssh-client, \
openssh-server, \
orphan-sysvinit-scripts, \
pciutils, \
pv, \
sg3-utils, \
sysvinit-core"
elif [ "${DST_ARCH}" == "i686" ]; then
ARCH_ARG="--arch=i386"
PKGLIST="console-setup, \
dump, \
firmware-linux-free, \
ifupdown, \
isc-dhcp-client, \
kbd, \
keyboard-configuration, \
linux-image-686-pae, \
live-boot, \
locales, \
lsscsi, \
lvm2, \
mdadm, \
mt-st, \
net-tools, \
nfs-common, \
openssh-client, \
openssh-server, \
orphan-sysvinit-scripts, \
pciutils, \
pv, \
sg3-utils, \
sysvinit-core"
fi

# Parameter strings for debootstrap must not include blanks.
PKGLIST_CLEAN="$(echo "${PKGLIST}" |tr -d ' ')"
debootstrap "${ARCH_ARG}" --components=main,non-free,non-free-firmware,contrib \
--include "${PKGLIST_CLEAN}" \
--exclude nano,systemd-sysv,tasksel,tasksel-data \
bookworm "${TMPMNT}" https://debian.inf.tu-dresden.de/debian/

# Prepare system.
echo "debian-live" > "${TMPMNT}"/etc/hostname
cat > "${TMPMNT}"/etc/default/keyboard <<-EOF
# Check /usr/share/doc/keyboard-configuration/README.Debian for
# documentation on what to do after having modified this file.

# The following variables describe your keyboard and can have the same
# values as the XkbModel, XkbLayout, XkbVariant and XkbOptions options
# in /etc/X11/xorg.conf.

XKBMODEL="pc105"
XKBLAYOUT="de"
XKBVARIANT=""
XKBOPTIONS=""

# If you don't want to use the XKB layout on the console, you can
# specify an alternative keymap. Make sure it will be accessible
# before /usr is mounted.
# KMAP=/etc/console-setup/defkeymap.kmap.gz
BACKSPACE="guess"
EOF

# Clean apt lists to save space. They might be outdated anyway and need to be retransferred.
rm -f "${TMPMNT}"/var/lib/apt/lists/* 2>/dev/null || true

# Set default locale.
echo "LANG=en_US.UTF-8" > "${TMPMNT}"/etc/environment

# Add default password entry.
sed '/^root:/ d' "${TMPMNT}"/etc/shadow > "${TMPMNT}"/etc/shadow~
echo 'root::17852:0:99999:7:::' > "${TMPMNT}"/etc/shadow
cat "${TMPMNT}"/etc/shadow~ >> "${TMPMNT}"/etc/shadow

# Help with ssh-remote-logins.
echo "PermitRootLogin yes" >> "${TMPMNT}"/etc/ssh/sshd_config
echo "PermitEmptyPasswords yes" >> "${TMPMNT}"/etc/ssh/sshd_config

# Switch initrd to gzip.
sed -Ei 's/^COMPRESS=zstd$/COMPRESS=gzip/' "${TMPMNT}"/etc/initramfs-tools/initramfs.conf

# Prepare system to rebuild initramfs
mount -o bind /dev "${TMPMNT}"/dev
mount -o bind /dev/pts "${TMPMNT}"/dev/pts
mount -t proc none "${TMPMNT}"/proc
mount -t sysfs none "${TMPMNT}"/sys
echo "Please run these commands:"
# FIXME: How to automate this manual process?
echo ' echo "locales locales/default_environment_locale select en_US.UTF-8" |debconf-set-selections'
echo ' echo "locales locales/locales_to_be_generated multiselect en_US.UTF-8 UTF-8" |debconf-set-selections'
echo " dpkg-reconfigure locales"
echo " update-initramfs -u"
echo "then exit chroot."
chroot "${TMPMNT}"

# Script resumes after chroot exit.
umount "${TMPMNT}"/dev/pts "${TMPMNT}"/dev "${TMPMNT}"/proc "${TMPMNT}"/sys

# Copy Kernel and initramfs for TFTP.
cp -v "${TMPMNT}"/vmlinuz "${TMPMNT}"/initrd.img /var/tftpboot/deb-live/"${DST_ARCH}"

# Compress into a file for NFS serving.
mksquashfs "${TMPMNT}" /var/nfsboot/deb-live/"${DST_ARCH}"/filesystem.squashfs -noappend

# Generate ISO image for booting.
# Note: This currently works only for BIOS.
#genisoimage -rational-rock -cache-inodes -joliet -full-iso9660-filenames \
# -input-charset UTF-8 -f -b isolinux/isolinux.bin -c isolinux/boot.cat \
# -no-emul-boot -boot-load-size 4 -boot-info-table \
# -o /var/tmp/debian-boot-"${DST_ARCH}".iso /var/nfsboot/deb-live/"${DST_ARCH}"

# vim: tabstop=4 shiftwidth=4 autoindent expandtab
</syntaxhighlight>

* Die Paketliste in ''$PKGLIST'' ist darauf zugeschnitten, die für eine schnelle Wiederherstellung notwendigen Komponenten zu beinhalten.

== Test ==
Wenn nichts falsch gemacht wurde, so bezieht der Client nun beim Netzboot eine IP-Adresse vom DHCP-Server und lädt die PXE-Dateien, um im Anschluss ein Menü anzuzeigen, was denn nun gestartet werden soll. Nach der Auswahl eines Punktes werden Kernel und Initrd per TFTP übermittelt und der Kernel gestartet. Per erneuter DHCP-Anfrage erhält der Kernel gültige Netzparameter und mountet nun das per NFS zugängliche Squashfs als ''root''. Ab dann ist das Debian-Live-System aktiv.

In ''/var/log/daemon.log'' finden sich Meldungen vom TFTP-Server, was hilfreich bei der Fehlersuche sein kann.

== Anpassungen für ISO-Generation ==
Als quasi "Abfallprodukt" kann aus dem sowieso schon vorhandenen Squashfs ein ISO-Image erzeugt werden, als zweiter Weg zum Booten von einem System. Falls das gewünscht ist, muss der entsprechende Aufruf von ''genisoimage'' im weiter oben gezeigten Script einkommentiert werden.

Die hierzu notwendigen Pakete ''genisoimage'' und ''isolinux'' wurden bereits oben installiert. Im Endeffekt fehlen eine Handvoll Dateien (Symlinks) und eine Konfigurationsdatei für Isolinux.

Die Konfiguration für das Bootmenü beim Boot vom ISO-Image muss in der Datei ''/var/nfsboot/deb-live/isolinux.cfg'' gespeichert werden:
prompt 0
menu title Boot Menu
menu tabmsg Press ENTER to boot or TAB to edit a menu entry
timeout 20

label linux
menu label ^Debian Live
kernel /boot/vmlinuz
append initrd=/boot/initrd.img net.ifnames=0 biosdevname=0 boot=live live-media-path=/ consoleblank=0
menu default

label bootlocal
menu label Boot ^local disk
localboot 0

ui menu.c32

Danach werden noch ein paar zum Booten notwendige Verzeichnisse und Symlinks zu Dateien angelegt. Symlinks brauchen weniger Speicher und wenn das Original (wegen Aktualisierungen) ausgetauscht wird, braucht man nicht manuell nachbessern. Da ''genisoimage'' mit dem Parameter <code>-f</code> aufgerufen wird, landen im Image keine Symlinks, sondern die eigentlichen Dateien (dereference).

<syntaxhighlight lang="shell">
cd /var/nfsboot/deb-live
mkdir amd64/boot amd64/isolinux i686/boot i686/isolinux

# Symlinks für Kernel und Initrd.
cd amd64/boot
ln -sf ../../../../tftpboot/deb-live/amd64/* .
cd ../../i686/boot
ln -sf ../../../../tftpboot/deb-live/i686/* .

# Boot-Dateien von Isolinux und Syslinux (Menü!) einbauen.
cd ../../amd64/isolinux
ln -s ../../isolinux.cfg .
ln -s ../../../../../usr/lib/ISOLINUX/isolinux.bin .
ln -s ../../../../../usr/lib/syslinux/modules/bios/ldlinux.c32 .
ln -s ../../../../../usr/lib/syslinux/modules/bios/libutil.c32 .
ln -s ../../../../../usr/lib/syslinux/modules/bios/menu.c32 .

# Boot-Dateien von Isolinux und Syslinux (Menü!) einbauen.
cd ../../i686/isolinux
ln -s ../../isolinux.cfg .
ln -s ../../../../../usr/lib/ISOLINUX/isolinux.bin .
ln -s ../../../../../usr/lib/syslinux/modules/bios/ldlinux.c32 .
ln -s ../../../../../usr/lib/syslinux/modules/bios/libutil.c32 .
ln -s ../../../../../usr/lib/syslinux/modules/bios/menu.c32 .
</syntaxhighlight>

== Weblinks ==
* [https://kb.isc.org/docs/aa-00333 Where to find ISC DHCP documentation?], ISC.org

== Fußnoten ==
<references />

[[Kategorie:Linux]]

APC-USV an AS/400

2025-08-08T16:37:17Z

PoC: +link

{{FIXME}}
'''Artikelrumpf'''

== Weblinks ==
* [http://www.apc.com/us/en/faqs/FA159551/ UPS Signalling Bundle for IBM AS/400 & IBMi (IBM Power Systems)] auf ''apc.com''
* [https://www.eaton.com/content/dam/eaton/products/backup-power-ups-surge-it-power-distribution/power-management-software-connectivity/eaton-relay-card-ms/eaton-relay-card-ms-user-guide.pdf.pdf Eaton Management Card Contact & RS232 / Serial], PDF
* [https://www.ibm.com/support/pages/connecting-ups-ibm-power-systems-server Connecting a UPS to an IBM Power Systems Server] auf ''ibm.com''
* [https://www.ibm.com/docs/en/i/7.5.0?topic=program-controlled-shutdown-concepts Controlled shutdown concepts] auf ''ibm.com''

[[Kategorie: AS/400]]
[[Kategorie: Kabel]]
[[Kategorie: Pinbelegung]]

APC-USV an AS/400

2025-08-05T17:11:40Z

PoC: Linkfix/Ergänzung

{{FIXME}}
'''Artikelrumpf'''

== Weblinks ==
* [http://www.apc.com/us/en/faqs/FA159551/ UPS Signalling Bundle for IBM AS/400 & IBMi (IBM Power Systems)] auf ''apc.com''
* [https://www.eaton.com/content/dam/eaton/products/backup-power-ups-surge-it-power-distribution/power-management-software-connectivity/eaton-relay-card-ms/eaton-relay-card-ms-user-guide.pdf.pdf Eaton Management Card Contact & RS232 / Serial], PDF
* [https://www.ibm.com/support/pages/connecting-ups-ibm-power-systems-server Connecting a UPS to an IBM Power Systems Server] auf ''ibm.com''

[[Kategorie: AS/400]]
[[Kategorie: Kabel]]
[[Kategorie: Pinbelegung]]

LTO-Tape Statistiken unter Linux auslesen

2025-07-26T12:43:28Z

PoC: Typo

Verschiedene '''Statistiken von LTO-Laufwerken'''<ref>… und vermutlich anderen Laufwerkstypen…</ref> und -Cartridges lassen sich '''unter Linux''' mit den sg3-utils auslesen.

Zuvor muss mit <code>lsscsi -g</code> die Zuordnung von SCSI-Geräten zu SCSI-Generic Gerätedateien ausgegeben werden:
[7:0:2:0] tape HP Ultrium 2-SCSI S63D /dev/st0 /dev/sg0

== Laufwerkstemperatur ==
sg_logs -t /dev/sg0

== Cartridge-Statistiken ==
sg_read_attr /dev/sg0

== Fußnoten ==
<references />

[[Kategorie:Datensicherung]]
[[Kategorie:Hardware]]
[[Kategorie:Linux]]
[[Kategorie:Storage]]

LTO-Tape Statistiken unter Linux auslesen

2025-07-26T12:43:05Z

PoC: Neu

Verschiedene '''Statistiken von LTO-Laufwerken'''<ref>… und vermutlich anderen Laufwerkstypen…</ref> und -Cartridges lassen sich '''unter Linux''' mit den sg3-utils auslesen.

Zuvor muss mit <code>lsscsi -g</code><ref> die Zuordnung von SCSI-Geräten zu SCSI-Generic Gerätedateien ausgegeben werden:
[7:0:2:0] tape HP Ultrium 2-SCSI S63D /dev/st0 /dev/sg0

== Laufwerkstemperatur ==
sg_logs -t /dev/sg0

== Cartridge-Statistiken ==
sg_read_attr /dev/sg0

== Fußnoten ==
<references />

[[Kategorie:Datensicherung]]
[[Kategorie:Hardware]]
[[Kategorie:Linux]]
[[Kategorie:Storage]]

Netzwerkperformance mit alten Macs und Linux

2025-06-24T09:05:13Z

PoC: Korrekte Syntax für iptables ausfindig gemacht

[[Datei:Helios_LANTest.png|thumb|right|AFP-Performance nach dem Abschalten von Window Scaling - immerhin knapp 1,6 MBytes/s beim Schreiben statt nur knapp 11 KBytes/s vorher.]]
Bei '''älteren Macs''' ist feststellbar, dass ab einer bestimmten — älteren — '''Linux'''-Kernelversion die Schreibgeschwindigkeit von TCP-Verbindungen (z. B. AFP oder FTP) im unteren zweistelligen Kilobyte/s-Bereich liegt.

Test haben gezeigt, dass MacTCP als auch OpenTransport bis einschliesslich Version 1.2 mit [https://de.wikipedia.org/wiki/TCP_Receive_Window#TCP_Window_Scale_Option TCP Window Scaling] nicht zurechtkommen. Testumgebung war ein PowerMac 7500 mit 400 MHz MPC750 (G3)-CPU, einer auf einem DEC-Chipsatz basierenden 100MBit/s Netzwerkkarte von Kingston unter MacOS 7.6.1.

== Lösungswege ==
Die aufgezeigten Lösungswege berücksichtigen (derzeit) nicht, dass zwischen Lesen und Schreiben noch immer fast eine Größenordnung an Übertragungsgeschwindigkeitsunterschied besteht.

=== Iptables ===
iptables -t mangle -A OUTPUT -d 192.168.0.128 -p tcp --tcp-option 3 -j TCPOPTSTRIP --strip-options wscale

=== Global (sysctl) ===
Global kann Window Scaling deaktiviert werden mit:
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
bzw.
sysctl -w net.ipv4.tcp_window_scaling = 0
Neustartfest wird der Parameter durch einen entsprechenden Eintrag in ''/etc/sysctl.conf'':
net.ipv4.tcp_window_scaling = 0

Transfers zu anderen Maschinen dürften je nach Übertragungsmedium nun auch langsamer werden.

=== Middlebox ===
Als Alternative zum harten Abschalten des Window Scaling besteht die Möglichkeit, durch Zwischenschalten z. B. einer [[Cisco PIX Konfigurationsbeispiele|Cisco PIX]] oder ASA den Paketfluss zu modifizieren (Konfigurationsausschnitt):
class-map match-any
match any
!
tcp-map preset_tcp_map
tcp-options window-scale clear
!
policy-map global_policy
class match-any
set connection advanced-options preset_tcp_map

Nachteile dieser Lösung:
* zusätzlicher Stromverbrauch,
* Lässt kein AppleTalk durch (auch nicht im Transparentmodus).

=== TCP-Proxy ===
Eine andere Möglichkeit wäre durch eine virtuelle Maschine mit wie oben gezeigt, global abgeschaltetem Window Scaling gegeben. Über den ''xinetd'' lassen sich Proxydienste auf IP Layer-4-Ebene abbilden. Ausschnitt aus einer Beispielkonfiguration ''/etc/xinetd.d/afp-proxy'':
service afp-proxy
{
id = afp-proxy
type = UNLISTED
disable = no
wait = no
protocol = tcp
user = root
group = nogroup
log_type = syslog daemon info
port = 548
redirect = 192.168.0.1 548
}
Sprich, eine TCP-Verbindung wird nicht zum eigentlichen AFP-Server auf der 192.168.0.1 aufgebaut, sondern auf zur VM, auf der der ''xinetd'' läuft. Diese erzeugt dann eine neue TCP-Verbindung zum eigentlichen AFP-Server.

Nachteile dieser Lösung:
* Lästig, weil der AFP-Server via AppleTalk unter anderem Namen angesprochen werden muss als per TCP.

== Weblinks ==
* [http://juljas.net/lpt/post/slow-connection Very slow or dying Internet connection to some hosts]
* [http://kb.pert.geant.net/PERTKB/WindowScalingProblems The window scaling problem]

[[Kategorie:Mac OS]]
[[Kategorie:Linux]]
[[Kategorie:Netzwerk]]
[[Kategorie:Cisco]]

Steam-Client auf Debian-Linux optimal einrichten

2025-04-28T23:06:52Z

PoC: /* Steam-Client */ update is required

Steam lädt beim Starten pro Benutzer ggfs. ein Update herunter und installiert dies in ''~/.local/share/Steam/''. Derzeit fasst dieses Verzeichnis 213 MiB. Um diesen unnötigen Overhead abzumildern, verschieben wir die Daten an einen zentralen Platz.

Updates müssen trotzdem als ''root'' erfolgen, da nur dieser Benutzer die Dateien überschreiben darf.

== Steam-Client ==
Als Grundvoraussetzung für alle Steam-Themen muss zuerst mal der Client installiert und grundkonfiguriert werden. Die zugehörigen Libraries sind allerdings nicht für 64-Bit x86 verfügbar, weswegen zuvor diese teilweise kompatible Architektur angeknipst werden muss.
<syntaxhighlight lang="shell">
dpkg --add-architecture i386
apt-get update
apt-get install steamcmd
</syntaxhighlight>

Im Zuge dessen werden einige benötigte 32-Bit Libraries installiert und eine Bestätigung der Lizenzbedingungen abgefragt.

=== Initialer Start ===
<syntaxhighlight lang="shell">
/usr/games/steamcmd
</syntaxhighlight>

Hier scrollt nun eine Menge Text durch mit Hinweisen ein Update. Am Ende muss ein fett gedruckter Prompt da stehen:
'''Steam>'''

Der Client kann an dieser Stelle mit <code>quit</code> verlassen werden.

=== Gemeinsamen Datenpool einrichten ===
<syntaxhighlight lang="shell" line>
mkdir /usr/local/share/games
mv ~/.local/share/Steam /usr/local/games
ln -s /usr/local/games/Steam ~/.local/share/Steam
chgrp -R games /usr/local/games/Steam
find /usr/local/games/Steam -type d -exec chmod 2755 {} \;
find /usr/local/games/Steam -type f -exec chmod 644 {} \;
find /usr/local/games/Steam -type f -a $ -name "*.sh" -o -name "*.so" -o -name "*.so.*" $ -exec chmod 755 {} \;
chmod 755 /usr/local/games/Steam/steamcmd/linux32/steamcmd /usr/local/games/Steam/steamcmd/linux32/steamerrorreporter
chmod 2770 /usr/local/games/Steam
</syntaxhighlight>

Der Symlink in Zeile 3 ist für jeden Benuzer der Steam benutzen darf vorab einzurichten. Ggfs. ist der übrige Verzeichnisbaum ''~/.local/share'' vorher anzulegen.

=== Suchpfad ergänzen ===
<syntaxhighlight lang="shell">
vi /etc/profile
</syntaxhighlight>

Natürlich kann man den Editor seiner Wahl verwenden. Letztendlich kommt es darauf an, in den Zeilen, in denen die <code>PATH</code>-Variable gesetzt wird, den Pfad zum Steam-Shellscript zu ergänzen.

;Vorher:
<syntaxhighlight lang="shell" line>
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
</syntaxhighlight>

;Nachher:
<syntaxhighlight lang="shell" line>
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
</syntaxhighlight>

Hinweis: Die Änderungen in Gruppenzuordnungen und des <tt>PATH</tt> werden erst nach einem Neulogin aktiv.

Damit sind die Vorbereitungen für die Installation von z. B. ''Dedicated Servern'' abgeschlossen.

[[Kategorie: Linux]]
[[Kategorie: Spiel]]

UUCP-Mail-News-FAQ

2024-12-31T17:15:14Z

PoC: /* Historie */ Tippfehler in Mailadresse korrigiert.

… oder wie einfach es sein kann, ''sendmail'', ''inn'' und ''Taylor uucp'' unter Linux unter einen Hut zu bringen.

== Was ist UUCP? ==
UUCP heißt ausgeschrieben ''Unix to Unix CoPy'', und ist eine Sammlung verschiedener Übertragungsprotokolle, die nicht nur einfach Dateien schaufeln, sondern auch auf dem entfernten Rechner Programme starten können, welche im Allgemeinen die übertragenen Daten gleich weiterverarbeiten. Ursprünglich diente UUCP aber hauptsächlich zur Dateiübertragung.

Im einfachsten Sinne kann man UUCP mit ''rcp'' gleichsetzen, nur dass UUCP bessere Möglichkeiten zum unbeaufsichtigten Betrieb hat und keine bestehende IP-Verbindung voraussetzt, sowie weitergehende Authentisierungsmöglichkeiten als ''.rhosts'' ermöglicht. Es wurde ursprünglich für Modem-Strecken entwickelt, funktioniert aber auch problemlos über IP.

Das ''uucp''- oder ''uux''-Programm macht allerdings nicht die eigentliche Arbeit, es legt normalerweise nur die Jobs (oder eine Referenz darauf, je nach Aufrufparameter) in ein Spoolverzeichnis, aus dem der ''uucico''-Dämon liest und die Jobs entsprechend verarbeitet. Dafür, dass ''uucico'' regelmäßig aufgerufen wird, um die Jobs abzuarbeiten, muß der Administrator selbst Sorge tragen (cron).

=== Wofür braucht man sowas? ===
Bedeutung hat UUCP heutzutage nur für den Nachrichtenaustausch. Früher wurde fast alles per uucp übertragen, heute wird nur noch selten Mail und News per uucp verschickt, da das Batching auf dem Remote-System erfolgt und keine feste IP benötigt, wie manche SMTP-Expensive-Krücken.

Für diese Mail und News ist uucp bei dial-up Systemen das effizienteste Verfahren, da vor allem (in der Regel) platzintensive News vor der Übertragung gepackt vorliegen können und die Bandbreite so am besten ausgenutzt werden kann. Es gibt auch Möglichkeiten, Mail zu packen (Stichwort ''bsmtp''), aber es ist weder vernünftig standardisiert noch verbreitet. Andererseits packen Modems seit Generationen die Daten in Hardware, sodaß der Packpunkt bei Dialupstrecken eigentlich nur bei (unkomprimierten) X.75-ISDN-Verbindungen wirklich interessant ist.

Der User braucht sich im Idealfall keine Gedanken mehr um seine Einwahl beim UUCP-Host zu machen, ein Cronjob erledigt das normalerweise, holt die dort liegenden Daten ab und schickt gleichzeitig die lokalen neuen Nachrichten zum Provider. UUCP kann auch problemlos über TCP gefahren werden, man muß dann aber aufpassen, dass kein Protokoll für die Übertragung fest eingestellt ist; das Protokoll ''i'' arbeitet unter Linux ab Kernel 2.4 z. B. nicht mehr zuverlässig bei großen Dateien.

Eine Anbindung per UUCP macht heutzutage nur dann Sinn, wenn eine Einwahl fuer jede einzelne SMTP-Verbindung vermieden werden soll, wie das bei einem System mit einem normal eingerichteten Mailer ohne schmutzige Tricks auch der Fall wäre (egal ob die Mails 'raus oder 'rein sollen). Durch das Batching von UUCP wird die Effektivität erhöht, die bidirektionalen internen Protokolle nutzen die Verbindungen auch besser aus als SMTP über IP. Eine weitere Einsatzmöglichkeit ist die Übertragung vom Mailgateway in einer DMZ auf den Mailserver im internen Netz, falls firewallseitig kein Paketfilter, sondern reine Proxylösungen zum Einsatz kommen.

=== Auf welchen Plattformen gibt’s das? ===
So ziemlich auf allen. Manche kommerzielle Unixvarianten haben möglicherweise noch Versionen, die die Features von Taylor UUCP nicht besitzen. In vielen Fällen läßt sich Taylor UUCP aber auch auf diesen Systemen problemlos zusammenkompilieren. Die gängigen modernen Distributionen liefern allerdings alle die entsprechenden Pakete mit.

Auf dem Mac existiert MacUCP, welches aber leider vom Autor nicht mehr gepflegt wird; Es unterstützt zum Beispiel noch kein ''i''-Protokoll.

Links und Ergänzungen für andere Betriebssysteme werden per Mail gerne angenommen.

== Wie ist es organisiert? ==
UUCP auf Unix (und bei der hier behandelten Version von Ian Taylor unter der Debian-Distribution von Linux) besteht aus nachfolgenden Dateien und Verzeichnissen:

* Dem Hauptverzeichnis, allgemein '''/var/spool/uucp/''', Rechte normalerweise uucp:uucp 750. Für jedes Remote-System gibt es ein Unterverzeichnis mit dem Namen des Systems (werden automatisch angelegt). Darunter gibt es jeweils drei Verzeichnisse:
** '''D./''' hier stehen die eigentlichen Daten (deren Inhalt), allerdings nicht mit Originalnamen.
** '''C./''' hier steht für jede Datei in ''D./'' eine nicht mit der Datenseite gleichnamige Datei, in der die Kommandos drin stehen die auf der Remote Seite ausgeführt werden sollen. Über diesen Dateinamen wir die mit ''uustat'' ausgegebene Job-ID erzeugt.
** '''X./''' hier steht nach dem Empfang von Daten das Futter für den ''uuxqt'', den Dämon, der das ausführt, was auf dem Remote-System vorher in ''C./'' gestanden hat.

* Im Logverzeichnis liegen eine Log- und ein Statusdatei, welche Informationen über die UUCP-Tätigkeit enthalten. ''uustat'' benutzt die Statusdatei, ebenfalls der Cronjob für das Reporting.

* '''/var/spool/uucppublic/''' ist eine Art ''public directory'' mit den Rechten <code>rwxrwxrwt</code>, <code>uucp:uucp</code>. Hier werden z. B. an Benutzer adressierte Kopien abgelegt.
* '''/etc/uucp/''' beherbergt die Konfigurationsdateien.
* '''/usr/lib/uucp/''' beherbergt verschiedene ausführbare Dateien und Dämonen. Manchmal liegen diese auch in ''/usr/libexec/uucp'' (NetBSD).
* In '''/usr/bin/''' liegen die Benutzerprogramme selbst.

Daneben gibt es noch ein paar Verzeichnisse die temporäre Daten enthalten und ein ''/var/spool/uucp/.Failed/''-Verzeichnis, das die schiefgegangenen Daten und Kommandos für jedes Remote System getrennt enthält. Hier ist die Stelle wo man bei einem Ausführungsfehler der Kommandos seinen Kram retten kann, indem man einfach Daten- und Kommandodateien wieder an Ort und Stelle schafft (nach ''X./'' und ''D./'') und den ''uuxqt'' von Hand aufruft, was aber auch nicht zwangsweise funktionieren muß, wenn die Daten selbst schadhaft sind oder die Zugriffsrechte nicht stimmen. Es ist sicherlich kein Fehler, sich den Kram vorher anzusehen.

=== Welche Programme gibt es, was tun sie? ===
Eine Übersicht über die häufigst gebrauchten Programme und ihre Berechtigungen:
* '''/usr/lib/uucp/uucico''' (-r-sr-sr-x, uucp:uucp) Dämon, der die eigentlichen Jobs erledigt, läßt sich z. B. mit Cron regelmäßig aufwecken, damit er nachsehen kann, ob's Arbeit gibt. Er muß auch als Shell für die Accounts eingetragen sein, die (dann halt ausschließlich) UUCP machen sollen. Besser (sicherer und weniger aufwendig) ist aber, die eingebaute Getty-Funktion zu benutzen.
* '''/usr/lib/uucp/uuxqt''' (-r-sr-sr-x, uucp:uucp) Dämon führt die Kommandos in den übertragenen Dateien aus.
* '''/usr/lib/uucp/uuchk''' (-rwxr-xr-x, root:root) Das Programm zeigt die gesamte Konfiguration human-readable an und ist angenehmerweise sehr gesprächig, was die Fehlersuche ungemein erleichtert.
* '''/usr/bin/uucp''' (-r-sr-sr-x, uucp:uucp) Setzt einen Kopierjob in die Queue.
* '''/usr/bin/uux''' (-r-sr-sr-x, uucp:uucp) Setzt einen Executejob in die Queue.
* '''/usr/bin/uuname''' (-r-sr-sr-x, uucp:uucp) Zeigt alle in ''sys'' spezifizierten Systeme oder den eigenen Namen an.
* '''/usr/bin/uustat''' (-r-sr-sr-x, uucp:uucp) Zeigt Informationen über ausstehende Jobs. Damit können Jobs z. B. auch gekillt werden, z. B. falls eine Mail nun doch nicht verschickt werden soll.
Beispiele:
uustat -s pocmail
zeigt alle Jobs die zur Auslieferung an das System pocmail bereitliegen mit ID an.
uustat -k pocmail.CR45hqWAAAgggy
löscht den zur Übertragung anstehenden Job mit z.B. der ID pocmail.CR45hqWAAAgggy aus der Queue.

=== Welche Konfigurationsdateien gibt es, was tun sie? ===
Es gibt sechs Konfigurationsdateien, die alle nach demselben Schema aufgebaut sind. Als erstes folgen Defaulteinträge, danach durch bestimmte Schlüsselworte getrennt die spezifischen Einstellungen.

* '''sys''' Hier werden die remote Systeme konfiguriert sowie Defaults für alle Remotes definiert. Das Schlüsselwort ist hier ''system'' (beginnt einen neuen Abschnitt). Für einen Sys-Eintrag gibt es z. B. ein Unterschlüsselwort ''alternate'', um eine alternative Erreichbarkeitsmethode zu definieren sowie ''alias'' für einen alternativen Namen für dieses System.
* '''port''' Hier werden die Schnittstellen wie ''/dev/ttyS'' oder auch Netzverbindungen mit den entsprechenden Parametern konfiguriert. Schlüsselwort ist ''port''.
* '''dial''' Hier stehen die Chatscripte für die an den in Port definierten Geräte (Modems). Schlüsselwort ist ''dialer''.
* '''passwd''' Hier stehen die Logins der Systeme die anrufen dürfen mit ihren Passworten im Klartext. ''/etc/passwd'' oder shadow wird nicht benutzt. Wird benötigt, wenn uucico im Getty-Mode läft oder Verbindungen über den ''inetd'' annehmen soll.
* '''call''' Eine Paßworttabelle für die Systeme, die angerufen werden. So weiß der uucico, welches Login-Paßwort-paar er für welches System zu verwenden hat. Die Paßworte brauchen dann nicht im Klartext in ''sys'' stehen, die dann wiederum für jeden lesbar sein darf.
* '''config''' Hier können einkompilierte Defaults umgebogen werden. Normalerweise beschränkt sich diese Datei auf den UUCP (Node) Namen des lokalen Rechners.

Es wird dringend empfohlen, die Dateien call und passwd auf Mode 640, uucp:uucp zu halten (security)! Besser gleich die Permissions auf 600 stellen, häufig tragen die Leute nämlich diejenigen User, die aufs Modem zugreifen dürfen, in die Gruppe uucp ein und dann dürfen diese Leute plötzlich die Passworte lesen, falls eine Gerätedatei der Gruppe uucp angehört …

=== Wie sieht eine Beispielkonfiguration aus? ===
In den nicht aufgeführten Dateien stehen meist Defaults, die unverändert übernommen werden können.

==== port ====
#
# port - Beschreibung der Schnittstellen
#
speed 38400
#
port isdn
device /dev/ttyI2
dialer isdn
#
port netz
type tcp
#
port seriell
device /dev/ttyS2
dialer generic
#
Ich denke, daß sich hier eine Erklärung erübrigt.

==== config ====
#
# config - Haupt UUCP-Konfigurations-Datei
#
nodename poc
passwdfile /var/lib/uucp/taylor_config/passwd
Hier wohl ebenso.

==== sys ====
#
# sys - Beschreibung der bekannten Systeme
#
#
# Globale Einstellungen fuer alle Systeme
#
#
# Passwort und Login aus call lesen
call-login *
call-password *
#
# Ich darf jederzeit 'rausrufen
time any
#
# Das darf ich ausführen und finde das im command-path
commands uucp rmail rnews
command-path /usr/bin /home/news/bin
# Wie führe ich ich einen Login durch
chat ogin: \L word: \P
# Grundsätzlich diesen Port benutzen
port netz
# Verkettung hier!da!sonstwo erlauben
forward ANY
# uucp remote!/tmp/herdamit /tmp erlauben (weil /tmp unterhalb / liegt)
local-receive /
#
#
system pocmail
called-login pocmail
alias ci
address ci.pocnet.net
remote-receive /home/poc ~ # Darf auf diesem System von fern nur dahin senden
remote-send /home/poc # Darf auf diesem System von fern nur von da empfangen
#
system heiko
called-login heiko
time never # Der ruft nur hier an
remote-receive /home/heiko ~
remote-send /home/heiko
#
Erläuterung:
* Commands sind die Kommandos, die ausgeführt werden dürfen. Ohne Pfadangabe eintragen!
* Command-Path ist der Suchpfad, in dem nach diesen Kommandos gesucht wird. Dieser ist unbedingt richtig anzugeben, da ein ''uux''-Aufruf mit direkter Pfadangabe ein <code>Permission Denied</code> provoziert.
* Chat ist ein wie von PPP bekanntes kleines Expect-Send-Expect … Script, welches den Login durchführt. Nähere Informationen finden sich in der Manpage zu ''chat(8)''.
* Called-login ist eine recht nette Sache, um das Faken von Systemen zu unterbinden: So kann man ein System für eingehende Calls an einen Login binden. Normalerweise kann jedes System mit sich jedem in der UUCP-Passwd eingetragenen Login-Paßwort-Paar gegenüber der Gegenseite authentisieren, wenn der Systemname bekannt ist. Wenn man Systemname, Login und Paßwort recht abstrakt wählt, kriegt man UUCP auf diese Weise genau so dicht wie einen normalen POP3 Zugang.
Aus dieser Beispielkonfiguration lassen sich die wichtigsten eigenen Konfigurationsbedürfnisse befriedigen. Nicht vergessen sollte man allerdings, daß auf der Gegenseite auch ein Eintrag für das eigene System stehen muß! 
Um zu testen, ob UUCP selbst nun funktioniert, sollte man einen Job in Auftrag geben:
uucp -r /bin/bash heiko\!~/poc-bash
Das nächste Mal, wenn uucico eine Verbindung mit Heiko eingeht (wenn er anruft), wird ''/bin/bash'' nach ''/var/spool/uucppublic/poc-bash'' kopiert. Das Ausrufezeichen muß escaped werden, damit die bash es nicht als Befehlswiederholung (wie sonst üblich) expandiert.

=== Wie funktioniert das mit uucp und Dateien versenden? ===
Normalerweise expandiert die Shell den UUCP-Pfadtrenner ! als Kommandowiederholung. Daher muß das ! mit \ maskiert werden: \! 
In der Konfigdatei ''sys'' muß ''uucp'' als Kommando erlaubt sein, falls verkettete Versendungen (<code>uucp hier!da!dort!~user/home/work</code>) erlaubt sein sollen.

Was in dem Zusammenhang ganz wichtig ist, sind die Zugriffsrechte! Uucp wie auch der uuxqt laufen alle setuid/setgid ''uucp:uucp''. Sprich, wenn die Konfiguration auch sonstwas erlaubt, je nach setup muß das Directory, aus welchem gelesen werden kann, mindestens Mode 5 (r-x) für ''uucp'' oder dessen Gruppe(n) sein. Für das übergeordnete Directory genügt Mode 1 (--x). Wenn in ein Directory geschrieben werden soll, muß es zusätzlich schreibbar sein, Mode 7 (rwx) oder als Dropbox Mode 3 (-wx), wenn ''uucp'' nicht mehr draus lesen können soll.

Siehe auch die entsprechenden Abschnitte in der UUCP-Dokumentation, Abschnitt ''sys''-Konfigurationsdatei, Punkte ''local-send'', ''local-receive'', ''remote-send'', ''remote-receive''.

=== UUCP ist ein Klartextprotokoll. Was ist mit der Security? ===
Am einfachsten ist es, man tunnelt UUCP über eine SSH-Verbindung.

Zuerst müssen beide beteiligten Seiten per SSH ohne Passwortabfrage einen Login auf die jeweils gegenüberliegende Seite durchführen dürfen. Zum Anlegen der Schlüssel und automatischen hinterlegen des Hostkeys in ''~/.ssh/known_hosts'' empfehle ich, mit <code>su - uucp</code> als uucp-Benutzer zu arbeiten und nicht als root. Vorteil: Die Dateien landen an den richtigen Stellen und die Zugriffsrechte passen auch von Anfang an.

* Keys auf beiden Hosts anlegen, alle Abfragen mit Return bestätigen.
mkdir ~/.ssh
ssh-keygen -t rsa -f ~/.ssh/id_rsa -N <nowiki>''</nowiki>
* Kopieren des Public-Keys eines Hosts auf den anderen zwecks automatisiertem Login. Das erste ''cat'' gibt die Schlüsselzeile aus, das zweite (muss auf dem jeweils anderen Host ausgeführt werden!) erzeugt die Datei ''authorized_keys'' und hinterlegt den Schlüssel dort. Wichtig, der Key ist und bleibt eine einzige lange Zeile!
cat ~/.ssh/id_rsa.pub
cat > ~/.ssh/authorized_keys
* Beschränken des Zugriffs mit diesem Schlüssel. Dazu wird vor dem ''ssh-rsa'' noch der folgende Konfiguration ergänzt:
''command="/usr/sbin/uucico -l",no-agent-forwarding,no-port-forwarding,no-X11-forwarding'' ssh-rsa AAAAB…
* Anlegen eines neuen Ports für diese Verbindung in ''/etc/uucp/port'':
port ''uucppeer''-ssh
type pipe
command /usr/bin/ssh ''otherside.example.com''
seven-bit false
reliable true
* Änderungen gegenüber einem normalen Host via ''inetd.conf'' in ''/etc/uucp/sys'':
system ''uucppeer''
[…]
port ''uucppeer''-ssh
protocol t
* Hinterlegen des Host-Keys in der ''known_hosts'', Nachfrage bestätigen, beim Loginprompt (von uucico!) dann mit ein paarmal Ctrl-C abbrechen. Es darf kein "nur Passwort"-Prompt erscheinen: Das ist dann ssh und die gegenseitige Auth mit den RSA-Keys funktioniert nicht. Das muss vorher behoben werden.
ssh ''otherside.example.com''
* Test:
uucico -S''uucppeer'' & tail -f /var/log/uucp/Log
Im Log steht dann sinngemäß:
uucico - - (2018-01-08 13:45:12.79 27991) Incoming call (login ''uucppeer'' port stdin)
uucico ''uucppeer2'' - (2018-01-08 13:45:14.80 27991) Handshake successful (protocol 't')
uucico ''uucppeer2'' - (2018-01-08 13:45:14.81 27991) Call complete (2 seconds 0 bytes 0 bps)

== Wie arbeitet UUCP mit Sendmail zusammen? ==
Mail (und News) Requests werden per ''uux'' übertragen. Sendmail zum Beispiel verfüttert die Mail an dessen ''stdin'' und ein paar Parameter dazu. Auf der Gegenseite ruft nach der Übertragung ''uuxqt'' diese Kommandodatei auf, welche ihrerseits ''rmail'' anwirft, welches dann den Kram in die Sendmail-Queue verschiebt. 
Sendmail wacht alle paar Minuten aus seinem Dämonenschlaf auf und schaut, ob's in der Queue was zu schaufeln gibt: Die Mail wird ausgeliefert.
Wie oft er das tut, wird beim Aufruf von Sendmail mit dem Parameter <code>-q''xx''m</code> festgelegt. Xx ist die Zeit in Minuten zwischen den Queue-Scans. Wenn einen der Delay zwischen ''rmail'' und <code>sendmail -q</code> nervt, kann man auch ''rmail'' patchen, so daß es nicht mehr <code>sendmail -odq</code> sondern <code>sendmail -odi</code> aufruft (entweder im Source ändern oder einfach den einen Buchstaben im Binary patchen), soll mit Emacs gehen (unverified). Der Source liegt sendmail bei.

=== Wie gelangt eine Mail von Sendmail zu UUCP? ===
In Sendmail gibt es für jede Übertragungsart einen sogenannten Mailer. Das ist das Programm welches die eigentliche Verschiebearbeit tut. Sendmail selbst wurschtelt nur an den Adressen ’rum, bis er weiß, welchen Mailer er benutzen muß. Diese Mailer haben einen symbolischen Namen z. B. ''local'' für das Programm was die Mails lokal auf dem Rechner ausliefert, oder eben auch ''uucp'' für den (oder besser gesagt die) uucp-Mailer. Sendmail ruft als uucp-Mailer direkt <code>/usr/bin/uux</code> mit bestimmten Parametern auf, die spezifizieren was schlußendlich in der Kommandodatei in <code>/var/spool/uucp/system/C./</code> drin steht, also den Aufruf von rmail auf der Gegenseite.

Über eine Tabelle, die ''mailertable'', stellt sendmail fest, daß eine Mail an eine Adresse über UUCP ausgeliefert werden soll und mit welcher Mailer-Spezifikation das geschehen soll. So eine Konfiguration ist zweckmäßig für ein UUCP-Relay, welches Mails per SMTP empfängt und sie per UUCP weiterleitet.

Ein Rechner, der Mails nur über UUCP senden und empfangen kann, braucht einen Defaultmailer, der alle abgesendeten Mails weiterverwurstelt, solange er keine näheren Infos in der ''mailertable'' findet. Im Prinzip kann man das mit der Defaultroute von TCP/IP vergleichen. Findet sich kein Mailer für eine Adresse, wird der Defaultmailer verwendet. 
Den Defaultmailer in der ''sendmail.cf'' definiert man über den Makro DS: <code>DSuucp-dom:''remotesys''</code>, wobei ''remotesys'' einem Eintrag in ''sys'' entspricht. In der entsprechenden m4-Datei für die Sendmail-Konfigurationszusammenschraubung ist das dann
define(`SMART_HOST', `uucp-dom:remotesys')dnl.

Beispiel-mailertable zur Sys weiter oben passend:
#Domain mailer:new_domain
hk.pocnet.net uucp-dom:heiko
Normalerweise muß die Datenbank noch gehasht (indiziert) werden, damit Sendmail ordnungsgemäß darauf zugreifen kann:
makemap hash mailertable.db < mailertable

Sendmail merkt durch diese Tabelle, daß Mail an heiko@hk.pocnet.net über UUCP geroutet werden muß, aktiviert den Mailer ''uucp-dom'', der die Mail im heute üblichen ''user@host.domain'' Stil weiterleitet (in die C./D. Verzeichnisse von uucp legt). ''hk.pocnet.net'' ist in diesem Falle eine Subdomain, uucp funktioniert logischerweise auch mit normalen Domains. Das heißt, im Nameserver für die Zone ''pocnet.net'' müssen entsprechende MX-Einträge stehen, die die Mail an das UUCP-Relay leiten:
$ORIGIN pocnet.net.
;For the UUCP-Users
hk IN MX 1 uucp-host

Als Anmerkung hier nur das Stichwort Replyadresse; eine Mail von ''deep-thought.hk.pocnet.net'' wird zwar richtig ausgeliefert, aber sobald der User einen Reply setzt, funktioniert eine Antwort auf diesen Reply nicht mehr. Das rührt daher, daß es für den Rechner ''deep-thought'' keinen DNS-Eintrag gibt. Lösung: Entweder passende DNS-Zonen mit Rechnernamen anlegen oder den User treten, daß er seine Replyadresse richtig setzt.

Zu beachten ist auch, daß die Hosts nicht in der Klasse ''w'' (lokaler Hostname) auftauchen dürfen, das heißt, ihr darf weder direkt über ''Cwlocalhost andere.dom'' in der ''sendmail.cf'' noch indirekt über die Klassendatei (in der sendmail.cf allgemein über ''Fw/etc/mail/local-host-names'') ein UUCP-Host zugeordnet werden. Ansonsten würde die Mail lokal ausgeliefert. Wir wollen aber nur weiterleiten (Relaying). Je nach Installation heißt die Datei ''local-host-names'' auch ''sendmail.cw'' und ist unter ''/etc/'' oder ''/etc/mail/'' zu finden.

Ein weiterer interessanter Aspekt zu der Problematik von oben sind wildcard-MXer, Einträge im DNS, der pauschal alle Mail an ''*.pocnet.net'' (Host, nicht User!) an das UUCP-Relay schickt. So eine allgemeine Formulierung ist in der Mailertable auch möglich, der Eintrag muß einfach mit einem Punkt beginnen, um relativ zu sein. 
Nachteil: Schickt jemand eine Mail an eine nicht existente Subdomain, schicken sich beide UUCP-Systeme die Mail solange zu, bis ein Sendmail aufgibt (normalerweise nach 26 Bounces).

=== Wie kommen die Daten von UUCP zum Sendmail? ===
[[#Wie gelangt eine Mail von Sendmail zu UUCP?|Weiter oben]] haben wir (ohne Details) gelernt das ''uux'' in der Kommandodatei etwas wie
Spezifikation der Daten absender@irgendwo 0 rmail empfänger@irgendwoanders
einträgt. ''Uuxqt'' macht nun nichts anderes als die empfangene Datei auszuführen, sprich die Daten an ''rmail'' zu verfüttern, welches sie dann brav bei Sendmail abgibt, also in dessen Queue legt. Wie [[#Wie arbeitet UUCP mit Sendmail zusammen?|hier]] bereits beschrieben, schaut Sendmail normalerweise selbständig die Queue regelmäßig durch. Wenn Mails zum Testen sofort ausgeliefert werden sollen, muß Sendmail mit <code>-q</code> aufgerufen werden, dann schaut er die Queue durch, liefert alles aus und beendet sich wieder. Alternativ kann auch ''rmail'' geändert oder frisch kompiliert werden.

=== Kann mein Sendmail denn UUCP? ===
Das bleibt festzustellen. Im Zweifelsfalle, testen:
leela:/root # fgrep Muucp /etc/mail/sendmail.cf
Muucp, P=/usr/bin/uux, F=DFMhuUd, S=FromU, R=EnvToU/HdrToU,
Muucp-old, P=/usr/bin/uux, F=DFMhuUd, S=FromU, R=EnvToU/HdrToU,
Muucp-new, P=/usr/bin/uux, F=mDFMhuUd, S=FromU, R=EnvToU/HdrToU,
Muucp-dom, P=/usr/bin/uux, F=mDFMhud, S=EnvFromUD/HdrFromSMTP, R=EnvToSMTP,
Muucp-uudom, P=/usr/bin/uux, F=mDFMhud, S=EnvFromUUD/HdrFromSMTP, R=EnvToSMTP,

Wenn da nix erscheint, kann er es nicht. Falls das der Fall sein sollte, nicht verzweifeln, soo schwer ist Sendmail auch nicht.

=== Er kann es nicht, kann ich ihm UUCP beibringen? ===
Klar! Alle moderneren Distros benutzen einen Weg, aus einer Definitionsdatei (oft ''/etc/mail/sendmail.mc'') eine entsprechende ''sendmail.cf'' zu generieren.

Wichtig ist, dass keinerlei
FEATURE(`nouucp', `nospecial')dnl
oder was in der Art in der mc auftaucht.

Folgende Punkte wären noch zu ergänzen, dabei sollten diese entsprechend einsortiert werden, also Feature zu den Features, Mailer zu den Mailern, usw.
FEATURE(mailertable)dnl
define(`UUCP_MAILER_MAX', `0')dnl
MAILER(uucp)dnl
Die verqueren Quotes müssen so übernommen werden, das liegt an m4. 
''UUCP_MAILER_MAX'' setzt das Mailgrößenlimit im Beispiel oben auf keins, sonst gehen etwas größere Mails wieder zurück. Danach kann die Mailertable angelegt und gehasht werden (Siehe [[#Wie gelangt eine Mail von Sendmail zu UUCP?|oben]]). Als nächstes gilt es, die Konfigurationsdatei mit m4 zu erstellen, auch das ist wiederum distributionsspezifisch.
cd /etc/mail
make

Stimmt jetzt alles, kann Sendmail neu gestartet und getestet werden:
leela:root # /usr/sbin/sendmail -bv heiko@hk.pocnet.net
heiko@hk.pocnet.net… deliverable: mailer uucp-dom, host heiko, user heiko@hk.pocnet.net

Umfangreichere Checks der einzelnen Regelsätze sind mit dem Testmode möglich:
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>

Danach wird explizit Ruleset 3 aufgerufen und die zu testende UUCP-Adresse eingegeben:
> 3,0 heiko@hk.pocnet.net
canonify input: heiko @ hk . pocnet . net
Canonify2 input: heiko < @ hk . pocnet . net >
Canonify2 returns: heiko < @ hk . pocnet . net . >
canonify returns: heiko < @ hk . pocnet . net . >
parse input: heiko < @ hk . pocnet . net . >
Parse0 input: heiko < @ hk . pocnet . net . >
Parse0 returns: heiko < @ hk . pocnet . net . >
ParseLocal input: heiko < @ hk . pocnet . net . >
ParseLocal returns: heiko < @ hk . pocnet . net . >
Parse1 input: heiko < @ hk . pocnet . net . >
MailerToTriple input: < uucp-dom : heiko > heiko < @ hk . pocnet . net . >
MailerToTriple returns: $# uucp-dom $@ heiko $: heiko < @ hk . pocnet . net . >
Parse1 returns: $# uucp-dom $@ heiko $: heiko < @ hk . pocnet . net . >
parse returns: $# uucp-dom $@ heiko $: heiko < @ hk . pocnet . net . >
So, das sieht gut aus, der UUCP-DOM-Mailer wird aufgerufen. Sendmail kann UUCP und die Mails werden weitergeroutet. Sendmail kann nun verlassen werden:
^D

=== Eine UUCP-Mail-Client Beispielkonfiguration ===
[[#Er kann es nicht, kann ich ihm UUCP beibringen?|Oben]] haben wir Sendmail beigebracht, Mails an ''bestimmte'' Domains per UUCP weiterzuleiten. Das paßt wunderbar für eine Site, die Relay spielt, also z. B. für den Rechner beim Provider. Die Rechner, die per UUCP als Clients unter diesem Server hängen, müßten alle möglichen Domains, erst in den Mailertable eintragen, damit Mails ’rausgehen. Das ist natürlich völlig unpraktikabel und deshalb gibt's da eine Alternative. Man muß einen Default-Mailer deklarieren, der UUCP benutzt. Die m4 Beispielkonfigurationsdatei ohne dann unnötige Mailertable sieht beispielsweise so aus:
VERSIONID(`$Id: client.mc, 2.1.3 for sendmail 8.11.0 07/23/00 by PoC Exp $')dnl
OSTYPE(linux)dnl
DOMAIN(generic)dnl
FEATURE(promiscous_relay)dnl
FEATURE(nocanonify)dnl
define(`SMART_HOST', `uucp-dom:''remotesys''')dnl
define(`UUCP_MAILER_MAX', `0')dnl
define(`confTRUSTED_USERS', `bin')dnl
define(`confPRIVACY_FLAGS', `goaway')dnl
MAILER(local)dnl
MAILER(smtp)dnl
MAILER(uucp)dnl
Das ''Define Smarthost'' definiert den oben beschriebenen Default-Mailer für Mails, die nicht auf dem lokalen Rechner bleiben sollen.

== Wie arbeiten UUCP und INN zusammen? ==
Das Network News Konzept ist im Vergleich zu Mail komplett anders. News sind Massenartikel und entsprechend diesem massenhaften Auftreten werden News über UUCP auch anders behandelt als Mails.

So werden News normalerweise nicht Artikel für Artikel gesendet sondern als Batch: Mehrere Artikel in einem Archiv, welches häufig noch zusätzlich gepackt (compress) wird, um den Datendurchsatz zu erhöhen.

News werden —ähnlich wie bei Sendmail durch die Mailertable— anhand einer Regeldatei (hier: ''newsfeeds'') weitergeleitet. Zum anderen werden per UUCP eingegangene News an ''rnews'' verfüttert, der diese gegebenenfalls auspackt, entbatcht und an INN weiterschaufelt.

=== Wie kommen die Daten von UUCP zum INN? ===
In der Kommandodatei eines Newspaketes steht ein ähnlicher Aufruf wie bei Mail drin, in etwa
Spezifikation der Daten 0 rnews.
''Uuxqt'' füttert nun ''rnews'' einfach mit den Daten aus dem Datenpaket. Die Daten liegen meist gepackt im Datenpaket vor, send-uucp hat diese beim Versand gepackt (compressed). Das Datenpaket beginnt deshalb mit der Zeile <code>#! cunbatch</code>, welche dafür sorgt, daß die Datei ordnungsgemäß entpackt wird. Rnews führt nun als erstes dieses Kommando aus. Danach liegt der entpackte Batch vor, alle News aneinandergekleistert und durch eine Zeile <code>#! rnews ''bytes''</code> getrennt. Diese Datei wird jetzt von ''rnews'' in einzelne Artikel zerhackt und an INN weitergesendet. Dazu sollte aber ein ME-Eintrag in der ''incoming.conf'' von INN stehen:
peer ME {
hostname: "localhost, 127.0.0.1, leela.pocnet.net"
}
Details siehe INN-Doku.

=== Wie kommen die Daten vom INN zu uucp? ===
In ''/etc/news/newsfeeds'' sollte ein Eintrag für das System, welches News empfangen soll stehen. Ich empfehle den UUCP-Namen und den Eintrag in newsfeeds gleich zu halten.

Wenn jetzt ein Artikel neu über einen Kanal (ein beliebiger Feed) eintrifft, wird in einer Datei ''spool/out.going/name'' ein Eintrag auf den Pfad des neu eingetroffenen Artikels hinzugefügt.

Diese Datei dient in festen Zeitabständen (cron) dem Script ''bin/send-uucp'' dazu, die eigentliche Verpackarbeit und uuxerei der Artikel durchzuführen.

=== Eine INN Beispielkonfiguration ===
Als Beispiel geht es hier um die Rechner ''leela.pocnet.net'' sowie ''deep-thought.hk.pocnet.net''. Beide Server müssen eine passende Zeile für das ''gegenüberliegende'' System in ihrer Feeddatei ''newsfeeds'' haben:
:{| class="wikitable"
!leela (UUCP-Node: poc)
!deep-thought (UUCP-Node: heiko)
|-
|align="center"|heiko/deep-thought.hk.pocnet.net:poc.*:Tf,Wn:
|align="center"|poc/leela.pocnet.net:poc.*:Tf,Wn:
|}

Anhand des Domainexcludes nach dem ersten / werden Bounces vermieden, das heißt, daß ein Artikel nicht immer wieder für das betreffende System wieder gebatcht wird, sobald er eingetroffen ist. Artikel, die ''hk.pocnet.net'' in der Path-Zeile stehen haben, werden nicht mehr an ''deep-thought'' geschickt und umgekehrt. Das vermeidet Bounces und schlechte Laune bei den Newsadministratoren.

Ansonsten entspricht die Konfiguration weitestgehend der Defaultmäßigen von INN. Kleinere Abwandlungen wie z. B. Expires oder Moderatorenliste und Ähnliches tun für die UUCP-Konfiguration nicht mal indirekt was zur Sache, dazu existieren weit mehr als genug Manpages und andere Dokumentationen.

Wichtig ist natürlich daß Gruppen, die an ein System gesendet werden, dort auch eingerichtet sind. Damit sollte ein einfacher Feed recht schnell zum Laufen zu bringen sein.

== Was kann ich tun wenn mir die FAQ zu kurz ist? ==
Ganz einfach, selbst basteln und die offenen Fragen beantworten. :-)

== Disclaimer ==
Diese FAQ wurde nach bestem Wissen und Gewissen zusammengestellt. Trotzdem kann es immer wieder passieren, daß sich Fehler einschleichen. Ich bitte deshalb um die Zusendung von Korrekturen an [mailto:poc@pocnet.net mich], falls so ein Fehler entdeckt wird! Ansonsten haftet der Leser für seine Handlungen selbst.

Diese FAQ soll kein Ersatz zur Doku der beschriebenen Programmpakete sein! Sie soll zusammenfassen, ergänzen und Lösungen zeigen. Trotzdem gilt nach wie vor: RTFM!

Danke an [mailto:Falk_Sauer@MGN.maus.de Falk Sauer] und [mailto:Ralf_Zehender@ccwn.fido.de Ralf Zehender] für die Initialzündung und erste Tips. Danke auch an die Jungs von O'Reilly Books, ohne die ich den ganzen Krempel wohl nie zum Laufen bekommen hätte. Danke auch an meine Tester [mailto:christophe@saout.de Chtephan], [mailto:dominik@vallendor.de Dominik], [mailto:heiko@wurst-wasser.net Heiko] und [mailto:phranck@phranck.net Phrank] sowie [mailto:roland@spinnaker.rhein.de Roland Rosenfeld] für weitere Tips.

== Historie ==
Diese FAQ unterliegt der [http://www.gnu.org/licenses/fdl-1.3.html GFDL].

{| class="wikitable"
|valign="top"|15.06.97
|erste offizielle Version.
|-
|valign="top"|21.06.97
|Client-UUCP ergänzt, Tippfehler bereinigt.
|-
|valign="top"|23.06.97
|Wie verläßt man Sendmail -bt? Sendmail -q, Tippfehler bereinigt.
|-
|valign="top"|25.06.97
|Kleinere Tips von Ralf Zehender eingebaut.
|-
|valign="top"|14.07.97
|Dicken Bug in der Client-Sendmail-Konfiguration ausgemerzt.
|-
|valign="top"|10.09.97
|Tippfehler und logische Ungereimtheiten ausgebügelt.
|-
|valign="top"|23.09.97
|Navigation verbessert (Backlinks ins Inhaltsverzeichnis um lahme Browserreloads zu vermeiden).
|-
|valign="top"|29.09.97
|Newsteil ergänzt und bereinigt, Disclaimer erweitert, Tips von Roland eingearbeitet.
|-
|valign="top"|10.10.97
|Mailteil bereinigt und ergänzt.
|-
|valign="top"|22.10.97
|Timegradegeheimnis ausgetüftelt und eingebracht.
|-
|valign="top"|06.03.98
|Timegrades nochmals besser erklärt.
|-
|valign="top"|09.03.99
|Kleinere Fehler ausgemerzt, Tippfehler bereinigt, Umzug der Seite zum neuen Arbeitgeber.
|-
|valign="top"|23.07.00
|Größere Überarbeitung, einige Kapitel vereinfacht, Pfadangaben an aktuelle Programmversionen angepaßt, Timegrades 'rausgeworfen, weil das bei den heutigen Telefontarifen mehr verwirrt als hilft, uvAm.
|-
|valign="top"|22.11.00
|Layout angepaßt, kleinere Typos behoben, Umzug auf den eigenen Server.
|-
|valign="top"|17.01.01
|Security mit called-login ergänzt.
|-
|valign="top"|22.02.01
|Neue URLs durch Umstrukturierungen.
|-
|valign="top"|14.03.01
|Copyright-Ergänzung, damit die FAQ auch mal offizielle Wege findet.
|-
|valign="top"|21.05.01
|Kernel-2.4 Note ergänzt.
|-
|valign="top"|16.12.01
|Ergänzung von Beispielen zu uustat, Tippfehler korrigiert. Danke an [mailto:andre@family-uhl.de André Uhl] für die Verbesserungen!
|-
|valign="top"|05.04.02
|URL zur Doku ergänzt.
|-
|valign="top"|03.05.04
|Kernel 2.4/Protokoll besser erklärt (für Götz).
|-
|valign="top"|22.12.06
|Mailadresse entfernt.
|-
|valign="top"|18.03.11
|Überarbeitet: Modernisiert, alten Krempel raus, Tippfehler korrigiert, usw., Umsetzung.
|-
|valign="top"|08.01.18
|Überarbeitet: Abschnitt über Ssh als Transport eingefügt.
|}

[[Kategorie:Internet]]
[[Kategorie:Protokoll]]
[[Kategorie:UNIX]]

Satisfactory Dedicated Server auf Debian Linux via Kommandozeile installieren

2024-12-07T15:51:09Z

PoC: Neu

Die Installation eines '''satisfactory Dedicated Servers auf auf Debian Linux via Kommandozeile''' ist relativ einfach zu erledigen.

Der geneigte Leser möchte deswegen vorab den Artikel [[Steam-Client auf Debian-Linux optimal einrichten]] lesen und durcharbeiten.

Der Server benötigt rund 4 GiB Platz auf der Platte und rund 4 GiB RAM (ohne Spieler).

== Installation ==
Sinnvollerweise richtet man den Server so ein, dass er unter einem eigenen Benutzer läuft. Dazu fügen wir den Benutzer satisfactory hinzu:
<syntaxhighlight lang="shell">
adduser --ingroup games --disabled-password --gecos 'Satisactory Dedicated Server Account' satisfactory
</syntaxhighlight>

Nun installieren wir den Server. Ganz wichtig ist, dass in ''/home'' genügend freier Platz zu Verfügung steht.
<syntaxhighlight lang="shell">
su - satisfactory
mkdir -p ~/.local/share
ln -s /usr/local/games/Steam ~/.local/share/Steam
steamcmd +force_install_dir ~/SatisfactoryDedicatedServer +login anonymous +app_update 1690800 validate +quit
</syntaxhighlight>

Der Download wird nun durchgeführt und dauert seine Zeit.

Folgende Fehler sind derzeit bekannt:
* <code>Error! App '1690800' state is 0x202 after update job.</code>: Nicht genügend freier Platz in ''/home/satisfactory''.
* <code>Error! App '1690800' state is 0x426 after update job.</code>: Servertask läuft noch. Muss vorher beendet werden.

Nun kann der Server gestartet werden.
<syntaxhighlight lang="shell">
cd SatisfactoryDedicatedServer
screen -d -m -S SatisfactoryServer -- ./FactoryServer.sh
screen -r
</syntaxhighlight>

In der Screen-Session sieht man die Logeinträge. Mit <tt>Ctrl-A-D</tt> kommt man aus der Session wieder raus.

=== Automatischer Start ===
Durch den nachfolgenden Cronjob wird der Server nach einem Reboot automatisch gestartet. Muss mit <code>crontab -e</code> als Benutzer ''satisfactory'' eingefügt werden:
@reboot cd SatisfactoryDedicatedServer && screen -d -m -S SatisfactoryServer -- ./FactoryServer.sh

=== Firewall ===
Der Server arbeitet nur über Port 7777, tcp und udp.

=== Server beanspruchen und ein Spiel starten ===
Bevor der Server ein Spiel starten kann, muss er zunächst beansprucht werden:

* Spiel auf einem Client starten,
* Vom Server-Manager im Hauptmenü aus den Server hinzufügen,
* Dort einen Namen für den Server festlegen und dessen Administratorkennwort festlegen.

Jetzt kann ein neues Spiel erstellt werden. Ein vorhandenes Spiel kann auch vom Ingame-Server-Manager aus auf den Server importiert werden.

Der Spielerkennwortschutz ist standardmäßig nicht aktiviert, aber ein Spielerkennwort kann über dieselbe Benutzeroberfläche festgelegt werden.

== Weblinks ==
* [https://satisfactory.wiki.gg/wiki/Dedicated_servers Dedicated servers], Satisfactory Wiki

[[Kategorie: Linux]]
[[Kategorie: Spiel]]

Steam-Client auf Debian-Linux optimal einrichten

2024-12-07T15:29:12Z

PoC: /* Gemeinsamen Datenpool einrichten */ Benötigt dass User installieren dürfen.

Steam lädt beim Starten pro Benutzer ggfs. ein Update herunter und installiert dies in ''~/.local/share/Steam/''. Derzeit fasst dieses Verzeichnis 213 MiB. Um diesen unnötigen Overhead abzumildern, verschieben wir die Daten an einen zentralen Platz.

Updates müssen trotzdem als ''root'' erfolgen, da nur dieser Benutzer die Dateien überschreiben darf.

== Steam-Client ==
Als Grundvoraussetzung für alle Steam-Themen muss zuerst mal der Client installiert und grundkonfiguriert werden. Die zugehörigen Libraries sind allerdings nicht für 64-Bit x86 verfügbar, weswegen zuvor diese teilweise kompatible Architektur angeknipst werden muss.
<syntaxhighlight lang="shell">
dpkg --add-architecture i386
apt-get install steamcmd
</syntaxhighlight>

Im Zuge dessen werden einige benötigte 32-Bit Libraries installiert und eine Bestätigung der Lizenzbedingungen abgefragt.

=== Initialer Start ===
<syntaxhighlight lang="shell">
/usr/games/steamcmd
</syntaxhighlight>

Hier scrollt nun eine Menge Text durch mit Hinweisen ein Update. Am Ende muss ein fett gedruckter Prompt da stehen:
'''Steam>'''

Der Client kann an dieser Stelle mit <code>quit</code> verlassen werden.

=== Gemeinsamen Datenpool einrichten ===
<syntaxhighlight lang="shell" line>
mkdir /usr/local/share/games
mv ~/.local/share/Steam /usr/local/games
ln -s /usr/local/games/Steam ~/.local/share/Steam
chgrp -R games /usr/local/games/Steam
find /usr/local/games/Steam -type d -exec chmod 2755 {} \;
find /usr/local/games/Steam -type f -exec chmod 644 {} \;
find /usr/local/games/Steam -type f -a $ -name "*.sh" -o -name "*.so" -o -name "*.so.*" $ -exec chmod 755 {} \;
chmod 755 /usr/local/games/Steam/steamcmd/linux32/steamcmd /usr/local/games/Steam/steamcmd/linux32/steamerrorreporter
chmod 2770 /usr/local/games/Steam
</syntaxhighlight>

Der Symlink in Zeile 3 ist für jeden Benuzer der Steam benutzen darf vorab einzurichten. Ggfs. ist der übrige Verzeichnisbaum ''~/.local/share'' vorher anzulegen.

=== Suchpfad ergänzen ===
<syntaxhighlight lang="shell">
vi /etc/profile
</syntaxhighlight>

Natürlich kann man den Editor seiner Wahl verwenden. Letztendlich kommt es darauf an, in den Zeilen, in denen die <code>PATH</code>-Variable gesetzt wird, den Pfad zum Steam-Shellscript zu ergänzen.

;Vorher:
<syntaxhighlight lang="shell" line>
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
</syntaxhighlight>

;Nachher:
<syntaxhighlight lang="shell" line>
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
</syntaxhighlight>

Hinweis: Die Änderungen in Gruppenzuordnungen und des <tt>PATH</tt> werden erst nach einem Neulogin aktiv.

Damit sind die Vorbereitungen für die Installation von z. B. ''Dedicated Servern'' abgeschlossen.

[[Kategorie: Linux]]
[[Kategorie: Spiel]]

7 Days To Die Dedicated Server auf Debian Linux via Kommandozeile installieren

2024-12-06T22:21:34Z

PoC: Verweis auf den separaten Artikel für Steam

Die Installation eines '''7 Days To Die Dedicated Servers auf auf Debian Linux via Kommandozeile''' ist nicht ganz trivial. Das gilt vor allem für die Inbetriebnahme des Steam-Clients für die Kommandozeile.

Der geneigte Leser möchte deswegen vorab den Artikel [[Steam-Client auf Debian-Linux optimal einrichten]] lesen und durcharbeiten.

Der Server benötigt rund 15 GiB Platz auf der Platte und rund 3,5 GiB RAM (ohne Spieler).

== Server ==
Sinnvollerweise richtet man den Server so ein, dass er unter einem eigenen Benutzer läuft. Dazu fügen wir den Benutzer sdtd hinzu:
adduser --ingroup games --disabled-password --gecos 'Seven Days To Die Dedicated Server Account' sdtd

=== Installation ===
Nun installieren wir den Server. Ganz wichtig ist, dass in ''/home'' genügend freier Platz zu Verfügung steht.
su - sdtd
steamcmd

Ab hier ist nun nach jeder Eingabe der <code>'''Steam>'''</code>-Prompt sichtbar.
login anonymous
app_update 294420 validate

Der Download wird nun durchgeführt und dauert seine Zeit.

Folgende Fehler sind derzeit bekannt:
* <code>Error! App '294420' state is 0x202 after update job.</code>: Nicht genügend freier Platz in ''/home/sdtd/Steam''.
* <code>Error! App '294420' state is 0x426 after update job.</code>: Servertask läuft noch. Muss vorher beendet werden.

Nach dem Update kann der Client wiederum beendet werden:
quit

=== Konfiguration ===
Die Konfiguration findet sich in ''~/Steam/steamapps/common/"7 Days to Die Dedicated Server"/serverconfig.xml''.

Mit <code>telnet localhost 8081</code> kann der Server via Kommandozeile gesteuert werden (sofern er läuft).

=== Automatischer Start ===
Damit der Server nach dem automatischen Start ordnungsgemäß im Hintergrund weiterläuft, muss im Startscript ''startserver.sh'' eine Anpassung vorgenommen werden: Die eigentlichen Startzeilen müssen mit einer Leerstelle und Kaufmanns-und (&) abgeschlossen werden:
;Vorher:
./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS

;Nachher:
./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS &

Durch den nachfolgenden Cronjob wird der Server nach einem Reboot automatisch gestartet. Muss mit <code>crontab -e</code> als Benutzer ''sdtd'' eingefügt werden:
@reboot cd ~/Steam/steamapps/common/'7 Days to Die Dedicated Server' && ./startserver.sh -configfile=serverconfig.xml

Mit der o. G. Zeile als Benutzer ''sdtd'', ohne das ''@reboot'' vornedran kann der Server dann gestartet und die Shell alsdann geschlossen werden (logout).

==== Server beenden ====
Mit dem Konsolen-Kommando (telnet, s. O.) ''shutdown'' kann der Server ordnungsgemäß beendet werden. Ob das auch bei einem normalen ''kill''-Kommando im Rahmen eines Host-Reboots so ordentlich läuft, ist derzeit unklar.

== Debugging ==
Im Unterordner ''7DaysToDieServer_Data'' findet sich ein ''output_log'' mit Timestamp hintendran, da landen die Ausgaben vom Server drin.

== Firewall ==
Der Server öffnet folgende Ports:
* tcp/127.0.0.1:8081 (Management)
* tcp/26900
* udp/26900
* udp/26902

Die letzten drei müssen in einer ggfs. vorhandenen Firewall bzw. einem NAT-Router entsprechend geöffnet bzw. weitergeleitet werden.

== Weblinks ==
* [https://wiki.dawico.de/display/WIKI/7+Days+To+Die%3A+dedicated+Server+auf+Debian+installieren 7 Days To Die: dedicated Server auf Debian installieren] (fehlerhaft, aber als initialer Start für diesen Artikel gut geeignet)
* [https://7daystodie.gamepedia.com/Server Server-Dokumentation] im 7 Days to Die Wiki
* [https://unix.stackexchange.com/questions/463708/uninstall-a-steam-game-with-the-console Uninstall a Steam game with the console], Stack Exchange
* [https://steamcommunity.com/sharedfiles/filedetails/?l=german&id=360404397 Installing Linux dedicated server for 7 days to die] mit Tips zur Installation von experimentellen Releases.

[[Kategorie: Linux]]
[[Kategorie: Spiel]]

Steam-Client auf Debian-Linux optimal einrichten

2024-12-06T22:18:45Z

PoC: Neu

Steam lädt beim Starten pro Benutzer ggfs. ein Update herunter und installiert dies in ''~/.local/share/Steam/''. Derzeit fasst dieses Verzeichnis 213 MiB. Um diesen unnötigen Overhead abzumildern, verschieben wir die Daten an einen zentralen Platz.

Updates müssen trotzdem als ''root'' erfolgen, da nur dieser Benutzer die Dateien überschreiben darf.

== Steam-Client ==
Als Grundvoraussetzung für alle Steam-Themen muss zuerst mal der Client installiert und grundkonfiguriert werden. Die zugehörigen Libraries sind allerdings nicht für 64-Bit x86 verfügbar, weswegen zuvor diese teilweise kompatible Architektur angeknipst werden muss.
<syntaxhighlight lang="shell">
dpkg --add-architecture i386
apt-get install steamcmd
</syntaxhighlight>

Im Zuge dessen werden einige benötigte 32-Bit Libraries installiert und eine Bestätigung der Lizenzbedingungen abgefragt.

=== Initialer Start ===
<syntaxhighlight lang="shell">
/usr/games/steamcmd
</syntaxhighlight>

Hier scrollt nun eine Menge Text durch mit Hinweisen ein Update. Am Ende muss ein fett gedruckter Prompt da stehen:
'''Steam>'''

Der Client kann an dieser Stelle mit <code>quit</code> verlassen werden.

=== Gemeinsamen Datenpool einrichten ===
<syntaxhighlight lang="shell" line>
mkdir /usr/local/share/games
mv ~/.local/share/Steam /usr/local/games
ln -s /usr/local/games/Steam ~/.local/share/Steam
chgrp -R games /usr/local/games/Steam
find /usr/local/games/Steam -type d -exec chmod 2755 {} \;
find /usr/local/games/Steam -type f -exec chmod 644 {} \;
find /usr/local/games/Steam -type f -a $ -name "*.sh" -o -name "*.so" -o -name "*.so.*" $ -exec chmod 755 {} \;
chmod 755 /usr/local/games/Steam/steamcmd/linux32/steamcmd /usr/local/games/Steam/steamcmd/linux32/steamerrorreporter
chmod 2750 /usr/local/games/Steam
</syntaxhighlight>

Der Symlink in Zeile 3 ist für jeden Benuzer der Steam benutzen darf vorab einzurichten. Ggfs. ist der übrige Verzeichnisbaum ''~/.local/share'' vorher anzulegen.

=== Suchpfad ergänzen ===
<syntaxhighlight lang="shell">
vi /etc/profile
</syntaxhighlight>

Natürlich kann man den Editor seiner Wahl verwenden. Letztendlich kommt es darauf an, in den Zeilen, in denen die <code>PATH</code>-Variable gesetzt wird, den Pfad zum Steam-Shellscript zu ergänzen.

;Vorher:
<syntaxhighlight lang="shell" line>
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
</syntaxhighlight>

;Nachher:
<syntaxhighlight lang="shell" line>
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
</syntaxhighlight>

Hinweis: Die Änderungen in Gruppenzuordnungen und des <tt>PATH</tt> werden erst nach einem Neulogin aktiv.

Damit sind die Vorbereitungen für die Installation von z. B. ''Dedicated Servern'' abgeschlossen.

[[Kategorie: Linux]]
[[Kategorie: Spiel]]

Linux von BIOS- auf UEFI-Boot umstellen

2024-09-20T15:32:29Z

PoC: /* Checkliste */ Formatierung

Ohne zu wissen, was es mit EFI auf sich hat, ist das '''Umstellen von Linux von BIOS- auf EFI-Boot''' auf echter Serverhardware (die meistens minutenlang in der internen Firmware rumhängt) zeitraubend und frustrierend. In Kürze Erklärung und Wichtiges:

== Grundlagen ==
(U)EFI ((Unified) Extensible Firmware Interface) ist mit neuerer Hardware unvermeidbar. Eigentlich ist das Thema sehr einfach: Es gibt keinen binären Bootblock mehr, sondern eine kleine FAT32-Partition zu Beginn der Boot-Disk (ggfs. HW-RAID-Array). Die Bootloader der verschiedenen Betriebssysteme erzeugen eine Verzeichnisstruktur, in welcher dann das eigentliche Startprogramm hinterlegt wird. Die Firmware sammelt beim Systemstart eine Liste der gefundenen ausführbaren Binaries (PE32+ executable) und bietet diese dann zum Start an (bzw. der Standardeintrag wird gestartet).

== Vorbereitungen ==
* Ohne Repartitionieren geht es nicht. Da die Umstellung auf EFI durch einem Hardwaretausch mit anschließender Kopie der vorhandenen Installation durchgeführt wird, ist das aber kein Beinbruch.
* Der initiale Boot (CD, ISO-Image, PXE, USB-Stick, usw.) muss zwingend im EFI-Modus mit einem dementsprechend EFI-fähigen Bootmedium durchgeführt werden. Das Debian-Live-Image von Debian 8 oder älter ist nicht geeignet! Erst ab 9 gibt es EFI-Support, z. B. [https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.2.0-amd64-standard.iso debian-live-12.2.0-amd64-standard.iso]. Ohne Boot im EFI-Modus sind die EFI-Hooks in der Firmware unsichtbar und Grub-EFI wird mit Fehlern um sich werfen.

== Checkliste ==
* Neues System vorbereiten (FW-Updates, BIOS-Settings, usw.),
* Bootmedium vorbereiten (siehe oben),
* Boot via EFI-Bootmenü von diesem Medium,
* Ggfs. manuelle Netzwerkkonfiguration,
* Nachinstallation von benötigten Systemkomponenten,
apt-get install gdisk mdadm dosfstools dump
* Vorbereiten der Platten für das OS:
** Partitionieren (''gdisk''), dabei (eine) z. B. 5 MB große EFI-Partition(en) anlegen, Typ EF00,<ref>Tatsächlich benötigt werden vom Grub-Loader einige 100 KBytes.</ref>
** Ggfs. Erzeugen der gewünschten Arrays mit ''mdadm'',
** Dateisysteme erzeugen, dabei die EFI-Partition(en) mit einem FAT32-Dateisystem versehen,
mkfs.fat /dev/sda1,
** Mounten des OS-Dateisystems nach z. B. ''/mnt'', <code>cd /mnt</code>,
** Kopieren der Installation vom Quellsystem, wie gehabt mit
ssh ''srcsys'' "dump -0a -b 256 -f - /dev/sda1" |restore -r -b 256 -f -
** Vorbereitungen für ''chroot'': <code>mount -o bind /dev dev/</code>,
* <code>chroot /mnt</code>,
* Nachmounten von Kernel-Pseudo-Dateisystemen:
mount -t proc none /proc; mount -t sysfs none /sys; mount -t devpts none /dev/pts
* Anpassen der ''/etc/fstab'', dabei Eintragen der EFI-Partition(en),
/dev/sda1 /boot/efi vfat defaults 0 0
* Anlegen des EFI-Bootverzeichnisses,
mkdir /boot/efi
* Anpassen der ''/etc/fstab'', dabei Eintragen von ''efivars'':
none /sys/firmware/efi/efivars efivarfs defaults 0 0
* Mounten der EFI-Partition(en),
mount -a
* Nachinstallation von auf dem später laufenden System benötigten Systemkomponenten (mdadm),
* Ggfs. schreiben der RAID-Konfiguration mit <code>/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf; update-initramfs -u</code>,
* Austauschen von Grub,
apt-get install grub-efi-amd64 grub-efi-amd64-bin
* Sichern der Grub-Defaults,
cp -a /etc/default/grub /etc/default/grub~
* Löschen von altem Grub-PC-Kram, die Frage nach Löschen vom alten Bootloader bejahen,
dpkg -P grub-pc grub-pc-bin
* Restore der Grub-Defaults,
mv /etc/default/grub~ /etc/default/grub
* Restore von gemeinsamen Grub-Dateien durch Reinstallation,
apt-get install --reinstall grub-efi-amd64 grub-efi-amd64-bin

Grub-EFI erfordert keine Platte mehr als Parameter beim beim Grub-Install:
grub-install
update-grub

* Raus aus der chroot: <code>exit</code>,
* Unmounten:
umount boot/efi* dev/pts dev proc sys/firmware/efi/efivars sys; cd ..; umount mnt

Nach einem Reboot muss die Installation dann wieder sauber hochkommen. Weitere Schritte wie Netzwerkkonfigurationsanpassungen an die neue Hardware sind nicht beschrieben.

=== Mögliche Fehler ===
Aus der Praxis…

==== Meldung: EFI variables are not supported on this system ====
grub-install: warning: EFI variables are not supported on this system.

Dieser Fehler kann zum einen bedeuten, dass das System selbst im BIOS-Modus gestartet wurde. Allerdings scheint es ab Debian 11 notwendig zu sein, einen weiteren Mountpoint zu setzen:

none /sys/firmware/efi/efivars efivarfs defaults 0 0

Damit funktioniert dann auch ein <code>grub-install</code> fehlerfrei.

==== Nach Reboot erscheint nur die Grub-Kommandozeile ====
Falls das alte BIOS-Grub-Paket mit <code>--purge</code> gelöscht wurde, hätte '''unbedingt''' danach ein
grub-install
update-grub
abgesetzt werden müssen, da das Purge des BIOS-Paketes auch die Konfiguration und weitere Dateien löscht.

Lösung: Die Schritte von oben nochmal wiederholen:
* Boot von externem Medium,
* <code>chroot</code>,
* Mounten der benötigten Partitionen,
* Grub-Konfiguration neu schreiben:
grub-install
update-grub
* <code>umount</code>,
* Reboot.

=== Redundanz ===
Beim Booten kann dann statt einem möglicherweise wechselnden Gerät, eine Boot-Konfiguration aus dem genannten Verzeichnis eines beliebigen Gerätes gestartet werden. Vorbei sind die Tage, in denen in einem Software-RAID die erste Platte ausfällt, die zweite Platte dann an die erste Stelle rückt, der Bootblock ist aber nicht auf die erste Platte konfiguriert, sondern entweder überhaupt nicht<ref>Schlampiger Admin…</ref> oder das BIOS kommt mit der neuen BIOS-ID (0x80 statt 0x81) nicht zurecht und verweigert den Boot.

EFI hat allerdings eine konzeptionelle Schwachstelle: Die Einfachhheit eine ''/boot''-Partition per Software-RAID zu spiegeln ist nicht vorgesehen. Man kann sich was basteln über ''mdadm'' mit nicht persistentem Superblock (damit keine Daten überschrieben werden), aber das ist letztlich alles Gebastel. 
Am Einfachsten ist es, manuell die Verzeichnisstruktur auf die zuvor manuell identisch partitionierten und in ''/boot/efi2'', ''/boot/efi3'', usw. gemounteten FAT32-Partitionen zu kopieren.

Für Debian muss eine Datei angelegt und als ausführbar markiert werden: ''/etc/grub.d/42_update-hook'':
#!/bin/sh
# Dirty hack: If there are multiple FA32-mountpoints in /boot/efi, sync
# contents manually to provide poor man's redundancy.
if mount -t vfat |awk '{print $3}' |grep -q '^/boot/efi$'; then
cat /dev/null > /var/log/update-grub.log
for MP in `mount -t vfat |awk '{print $3}' |grep -v '^/boot/efi$'`; do
rsync -av --delete /boot/efi/ ${MP}/ >> /var/log/update-grub.log
done
else
echo "No EFI Mount Point detected." > /var/log/update-grub.log
fi

# --EOF--

Bei jedem Aufruf, der die Grub-Konfiguration neu erzeugt, wird somit auch die Struktur kopiert. Das beinhaltet auch Updates von Kernel und Grub selbst. Fire and forget.

== Weblinks ==
* [https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/ UEFI booting and RAID1]
* [https://www.heise.de/newsticker/meldung/Was-Linux-Anwender-ueber-UEFI-wissen-muessen-4204725.html Was Linux-Anwender über UEFI wissen müssen]
* [https://packages.debian.org/stable/bootcd Run your system from cd without need for disks]<ref>Ob das EFI kompatible Images herstellt, ist derzeit nicht bekannt.</ref>
* [https://wiki.debian.org/EFIStub …it is possible to load the kernel directly, without any additional bootloader]

== Fußnoten ==
<references />

[[Kategorie: Linux]]

Linux von BIOS- auf UEFI-Boot umstellen

2024-09-20T15:31:20Z

PoC: /* Checkliste */ Formatierung

Ohne zu wissen, was es mit EFI auf sich hat, ist das '''Umstellen von Linux von BIOS- auf EFI-Boot''' auf echter Serverhardware (die meistens minutenlang in der internen Firmware rumhängt) zeitraubend und frustrierend. In Kürze Erklärung und Wichtiges:

== Grundlagen ==
(U)EFI ((Unified) Extensible Firmware Interface) ist mit neuerer Hardware unvermeidbar. Eigentlich ist das Thema sehr einfach: Es gibt keinen binären Bootblock mehr, sondern eine kleine FAT32-Partition zu Beginn der Boot-Disk (ggfs. HW-RAID-Array). Die Bootloader der verschiedenen Betriebssysteme erzeugen eine Verzeichnisstruktur, in welcher dann das eigentliche Startprogramm hinterlegt wird. Die Firmware sammelt beim Systemstart eine Liste der gefundenen ausführbaren Binaries (PE32+ executable) und bietet diese dann zum Start an (bzw. der Standardeintrag wird gestartet).

== Vorbereitungen ==
* Ohne Repartitionieren geht es nicht. Da die Umstellung auf EFI durch einem Hardwaretausch mit anschließender Kopie der vorhandenen Installation durchgeführt wird, ist das aber kein Beinbruch.
* Der initiale Boot (CD, ISO-Image, PXE, USB-Stick, usw.) muss zwingend im EFI-Modus mit einem dementsprechend EFI-fähigen Bootmedium durchgeführt werden. Das Debian-Live-Image von Debian 8 oder älter ist nicht geeignet! Erst ab 9 gibt es EFI-Support, z. B. [https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.2.0-amd64-standard.iso debian-live-12.2.0-amd64-standard.iso]. Ohne Boot im EFI-Modus sind die EFI-Hooks in der Firmware unsichtbar und Grub-EFI wird mit Fehlern um sich werfen.

== Checkliste ==
* Neues System vorbereiten (FW-Updates, BIOS-Settings, usw.),
* Bootmedium vorbereiten (siehe oben),
* Boot via EFI-Bootmenü von diesem Medium,
* Ggfs. manuelle Netzwerkkonfiguration,
* Nachinstallation von benötigten Systemkomponenten,
apt-get install gdisk mdadm dosfstools dump
* Vorbereiten der Platten für das OS:
** Partitionieren (''gdisk''), dabei (eine) z. B. 5 MB große EFI-Partition(en) anlegen, Typ EF00,<ref>Tatsächlich benötigt werden vom Grub-Loader einige 100 KBytes.</ref>
** Ggfs. Erzeugen der gewünschten Arrays mit ''mdadm'',
** Dateisysteme erzeugen, dabei die EFI-Partition(en) mit einem FAT32-Dateisystem versehen,
mkfs.fat /dev/sda1,
** Mounten des OS-Dateisystems nach z. B. ''/mnt'', <code>cd /mnt</code>,
** Kopieren der Installation vom Quellsystem, wie gehabt mit
ssh ''srcsys'' "dump -0a -b 256 -f - /dev/sda1" |restore -r -b 256 -f -
** Vorbereitungen für ''chroot'': <code>mount -o bind /dev dev/</code>,
* <code>chroot /mnt</code>,
* Nachmounten von Kernel-Pseudo-Dateisystemen:
mount -t proc none /proc; mount -t sysfs none /sys; mount -t devpts none /dev/pts
* Anpassen der ''/etc/fstab'', dabei Eintragen der EFI-Partition(en),
/dev/sda1 /boot/efi vfat defaults 0 0
* Anlegen des EFI-Bootverzeichnisses,
mkdir /boot/efi
* Anpassen der ''/etc/fstab'', dabei Eintragen von ''efivars'':
none /sys/firmware/efi/efivars efivarfs defaults 0 0
* Mounten der EFI-Partition(en),
mount -a
* Nachinstallation von auf dem später laufenden System benötigten Systemkomponenten (mdadm),
* Ggfs. schreiben der RAID-Konfiguration mit <code>/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf; update-initramfs -u</code>,
* Austauschen von Grub,
apt-get install grub-efi-amd64 grub-efi-amd64-bin
* Sichern der Grub-Defaults,
cp -a /etc/default/grub /etc/default/grub~
* Löschen von altem Grub-PC-Kram, die Frage nach Löschen vom alten Bootloader bejahen,
dpkg -P grub-pc grub-pc-bin
* Restore der Grub-Defaults,
mv /etc/default/grub~ /etc/default/grub
* Restore von gemeinsamen Grub-Dateien durch Reinstallation,
apt-get install --reinstall grub-efi-amd64 grub-efi-amd64-bin

Grub-EFI erfordert keine Platte mehr als Parameter beim beim Grub-Install:
grub-install
update-grub

* Raus aus der chroot: <code>exit</code>,
* Unmounten: <code>umount boot/efi* dev/pts dev proc sys; cd ..; umount mnt</code>.

Nach einem Reboot muss die Installation dann wieder sauber hochkommen. Weitere Schritte wie Netzwerkkonfigurationsanpassungen an die neue Hardware sind nicht beschrieben.

=== Mögliche Fehler ===
Aus der Praxis…

==== Meldung: EFI variables are not supported on this system ====
grub-install: warning: EFI variables are not supported on this system.

Dieser Fehler kann zum einen bedeuten, dass das System selbst im BIOS-Modus gestartet wurde. Allerdings scheint es ab Debian 11 notwendig zu sein, einen weiteren Mountpoint zu setzen:

none /sys/firmware/efi/efivars efivarfs defaults 0 0

Damit funktioniert dann auch ein <code>grub-install</code> fehlerfrei.

==== Nach Reboot erscheint nur die Grub-Kommandozeile ====
Falls das alte BIOS-Grub-Paket mit <code>--purge</code> gelöscht wurde, hätte '''unbedingt''' danach ein
grub-install
update-grub
abgesetzt werden müssen, da das Purge des BIOS-Paketes auch die Konfiguration und weitere Dateien löscht.

Lösung: Die Schritte von oben nochmal wiederholen:
* Boot von externem Medium,
* <code>chroot</code>,
* Mounten der benötigten Partitionen,
* Grub-Konfiguration neu schreiben:
grub-install
update-grub
* <code>umount</code>,
* Reboot.

=== Redundanz ===
Beim Booten kann dann statt einem möglicherweise wechselnden Gerät, eine Boot-Konfiguration aus dem genannten Verzeichnis eines beliebigen Gerätes gestartet werden. Vorbei sind die Tage, in denen in einem Software-RAID die erste Platte ausfällt, die zweite Platte dann an die erste Stelle rückt, der Bootblock ist aber nicht auf die erste Platte konfiguriert, sondern entweder überhaupt nicht<ref>Schlampiger Admin…</ref> oder das BIOS kommt mit der neuen BIOS-ID (0x80 statt 0x81) nicht zurecht und verweigert den Boot.

EFI hat allerdings eine konzeptionelle Schwachstelle: Die Einfachhheit eine ''/boot''-Partition per Software-RAID zu spiegeln ist nicht vorgesehen. Man kann sich was basteln über ''mdadm'' mit nicht persistentem Superblock (damit keine Daten überschrieben werden), aber das ist letztlich alles Gebastel. 
Am Einfachsten ist es, manuell die Verzeichnisstruktur auf die zuvor manuell identisch partitionierten und in ''/boot/efi2'', ''/boot/efi3'', usw. gemounteten FAT32-Partitionen zu kopieren.

Für Debian muss eine Datei angelegt und als ausführbar markiert werden: ''/etc/grub.d/42_update-hook'':
#!/bin/sh
# Dirty hack: If there are multiple FA32-mountpoints in /boot/efi, sync
# contents manually to provide poor man's redundancy.
if mount -t vfat |awk '{print $3}' |grep -q '^/boot/efi$'; then
cat /dev/null > /var/log/update-grub.log
for MP in `mount -t vfat |awk '{print $3}' |grep -v '^/boot/efi$'`; do
rsync -av --delete /boot/efi/ ${MP}/ >> /var/log/update-grub.log
done
else
echo "No EFI Mount Point detected." > /var/log/update-grub.log
fi

# --EOF--

Bei jedem Aufruf, der die Grub-Konfiguration neu erzeugt, wird somit auch die Struktur kopiert. Das beinhaltet auch Updates von Kernel und Grub selbst. Fire and forget.

== Weblinks ==
* [https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/ UEFI booting and RAID1]
* [https://www.heise.de/newsticker/meldung/Was-Linux-Anwender-ueber-UEFI-wissen-muessen-4204725.html Was Linux-Anwender über UEFI wissen müssen]
* [https://packages.debian.org/stable/bootcd Run your system from cd without need for disks]<ref>Ob das EFI kompatible Images herstellt, ist derzeit nicht bekannt.</ref>
* [https://wiki.debian.org/EFIStub …it is possible to load the kernel directly, without any additional bootloader]

== Fußnoten ==
<references />

[[Kategorie: Linux]]

Passwortreset Innovaphone IP200 und IP202

2024-07-27T20:08:12Z

PoC: Default-Credentials

Für einen Reset auf Herstellergrundeinstellungen: Alt drücken und gedrückt halten, Stromversorgung anstecken und ca. 3 s warten bis die rote Hörer-LED aufhört zu blinken. Alt loslassen und nochmal Stromversorgung ab- und wieder anstecken.

Der Standardbenutzer zur Anmeldung ist ''admin''. Das Standardpasswort ist der Gerätetyp, also ''ip200'' bzw. ''ip202''.

[[Kategorie: Passwort-Reset]]
[[Kategorie: VoIP‏]]

7 Days To Die Dedicated Server auf Debian Linux via Kommandozeile installieren

2024-05-13T00:18:16Z

PoC: Genauer

Die Installation eines '''7 Days To Die Dedicated Servers auf auf Debian Linux via Kommandozeile''' ist nicht ganz trivial. Das gilt vor allem für die Inbetriebnahme des Steam-Clients für die Kommandozeile.

Der Server benötigt rund 15 GiB Platz auf der Platte und rund 3,5 GiB RAM (ohne Spieler).

== Steam-Client ==
Als Grundvoraussetzung für alle Steam-Themen muss zuerst mal der Client installiert und grundkonfiguriert werden. Das passiert am Besten als ''root'', um den Client systemweit für alle Benutzer anbieten zu können.

=== Download und Auspacken ===
Im Zielverzeichnis müssen rund 285 MiB Platz vorhanden sein.
cd /tmp
wget <nowiki>http://media.steampowered.com/installer/steamcmd_linux.tar.gz</nowiki>
mkdir /opt/steamcmd
cd /opt/steamcmd
tar xzf /tmp/steamcmd_linux.tar.gz && rm -f /tmp/steamcmd_linux.tar.gz

Alternativ kann mit <code>apt-get install steamcmd</code> das zugehörige Debian-Paket installiert werden. Die weiteren Ausführungen für Berechtigungen und Suchpfad können hier dann aber nicht angewendet werden.

=== Initialer Start ===
./steamcmd

Hier scrollt nun eine Menge Text durch mit Hinweisen über Downloads und Pakete. Am Ende muss ein fett gedruckter Prompt da stehen:
'''Steam>'''

Der Client kann an dieser Stelle mit <code>quit</code> verlassen werden.

=== Berechtigungen einrichten ===
groupadd steam
chgrp -R steam /opt/steamcmd
find /opt/steamcmd -type d -exec chmod 2775 {} \;
find /opt/steamcmd -type f -exec chmod 664 {} \;
find /opt/steamcmd -type f -a $ -name "*.sh" -o -name "*.so" -o -name "*.so.*" $ -exec chmod -v 755 {} \;
chmod a+x /opt/steamcmd/linux32/*
chmod 2770 /opt/steamcmd

=== Suchpfad ergänzen ===
vi /etc/profile

Natürlich kann man den Editor seiner Wahl verwenden. Letztendlich kommt es darauf an, in den Zeilen, in denen die <code>PATH</code>-Variable gesetzt wird, den Pfad zum Steam-Client zu ergänzen.

;Vorher:
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games"
fi

;Nachher:
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/opt/steamcmd"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/opt/steamcmd"
fi

Optional können nun bereits auf dem System angelegte Benutzer in die Gruppe ''steam'' aufgenommen werden.
useradd reiner steam
(Im Beispiel heißt der vorhandene Benutzer ''reiner''.)

Damit sind die vorbereitenden Arbeiten für den Client abgeschlossen.

== Server ==
Sinnvollerweise richtet man den Server so ein, dass er unter einem eigenen Benutzer läuft. Dazu fügen wir den Benutzer sdtd hinzu:
adduser --ingroup steam --disabled-password --gecos 'Seven Days To Die Dedicated Server Account' sdtd

=== Installation ===
Nun installieren wir den Server. Ganz wichtig ist, dass in ''/home'' genügend freier Platz zu Verfügung steht.
su - sdtd
steamcmd.sh

Ab hier ist nun nach jeder Eingabe der <code>'''Steam>'''</code>-Prompt sichtbar.
login anonymous
app_update 294420 validate

Der Download wird nun durchgeführt und dauert seine Zeit.

Folgende Fehler sind derzeit bekannt:
* <code>Error! App '294420' state is 0x202 after update job.</code>: Nicht genügend freier Platz in ''/home/sdtd/Steam''.
* <code>Error! App '294420' state is 0x426 after update job.</code>: Servertask läuft noch. Muss vorher beendet werden.

Nach dem Update kann der Client wiederum beendet werden:
quit

=== Konfiguration ===
Die Konfiguration findet sich in ''~/Steam/steamapps/common/"7 Days to Die Dedicated Server"/serverconfig.xml''.

Mit <code>telnet localhost 8081</code> kann der Server via Kommandozeile gesteuert werden (sofern er läuft).

Weiteres wird noch ergänzt.

=== Automatischer Start ===
Damit der Server nach dem automatischen Start ordnungsgemäß im Hintergrund weiterläuft, muss im Startscript ''startserver.sh'' eine Anpassung vorgenommen werden: Die eigentlichen Startzeilen müssen mit einer Leerstelle und Kaufmanns-und (&) abgeschlossen werden:
;Vorher:
./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS

;Nachher:
./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS &

Durch den nachfolgenden Cronjob wird der Server nach einem Reboot automatisch gestartet. Muss mit <code>crontab -e</code> als Benutzer ''sdtd'' eingefügt werden:
@reboot cd ~/Steam/steamapps/common/'7 Days to Die Dedicated Server' && ./startserver.sh -configfile=serverconfig.xml

Mit der o. G. Zeile als Benutzer ''sdtd'', ohne das ''@reboot'' vornedran kann der Server dann gestartet und die Shell alsdann geschlossen werden (logout).

==== Server beenden ====
Mit dem Konsolen-Kommando (telnet, s. O.) ''shutdown'' kann der Server ordnungsgemäß beendet werden. Ob das auch bei einem normalen ''kill''-Kommando im Rahmen eines Host-Reboots so ordentlich läuft, ist derzeit unklar.

== Debugging ==
Im Unterordner ''7DaysToDieServer_Data'' findet sich ein ''output_log'' mit Timestamp hintendran, da landen die Ausgaben vom Server drin.

== Firewall ==
Der Server öffnet folgende Ports:
* tcp/127.0.0.1:8081 (Management)
* tcp/26900
* udp/26900
* udp/26902

Die letzten drei müssen in einer ggfs. vorhandenen Firewall bzw. einem NAT-Router entsprechend geöffnet bzw. weitergeleitet werden.

== Weblinks ==
* [https://wiki.dawico.de/display/WIKI/7+Days+To+Die%3A+dedicated+Server+auf+Debian+installieren 7 Days To Die: dedicated Server auf Debian installieren] (fehlerhaft, aber als initialer Start für diesen Artikel gut geeignet)
* [https://7daystodie.gamepedia.com/Server Server-Dokumentation] im 7 Days to Die Wiki
* [https://unix.stackexchange.com/questions/463708/uninstall-a-steam-game-with-the-console Uninstall a Steam game with the console], Stack Exchange
* [https://steamcommunity.com/sharedfiles/filedetails/?l=german&id=360404397 Installing Linux dedicated server for 7 days to die] mit Tips zur Installation von experimentellen Releases.

[[Kategorie: Linux]]
[[Kategorie: Spiel]]

7 Days To Die Dedicated Server auf Debian Linux via Kommandozeile installieren

2024-05-12T23:54:58Z

PoC: /* Automatischer Start */ Wie heißt das Ding?

Die Installation eines '''7 Days To Die Dedicated Servers auf auf Debian Linux via Kommandozeile''' ist nicht ganz trivial. Das gilt vor allem für die Inbetriebnahme des Steam-Clients für die Kommandozeile.

Der Server benötigt rund 6,4 GiB Platz auf der Platte und rund 2 GiB RAM (ohne Spieler).

== Steam-Client ==
Als Grundvoraussetzung für alle Steam-Themen muss zuerst mal der Client installiert und grundkonfiguriert werden. Das passiert am Besten als ''root'', um den Client systemweit für alle Benutzer anbieten zu können.

=== Download und Auspacken ===
Im Zielverzeichnis müssen rund 285 MiB Platz vorhanden sein.
cd /tmp
wget <nowiki>http://media.steampowered.com/installer/steamcmd_linux.tar.gz</nowiki>
mkdir /opt/steamcmd
cd /opt/steamcmd
tar xzf /tmp/steamcmd_linux.tar.gz && rm -f /tmp/steamcmd_linux.tar.gz

Alternativ kann mit <code>apt-get install steamcmd</code> das zugehörige Debian-Paket installiert werden. Die weiteren Ausführungen für Berechtigungen und Suchpfad können hier dann aber nicht angewendet werden.

=== Initialer Start ===
./steamcmd

Hier scrollt nun eine Menge Text durch mit Hinweisen über Downloads und Pakete. Am Ende muss ein fett gedruckter Prompt da stehen:
'''Steam>'''

Der Client kann an dieser Stelle mit <code>quit</code> verlassen werden.

=== Berechtigungen einrichten ===
groupadd steam
chgrp -R steam /opt/steamcmd
find /opt/steamcmd -type d -exec chmod 2775 {} \;
find /opt/steamcmd -type f -exec chmod 664 {} \;
find /opt/steamcmd -type f -a $ -name "*.sh" -o -name "*.so" -o -name "*.so.*" $ -exec chmod -v 755 {} \;
chmod a+x /opt/steamcmd/linux32/*
chmod 2770 /opt/steamcmd

=== Suchpfad ergänzen ===
vi /etc/profile

Natürlich kann man den Editor seiner Wahl verwenden. Letztendlich kommt es darauf an, in den Zeilen, in denen die <code>PATH</code>-Variable gesetzt wird, den Pfad zum Steam-Client zu ergänzen.

;Vorher:
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games"
fi

;Nachher:
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/opt/steamcmd"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/opt/steamcmd"
fi

Optional können nun bereits auf dem System angelegte Benutzer in die Gruppe ''steam'' aufgenommen werden.
useradd reiner steam
(Im Beispiel heißt der vorhandene Benutzer ''reiner''.)

Damit sind die vorbereitenden Arbeiten für den Client abgeschlossen.

== Server ==
Sinnvollerweise richtet man den Server so ein, dass er unter einem eigenen Benutzer läuft. Dazu fügen wir den Benutzer sdtd hinzu:
adduser --ingroup steam --disabled-password --gecos 'Seven Days To Die Dedicated Server Account' sdtd

=== Installation ===
Nun installieren wir den Server. Ganz wichtig ist, dass in ''/home'' genügend freier Platz zu Verfügung steht. Ausgepackt bringt der Server derzeit 16 GiB an Daten mit!
su - sdtd
steamcmd.sh

Ab hier ist nun nach jeder Eingabe der <code>'''Steam>'''</code>-Prompt sichtbar.
login anonymous
app_update 294420 validate

Der Download wird nun durchgeführt und dauert seine Zeit.

Folgende Fehler sind derzeit bekannt:
* <code>Error! App '294420' state is 0x202 after update job.</code>: Nicht genügend freier Platz in ''/home/sdtd/Steam''.
* <code>Error! App '294420' state is 0x426 after update job.</code>: Servertask läuft noch. Muss vorher beendet werden.

Nach dem Update kann der Client wiederum beendet werden:
quit

=== Konfiguration ===
Die Konfiguration findet sich in ''~/Steam/steamapps/common/"7 Days to Die Dedicated Server"/serverconfig.xml''.

Mit <code>telnet localhost 8081</code> kann der Server via Kommandozeile gesteuert werden (sofern er läuft).

Weiteres wird noch ergänzt.

=== Automatischer Start ===
Damit der Server nach dem automatischen Start ordnungsgemäß im Hintergrund weiterläuft, muss im Startscript ''startserver.sh'' eine Anpassung vorgenommen werden: Die eigentlichen Startzeilen müssen mit einer Leerstelle und Kaufmanns-und (&) abgeschlossen werden:
;Vorher:
./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS

;Nachher:
./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS &

Durch den nachfolgenden Cronjob wird der Server nach einem Reboot automatisch gestartet. Muss mit <code>crontab -e</code> als Benutzer ''sdtd'' eingefügt werden:
@reboot cd ~/Steam/steamapps/common/'7 Days to Die Dedicated Server' && ./startserver.sh -configfile=serverconfig.xml

Mit der o. G. Zeile als Benutzer ''sdtd'', ohne das ''@reboot'' vornedran kann der Server dann gestartet und die Shell alsdann geschlossen werden (logout).

==== Server beenden ====
Mit dem Konsolen-Kommando (telnet, s. O.) ''shutdown'' kann der Server ordnungsgemäß beendet werden. Ob das auch bei einem normalen ''kill''-Kommando im Rahmen eines Host-Reboots so ordentlich läuft, ist derzeit unklar.

== Debugging ==
Im Unterordner ''7DaysToDieServer_Data'' findet sich ein ''output_log'' mit Timestamp hintendran, da landen die Ausgaben vom Server drin.

== Firewall ==
Der Server öffnet folgende Ports:
* tcp/127.0.0.1:8081 (Management)
* tcp/26900
* udp/26900
* udp/26902

Die letzten drei müssen in einer ggfs. vorhandenen Firewall bzw. einem NAT-Router entsprechend geöffnet bzw. weitergeleitet werden.

== Weblinks ==
* [https://wiki.dawico.de/display/WIKI/7+Days+To+Die%3A+dedicated+Server+auf+Debian+installieren 7 Days To Die: dedicated Server auf Debian installieren] (fehlerhaft, aber als initialer Start für diesen Artikel gut geeignet)
* [https://7daystodie.gamepedia.com/Server Server-Dokumentation] im 7 Days to Die Wiki
* [https://unix.stackexchange.com/questions/463708/uninstall-a-steam-game-with-the-console Uninstall a Steam game with the console], Stack Exchange
* [https://steamcommunity.com/sharedfiles/filedetails/?l=german&id=360404397 Installing Linux dedicated server for 7 days to die] mit Tips zur Installation von experimentellen Releases.

[[Kategorie: Linux]]
[[Kategorie: Spiel]]

7 Days To Die Dedicated Server auf Debian Linux via Kommandozeile installieren

2024-05-12T23:34:19Z

PoC: /* Installation */ Viel gröer

Die Installation eines '''7 Days To Die Dedicated Servers auf auf Debian Linux via Kommandozeile''' ist nicht ganz trivial. Das gilt vor allem für die Inbetriebnahme des Steam-Clients für die Kommandozeile.

Der Server benötigt rund 6,4 GiB Platz auf der Platte und rund 2 GiB RAM (ohne Spieler).

== Steam-Client ==
Als Grundvoraussetzung für alle Steam-Themen muss zuerst mal der Client installiert und grundkonfiguriert werden. Das passiert am Besten als ''root'', um den Client systemweit für alle Benutzer anbieten zu können.

=== Download und Auspacken ===
Im Zielverzeichnis müssen rund 285 MiB Platz vorhanden sein.
cd /tmp
wget <nowiki>http://media.steampowered.com/installer/steamcmd_linux.tar.gz</nowiki>
mkdir /opt/steamcmd
cd /opt/steamcmd
tar xzf /tmp/steamcmd_linux.tar.gz && rm -f /tmp/steamcmd_linux.tar.gz

Alternativ kann mit <code>apt-get install steamcmd</code> das zugehörige Debian-Paket installiert werden. Die weiteren Ausführungen für Berechtigungen und Suchpfad können hier dann aber nicht angewendet werden.

=== Initialer Start ===
./steamcmd

Hier scrollt nun eine Menge Text durch mit Hinweisen über Downloads und Pakete. Am Ende muss ein fett gedruckter Prompt da stehen:
'''Steam>'''

Der Client kann an dieser Stelle mit <code>quit</code> verlassen werden.

=== Berechtigungen einrichten ===
groupadd steam
chgrp -R steam /opt/steamcmd
find /opt/steamcmd -type d -exec chmod 2775 {} \;
find /opt/steamcmd -type f -exec chmod 664 {} \;
find /opt/steamcmd -type f -a $ -name "*.sh" -o -name "*.so" -o -name "*.so.*" $ -exec chmod -v 755 {} \;
chmod a+x /opt/steamcmd/linux32/*
chmod 2770 /opt/steamcmd

=== Suchpfad ergänzen ===
vi /etc/profile

Natürlich kann man den Editor seiner Wahl verwenden. Letztendlich kommt es darauf an, in den Zeilen, in denen die <code>PATH</code>-Variable gesetzt wird, den Pfad zum Steam-Client zu ergänzen.

;Vorher:
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games"
fi

;Nachher:
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/opt/steamcmd"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/opt/steamcmd"
fi

Optional können nun bereits auf dem System angelegte Benutzer in die Gruppe ''steam'' aufgenommen werden.
useradd reiner steam
(Im Beispiel heißt der vorhandene Benutzer ''reiner''.)

Damit sind die vorbereitenden Arbeiten für den Client abgeschlossen.

== Server ==
Sinnvollerweise richtet man den Server so ein, dass er unter einem eigenen Benutzer läuft. Dazu fügen wir den Benutzer sdtd hinzu:
adduser --ingroup steam --disabled-password --gecos 'Seven Days To Die Dedicated Server Account' sdtd

=== Installation ===
Nun installieren wir den Server. Ganz wichtig ist, dass in ''/home'' genügend freier Platz zu Verfügung steht. Ausgepackt bringt der Server derzeit 16 GiB an Daten mit!
su - sdtd
steamcmd.sh

Ab hier ist nun nach jeder Eingabe der <code>'''Steam>'''</code>-Prompt sichtbar.
login anonymous
app_update 294420 validate

Der Download wird nun durchgeführt und dauert seine Zeit.

Folgende Fehler sind derzeit bekannt:
* <code>Error! App '294420' state is 0x202 after update job.</code>: Nicht genügend freier Platz in ''/home/sdtd/Steam''.
* <code>Error! App '294420' state is 0x426 after update job.</code>: Servertask läuft noch. Muss vorher beendet werden.

Nach dem Update kann der Client wiederum beendet werden:
quit

=== Konfiguration ===
Die Konfiguration findet sich in ''~/Steam/steamapps/common/"7 Days to Die Dedicated Server"/serverconfig.xml''.

Mit <code>telnet localhost 8081</code> kann der Server via Kommandozeile gesteuert werden (sofern er läuft).

Weiteres wird noch ergänzt.

=== Automatischer Start ===
Damit der Server nach dem automatischen Start ordnungsgemäß im Hintergrund weiterläuft, muss im Startscript eine Anpassung vorgenommen werden: Die eigentlichen Startzeilen müssen mit einer Leerstelle und Kaufmanns-und (&) abgeschlossen werden:
;Vorher:
./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS

;Nachher:
./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS &

Durch den nachfolgenden Cronjob wird der Server nach einem Reboot automatisch gestartet. Muss mit <code>crontab -e</code> als Benutzer ''sdtd'' eingefügt werden:
@reboot cd ~/Steam/steamapps/common/'7 Days to Die Dedicated Server' && ./startserver.sh -configfile=serverconfig.xml

Mit der o. G. Zeile als Benutzer ''sdtd'', ohne das ''@reboot'' vornedran kann der Server dann gestartet und die Shell alsdann geschlossen werden (logout).

==== Server beenden ====
Mit dem Konsolen-Kommando (telnet, s. O.) ''shutdown'' kann der Server ordnungsgemäß beendet werden. Ob das auch bei einem normalen ''kill''-Kommando im Rahmen eines Host-Reboots so ordentlich läuft, ist derzeit unklar.

== Debugging ==
Im Unterordner ''7DaysToDieServer_Data'' findet sich ein ''output_log'' mit Timestamp hintendran, da landen die Ausgaben vom Server drin.

== Firewall ==
Der Server öffnet folgende Ports:
* tcp/127.0.0.1:8081 (Management)
* tcp/26900
* udp/26900
* udp/26902

Die letzten drei müssen in einer ggfs. vorhandenen Firewall bzw. einem NAT-Router entsprechend geöffnet bzw. weitergeleitet werden.

== Weblinks ==
* [https://wiki.dawico.de/display/WIKI/7+Days+To+Die%3A+dedicated+Server+auf+Debian+installieren 7 Days To Die: dedicated Server auf Debian installieren] (fehlerhaft, aber als initialer Start für diesen Artikel gut geeignet)
* [https://7daystodie.gamepedia.com/Server Server-Dokumentation] im 7 Days to Die Wiki
* [https://unix.stackexchange.com/questions/463708/uninstall-a-steam-game-with-the-console Uninstall a Steam game with the console], Stack Exchange
* [https://steamcommunity.com/sharedfiles/filedetails/?l=german&id=360404397 Installing Linux dedicated server for 7 days to die] mit Tips zur Installation von experimentellen Releases.

[[Kategorie: Linux]]
[[Kategorie: Spiel]]

7 Days To Die Dedicated Server auf Debian Linux via Kommandozeile installieren

2024-05-12T23:13:23Z

PoC: /* Download und Auspacken */ Genauer

Die Installation eines '''7 Days To Die Dedicated Servers auf auf Debian Linux via Kommandozeile''' ist nicht ganz trivial. Das gilt vor allem für die Inbetriebnahme des Steam-Clients für die Kommandozeile.

Der Server benötigt rund 6,4 GiB Platz auf der Platte und rund 2 GiB RAM (ohne Spieler).

== Steam-Client ==
Als Grundvoraussetzung für alle Steam-Themen muss zuerst mal der Client installiert und grundkonfiguriert werden. Das passiert am Besten als ''root'', um den Client systemweit für alle Benutzer anbieten zu können.

=== Download und Auspacken ===
Im Zielverzeichnis müssen rund 285 MiB Platz vorhanden sein.
cd /tmp
wget <nowiki>http://media.steampowered.com/installer/steamcmd_linux.tar.gz</nowiki>
mkdir /opt/steamcmd
cd /opt/steamcmd
tar xzf /tmp/steamcmd_linux.tar.gz && rm -f /tmp/steamcmd_linux.tar.gz

Alternativ kann mit <code>apt-get install steamcmd</code> das zugehörige Debian-Paket installiert werden. Die weiteren Ausführungen für Berechtigungen und Suchpfad können hier dann aber nicht angewendet werden.

=== Initialer Start ===
./steamcmd

Hier scrollt nun eine Menge Text durch mit Hinweisen über Downloads und Pakete. Am Ende muss ein fett gedruckter Prompt da stehen:
'''Steam>'''

Der Client kann an dieser Stelle mit <code>quit</code> verlassen werden.

=== Berechtigungen einrichten ===
groupadd steam
chgrp -R steam /opt/steamcmd
find /opt/steamcmd -type d -exec chmod 2775 {} \;
find /opt/steamcmd -type f -exec chmod 664 {} \;
find /opt/steamcmd -type f -a $ -name "*.sh" -o -name "*.so" -o -name "*.so.*" $ -exec chmod -v 755 {} \;
chmod a+x /opt/steamcmd/linux32/*
chmod 2770 /opt/steamcmd

=== Suchpfad ergänzen ===
vi /etc/profile

Natürlich kann man den Editor seiner Wahl verwenden. Letztendlich kommt es darauf an, in den Zeilen, in denen die <code>PATH</code>-Variable gesetzt wird, den Pfad zum Steam-Client zu ergänzen.

;Vorher:
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games"
fi

;Nachher:
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/opt/steamcmd"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/opt/steamcmd"
fi

Optional können nun bereits auf dem System angelegte Benutzer in die Gruppe ''steam'' aufgenommen werden.
useradd reiner steam
(Im Beispiel heißt der vorhandene Benutzer ''reiner''.)

Damit sind die vorbereitenden Arbeiten für den Client abgeschlossen.

== Server ==
Sinnvollerweise richtet man den Server so ein, dass er unter einem eigenen Benutzer läuft. Dazu fügen wir den Benutzer sdtd hinzu:
adduser --ingroup steam --disabled-password --gecos 'Seven Days To Die Dedicated Server Account' sdtd

=== Installation ===
Nun installieren wir den Server. Ganz wichtig ist, dass in ''/home'' genügend freier Platz zu Verfügung steht. Ausgepackt bringt der Server derzeit 6,4 GiB an Daten mit!
su - sdtd
steamcmd.sh

Ab hier ist nun nach jeder Eingabe der <code>'''Steam>'''</code>-Prompt sichtbar.
login anonymous
app_update 294420 validate

Der Download wird nun durchgeführt und dauert seine Zeit.

Folgende Fehler sind derzeit bekannt:
* <code>Error! App '294420' state is 0x202 after update job.</code>: Nicht genügend freier Platz in ''/home/sdtd/Steam''.
* <code>Error! App '294420' state is 0x426 after update job.</code>: Servertask läuft noch. Muss vorher beendet werden.

Nach dem Update kann der Client wiederum beendet werden:
quit

=== Konfiguration ===
Die Konfiguration findet sich in ''~/Steam/steamapps/common/"7 Days to Die Dedicated Server"/serverconfig.xml''.

Mit <code>telnet localhost 8081</code> kann der Server via Kommandozeile gesteuert werden (sofern er läuft).

Weiteres wird noch ergänzt.

=== Automatischer Start ===
Damit der Server nach dem automatischen Start ordnungsgemäß im Hintergrund weiterläuft, muss im Startscript eine Anpassung vorgenommen werden: Die eigentlichen Startzeilen müssen mit einer Leerstelle und Kaufmanns-und (&) abgeschlossen werden:
;Vorher:
./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS

;Nachher:
./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS &

Durch den nachfolgenden Cronjob wird der Server nach einem Reboot automatisch gestartet. Muss mit <code>crontab -e</code> als Benutzer ''sdtd'' eingefügt werden:
@reboot cd ~/Steam/steamapps/common/'7 Days to Die Dedicated Server' && ./startserver.sh -configfile=serverconfig.xml

Mit der o. G. Zeile als Benutzer ''sdtd'', ohne das ''@reboot'' vornedran kann der Server dann gestartet und die Shell alsdann geschlossen werden (logout).

==== Server beenden ====
Mit dem Konsolen-Kommando (telnet, s. O.) ''shutdown'' kann der Server ordnungsgemäß beendet werden. Ob das auch bei einem normalen ''kill''-Kommando im Rahmen eines Host-Reboots so ordentlich läuft, ist derzeit unklar.

== Debugging ==
Im Unterordner ''7DaysToDieServer_Data'' findet sich ein ''output_log'' mit Timestamp hintendran, da landen die Ausgaben vom Server drin.

== Firewall ==
Der Server öffnet folgende Ports:
* tcp/127.0.0.1:8081 (Management)
* tcp/26900
* udp/26900
* udp/26902

Die letzten drei müssen in einer ggfs. vorhandenen Firewall bzw. einem NAT-Router entsprechend geöffnet bzw. weitergeleitet werden.

== Weblinks ==
* [https://wiki.dawico.de/display/WIKI/7+Days+To+Die%3A+dedicated+Server+auf+Debian+installieren 7 Days To Die: dedicated Server auf Debian installieren] (fehlerhaft, aber als initialer Start für diesen Artikel gut geeignet)
* [https://7daystodie.gamepedia.com/Server Server-Dokumentation] im 7 Days to Die Wiki
* [https://unix.stackexchange.com/questions/463708/uninstall-a-steam-game-with-the-console Uninstall a Steam game with the console], Stack Exchange
* [https://steamcommunity.com/sharedfiles/filedetails/?l=german&id=360404397 Installing Linux dedicated server for 7 days to die] mit Tips zur Installation von experimentellen Releases.

[[Kategorie: Linux]]
[[Kategorie: Spiel]]

7 Days To Die Dedicated Server auf Debian Linux via Kommandozeile installieren

2024-05-12T23:07:31Z

PoC: Geht auch als Package

Die Installation eines '''7 Days To Die Dedicated Servers auf auf Debian Linux via Kommandozeile''' ist nicht ganz trivial. Das gilt vor allem für die Inbetriebnahme des Steam-Clients für die Kommandozeile.

Der Server benötigt rund 6,4 GiB Platz auf der Platte und rund 2 GiB RAM (ohne Spieler).

== Steam-Client ==
Als Grundvoraussetzung für alle Steam-Themen muss zuerst mal der Client installiert und grundkonfiguriert werden. Das passiert am Besten als ''root'', um den Client systemweit für alle Benutzer anbieten zu können.

=== Download und Auspacken ===
Im Zielverzeichnis müssen rund 250 MiB Platz vorhanden sein.
cd /tmp
wget <nowiki>http://media.steampowered.com/installer/steamcmd_linux.tar.gz</nowiki>
mkdir /opt/steamcmd
cd /opt/steamcmd
tar xzf /tmp/steamcmd_linux.tar.gz && rm -f /tmp/steamcmd_linux.tar.gz

Alternativ kann mit <code>apt-get install steamcmd</code> das zugehörige Debian-Paket installiert werden.

=== Initialer Start ===
./steamcmd

Hier scrollt nun eine Menge Text durch mit Hinweisen über Downloads und Pakete. Am Ende muss ein fett gedruckter Prompt da stehen:
'''Steam>'''

Der Client kann an dieser Stelle mit <code>quit</code> verlassen werden.

=== Berechtigungen einrichten ===
groupadd steam
chgrp -R steam /opt/steamcmd
find /opt/steamcmd -type d -exec chmod 2775 {} \;
find /opt/steamcmd -type f -exec chmod 664 {} \;
find /opt/steamcmd -type f -a $ -name "*.sh" -o -name "*.so" -o -name "*.so.*" $ -exec chmod -v 755 {} \;
chmod a+x /opt/steamcmd/linux32/*
chmod 2770 /opt/steamcmd

=== Suchpfad ergänzen ===
vi /etc/profile

Natürlich kann man den Editor seiner Wahl verwenden. Letztendlich kommt es darauf an, in den Zeilen, in denen die <code>PATH</code>-Variable gesetzt wird, den Pfad zum Steam-Client zu ergänzen.

;Vorher:
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games"
fi

;Nachher:
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/opt/steamcmd"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/opt/steamcmd"
fi

Optional können nun bereits auf dem System angelegte Benutzer in die Gruppe ''steam'' aufgenommen werden.
useradd reiner steam
(Im Beispiel heißt der vorhandene Benutzer ''reiner''.)

Damit sind die vorbereitenden Arbeiten für den Client abgeschlossen.

== Server ==
Sinnvollerweise richtet man den Server so ein, dass er unter einem eigenen Benutzer läuft. Dazu fügen wir den Benutzer sdtd hinzu:
adduser --ingroup steam --disabled-password --gecos 'Seven Days To Die Dedicated Server Account' sdtd

=== Installation ===
Nun installieren wir den Server. Ganz wichtig ist, dass in ''/home'' genügend freier Platz zu Verfügung steht. Ausgepackt bringt der Server derzeit 6,4 GiB an Daten mit!
su - sdtd
steamcmd.sh

Ab hier ist nun nach jeder Eingabe der <code>'''Steam>'''</code>-Prompt sichtbar.
login anonymous
app_update 294420 validate

Der Download wird nun durchgeführt und dauert seine Zeit.

Folgende Fehler sind derzeit bekannt:
* <code>Error! App '294420' state is 0x202 after update job.</code>: Nicht genügend freier Platz in ''/home/sdtd/Steam''.
* <code>Error! App '294420' state is 0x426 after update job.</code>: Servertask läuft noch. Muss vorher beendet werden.

Nach dem Update kann der Client wiederum beendet werden:
quit

=== Konfiguration ===
Die Konfiguration findet sich in ''~/Steam/steamapps/common/"7 Days to Die Dedicated Server"/serverconfig.xml''.

Mit <code>telnet localhost 8081</code> kann der Server via Kommandozeile gesteuert werden (sofern er läuft).

Weiteres wird noch ergänzt.

=== Automatischer Start ===
Damit der Server nach dem automatischen Start ordnungsgemäß im Hintergrund weiterläuft, muss im Startscript eine Anpassung vorgenommen werden: Die eigentlichen Startzeilen müssen mit einer Leerstelle und Kaufmanns-und (&) abgeschlossen werden:
;Vorher:
./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS

;Nachher:
./7DaysToDieServer.x86_64 -logfile 7DaysToDieServer_Data/output_log__`date +%Y-%m-%d__%H-%M-%S`.txt -quit -batchmode -nographics -dedicated $PARAMS &

Durch den nachfolgenden Cronjob wird der Server nach einem Reboot automatisch gestartet. Muss mit <code>crontab -e</code> als Benutzer ''sdtd'' eingefügt werden:
@reboot cd ~/Steam/steamapps/common/'7 Days to Die Dedicated Server' && ./startserver.sh -configfile=serverconfig.xml

Mit der o. G. Zeile als Benutzer ''sdtd'', ohne das ''@reboot'' vornedran kann der Server dann gestartet und die Shell alsdann geschlossen werden (logout).

==== Server beenden ====
Mit dem Konsolen-Kommando (telnet, s. O.) ''shutdown'' kann der Server ordnungsgemäß beendet werden. Ob das auch bei einem normalen ''kill''-Kommando im Rahmen eines Host-Reboots so ordentlich läuft, ist derzeit unklar.

== Debugging ==
Im Unterordner ''7DaysToDieServer_Data'' findet sich ein ''output_log'' mit Timestamp hintendran, da landen die Ausgaben vom Server drin.

== Firewall ==
Der Server öffnet folgende Ports:
* tcp/127.0.0.1:8081 (Management)
* tcp/26900
* udp/26900
* udp/26902

Die letzten drei müssen in einer ggfs. vorhandenen Firewall bzw. einem NAT-Router entsprechend geöffnet bzw. weitergeleitet werden.

== Weblinks ==
* [https://wiki.dawico.de/display/WIKI/7+Days+To+Die%3A+dedicated+Server+auf+Debian+installieren 7 Days To Die: dedicated Server auf Debian installieren] (fehlerhaft, aber als initialer Start für diesen Artikel gut geeignet)
* [https://7daystodie.gamepedia.com/Server Server-Dokumentation] im 7 Days to Die Wiki
* [https://unix.stackexchange.com/questions/463708/uninstall-a-steam-game-with-the-console Uninstall a Steam game with the console], Stack Exchange
* [https://steamcommunity.com/sharedfiles/filedetails/?l=german&id=360404397 Installing Linux dedicated server for 7 days to die] mit Tips zur Installation von experimentellen Releases.

[[Kategorie: Linux]]
[[Kategorie: Spiel]]

Debian-Live Netzbootsystem

2024-05-12T13:33:01Z

PoC: /* TFTP-Server */ Hinweis verschoben.

Die Möglichkeit, hinreichend aktuelle Maschinen (allgemein, also VMs oder auch Blech) über das LAN zu booten ist eine feine Sache. Bare Metal Restore, oder auch die Offline-Korrektur von Fehlern wie z. B. zu kleinen Partitionen, etc. wird damit zum Kinderspiel.

Das '''Debian-Live'''-Projekt hat für Wiederherstellungszwecke eine Live-Boot CD-Serie bereitgestellt. Allerdings haben diese Images ein paar (teils subjektive) Nachteile:
* Gewohnte Konfigurationstools wurden durch modernere Varianten mit eigener Syntax abgelöst; ein Paradebeispiel ist das Fehlen von <code>ifconfig</code>.
* Hardware welche proprietäre Firmware-Binärdateien benötigt ist — vor allem wenn es um Netzwerkkarten geht — außen vor; ein Booten vom Netz geht spätestens nach dem Starten des Kernels schief.
* Viele weitere Pakete mit fast immer benötigten Tools fehlen und müssen immer und immer wieder per Hand nachinstalliert werden.

Der Artikel beschreibt die notwendigen Schritte, dieses Netzbootsystem auf einem existierenden Debian Linux 12 (Bookworm) aufzusetzen. Ob die zu startende Maschine ein älteres BIOS-basiertes System ist oder ein neueres EFI-System, ist egal: Beides wird dynamisch anhand von DHCP-Optionen passend konfiguriert. Dabei kann zum Bootzeitpunkt ausgewählt werden, ob ein 32- oder ein 64-Bit-System gestartet werden soll.

Es ist selbstverständlich möglich, weitere via PXE zu startende Betriebssysteme einzubinden. Wichtig ist zu beachten, dass die via TFTP bereitgestellten Dateien in den entsprechenden Unterverzeichnissen für die verschiedenen Architekturen zu hinterlegen sind (bios, efi32, efi64).

<blockquote>'''Hinweis''': Das von mir benutzte System ist traditionell mit ''SysV-init'' ausgerüstet. ''Systemd'' wird nicht benutzt. Die hier aufgeführten Schritte sind ansonsten so generisch wie möglich gehalten.</blockquote>

== Benötigte Komponenten ==
* ''DHCP-Server'' für die Zuweisung grundlegender Netzwerkparameter,
* ''TFTP-Server'' für den initialen Download von Bootloader, Menü und anschließend Kernel und Initrd,
* ''NFS-Server'' für den Zugriff auf das komprimierte Root-Dateisystem,
* ''Scripte'' zur Erstellung des übers Netz geladenen Root-Dateisystems.

Installation:
apt-get install openbsd-inetd isc-dhcp-server tftp-hpa tftpd-hpa nfs-kernel-server pxelinux syslinux-common syslinux-efi debootstrap squashfs-tools

== DHCP-Konfiguration ==
<blockquote>'''Hinweis''': Im lokalen Netzwerksegment soll nur '''ein''' DHCP-Server aktiv sein. Sind es mehrere, ist es mehr oder weniger Zufall, welches Antwortpaket der anfragende Client zuerst bearbeitet. Sollte also schon ein DHCP-Server existieren, muss die gezeigte Konfiguration in die bestehende Konfiguration eingebaut werden. Durch die Benutzung von DHCP-Klassen ("class") ist dies im Regelfall aber sehr einfach möglich.</blockquote>

Der erste Start des noch nicht unkonfigurierten DHCP-Servers geht erfahrungsgemäß schief, dies kann ignoriert werden.

Weil hier nur IPv4 berücksichtigt wird, muss in ''/etc/default/isc-dhcp-server die Zeile ''INTERFACESv6'' gelöscht werden. Ebenso muss in ''INTERFACESv4'' das für DHCP zu verwendenden Netzwerkinterface eingetragen werden. Beispiel:
INTERFACESv4="eth0"

Dies ist ein '''Beispiel''' für eine DHCP-Konfiguration! Insbesondere der ''group''-Abschnitt muss auf die lokalen Gegebenheiten angepasst werden!
<syntaxhighlight lang="shell">
authoritative;
ddns-updates off;
default-lease-time 3600;
log-facility daemon;
max-lease-time 86400;
min-lease-time 300;
min-secs 0;

option architecture-type code 93 = unsigned integer 16; # RFC4578

# Route different kinds of requesting clients to distinct PXE bootloaders.
class "pxeclients" {
match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";

if option architecture-type = 00:00 {
filename "/var/tftpboot/bios/lpxelinux.0";
} elsif option architecture-type = 00:06 {
filename "/var/tftpboot/efi32/syslinux.efi";
} elsif option architecture-type = 00:07 {
filename "/var/tftpboot/efi64/syslinux.efi";
} elsif option architecture-type = 00:09 {
filename "/var/tftpboot/efi64/syslinux.efi";
}

# This is the TFTP server's IP address.
next-server 192.168.111.10;
}

# Ethernet
group {
option broadcast-address 192.168.111.0;
option domain-name "pocnet.net";
option domain-name-servers 192.168.111.10;
option ntp-servers 192.168.111.10;
option routers 192.168.111.1;
option subnet-mask 255.255.255.0;

subnet 192.168.111.0 netmask 255.255.255.0 {
range 192.168.111.120 192.168.111.126;
}
}
</syntaxhighlight>

Nun kann der DHCP-Server gestartet werden:
service isc-dhcp-server start

== TFTP-Server ==
Die Konfiguration des Servers findet sich in ''/etc/default/tftpd-hpa''. Dort müssen folgende Änderungen durchgeführt werden:
* Ändern des Pfades ''/srv/tftp'' nach ''/var/tftpboot'',<ref>Ist kein Muss, aber in dieser Anleitung wird dieser Pfad vorausgesetzt.</ref>
* Ändern der ''TFTP_OPTIONS'':<ref>Dies ist notwendig, damit die später angelegten Symlinks auch aufgelöst werden.</ref>
** Löschen von <code>--secure</code>,
** Hinzufügen von <code>--permissive -v</code>.

Nun kann der alte Pfad gelöscht werden und der neue angelegt:
rmdir /srv/tftp
mkdir /var/tftpboot

Als letztes sollte der TFTP-Server neu gestartet werden:
service tftpd-hpa restart

=== Inhalte für <code>/var/tftpboot</code> ===
Zuerst werden ein paar grundlegende Verzeichnisse für die benötigten Dateien angelegt:
cd /var/tftpboot
mkdir -p deb-live/amd64 deb-live/i686 bios efi32 efi64 pxelinux.cfg

Für die einzelnen Architekturen werden nun die benötigten Bootdateien über Symlinks bereit gestellt. Symlinks brauchen weniger Speicher und wenn das Original (wegen Aktualisierungen) ausgetauscht wird, braucht man nicht mehr manuell nachbessern.

<syntaxhighlight lang="shell">
# BIOS-Loaders
cd bios
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/bios/ldlinux.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/pxechn.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/vesamenu.c32 .
ln -s ../../../usr/lib/PXELINUX/lpxelinux.0 .

# EFI32-Loaders
cd ../efi32
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/efi32/ldlinux.e32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/vesamenu.c32 .
ln -s ../../../usr/lib/SYSLINUX.EFI/efi32/syslinux.efi .

# EFI64-Loaders
cd ../efi64
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/efi64/ldlinux.e64 .
ln -s ../../../usr/lib/syslinux/modules/efi64/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/vesamenu.c32 .
ln -s ../../../usr/lib/SYSLINUX.EFI/efi64/syslinux.efi .
</syntaxhighlight>

Um die Pflege des PXE-Bootmenüs zu vereinfachen, wird eine "globale" Konfiguration in ''/var/tftpboot/pxelinux.cfg'' (der Standardname, mit dem die PXE-Loader nach der Konfiguration suchen) für alle Architekturen via Symlinks zugänglich gemacht.

Die eigentliche Konfiguration für das Bootmenü findet sich in der Datei ''/var/tftpboot/pxelinux.cfg/default'':
menu title Boot menu
menu tabmsg Press ENTER to boot or TAB to edit a menu entry
prompt 0
timeout 600

label deblive64
menu label Debian Live ^amd64
kernel deb-live/amd64/vmlinuz
append initrd=deb-live/amd64/initrd.img net.ifnames=0 biosdevname=0 ip=:::::eth0:dhcp boot=live netboot=nfs root=/dev/nfs nfsroot=192.168.1.10:/var/nfsboot/deb-live/amd64 live-media-path=/ consoleblank=0 nfsrootdebug

label deblive32
menu label Debian Live ^i686
kernel deb-live/i686/vmlinuz
append initrd=deb-live/i686/initrd.img net.ifnames=0 biosdevname=0 ip=:::::eth0:dhcp boot=live netboot=nfs root=/dev/nfs nfsroot=192.168.1.10:/var/nfsboot/deb-live/amd64 live-media-path=/ consoleblank=0 nfsrootdebug

label bootlocal
menu label Boot ^local disk
menu default
localboot 0

ui menu.c32

* <code>net.ifnames=0 biosdevname=0</code> stellt die ursprüngliche, aufsteigende Nummerierung vom Kernel wieder her, damit die Netzwerkschnittstelle überall wieder ''eth0''heißt und diese wiederum in der <code>ip=</code>-Konfigurationszeile statisch referenziert werden kann.<ref>Früher hat die Autokonfiguration bei mehreren vorhandenen Netzwerkschnittstellen nicht zuverlässig funktioniert, deswegen der gezeigte Workaround.</ref>
* Das Zirkumflex (<code>^</code>) dient als Hervorhebung für einen Buchstaben im Menü. Dieser Buchstabe auf der Tastatur eingegeben aktiviert diesen Menüeintrag.

== NFS-Server ==
In der Datei ''/etc/exports'' wird definiert, welche Hosts auf welche Verzeichnisse Zugriff haben:
/var/nfsboot 192.168.1.0/24(ro,no_root_squash,insecure,no_subtree_check)

Nun müssen die Verzeichnisse für das Rootdateisystem noch angelegt werden:
mkdir -p /var/nfsboot/deb-live/amd64 /var/nfsboot/deb-live/i686

Damit die Änderungen ziehen, einmal den (mangels gültiger Einträge in ''exports'' sowieso nicht gestarteten) NFS-Server starten:
service nfs-kernel-server start

== Root-Dateisystem ==
Dies wird über eine "frische" Installation von Debian von Grund auf neu erzeugt:
* Debootstrap,
* Konfigurationsanpassungen,
* Squashfs-Build.

Das folgende Script kann mit den Parametern ''amd64'' oder ''i686'' aufgerufen werden und erzeugt jeweils ein Squashfs in den zuvor angelegten Verzeichnissen in ''/var/nfsboot''.

<syntaxhighlight lang="shell">
#!/bin/bash

# Must run as root.
if ! id |grep -Fq 'uid=0(root) gid=0(root) groups=0(root)'; then
echo "Must run as root."
exit 1
fi

# Must supply what to build.
if [ -z "${1}" ]; then
echo "Give arch as argument: amd64 or i686."
exit 0
fi

# Check what to build.
if [ "${1}" == "amd64" ]; then
DST_ARCH="amd64"
elif [ "${1}" == "i686" ] || [ "${1}" == "i386" ]; then
DST_ARCH="i686"
else
echo "Give arch as argument: amd64 or i686."
exit 0
fi

# Automatically clean up when we terminate.
trap '{ umount ${TMPMNT} && rmdir ${TMPMNT}; rm -f ${TMPIMG}; }' EXIT

# Terminate on error.
set -e

# Temporary image file and mount point to work within.
TMPIMG=$(mktemp --tmpdir=/var/tmp live-image.XXXXXXXXXX)
TMPMNT=$(mktemp -d --tmpdir=/var/tmp live-root.XXXXXXXXXX)

# Prepare image file and mount.
fallocate -v -l 4GiB "${TMPIMG}"
mke2fs -t ext4 -E lazy_itable_init=0 -O ^has_journal -i 16384 -L live-build -F "${TMPIMG}"
tune2fs -r0 -c0 -i12m -o '^acl,nobarrier' -e remount-ro -f "${TMPIMG}"
mount -o loop "${TMPIMG}" "${TMPMNT}"

# Install system.
if [ "${DST_ARCH}" == "amd64" ]; then
ARCH_ARG="--arch=amd64"
PKGLIST="console-setup, \
dosfstools, \
dump, \
firmware-amd-graphics, \
firmware-bnx2, \
firmware-bnx2x, \
firmware-linux-free, \
firmware-misc-nonfree, \
gdisk, \
ifupdown, \
isc-dhcp-client, \
kbd, \
keyboard-configuration, \
linux-image-amd64, \
live-boot, \
locales, \
lsscsi, \
lvm2, \
mdadm, \
mt-st, \
net-tools, \
nfs-common, \
openssh-client, \
openssh-server, \
orphan-sysvinit-scripts, \
pciutils, \
pv, \
sg3-utils, \
sysvinit-core"
elif [ "${DST_ARCH}" == "i686" ]; then
ARCH_ARG="--arch=i386"
PKGLIST="console-setup, \
dump, \
firmware-linux-free, \
ifupdown, \
isc-dhcp-client, \
kbd, \
keyboard-configuration, \
linux-image-686-pae, \
live-boot, \
locales, \
lsscsi, \
lvm2, \
mdadm, \
mt-st, \
net-tools, \
nfs-common, \
openssh-client, \
openssh-server, \
orphan-sysvinit-scripts, \
pciutils, \
pv, \
sg3-utils, \
sysvinit-core"
fi

# Parameter strings for debootstrap must not include blanks.
PKGLIST_CLEAN="$(echo "${PKGLIST}" |tr -d ' ')"
debootstrap "${ARCH_ARG}" --components=main,non-free,non-free-firmware,contrib \
--include "${PKGLIST_CLEAN}" \
--exclude nano,systemd-sysv,tasksel,tasksel-data \
stable "${TMPMNT}" https://debian.inf.tu-dresden.de/debian/

# Prepare system.
echo "debian-live" > "${TMPMNT}"/etc/hostname
cat > "${TMPMNT}"/etc/default/keyboard <<-EOF
# Check /usr/share/doc/keyboard-configuration/README.Debian for
# documentation on what to do after having modified this file.

# The following variables describe your keyboard and can have the same
# values as the XkbModel, XkbLayout, XkbVariant and XkbOptions options
# in /etc/X11/xorg.conf.

XKBMODEL="pc105"
XKBLAYOUT="de"
XKBVARIANT=""
XKBOPTIONS=""

# If you don't want to use the XKB layout on the console, you can
# specify an alternative keymap. Make sure it will be accessible
# before /usr is mounted.
# KMAP=/etc/console-setup/defkeymap.kmap.gz
BACKSPACE="guess"
EOF

# Clean apt lists to save space. They might be outdated anyway and need to be retransferred.
rm -f "${TMPMNT}"/var/lib/apt/lists/* 2>/dev/null || true

# Set default locale.
echo "LANG=en_US.UTF-8" > "${TMPMNT}"/etc/environment

# Add default password entry.
sed '/^root:/ d' "${TMPMNT}"/etc/shadow > "${TMPMNT}"/etc/shadow~
echo 'root::17852:0:99999:7:::' > "${TMPMNT}"/etc/shadow
cat "${TMPMNT}"/etc/shadow~ >> "${TMPMNT}"/etc/shadow

# Help with ssh-remote-logins.
echo "PermitRootLogin yes" >> "${TMPMNT}"/etc/ssh/sshd_config
echo "PermitEmptyPasswords yes" >> "${TMPMNT}"/etc/ssh/sshd_config

# Switch initrd to gzip.
sed -Ei 's/^COMPRESS=zstd$/COMPRESS=gzip/' "${TMPMNT}"/etc/initramfs-tools/initramfs.conf

# Prepare system to rebuild initramfs
mount -o bind /dev "${TMPMNT}"/dev
mount -o bind /dev/pts "${TMPMNT}"/dev/pts
mount -t proc none "${TMPMNT}"/proc
mount -t sysfs none "${TMPMNT}"/sys
echo "Please run these commands:"
# FIXME: How to automate this manual process?
echo ' echo "locales locales/default_environment_locale select en_US.UTF-8" |debconf-set-selections'
echo ' echo "locales locales/locales_to_be_generated multiselect en_US.UTF-8 UTF-8" |debconf-set-selections'
echo " dpkg-reconfigure locales"
echo " update-initramfs -u"
echo "then exit chroot."
chroot "${TMPMNT}"

# Script resumes after chroot exit.
umount "${TMPMNT}"/dev/pts "${TMPMNT}"/dev "${TMPMNT}"/proc "${TMPMNT}"/sys

# Copy Kernel and initramfs for TFTP
cp -v "${TMPMNT}"/vmlinuz "${TMPMNT}"/initrd.img /var/tftpboot/deb-live/"${DST_ARCH}"

# Compress into a file for NFS serving
mksquashfs "${TMPMNT}" /var/nfsboot/deb-live/"${DST_ARCH}"/filesystem.squashfs -noappend

# vim: tabstop=4 shiftwidth=4 autoindent expandtab
</syntaxhighlight>

* Die Paketliste in ''$PKGLIST'' ist darauf zugeschnitten, die für eine schnelle Wiederherstellung notwendigen Komponenten zu beinhalten.

== Test ==
Wenn nichts falsch gemacht wurde, so bezieht der Client nun beim Netzboot eine IP-Adresse vom DHCP-Server und lädt die PXE-Dateien, um im Anschluss ein Menü anzuzeigen, was denn nun gestartet werden soll. Nach der Auswahl eines Punktes werden Kernel und Initrd per TFTP übermittelt und der Kernel gestartet. Per erneuter DHCP-Anfrage erhält der Kernel gültige Netzparameter und mountet nun das per NFS zugängliche Squashfs als ''root''. Ab dann ist das Debian-Live-System aktiv.

In ''/var/log/daemon.log'' finden sich Meldungen vom TFTP-Server, was hilfreich bei der Fehlersuche sein kann.

== Weblinks ==
* [https://kb.isc.org/docs/aa-00333 Where to find ISC DHCP documentation?], ISC.org
* [http://grml.org/online-docs/live-initramfs.en.7.html Doku zur live-initramfs] (Manpage im HTML-Format, englisch.)

== Fußnoten ==
<references />

[[Kategorie:Linux]]

Debian-Live Netzbootsystem

2024-05-12T13:32:32Z

PoC: /* TFTP-Server */ Hinweis

Die Möglichkeit, hinreichend aktuelle Maschinen (allgemein, also VMs oder auch Blech) über das LAN zu booten ist eine feine Sache. Bare Metal Restore, oder auch die Offline-Korrektur von Fehlern wie z. B. zu kleinen Partitionen, etc. wird damit zum Kinderspiel.

Das '''Debian-Live'''-Projekt hat für Wiederherstellungszwecke eine Live-Boot CD-Serie bereitgestellt. Allerdings haben diese Images ein paar (teils subjektive) Nachteile:
* Gewohnte Konfigurationstools wurden durch modernere Varianten mit eigener Syntax abgelöst; ein Paradebeispiel ist das Fehlen von <code>ifconfig</code>.
* Hardware welche proprietäre Firmware-Binärdateien benötigt ist — vor allem wenn es um Netzwerkkarten geht — außen vor; ein Booten vom Netz geht spätestens nach dem Starten des Kernels schief.
* Viele weitere Pakete mit fast immer benötigten Tools fehlen und müssen immer und immer wieder per Hand nachinstalliert werden.

Der Artikel beschreibt die notwendigen Schritte, dieses Netzbootsystem auf einem existierenden Debian Linux 12 (Bookworm) aufzusetzen. Ob die zu startende Maschine ein älteres BIOS-basiertes System ist oder ein neueres EFI-System, ist egal: Beides wird dynamisch anhand von DHCP-Optionen passend konfiguriert. Dabei kann zum Bootzeitpunkt ausgewählt werden, ob ein 32- oder ein 64-Bit-System gestartet werden soll.

Es ist selbstverständlich möglich, weitere via PXE zu startende Betriebssysteme einzubinden. Wichtig ist zu beachten, dass die via TFTP bereitgestellten Dateien in den entsprechenden Unterverzeichnissen für die verschiedenen Architekturen zu hinterlegen sind (bios, efi32, efi64).

<blockquote>'''Hinweis''': Das von mir benutzte System ist traditionell mit ''SysV-init'' ausgerüstet. ''Systemd'' wird nicht benutzt. Die hier aufgeführten Schritte sind ansonsten so generisch wie möglich gehalten.</blockquote>

== Benötigte Komponenten ==
* ''DHCP-Server'' für die Zuweisung grundlegender Netzwerkparameter,
* ''TFTP-Server'' für den initialen Download von Bootloader, Menü und anschließend Kernel und Initrd,
* ''NFS-Server'' für den Zugriff auf das komprimierte Root-Dateisystem,
* ''Scripte'' zur Erstellung des übers Netz geladenen Root-Dateisystems.

Installation:
apt-get install openbsd-inetd isc-dhcp-server tftp-hpa tftpd-hpa nfs-kernel-server pxelinux syslinux-common syslinux-efi debootstrap squashfs-tools

== DHCP-Konfiguration ==
<blockquote>'''Hinweis''': Im lokalen Netzwerksegment soll nur '''ein''' DHCP-Server aktiv sein. Sind es mehrere, ist es mehr oder weniger Zufall, welches Antwortpaket der anfragende Client zuerst bearbeitet. Sollte also schon ein DHCP-Server existieren, muss die gezeigte Konfiguration in die bestehende Konfiguration eingebaut werden. Durch die Benutzung von DHCP-Klassen ("class") ist dies im Regelfall aber sehr einfach möglich.</blockquote>

Der erste Start des noch nicht unkonfigurierten DHCP-Servers geht erfahrungsgemäß schief, dies kann ignoriert werden.

Weil hier nur IPv4 berücksichtigt wird, muss in ''/etc/default/isc-dhcp-server die Zeile ''INTERFACESv6'' gelöscht werden. Ebenso muss in ''INTERFACESv4'' das für DHCP zu verwendenden Netzwerkinterface eingetragen werden. Beispiel:
INTERFACESv4="eth0"

Dies ist ein '''Beispiel''' für eine DHCP-Konfiguration! Insbesondere der ''group''-Abschnitt muss auf die lokalen Gegebenheiten angepasst werden!
<syntaxhighlight lang="shell">
authoritative;
ddns-updates off;
default-lease-time 3600;
log-facility daemon;
max-lease-time 86400;
min-lease-time 300;
min-secs 0;

option architecture-type code 93 = unsigned integer 16; # RFC4578

# Route different kinds of requesting clients to distinct PXE bootloaders.
class "pxeclients" {
match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";

if option architecture-type = 00:00 {
filename "/var/tftpboot/bios/lpxelinux.0";
} elsif option architecture-type = 00:06 {
filename "/var/tftpboot/efi32/syslinux.efi";
} elsif option architecture-type = 00:07 {
filename "/var/tftpboot/efi64/syslinux.efi";
} elsif option architecture-type = 00:09 {
filename "/var/tftpboot/efi64/syslinux.efi";
}

# This is the TFTP server's IP address.
next-server 192.168.111.10;
}

# Ethernet
group {
option broadcast-address 192.168.111.0;
option domain-name "pocnet.net";
option domain-name-servers 192.168.111.10;
option ntp-servers 192.168.111.10;
option routers 192.168.111.1;
option subnet-mask 255.255.255.0;

subnet 192.168.111.0 netmask 255.255.255.0 {
range 192.168.111.120 192.168.111.126;
}
}
</syntaxhighlight>

Nun kann der DHCP-Server gestartet werden:
service isc-dhcp-server start

== TFTP-Server ==
Die Konfiguration des Servers findet sich in ''/etc/default/tftpd-hpa''. Dort müssen folgende Änderungen durchgeführt werden:
* Ändern des Pfades ''/srv/tftp'' nach ''/var/tftpboot'',<ref>Ist kein Muss, aber in dieser Anleitung wird dieser Pfad vorausgesetzt.</ref>
* Ändern der ''TFTP_OPTIONS'':
** Löschen von <code>--secure</code>,
** Hinzufügen von <code>--permissive -v</code>.<ref>Dies ist notwendig, damit die später angelegten Symlinks auch aufgelöst werden.</ref>

Nun kann der alte Pfad gelöscht werden und der neue angelegt:
rmdir /srv/tftp
mkdir /var/tftpboot

Als letztes sollte der TFTP-Server neu gestartet werden:
service tftpd-hpa restart

=== Inhalte für <code>/var/tftpboot</code> ===
Zuerst werden ein paar grundlegende Verzeichnisse für die benötigten Dateien angelegt:
cd /var/tftpboot
mkdir -p deb-live/amd64 deb-live/i686 bios efi32 efi64 pxelinux.cfg

Für die einzelnen Architekturen werden nun die benötigten Bootdateien über Symlinks bereit gestellt. Symlinks brauchen weniger Speicher und wenn das Original (wegen Aktualisierungen) ausgetauscht wird, braucht man nicht mehr manuell nachbessern.

<syntaxhighlight lang="shell">
# BIOS-Loaders
cd bios
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/bios/ldlinux.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/pxechn.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/vesamenu.c32 .
ln -s ../../../usr/lib/PXELINUX/lpxelinux.0 .

# EFI32-Loaders
cd ../efi32
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/efi32/ldlinux.e32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/vesamenu.c32 .
ln -s ../../../usr/lib/SYSLINUX.EFI/efi32/syslinux.efi .

# EFI64-Loaders
cd ../efi64
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/efi64/ldlinux.e64 .
ln -s ../../../usr/lib/syslinux/modules/efi64/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/vesamenu.c32 .
ln -s ../../../usr/lib/SYSLINUX.EFI/efi64/syslinux.efi .
</syntaxhighlight>

Um die Pflege des PXE-Bootmenüs zu vereinfachen, wird eine "globale" Konfiguration in ''/var/tftpboot/pxelinux.cfg'' (der Standardname, mit dem die PXE-Loader nach der Konfiguration suchen) für alle Architekturen via Symlinks zugänglich gemacht.

Die eigentliche Konfiguration für das Bootmenü findet sich in der Datei ''/var/tftpboot/pxelinux.cfg/default'':
menu title Boot menu
menu tabmsg Press ENTER to boot or TAB to edit a menu entry
prompt 0
timeout 600

label deblive64
menu label Debian Live ^amd64
kernel deb-live/amd64/vmlinuz
append initrd=deb-live/amd64/initrd.img net.ifnames=0 biosdevname=0 ip=:::::eth0:dhcp boot=live netboot=nfs root=/dev/nfs nfsroot=192.168.1.10:/var/nfsboot/deb-live/amd64 live-media-path=/ consoleblank=0 nfsrootdebug

label deblive32
menu label Debian Live ^i686
kernel deb-live/i686/vmlinuz
append initrd=deb-live/i686/initrd.img net.ifnames=0 biosdevname=0 ip=:::::eth0:dhcp boot=live netboot=nfs root=/dev/nfs nfsroot=192.168.1.10:/var/nfsboot/deb-live/amd64 live-media-path=/ consoleblank=0 nfsrootdebug

label bootlocal
menu label Boot ^local disk
menu default
localboot 0

ui menu.c32

* <code>net.ifnames=0 biosdevname=0</code> stellt die ursprüngliche, aufsteigende Nummerierung vom Kernel wieder her, damit die Netzwerkschnittstelle überall wieder ''eth0''heißt und diese wiederum in der <code>ip=</code>-Konfigurationszeile statisch referenziert werden kann.<ref>Früher hat die Autokonfiguration bei mehreren vorhandenen Netzwerkschnittstellen nicht zuverlässig funktioniert, deswegen der gezeigte Workaround.</ref>
* Das Zirkumflex (<code>^</code>) dient als Hervorhebung für einen Buchstaben im Menü. Dieser Buchstabe auf der Tastatur eingegeben aktiviert diesen Menüeintrag.

== NFS-Server ==
In der Datei ''/etc/exports'' wird definiert, welche Hosts auf welche Verzeichnisse Zugriff haben:
/var/nfsboot 192.168.1.0/24(ro,no_root_squash,insecure,no_subtree_check)

Nun müssen die Verzeichnisse für das Rootdateisystem noch angelegt werden:
mkdir -p /var/nfsboot/deb-live/amd64 /var/nfsboot/deb-live/i686

Damit die Änderungen ziehen, einmal den (mangels gültiger Einträge in ''exports'' sowieso nicht gestarteten) NFS-Server starten:
service nfs-kernel-server start

== Root-Dateisystem ==
Dies wird über eine "frische" Installation von Debian von Grund auf neu erzeugt:
* Debootstrap,
* Konfigurationsanpassungen,
* Squashfs-Build.

Das folgende Script kann mit den Parametern ''amd64'' oder ''i686'' aufgerufen werden und erzeugt jeweils ein Squashfs in den zuvor angelegten Verzeichnissen in ''/var/nfsboot''.

<syntaxhighlight lang="shell">
#!/bin/bash

# Must run as root.
if ! id |grep -Fq 'uid=0(root) gid=0(root) groups=0(root)'; then
echo "Must run as root."
exit 1
fi

# Must supply what to build.
if [ -z "${1}" ]; then
echo "Give arch as argument: amd64 or i686."
exit 0
fi

# Check what to build.
if [ "${1}" == "amd64" ]; then
DST_ARCH="amd64"
elif [ "${1}" == "i686" ] || [ "${1}" == "i386" ]; then
DST_ARCH="i686"
else
echo "Give arch as argument: amd64 or i686."
exit 0
fi

# Automatically clean up when we terminate.
trap '{ umount ${TMPMNT} && rmdir ${TMPMNT}; rm -f ${TMPIMG}; }' EXIT

# Terminate on error.
set -e

# Temporary image file and mount point to work within.
TMPIMG=$(mktemp --tmpdir=/var/tmp live-image.XXXXXXXXXX)
TMPMNT=$(mktemp -d --tmpdir=/var/tmp live-root.XXXXXXXXXX)

# Prepare image file and mount.
fallocate -v -l 4GiB "${TMPIMG}"
mke2fs -t ext4 -E lazy_itable_init=0 -O ^has_journal -i 16384 -L live-build -F "${TMPIMG}"
tune2fs -r0 -c0 -i12m -o '^acl,nobarrier' -e remount-ro -f "${TMPIMG}"
mount -o loop "${TMPIMG}" "${TMPMNT}"

# Install system.
if [ "${DST_ARCH}" == "amd64" ]; then
ARCH_ARG="--arch=amd64"
PKGLIST="console-setup, \
dosfstools, \
dump, \
firmware-amd-graphics, \
firmware-bnx2, \
firmware-bnx2x, \
firmware-linux-free, \
firmware-misc-nonfree, \
gdisk, \
ifupdown, \
isc-dhcp-client, \
kbd, \
keyboard-configuration, \
linux-image-amd64, \
live-boot, \
locales, \
lsscsi, \
lvm2, \
mdadm, \
mt-st, \
net-tools, \
nfs-common, \
openssh-client, \
openssh-server, \
orphan-sysvinit-scripts, \
pciutils, \
pv, \
sg3-utils, \
sysvinit-core"
elif [ "${DST_ARCH}" == "i686" ]; then
ARCH_ARG="--arch=i386"
PKGLIST="console-setup, \
dump, \
firmware-linux-free, \
ifupdown, \
isc-dhcp-client, \
kbd, \
keyboard-configuration, \
linux-image-686-pae, \
live-boot, \
locales, \
lsscsi, \
lvm2, \
mdadm, \
mt-st, \
net-tools, \
nfs-common, \
openssh-client, \
openssh-server, \
orphan-sysvinit-scripts, \
pciutils, \
pv, \
sg3-utils, \
sysvinit-core"
fi

# Parameter strings for debootstrap must not include blanks.
PKGLIST_CLEAN="$(echo "${PKGLIST}" |tr -d ' ')"
debootstrap "${ARCH_ARG}" --components=main,non-free,non-free-firmware,contrib \
--include "${PKGLIST_CLEAN}" \
--exclude nano,systemd-sysv,tasksel,tasksel-data \
stable "${TMPMNT}" https://debian.inf.tu-dresden.de/debian/

# Prepare system.
echo "debian-live" > "${TMPMNT}"/etc/hostname
cat > "${TMPMNT}"/etc/default/keyboard <<-EOF
# Check /usr/share/doc/keyboard-configuration/README.Debian for
# documentation on what to do after having modified this file.

# The following variables describe your keyboard and can have the same
# values as the XkbModel, XkbLayout, XkbVariant and XkbOptions options
# in /etc/X11/xorg.conf.

XKBMODEL="pc105"
XKBLAYOUT="de"
XKBVARIANT=""
XKBOPTIONS=""

# If you don't want to use the XKB layout on the console, you can
# specify an alternative keymap. Make sure it will be accessible
# before /usr is mounted.
# KMAP=/etc/console-setup/defkeymap.kmap.gz
BACKSPACE="guess"
EOF

# Clean apt lists to save space. They might be outdated anyway and need to be retransferred.
rm -f "${TMPMNT}"/var/lib/apt/lists/* 2>/dev/null || true

# Set default locale.
echo "LANG=en_US.UTF-8" > "${TMPMNT}"/etc/environment

# Add default password entry.
sed '/^root:/ d' "${TMPMNT}"/etc/shadow > "${TMPMNT}"/etc/shadow~
echo 'root::17852:0:99999:7:::' > "${TMPMNT}"/etc/shadow
cat "${TMPMNT}"/etc/shadow~ >> "${TMPMNT}"/etc/shadow

# Help with ssh-remote-logins.
echo "PermitRootLogin yes" >> "${TMPMNT}"/etc/ssh/sshd_config
echo "PermitEmptyPasswords yes" >> "${TMPMNT}"/etc/ssh/sshd_config

# Switch initrd to gzip.
sed -Ei 's/^COMPRESS=zstd$/COMPRESS=gzip/' "${TMPMNT}"/etc/initramfs-tools/initramfs.conf

# Prepare system to rebuild initramfs
mount -o bind /dev "${TMPMNT}"/dev
mount -o bind /dev/pts "${TMPMNT}"/dev/pts
mount -t proc none "${TMPMNT}"/proc
mount -t sysfs none "${TMPMNT}"/sys
echo "Please run these commands:"
# FIXME: How to automate this manual process?
echo ' echo "locales locales/default_environment_locale select en_US.UTF-8" |debconf-set-selections'
echo ' echo "locales locales/locales_to_be_generated multiselect en_US.UTF-8 UTF-8" |debconf-set-selections'
echo " dpkg-reconfigure locales"
echo " update-initramfs -u"
echo "then exit chroot."
chroot "${TMPMNT}"

# Script resumes after chroot exit.
umount "${TMPMNT}"/dev/pts "${TMPMNT}"/dev "${TMPMNT}"/proc "${TMPMNT}"/sys

# Copy Kernel and initramfs for TFTP
cp -v "${TMPMNT}"/vmlinuz "${TMPMNT}"/initrd.img /var/tftpboot/deb-live/"${DST_ARCH}"

# Compress into a file for NFS serving
mksquashfs "${TMPMNT}" /var/nfsboot/deb-live/"${DST_ARCH}"/filesystem.squashfs -noappend

# vim: tabstop=4 shiftwidth=4 autoindent expandtab
</syntaxhighlight>

* Die Paketliste in ''$PKGLIST'' ist darauf zugeschnitten, die für eine schnelle Wiederherstellung notwendigen Komponenten zu beinhalten.

== Test ==
Wenn nichts falsch gemacht wurde, so bezieht der Client nun beim Netzboot eine IP-Adresse vom DHCP-Server und lädt die PXE-Dateien, um im Anschluss ein Menü anzuzeigen, was denn nun gestartet werden soll. Nach der Auswahl eines Punktes werden Kernel und Initrd per TFTP übermittelt und der Kernel gestartet. Per erneuter DHCP-Anfrage erhält der Kernel gültige Netzparameter und mountet nun das per NFS zugängliche Squashfs als ''root''. Ab dann ist das Debian-Live-System aktiv.

In ''/var/log/daemon.log'' finden sich Meldungen vom TFTP-Server, was hilfreich bei der Fehlersuche sein kann.

== Weblinks ==
* [https://kb.isc.org/docs/aa-00333 Where to find ISC DHCP documentation?], ISC.org
* [http://grml.org/online-docs/live-initramfs.en.7.html Doku zur live-initramfs] (Manpage im HTML-Format, englisch.)

== Fußnoten ==
<references />

[[Kategorie:Linux]]

Debian-Live Netzbootsystem

2024-05-12T13:29:19Z

PoC: /* Root-Dateisystem */ +Script

Die Möglichkeit, hinreichend aktuelle Maschinen (allgemein, also VMs oder auch Blech) über das LAN zu booten ist eine feine Sache. Bare Metal Restore, oder auch die Offline-Korrektur von Fehlern wie z. B. zu kleinen Partitionen, etc. wird damit zum Kinderspiel.

Das '''Debian-Live'''-Projekt hat für Wiederherstellungszwecke eine Live-Boot CD-Serie bereitgestellt. Allerdings haben diese Images ein paar (teils subjektive) Nachteile:
* Gewohnte Konfigurationstools wurden durch modernere Varianten mit eigener Syntax abgelöst; ein Paradebeispiel ist das Fehlen von <code>ifconfig</code>.
* Hardware welche proprietäre Firmware-Binärdateien benötigt ist — vor allem wenn es um Netzwerkkarten geht — außen vor; ein Booten vom Netz geht spätestens nach dem Starten des Kernels schief.
* Viele weitere Pakete mit fast immer benötigten Tools fehlen und müssen immer und immer wieder per Hand nachinstalliert werden.

Der Artikel beschreibt die notwendigen Schritte, dieses Netzbootsystem auf einem existierenden Debian Linux 12 (Bookworm) aufzusetzen. Ob die zu startende Maschine ein älteres BIOS-basiertes System ist oder ein neueres EFI-System, ist egal: Beides wird dynamisch anhand von DHCP-Optionen passend konfiguriert. Dabei kann zum Bootzeitpunkt ausgewählt werden, ob ein 32- oder ein 64-Bit-System gestartet werden soll.

Es ist selbstverständlich möglich, weitere via PXE zu startende Betriebssysteme einzubinden. Wichtig ist zu beachten, dass die via TFTP bereitgestellten Dateien in den entsprechenden Unterverzeichnissen für die verschiedenen Architekturen zu hinterlegen sind (bios, efi32, efi64).

<blockquote>'''Hinweis''': Das von mir benutzte System ist traditionell mit ''SysV-init'' ausgerüstet. ''Systemd'' wird nicht benutzt. Die hier aufgeführten Schritte sind ansonsten so generisch wie möglich gehalten.</blockquote>

== Benötigte Komponenten ==
* ''DHCP-Server'' für die Zuweisung grundlegender Netzwerkparameter,
* ''TFTP-Server'' für den initialen Download von Bootloader, Menü und anschließend Kernel und Initrd,
* ''NFS-Server'' für den Zugriff auf das komprimierte Root-Dateisystem,
* ''Scripte'' zur Erstellung des übers Netz geladenen Root-Dateisystems.

Installation:
apt-get install openbsd-inetd isc-dhcp-server tftp-hpa tftpd-hpa nfs-kernel-server pxelinux syslinux-common syslinux-efi debootstrap squashfs-tools

== DHCP-Konfiguration ==
<blockquote>'''Hinweis''': Im lokalen Netzwerksegment soll nur '''ein''' DHCP-Server aktiv sein. Sind es mehrere, ist es mehr oder weniger Zufall, welches Antwortpaket der anfragende Client zuerst bearbeitet. Sollte also schon ein DHCP-Server existieren, muss die gezeigte Konfiguration in die bestehende Konfiguration eingebaut werden. Durch die Benutzung von DHCP-Klassen ("class") ist dies im Regelfall aber sehr einfach möglich.</blockquote>

Der erste Start des noch nicht unkonfigurierten DHCP-Servers geht erfahrungsgemäß schief, dies kann ignoriert werden.

Weil hier nur IPv4 berücksichtigt wird, muss in ''/etc/default/isc-dhcp-server die Zeile ''INTERFACESv6'' gelöscht werden. Ebenso muss in ''INTERFACESv4'' das für DHCP zu verwendenden Netzwerkinterface eingetragen werden. Beispiel:
INTERFACESv4="eth0"

Dies ist ein '''Beispiel''' für eine DHCP-Konfiguration! Insbesondere der ''group''-Abschnitt muss auf die lokalen Gegebenheiten angepasst werden!
<syntaxhighlight lang="shell">
authoritative;
ddns-updates off;
default-lease-time 3600;
log-facility daemon;
max-lease-time 86400;
min-lease-time 300;
min-secs 0;

option architecture-type code 93 = unsigned integer 16; # RFC4578

# Route different kinds of requesting clients to distinct PXE bootloaders.
class "pxeclients" {
match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";

if option architecture-type = 00:00 {
filename "/var/tftpboot/bios/lpxelinux.0";
} elsif option architecture-type = 00:06 {
filename "/var/tftpboot/efi32/syslinux.efi";
} elsif option architecture-type = 00:07 {
filename "/var/tftpboot/efi64/syslinux.efi";
} elsif option architecture-type = 00:09 {
filename "/var/tftpboot/efi64/syslinux.efi";
}

# This is the TFTP server's IP address.
next-server 192.168.111.10;
}

# Ethernet
group {
option broadcast-address 192.168.111.0;
option domain-name "pocnet.net";
option domain-name-servers 192.168.111.10;
option ntp-servers 192.168.111.10;
option routers 192.168.111.1;
option subnet-mask 255.255.255.0;

subnet 192.168.111.0 netmask 255.255.255.0 {
range 192.168.111.120 192.168.111.126;
}
}
</syntaxhighlight>

Nun kann der DHCP-Server gestartet werden:
service isc-dhcp-server start

== TFTP-Server ==
Die Konfiguration des Servers findet sich in ''/etc/default/tftpd-hpa''. Dort müssen folgende Änderungen durchgeführt werden:
* Ändern des Pfades ''/srv/tftp'' nach ''/var/tftpboot'',<ref>Ist kein Muss, aber in dieser Anleitung wird dieser Pfad vorausgesetzt.</ref>
* Ändern der ''TFTP_OPTIONS'':
** Löschen von <code>--secure</code>,
** Hinzufügen von <code>--permissive -v</code>.

Nun kann der alte Pfad gelöscht werden und der neue angelegt:
rmdir /srv/tftp
mkdir /var/tftpboot

Als letztes sollte der TFTP-Server neu gestartet werden:
service tftpd-hpa restart

=== Inhalte für <code>/var/tftpboot</code> ===
Zuerst werden ein paar grundlegende Verzeichnisse für die benötigten Dateien angelegt:
cd /var/tftpboot
mkdir -p deb-live/amd64 deb-live/i686 bios efi32 efi64 pxelinux.cfg

Für die einzelnen Architekturen werden nun die benötigten Bootdateien über Symlinks bereit gestellt. Symlinks brauchen weniger Speicher und wenn das Original (wegen Aktualisierungen) ausgetauscht wird, braucht man nicht mehr manuell nachbessern.

<syntaxhighlight lang="shell">
# BIOS-Loaders
cd bios
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/bios/ldlinux.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/pxechn.c32 .
ln -s ../../../usr/lib/syslinux/modules/bios/vesamenu.c32 .
ln -s ../../../usr/lib/PXELINUX/lpxelinux.0 .

# EFI32-Loaders
cd ../efi32
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/efi32/ldlinux.e32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi32/vesamenu.c32 .
ln -s ../../../usr/lib/SYSLINUX.EFI/efi32/syslinux.efi .

# EFI64-Loaders
cd ../efi64
ln -s ../deb-live .
ln -s ../pxelinux.cfg .
ln -s ../../../usr/lib/syslinux/modules/efi64/ldlinux.e64 .
ln -s ../../../usr/lib/syslinux/modules/efi64/libcom32.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/libutil.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/mboot.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/menu.c32 .
ln -s ../../../usr/lib/syslinux/modules/efi64/vesamenu.c32 .
ln -s ../../../usr/lib/SYSLINUX.EFI/efi64/syslinux.efi .
</syntaxhighlight>

Um die Pflege des PXE-Bootmenüs zu vereinfachen, wird eine "globale" Konfiguration in ''/var/tftpboot/pxelinux.cfg'' (der Standardname, mit dem die PXE-Loader nach der Konfiguration suchen) für alle Architekturen via Symlinks zugänglich gemacht.

Die eigentliche Konfiguration für das Bootmenü findet sich in der Datei ''/var/tftpboot/pxelinux.cfg/default'':
menu title Boot menu
menu tabmsg Press ENTER to boot or TAB to edit a menu entry
prompt 0
timeout 600

label deblive64
menu label Debian Live ^amd64
kernel deb-live/amd64/vmlinuz
append initrd=deb-live/amd64/initrd.img net.ifnames=0 biosdevname=0 ip=:::::eth0:dhcp boot=live netboot=nfs root=/dev/nfs nfsroot=192.168.1.10:/var/nfsboot/deb-live/amd64 live-media-path=/ consoleblank=0 nfsrootdebug

label deblive32
menu label Debian Live ^i686
kernel deb-live/i686/vmlinuz
append initrd=deb-live/i686/initrd.img net.ifnames=0 biosdevname=0 ip=:::::eth0:dhcp boot=live netboot=nfs root=/dev/nfs nfsroot=192.168.1.10:/var/nfsboot/deb-live/amd64 live-media-path=/ consoleblank=0 nfsrootdebug

label bootlocal
menu label Boot ^local disk
menu default
localboot 0

ui menu.c32

* <code>net.ifnames=0 biosdevname=0</code> stellt die ursprüngliche, aufsteigende Nummerierung vom Kernel wieder her, damit die Netzwerkschnittstelle überall wieder ''eth0''heißt und diese wiederum in der <code>ip=</code>-Konfigurationszeile statisch referenziert werden kann.<ref>Früher hat die Autokonfiguration bei mehreren vorhandenen Netzwerkschnittstellen nicht zuverlässig funktioniert, deswegen der gezeigte Workaround.</ref>
* Das Zirkumflex (<code>^</code>) dient als Hervorhebung für einen Buchstaben im Menü. Dieser Buchstabe auf der Tastatur eingegeben aktiviert diesen Menüeintrag.

== NFS-Server ==
In der Datei ''/etc/exports'' wird definiert, welche Hosts auf welche Verzeichnisse Zugriff haben:
/var/nfsboot 192.168.1.0/24(ro,no_root_squash,insecure,no_subtree_check)

Nun müssen die Verzeichnisse für das Rootdateisystem noch angelegt werden:
mkdir -p /var/nfsboot/deb-live/amd64 /var/nfsboot/deb-live/i686

Damit die Änderungen ziehen, einmal den (mangels gültiger Einträge in ''exports'' sowieso nicht gestarteten) NFS-Server starten:
service nfs-kernel-server start

== Root-Dateisystem ==
Dies wird über eine "frische" Installation von Debian von Grund auf neu erzeugt:
* Debootstrap,
* Konfigurationsanpassungen,
* Squashfs-Build.

Das folgende Script kann mit den Parametern ''amd64'' oder ''i686'' aufgerufen werden und erzeugt jeweils ein Squashfs in den zuvor angelegten Verzeichnissen in ''/var/nfsboot''.

<syntaxhighlight lang="shell">
#!/bin/bash

# Must run as root.
if ! id |grep -Fq 'uid=0(root) gid=0(root) groups=0(root)'; then
echo "Must run as root."
exit 1
fi

# Must supply what to build.
if [ -z "${1}" ]; then
echo "Give arch as argument: amd64 or i686."
exit 0
fi

# Check what to build.
if [ "${1}" == "amd64" ]; then
DST_ARCH="amd64"
elif [ "${1}" == "i686" ] || [ "${1}" == "i386" ]; then
DST_ARCH="i686"
else
echo "Give arch as argument: amd64 or i686."
exit 0
fi

# Automatically clean up when we terminate.
trap '{ umount ${TMPMNT} && rmdir ${TMPMNT}; rm -f ${TMPIMG}; }' EXIT

# Terminate on error.
set -e

# Temporary image file and mount point to work within.
TMPIMG=$(mktemp --tmpdir=/var/tmp live-image.XXXXXXXXXX)
TMPMNT=$(mktemp -d --tmpdir=/var/tmp live-root.XXXXXXXXXX)

# Prepare image file and mount.
fallocate -v -l 4GiB "${TMPIMG}"
mke2fs -t ext4 -E lazy_itable_init=0 -O ^has_journal -i 16384 -L live-build -F "${TMPIMG}"
tune2fs -r0 -c0 -i12m -o '^acl,nobarrier' -e remount-ro -f "${TMPIMG}"
mount -o loop "${TMPIMG}" "${TMPMNT}"

# Install system.
if [ "${DST_ARCH}" == "amd64" ]; then
ARCH_ARG="--arch=amd64"
PKGLIST="console-setup, \
dosfstools, \
dump, \
firmware-amd-graphics, \
firmware-bnx2, \
firmware-bnx2x, \
firmware-linux-free, \
firmware-misc-nonfree, \
gdisk, \
ifupdown, \
isc-dhcp-client, \
kbd, \
keyboard-configuration, \
linux-image-amd64, \
live-boot, \
locales, \
lsscsi, \
lvm2, \
mdadm, \
mt-st, \
net-tools, \
nfs-common, \
openssh-client, \
openssh-server, \
orphan-sysvinit-scripts, \
pciutils, \
pv, \
sg3-utils, \
sysvinit-core"
elif [ "${DST_ARCH}" == "i686" ]; then
ARCH_ARG="--arch=i386"
PKGLIST="console-setup, \
dump, \
firmware-linux-free, \
ifupdown, \
isc-dhcp-client, \
kbd, \
keyboard-configuration, \
linux-image-686-pae, \
live-boot, \
locales, \
lsscsi, \
lvm2, \
mdadm, \
mt-st, \
net-tools, \
nfs-common, \
openssh-client, \
openssh-server, \
orphan-sysvinit-scripts, \
pciutils, \
pv, \
sg3-utils, \
sysvinit-core"
fi

# Parameter strings for debootstrap must not include blanks.
PKGLIST_CLEAN="$(echo "${PKGLIST}" |tr -d ' ')"
debootstrap "${ARCH_ARG}" --components=main,non-free,non-free-firmware,contrib \
--include "${PKGLIST_CLEAN}" \
--exclude nano,systemd-sysv,tasksel,tasksel-data \
stable "${TMPMNT}" https://debian.inf.tu-dresden.de/debian/

# Prepare system.
echo "debian-live" > "${TMPMNT}"/etc/hostname
cat > "${TMPMNT}"/etc/default/keyboard <<-EOF
# Check /usr/share/doc/keyboard-configuration/README.Debian for
# documentation on what to do after having modified this file.

# The following variables describe your keyboard and can have the same
# values as the XkbModel, XkbLayout, XkbVariant and XkbOptions options
# in /etc/X11/xorg.conf.

XKBMODEL="pc105"
XKBLAYOUT="de"
XKBVARIANT=""
XKBOPTIONS=""

# If you don't want to use the XKB layout on the console, you can
# specify an alternative keymap. Make sure it will be accessible
# before /usr is mounted.
# KMAP=/etc/console-setup/defkeymap.kmap.gz
BACKSPACE="guess"
EOF

# Clean apt lists to save space. They might be outdated anyway and need to be retransferred.
rm -f "${TMPMNT}"/var/lib/apt/lists/* 2>/dev/null || true

# Set default locale.
echo "LANG=en_US.UTF-8" > "${TMPMNT}"/etc/environment

# Add default password entry.
sed '/^root:/ d' "${TMPMNT}"/etc/shadow > "${TMPMNT}"/etc/shadow~
echo 'root::17852:0:99999:7:::' > "${TMPMNT}"/etc/shadow
cat "${TMPMNT}"/etc/shadow~ >> "${TMPMNT}"/etc/shadow

# Help with ssh-remote-logins.
echo "PermitRootLogin yes" >> "${TMPMNT}"/etc/ssh/sshd_config
echo "PermitEmptyPasswords yes" >> "${TMPMNT}"/etc/ssh/sshd_config

# Switch initrd to gzip.
sed -Ei 's/^COMPRESS=zstd$/COMPRESS=gzip/' "${TMPMNT}"/etc/initramfs-tools/initramfs.conf

# Prepare system to rebuild initramfs
mount -o bind /dev "${TMPMNT}"/dev
mount -o bind /dev/pts "${TMPMNT}"/dev/pts
mount -t proc none "${TMPMNT}"/proc
mount -t sysfs none "${TMPMNT}"/sys
echo "Please run these commands:"
# FIXME: How to automate this manual process?
echo ' echo "locales locales/default_environment_locale select en_US.UTF-8" |debconf-set-selections'
echo ' echo "locales locales/locales_to_be_generated multiselect en_US.UTF-8 UTF-8" |debconf-set-selections'
echo " dpkg-reconfigure locales"
echo " update-initramfs -u"
echo "then exit chroot."
chroot "${TMPMNT}"

# Script resumes after chroot exit.
umount "${TMPMNT}"/dev/pts "${TMPMNT}"/dev "${TMPMNT}"/proc "${TMPMNT}"/sys

# Copy Kernel and initramfs for TFTP
cp -v "${TMPMNT}"/vmlinuz "${TMPMNT}"/initrd.img /var/tftpboot/deb-live/"${DST_ARCH}"

# Compress into a file for NFS serving
mksquashfs "${TMPMNT}" /var/nfsboot/deb-live/"${DST_ARCH}"/filesystem.squashfs -noappend

# vim: tabstop=4 shiftwidth=4 autoindent expandtab
</syntaxhighlight>

* Die Paketliste in ''$PKGLIST'' ist darauf zugeschnitten, die für eine schnelle Wiederherstellung notwendigen Komponenten zu beinhalten.

== Test ==
Wenn nichts falsch gemacht wurde, so bezieht der Client nun beim Netzboot eine IP-Adresse vom DHCP-Server und lädt die PXE-Dateien, um im Anschluss ein Menü anzuzeigen, was denn nun gestartet werden soll. Nach der Auswahl eines Punktes werden Kernel und Initrd per TFTP übermittelt und der Kernel gestartet. Per erneuter DHCP-Anfrage erhält der Kernel gültige Netzparameter und mountet nun das per NFS zugängliche Squashfs als ''root''. Ab dann ist das Debian-Live-System aktiv.

In ''/var/log/daemon.log'' finden sich Meldungen vom TFTP-Server, was hilfreich bei der Fehlersuche sein kann.

== Weblinks ==
* [https://kb.isc.org/docs/aa-00333 Where to find ISC DHCP documentation?], ISC.org
* [http://grml.org/online-docs/live-initramfs.en.7.html Doku zur live-initramfs] (Manpage im HTML-Format, englisch.)

== Fußnoten ==
<references />

[[Kategorie:Linux]]

Debian-Live Netzbootsystem

2024-05-11T22:32:20Z

PoC: Überarbeitet

VMware ESXi-Installation via PXE starten

2024-05-11T16:38:33Z

PoC: Kommt nicht mehr, ich mach nix mehr mit Vmware

Um eine aktuelle Version von '''VMware ESXi''' in eine '''PXE'''-Bootumgebung zu integrieren wird zuerst eine bestehende PXE-Umgebung benötigt. Wie diese im Linux-Kontext zu konfigurieren ist, ist im Artikel [[Debian-Live Netzbootsystem]] nachzulesen.

Dabei muss zwischen älteren und neueren Versionen von ''pxelinux'' unterschieden werden. Neuere Versionen können die bei VMware mitgelieferte ''mboot.c32'' nicht mehr starten. Dieses ist eine COM32R-Datei, während alle neueren Versionen das ELF-Format benutzen.

Zuerst muss von VMware das entsprechende Image heruntergeladen werden. Dieses wird dann auf dem Linuxserver gemountet.

== Mit altem Syslinux/pxeboot ==
Der Inhalt in einen Ordner unterhalb des TFTP-Ordners kopiert (beispielhafte Kommdos, Pfade sind ggfs. anzupassen):
mount -o loop,ro /data/VMware-VMvisor-Installer-5.5.0.update02-2068190.x86_64.iso /mnt/cdrom
mkdir /var/tftpboot/vmware-install
cp -R /mnt/cdrom/* /var/tftpboot/vmware-install/

Als nächster Schritt muss die Bootkonfigurationsdatei angepasst werden:
cd /var/tftpboot/vmware-install
sed -e "s#/##g" -e "3s#^#prefix=$PWD/\n#" -e "6s#jumpstrt.gz --- useropts.gz --- ##" -i.bak boot.cfg

Die gezeigte Vereinfachung mittels sed erledigt folgende Schritte:
* Löscht alle führenden / aus allen Pfadangaben,
* Fügt eine neue Zeile ein mit der ''Prefix''-Direktive und dem vollen Pfad zum tftp-Ordner, damit nicht alle Dateien mit den vollen Pfadnamen referenziert werden müssen
* Löscht Referenzen auf ''jumpstrt.gz'' und ''useropts.gz'' – beides leere Dateien im Gzip-Format. Beim Booten von ESXi 5.5 via tftp bleibt der Loader sonst mit einer Fehlermeldung bei diesen Dateien stehen. Bei ESXi 5.1 gibt es ''jumpstrt.gz'' nicht, daher funktioniert o. G. Regexp nicht. Bitte dann manuell nachbessern.

Als letztes muss nun noch ein Eintrag in die PXE-Konfigurationsdatei mit aufgenommen werden, um einen entsprechenden Eintrag im Menü zu erhalten:
label esxi55
menu label VMware ESXi 5.5 Install
kernel vmware-install/mboot.c32
append -c /var/tftpboot/vmware-install/boot.cfg

Die Dateien ''s.v00'', ''sb.v00'' und ''tools.t00'' sind recht groß und benötigen zum Download via tftp ihre Zeit. Nicht verzweifeln, falls es so aussieht als würde sich der Bootvorgang an dieser Stelle aufgehängt haben.

== Weblinks ==
* [http://www.vcritical.com/2011/07/vmware-esxi-5-interactive-pxe-installation-improvements/ VMware ESXi 5 Interactive PXE Installation Improvements]

[[Kategorie:VMware]]

Microsoft Windows Server 2000 temporäre Terminaldienstelizenzen automatisch erneuern

2024-05-10T09:07:18Z

PoC: /* Weblinks */ http-Link

'''Microsoft Windows Server 2000''' stellt ohne gültige Terminaldienste-Lizenz lediglich temporäre Lizenzen aus. Diese sind nur drei Monate Tage gültig. Durch Löschen des Lizenzspeichers ''C:\WINNT\system32\LServer\TLSLic.edb'' kann man wiederum drei Monate Nutzungszeit in Anspruch nehmen. Allerdings müssen dann auch die temporären Lizenzen der Clients gelöscht werden.

== Automatisierung ==
Diese Batchdatei kann als geplanter Task benutzt werden:
@echo off
net stop TermServLicensing
del C:\WINNT\system32\LServer\TLSLic.bak
rename C:\WINNT\system32\LServer\TLSLic.edb TLSLic.bak
del C:\WINNT\system32\LServer\TLSLic.bak
del C:\WINNT\system32\LServer\edb.chk
net start TermServLicensing

== Siehe auch ==
* [[Lizenzspeicher bei Microsoft Remote Desktop for Mac bereinigen]]

== Weblinks ==
* [https://support.microsoft.com/de-de/help/187614/removing-terminal-server-licenses-from-an-rdp-client Entfernen von Terminalserverlizenzen von einem RDP-client]
* [https://itech-tr.blogspot.com/2010/06/terminal-services-unlimited.html Terminal Services Unlimited]
* [https://smarterlasopa452.weebly.com/crack-rdp-windows-server-2008-r2.html How to reset Windows Terminal Services three Month Trial]

[[Kategorie: Windows]]

Datei:1x1-transparent.png

2024-04-14T15:14:44Z

PoC:

Debian Bullseye auf HPE Microserver Gen10

2024-04-11T19:54:32Z

PoC: Neu

Der '''HPE Microserver Gen10''' hat einen Onboard Marvell SATA Controller. Mit dem Standardkernel (6.1.0) von '''Debian Bullseye''' bleibt der Rechner während des Kernel-Starts beim Erkennen der Festplatten hängen, versucht die Disks mit geringeren Datenraten anzusprechen und beginnt wieder von vorn.

Marvell Technology Group Ltd. 88SE9230 PCIe 2.0 x2 4-port SATA 6 Gb/s RAID Controller (rev 11)

Kernelmeldungen beinhalten den String <code>failed to IDENTIFY</code>.

== Lösung ==
<code>iommu=pt</code> zu den Kernelparametern ergänzen.<ref>Das rauszufinden hat mich drei Stunden Recherche, wiederholtes PXE-Booten und Ausprobieren gekostet.</ref> Es ist nicht notwendig, die MMU mit <code>iommu=off</code> ganz auszuknipsen.

== Weblinks ==
* [https://lore.kernel.org/linux-iommu/20230328012231.GB21977@lst.de/T/ <nowiki>Re: [regression] Bug 217218 - Trying to boot Linux version 6-2.2 kernel with Marvell SATA controller 88SE9235</nowiki>], LKML

== Fußnoten ==
<references />

[[Kategorie: Hardware]]
[[Kategorie: Linux]]

Linux von BIOS- auf UEFI-Boot umstellen

2023-10-18T16:17:25Z

PoC: Überarbeitet anhand Deb12

Ohne zu wissen, was es mit EFI auf sich hat, ist das '''Umstellen von Linux von BIOS- auf EFI-Boot''' auf echter Serverhardware (die meistens minutenlang in der internen Firmware rumhängt) zeitraubend und frustrierend. In Kürze Erklärung und Wichtiges:

== Grundlagen ==
(U)EFI ((Unified) Extensible Firmware Interface) ist mit neuerer Hardware unvermeidbar. Eigentlich ist das Thema sehr einfach: Es gibt keinen binären Bootblock mehr, sondern eine kleine FAT32-Partition zu Beginn der Boot-Disk (ggfs. HW-RAID-Array). Die Bootloader der verschiedenen Betriebssysteme erzeugen eine Verzeichnisstruktur, in welcher dann das eigentliche Startprogramm hinterlegt wird. Die Firmware sammelt beim Systemstart eine Liste der gefundenen ausführbaren Binaries (PE32+ executable) und bietet diese dann zum Start an (bzw. der Standardeintrag wird gestartet).

== Vorbereitungen ==
* Ohne Repartitionieren geht es nicht. Da die Umstellung auf EFI durch einem Hardwaretausch mit anschließender Kopie der vorhandenen Installation durchgeführt wird, ist das aber kein Beinbruch.
* Der initiale Boot (CD, ISO-Image, PXE, USB-Stick, usw.) muss zwingend im EFI-Modus mit einem dementsprechend EFI-fähigen Bootmedium durchgeführt werden. Das Debian-Live-Image von Debian 8 oder älter ist nicht geeignet! Erst ab 9 gibt es EFI-Support, z. B. [https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.2.0-amd64-standard.iso debian-live-12.2.0-amd64-standard.iso]. Ohne Boot im EFI-Modus sind die EFI-Hooks in der Firmware unsichtbar und Grub-EFI wird mit Fehlern um sich werfen.

== Checkliste ==
* Neues System vorbereiten (FW-Updates, BIOS-Settings, usw.),
* Bootmedium vorbereiten (siehe oben),
* Boot via EFI-Bootmenü von diesem Medium,
* Ggfs. manuelle Netzwerkkonfiguration,
* Nachinstallation von benötigten Systemkomponenten,
apt-get install gdisk mdadm dosfstools dump
* Vorbereiten der Platten für das OS:
** Partitionieren (''gdisk''), dabei (eine) z. B. 5 MB große EFI-Partition(en) anlegen, Typ EF00,<ref>Tatsächlich benötigt werden vom Grub-Loader einige 100 KBytes.</ref>
** Ggfs. Erzeugen der gewünschten Arrays mit ''mdadm'',
** Dateisysteme erzeugen, dabei die EFI-Partition(en) mit einem FAT32-Dateisystem versehen,
mkfs.fat /dev/sda1,
** Mounten des OS-Dateisystems nach z. B. ''/mnt'', <code>cd /mnt</code>,
** Kopieren der Installation vom Quellsystem, wie gehabt mit
ssh ''srcsys'' "dump -0a -b 256 -f - /dev/sda1" |restore -r -b 256 -f -
** Vorbereitungen für ''chroot'': <code>mount -o bind /dev dev/</code>,
* <code>chroot /mnt</code>,
* Nachmounten von Kernel-Pseudo-Dateisystemen: <code>mount -t proc none /proc; mount -t sysfs none /sys; mount -t devpts none /dev/pts</code>,
* Anpassen der ''/etc/fstab'', dabei Eintragen der EFI-Partition(en),
/dev/sda1 /boot/efi vfat defaults 0 0
* Anlegen des EFI-Bootverzeichnisses,
mkdir /boot/efi
* Anpassen der ''/etc/fstab'', dabei Eintragen von ''efivars'':
none /sys/firmware/efi/efivars efivarfs defaults 0 0
* Mounten der EFI-Partition(en),
mount -a
* Nachinstallation von auf dem später laufenden System benötigten Systemkomponenten (mdadm),
* Ggfs. schreiben der RAID-Konfiguration mit <code>/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf; update-initramfs -u</code>,
* Austauschen von Grub,
apt-get install grub-efi-amd64 grub-efi-amd64-bin
* Sichern der Grub-Defaults,
cp -a /etc/default/grub /etc/default/grub~
* Löschen von altem Grub-PC-Kram, die Frage nach Löschen vom alten Bootloader bejahen,
dpkg -P grub-pc grub-pc-bin
* Restore der Grub-Defaults,
mv /etc/default/grub~ /etc/default/grub
* Restore von gemeinsamen Grub-Dateien durch Reinstallation,
apt-get install --reinstall grub-efi-amd64 grub-efi-amd64-bin

Grub-EFI erfordert keine Platte mehr als Parameter beim beim Grub-Install:
grub-install
update-grub

* Raus aus der chroot: <code>exit</code>,
* Unmounten: <code>umount boot/efi* dev/pts dev proc sys; cd ..; umount mnt</code>.

Nach einem Reboot muss die Installation dann wieder sauber hochkommen. Weitere Schritte wie Netzwerkkonfigurationsanpassungen an die neue Hardware sind nicht beschrieben.

=== Mögliche Fehler ===
Aus der Praxis…

==== Meldung: EFI variables are not supported on this system ====
grub-install: warning: EFI variables are not supported on this system.

Dieser Fehler kann zum einen bedeuten, dass das System selbst im BIOS-Modus gestartet wurde. Allerdings scheint es ab Debian 11 notwendig zu sein, einen weiteren Mountpoint zu setzen:

none /sys/firmware/efi/efivars efivarfs defaults 0 0

Damit funktioniert dann auch ein <code>grub-install</code> fehlerfrei.

==== Nach Reboot erscheint nur die Grub-Kommandozeile ====
Falls das alte BIOS-Grub-Paket mit <code>--purge</code> gelöscht wurde, hätte '''unbedingt''' danach ein
grub-install
update-grub
abgesetzt werden müssen, da das Purge des BIOS-Paketes auch die Konfiguration und weitere Dateien löscht.

Lösung: Die Schritte von oben nochmal wiederholen:
* Boot von externem Medium,
* <code>chroot</code>,
* Mounten der benötigten Partitionen,
* Grub-Konfiguration neu schreiben:
grub-install
update-grub
* <code>umount</code>,
* Reboot.

=== Redundanz ===
Beim Booten kann dann statt einem möglicherweise wechselnden Gerät, eine Boot-Konfiguration aus dem genannten Verzeichnis eines beliebigen Gerätes gestartet werden. Vorbei sind die Tage, in denen in einem Software-RAID die erste Platte ausfällt, die zweite Platte dann an die erste Stelle rückt, der Bootblock ist aber nicht auf die erste Platte konfiguriert, sondern entweder überhaupt nicht<ref>Schlampiger Admin…</ref> oder das BIOS kommt mit der neuen BIOS-ID (0x80 statt 0x81) nicht zurecht und verweigert den Boot.

EFI hat allerdings eine konzeptionelle Schwachstelle: Die Einfachhheit eine ''/boot''-Partition per Software-RAID zu spiegeln ist nicht vorgesehen. Man kann sich was basteln über ''mdadm'' mit nicht persistentem Superblock (damit keine Daten überschrieben werden), aber das ist letztlich alles Gebastel. 
Am Einfachsten ist es, manuell die Verzeichnisstruktur auf die zuvor manuell identisch partitionierten und in ''/boot/efi2'', ''/boot/efi3'', usw. gemounteten FAT32-Partitionen zu kopieren.

Für Debian muss eine Datei angelegt und als ausführbar markiert werden: ''/etc/grub.d/42_update-hook'':
#!/bin/sh
# Dirty hack: If there are multiple FA32-mountpoints in /boot/efi, sync
# contents manually to provide poor man's redundancy.
if mount -t vfat |awk '{print $3}' |grep -q '^/boot/efi$'; then
cat /dev/null > /var/log/update-grub.log
for MP in `mount -t vfat |awk '{print $3}' |grep -v '^/boot/efi$'`; do
rsync -av --delete /boot/efi/ ${MP}/ >> /var/log/update-grub.log
done
else
echo "No EFI Mount Point detected." > /var/log/update-grub.log
fi

# --EOF--

Bei jedem Aufruf, der die Grub-Konfiguration neu erzeugt, wird somit auch die Struktur kopiert. Das beinhaltet auch Updates von Kernel und Grub selbst. Fire and forget.

== Weblinks ==
* [https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/ UEFI booting and RAID1]
* [https://www.heise.de/newsticker/meldung/Was-Linux-Anwender-ueber-UEFI-wissen-muessen-4204725.html Was Linux-Anwender über UEFI wissen müssen]
* [https://packages.debian.org/stable/bootcd Run your system from cd without need for disks]<ref>Ob das EFI kompatible Images herstellt, ist derzeit nicht bekannt.</ref>
* [https://wiki.debian.org/EFIStub …it is possible to load the kernel directly, without any additional bootloader]

== Fußnoten ==
<references />

[[Kategorie: Linux]]

Linux von BIOS- auf UEFI-Boot umstellen

2023-10-18T16:02:55Z

PoC: /* Fallstricke */ Neueres Image

Ohne zu wissen, was es mit EFI auf sich hat, ist das '''Umstellen von Linux von BIOS- auf EFI-Boot''' auf echter Serverhardware (die meistens minutenlang in der internen Firmware rumhängt) zeitraubend und frustrierend. In Kürze Erklärung und Wichtiges:

== Grundlagen ==
(U)EFI ((Unified) Extensible Firmware Interface) ist mit neuerer Hardware unvermeidbar. Eigentlich ist das Thema sehr einfach: Es gibt keinen binären Bootblock mehr, sondern eine kleine FAT32-Partition zu Beginn der Boot-Disk (ggfs. HW-RAID-Array). Die Bootloader der verschiedenen Betriebssysteme erzeugen eine Verzeichnisstruktur, in welcher dann das eigentliche Startprogramm hinterlegt wird. Die Firmware sammelt beim Systemstart eine Liste der gefundenen ausführbaren Binaries (PE32+ executable) und bietet diese dann zum Start an (bzw. der Standardeintrag wird gestartet).

== Fallstricke ==
* Ohne Repartitionieren geht es nicht. Da die Umstellung auf EFI durch einem Hardwaretausch mit anschließender Kopie der vorhandenen Installation durchgeführt wird, ist das aber kein Beinbruch.
* Der initiale Boot (CD, ISO-Image, PXE, USB-Stick, usw.) muss zwingend im EFI-Modus mit einem dementsprechend EFI-fähigen Bootmedium durchgeführt werden. Das Debian-Live-Image von Debian 8 oder älter ist nicht geeignet! Erst ab 9 gibt es EFI-Support, z. B. [https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.2.0-amd64-standard.iso debian-live-12.2.0-amd64-standard.iso]. Ohne Boot im EFI-Modus sind die EFI-Hooks in der Firmware unsichtbar und Grub-EFI wird mit Fehlern um sich werfen.
* Falls das alte BIOS-Grub-Paket mit <code>--purge</code> gelöscht wird, ist '''unbedingt''' danach ein
grub-install dummy
update-grub
abzusetzen, da das Purge des BIOS-Paketes auch die Konfiguration und weitere Dateien löscht. Nach einem Reboot gibt's ansonsten die Grub-Kommandozeile.

== Checkliste ==
* Neues System vorbereiten (FW-Updates, BIOS-Settings, usw.),
* Bootmedium vorbereiten (siehe oben),
* Boot via EFI-Bootmenü von diesem Medium,
* Ggfs. manuelle Netzwerkkonfiguration,
* Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),
* Vorbereiten der Platten für das OS:
** Partitionieren (''gdisk''), dabei (eine) z. B. 5 MB große EFI-Partition(en) anlegen, Typ EF00,<ref>Tatsächlich benötigt werden vom Grub-Loader einige 100 KBytes.</ref>
** Ggfs. Erzeugen der gewünschten Arrays mit ''mdadm'',
** Dateisysteme erzeugen, dabei die EFI-Partition(en) mit einem FAT32-Dateisystem versehen, z. B.: <code>mkfs.fat -F32 /dev/sda1</code>,
** Mounten des OS-Dateisystems nach z. B. ''/mnt'', <code>cd /mnt</code>,
** Kopieren der Installation vom Quellsystem, wie gehabt mit z. B. <code>ssh ''srcsys'' "dump -0a -b 256 -f - /dev/sda1" |restore -r -b 256 -f -</code>,
** Vorbereitungen für ''chroot'': <code>mount -o bind /dev dev/</code>,
* <code>chroot /mnt</code>,
* Nachmounten von Kernel-Pseudo-Dateisystemen: <code>mount -t proc none /proc; mount -t sysfs none /sys; mount -t devpts none /dev/pts</code>,
* Anpassen der ''/etc/fstab'', dabei Eintragen der EFI-Partition(en),
* Anpassen der ''/etc/fstab'', dabei Eintragen von ''efivars'':
none /sys/firmware/efi/efivars efivarfs defaults 0 0
* Mounten der EFI-Partition(en),
* Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),
* Ggfs. schreiben der RAID-Konfiguration mit <code>/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf; update-initramfs -u</code>,
* Austauschen von Grub: <code>apt-get install grub-efi-amd64 grub-efi-amd64-bin</code>,
* Löschen von altem Grub-PC-Kram: <code>dpkg -P grub-pc grub-pc-bin</code>,
* Prüfen, ob ''/etc/default/grub'' existiert und falls nicht, nochmal vom Backup kopieren.

Grub-EFI erfordert keine Platte mehr als Parameter beim beim Grub-Install. Statt dessen wird als (leider benötigter Parameter) ''dummy'' übergeben.
grub-install dummy

* Raus aus der chroot: <code>exit</code>,
* Unmounten: <code>umount boot/efi* dev proc sys; cd ..; umount mnt</code>.

Nach einem Reboot muss die Installation dann wieder sauber hochkommen. Weitere Schritte wie Netzwerkkonfigurationsanpassungen an die neue Hardware sind nicht beschrieben.

=== Mögliche Fehler ===
grub-install: warning: EFI variables are not supported on this system.

Dieser Fehler kann zum einen bedeuten, dass das System selbst im BIOS-Modus gestartet wurde. Allerdings scheint es ab Debian 11 notwendig zu sein, einen weiteren Mountpoint zu setzen:

none /sys/firmware/efi/efivars efivarfs defaults 0 0

Damit funktioniert dann auch ein <code>grub-install</code> fehlerfrei.

=== Redundanz ===
Beim Booten kann dann statt einem möglicherweise wechselnden Gerät, eine Boot-Konfiguration aus dem genannten Verzeichnis eines beliebigen Gerätes gestartet werden. Vorbei sind die Tage, in denen in einem Software-RAID die erste Platte ausfällt, die zweite Platte dann an die erste Stelle rückt, der Bootblock ist aber nicht auf die erste Platte konfiguriert, sondern entweder überhaupt nicht<ref>Schlampiger Admin…</ref> oder das BIOS kommt mit der neuen BIOS-ID (0x80 statt 0x81) nicht zurecht und verweigert den Boot.

EFI hat allerdings eine konzeptionelle Schwachstelle: Die Einfachhheit eine ''/boot''-Partition per Software-RAID zu spiegeln ist nicht vorgesehen. Man kann sich was basteln über ''mdadm'' mit nicht persistentem Superblock (damit keine Daten überschrieben werden), aber das ist letztlich alles Gebastel. 
Am Einfachsten ist es, manuell die Verzeichnisstruktur auf die zuvor manuell identisch partitionierten und in ''/boot/efi2'', ''/boot/efi3'', usw. gemounteten FAT32-Partitionen zu kopieren.

Für Debian muss eine Datei angelegt und als ausführbar markiert werden: ''/etc/grub.d/42_update-hook'':
#!/bin/sh
# Dirty hack: If there are multiple FA32-mountpoints in /boot/efi, sync
# contents manually to provide poor man's redundancy.
if mount -t vfat |awk '{print $3}' |grep -q '^/boot/efi$'; then
cat /dev/null > /var/log/update-grub.log
for MP in `mount -t vfat |awk '{print $3}' |grep -v '^/boot/efi$'`; do
rsync -av --delete /boot/efi/ ${MP}/ >> /var/log/update-grub.log
done
else
echo "No EFI Mount Point detected." > /var/log/update-grub.log
fi

# --EOF--

Bei jedem Aufruf, der die Grub-Konfiguration neu erzeugt, wird somit auch die Struktur kopiert. Das beinhaltet auch Updates von Kernel und Grub selbst. Fire and forget.

== Weblinks ==
* [https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/ UEFI booting and RAID1]
* [https://www.heise.de/newsticker/meldung/Was-Linux-Anwender-ueber-UEFI-wissen-muessen-4204725.html Was Linux-Anwender über UEFI wissen müssen]
* [https://packages.debian.org/stable/bootcd Run your system from cd without need for disks]<ref>Ob das EFI kompatible Images herstellt, ist derzeit nicht bekannt.</ref>
* [https://wiki.debian.org/EFIStub …it is possible to load the kernel directly, without any additional bootloader]

== Fußnoten ==
<references />

[[Kategorie: Linux]]

Systemd bei Debian loswerden

2023-10-18T12:14:39Z

PoC: Test mit Deb 11: Kein shim mehr, Rest funktioniert 1:1

'''Debian Jessie''' (8) (und neuer) bringt per Default ein neues Startsystem, mit: Systemd. Nach sorgfältiger Recherche und Abwägen des Für und Wider habe ich mich dazu entschlossen, meine Debian-Installationen ohne '''Systemd''' zu betreiben, sondern auf die nach wie vor unterstützte traditionelle Sysv-Umgebung zu setzen. Bei den Betrachtungen ist wichtig, dass es hier nicht um Desktopsysteme geht, sondern um Serverinstallationen.

Diese Anleitung wurde mit Debian Buster (10) verifiziert.

Mit Debian 12 (Bookworm) gibt es wohl neue Paketabhängigkeiten, weswegen diese Anleitung nicht mehr funktioniert.

== Gründe ==
Achtung, dies ist meine subjektive Betrachtungsweise!

* Systemd ist unübersichtlich, weil Systemd alles abdecken möchte, was derzeit von bekannten und gut funktionierenden Subsystemen abgedeckt wird:
** ''Init'' für Runlevelmanagement und Startvorgang,
** ''Udev'' für dynamische ''/dev''-Nodes und Netzwerkinterfaces,
** Ergänzung/Ablöse von ''(x)inetd'' zwecks Nachstarten von Prozessen,
** evtl. weiteres, was mir bisher nicht negativ aufgefallen ist.

Welche eigentlich netten und relevanten Features verlieren die Installationen durch den Verzicht?
* Den beeindruckend schnellen Startvorgang, u. A. durch Parallelisierung von Daemonstarts,
* Automatische Prozessisolation durch die Integration von ''cgroups'' in den Startvorgang.

Was gewinnt man durch den Verzicht?
* Eine bekannte, verlässliche und durch jahrelange Erfahrung gestützte Systemumgebung, die alte Hasen im Schlaf und zeitgleichem Vollsuff beherrschen; ein nicht zu unterschätzender Punkt für Serveradministratoren,
* deutlich näher dran an ''[https://en.wikipedia.org/wiki/Everything_is_a_file everything is a file]'',
* erprobtes Logging im ASCII-Format mit allen Vorteilen wie z. B. ''grep''.

== Vorgehensweise ==
apt-get install sysvinit-core bootlogd systemd-sysv-
reboot

Danach:
apt-get autoremove --purge systemd

Fertig.

Beim letzten ''apt-get''-Aufruf sollte geprüft werden, ob eventuell weitere Pakete deinstalliert werden, welche ''Systemd'' als Abhängigkeit besitzen. Bei Serverinstallationen dürfte dies in der Regel nicht der Fall sein.

== Siehe auch ==
* [[Debian-Upgrade auf Jessie ohne Systemd]]

== Weblinks ==
* [http://www.freedesktop.org/wiki/Software/systemd/ Systemd Projektseite] (en)
* [http://unix.stackexchange.com/questions/5877/what-are-the-pros-cons-of-upstart-and-systemd Darlegung von Für/Wider] bei Stackexchange (en)
* [http://0pointer.de/blog/projects/the-biggest-myths.html Mythen über Systemd] (en)
* [http://www.simonrichter.eu/blog/2016-03-03-why-sysvinit.html SimonRichter/ blog/ Why sysvinit?] (en)
* [https://unix.stackexchange.com/questions/218933/after-switching-to-devuan-how-do-i-remove-systemd After switching to Devuan, how do I remove systemd?] (en)

[[Kategorie:Linux]]

Linux von BIOS- auf UEFI-Boot umstellen

2023-10-18T12:13:43Z

PoC: /* Checkliste */ 5MB reichen

Ohne zu wissen, was es mit EFI auf sich hat, ist das '''Umstellen von Linux von BIOS- auf EFI-Boot''' auf echter Serverhardware (die meistens minutenlang in der internen Firmware rumhängt) zeitraubend und frustrierend. In Kürze Erklärung und Wichtiges:

== Grundlagen ==
(U)EFI ((Unified) Extensible Firmware Interface) ist mit neuerer Hardware unvermeidbar. Eigentlich ist das Thema sehr einfach: Es gibt keinen binären Bootblock mehr, sondern eine kleine FAT32-Partition zu Beginn der Boot-Disk (ggfs. HW-RAID-Array). Die Bootloader der verschiedenen Betriebssysteme erzeugen eine Verzeichnisstruktur, in welcher dann das eigentliche Startprogramm hinterlegt wird. Die Firmware sammelt beim Systemstart eine Liste der gefundenen ausführbaren Binaries (PE32+ executable) und bietet diese dann zum Start an (bzw. der Standardeintrag wird gestartet).

== Fallstricke ==
* Ohne Repartitionieren geht es nicht. Da die Umstellung auf EFI durch einem Hardwaretausch mit anschließender Kopie der vorhandenen Installation durchgeführt wird, ist das aber kein Beinbruch.
* Der initiale Boot (CD, ISO-Image, PXE, USB-Stick, usw.) muss zwingend im EFI-Modus mit einem dementsprechend EFI-fähigen Bootmedium durchgeführt werden. Das Debian-Live-Image von Debian 8 oder älter ist nicht geeignet! Erst ab 9 gibt es EFI-Support, z. B. [http://cdimage.debian.org/debian-cd/9.6.0-live/amd64/iso-hybrid/debian-live-9.6.0-amd64-xfce.iso debian-live-9.6.0-amd64-xfce.iso]. Ohne Boot im EFI-Modus sind die EFI-Hooks in der Firmware unsichtbar und Grub-EFI wird mit Fehlern um sich werfen.
* Falls das alte BIOS-Grub-Paket mit <code>--purge</code> gelöscht wird, ist '''unbedingt''' danach ein
grub-install dummy
update-grub
abzusetzen, da das Purge des BIOS-Paketes auch die Konfiguration und weitere Dateien löscht. Nach einem Reboot gibt's ansonsten die Grub-Kommandozeile.

== Checkliste ==
* Neues System vorbereiten (FW-Updates, BIOS-Settings, usw.),
* Bootmedium vorbereiten (siehe oben),
* Boot via EFI-Bootmenü von diesem Medium,
* Ggfs. manuelle Netzwerkkonfiguration,
* Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),
* Vorbereiten der Platten für das OS:
** Partitionieren (''gdisk''), dabei (eine) z. B. 5 MB große EFI-Partition(en) anlegen, Typ EF00,<ref>Tatsächlich benötigt werden vom Grub-Loader einige 100 KBytes.</ref>
** Ggfs. Erzeugen der gewünschten Arrays mit ''mdadm'',
** Dateisysteme erzeugen, dabei die EFI-Partition(en) mit einem FAT32-Dateisystem versehen, z. B.: <code>mkfs.fat -F32 /dev/sda1</code>,
** Mounten des OS-Dateisystems nach z. B. ''/mnt'', <code>cd /mnt</code>,
** Kopieren der Installation vom Quellsystem, wie gehabt mit z. B. <code>ssh ''srcsys'' "dump -0a -b 256 -f - /dev/sda1" |restore -r -b 256 -f -</code>,
** Vorbereitungen für ''chroot'': <code>mount -o bind /dev dev/</code>,
* <code>chroot /mnt</code>,
* Nachmounten von Kernel-Pseudo-Dateisystemen: <code>mount -t proc none /proc; mount -t sysfs none /sys; mount -t devpts none /dev/pts</code>,
* Anpassen der ''/etc/fstab'', dabei Eintragen der EFI-Partition(en),
* Anpassen der ''/etc/fstab'', dabei Eintragen von ''efivars'':
none /sys/firmware/efi/efivars efivarfs defaults 0 0
* Mounten der EFI-Partition(en),
* Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),
* Ggfs. schreiben der RAID-Konfiguration mit <code>/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf; update-initramfs -u</code>,
* Austauschen von Grub: <code>apt-get install grub-efi-amd64 grub-efi-amd64-bin</code>,
* Löschen von altem Grub-PC-Kram: <code>dpkg -P grub-pc grub-pc-bin</code>,
* Prüfen, ob ''/etc/default/grub'' existiert und falls nicht, nochmal vom Backup kopieren.

Grub-EFI erfordert keine Platte mehr als Parameter beim beim Grub-Install. Statt dessen wird als (leider benötigter Parameter) ''dummy'' übergeben.
grub-install dummy

* Raus aus der chroot: <code>exit</code>,
* Unmounten: <code>umount boot/efi* dev proc sys; cd ..; umount mnt</code>.

Nach einem Reboot muss die Installation dann wieder sauber hochkommen. Weitere Schritte wie Netzwerkkonfigurationsanpassungen an die neue Hardware sind nicht beschrieben.

=== Mögliche Fehler ===
grub-install: warning: EFI variables are not supported on this system.

Dieser Fehler kann zum einen bedeuten, dass das System selbst im BIOS-Modus gestartet wurde. Allerdings scheint es ab Debian 11 notwendig zu sein, einen weiteren Mountpoint zu setzen:

none /sys/firmware/efi/efivars efivarfs defaults 0 0

Damit funktioniert dann auch ein <code>grub-install</code> fehlerfrei.

=== Redundanz ===
Beim Booten kann dann statt einem möglicherweise wechselnden Gerät, eine Boot-Konfiguration aus dem genannten Verzeichnis eines beliebigen Gerätes gestartet werden. Vorbei sind die Tage, in denen in einem Software-RAID die erste Platte ausfällt, die zweite Platte dann an die erste Stelle rückt, der Bootblock ist aber nicht auf die erste Platte konfiguriert, sondern entweder überhaupt nicht<ref>Schlampiger Admin…</ref> oder das BIOS kommt mit der neuen BIOS-ID (0x80 statt 0x81) nicht zurecht und verweigert den Boot.

EFI hat allerdings eine konzeptionelle Schwachstelle: Die Einfachhheit eine ''/boot''-Partition per Software-RAID zu spiegeln ist nicht vorgesehen. Man kann sich was basteln über ''mdadm'' mit nicht persistentem Superblock (damit keine Daten überschrieben werden), aber das ist letztlich alles Gebastel. 
Am Einfachsten ist es, manuell die Verzeichnisstruktur auf die zuvor manuell identisch partitionierten und in ''/boot/efi2'', ''/boot/efi3'', usw. gemounteten FAT32-Partitionen zu kopieren.

Für Debian muss eine Datei angelegt und als ausführbar markiert werden: ''/etc/grub.d/42_update-hook'':
#!/bin/sh
# Dirty hack: If there are multiple FA32-mountpoints in /boot/efi, sync
# contents manually to provide poor man's redundancy.
if mount -t vfat |awk '{print $3}' |grep -q '^/boot/efi$'; then
cat /dev/null > /var/log/update-grub.log
for MP in `mount -t vfat |awk '{print $3}' |grep -v '^/boot/efi$'`; do
rsync -av --delete /boot/efi/ ${MP}/ >> /var/log/update-grub.log
done
else
echo "No EFI Mount Point detected." > /var/log/update-grub.log
fi

# --EOF--

Bei jedem Aufruf, der die Grub-Konfiguration neu erzeugt, wird somit auch die Struktur kopiert. Das beinhaltet auch Updates von Kernel und Grub selbst. Fire and forget.

== Weblinks ==
* [https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/ UEFI booting and RAID1]
* [https://www.heise.de/newsticker/meldung/Was-Linux-Anwender-ueber-UEFI-wissen-muessen-4204725.html Was Linux-Anwender über UEFI wissen müssen]
* [https://packages.debian.org/stable/bootcd Run your system from cd without need for disks]<ref>Ob das EFI kompatible Images herstellt, ist derzeit nicht bekannt.</ref>
* [https://wiki.debian.org/EFIStub …it is possible to load the kernel directly, without any additional bootloader]

== Fußnoten ==
<references />

[[Kategorie: Linux]]

BBEdit Einstellungen auf Standard nach Update

2023-09-04T08:41:12Z

PoC: reworked

Seitdem ''TextWrangler'' nicht mehr weiterentwickelt wird und stattdessen eine Light-Version von ''BBEdit'' dessen Funktion übernehmen soll, kommt es immer wieder vor, dass nach einem Upgrade via Appstore die '''Einstellungen von BBEdit wieder zurück auf Standard gesetzt werden'''. Ob dies einem Schluckauf der OS X Sandbox geschuldet ist, oder andere Ursachen hat, lässt sich nicht ohne weiteres feststellen.

Jedenfalls ist es ärgerlich, wenn die über längere Zeit etablierten Einstellungen plötzlich weg sind.

== Lokation ==
Die Einstelllungen selbst befinden sich in ''~/Library/Containers/com.barebones.bbedit/Data/Library/Preferences/com.barebones.bbedit.plist''. Diese Datei kann man sich recht einfach aus einem Timemachine-Backup zurückholen. Dummerweise sieht die Verzeichnisstruktur im Finder leicht anders aus. Dort ist es ''~/Library/Containers/BBEdit/Data/Library/Preferences/com.barebones.bbedit.plist''.

<s>Am Besten man öffnet sich via Terminal-Kommando den standardmäßig versteckten ''Library''-Ordner und hangelt sich via Finder-Fenster durch:
open ~/Library

Danach markiert man die Prefs-Datei, wählt im Time Machine Menü ''Time Machine öffnen'' und sucht sich einen hinreichend alten Stand raus, definitiv vor dem letzten Upgrade.</s>

Mit der Shell hangelt man sich dann durch das Time Machine Backup Volume (unterhalb ''/Volumes/'') und bis zum o. G. Ordner durch. Mittels <code>cp com.barebones.bbedit.plist ~/Library/Containers/com.barebones.bbedit/Data/Library/Preferences/</code> kopiert man den alten Stand.

Damit ist das Problem (temporär, bis zu wieder einem anderen Upgrade) gelöst.

[[Kategorie: Datensicherung]]
[[Kategorie: Mac OS X]]

Systemd bei Debian loswerden

2023-06-24T14:12:08Z

PoC: Versionstests, toten Link entfernt

'''Debian Jessie''' (8) (und neuer) bringt per Default ein neues Startsystem, mit: Systemd. Nach sorgfältiger Recherche und Abwägen des Für und Wider habe ich mich dazu entschlossen, meine Debian-Installationen ohne '''Systemd''' zu betreiben, sondern auf die nach wie vor unterstützte traditionelle Sysv-Umgebung zu setzen. Bei den Betrachtungen ist wichtig, dass es hier nicht um Desktopsysteme geht, sondern um Serverinstallationen.

Diese Anleitung wurde mit Debian Buster (10) verifiziert.

Mit Debian 12 (Bookworm) gibt es wohl neue Paketabhängigkeiten, weswegen diese Anleitung nicht mehr funktioniert.

== Gründe ==
Achtung, dies ist meine subjektive Betrachtungsweise!

* Systemd ist unübersichtlich, weil Systemd alles abdecken möchte, was derzeit von bekannten und gut funktionierenden Subsystemen abgedeckt wird:
** ''Init'' für Runlevelmanagement und Startvorgang,
** ''Udev'' für dynamische ''/dev''-Nodes und Netzwerkinterfaces,
** Ergänzung/Ablöse von ''(x)inetd'' zwecks Nachstarten von Prozessen,
** evtl. weiteres, was mir bisher nicht negativ aufgefallen ist.

Welche eigentlich netten und relevanten Features verlieren die Installationen durch den Verzicht?
* Den beeindruckend schnellen Startvorgang, u. A. durch Parallelisierung von Daemonstarts,
* Automatische Prozessisolation durch die Integration von ''cgroups'' in den Startvorgang.

Was gewinnt man durch den Verzicht?
* Eine bekannte, verlässliche und durch jahrelange Erfahrung gestützte Systemumgebung, die alte Hasen im Schlaf und zeitgleichem Vollsuff beherrschen; ein nicht zu unterschätzender Punkt für Serveradministratoren,
* deutlich näher dran an ''[https://en.wikipedia.org/wiki/Everything_is_a_file everything is a file]'',
* erprobtes Logging im ASCII-Format mit allen Vorteilen wie z. B. ''grep''.

== Vorgehensweise ==
apt-get install sysvinit-core systemd-shim bootlogd systemd-sysv-
reboot

Danach:
apt-get autoremove --purge systemd systemd-shim

Fertig.

Beim letzten ''apt-get''-Aufruf sollte geprüft werden, ob eventuell weitere Pakete deinstalliert werden, welche ''Systemd'' als Abhängigkeit besitzen. Bei Serverinstallationen dürfte dies in der Regel nicht der Fall sein.

== Siehe auch ==
* [[Debian-Upgrade auf Jessie ohne Systemd]]

== Weblinks ==
* [http://www.freedesktop.org/wiki/Software/systemd/ Systemd Projektseite] (en)
* [http://unix.stackexchange.com/questions/5877/what-are-the-pros-cons-of-upstart-and-systemd Darlegung von Für/Wider] bei Stackexchange (en)
* [http://0pointer.de/blog/projects/the-biggest-myths.html Mythen über Systemd] (en)
* [http://www.simonrichter.eu/blog/2016-03-03-why-sysvinit.html SimonRichter/ blog/ Why sysvinit?] (en)
* [https://unix.stackexchange.com/questions/218933/after-switching-to-devuan-how-do-i-remove-systemd After switching to Devuan, how do I remove systemd?] (en)

[[Kategorie:Linux]]

Apple TimeMachine Backup in Disk Image

2023-05-07T14:12:22Z

PoC: /* Siehe auch */ +Link

'''Apple TimeMachine''' ist ziemlich wählerisch, wohin es Backups macht. Ursprünglich sollte das eine lokal angehängte Disk sein, mit der man im Katastrophenfall starten und dann direkt auf das neue Speichermedium rücksichern kann.

Seit längerer Zeit beherrschen Macs das Starten via Internet bzw. den dort angeschlossenen Apple Servern — sofern man eine funktionierende Internetverbindung hat eine praktische Sache. Damit ist das Thema Starten für Restore vakant.

== Notwendige Schritte ==
Im Terminal:
* '''Lokales''' Backupimage anlegen. Angelegt wird das im aktuellen Verzeichnis. Im Regelfall ist das das Homeverzeichnis. Die Parameter sollten nach Notwendigkeit angepasst werden.
hdiutil create -size 500G -fs HFS+J -volname 'Backup Volume' Backupvolume.sparsebundle

* Mounten des Servervolumes (mit ''Cmd-K'') und Kopieren des Images via Finder.<blockquote>'''Achtung!''' Anlegen des Images direkt auf dem Server dauert erheblich länger und legt kein Sparsebundle an, sondern die Datei in voller Größe!</blockquote>Nach dem Kopieren kann die lokale Version gelöscht werden.

* Image auf dem Server doppelklicken (mounten).

* Timemachine via Kommandozeile im Terminal anweisen, das gemountete Volume zu benutzen. ''Sudo'' wird nach dem Passwort fragen!
sudo tmutil setdestination /Volumes/'Backup Volume'

In den TimeMachine Systemeinstellungen bzw. über die Menüleiste kann nun das erste Backup von Hand gestartet werden.

== Siehe auch ==
* [https://foliovision.com/2010/05/network-backup-apple-timemachine How to create a network backup with Apple’s TimeMachine], FolioVision
* [https://www.makeuseof.com/tag/turn-nas-windows-share-time-machine-backup/ Turn Your NAS Or Windows Share Into A Time Machine Backup], Makeuseof.com

[[Kategorie: Datensicherung]]
[[Kategorie: Mac OS X]]

AS/400 DNS-Server ohne OpNav

2023-01-23T15:52:10Z

PoC: Typo

Der '''DNS-Server''' von OS/400 kann offiziell nur via '''OpNav''' konfiguriert werden. Es geht aber auch anders…

OpNav ist ein Bestandteil von ClientAccess für Windows, was bei einer OS/400-Installation mit installiert wird. Bei alten OS/400-Versionen wird eine entsprechend alte ClientAccess-Version mitgeliefert, die unter aktuellen Windows-Versionen nicht oder nicht mehr sauber läuft. Erschwerend kommt hinzu, dass der SMB-Server dieser alten Versionen nicht mehr mit dem neueren Client-Code in neueren Windows-Versionen harmoniert — Zugriff leider nicht möglich. Somit bleibt nur FTP zum Datenaustausch.

== Konfiguration ==
Dns DNS von OS/400 V4R2 bis einschliesslich V4R5 basiert auf BIND 4.9.3 vom ISC. Somit gelten auch die Konfigurationsdirektiven unmittelbar. Beim Start wird nach der Hauptkonfiguratiosndatei ''/QIBM/USERDATA/OS400/DNS/BOOT'' gesucht. Diese kann man bequem selbst erstellen:

EDTF '/QIBM/USERDATA/OS400/DNS/BOOT'

Beispiel:
; Working Directory
directory /QIBM/USERDATA/OS400/DNS
; Root-DNS-File
cache . NAMED.ROOT
; Zone Statements
secondary myzone.com 192.168.1.11 db.myzone.com

''EDTF'' ist in der Bedienung sehr ähnlich zu ''SEU''. Alternativ kann man diese Datei auch woanders erstellen und im ASCII-Mode per FTP an die passende Stelle laden.

Es empfiehlt sich, eine aktuelle Rootzonen-Datei zu importieren. Diese erhält man z. B. bei [https://www.internic.net/domain/named.root Internic] und kann per FTP nach ''QDNS/QATOCDNSRV.ROOT'' als auch nach — wie in der entsprechenden Direktive angegeben — nach ''/QIBM/USERDATA/OS400/DNS/ROOT.HINT'' übertragen werden.<ref>Der BIND kann mit einer Datei in einer Library nichts anfangen.</ref>

Vor dem Start des DNS-Servers sollten die Verzeichnisrechte angepasst werden:
STRQSH CMD('CHOWN QTCP /QIBM/USERDATA/OS400/DNS')

Mit <code>CHGDNSA</code> kann der Autostart beim TCP-Start als auch der Debuglevel festgelegt und danach der Server mit <code>STRTCPSVR *DNS</code> gestartet werden.

Weniger erfreulich ist die Tatsache, dass sich beim Test des DNS als Secondary zu einem BIND 9.10.3 unter Debian Linux keine Sekundärzonen laden lassen. Der Primärserver schiebt die Zonen via AXFR raus, der Slave auf der AS/400 nimmt diese leider nicht an. Gemäß Job Log der AXFRs erwartet BIND mehr Datenbytes als er geliefert bekommt.

== Weblinks ==
* [http://www.cs.ait.ac.th/~on/O/oreilly/tcpip/dnsbind/ch04_03.htm Setting Up a BIND Configuration File], O'Reilly Books
* [https://www.redbooks.ibm.com/redbooks/pdfs/sg245147.pdf AS/400 TCP/IP Autoconfiguration: DNS and DHCP Support], IBM RedBooks

[[Kategorie: AS/400]]

Apple SNA•ps Konfiguration für 5250-Sitzungen

2023-01-07T02:31:29Z

PoC: mv => try-as400

Der Artikel ist in englischer Sprache im [https://try-as400.pocnet.net/wiki/Apple_SNA•ps AS/400-Wiki] abrufbar.

Die Pflege von Artikeln in zwei Sprachen ist mir zu aufwendig.

[[Kategorie: AS/400]]
[[Kategorie: Mac OS]]
[[Kategorie: Netzwerk]]

Apple SNA•ps Konfiguration für 5250-Sitzungen

2023-01-06T21:21:07Z

PoC: Gliederung

[[Datei:5250term.gif|thumb|right|5250 Clientverbindung via SNA•ps]]
[[Datei:Snagw-run.gif|thumb|right|SNA•ps Gateway Fenster]]
'''Apple SNA•ps''' ist eine Software, welche die Kommunikation von Apple Macs mit System 7.x mit IBM-Rechnersystemen ermöglicht. Die Kommunikation mit den Rechnern findet hierbei nicht wie heutzutage üblich über IP statt, sondern über Protokolle im Rahmen von '''SNA''' (Systems Network Architecture).<ref>Neuere Versionen vom SNA•ps 5250 Client unterstützen auch IP/tn5250 als Transportweg.</ref> 
Das Programmpaket wurde als Ergebnis einer erklärten Zusammenarbeit von IBM und Apple Anfang der 1990er Jahre von Orion Software programmiert.

SNA•ps gibt es zum einen als Gateway mit einer lizenzabhängigen Maximalanzahl von 8, 32 oder 64 [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture#Logical_Unit_.28LU.29 LU]-Sessions, zum anderen als Client für 5250-Terminal- und Druckservices als auch 3270-Terminalservices. Dieser Artikel konzentriert sich auf das Thema AS/400 bzw. 5250-Anbindung.

== Funktionsüberblick ==
Das SNA•ps Gateway macht Ressourcen, die vom Mainframe oder der AS/400 via [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture#Physical_Unit_.28PU.29 SNA PUs] bzw. [https://en.wikipedia.org/wiki/IBM_Advanced_Peer-to-Peer_Networking APPN]/[https://en.wikipedia.org/wiki/IBM_Advanced_Program-to-Program_Communication APPC] bereit gestellt werden, im AppleTalk-Netzwerk verfügbar und umgekehrt. Somit muss nicht in jeden Mac eine (teure) Karte zur Anbindung an das SNA-Netzwerk eingebaut werden, zumal das in manchen Fällen gar nicht möglich ist (kompakte Macs wie der Plus haben keine oder nur eingeschränkte Erweiterungsmöglichkeiten. Zudem ist ggfs. die notwendige Netzwerkverkabelung evtl. nicht vorhanden.) 
Beispiele für Clients sind die Terminalemulationen [https://en.wikipedia.org/wiki/IBM_3270 3270], [https://en.wikipedia.org/wiki/IBM_5250 5250]), die dem SNA•ps-Clientpaket beiliegen: Damit können Macs, die nur im [https://en.wikipedia.org/wiki/AppleTalk AppleTalk]-Netzwerk (z. B. via [https://en.wikipedia.org/wiki/LocalTalk LocalTalk]) verbunden sind, Terminalsitzungen zu den SNA-Hosts aufbauen. 
Ein Beispiel für die umgekehrte Richtung ist die Druckunterstützung. Der SNA•ps-Print Client emuliert einen IBM 8312-Drucker. Druckjobs, die von einer Druckerqueue auf dem Host dort hin versandt werden, können je nach dem über den in der [https://en.wikipedia.org/wiki/Chooser_(Mac_OS) Auswahl] voreingestellten Drucker gedruckt, oder als Text in eine Datei gesichert werden. Dies war ein Weg, den seinerzeit sehr teuren [https://en.wikipedia.org/wiki/LaserWriter Apple LaserWriter] auch für Großrechner nutzbar zu machen.

Das Gegenstück zum SNA•ps Gateway ist eine Systemerweiterung ''SNA•ps Access''. Die oben genannten Programme benutzen Routinen, welche diese Erweiterung zu Verfügung stellt. Das SNA•ps API kann somit auch von Drittanbietern genutzt werden. Ein Beispiel hierzu ist [https://en.wikipedia.org/wiki/Database_abstraction_layer DAL] für den Macintosh, welches verschiedene Protokolle für die Verbindung zur eigentlichen Datenbank benutzt; unter Anderem IP (via MacTCP) als auch SNA (via SNA•ps Access).

Für die AS/400 existierten in den 1990er Jahren auch LocalTalk-Zusatzkarten und eine Erweiterung für OS/400, um den AppleTalk-Stack auch auf der AS/400 zu implementieren. Die Implementation auf der AS/400 entsprach dem SNA•ps Gateway, so dass kein Mac als Gateway benötigt wurde: Die notwendige Software lief komplett auf der AS/400.

== Systemkompatibilität ==
Der SNA•ps 5250 Client benötigt zwingend System 7.0 oder höher. Unter System 6 erhält man eine entsprechende Meldung und der Client startet nicht. Der 3270-Terminalclient startet klaglos unter System 6.0.7.

Der Client funktioniert unter Systemen bis inkl. 8.1 und OpenTransport auf 68k-Macs. Er läuft nicht mehr auf PowerPC-Macs, der Start einer Verbindung lässt den Client mit einer ''unimplemented instruction'' abstürzen.

Eine Verbindung via TCP (möglich ab Client Version 1.1) provoziert bereits beim Verbindungsaufbau die Meldung, das Gegenüber könne kein 5250-Protokoll. Nachvollziehbar unter 7.6.1/OT/PPC als auch unter 7.1/MacTCP auf 68k.

Das Gateway selbst verlangt spezielle Hardware für die SNA-Netzwerkverbindung und ist daher eingeschränkt auf NuBus-Systeme.

== Transport ==
Folgende Verbindungsmöglichkeiten werden unterstützt:

{|class="wikitable"
! Phy
! Bemerkungen
|-
|SDLC
|Via Apple Serial NB-Karte
|-
|Token Ring
|Via Apple Token Ring 4/16 NB Karte
|-
|Twinax<ref>5250-Sitzungen über Twinax werden nicht unterstützt. Das hätte mal implementiert werden sollen, dazu kam es allerdings nicht mehr.</ref>
|Via Apple Koax/Twinax Karte
|}

Alle diese Karten haben als Besonderheit eine eigene 68000 CPU und lokalen Speicher und entsprechen der Macintosh Coprocessor Platform Spezifikation. Auf der Karte läuft ein kleiner Prozess, welcher über ''Message Passing'' mit dem Gegenstück ''A/ROSE'' im Mac OS kommuniziert und Daten austauscht.

Als Besonderheit läuft ein Teil der SNA•ps-Software auf dem Prozessor der jeweiligen Karte. Zusammen mit dem Rest der Software auf Mac OS-Seite werden APPC-Sitzungen in AppleTalk verpackt und können so auch anderen Macs im lokalen Netzwerk zu Verfügung gestellt werden. Auch über Netzwerkverbindungen, welche kein SNA unterstützen wie z. B. LocalTalk.

<gallery mode="packed">
Datei:Apple-Token-Ring-NB-Compside.jpg|Apple Token Ring 4/16 NB Karte, vorne
Datei:Apple-Token-Ring-NB-Solderside.jpg|Apple Token Ring 4/16 NB Karte, hinten
Datei:Apple-Coax-Twinax-Compside.jpg|Apple Coax/Twinax Karte, vorne
Datei:Apple-Coax-Twinax-Solderside.jpg|Apple Coax/Twinax Karte, hinten
</gallery>

== Konfiguration ==
[[File:Cfg-snaps.gif|thumb|right|183px|Übersicht des Konfigurationsfensters]]
Als Voraussetzung auf AS/400-Seite muss Autokonfiguration für Controller- und Gerätebeschreibungen erlaubt sein: Siehe dazu den Befehl WRKSYSVAL und die Variablen QAUTOCFG, QAUTORMT und QAUTOVRT. Ggfs. ist es sinnvoll, die Variablen QLMTDEVSSN und QLMTSECOFR anzupassen. Zudem wird eine funktionierende Token Ring-Verbindung vorausgesetzt. In der Leitungsbeschreibung muss der Parameter AUTOCRTCTL auf *YES stehen. Es wird empfohlen, den zugehörigen Parameter AUTODLTCTL auf *NONE zu setzen. 
Mit dieser Vorbereitung spart man sich die mühsame und fehlerträchtige Konfiguration von OS/400-Controller (*CTLD) und -Gerät (*DEVD) für die Kommunikation mit dem Gateway auf Mac-Seite.

Die Konfiguration wird mit dem Programm ''SNA•ps Config'' erstellt und schichtweise aufgebaut.

Es ist problemlos möglich, mehrere AS/400 in einem Konfigurationsdokument zu erfassen. Dazu müssen pro Maschine eigene Definitionen für
* TR Lines,
* Partners,
* Remote 6.2 LUs,
* Modes
erstellt werden. ''Local 6.2 LUs'' und ''TPs'' gelten für das gesamte Dokument.

Ist eine Maschine im APPN-Verbund als ''Network Node'' konfiguriert, genügt eine Verbindung vom Gateway zu jener Maschine. SNA-APPC Sitzungen werden dann von dort aus weitergeleitet. Es genügt dann, die entsprechenden LUs auf dem Gateway anzulegen.

=== Line ===
[[File:Cfg-line.gif|thumb|right|183px|Line-Konfiguration]]
Zuerst wird die ''Line''-Konfiguration erstellt. Der Name kann frei gewählt werden. Die Vergrößerung des ''Maximum I-Field Length''-Parameters erhöht den Datendurchsatz und somit die Geschwindigkeit mit welcher Daten durch das Gateway weitergereicht werden. Der höchste akzeptierte Wert ist 4105 Bytes. In der ''Line Description'' der AS/400 (was der Line-Konfiguration von SNA•ps entspricht) steht in aller Regel 16393 Bytes. Der tatsächlich verwendete Wert wird dynamisch ausgehandelt.

=== Partner ===
[[File:Cfg-peer.gif|thumb|right|183px|Partnerkonfiguration]]
Solange die erstellte ''Line'' markiert ist, kann im ''Partners''-Feld nebenan die Beschreibung für die eigentliche Netzwerkverbindung zur AS/400 definiert werden. Dabei gelten folgende Parallelen zur AS/400-Konfiguration:
{|class="wikitable"
!Partner-Parameter
!AS/400-Parameter
|-
|Name
|DSPNETA, Name des lokalen Kontrollpunkts (LCLCPNAME)
|-
|Link Address
|WRKLIND, Lokale Adapteradresse (der Token Ring Line) (ADPTADR)
|-
|Partner XID
|WRKLIND, Austausch-ID (der Token Ring Line) (EXCHID)
|-
|Gateway XID
|Selbst würfeln, muss mit 056 beginnen<ref>Dieser Wert wird beim ersten Start per Autokonfiguration auf die AS/400-seitige Controllerbeschreibung übernommen.</ref>
|-
|Gateway Network Name
|Selbst würfeln, ggfs. den Namen aus dem Kontrollfeld ''Gemeinschaftsfunktionen'' benutzen
|-
|Gateway Network Qualifier
|DSPNETA, Lokale Netzwerk-ID (LCLNETID)
|}

Die Charakteristik muss auf ''Peer (Node Type 2.1)'' gesetzt werden. Die ''SAP Address'' bleibt auf 4.

=== Local 6.2 LUs ===
[[File:Cfg-loclu.gif|thumb|right|183px|Lokale 6.2 LUs]]
{|class="wikitable"
!LU-Parameter
!AS/400-Parameter
|-
|Name: PASSTHRU (wird im Kontrollfeld SNA•ps… der Clients benutzt)
| 
|-
|Network LU Name = Gateway Network Name aus der Partner-Konfiguration
| 
|-
|Network Qualifier
|DSPNETA, Lokale Netzwerk-ID (LCLNETID)
|}

=== TPs ===
[[File:Cfg-tp.gif|thumb|right|183px|Transaction Points]]
Die eben definierte ''Local 6.2 LU'' muss markiert sein, damit ein neuer ''Transaction Point'' erstellt werden kann.
* Name: * (Sternchen)
* Network Name = DSPNETA, Lokale Netzwerk-ID der AS/400 (LCLNETID)

Rest belassen.

=== Remote 6.2 LUs ===
[[File:Cfg-remlu.gif|thumb|right|183px|Ferne 6.2 LUs]]
Der oben erstellte ''Partner'' muss markiert sein, damit eine zugehörige LU-Konfiguration erstellt werden kann.
* Name = Name des ''Partner''s
* Network LU name = Name des ''Partner''s
* Network Qualifier = DSPNETA, Lokale Netzwerk-ID der AS/400 (LCLNETID)

Rest belassen.

=== Modes ===
[[File:Cfg-mode.gif|thumb|right|183px|APLSNAPS-Modusbeschreibung]]
Die oben erstellte ''Remote 6.2 LU'' muss markiert sein, damit eine zugehörige Mode-Konfiguration erstellt werden kann.

Auf der AS/400 gibt es keine passende Modusbeschreibung. Man muss diese daher manuell anlegen:
CRTMODD MODD(APLSNAPS) COS(#CONNECT) MAXSSN(32) MAXCNV(32) LCLCTLSSN(0) INPACING(7) OUTPACING(7) TEXT('Für Apple SNA.ps')

Es kann passieren, dass das Gateway nicht startet, weil der Speicher (auf der Karte) nicht ausreicht. Dann empfiehlt es sich, mit ''wrkmodd'' anzupassen: MAXSSN und LCLCTLSSN zu reduzieren. Dies muss logischerweise auch in der SNA ps-Config nachgezogen werden.

== Aktivierung des Gateways ==
Nachdem die Konfiguration gesichert wurde, wird diese mit dem Programm ''SNA•ps Admin'' der vorhandenen physikalischen Verbindung zugeordnet. Pro SNA-fähiger Verbindungskarte wird im eingeblendeten Fenster ''Network Gateway Status'' eine Zeile angezeigt. Die gewünschte Zeile wird markiert und danach im Menü ''Gateway'' mit ''Select configuration…'' der oben erstellten Konfiguration zugeordnet. 
Im selben Menü wird empfohlen, über den Punkt ''Change Settings…''
* dem Gateway einen schöneren Namen zuzuordnen und
* alle Checkboxen bis auf ''Initially Log Line Trace'' unter ''Characteristics'' anzuknipsen.

Danach kann im Menü ''Gateway'' mit ''Start Gateway'' die Gatewaysoftware gestartet werden.

Es hat sich gezeigt, dass zumindest mit SNA•ps Version 1.1 das Ausprobieren von Konfigurationsinstellungen mit manuellem Stop und Start manchmal die Meldung provoziert, es wäre zu wenig Speicher vorhanden. Diese Aussage bezieht sich auf den lokalen Speicher auf der entsprechenden Netzwerkkarte. Anscheinend werden Ressourcen dort nicht zuverlässig überschrieben, nach einem Neustart des Rechners ist die Fehlermeldung weg.

Ebenfalls im Menü ''Gateway'' kann nun mit ''Show Gateway'' eine Übersicht über die vorhandenen Ressourcen angezeigt werden. Ein Beispiel ist im zweiten Screenshot ab Artikelbeginn zu sehen.

=== Screenshots ===
<gallery mode="nolines">
File:Stat-line.gif
File:Stat-peer.gif
File:Stat-loclu.gif
File:Stat-tp.gif
File:Stat-remlu.gif
File:Stat-mode-snasvcmg.gif
File:Stat-mode-aplsnaps.gif
File:Stat-sess-snasvcmg.gif
File:Stat-sess-aplsnaps.gif
</gallery>

== Client-Konfiguration SNA•ps 5250 ==
Im Kontrollfeld ''SNA•ps Access/5250'' kann in der ''Display Configuration'' auf ''Virtual Controller'' umgestellt werden. Der Controllername ist üblicherweise ''QPACTL01''.

[[Datei:Dft-connsel.gif|right|thumb|Modaler Dialog zur Auswahl einer Standardsitzung]]
Die Clientkonfiguration beschränkt sich auf die Auswahl der ''Default Connection'' im Menü ''Pref(erence)s''. Alternativ kann im Client die gewünschte Sitzung direkt konfiguriert werden (''Session'', ''Connection…'').

Danach wird im Menü ''Session'' mit dem Punkt ''Connect'' die Verbindung zum vorab ausgewählten SNA-Gateway hergestellt. Nach einigen Sekunden wird der AS/400 Signon-Screen angezeigt.

Nebenbei können dann auch noch weitere Parameter gesetzt werden: Größere Schriftart bei entsprechend großen Monitoren, alternative Tastenbelegungen für kleine Mac-Tastaturen (hier bietet sich der Zehnerblock an), usw. Die Einstellungen können in einem Verbindungsdokument gesichert werden. Beim Öffnen eines solchen Dokuments wird die Sitzung automatisch aufgebaut.

Alle weiteren Einstellungen können je nach Gusto vorgenommen werden.

== Client-Konfiguration SNA•ps Print ==
Der Print-Client ist nur in der Paketversion 1.0 enthalten. Damit können Druckjobs flexibel gehandhabt werden.

Im Kontrollfeld ''SNA•ps Access/5250'' muss in der ''Printer Configuration'', ''Printer Device List…'' ein Drucker konfiguriert werden. Dieser sollte auf der AS/400 nicht existieren, damit er mit den richtigen Parametern angelegt wird.

Nach dem Start von ''SNA•ps Print'' wird nach einem Dateinamen für die nun neu angelegte Druckerverbindung gefragt. Dieses Dokument entsprechend sichern.

Danach wird im Menü ''Session'' mit dem Punkt ''Connect'' die Verbindung zum vorab ausgewählten SNA-Gateway hergestellt. Die AS/400 legt eine Druckergerätedatei (*DEVD) und eine entsprechende Ausgabewarteschlange (*OUTQ) an. Alles was dort reingestellt wird, landet in der Druckroutine von SNA•ps Print.

Es wird ein IBM 3812 Model 1 Drucker (SCS) emuliert.

== Fehlerquellen ==
* Die Benutzung von ''Trawl'' auf dem Gatewayrechner selbst bringt u. U. AppleTalk ins Schleudern, sodass das Gateway nicht mehr im Managertool auftaucht. Dann hilft nur ein Reboot des Gateway-Rechners.

== Weblinks ==
* Wikipedia (en):
** [https://en.wikipedia.org/wiki/IBM_Systems_Network_Architecture IBM Systems Network Architecture]
** [https://en.wikipedia.org/wiki/IBM_Advanced_Program-to-Program_Communication IBM Advanced Program-to-Program Communication]
** [https://en.wikipedia.org/wiki/IBM_Advanced_Peer-to-Peer_Networking IBM Advanced Peer-to-Peer Networking]
** [https://en.wikipedia.org/wiki/Synchronous_Data_Link_Control Synchronous Data Link Control]
** [https://en.wikipedia.org/wiki/A/ROSE Apple Real-time Operating System Environment]
** [https://en.wikipedia.org/wiki/Message_passing Message Passing]
** [https://en.wikipedia.org/wiki/AppleTalk AppleTalk]
** [https://en.wikipedia.org/wiki/LocalTalk LocalTalk]
* [http://www.mactech.com/articles/develop/issue_04/coprocessor.html Inside The Macintosh Coprocessor Platform And A/ROSE]
* [https://www.computerwoche.de/a/terminalemulation-bindet-apple-welt-an-as-400-mac-user-haben-direkten-zugriff-auf-as-400-daten,1128406 Terminalemulation bindet Apple-Welt an AS/400], Computerwoche 1993-06-11
* [https://www.ibm.com/support/knowledgecenter/en/SSEQ5Y_5.9.0/com.ibm.pcomm.doc/books/html/admin_guide19.htm Administrator's Guide and Reference, SNA Client/Server Concepts], IBM
* [https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.znetwork/znetwork_6.htm Introduction to networking on the mainframe], IBM
* [https://web.archive.org/web/20181229140138/http://docwiki.cisco.com/wiki/IBM_Systems_Network_Architecture_Protocols IBM Systems Network Architecture Protocols], Cisco Docwiki (aus dem Archiv)

== Fußnoten ==
<references />

[[Kategorie: AS/400]]
[[Kategorie: Mac OS]]
[[Kategorie: Netzwerk]]

Datei:IPCS-285A.jpg

2023-01-05T18:18:59Z

PoC: +Kat

== Beschreibung ==
Zusatzkarte für den IPCS #2850 mit den eigentlichen Schnittstellen und Chipsatz.

[[Kategorie: AS/400]]