Rootserver: Unterschied zwischen den Versionen
(150 dazwischenliegende Versionen von 11 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
Das Weimarnetz verwendet einen Rechner, der das Funk-Netz unterstützt und Dienste im Weimarnetz und im Internet anbietet. Wichtige Eigenschaften dieses Rechners sind eine sehr gute Internet-Anbindung, eine feste Internet-Adresse, hohe Verfügbarkeit und eine gute Internet-Verbindung zu den Internet-Anschlüssen im Weimarnetz. Je nach Aufgabe wird dieser Rechner hier im wiki als Root- oder Route-Server bezeichnet. | Das Weimarnetz verwendet einen Rechner, der das Funk-Netz unterstützt und Dienste im Weimarnetz und im Internet anbietet. Wichtige Eigenschaften dieses Rechners sind eine sehr gute Internet-Anbindung, eine feste Internet-Adresse, hohe Verfügbarkeit und eine gute Internet-Verbindung zu den Internet-Anschlüssen im Weimarnetz. Je nach Aufgabe wird dieser Rechner hier im wiki als Root- oder Route-Server bezeichnet. | ||
+ | |||
+ | =Rootserver 2.0= | ||
+ | ==Technik== | ||
+ | * 19 Zoll ATX Server mit 1 Höheneinheit (1HE) | ||
+ | * CPU: 2 x XEON QUAD CORE L5420 2,5 GHz | ||
+ | * RAM: 32 GB DDR-2 FB ECC Reg. | ||
+ | * HDD: incl. SATA-TRAY HOT-SWAP für 3 x SATA-HDD 3.5 Zoll | ||
+ | * 600 Watt Win-Tact Powersupply WP507F12 | ||
+ | * 2 Platten Western Digital WD30EFRX, geeignet für Dauerbetrieb | ||
+ | * Leistungsaufnahme: Beim Einschalten ca. 300 W, im Idle ca. 200 W | ||
+ | ==Kosten== | ||
+ | * Server mit Versand: 370 Euro | ||
+ | * Festplatten: 260 Euro | ||
+ | * Kosten pro Monat bei durchschnittlicher Leistungsaufnahme von 250W: 60 Euro (1HE=10,- + 5x10,- pro 50Watt) | ||
+ | |||
+ | ==Installation== | ||
+ | ===Partitionierung=== | ||
+ | * wegen 3TB, GPT und EFI nach dieser Anleitung vorgegangen: http://stackful.io/blog/raid-install-ubuntu-server-on-a-large-hard-drive/ | ||
+ | ** 40GB Swap pro Platte, da nicht gespiegelt ==> 80 GB Swap ingesamt | ||
+ | ** 120GB für das System und ISO-Store zur Ablage von OS-Images (unter /media/isostore) | ||
+ | ** per LVM Rest für Images | ||
+ | * Das alles im Raid 1 per mdadm. Fehlermeldungen kommen per Mail auf die [[Mailingliste]] | ||
+ | * Erfolgreich getestet wurde, dass das System beim Ausfall einer Platte trotzdem noch bootet | ||
+ | * Noch zu klären: Was machen wir im Fehlerfall? Vorschlag: Mit Daniel von Freifunk Berlin reden, ob wir ihm im Notfall eine Platte geben können. Diese muss gegen die defekte Platte getauscht werden (Reboot notwendig). Danach muss das gleiche Partitionsschema angelegt werden und die Platten können wieder synchronisieren (dauert insgesammt 8-9 Stunden) | ||
+ | |||
+ | ===OS=== | ||
+ | * Ubuntu 12.04 LTS | ||
+ | ** Pakete: apticron, virt-manager, bridge-utils, ... | ||
+ | ===Netzwerk=== | ||
+ | * Bridge und VLAN, IP-Konfiguration | ||
+ | ** feste, öffentliche IP | ||
+ | *** Netz: ''77.87.48.16/28'' und ''77.87.48.32/28'' | ||
+ | *** Netzmaske: ''255.255.255.240'' =/28 = 14 IP-Adressen + Netz + Gateway = 16 | ||
+ | *** Gateway: ''77.87.48.17'' | ||
+ | ** '''eth0''': | ||
+ | *** untagged IN-Berlin: ''217.197.91.138'' | ||
+ | *** tagged Freifunk-VLAN mit bridge 77.87.48.18 = tag1300 | ||
+ | **** dadurch sind alle Gäste per Bridge mit dem Freifunk-VLAN verbunden | ||
+ | |||
+ | ===Serielle Konsole=== | ||
+ | * Zugriff über Konsolenserver | ||
+ | * Zugang im Notfall, Neustart per serieller Konsole möglich? | ||
+ | * Details folgen nach Einbau | ||
+ | |||
+ | ==HowTo== | ||
+ | ===Start/Stop/Autostart=== | ||
+ | * virsh-wrapper, um jedem Nutzer die Steuerung der eigenen Maschine(n) zu ermöglichen | ||
+ | * virsh-wrapper ist erweiterbar zur Steuerung anderer KVM-Elemente, z.B. Storage, Netzwerk, usw. | ||
+ | * https://github.com/weimarnetz/virsh-wrapper | ||
+ | * Funktionsweise: | ||
+ | ** Vereichnis virsh im Homeverzeichnis jedes Nutzers | ||
+ | ** in virsh ein Verzeichnis pro Maschine, Namenskonvention: dom-<maschinenname> (maschinenname ohne Benutzerkürzel) - z.B.: mkdir /home/cs/virsh/dom-erich | ||
+ | ** innerhalb des Maschinenverzeichnisses stehen Dateien für etwaige Aktionen, die Inhalte der Dateien werden als Parameter übergeben | ||
+ | ** Cronjob läuft jede Minute durch die Virsh-Verzeichnisse aller Nutzer, die in der Gruppe vmguests sind | ||
+ | ** Chronik und Fehlermeldungen werden in anderen Verzeichnissen gespeichert | ||
+ | * Start einer Maschine | ||
+ | ** <tt>touch ~/virsh/dom-<machine>/start</tt> | ||
+ | * Anhalten einer Maschine | ||
+ | ** <tt>touch ~/virsh/dom-<machine>/shutdown</tt> (für Maschinen mit ACPI-Funktionen) | ||
+ | ** <tt>touch ~/virsh/dom-<machine>/destroy</tt> (falls die Maschine nicht mehr reagiert oder nicht per ACPI ausgeschaltet werden kann) | ||
+ | * Autostart | ||
+ | ** <tt>touch ~/virsh/dom-<machine>/autostart</tt> (Autostart anschalten) | ||
+ | ** <tt>echo "--disable" > ~/virsh/dom-<machine>/autostart</tt> (Autostart deaktivieren) | ||
+ | |||
+ | ===VNC über SSH=== | ||
+ | * VNC ist die Konsolenausgabe der virtuellen Maschinen | ||
+ | * VNC hört nur auf 127.0.0.1 (ginge zwar auch anders, wollen wir aber nicht) | ||
+ | * Pro Maschine ein Port, dieser wird manuell von uns auf 59xy festgelegt. xy entspricht der letzten Stelle der IP-Adresse | ||
+ | * Verbindung erfolgt über SSH-Tunnel | ||
+ | ** unter Linux | ||
+ | *** Start des Tunnels: <tt>ssh -N -L 5900:localhost:59xy username@root.weimarnetz.de</tt> | ||
+ | **** (durch -N bleibt die Verbindung ohne Prompt hängen, das ist OK so) | ||
+ | *** Start VNC-Client: <tt>vncviewer localhost (auf port 5900)</tt> | ||
+ | ** unter Mac OS X | ||
+ | *** Start des Tunnels: <tt>ssh -N -L 5900:localhost:59xy username@root.weimarnetz.de</tt> | ||
+ | *** Da es Probleme mit dem Mac OS X VNC-Viewer gibt, empfiehlt sich [http://sourceforge.net/projects/cotvnc/ Chicken of the VNC] | ||
+ | ** unter Windows | ||
+ | *** Unter Putty normal eine Session zu root.weimarnetz.de starten, VOR dem anmelden jedoch im Punkt | ||
+ | *** Connection --> SSH --> Tunnels folgendes Eintragen: | ||
+ | *** Source Port: 5900 Destination: 127.0.0.1:59xy (xy ist eure IP) | ||
+ | *** Button "Add" drücken, der Tunnel sollte dann unter "forwarded ports" stehen. Diese Session könnt ihr euch auch dauerhaft speichern | ||
+ | *** --> Open Connection, anmelden und vncviewer auf localhost starten | ||
+ | * Unter Umständen bricht die SSH-Verbindung ab und dann ist der lokale Port mit der gestorbenen SSH-Session blockiert. Mit <tt>ps aux | grep ssh</tt> kann man die Prozess-ID ermitteln und mit <tt>kill $ID</tt> wieder befreien. | ||
+ | |||
+ | === iPXE === | ||
+ | |||
+ | PXE ist teil des virtuellen bootloaders jeder vm. | ||
+ | wenn kein image zugewiesen ist (= keine virtuelle cd eingelegt), kann der bootloader ein frisches image laden und booten. per http! | ||
+ | |||
+ | * beim starten <tt>CTRL + B</tt> drücken, um in die iPXE konsole zu gelangen | ||
+ | * unsere vms haben fixe ips (Befehl dhcp geht net) -> http://ipxe.org/cmd/set | ||
+ | * ein image über HTTP laden: <tt>$ chain http://releng.archlinux.org/pxeboot/ipxe.lkrn</tt> | ||
+ | * warten | ||
+ | * terminal promptet mit <tt>boot:</tt>, warten <tt>ENTER</tt> drücken | ||
+ | * wer das für ubuntu hinbekommt - immer her damit! Als Einstieg das: http://archive.ubuntu.com/ubuntu/dists/trusty-updates/main/installer-amd64/current/images/xenial-netboot/ubuntu-installer/amd64/ | ||
+ | * profit! | ||
+ | |||
+ | ===Netzwerkkonfiguration im Gast=== | ||
+ | * je nach verwendetem OS: Netzwerk konfigurieren in ''/etc/network/interfaces'' (Ubuntu, Debian) | ||
+ | auto eth0 | ||
+ | iface eth0 inet static | ||
+ | address 77.87.48.xx | ||
+ | netmask 255.255.255.240 | ||
+ | gateway 77.87.48.17 oder 33 | ||
+ | |||
+ | iface eth0 inet6 static | ||
+ | address 2001:bf7:b101:1::xx | ||
+ | netmask 64 | ||
+ | gateway 2001:bf7:b101:1::1 | ||
+ | |||
+ | * DNS einrichten in ''/etc/resolv.conf'' | ||
+ | domain lan | ||
+ | search lan | ||
+ | nameserver 192.109.42.41 | ||
+ | nameserver 192.109.42.42 | ||
+ | |||
+ | * manuell | ||
+ | NR=(interne vm nummer) | ||
+ | ip link set eth0 up | ||
+ | ip addr add 77.87.48.$NR/28 dev eth0 | ||
+ | ip route add default via 77.87.48.17 | ||
+ | vim /etc/resolv.conf | ||
+ | |||
+ | ===Tipps und Tricks=== | ||
+ | ====LV mounten und oder LV fsck==== | ||
+ | * wenn das Dateisystem des LV kaputt ist und das automatische fsck fehlschlägt: | ||
+ | ** fdisk fdisk /dev/vg_images/cs-erich und "p" | ||
+ | Disk /dev/vg_images/cs-erich: 104.9 GB, 104857600000 bytes | ||
+ | 255 heads, 63 sectors/track, 12748 cylinders, total 204800000 sectors | ||
+ | Units = sectors of 1 * 512 = 512 bytes | ||
+ | Sector size (logical/physical): 512 bytes / 4096 bytes | ||
+ | I/O size (minimum/optimal): 4096 bytes / 4096 bytes | ||
+ | Disk identifier: 0x000ee166 | ||
+ | Device Boot Start End Blocks Id System | ||
+ | /dev/vg_images/cs-erich1 * 2048 196943871 98470912 83 Linux | ||
+ | ** sudo mount -o loop,offset=$((2048 * 512)) /dev/mapper/vg_images-cs--erich /home/cs/mnt | ||
+ | ** oder für fsck: sudo losetup --offset=$((2048 * 512)) /dev/loop0 /dev/vg_images/cs-erich | ||
+ | ** /dev/loop0 kann dann gefsckt werden | ||
+ | |||
+ | |||
+ | * Nutzung der virtio-Treiber für HDD, Netzwerk und RAM-Controller | ||
+ | * Distributionen wie Debian bringen diese schon bei der Installation mit und richten alles automatisch ein | ||
+ | * virtio-Treiber für RAM-Controller erlaubt uns, garantierten und maximalen RAM festzulegen. Bei Speicherknappheit im System werden die Resourcen pro VM zurückgefahren. | ||
+ | * Zugriff auf Maschinen via SSH vom Host aus ermöglichen: -net user,hostfwd=tcp::5555-:22 | ||
+ | * block-device scheduler im Gast auf primitiv stellen, das macht der Wirt besser: | ||
+ | ** sudo echo "deadline" >/sys/block/sr0/queue/scheduler | ||
+ | |||
+ | ===Neue Maschine hinzu=== | ||
+ | * Benutzer anlegen | ||
+ | * Maschine anlegen mit virt-manager | ||
+ | * vnc Port festlegen mit virsh | ||
+ | * sshd konfig anpassen damit jeder nur seinen vnc Port erreicht | ||
+ | * Doku im WIKI | ||
+ | * Spendenermunterung | ||
+ | |||
+ | |||
+ | ==Offline-DHCP== | ||
+ | ===Netze=== | ||
+ | * 77.87.48.16/28 und 77.87.48.32/28 | ||
+ | * jeder hat dann sowas wie 77.87.48.IP | ||
+ | |||
+ | ===Zuordnung=== | ||
+ | {| class="wikitable sortable" | ||
+ | ! data-sort-type="number" |IP | ||
+ | ! IPv6 | ||
+ | ! Nutzer | ||
+ | ! RevDNS | ||
+ | ! RAM | ||
+ | ! CPU's | ||
+ | ! Pinning | ||
+ | |- | ||
+ | | 18 | ||
+ | | | ||
+ | | Bridge | ||
+ | | | ||
+ | |- | ||
+ | | 19 | ||
+ | | 2001:bf7:b101:1::19 | ||
+ | | Weimarnetz e.V. | ||
+ | | weimarnetz.de | ||
+ | | 2 GB | ||
+ | | 2 | ||
+ | | 5 | ||
+ | |- | ||
+ | | 20 | ||
+ | | 2001:bf7:b101:1::20 | ||
+ | | Storchi | ||
+ | | cs.weimarnetz.de | ||
+ | | 2 GB | ||
+ | | 1 | ||
+ | | 4 | ||
+ | |- | ||
+ | | 21 | ||
+ | | 2001:bf7:b101:1::21 | ||
+ | | Andi | ||
+ | | ja.ishalt.so | ||
+ | | 2 GB | ||
+ | | 2 | ||
+ | | 6,7 | ||
+ | |- | ||
+ | | 22 | ||
+ | | 2001:bf7:b101:1::22 | ||
+ | | Basti | ||
+ | | bb.weimarnetz.de | ||
+ | | 1 GB | ||
+ | | 1 | ||
+ | | 6 | ||
+ | |- | ||
+ | | 23 | ||
+ | | 2001:bf7:b101:1::23 | ||
+ | | Thomas | ||
+ | | tf.weimarnetz.de | ||
+ | | 3 GB | ||
+ | | 2 | ||
+ | | 4,5 | ||
+ | |- | ||
+ | | 24 | ||
+ | | 2001:bf7:b101:1::24 | ||
+ | | Weimarnetz | ||
+ | | map.weimarnetz.de | ||
+ | | 1 GB | ||
+ | | 1 | ||
+ | | | ||
+ | |- | ||
+ | | 25 | ||
+ | | 2001:bf7:b101:1::25 | ||
+ | | Heiko | ||
+ | | hf.weimarnetz.de | ||
+ | | 2 GB | ||
+ | | 1 | ||
+ | | 7 | ||
+ | |- | ||
+ | | 26 | ||
+ | | 2001:bf7:b101:1::26 | ||
+ | | Stephan | ||
+ | | sj.weimarnetz.de | ||
+ | | 1 GB | ||
+ | | 1 | ||
+ | | 0 | ||
+ | |- | ||
+ | | 27 | ||
+ | | 2001:bf7:b101:1::27 | ||
+ | | Weimarnetz e.V. | ||
+ | | meet.weimarnetz.de | ||
+ | | 4 GB | ||
+ | | 2 | ||
+ | | | ||
+ | |- | ||
+ | | 28 | ||
+ | | 2001:bf7:b101:1::28 | ||
+ | | Kay | ||
+ | | ks.weimarnetz.de | ||
+ | | 2 GB | ||
+ | | 1 | ||
+ | | 1 | ||
+ | |- | ||
+ | | 29 | ||
+ | | 2001:bf7:b101:1::29 | ||
+ | | Bernd | ||
+ | | ed.weimarnetz.de | ||
+ | | 1 GB | ||
+ | | 2 | ||
+ | | 2,3 | ||
+ | |- | ||
+ | | 30 | ||
+ | | 2001:bf7:b101:1::30 | ||
+ | | Ufo | ||
+ | | vpn8.leipzig.freifunk.net | ||
+ | | 512 MB | ||
+ | | 1 | ||
+ | | 2 | ||
+ | |- | ||
+ | | 34 | ||
+ | | 2001:bf7:b101:1::34 | ||
+ | | Weimarnetz e.V. | ||
+ | | dyn.weimarnetz.de | ||
+ | | 1 GB | ||
+ | | 1 | ||
+ | | 3 | ||
+ | |- | ||
+ | | 35 | ||
+ | | 2001:bf7:b101:1::35 | ||
+ | | Weimarnetz e.V. | ||
+ | | vpn3.weimarnetz.de | ||
+ | | 1GB | ||
+ | | 2 | ||
+ | | | ||
+ | |- | ||
+ | | 36 | ||
+ | | 2001:bf7:b101:1::36 | ||
+ | | Bernd | ||
+ | | | ||
+ | |- | ||
+ | | 37 | ||
+ | | 2001:bf7:b101:1::37 | ||
+ | | Weimarnetz e.V. | ||
+ | | jabber.weimarnetz.de | ||
+ | | 1 | ||
+ | | 1 | ||
+ | | 0 | ||
+ | |- | ||
+ | | 38 | ||
+ | | 2001:bf7:b101:1::38 | ||
+ | | ex Julius | ||
+ | | FREI FREI FREI | ||
+ | | x | ||
+ | | x | ||
+ | | x | ||
+ | |- | ||
+ | | 39 | ||
+ | | 2001:bf7:b101:1::39 | ||
+ | | Micha Stoecker | ||
+ | | freifunk jena | ||
+ | | 2 | ||
+ | | 1 | ||
+ | | | ||
+ | |- | ||
+ | | 40 | ||
+ | | 2001:bf7:b101:1::40 | ||
+ | | frei | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | 41 | ||
+ | | 2001:bf7:b101:1::41 | ||
+ | | tasifan | ||
+ | | noch kein rDNS | ||
+ | | 2 | ||
+ | | ? | ||
+ | | --- | ||
+ | |- | ||
+ | | 42 | ||
+ | | 2001:bf7:b101:1::42 | ||
+ | | Max | ||
+ | | ars.weimarnetz.de | ||
+ | | 4 GB | ||
+ | | 2 | ||
+ | | 0,1 | ||
+ | |- | ||
+ | | 43 | ||
+ | | 2001:bf7:b101:1::43 | ||
+ | | cs | ||
+ | | wird wieder frei... | ||
+ | | 1GB | ||
+ | | | ||
+ | |- | ||
+ | | 44 | ||
+ | | 2001:bf7:b101:1::44 | ||
+ | | | ||
+ | | aktuell gateway für netz 2 zum Testen | ||
+ | |- | ||
+ | | 45 | ||
+ | | 2001:bf7:b101:1::45 | ||
+ | | | ||
+ | | | ||
+ | |} | ||
=Dienste= | =Dienste= | ||
Zeile 125: | Zeile 483: | ||
exit(0); | exit(0); | ||
</pre> | </pre> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Aktuelle Version vom 18. März 2020, 20:49 Uhr
Das Weimarnetz verwendet einen Rechner, der das Funk-Netz unterstützt und Dienste im Weimarnetz und im Internet anbietet. Wichtige Eigenschaften dieses Rechners sind eine sehr gute Internet-Anbindung, eine feste Internet-Adresse, hohe Verfügbarkeit und eine gute Internet-Verbindung zu den Internet-Anschlüssen im Weimarnetz. Je nach Aufgabe wird dieser Rechner hier im wiki als Root- oder Route-Server bezeichnet.
Rootserver 2.0
Technik
- 19 Zoll ATX Server mit 1 Höheneinheit (1HE)
- CPU: 2 x XEON QUAD CORE L5420 2,5 GHz
- RAM: 32 GB DDR-2 FB ECC Reg.
- HDD: incl. SATA-TRAY HOT-SWAP für 3 x SATA-HDD 3.5 Zoll
- 600 Watt Win-Tact Powersupply WP507F12
- 2 Platten Western Digital WD30EFRX, geeignet für Dauerbetrieb
- Leistungsaufnahme: Beim Einschalten ca. 300 W, im Idle ca. 200 W
Kosten
- Server mit Versand: 370 Euro
- Festplatten: 260 Euro
- Kosten pro Monat bei durchschnittlicher Leistungsaufnahme von 250W: 60 Euro (1HE=10,- + 5x10,- pro 50Watt)
Installation
Partitionierung
- wegen 3TB, GPT und EFI nach dieser Anleitung vorgegangen: http://stackful.io/blog/raid-install-ubuntu-server-on-a-large-hard-drive/
- 40GB Swap pro Platte, da nicht gespiegelt ==> 80 GB Swap ingesamt
- 120GB für das System und ISO-Store zur Ablage von OS-Images (unter /media/isostore)
- per LVM Rest für Images
- Das alles im Raid 1 per mdadm. Fehlermeldungen kommen per Mail auf die Mailingliste
- Erfolgreich getestet wurde, dass das System beim Ausfall einer Platte trotzdem noch bootet
- Noch zu klären: Was machen wir im Fehlerfall? Vorschlag: Mit Daniel von Freifunk Berlin reden, ob wir ihm im Notfall eine Platte geben können. Diese muss gegen die defekte Platte getauscht werden (Reboot notwendig). Danach muss das gleiche Partitionsschema angelegt werden und die Platten können wieder synchronisieren (dauert insgesammt 8-9 Stunden)
OS
- Ubuntu 12.04 LTS
- Pakete: apticron, virt-manager, bridge-utils, ...
Netzwerk
- Bridge und VLAN, IP-Konfiguration
- feste, öffentliche IP
- Netz: 77.87.48.16/28 und 77.87.48.32/28
- Netzmaske: 255.255.255.240 =/28 = 14 IP-Adressen + Netz + Gateway = 16
- Gateway: 77.87.48.17
- eth0:
- untagged IN-Berlin: 217.197.91.138
- tagged Freifunk-VLAN mit bridge 77.87.48.18 = tag1300
- dadurch sind alle Gäste per Bridge mit dem Freifunk-VLAN verbunden
- feste, öffentliche IP
Serielle Konsole
- Zugriff über Konsolenserver
- Zugang im Notfall, Neustart per serieller Konsole möglich?
- Details folgen nach Einbau
HowTo
Start/Stop/Autostart
- virsh-wrapper, um jedem Nutzer die Steuerung der eigenen Maschine(n) zu ermöglichen
- virsh-wrapper ist erweiterbar zur Steuerung anderer KVM-Elemente, z.B. Storage, Netzwerk, usw.
- https://github.com/weimarnetz/virsh-wrapper
- Funktionsweise:
- Vereichnis virsh im Homeverzeichnis jedes Nutzers
- in virsh ein Verzeichnis pro Maschine, Namenskonvention: dom-<maschinenname> (maschinenname ohne Benutzerkürzel) - z.B.: mkdir /home/cs/virsh/dom-erich
- innerhalb des Maschinenverzeichnisses stehen Dateien für etwaige Aktionen, die Inhalte der Dateien werden als Parameter übergeben
- Cronjob läuft jede Minute durch die Virsh-Verzeichnisse aller Nutzer, die in der Gruppe vmguests sind
- Chronik und Fehlermeldungen werden in anderen Verzeichnissen gespeichert
- Start einer Maschine
- touch ~/virsh/dom-<machine>/start
- Anhalten einer Maschine
- touch ~/virsh/dom-<machine>/shutdown (für Maschinen mit ACPI-Funktionen)
- touch ~/virsh/dom-<machine>/destroy (falls die Maschine nicht mehr reagiert oder nicht per ACPI ausgeschaltet werden kann)
- Autostart
- touch ~/virsh/dom-<machine>/autostart (Autostart anschalten)
- echo "--disable" > ~/virsh/dom-<machine>/autostart (Autostart deaktivieren)
VNC über SSH
- VNC ist die Konsolenausgabe der virtuellen Maschinen
- VNC hört nur auf 127.0.0.1 (ginge zwar auch anders, wollen wir aber nicht)
- Pro Maschine ein Port, dieser wird manuell von uns auf 59xy festgelegt. xy entspricht der letzten Stelle der IP-Adresse
- Verbindung erfolgt über SSH-Tunnel
- unter Linux
- Start des Tunnels: ssh -N -L 5900:localhost:59xy username@root.weimarnetz.de
- (durch -N bleibt die Verbindung ohne Prompt hängen, das ist OK so)
- Start VNC-Client: vncviewer localhost (auf port 5900)
- Start des Tunnels: ssh -N -L 5900:localhost:59xy username@root.weimarnetz.de
- unter Mac OS X
- Start des Tunnels: ssh -N -L 5900:localhost:59xy username@root.weimarnetz.de
- Da es Probleme mit dem Mac OS X VNC-Viewer gibt, empfiehlt sich Chicken of the VNC
- unter Windows
- Unter Putty normal eine Session zu root.weimarnetz.de starten, VOR dem anmelden jedoch im Punkt
- Connection --> SSH --> Tunnels folgendes Eintragen:
- Source Port: 5900 Destination: 127.0.0.1:59xy (xy ist eure IP)
- Button "Add" drücken, der Tunnel sollte dann unter "forwarded ports" stehen. Diese Session könnt ihr euch auch dauerhaft speichern
- --> Open Connection, anmelden und vncviewer auf localhost starten
- unter Linux
- Unter Umständen bricht die SSH-Verbindung ab und dann ist der lokale Port mit der gestorbenen SSH-Session blockiert. Mit ps aux | grep ssh kann man die Prozess-ID ermitteln und mit kill $ID wieder befreien.
iPXE
PXE ist teil des virtuellen bootloaders jeder vm. wenn kein image zugewiesen ist (= keine virtuelle cd eingelegt), kann der bootloader ein frisches image laden und booten. per http!
- beim starten CTRL + B drücken, um in die iPXE konsole zu gelangen
- unsere vms haben fixe ips (Befehl dhcp geht net) -> http://ipxe.org/cmd/set
- ein image über HTTP laden: $ chain http://releng.archlinux.org/pxeboot/ipxe.lkrn
- warten
- terminal promptet mit boot:, warten ENTER drücken
- wer das für ubuntu hinbekommt - immer her damit! Als Einstieg das: http://archive.ubuntu.com/ubuntu/dists/trusty-updates/main/installer-amd64/current/images/xenial-netboot/ubuntu-installer/amd64/
- profit!
Netzwerkkonfiguration im Gast
- je nach verwendetem OS: Netzwerk konfigurieren in /etc/network/interfaces (Ubuntu, Debian)
auto eth0 iface eth0 inet static address 77.87.48.xx netmask 255.255.255.240 gateway 77.87.48.17 oder 33
iface eth0 inet6 static address 2001:bf7:b101:1::xx netmask 64 gateway 2001:bf7:b101:1::1
- DNS einrichten in /etc/resolv.conf
domain lan search lan nameserver 192.109.42.41 nameserver 192.109.42.42
- manuell
NR=(interne vm nummer) ip link set eth0 up ip addr add 77.87.48.$NR/28 dev eth0 ip route add default via 77.87.48.17 vim /etc/resolv.conf
Tipps und Tricks
LV mounten und oder LV fsck
- wenn das Dateisystem des LV kaputt ist und das automatische fsck fehlschlägt:
- fdisk fdisk /dev/vg_images/cs-erich und "p"
Disk /dev/vg_images/cs-erich: 104.9 GB, 104857600000 bytes 255 heads, 63 sectors/track, 12748 cylinders, total 204800000 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0x000ee166 Device Boot Start End Blocks Id System /dev/vg_images/cs-erich1 * 2048 196943871 98470912 83 Linux
- sudo mount -o loop,offset=$((2048 * 512)) /dev/mapper/vg_images-cs--erich /home/cs/mnt
- oder für fsck: sudo losetup --offset=$((2048 * 512)) /dev/loop0 /dev/vg_images/cs-erich
- /dev/loop0 kann dann gefsckt werden
- Nutzung der virtio-Treiber für HDD, Netzwerk und RAM-Controller
- Distributionen wie Debian bringen diese schon bei der Installation mit und richten alles automatisch ein
- virtio-Treiber für RAM-Controller erlaubt uns, garantierten und maximalen RAM festzulegen. Bei Speicherknappheit im System werden die Resourcen pro VM zurückgefahren.
- Zugriff auf Maschinen via SSH vom Host aus ermöglichen: -net user,hostfwd=tcp::5555-:22
- block-device scheduler im Gast auf primitiv stellen, das macht der Wirt besser:
- sudo echo "deadline" >/sys/block/sr0/queue/scheduler
Neue Maschine hinzu
- Benutzer anlegen
- Maschine anlegen mit virt-manager
- vnc Port festlegen mit virsh
- sshd konfig anpassen damit jeder nur seinen vnc Port erreicht
- Doku im WIKI
- Spendenermunterung
Offline-DHCP
Netze
- 77.87.48.16/28 und 77.87.48.32/28
- jeder hat dann sowas wie 77.87.48.IP
Zuordnung
IP | IPv6 | Nutzer | RevDNS | RAM | CPU's | Pinning |
---|---|---|---|---|---|---|
18 | Bridge | |||||
19 | 2001:bf7:b101:1::19 | Weimarnetz e.V. | weimarnetz.de | 2 GB | 2 | 5 |
20 | 2001:bf7:b101:1::20 | Storchi | cs.weimarnetz.de | 2 GB | 1 | 4 |
21 | 2001:bf7:b101:1::21 | Andi | ja.ishalt.so | 2 GB | 2 | 6,7 |
22 | 2001:bf7:b101:1::22 | Basti | bb.weimarnetz.de | 1 GB | 1 | 6 |
23 | 2001:bf7:b101:1::23 | Thomas | tf.weimarnetz.de | 3 GB | 2 | 4,5 |
24 | 2001:bf7:b101:1::24 | Weimarnetz | map.weimarnetz.de | 1 GB | 1 | |
25 | 2001:bf7:b101:1::25 | Heiko | hf.weimarnetz.de | 2 GB | 1 | 7 |
26 | 2001:bf7:b101:1::26 | Stephan | sj.weimarnetz.de | 1 GB | 1 | 0 |
27 | 2001:bf7:b101:1::27 | Weimarnetz e.V. | meet.weimarnetz.de | 4 GB | 2 | |
28 | 2001:bf7:b101:1::28 | Kay | ks.weimarnetz.de | 2 GB | 1 | 1 |
29 | 2001:bf7:b101:1::29 | Bernd | ed.weimarnetz.de | 1 GB | 2 | 2,3 |
30 | 2001:bf7:b101:1::30 | Ufo | vpn8.leipzig.freifunk.net | 512 MB | 1 | 2 |
34 | 2001:bf7:b101:1::34 | Weimarnetz e.V. | dyn.weimarnetz.de | 1 GB | 1 | 3 |
35 | 2001:bf7:b101:1::35 | Weimarnetz e.V. | vpn3.weimarnetz.de | 1GB | 2 | |
36 | 2001:bf7:b101:1::36 | Bernd | ||||
37 | 2001:bf7:b101:1::37 | Weimarnetz e.V. | jabber.weimarnetz.de | 1 | 1 | 0 |
38 | 2001:bf7:b101:1::38 | ex Julius | FREI FREI FREI | x | x | x |
39 | 2001:bf7:b101:1::39 | Micha Stoecker | freifunk jena | 2 | 1 | |
40 | 2001:bf7:b101:1::40 | frei | ||||
41 | 2001:bf7:b101:1::41 | tasifan | noch kein rDNS | 2 | ? | --- |
42 | 2001:bf7:b101:1::42 | Max | ars.weimarnetz.de | 4 GB | 2 | 0,1 |
43 | 2001:bf7:b101:1::43 | cs | wird wieder frei... | 1GB | ||
44 | 2001:bf7:b101:1::44 | aktuell gateway für netz 2 zum Testen | ||||
45 | 2001:bf7:b101:1::45 |
Dienste
- interne IP ist 10.63.1.1
Kabelkopplung
Erfreulicherweise erstreckt sich das Weimarnetz über weite Teile der Stadt. Um sicher zu stellen, dass alle Teilnehmer im Netz miteinander kommunizieren können wird das Weimarnetz zusätzlich zum Funknetz über die Internet-Einspeiser am Route-Server zusammengehalten. Neben der Verbindung von Funk-Inseln können langsame Verbindungen über viele Funk-Knoten mit einer Abkürzung über den Route-Server verbessert werden.
Newsserver
Auch in Weimar existiert nun ein Newsserver als zukünftige Alternative zu den Mailinglisten. Entscheidende Vorteile sind, daß man diese Newsgroups einfach bestellen und auch wieder abbestellen kann (ohne das aufwändige Senden von Mails wie bei Mailinglisten) und die Synchronisation mit Newsservern in Leipzig und Halle. Damit kann auf die Newsgroups anderer Freifunk-Communities zugegriffen werden.
- Servername (freifunkintern): 10.63.1.254 (mit Router-Firmware vom 9.November auch als news.weimarnetz.de)
- Zugang (extern):
- nntp://news.weimarnetz.de
- mit Weboberfläche:
- http://news.weimarnetz.de/newsgroups/index.php (Schnelle Variante oder
- http://www.weimarnetz.de/news/newsgroups.php komfortable Variante mit RSS etc.)
- Login für den Zugang:
- Benutzername "freifunk"
- Passwort: "weimar"
TODO
- Upstream auch in Richtung Leipzig
Proxy
Ein Proxy dient als Zwischenstation zum Internet. Damals, als das Internet noch langsam und Pluto ein Planet war, dienten Proxies als Zwischenspeicher häufig angeforderter Dateien aus dem Internet. Dieser Nutzen verliert in der Verwendung am Root-Server an Wert, da
- der Server nur über das Internet erreichbar ist und als zusätzlicher Umweg eher bremst als beschleunigt
- die meisten Stöberer selbst lokal Informationen speichern
- schlecht programmierte Web-Anwendungen Probleme mit Proxies haben können
- Informationen gespeichert werden können, die besser nicht gespeichert werden sollten
Vorteilhafter wirkt der Proxy als Werbefilter und um Die Rückverfolgung von Internet-Nutzern am Root-Server statt am nächsten Internet-Einspeiser enden zu lassen.
Der Proxy ist mit folgender Einstellungen erreichbar: momentan nicht aktiviert
Proxy: 87.118.106.19 Port: 3128
Portforwarding (Dienste ins Internet zur Verfuegung stellen)
Johannes Gramse / Kirchmessaufbau: # noch nicht aktiv
Erinnerung ans Treffen für den Kassenwart
- liegt unter /usr/local/bin/meeting_reminder.pl
- verschickt Montags um 12 die aktuellen Daten des Treffens
- als cronjob in /etc/cron.d/scripts definiert
hier das Script zum Verbessern:
#! /usr/bin/perl use Net::NNTP; use LWP::Simple; ####### ## change this to point to your NNTP server host. $nntpserver = 'localhost'; ######## # url to wiki my $url_meeting="http://wireless.subsignal.org/index.php?title=Treffen"; my $place="undef"; my $date="undef"; my $subject=""; my $body=""; my $newsgroup="freifunk.de.weimar.discuss"; # Print warning and exit. Some mailers will discard warning string. # # Postfix is nice enough to display it in the mailq & log output when # # we exit with non-success exitcode. sub croak { my ($msg,$exitcode) = @_; warn "$msg\n"; exit($exitcode); } my $content = get $url_meeting; die "Couldn't get $url_meeting" unless defined $content; # Then go do things with $content, like this: if($content =~ m/Naechster Stammtisch<\/a>: (.*?)<\/b>.*?<a.*?>(.*?)<\/a>/s) { $date=$1; $place=$2; } #build subject if ($place eq "undef" or $date eq "undef") { $subject="Naechstes Treffen wahrscheinlich am Dienstag in der M18"; $body="Hallo allerseits, \n\nda das Wiki aktuell nicht erreichbar ist oder sich die Seitenstruktur erheblich veraendert hat, sind derzeit keine genauen Prognosen bezueglich des naechsten Treffens moeglich\n\nVielleicht ist es ja schonwieder erreichbar: " . $url_meeting . "\n\nDer Weimarnetzerinnerungsdienst\n\nps: Das ist eine computergenerierte Nachricht"; } else { $subject="Naechstes Treffen am: " . $date . ", Ort: " . $place; $body="Hallo allerseits, \n\nnaehere Informationen zum naechsten Treffen sind unter " . $url_meeting . " auffindbar. Sollte das Datum veraltet sein, hat sich wieder niemand um das aktuelle Treffen gekuemmert.\n\nDer Weimarnetzerinnerungsdienst\n\nps: Das ist eine computergenerierte Nachricht"; } push @headers,"From: Weimarnetz Wiki <do_not_reply\@weimarnetz.de>\n"; push @headers,"Newsgroups: ". $newsgroup ."\n"; push @headers,"Subject: ". $subject ."\n"; push @headers,"\n"; my $nntp = Net::NNTP->new($nntpserver) or croak('Net::NNTP failure.', "1"); $nntp->post() or croak('post() failure',&EX_TEMPFAIL); $nntp->datasend(\@headers) or croak('datasend() header failure',"1"); #while (<>) { $nntp->datasend($body)or croak('datasend() body failure',"1"); #} #$nntp->debug(1); # if error exit code, log to maillog (STDERR) $nntp->dataend() or croak('Post dataend() failure.', "2"); $nntp->quit(); exit(0);