Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- invis_server_wiki:installation:basesetup-160 [2026/02/16 07:57]
flacco [Letzte Vorbereitungen]
+++ invis_server_wiki:installation:basesetup-160 [2026/04/02 12:14] (aktuell)
flacco [Letzte Vorbereitungen]
@@ Zeile 5: / Zeile 5: @@
 Zur Installation eines invis-Servers ab Version 16.0 wird ein [[https://software.opensuse.org/distributions/leap | openSUSE Leap 16.x]] vorausgesetzt.
+Einer der Unterschiede zu früheren Leap Versionen ist, dass sich ab 16.0 der Benutzer **root** per default nicht mehr per SSH am System anmelden kann. Daher wird empfohlen während des Setups einen lokalen Benutzer anzulegen der dann per //**su**// oder //**sudo**// arbeitet.
 ===== Software Auswahl =====
@@ Zeile 15: / Zeile 16: @@
 Gerade im Hinblick auf das Datenträger-Management lässt Agama einiges zu Wünschen übrig. Dumm für die Server-Installation, Agama kann nicht mit Linux Software-RAID umgehen. Allerdings werden fertige RAID-Verbünde als Festplatten erkannt. Daraus folgt, dass ein SW-RAID gestütztes Setup mit Agama nur funktioniert, wenn der oder die RAID-Verbünde bereits zuvor via Kommandozeile in einem Rettungssystem oder einem Terminal des unter Agama laufenden Installationssystem erstellt wird.
+//**Hinweis:** Im Rettungssystem ist das Tastatur-Layout auf eine amerikanische Umgebung gesetzt. Dies lässt sich mit dem Kommando **loadkeys de** auf ein deutsches Layout ändern.//
 Dem Festplattenmanagement sollten Sie besondere Aufmerksamkeit widmen, schließlich geht es um sinnvolle Nutzung Ihres Plattenplatzes, der Sicherheit Ihrer Daten und der Wartbarkeit des Servers. Wir erläutern das Management beispielhaft anhand eines von uns in der Praxis meist genutzten Setups.
@@ Zeile 51: / Zeile 54: @@
 linux:~ # mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda2 /dev/sdb2
 </code>
+Leider ignoriert **agama** feste Größenangaben zu erstellender LVM-Volumes, statt dessen nutzt er den gesamten Platz des physical Volumes aus und vergrößert alle anzulegenden Volumes im Verhältnis der getätigten Größenangabe, was ziemlicher Schwachsinn ist. Wenn die einzelnen Volumes mit dem Dateisystem **ext4** formatiert wurden ist es möglich sowohl die Dateisysteme als auch die Volumes nachträglich wieder zu verkleinern. Das funktioniert nur wenn die Dateisysteme **nicht** eingehängt sind, also im Falle eines var-Volumes nur aus einem Rescue-System heraus. Das ganze funktioniert wie folgt. Zunächst erfolgt der umount:
+<code>
+invis:~ # umount /dev/system/srv
+</code>
+Danach muss das Dateisystem zwingend überprüft werden:
+<code>
+invis:~# e2fsck -f /dev/system/srv
+</code>
+Jetzt kann zunächst das Dateisystem verkleinert werden, im Beispiel auf 100GiB:
+<code>
+invis:~# resize2fs /dev/system/srv 100G
+</code>
+Anschließend wird das Volume passend dazu verleinert:
+<code>
+invis:~# lvresize -L 100G /dev/system/srv
+</code>
+Danach kann das Volume wieder eingehängt werden. Am einfachsten mit:
+<code>
+invis:~# mount -a
+</code>
+//**Achtung:** Das Dateisystem **XFS** lässt sich nicht  verkleinern.//
+Wird das Verkleinern in einem Rescue-System vorgenommen sind zunächst MD-RAID-Verbünde und auch darauf befindliche Logical-Volumes inaktiv. Beides muss erst aktiviert werden. Zunächst der RAID-Verbund mit:
+<code>
+invis:~ # mdadm --assemle --scan
+</code>
+Dann sind die betreffenden Volumes zu aktivieren, hier am Beispiel des var-Volumes:
+<code>
+invis:~ # lvchange -ay /dev/system/var
+</code>
+Danach wird verfahren wie zuvor gezeigt.
 ===== Letzte Vorbereitungen =====
@@ Zeile 85: / Zeile 135: @@
 <code>
 linux:~ # zypper ref
-linux:~ # zypper in invisAD-setup-16 (vorerst noch -15)
+linux:~ # zypper in invisAD-setup-16
 </code>
@@ Zeile 94: / Zeile 144: @@
 ===== Netzwerkkonfiguration =====
+Durch den Wegfall von YaST mit Leap 16 hat sich hier einiges geändert. Auch "wicked" als Dienst zum Management der Netzwerkschnittstellen ist nicht mehr Teil von openSUSE Leap. openSUSE Leap setzt zunächst voll und ganz auf den Networkmanager. Dieser spielt seine Stärken vor allem auf Desktop-Installationen aus, da es damit normalen Usern ohne administrative Rechte gestattet ist beispielsweise einen WLAN-Zugriff zu konfigurieren. Für Server-Installationen ohne grafische Oberfläche ist er unserer Meinung nach eher nicht geeignet. Daher ersetzen wir ab invis-Server 16, den Networkmanager, respektive "wicked" durch "systemd-networkd", eine Komponente des Systemd, wie unschwer am Namen zu erkennen ist.
+Der Wechsel erfolgt automatisch mit dem Ausführen des Scripts **//netsetup//**.
+Unverändert bleibt, dass beim invis-Server die einzelnen Netzwerkschnittstellen entsprechend Ihrer Verbindung, bzw. Firewall-Zone benannt werden.
+Um die Benennung der Netzwerkschnittstellen mit den einzelnen Firewall-Zonen eines invis-Servers in Verbindung zu bringen, werden die Namen der Netzwerkschnittstellen auf Basis von udev-Regeln vergeben. Auch die Benennung der im Laufe des Setups einzurichtenden VPN-Schnittstelle wird ein entsprechender Name gegeben:
+^  Vom System vergebener Gerätename  ^  Aktueller Name  ^
+|  eth0 oder enpXsY                |  extern          |
+|  eth1 oder enpXsY                 |  intern          |
+|  //eth2 oder enpXsY//             |  //dmz//         |
+|  tun1                 |  vpn             |
+Die erste Netzwerkkarte des Systems (extern) stellt die Verbindung des Servers mit dem Internet her - entspricht somit der externen Zone Ihrer Firewall.
+Je nach dem, wie der dem invis-Server vorgeschaltete Router konfiguriert ist, müssen Sie "extern" als DHCP-Client oder gemäß den Vorgaben Ihres Providers Konfigurieren.
+Die zweite Netzwerkkarte (intern) muss mit einer festen IP-Adresse versehen werden. Selbst, wenn über den Internet-Service-Provider eine feste IP-Adresse zur Verfügung steht, ist für das interne Netz die Verwendung eines eigenen Netzes zwingend.
+Falls mehr als zwei Netzwerkschnittstellen vorhanden sind, wird die dritte Schnittstelle in **dmz** umbenannt, auch wenn das invis-Server Setup dies (derzeit) in keiner Weise nutzt.
+Die Erstellung der UDEV-Regeln wird mittels unseres Script **//netsetup//** erledigt, aufgerufen wird es ohne weitere Parameter:
+<code>
+localhost:~ # netsetup
+localhost:~ # reboot
+</code>
+Im Anschluss an dessen Ausführung muss das System neu gestartet werden. **//netsetup//** sorgt automatisch dafür, dass die externe Schnittstelle versucht sich eine IP-Adresse per DHCP zu besorgen. Wenn alles gut geht, ist der Server also nach dem Reboot per **SSH** erreichbar.
+Die Konfiguration der internen oder weiterer Schnittstellen erfolgt mittels des neuen Scripts **//netdevconf//**.
+//**Achtung: Vermeiden Sie es Ihrem lokalen Netzwerk typisch Adressbereiche gängiger Router-Modelle wie auch üblicher Docker Konfigurationen zu verpassen. Hier ein paar Beispiele von denen Sie die Finger lassen sollten:**//
+^  typische IP Netze gängiger Router und Docker-Installationen  ^
+|  192.168.0.0/24                     |
+|  192.168.1.0/24                     |
+|  192.168.2.0/24                     |
+|  192.168.50.0/24                    |
+|  192.168.100.0/24                   |
+|  192.168.177.0/24                   |
+|  192.168.178.0/24                   |
+|  192.168.188.0/24                   |
+|  172.16 - 24.0.0/16                 |
+//**Achtung:** Bevor Sie jetzt die Netzwerkschnittstellen Ihres invis-Servers konfigurieren ein Hinweis dazu. invis-Server können lediglich mit 16 und 24 Bit breiten Netzwerkmasken also „255.255.0.0“ (/16) und „255.255.255.0“ (/24) umgehen.//
+Idealerweise konfigurieren Sie für die interne Netzwerkschnittstelle ein privates IP-Netzwerk der Klassen „B“ (172.16.0.0 bis 172.31.255.255) oder „C“ (192.168.0.0 bis 192.168.255.255). Über die Unterstützung von Klasse „A“ Netzen denken wir noch nach, erachten dies aber nicht wirklich als notwendig für „kleine“ Netze.
+**//netdevconf//** erfordert als Aufrufparameter zunächst den Namen der Schnittstelle und dann die gewünschte IP-Adresse nebst Netzwerkmaske in Kurzschreibweise:
+<code>
+localhost:~ # netdevconf intern 172.26.0.10/16
+</code>
+Wir unterteilen die Netze der beiden unterstützten Netzwerkklassen für den DHCP-Server in verschiedene Bereiche (Damit ist **kein** Subnetting gemeint). Die nachfolgende Tabelle zeigt die verschiedenen Bereiche, angezeigt wird jeweils nur der Host-Anteil der IP-Adressen.
+^  Geräteklasse  ^  Klasse C Netz  ^  Klasse B Netz  ^
+^  Server  |  .11 - .19  |  .0.11 - .0.253  |
+^  Drucker  |  .20 - .50  |  .1.1 - .1.254  |
+^  IP-Geräte  |  .60 - .90  |  .2.1 - .3.254  |
+^  PCs  |  .120 - .199  |  .4.1 - .4.254  |
+^  dyn. Bereich  |  .200 - .220  |  .200.1 - .200.254  |
+Anders als früher mit YaST wird der Hostname zu diesem Zeitpunkt noch nicht konfiguriert. Dies ist in das nachfolgende Setup mit //**sine2**// gewandert.
+//**Achtung:** Ab openSUSE Leap 16.0 hat Leap das Security-Framework gewechselt. Es kommt jetzt SELinux anstelle von AppArmor zum Einsatz. Wir arbeiten daran unser invis-Server Setup kompatibel mit SELinux zu gestalten. Das ist allerdings nicht ganz so trivial. Wir empfehlen daher vorübergehend SELinux von **enforcing** auf **permissive** umzustellen.//
+Die Einstellung wird in <file>/etc/selinux/config</file> vorgenommen:
+<code>
+...
+SELINUX=permissive
+...
+</code>
+Damit ist die Vorarbeit abgeschlossen, weiter geht'S mit //**sine2**// und dem eigentlichen Server-Setup.