MosNis Installation/Servergrundeinrichtung

Achtung dieser Artikel ist noch in Arbeit und dient vorläufig nur als Vorlage. Dieser Beitrag zu Linux oder der Abschnitt ist in Bearbeitung. Weitere Informationen findest du hier. Der Ersteller arbeitet an dem Beitrag oder Abschnitt und entsorgt den Wartungsbaustein spätestens 3 Tage nach der letzten Bearbeitung. Änderungen außer Rechtschreibkorrekturen ohne Absprache mit dem Urspungsautor sind möglichst zu vermeiden, solange dieser Baustein noch innerhalb der genannten Frist aktiviert ist.

--TomcatMJ 03:26, 12. Sep 2006 (CEST)

Die Servergrundeinrichtung des MosNis:

Nachdem die Grundvorraussetzungen nun soweit geklärt sind, folgt die Grundeinrichtung des MosNis auf der dann aufbauend die Betriebsysteme zur späteren Installation auf den Clients im MosNis integriert werden.

xinetd-Servereinrichtung

Wenn der xinetd nicht bereits läuft, sollte das xinetd-Paket per Yast, Apt, Smart, Yum oder rpm -Uvh <paketname> installiert werden und über Yast im Runlevel-Editor für die Runlevel 3 und 5 aktiviert werden.

xinetd Aktivierung im Yast2 Runleveleditor

DHCP-Servereinrichtung

Für einen funktionsfähigen TFTP-Server benötigt man natürlich auch einen Server, der die benötigten Informationen den PXE-Bootclients bzw.Netboot/Etherboot-Clients zur Verfügung stellt. Dazu muss natürlich erst einmal ein solcher Server laufen. Aufgrund der heute üblichen Integration des BOOTP in DHCP entscheiden wir uns zur Installation des mit openSUSE mitgelieferten DHCP-Servers dhcpd, sofern noch kein DHCP-Server im lokalen Netzwerk läuft. Nach der Installation per Yast, Apt, Smart, Yum oder rpm- Uvh <paketname> aktivieren wir ihn im Runlevel-Editor von Yast für die Runlevel 3 und 5. Falls bisher noch kein DHCP-Server im Netzwerk lief und er nun gerade erst installiert wurde, wird natürlich noch eine Konfiguration benötigt. Dazu kann folgende Mustervorlage genutzt werden oder das DHCP-Serverkonfigurationsmodul in Yast2:

/etc/dhcpd.conf (stripped-down Version eines komplexen DHCP-Servers)

option resource-location-servers 192.168.2.1;
option www-server 192.168.2.1;
option domain-name-servers 192.168.2.1, 194.8.194.60;
option domain-name "meinnetz.homeip.net";
option all-subnets-local true;
option subnet-mask 255.255.255.0;
option routers 192.168.2.1;
option tftp-server-name "hauptserver.meinnetz.homeip.net";
filename "pxelinux.0";
next-server 192.168.2.1;
server-name "hauptserver.meinnetz.homeip.net";
authoritative;
default-lease-time 60000;
log-facility local7;
max-lease-time 72000;

# MEINNETZ LAN
subnet 192.168.2.0 netmask 255.255.255.0 {
  option broadcast-address 192.168.2.255;
  option subnet-mask 255.255.255.0;
  option domain-name "meinnetz.homeip.net";
  option domain-name-servers 192.168.2.1,194.8.194.60;
  option netbios-name-servers 192.168.2.1;
  option routers 192.168.2.1;
  option tftp-server-name "hauptserver.meeinnetz.homeip.net";
  filename "pxelinux.0";
  next-server 192.168.2.1;
  range 192.168.2.20 192.168.2.100;
  authoritative ;
  # PXE
  group {
        allow unknown-clients;
        filename "pxelinux.0";
        next-server 192.168.2.1;
        }
}

Wenn jedoch bereits ein DHCP-Server lief müssen wir folgende Ergänzungen in der /etc/dhcpd.conf hinzufügen, entweder im globalen Abschnitt oder nur für das gewünschte Subnet-Segment:

(Auszug aus der /etc/dhcpd.conf)

.
.
.
option tftp-server-name "hauptserver.meinnetz.homeip.net";
filename "pxelinux.0";
next-server 192.168.2.1;
.
.
.
# PXE
group {
        allow unknown-clients;
        filename "pxelinux.0";
        next-server 192.168.2.1;
        }
.
.
.

DNS-Servereinrichtung

Ein DNS-Server ist eigentlich immer eine gute Ergänzung zu einem DHCP-Server, jedoch ist er für dieses Projekt nicht unbedingt zwingend notwendig sofern man auf einen providerseitigen DNS-Server in der DHCP-Konfiguration verweisen kann oder den Debian-Netinstaller und die Windowsinstallationen nicht nutzen will, der Debian Netinstaller lädt nämlich per Default Dateien aus dem Internet nach sofern man keinen eigenen Mirror für die später dort benötigten Installationsdateien anlegt und Windows benötigt die Namensauflösung für „ntinstall“. In einer bereits vorhandenen DNS-Servereinrichtung reicht dazu ein CNAME-Eintrag, der den zuständigen SAMBA-Server unter dem namen "ntinstall" im Netzwerk bekanntmacht. Ein WINS-Server reicht hierzu nicht aus, da per PXE-Boot noch keine Netbios-Namensauflösung gegeben ist, die DNS-Auflösung des Namens jedoch bereits zugänglich ist.

TFTP-Servereinrichtung

Danach muss der TFTP-Server eingerichtet werden. Dazu installiert man das tftpd rpm-Paket per Yast, Apt, Smart, Yum oder mit rpm -Uvh <Paketname> über die Kommandozeile. Folgende Konfigurationsdatei richtet den TFTP-Server dann zur Nutzung mit Hilfe des xinetd ein:

/etc/xinet.d/tftp

# default: off
# description: tftp service is provided primarily for booting or when a \
# router need an upgrade. Most sites run this only on machines acting as
# "boot servers".
service tftp
{
        socket_type     = dgram
        protocol        = udp
        wait            = yes
        user            = root
        server          = /usr/sbin/in.tftpd
        server_args     =  -s /tftpboot/
        disable         = no
}

Um später von diesem Server per PXE-Client booten zu können wird natürlich erst einmal ein Bootloader benötigt, den der TFTP-Server den Clients liefern muss. Dazu installieren wir das Syslinux-Paket per Yast, Apt, Smart, Yum oder rpm -Uvh <Paketname> und kopieren die folgenden Dateien nach /tftpboot :

/usr/lib/syslinux/pxelinux.0 

Das Zeichen am Ende des Dateinamens ist eine Null,kein großes o.

/usr/lib/syslinux/memdisk

Man könnte auch pxegrub.0 aus dem Grub-Paket nehmen, jedoch ist pxelinux umgänglicher im Handling und ermöglicht über eine kleine Erweiterung nicht nur menügesteuerte Installation bzw. menügesteuertes Starten von Betriebsystemen bzw. Kerneln sondern mit einem kleinen Zusatz, der in den openSUSE Paketen offenbar leider vergessen wurde, das Ganze auch mit Untermenüs, und dies demnächst bei Bedarf sogar grafisch statt nur im Textmode. Zunächst wird hier jedoch die Textmode-Variante mit Untermenüs besprochen, da sich die VESA-Unterstützung zur Zeit noch im Pre-Alpha-Stadium befindet. Zu diesem Zwecke laden wir dazu noch den passenden Tarball von der Syslinux-Homepage herunter und kopieren uns aus diesem die Dateien menu.c32 für den Menüsupport und german.kbd für die Unterstützung deutscher Tastaturen nach /tftpboot .

NFS-Server Einrichtung

Als nächstes muss der NFS-Kerneldaemon eingerichtet werden sofern nicht bereits ein NFS-Server läuft. Das per Yast, Apt, Smart, Yum oder rpm -Uvh <paketname> zu installierende Paket wäre dann, sofern nicht bereits ein NFS-Server läuft, kernel-nfsd. Der Start des NFS-Servers wird durch aktivieren des NFS-Servers im Runleveleditor erledigt:

Danach benötigt man natürlich einen passenden Eintrag in /etc/exports um das Installationsquellverzeichnis im lokalen Netzwerk freizugeben. Sinnvollerweise legt man ein übergeordnetes Verzeichnis für alle anzulegenden Installationsquellen an, da man dann nicht jedes einzeln exportieren muss. Angelegt wird das Verzeichnis folgendermaßen:

mkdir /Installationsserver

Über die folgende Einstellung in /etc/exports exportiert man es dann optimalerweise als read-only NFS-Verzeichnis im asynchronen Übertragungsmodus:

/etc/exports

/Installserver/ *(ro,root_squash,async)

Die „async“ Option bewirkt den Verzicht auf Dateisystemsynchronisation und bringt erhebliche Geschwindigkeitsvorteile. Synchronisation wird eh nicht benötigt, da dieses Verzeichnis ohnehin nur als „Nur-Lese-Verzeichnis“ exportiert wird und keinerlei Schreibzugriff durch die Clients geplant ist.

FTP-Servergrundeinrichtung

Da manche Betriebsysteme NFS nicht als Installationsmedium akzeptieren, aber dafür FTP nutzen können, installieren wir einen FTP-Server sofern noch keiner läuft. Dazu installieren wir das vsftpd Paket per Yast, Apt, Smart, Yum oder per rpm -Uvh <Paketname>. Aus Performancegründen und um die Prozesslast auf dem Server niedrig zu halten betreiben wir den Server im Standalone Modus und nicht im Listen Modus. Die Betriebssysteminstallationen benötigen meistens anonymen FTP-Zugang. Wie man diesen und den Standalone Modus für den vsftpd aktiviert ist nachzulesen in der vsftpd Konfigurationsanleitung. Aus Gründen der Platzersparnis und da Symlinks eventuell in der FTP-Serverkonfiguration nicht erlaubt sind, wird das bereits im NFS-Abschnitt angelegte Installationsserververzeichnis mit folgendem Eintrag in der /etc/fstab einfach durch erneutes mounten mit der Option bind in das normale FTP-Serververzeichnis wiederverwendet. Dabei ist darauf zu achten, daß anonymer Lesezugriff in den Dateirechten ermöglicht bleibt, da es sonst massive Probleme bei den späteren Systeminstallationen geben kann.

Auszug aus der /etc/fstab :

/Installserver/   /srv/ftp//Installserver/        auto    bind 1 1

HTTP-Servergrundeinrichtung

Wie im Abschnitt FTP-Servergrundeinrichtung nutzen wir auch hier die Möglichkeit Verzeichnisse erneut per Mountbefehl bzw. Eintrag in der /etc/fstab an anderer Stelle im Dateisystem nochmals einzufügen.

Auszug aus der /etc/fstab :

/Installserver/   /srv/www/htdocs//Installserver/ auto    bind 1 1

Samba-Servergrundeinrichtung

Da einige Betriebssysteme auch die Installation über SMB/CIFS Server ermöglichen oder im Falle von Windows diese als einzige Netzwerkinstallationsquellenoption gut unterstützen, nutzen wir diese Option natürlich auch für unseren Installationsserver. Dazu legen wir ein Share an, welches anonym über den Benutzer „guest“ mit Passwort „guest“ zugänglich sein muss. Für Windows sollte dieses Share dann als Laufwerk Z: im System eingebunden werden damit die Installation über das Netzwerk funktioniert. Wie ein Samba-Server generell eingerichtet wird ist dem Samba-HowTo zu entnehmen. Der Abschnitt für das benötigte Share sieht dann folgendermaßen aus:

Auszug aus der /etc/samba/smb.conf :

SLP-Servergrundeinrichtung

Da eventuell Software später nachinstalliert werden soll und einige Betriebssysteme die automatische Erkennung von Softwareinstallationsquellen per ServerLocationProtocol, kurz SLP, unterstützen, setzen wir dies ebenso für spätere Nutzung ein. Dazu muss nur der entsprechend angebotene Dienst dem SLP-Server, in diesem Fall OpenSLP, der per Yast, APT, Smart, Yum oder rpm -Uvh <Paketname> nachzuinstallieren und im Runlevel-Editor dann für die Runlevel 3 und 5 zu aktivieren ist, bekannt gemacht werden. Dies geschieht über Registrierungsdateien im Verzeichnis /etc/slpd.reg.d Als Muster dafür hier die Installationsquellendeklarationsdateien für openSUSE 10.1 und NFS Nutzung :

/etc/slp.reg.d/YaST-Installationsserver-i586.reg

service:install.suse:nfs://192.168.2.1/Installserver/openSUSE/10.1/32Bit,de,65535 
defaultbase=i586
description=SUSE Linux 10.1 ++SUSE-Linux-10.1-DVD-i586++  #1
label=SUSE Linux 10.1
machine=i386,i486,i586,i686,x86_64
vendor=SUSE LINUX Products GmbH, Nuernberg, Germany

/etc/slp.reg.d/YaST-Installationsserver-x86-64.reg

service:install.suse:nfs://192.168.2.1/Installserver/openSUSE/10.1/64Bit,en,65535
defaultbase=x86_64
description=SUSE Linux 10.1 ++SUSE-Linux-10.1-DVD-x86_64++  #1
label=SUSE Linux 10.1
machine=i386,i486,i586,i686,x86_64
vendor=SUSE LINUX Products GmbH, Nuernberg, Germany

Die Servergrundeinrichtung ist damit dann fertig.