Artikel-Schlagworte: „Server“

Ubuntu als Router

Samstag, 10. Juli 2010

Handelsübliche “DSL-Router”, oder die sogenannten eierlegenden Wollmilch-Säue, nehmen einem im Alltag schon sehr viel Arbeit ab. Leider legen die Hersteller wenig Wert auf  Transparenz oder Wartbarkeit.  Spätestens wenn man etwas mehr Flexibilität will, darf man gleich richtig Tief in die Tasche greifen oder sich selber was basteln.

Linux-Distributionen kommen schon seit Jahren mit einer Grundkonfigurationen die sie mit wenigen Handgriffen in einen vollwertigen Router verwandelt.

Einen DSL-Modem kann man mittels pppoeconf ansprechen.

sudo pppoeconf

Der Installationsmechanismus ist ein wenig krüppelig aber anschließend hat man eine Verbindung ins Internet. Standardmäßig ist sie im “persistenten” Modus, soll heißen, nach einem 24 Stunden disconnect verbindet sich das System automatisch neu. Zusätzlich wird noch die möglichkeit geboten scriptes aufzurufen wenn die Verbindung auf oder abgebaut wurde. Das kann man dazu nutzen einen dyndns-Dienst
zu aktualisieren. Installiert man den ddclient, klinkt er sich dort eigenständig ein.

sudo aptitude install ddclient

zusätzlich zu dieser Konfiguration bedarf es noch der Verschaltung der Netzwerke. Wenn man nicht gerade ein öffentliches Netz im betrieb hat wird man NAT nutzen müssen. Dazu muss man einfach mittels iptables folgende regeln konfigurieren. Am besten sollte man das gleich in /etc/rc.local ablegen, damit das setup bei jedem reboot gesetzt wird.

sudo -s
echo "1" > /proc/sys/net/ipv4/ip_forward #alternative /etc/sysctl bearbeiten
 
iptables -A FORWARD -o <internes interface> -m state --state ESTABLISHED,RELATED -J ACCEPT #alles akzeptieren was vom Internet kommt und von lokalen Lan initialisiert wurde.
iptables -A FORWARD -o <externes interface> -J ACCEPT #alles was von Intern nach Extern will akzeptieren.
 
iptables -t nat -A POSTROUTING -o <externes interface> -j MASQUERADE #NAT aktivieren

Nach diesem Setup hat man erstmal wieder Internet von allen Clients, wenn man den default-dns-server und standart-gateway korrekt eingestellt hat.

Wenn man über längere zeit “ernsthaft” einen rechner direkt am I-Net hängen lässt, sollte man sich jedoch über iptables genauer Informieren. Das genannte Setup ist nur ein Grundsetup um last den Router-Rechner ziemlich “exposed” im Netz.

serverseitige Profile

Sonntag, 19. Juli 2009

Wer mehrere Rechner sein eigen nennt und dazu noch einen Server beseitzt wird über kurz oder lang auf die wahnsinnige Idee kommen, alle userbezogenen Daten auf dem Server abzulegen, um im Falle eines Crashes alles wieder bei sammen zu haben oder schlicht um an allen Rechnern auf die gleichen Daten zuzugreifen.

Dies kann man unter Linux sehr bequem mittels mounting sehr elegant lösen. Einfach den Pfad /home/$(USERNAME) mittels pam_mount auf ein externe Quelle/Server mounten.

Unter Windows geht das nur über eine Domäne, bei der (nach wunsch) das Userprofiel serverseitig gespeichert wird.

Fährt man den Server jedoch mal runter  (kann im wartungsfall passieren) oder nutzt man das Ganze an einem Laptop und ist nicht im privaten netzt wird man folgendes festellen:

  • Linux: die GUI (Gnome/KDE/whatever) fährt hoch, aber alles sieht aus wie beim ersten Start.
  • Windows: man wird darauf hingewiesen, dass die Domäne samt serverseitgen Profielen nicht verfügbar ist. Sonst merkt man nichts.

Dies liegt an dem Umstand das Windows die Profile nach dem Anmelden downloaded und beim Abmelden wieder zurück kopiert. Steht der Server einmal nicht zur Verfügung wird mit der Kopie weitergearbeitet.

Steht ein Server bei einem Linux-Mount mittels CIFS oder NFS  nicht zur verfügung, schlegt der Mount fehl (was einem aber nur im syslog vermerkt wird) und man arbeitet nur noch lokal. Solange der Server online ist, schreibt man aber alles “direkt” auf dem Server. Ohne nutzbare lokale kopie.

Ideal wäre eine DFS -implemntierung die einen das alles transparent abnimmt. Diese eierlegende Wollmichsau habe ich leider nicht gefunden. Deswegen habe ich folgenden Lösungsansatzt benutzt.

Die Idee von Microsoft für unterschiedliche “Systeme” unterschiedliche Profile anzulegen, fand ich ganz vernünftig. Es gibt also Profile für ein WinXP64, WinXP32 usw… Auf einem DoppelKern mit dicker Graka läuft was anderes als auf einem Atom-Laptop. Nachteilig ist, dass das auch die “Eigenen Dateien” betrifft, welche eigendlich Systemunabhängig sein sollten, wenn sich mal alle Entwickler drann halten würden.

Unter Linux lässt sich diese Trennung wesentlich leichter durchziehen, dank der Disziplin. Auf dem Server werden zwei Verzeichnisse angelegt und verfügbar gemacht.

  • Home-Verzeichniss: hier kommt alles rein was auf allen Rechnern zur verfügung stehen soll.
  • Profiles\$(System): hier kommt alles rein, was ein bestimmtes system betrifft.

Am Client muss man diese beiden verzeichnisse nur noch mittels mount irgendwohin mounten. “/mnt/.serverprofile” und “/mnt/homedir” bieten sich an . Da man den String der das System identifieziert selber wählen kann, steht einem die aufteilung frei. Sinnvoll ist eine auftreilung nach KDE/Gnome/Xfce. Es sind aber auch andere Aufteilungen möglich.

jetzt braucht es zwei scripte die das kopieren übernehmen:

  • Server->Lokale Kopie:
     rsync -a /mnt/.serverprofile/ ~/
    rsync -a /mnt/homedir/* ~/
  • Lokale Kopie->Server:
     rsync -a ~/.[a-Z,0-9]* /mnt/.serverprofile/
    rsync -a ~/* /mnt/homedir

Das erste Bash-Listing dürfte nicht verwundern. Alle Dateien aus den serververzeinissen werden in das Uservervzeichniss kopiert. “rsync -a” sorgt nur dafür das alle gesetzten Rechte erhalten bleiben (außer ACLs was mich aber nicht stört)

Beim zweite Listing könnte nur der Ausdruck “~/.[a-Z,0-9]*” verwirren. Der sorgt dafür das nur Files kopiert werden die mit einem Punkt beginnen. (Korrekt: es werden nur Dateien/Ordner kopiert die mit Punkt beginnen gefolgt von einem Buchstaben oder Zahl. Bei Bedarf muss das angepasst werden)

Die scripte sind nicht sonderlich intelligent und werden von mir im laufe der  Zeit auf effizents getrimmt. Man gewinnt viel zeit wenn man nur änderungen übertragt. Ich werde mal schauen was mit tar so gemacht werden kann…

Jetzt müssen diese beiden Scriptes nur noch bei an/abmeldung ausgeführt werden. Jeh nachdem welchen Desktopmanager man benutzt, ändert sich das vorgehen.

  • KDE: Unter “Systemeinstellung” -> “Erweiterte Benutzereinstellung” -> “Autostart” kann man die Scriptes verlinken. Das ist unschön, da man es für jeden benutzer einzeln machen muss, für eine größere Anzahl an Rechner ist das nicht zu administrieren. Unter /usr/shutdown kann man auch scriptes ablegen. Diese Scriptes ziehen aber nur bei “Shutdown” nicht logoff. Hier bin ich noch auf der suche nach einem entsprechend besseren Lösung.
  • Gnome: Hier bietet der GDM entsprechende Einsprungpunkte. /etc/gdm/PostSession und /etc/gdm/PreSession
  • Xcfe: hab ich (noch) nicht einsatzt. Wird aber im Laufe der nächsten Wochen geändert.

Mit den gemachten einstellung hat man sein Profiel auch wenn der Server mal nicht verfügbar ist.

PS: unter KDE wird er Kopie-Script ausgeführt wenn die Oberfläche oben ist. Es empfiehlt sich also vor dem ersten start, in der Konsole alles zu kopieren. Sonst könnte der geneigte user beim ersten start ein Schock bekommen: “Whaaa alles weg”.

Server Suspend – a long tail

Mittwoch, 8. Juli 2009

Einleitung

Was braucht man sinnigerweise für einen Server den man Schlafen legen will?

  1. Eine CPU/Board – Kombo die das unterstützt…
  2. Eine Netzwerkkarte die WakeUp-on-LAN unterstützt
  3. Alle Periferiere muss Suspend unterstützen (RAID Controler, etc…)

Primär spielt es keine Rolle welchen Suspend man anstrebt. Ob “Suspend to Ram” (Suspend) oder “Suspend to Disk”(Hibernate) unterscheidet sich im Administrativen, wie man den Server dazu bekommt, nicht. Es muss einfach ein anderer Wert (Zahl) in /proc/acpi/sleep geschrieben werden…

In meinen Versuchen hat sich Suspend to RAM aber als sinnvoller erwiesen. Das Aufwachen nach einem Suspend ging (erwartungsgemäß) schneller. Aus einem Suspend kam der Server innerhalb von unter 2 Sek wieder zum laufen (laut Kernel – Syslog, zu messen war das kaum sinnvoll…) beim Hibernate benötigte es einen kompletten Boot… das dauerte bei mir ganze 5-7 Sekunden.

Die Einsparung an Energie gegenüber einem Suspend hielt sich in grenzen:

  • Server (Boot): 75 Watt
  • Server (Working): 20 Watt
  • Server (Idle): 15 Watt
  • Server (Suspend): 3 Watt
  • Server (Hibernate): <1 Watt

Der geringe “Gewinn” war es mir nicht wert meine Sicherheit und die Response-Zeit zu opfern… Man sollte immer bedenken, dass der Memory auf die Festplatte geschrieben wird…. und selbst wenn man den verschlüsselt, ein Angreifer den Server bewegen kann (da er keinen Strom braucht) und in seiner umgebung booten kann… Hat man hingegen ein verschlüsselte Boot-Partition (TrueCrypt etc) nutzt einem der Hibernate nicht viel, da der Server nicht “unbeobachtet” wieder hoch kommt…

Vorbereitungen

Als erstes muss man die Netzwerkkarte testen bzw fit für WakeUp on Lan (WOL) machen. Wie das geht wird sehr gut hier beschrieben. Zu den einzelnen WOL-Modi:

  • WOL-Packet: Das eigentlich aufwecken über ein WOL/Magic-Packet ist weniger Sinnvoll und erlaubt nur einen Betrieb eines File/Domain-Servers. Beim Booten müssen alle Clientes automatisiert das WOL-Packet lostrehten und der Server darf über die dauer der Session nicht runter Fahren.
  • u/m/b/a: Das Aufwachen des Servers bei Broad/Multi/Uni-Cast ist die (imho) interessanteste Variante. Der Server wird in jedem Fall geweckt wenn er gebraucht wird. Fast alle heute verwendeten Protokolle arbeiten über IP. Dabei impliziert ist das beziehen einer Adresse (DHCP) und das Auflösen einer Adresse (ARP). Beide Protokolle beginnen den initialen Request über Broadcast. So kann man fast alles betreiben: DHCP, DNS, Webserver. Warum im Standart nochmals ein WakeUp on ARP(a) ausgewiesen wird, erschließt sich mir nicht…
  • WakeUp on physikal activity: diesen Modus hab ich bei meinen getesteten Karten nicht zum laufen bekommen. Oder nicht so wie ich das wollte. Entweder wurde der Rechner sofort nach seinem suspend wieder geweckt oder er reagierte überhaupt nicht… wer denn Sinn dahinter versteht, möge es posten…

Shutdown

Ich habe lange gesucht (ok, nicht wirklich lange, aber schon länger… ;) ) bis ich eine geeignete Methode gefunden hatte, bzw zu meiner ersten Idee zurück kam. Ich machs kurz: Sleepd und andere Methoden Interupts abzufragen (oder besser deren nichterscheinen) funktionierten nicht oder nur eingeschränkt… Die interessanten Interrupts ließen sich nicht abhören und so was wie Maus und Tastatur nutzt bei einem Server ohne selbige nichts.

Deswegen verwende ich einen Script der alle 5 Minuten via Cron ausgeführt wird. Dieser ist in seiner “Urform” hier zu finden. Der Script als solches funktioniert prima, musste nur um zwei Funktionalitäten an meine Bedürfnisse angepasst werden.

  • Wenn man den Server als zentralen FileServer für die Home-Dirs nutzt, sollte dieser tunlichst nicht runterfahren, solange ein User angemeldet ist. Das CIFS/Samba Protokoll und deren Implementierungen können das zwar ab, die Programme (KDE, OpenOffice, …) jedoch nicht. Stalled Lockfiles und andere “interessante” Probleme sind die Folge… Aus diesem Grund habe ich den Script um eine Überprüfung erweitert, ob SMB-User angemeldet sind. Dies erfolgt über “smbstatus”.
  • Des weiteren kam es immer wieder dazu, dass der Server nicht “richtig” in den Suspend ging, oder nicht ordentlich aufwachte.Dies häufte sich besonders bei häufigen Suspends (ich hatte Testhalber die Überprüfung auf minütlich gesetzt). Nach einer weile /var/syslog-Studium fand ich den Übeltäter. Cron kann zuschlagen, während der Kernel noch am “aufwachen” ist und im somit abermals einen Schlafbefehl verpassen. Das bringt den Kernel ein wenig aus dem Trab. Um das zu unterbinden hab ich zwei weitere Prüfungen eingebaut. Zum einen wird ein Lockfile angelegt, das erst nach dem beenden von des “echo”-Befehls gelöscht wird, eine Semaphore. Zum zweiten muss zwischen “Aufwachen” und erneutem Suspend mindestens 30 Minuten liegen. Dies wird mit einem Datei geprüft die mittels “touch” aktualisiert wird, bevor das Lockfile gelöscht wird. Danach einfach das Datediff abfragen…

Die von mir verwendete Version ist hier zu finden.

Fazit

Der Server steht mir nunmehr 24/7 zur Verfügung, spart sich jedoch Strom da nicht immer an… Zudem zühlt die Uptime auch hoch, obwohl der Server am “Schlafen” ist, nennt man das cheaten? *G*

Einziges Manko: Aus Sicht der Festplatten handelt es sich um einen “Shutdown”. Zu mindestens wird der Motor komplett stromlos geschaltet. Das Wiederanfahren sowie justieren der Köpfe reduziert die Lebensdauer der Platten entsprechend. Bei guten (verlässlichen) RAIDs sollte das aber kein Problem darstellen.

Links