Server/ryoko: Unterschied zwischen den Versionen
Lars (Diskussion | Beiträge) (Überschriften neu sortiert; Aufgaben hinzugefügt; Netzwerkinterfaces hinzugefügt) |
Lars (Diskussion | Beiträge) (Serverliste) |
||
Zeile 37: | Zeile 37: | ||
= Netzwerk = | = Netzwerk = | ||
[[Datei:ryoko-Netzwerkbuchsen.svg|mini|Netzwerkbuchsen in [[Server/ryoko]] (dia-Quelle: [[Datei:ryoko-Netzwerkbuchsen.dia]])]]. | [[Datei:ryoko-Netzwerkbuchsen.svg|mini|Netzwerkbuchsen in [[Server/ryoko]] (dia-Quelle: [[Datei:ryoko-Netzwerkbuchsen.dia]])]]. | ||
− | |||
Die vier Netzwerkbuchsen sind mit dem Hausswitch verbunden. | Die vier Netzwerkbuchsen sind mit dem Hausswitch verbunden. | ||
Zeile 56: | Zeile 55: | ||
|} | |} | ||
− | = | + | = Virtuelle Hosts = |
+ | Virtuelle Hosts, die bereits auf der [[Server]]-Seite dokumentiert wurden, sollten hier lediglich einen Verweis darauf enthalten. | ||
+ | {| {{Prettytable}} | ||
+ | ! Hostname | ||
+ | ! IP | ||
+ | ! Verantwortlicher | ||
+ | ! Verwendung | ||
+ | |- | ||
+ | | ap2-155 || 192.168.2.155 || Lars || Test-AP für Firmware-Entwicklung (Rolle: Nutzer-Tunnel) | ||
+ | |- | ||
+ | | ap2-156 || 192.168.2.156 || Lars || Test-AP für Firmware-Entwicklung (Rolle: UGW) | ||
+ | |- | ||
+ | | fastd ||colspan="3"| siehe [[Server]] | ||
+ | |- | ||
+ | | gateway || 192.168.2.201 || oyla || UGW mit Standard-Firmware | ||
+ | |- | ||
+ | | kinjo ||colspan="3"| siehe [[Server]] | ||
+ | |- | ||
+ | | ks || 172.23.12.106 || oyla || Backup-Server für Kunstschule | ||
+ | |} | ||
== Virtuellen Host anlegen oder löschen == | == Virtuellen Host anlegen oder löschen == |
Version vom 4. Juli 2015, 21:11 Uhr
Inhaltsverzeichnis |
Technische Daten
Name | ryoko |
---|---|
Hardware | HP DL360 G7 |
Betriebsystem | Debian 8 Jessie |
Anbindung | |
IP / DNS | 192.168.10.10 / ryoko.on dynamisch am Friedanetz |
Ausstattung | 6 GB RAM 6x300 GB HDD (SAS) |
Dienste | KVM Virtualisierung |
Backup |
Verantwortlichkeiten
- Zugang/Hosting: oyla
- Administration: oyla, lars, ?
Status
ryoko ist noch im Aufbau
Netzwerk
.Die vier Netzwerkbuchsen sind mit dem Hausswitch verbunden.
Interface | IP | Haus-Anbindung | Verwendung |
---|---|---|---|
eth0 | - | Opennet-VLAN | - |
eth1 | 192.168.10.10/16 | Opennet-VLAN | olsr-Bridge für Server/ryoko und virtuelle Hosts |
eth2 | - | Router-Uplink-VLAN | - |
eth3 | 172.23.12.120/24 | Router-Uplink-VLAN | Bridge für Internet-Uplink von Server/ryoko und virtuellen Hosts (DHCP) |
Virtuelle Hosts
Virtuelle Hosts, die bereits auf der Server-Seite dokumentiert wurden, sollten hier lediglich einen Verweis darauf enthalten.
Hostname | IP | Verantwortlicher | Verwendung |
---|---|---|---|
ap2-155 | 192.168.2.155 | Lars | Test-AP für Firmware-Entwicklung (Rolle: Nutzer-Tunnel) |
ap2-156 | 192.168.2.156 | Lars | Test-AP für Firmware-Entwicklung (Rolle: UGW) |
fastd | siehe Server | ||
gateway | 192.168.2.201 | oyla | UGW mit Standard-Firmware |
kinjo | siehe Server | ||
ks | 172.23.12.106 | oyla | Backup-Server für Kunstschule |
Virtuellen Host anlegen oder löschen
Das Skript /root/bin/vhost-admin.sh dient zur vereinfachten Erzeugung und Löschung virtueller Hosts. Folgende Aktionen stehen aktuell zur Verfügung:
-
vhost-admin.sh create-debian foo 192.168.5.23
- ein Debian-basiertes System wird via debootstrap auf einem LVM-Volume vorbereitet
- Netzwerk wird vorkonfiguriert:
- eth0: oben angegebene IP-Adresse (Bridge ins opennet-VLAN in der Frieda)
- die IP muss zuvor unter Server reserviert werden
- eth1: DHCP-Client (Bridge ins Router-VLAN in der Frieda)
- olsrd: automatischer Start für eth0
- eth0: oben angegebene IP-Adresse (Bridge ins opennet-VLAN in der Frieda)
- root-Schlüssel von Server/ryoko wird importiert
- der Hostname (foo) wird für die Namen der LVM-Volumes und des libvirt-Hosts verwendet
-
vhost-admin.sh create-ap ap1-23 192.168.1.23
- ein openwrt-basiertes System wird mittels eines herunterzuladenden Images vorbereitet
- ein LVM-Image wird als Datenträger erzeugt
- das openwrt-Image sollte vom Type x86-combined-squashfs sein (z.B. [[1]])
- lokale Dateien können via
file://DATEINAME
referenziert werden (sieheman curl
)
- lokale Dateien können via
- das Skript konfiguriert die Netzwerk-Interfaces des AP entsprechend der eingebundenen Hausnetze (eth0: olsr-Mesh, kein LAN)
- nach dem Starten des virtuellen Hosts (
virsh start ap1-23
) ist er unter der gewählten IP in der gesamten OLSR-Wolke erreichbar- die IP muss zuvor unter Opennet_Nodes reserviert werden
-
vhost-admin.sh remove ap1-23
- das virtuelle System (debian- oder openwrt-basiert) wird gestoppt und inklusive der LVM-Images ohne Nachfrage gelöscht
Neue virtuelle Hosts können anschließend via virsh start foo
gestartet werden.
Virtuellen Hosts: starten / stoppen / Überblick
- Starten:
virsh start HOSTNAME
- Stoppen:
virsh shutdown HOSTNAME
- Automatisch bei jedem Booten starten:
virsh autoload HOSTNAME
- dies erzeugt Symlinks der Host-Definitionen nach
/etc/libvirt/qemu/autostart
- dies erzeugt Symlinks der Host-Definitionen nach
- aktuell laufende Hosts:
virsh list
- Konfiguration eines Hosts ändern:
virsh edit HOSTNAME
- alternativ: auf dem eigenen Rechner virt-manager installieren und mit Server/ryoko verbinden
Zugriff auf virtuelle Hosts via Konsole
Der Zugriff via Konsole ist nur für openwrt-Hosts spontan verfügbar. Bei Debian-basierten Hosts muss die Konsole via Kernel-Boot-Parameter explizit aktiviert werden.
-
virsh console ap1-23
- anschließend
Enter
drücken, um die passwortfreie Konsole zu eröffnen - Abbruch der Konsole:
STRG-ALT-]
(schließende eckige Klammer)
- anschließend
Zugriff auf virtuelle Hosts via VNC (grafisch)
Der Zugriff via VNC ist sowohl für Debian-basierte, als auch für openwrt-basierte Hosts spontan verfügbar.
- Konsole ermitteln:
ss -lpn | grep qemu
- anhand der Monitor-Sockets den passenden Prozess identifizieren
- den vnc-Port (5900 + ?) dieses Prozesses ermitteln
- die Differenz zu 5900 ist die vnc-Screen-Nummer
- Verbindung aufbauen:
vncviewer -via ryoko :7
Viel komfortabler ist die lokale Installation von virt-manager auf dem eigenen Rechner. Dieses Programm kann sich mit verschiedenen entfernten Virtualisierungsservern bei Bedarf verbinden und auch die VNC-Verbindung komfortabel aufbauen.
Offene Aufgaben
- Hardware-RAID-Controller entfernen
- aktuell fehlt uns (wahrscheinlich aufgrund des zwischengeschalteten Controllers) hotplug und smartcontrol
- Prüfen, ob/wie sich eth0 und eth2 an einen virtuellen Server ohne Bridge weiterreichen lassen