Server/ryoko: Unterschied zwischen den Versionen
ehem. Sonderlösung Frieda Bürorouter entfernt |
Lars (Diskussion | Beiträge) Dokumentation des vhost-admin-Skripts nach "Server_Installation/vhost-admin" verschoben |
||
| Zeile 21: | Zeile 21: | ||
|- |
|- |
||
| '''Dienste''' |
| '''Dienste''' |
||
|KVM Virtualisierung |
|[[Server Installation/KVM|KVM Virtualisierung]] |
||
|- |
|- |
||
| '''Backup''' |
| '''Backup''' |
||
| Zeile 104: | Zeile 104: | ||
|} |
|} |
||
== Anlegen oder Löschen == |
== Anlegen oder Löschen von VMs == |
||
Siehe [[Server_Installation/vhost-admin|vhost-admin]]-Skript. |
|||
Das Skript ''/root/bin/vhost-admin.sh'' dient zur vereinfachten Erzeugung und Löschung virtueller Hosts. |
|||
=== Debian-Host anlegen === |
|||
<code>vhost-admin.sh create-debian foo 192.168.5.23</code> |
|||
* 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 |
|||
* root-Schlüssel von [[Server/ryoko]] wird importiert |
|||
* der Hostname (''foo'') wird für die Namen der LVM-Volumes und des libvirt-Hosts verwendet |
|||
=== OpenWRT-Host anlegen === |
|||
<code>vhost-admin.sh create-ap ap1-23 192.168.1.23</code> |
|||
** ein openwrt-basiertes System wird mittels eines herunterzuladenden Images vorbereitet |
|||
*** das Image kann auch als Firmware-Release-Version angegeben werden (z.B. ''0.4.5'') |
|||
** ein LVM-Image wird als Datenträger erzeugt |
|||
** das openwrt-Image sollte vom Type ''x86-combined-squashfs'' sein (z.B. [[http://downloads.opennet-initiative.de/openwrt/stable/0.5.1/x86/openwrt-x86-generic-combined-squashfs.img.gz]]) |
|||
*** lokale Dateien können via <code>file://DATEINAME</code> referenziert werden (siehe <code>man curl</code>) |
|||
** das Skript konfiguriert die Netzwerk-Interfaces des AP entsprechend der eingebundenen Hausnetze (eth0: olsr-Mesh, kein LAN) |
|||
** nach dem Starten des virtuellen Hosts (<code>virsh start ap1-23</code>) ist er unter der gewählten IP in der gesamten OLSR-Wolke erreichbar |
|||
*** die IP muss zuvor unter [[Opennet_Nodes]] reserviert werden |
|||
=== Host löschen === |
|||
<code>vhost-admin.sh remove ap1-23</code> |
|||
** das virtuelle System (debian- oder openwrt-basiert) wird gestoppt und inklusive der LVM-Images ohne Nachfrage gelöscht |
|||
== Verwaltung == |
|||
Siehe dazu [[Server Installation/KVM]]. |
|||
= Besonderheiten = |
= Besonderheiten = |
||
Version vom 7. Mai 2017, 12:11 Uhr
Technische Daten
| Name | ryoko |
|---|---|
| Hardware | HP DL360 G7 (2010) |
| Betriebsystem | Debian Linux |
| Anbindung | 1000 MBit/s (Hausnetz, Frieda23) 50/10 MBit/s (down/up) (DSL, dynamische IP, NAT) |
| IP / DNS | 192.168.10.10 - ryoko.on (Opennet IPv4, eth1) 192.168.20.10 - ryoko-if2.on (Opennet IPv4, intern, br-mesh) DHCP via Frieda-Hausnetz (eth2) |
| Ausstattung | 6 GB RAM 6x300 GB HDD (SAS) |
| Dienste | KVM Virtualisierung |
| Backup |
Verantwortlichkeiten
- Zugang/Hosting: oyla
- Administration: oyla, lars, ?
Status
ryoko ist aktiv in Nutzung.
Netzwerk

Die vier Netzwerkbuchsen sind mit dem Hausswitch verbunden. Zwei davon liegen im Opennet-VLAN (olsr) und zwei sind im Router-VLAN des Hauses (Uplink ins Internet).
| Interface | IP | Haus-Anbindung | Verwendung |
|---|---|---|---|
| eth0 | - | Opennet-VLAN | exklusiv für das virtualisierte Frieda-UGW (AP2.209) |
| eth1 | 192.168.10.10/16 | Opennet-VLAN | olsr-Anbindung an die anderen Haus-APs |
| eth2 | - | Router-Uplink-VLAN | exklusiv für das virtualisierte Frieda-UGW (AP2.209) |
| eth3 | - | Router-Uplink-VLAN | Teil von br-internet |
| br-mesh | 192.168.10.20/16 | nicht verbunden | interne olsr-Bridge für die virtuellen Hosts |
| br-internet | 172.23.12.120/24 | - | Bridge für Internet-Uplink von Server/ryoko und virtuelle Hosts (DHCP) |
| br-hotspot | - | - | Bridge für Tests der Funktionalität von Captive-Portal-APs |
Virtuelle Hosts
Die folgende Struktur ist die Voreinstellung beim Erzeugen eines virtuellen Hosts - die konkrete Konfiguration kann natürlich geändert werden.
Das jeweils erste Netzwerk-Interface eines virtuellen Hosts ist mit einer internen Bridge verbunden und wird für olsr-Routing verwendet. Diese Bridge ist nicht direkt mit dem Opennet-VLAN im Haus verbunden. Somit ist die olsr-Wolke der virtualisierten olsr-Hosts von der olsr-Wolke der Vereins-APs in der Frieda23 durch einen Hop getrennt. Dies reduziert den olsr-Broadcast-Verkehr und spiegelt die physische Struktur wieder.
Das jeweils zweite Netzwerk-Interface eines virtualisierten Hosts ist mittels einer Bridge mit dem Hausnetz verbunden (Internetzugang, DHCP).
Der Frieda-UGW (AP2.209) ist nicht über die obigen Bridges angebunden, sondern verfügt über exklusiven Zugriff auf einen der olsr- und einen der Router-Ports.
Virtuelle Hosts
Die Hosts werden via libvirt verwaltet und verwenden LVM-basierte Images als Datenträger.
Host-Liste
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 / Captive-Portal) |
| ap2-156 | 192.168.2.156 | Lars | Test-AP für Firmware-Entwicklung (Rolle: UGW) |
| ap2-161 | 192.168.2.161 | Lars | Test-AP für Firmware-Entwicklung (Rolle: Client des Captive Portal) |
| ap2-209 | 192.168.2.209 | oyla | UGW mit Standard-Firmware (aktiv in Benutzung); direkt mit olsr-Wolke im Haus verbunden |
| fastd | siehe Server | ||
| howmei | siehe Server | ||
| kinjo | siehe Server | ||
| ruri | siehe Server | ||
| itsuki | siehe Server | ||
| ks | 172.23.12.106 | oyla | Backup-Server für Kunstschule |
Anlegen oder Löschen von VMs
Siehe vhost-admin-Skript.
Besonderheiten
- keine
Offene Aufgaben
- Hardware-RAID-Controller entfernen
- aktuell fehlt uns (wahrscheinlich aufgrund des zwischengeschalteten Controllers) hotplug und smartcontrol