Twitter Timeline
|
Sonntag, 24. März 2013Eigenen Git-Server ala Github aufsetzen
Eine Versionsverwaltung bestimmt den Alltag in größeren Projekten. Wo bisher SVN oder Merurical herhalten durfte, hat sich ein neuer Platzhirsch durchgesetzt, der aufgrund seiner Simplizität und Mächtigkeit überzeugt. Viele dürften es erraten haben, es handelt sich um Git.
Es gibt vielerlei Möglichkeiten mit Git eine Versionierung zu erreichen, sei es lokal oder auf github, bitbucket oder anderen Git-Repository Providern. Spätestens wenn es aber um Firmeninterne Projekte geht oder aber um allgemein nicht der Öffentlichkeit zugängliche Projekte muss man meist in die Tasche greifen und den Providern einen kleinen Obolus zahlen, damit diese die privaten Projekte Hosten und mehreren Teammitgleider ggf. Zugriff darauf gewähren. Kostengünstiger wäre es da einen eigenen Git-Server zu haben, welcher die internen Projekte angemessen verwaltet. Theoretisch ist auch dies schnell von statten gegangen, kann man doch über SSH auf ein zentrales Bare-Repository tunneln und Änderungen pushen und pullen. Wenn man jedoch auch gleichzeitig eine schöne Übersicht sämtlicher Commits haben möchte, samt Administration für Repoverwaltung, Benutzerverwaltung, etc. dann kommt man nicht umher sich diverse Webinterfaces anzuschauen, die einem diese Arbeit abnehmen können. Eine begrenzte Auswahl wären die folgenden Verwaltungssysteme:
Gitlab bring viele Funktionen mit, wie man sie auch von öffentlichen Git-Repository Servern wie z.B. GitHub kennt. Man hat eine pro Benutzer Projektverwaltung, ein Wiki, Issuetracker mit Redmine Integrationsmöglichkeiten, einfache Möglichkeiten POST-Hooks bei einem push in das Repo auszulösen und das mitunter beste ist, dass das Gitlab Webinterface fast ausschließlich über die Gitlab eigene API aufbaut. Das bedeutet man kann alles was man im Webinterface klicken kann auch über automatisierte Skripte auslösen, abfragen und verarbeiten. Die Installation die hier vorgestellt wird, nutzt abseits von dem empfohlenen Weg ein RVM (Ruby Virtual Environment), da man sich nicht unbedingt mit dem Betriebssystem über die installierte Rubyversion oder verschiedener Gems streiten möchte. Jedoch verlangt dies einige nachträgliche Anpassungen, welche aber so minimal gehalten sind, dass diese nicht ins Gewicht fallen. Zudem werden wir statt nginx den Apache2 nutzen um Gitlab auszuliefern. Die Schritte für nginx stehen auch im vorgestellten Skript, sind jedoch auskommentiert. (Es sei darauf hingewiesen das es kein richtiges Bash-Skript ist sondern mehr eine Anleitung was wann zu tun ist). An den Stellen, wo zum bearbeiten der Konfigurationsdateien ,vim‘ genutzt wird kann der persönlich bevorzugte Editor genutzt werden (emacs, nano, etc.) Bevor es nun los geht weise ich noch darauf hin, dass wir hier Gitlab @master nutzen, bedeutet die aktuelle Entwickler Version. Dies wird entsprechend so gemacht, da ab der Version 5.0 (Zum Zeitpunkt dieses Posts @master) gitolite durch eine eigene Loginshell ersetzt wird. Da gitolite als Repositoryverwaltung im Zusammenspiel mit Gitlab sehr verbuggt war. Sollte es also irgendwann einmal ein 5-x-stable branch geben so wäre dieser zu bevorzugen. Das kann man enstprechend prüfen, indem man nach dem clone des gitlab repos ,git branch -a‘ aufruft. Sollte da ein remotes/origin/5-x-stable existieren so kann man dies mit ,git checkout 5-x-stable‘ auschecken und fortan nutzen. (x steht für eine beliebige Zahl) Die Loginshell wird nach einem Erfolgreichen authentifizieren gegenüber SSH für den Benutzer git gerufen. Das ganze kann man sich anschauen, wenn man sich die Datei ,/home/git/.ssh/authorized_keys‘ anschaut. Hat man für einen Benutzer einen Key im Frontend importiert, so wird dieser in diese Datei geschrieben (zusammen mit dem command auf die gitlab-shell) und regelt den SSH Zugriff auf das Repository über die git-checkout URL eines Projekts. Die genutzte Distribution, bei der die folgenden Anweisungen genutzt wurden, ist Debian 6 „Squeeze“. Der Benutzer mit dem installiert wird ist ,root‘ aber keine Angst, Gitlab wird später unter dem Benutzer ,git‘ in das System installiert, für die ersten Schritte wie apt-get ist root jedoch vorrausgesetzt. Der Name des Benutzers sollte nicht verändert werden, da sonst viele der Standard Skripte angepasst werden müssten, da diese ,git‘ als Benutzer für sämtliche ,sudo‘ Befehle hard-coded haben. Zuerst aktivieren wir das Backports Repository damit wir einen Redis-Server >v2.0 installieren können. Dieser wird benötigt, da Gitlab BRPOP nutzt, welches erst seit v2.0.0 in Redis implementiert ist. # Enable backports Als nächstes benötigen wir sudo und einige weitere Pakete um Ruby und dessen Gems entsprechend kompilieren zu können.
Soll Gitlab auch Mails versenden können (z.B. „Passwort vergessen“-Mails), so wird auch ein postfix benötigt.
Als nächstes intallieren wir Python, dies wird von Gitlab auch noch benötigt.
Als nächstes legen wir die Datenbank an.
Jetzt wechseln wir auf den Benutzer und installieren Gitlab in dessen HOME-Verzeichnis:
Nun haben wir Gitlab erfolgreich auf dem System installiert und müssen dies nur noch starten. Dazu kann man das vom Entwickler bereitgestellte init.d Skript nutzen.
Nun hat man 2 Möglichkeiten, einmal NGinx und einmal Apache2. NGinx:
Apache2:
git.domain.tld-VHost Konfiguration:
Danach kann man prüfen ob alles läuft und funktionsfähig ist:
Schon hat man seinen eigenen Git-Repository Server am laufen, welcher zudem große Ähnlichkeiten mit Github hat. Viele Entwickler im eigenen Team die schon einmal mit Github gearbeitet haben, werden sich da schnell zurechtfinden. Der initiale Administratoren Login lautet dann admin@local.host mit dem Passwort: 5iveL!fe Dieser Benutzer sollte nach dem anlegen des eigenen Admin-Benutzers am besten gelöscht werden. Bei Fragen oder Kritiken können gern die Kommentare genutzt werden Dienstag, 11. Dezember 2012Netzwerk-Konfiguration mit Proxmox VE
Mit Proxmox VE kann man hervorragend virtualisieren und bekommt ein nettes Webinterface dazu, um die Konfiguration vorzunehmen. Deshalb kommt diese Lösung, vor Allem mit KVM, seit einiger Zeit auch bei den virtuellen managed Servern von RobHost erfolgreich zum Einsatz. Selbst Hochverfügbarkeit wird unterstützt - dazu in einem späteren Blogpost mehr.
Leider ist die Netzwerk-Config nicht immer ganz trivial, im Netz finden man haufenweise Fragen und Howto's zu diesem Thema. Zwar beschreibt das Proxmox-Wiki auch einige Szenarien, in der Praxis sind aber oft Host-IP und das Subnetz für die VM's verschiedene Netzbereiche. Ein Problem bei vielen Rootservern ist, dass die Anbieter i.d.R. aus Sicherheitsgründen nicht zulassen, dass Netzwerk-Traffic über ein Interface von mehreren MAC-Adressen kommt. Dies hat zur Folge, das oft die normale Bridged-Lösung nicht funktioniert und eine etwas unschöne Routed-Konfiguration herhalten muss. Wir haben das Problem im Rechenzentrum zum Glück nicht, daher wird hier die Bridged-Variante vorgestellt. Dennoch gibt es das "Problem", dass die IP des Proxmox-Host in einem anderen Netz liegt als das Subnetz für die virtuellen Maschinen. Daher klappt die ganz einfache Bridged-Konfiguration hier nicht, da wir ja keine IP verlieren wollen. Ansonsten könnte man natürlich dem Host die erste IP des Subnetzes geben. In Zeiten chronischer IPv4-Knappheit ist das aber wohl nicht im Sinne des Erfinders bzw. der RIPE Also brauchen wir eine Point-to-Point Verbindung, so dass die VMs zum Gateway auch durchkommen und eine normal funktionierende Netzwerk-Config haben. So sieht das Ganze dann unter Proxmox/Debian auf dem Host aus: iface eth0 inet manualWichtig ist die Netzmaske von 255.255.255.255 sowie der pointopoint Eintrag (Achtung: nur mit einem "t"!). Mehr ist nicht nötig, d.h. es müssen keine expliziten Routen zu den VMs oder dem Subnetz gesetzt werden. Innerhalb der VMS sieht das dann so aus (Debian/Ubuntu): iface eth0 inet staticBzw. so unter CentOS: # File: /etc/sysconfig/network-scripts/ifcfg-eth0Das war es auch schon, damit sollten alle VMs problemlos an das Netz angebunden sein. In Kürze stellen wir hier unser Auto-Deployment Script für Proxmox vor. Bei Fragen einfach die Kommentare nutzen Freitag, 13. Juli 2012Multiuser-GIT-Repos mit Gitolite (Debian Squeeze)
Git als Versionsverwaltung wird immer beliebter und die Dienste gitorious.org oder github.com boomen. Wer dennoch Herr seiner Daten bleiben will oder wer die Kosten für einen Pro-Account bei diesen Diensten scheut kann sich leicht mit einer eigenen Repo-Verwaltung behelfen. Gitolite ist ein tolles Tool um genau dies zu ermöglichen.
InstallationGit und gitolite sind Bestandteil des Debian Squezze Repositories. Die Installation sollte also wieder ohne großen Aufwand erfolgen. #apt-get install git-core gitolite Falls noch nicht geschehen, genenrieren wir uns einen SSH-Key. #ssh-keygen Diesen Key benötigen wir für den initialen Zugang zur gitolite-Verwaltung. Wir kopieren ihn nach /tmp um ihn für unseren git-Systemuser verfügbar zu machen. #cp .ssh/id_rsa.pub /tmp/gitolite_init.pub Optional können wir noch ein paar globale git Konfigurationsvariablen setzen. git config --global user.name "Dein Name" Nun erstellen wir unser zentrales Repoverzeichniss und legen einen git-Systemuser an. #/var/git-repos Nun wechseln wir zu unserem git-Systemuser und starten das Setup von gitolite in seinem home-Verzeichniss. Wichtig ist die Übergabe des inititalen SSH-Keys den wir in /tmp abgelegt haben. Der Key in /tmp wird danach nicht mehr benötigt und kann gelöscht werden. #su git Dann können wir das administrative Repo auschecken und die Konfigurationen auf unsere Bedürfnisse anpassen. git clone git@127.0.0.1:gitolite-admin.git In ./gitolite-admin/conf/gitolite.conf werden die Repos und Berechtigungen verwaltet. im Verzeichniss ./gitolite-admin/keydir/ werden die public-ssh-keys der User abgelegt. Die Änderungen werden erst wirksam wenn wir das repo auf den Server pushen. #git add . Falls wir in ./gitolite-admin/conf/gitolite.conf ein neues Repo konfiguriert haben wird dies nach einem push auch automatisch angelegt und steht sofort bereit. FazitGitolite bietet die Möglichkeit mehrere git-Repos für mehrere User komfortabel zu verwalten ohne dem User weitere Rechte auf dem System ermöglichen zu müssen. Gitolite setzt für die Authentifizierung von Benutzern ausschließlich auf SSH-Keys. Eine Authentifizierung via Passwort ist nicht möglich. Es sind sehr komplexe Berechtigungsstrukturen möglich die Dokumentation dazu findet man hier. Wer ein schönes Web-Interface braucht sollte ein Blick auf gitlabhq.com werfen. Dies scheint ein interessantes Projekt zu sein und setzt direkt auf gitolite. Freitag, 6. Juli 2012multitail - Ein Auge auf den Logs
Wer gleichzeitig mehr als ein Log-Datei im Auge behalten will kommt um das Tool multitail nicht herrum. Multitail erlaubt das gleichzeitige Betrachen mehrerer Log-Dateien.
InstallationInstallation erfolgt in der Regel aus den Repos der Distribution. #apt-get install multitail Danach ist multitail schon vollständig einsatzbereit. HowToUm Logdatei gleichzeit anzuschauen verwendet man: #multitail datei01 datei02 datei03 ... Mit dem Parameter -I kann man Dateien zusammenführen. Im Beispiel werden die Dateien /var/log/mail.log und /var/log/auth.log in einen Fenster zusammengeführt dargestellt. multitail /var/log/apache2/access.log /var/log/mail.log -I /var/log/auth.log Der Parameter -l ermöglicht das Ausführen von Befehlen und Scripten. Mit -R wird der Refresh-Intervall bestimmt. Im Beispiel wird netstat -tupan aller 2 Sekunden in einen Fester ausgeführt. multitail /var/log/apache2/access.log /var/log/mail.log -I /var/log/auth.log -R 2 -l "netstat -tupan" Falls man die Fenster auch noch vertikal teilen möchte geht das natürlich auch. Der Parameter -s gibt an wieviele vertikal Fenster erstellt werden sollen. multitail -s 2 /var/log/apache2/access.log /var/log/mail.log -I /var/log/auth.log -R 2 -l "netstat -tupan" FazitMultitail ist für mich eine bessere und komfortablere Variante mehrere Logfile zu betrachten. Multitail ist sehr gut an die persönlichen Bedürfnisse und Vorlieben anpassbar. Einstellungen können global in /etc/multitail.conf oder für jeden User in der .multitailrc angepasst werden. Eine sehr umfangreiche Dokumentation findet man auf der Projektseite von Multitail http://www.vanheusden.com/multitail/ oder in den Manpages. Dienstag, 3. Juli 2012Das Problem mit der Schaltsekunde
Durch eine am Wochenden eingefügte Schaltsekunde gab es auf vielen Linux-Servern ein Problem mit der CPU-Load. Das ging von 100% CPU-Usage auf einem oder mehreren Cores bis zum kompletten Absturz. In der Verzweiflung haben viele Admins (so wie ich auch erstmal, bevor das Problem langsam klar wurde) mit Reboots die Rettung erzwungen. Inzwischen ist das Problem aber bekannt, so dass man zum Beispiel mit folgendem Befehl die Last wieder normalisieren kann:
date; date `date +"%m%d%H%M%C%y.%S"`; date;Vor Allem betroffen waren Systeme mit MySQL und auf Java basierenden Applikationen (Tomcat etc.). Hoffen wir also, dass bis zur nächsten Schaltsekunde ein Fix direkt im Kernel integriert wird. Der Webhoster Hetzner informierte seine Kunden sogar per Mail darüber, dass diese doch bitte mal ihre Server prüfen sollen. Durch den Anstieg der CPU-Load auf tausenden Servern ist dort der Stromverbrauch angeblich im 1 Megawatt (!) gestiegen. Es lohnt also generell die Kontrolle des eigenen Servers. Freitag, 29. Juni 2012owncloud - die eigene Wolke!
Die Cloud… Cloud… Cloud… kein Tag vergeht, keine Fachzeitschrift kann man aufschlagen, ohne über die "Cloud" zu stolpern. Da dachten wir uns "Wenn schon Cloud, dann wollen wir unsere eigene Cloud!".
In den nachfolgende Zeilen werde ich Euch durch die wirklich kinderleichte Installation der "owncloud" führen. Danach seid Ihr in der Lage Eure eigene "Cloud" zu betreiben. Für den Familien-Betrieb der owncloud reicht ein mittlerer VServer aus. Auf einem minimalen Debian-System installiert man die benötigen Pakete. apt-get install apache2 php5 php5-gd php5-sqlite curl libcurl3 libcurl3-dev php5-curl bzip2 Danach holen wir uns die aktuelle Version von der ownclound-Projektseite. Derzeit ist die 4.0.4 aktuell. wget http://download.owncloud.org/releases/owncloud-x.x.x.tar.bz2 Wir entpacken das Archiv und kopieren es in unser Documentroot des Webservers. tar -xjf owncloud-x.x.x.tar.bz2 Danach aktivieren wir noch ein paar Apache-module a2enmod rewrite und passen unsere Konfiguration an. (die einfachste Methode) vi /etc/apache2/sites-available/default Dann steht unsere owncloud unter http://unser.server/owncloud/ bereit. Beim Erstaufruf der Seite vergeben wir Name und Passwort des administrativen Benutzers. Nun können wir im Backend weitere Einstellungen tätigen und die Cloud für weitere User freigeben. Derzeit läuft die Datenbank mit SQLite, falls ihr MySQL bevorzugt installiert Ihr einfach den MySQL-Server und könnt beim Erstaufruf von http://unser.server/owncloud/ unter dem Punkt erweitert auch die Zugangsdaten für den MySQL-server eingeben. FazitLeider ist in der Community Edition keine HA/Replikation möglich. Eine Übersicht der Unterschiede zu den Pro-Versionen findet ihr hier. Die Community-Version der owncloud hat mich persönlich enttäuscht. Der gebotene Funktionsumfang ist sehr rudimentär und die fehlende Replikation konnten meine Erwartungen nicht erfüllen. Im Bereich Hobby/Familie dennoch ein interessantes Projekt. Was habt ihr für Erfahrungen mit der Owncloud? Dienstag, 26. Juni 2012Pakete vom Update aussschließen (Debian/Ubuntu)
Oft ist es sinnvoll die Aktualisierung eines Paketes zu verhindern oder etwas zu verzögern. Um Trotzdem wie gewohnt den Paketmanager zu nutzen, müssen wir die Paket von der Aktualisierung ausschliessen. Das funktioniert, indem wir ihm den Status hold verpassen.
Ausgangssittuation#apt-get upgradeWir wollen nun verhindern, dass libgcrypt11 zukünftig aktualisiert wird. Pakete auf hold setzendpkg (apt-get) #echo "libgcrypt11 hold"|dpkg --set-selections aptitude #aptitude hold libgcrypt11 Auflisten der Paket die auf hold gesetzt sindUm eine Übersicht zu erhalten, welche Pakete wir ausgeschlossen haben, verwenden wir: dpkg (apt-get) #dpkg --get-selections |awk '$2 == "hold" { print $1 }' aptitude #aptitude search ~ahold KontrolleNun sollte bei einem upgrade das Paket libgcrypt11 ausgeschlossen werden. #apt-get upgrade Paket auf unhold setzenUm das Paket wieder in das regelmäßige Update aufzunehmen setzen wir den Satus wieder in den Ausgangszustand. dpkg (apt-get) #echo "libgcrypt11 install"|dpkg --set-selections aptitude #aptitude unhold libgcrypt11 KontrolleNun sollte das Paket wieder in den Aktualisierungen vorhanden sein. #apt-get upgrade Dieses Verfahren ist eher die Ausnahme als die Regel. Bitte denkt daran, Eure Systeme stets aktuell zu halten. Montag, 7. November 2011Schutz bei (D)DOS Angriffen mit Iptables
Es soll ja vorkommen, dass ein Server von extern z.B. mit sehr vielen HTTP-Anfragen lahmgelegt werden soll. In so einem Fall ist guter Rat teuer, um Schaden vom Server und der darauf laufenden Websites bzw. Applikationen abzuwenden. Oft hilft einem auch der ISP dabei, verlassen kann man sich darauf freilich nicht. So wurde kürzlich bei einem Fall der Kunde zwar sogar von Hetzner über die DDOS-Attacke informiert Gegenmaßnahmen wurden aber nicht getroffen. Im schlimmsten Fall droht sogar die Sperrung der IP seitens Hetzner, was natürlich zum Teil auch nachvollziehbar ist.
Serverseitig kann man aber auch etwas tun, z.B. das kleine Shell-Script (D)DoS Deflate laufen lassen. Dieses kleine Script prüft ganz einfach per netstat, welche IP eine in der Config definierte Anzahl von Verbindungen überschreitet und sperrt diese wirksam direkt via iptables (diese Variante bevorzuge ich, es wird einfach DROP auf alle Pakete von der Quell-IP angewendet) oder via apf (Advanced Policy Firewall). Das Script hilft natürlich nur, wenn der Server noch erreichbar ist und arbeitet, d.h. wenn die Attacke nicht die die komplette Bandbreite verbraucht oder zu extrem ist. Zur "Installation", die im Wesentlichen aus ein paar Downloads via wget und der Einrichtung eines Cronjobs funktioniert, holt man sich einfach wie auf der Website angegeben das Script install.sh von einem Server. Alternativ habe ich das Ganze hier nochmals als Mirror hinterlegt: ddos.tar (20 KByte). Den Tarball einfach z.B. nach /usr/local/ entpacken und es kann losgehen. In der ddos.conf kann man via NO_OF_CONNECTIONS angeben, ab wievielen Verbindungen eine IP gesperrt wird. Das muss man einfach testen bzw. es kommt sehr darauf an, was auf dem Server normalerweise los ist. Bei zu niedrigen Werten läuft man natürlich Gefahr, auch "normale" User zu sperren. Mit BAN_PERIOD legt man dann fest, wie lange die IP gesperrt werden soll. Die eigene IP kann man übrigens mit einem Eintrag (neue Zeile) in der Datei ignore.ip.list whitelisten, 127.0.0.1 ist default auf der Whitelist Jetzt kann man direkt ./ddos.sh ausführen und sieht auch direkt den Output den im Script ausgeführten netstat, das konkret so aussieht: netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nAlle IPs mit einer Connection-Anzahl > NO_OF_CONNECTIONS werden nun also für BAN_PERIOD Sekunden gesperrt. Ein Cronjob, der am besten im Abstand läuft, wie auch BAN_PERIOD gesetzt ist, rundet die Config ab. Erfolge kann man dann ganz einfach z.B. via iptables -L -nv sehen. Diese recht rudimentäre Lösung kann bei kleineren Angriffen durchaus nützlich sein und hat sich schon mehrfach im Einsatz bewährt. Hilfreich sind übrigens auch weitere IP-Adressen und kurze TTL im DNS, um schnell reagieren zu können. Sollte der Angriff nur auf einzelne Dienste wie z.B. Apache durchgeführt werden, lohnt auch ein Blick auf Fail2Ban. Donnerstag, 3. November 2011Top of the Tops
Prozess-Informationen (ps oder pstree) und CPU- und Speicherauslastung eines Linux-Systems (top, vmstat oder free) gehören wohl zu den am häufigsten benutzten Kommandos eines Admin, der für Linux-Server verantwortlich ist. In den meisten Fällen schaut man nach einem SSH-Connect ja erstmal, was auf der Maschine so los ist, zu der man sich gerade verbunden hat.
Für mich ist das schon fast eine Obsession, schließlich bin ich Statistik-Fan. Neben dem auf jedem System vorhandenen top (welches man auch ganz gut anpassen kann) haben sich mit der Zeit noch ein paar andere Tools in meine tägliche Nutzung eingefügt, die auf keinem Server fehlen. Klarer Favorit und inzwischen nahezu 100%iger Ersatz für top ist für mich htop. Grafisch ansprechender aufbereitet zeigt es die Auslastung der einzelnen CPU-Cores live mit einem Balken an und fühlt sich generell irgendwie moderner an. Ein weiterer Vorteil ist, dass htop schneller startet als top, da top erst einige Daten sammelt. Weitere Unterschiede sind hier aufgelistet. In Debian und CentOS ist es aus der Distribution problemlos zu installieren. Das Schweizer Taschenmesser der "Tops" ist aber atop. Es zeichnet sich vor Allem dadurch aus, dass es deutlich mehr Statistiken und Daten liefert als top, nämlich z.B. "Disk Utilization" und "Network Utilization" je Prozess. Außerdem loggt atop periodisch diverse Systemparameter, die sich dann mit dem mitgelieferten Tool atopsar darstellen lassen. Dafür läuft dann allerdings permanent ein atop Prozess auf dem System. Wer keinen eigenen Dienst laufen lassen möchte oder atop nicht nutzt, die Systemlast aber trotzdem permanent überwachen möchte, kann sich atsar mal anschauen. Hier wird im Grunde wie bei atop der Zustand periodisch geloggt und man kann im sich problemlos die Loadavg oder Disk Utilization der letzten Tage anschauen. Weitere Live-Tools für diverse Anwendungsfälle, die ich häufig sinnvoll einsetze sind zum Beispiel apachetop, womit sich live sehen lässt, welche Dateien am häufigsten aufgerufen werden, oder iotop. Mit iotop kann man schön sehen, was gerade an I/O auf den Platten los ist und welche Prozesse dafür verantwortlich sind. Zum Schluss noch der Hinweis auf ein "grafisches" Tool auf der Shell, womit sich der Traffic von Netzwerk-Interfaces ziemlich gut darstellen lässt: nload. Hiermit sieht man recht gut, was gerade an Traffic über ein bestimmtes Interface geht samt Durchschnittswerten. Natürlich gibt es noch dutzende weiterer Tools. Hinweise oder Tipps in den Kommentaren dazu sind natürlich erwünscht Montag, 24. Oktober 2011Acer EasyStore H341 als NAS für SMB und AFP mit Ubuntu Server
Nachdem meine Synology DS207 mit ihren 2x1TB (RAID1) Platten zu klein und auch generell zu langsam wurde, musste eine Neuerung her. Möglichst auch mit Verschlüsselung und mehr Kontrolle über das eigentliche System. Denn neben den Änderungen von Apple in der AFP-Implementation und der Tatsache, dass ältere Netatalk-Versionen dann plötzlich nicht mehr mit Lion reden wollten, nervte die Abhängigkeit vom Hersteller Synology schon extrem. Klar, nach ein paar Wochen kam dann das Update, so dass TimeMachine und AFP wieder korrekt funktionierten, mit einer eigenen Lösung hätte man das aber deutlich schneller hinbekommen.
Also fiel die Wahl auf einen "Home-Server" mit Atom-CPU, konkret auf den Acer EasyStore H341. Das Gehäuse ist mit 4 HDD Plätzen ausgestattet, so dass ich in meiner Ausbaustufe mit 4x2 TB Platten (Seagate Barracuda LP, ST32000542AS) auf 8 TB Plattenplatz komme. Die Intel Atom D410 mit 2 Threads und 1.66 Ghz samt 2 GB RAM ist zwar nicht der Renner, erschien aber erstmal ausreichend. Leider verfügt das Board nur über einen einzigen LAN-Anschluss (Realtek, GBit). Viel schlimmer ist aber die Tatsache, dass kein VGA-Anschluss im Auslieferungszustand vorhanden ist. Somit ist es natürlich sehr schwer, andere Betriebssysteme als das bereits auf einer internen USB Disk (256 MB) vorhandenen Windows zu installieren. Abhilfe schafft ein optionaler VGA-Adapter (ca. 30 EUR bei Amazon), der samt Low-Profile-Adapter recht einfach in das Gehäuse gesteckt wird. Klappte hier sofort ohne Probleme. Außerdem sollte man wissen, dass nur USB und kein PS-2 vorhanden ist. Eine USB Tastatur sollte man also auch besitzen. Mit einem USB-DVD ging es dann also an die Installation. Testweise kam erstmal Freenas 7 zum Einsatz, welches locker auf die interne 256 MB USB-Disk passte. Da aber in Freenas 7 die AFP-Implementation leider veraltet ist, war dies wirklich nur ein kurzer Test. Keine Chance, TimeMachine lauffähig zu bekommen. Außerdem war mit Freenas 7 und einem verschlüsselten ZFS-Volume die Performance grauenvoll, was wohl an der schwachen CPU lag (nur gut 15 MB/s Durchsatz!). Mit der kürzlich veröffentlichten Version 8 von Freenas - von einem 2 GB USB-Stick gebootet - ging zwar AFP reibungslos, leider ist dort aber noch keine Verschlüsselung implementiert. Außerdem hat Freenas grundsätzlich das gleiche Problem wie eine "fertige" NAS, nämlich die Abhängigkeit seitens der Herausgeber. Daher fiel die Wahl nach den ganzen Freenas-Experimenten zuerst auf Debian Squeeze. Der Kernel wollte aber leider nicht mit der Hardware zusammenarbeiten (USB ging nicht, somit auch keine Tastatur etc.), so dass dann doch Ubuntu Server zum Einsatz kam. Hier lief die Installation sofort problemlos und die Hardware wurde komplett erkannt. Bei der Installation entschied ich mich wegen der schwachen CPU ohne Hardware-AES-Support gegen komplett verschlüsselte Platten. Es kommen nunmehr mehrere "kleine" Crypto-Container mit je 1-10 GB zum Einsatz, die an die entsprechenden Stellen gemountet werden. Somit sind nur wirklich wichtige Sachen verschlüsselt und die Performance passt. Die Platten wurden in einem Software-RAID10 zusammengefasst und mit ext4 formatiert. Wegen der hohen Schreibrate durch Backups etc. erschien das hier als die bessere Wahl gegenüber RAID5, zumal 4 TB netto immernoch genug Speicherplatz sind. Zur Performance später mehr. Nach der Installation des Grundsystems ging es an die Serverdienste. Hier standen in erster Linie AFP für die Macs und Samba für die Windows-Kisten zur Debatte. Samba war leicht konfiguriert, schließlich sollten nur 2-3 Shares eingerichtet werden. Die Nutzer wurden jeweils als normale Linux-User eingerichtet, wogegen sich dann die Dienste authentifizieren. Ein wenig schwieriger war hingegen die Installation von netatalk für AFP. Wegen der Kompatibilität musste es unbedingt die neueste Version 2.1.1 sein, die natürlich nicht in der Distribution verfügbar war. Zum Glück stellt Stefano Rivera auf Launchpad fertige Pakete der neuesten Version für Ubuntu bereit, die sich problemlos installieren ließen. Ein paar Shares inklusive TimeMachine waren dann schnell eingerichtet und es funktionierte sofort problemlos. Und zwar genau so, wie ich es wollte, also mit Freigaben auf Gruppen- und Userebene. Dank "avahi-daemon" wird die NAS auch von Macs als Server erkannt und kann direkt im Finder angesprochen werden. Außerdem wird die NAS noch als OpenVPN Gateway benutzt, was auch problemlos geht und unter Freenas schon ein kleiner Krampf war. Zur Überwachung kommt mdadm samt smartd zum Einsatz, womit sich Festplatten-Ausfälle zeitnah erkennen lassen sollten. Im Idealfall können ja in der RAID10-Konstellation sogar 2 der 4 Platten ausfallen. Zur Performance kann ich mich weitestgehend positiv äußern. Nachdem der initiale Raid-Sync nach 30h (!) abgeschlossen war, erreiche ich bei lokalen Tests mit "dd" eine Schreibrate von über 140 MB/s im groben Schnitt. Via AFP sind es über GBit-LAN immernoch ausreichende 60 MB/s im Schnitt. Zu SMB liegen keine Messwerte vor, langsam erscheint es aber von Windows-PCs aus nicht. Das sind Werte, von denen ich mit der alten Synology-NAS nur träumen konnte. Klar, die CPU könnte schon stärker sein. Bei simultanen Zugriffen merkt man schon, dass das der Flaschenhals ist. Für den Heimbereich oder, wie bei uns, im Büroeinsatz ist das Gerät aber ansich durchaus zu empfehlen. Denn für unter 500 EUR inkl. Platten hat man eine redundante, einigermaßen flotte und komplett selbst verwaltbare NAS-Lösung mit einem Linux-System, was sich perfekt anpassen lässt - so regeln z.B. diverse Cronjobs via "rsync" bei uns das Backup auf entfernte Server etc. Ansich also eine durchaus empfehlenswerte Lösung. Es soll wohl einen Nachfolger (?) namens von Acer H342 geben, der dann eine Dualcore CPU hat. Scheint aber nur in den USA verfügbar zu sein. Zumindest gab es nirgends konkrete Infos oder Preise. PS: Sollte Interesse an der konkreten Config unserer NAS bestehen, reichen wir diese gern nach und freuen uns über Kommentare. Donnerstag, 27. Januar 2011Zentraler Loghost mit Komprimierung auf Filesystem-Ebene dank ZFS
Viele unserer (Web)Server loggen auf einen zentralen Logging-Server, der via syslog-ng die Logdaten einsammelt und einheitlich zur Verfügung stellt. Besonders bei Webclustern, wo ein Loadbalancer die Anfragen auf diverse Server verteilt, ist z.B. ein zentrales Apache-Logfile u.A. für die Logfile-Auswertung wünschenswert. Außerdem kann man dann mit logcheck nette Security-Auswertungen etc. für alle Server gemeinsam machen und muss dies nicht auf jeder Kiste einzeln tun.
Bisher lief der Logging-Server auf Linux-Basis, nachts wurden die zig GByte großen Logfiles des letzten Tages dann komprimiert. Das hat soweit auch ganz gut funktioniert, nur leider wird es an der Stelle nervig, wenn man in den Logfiles der letzten Monate etwas sucht und dann beispielsweise 200 GByte an GZIP-Files durchsuchen muss. Ganz davon abgesehen sorgte die nächtliche Komprimierung via logrotate (GZIP) doch für eine ordentliche Serverlast über Stunden hinweg (CPU und I/O gleichermaßen). Als Lösung fiel die Wahl jetzt auf FreeBSD 8.1 als OS für den Loghost. Filesystem ist, wie könnte es anders sein, nun ZFS! Und dank "eingebauter" Komprimierung ist die Verwaltung der Logfiles jetzt deutlich angenehmer. Auf Filesystem-Ebene via GZIP komprimiert ergibt sich für den Nutzer kein Nachteil, die CPU-Last wird nicht mehr auf die Nacht verteilt, sondern permanent beim Schreiben der Files - aber eben kaum merklich, da konstant und minimal. Die Kompressionsrate ist identisch mit der früheren Kompression unter Linux. Neben GZIP stand noch LZJB als Methode zur Auswahl. Das soll wohl schneller sein, komprimiert aber nicht so akkurat wie GZIP. Wie erstellt man nun ein solch komprimiertes Filesystem via ZFS? Man erstellt einen zpool z.B. als RAID-1 via: zpool create data mirror /dev/da1 /dev/da2Nun erstellt man das Filesystem via: zfs create -o compression=gzip -o mountpoint=legacy data/varlogMit -o gibt man die Optionen an, hier gzip. Default ist die Kompression auf Stufe 6 (=ausgewogen) eingestellt, man könnte aber auch gzip-9 für maximale Kompression verwenden. mountpoint=legacy bedeutet, dass ZFS sich nicht um die Verwaltung des Mountpoints kümmert. Default würde dies sonst unter /data/varlog gemountet werden. Da wir aber /var/log haben möchten, behelfen wir uns mit diesem Eintrag in der /etc/fstab: data/varlog /var/log zfs rw 1 0 Tricky war allerdings, dass der Installer selbst dies nicht zur Verfügung gestellt hat (zumindest haben wir es nicht gesehen..). Daher wurde normal mit UFS installiert und anschließend die neue Partition erstellt, gemountet und mit den Inhalten aus der alten UFS-Partition gefüllt. Eine etwas umständliche Methode, die allerdings problemlos funktioniert hat. Die Kompression kann man via ls und du sehr gut nachvollziehen, da ls die ursprüngliche Dateigröße anzeigt. Mit du sieht man dann die tatsächliche Größe auf Platte: # l -h apache_central.log-20110109Insgesamt ein sehr nettes Szenario, um Speicher zu sparen und Logfiles dauerhaft vorzuhalten, ohne sich durch viele GZIP-Files wühlen zu müssen. Die Performance ist ingesamt gut, es gibt eigentlich keine Probleme trotz sehr großer Logfiles, die täglich anfallen. Sonntag, 14. März 2010Chemnitzer Linux Tage 2010 - nächstes Jahr gern wieder
Wie ich in einem meiner vorherigen Beiträge schon erwähnte, verschlug es mich gestern zu den Chemnitzer-Linux-Tagen.
Auf der Veranstaltung angekommen, eröffneten sich uns wieder viele Stände namenhafter Opensource Projoekte, Distributionen und auch Vereinen wie zum Beispiel dem Wikimedia e.V.. Auch die gut gefüllte Bücker-Ecke sowie der Linux-Merchandising-Stand waren freudigerweise wieder vertreten. Es gab jedoch 2 Punkte die ganz besondern hervorstachen. Das waren zum einen die Cafetaria mit ihrer neuen Kuchen/Muffin/Caffee Bar, die auch dieses Jahr kleinere Köstlichkeiten sowie konkurrenzlose Schoko-Muffins bereitstellt, sowie die in diesem Jahr herausragenden Vorträge im Kernel-Track. Angefangen beim Vortrag über Kernel-Debugging mit k(g)db, über den meiner Meinung nach besten Vortrag des Tages vom Kernel-Log Autor des Heise Verlags mit dem Thema "Aktuelle Entwicklung im Linux Kernel", sowie dem abschließenden Vortrag von Frédérick Weisbecker über "ftrace and perf, tracing the linux kernel" waren alle Vorträge von sehr guter Qualität. Für mich steht also jetzt schon fest: Chemnitzer-Linux-Tage 2011 - gerne wieder. Freitag, 15. Januar 2010Chemnitzer Linux Tage 2010 Heute möchte ich euch die Chemnitzer Linux Tage etwas näher bringen. Wie jedes Jahr findet dieser wieder im März (diesmal am 13. und 14. - dick im Kalender einkreisen) in den Hörsaal- und Seminar-Gebäuden der Technischen Universität Chemnitz statt.Eines der Themengebiete des diesjährigen CLT lautet Dienste und Dämonen und soll die Protokolle und ihre Implementierungen, sowie die Anwendungsgebiete und Geschäftsmodelle dem interessierten Linux-Nutzer etwas näher bringen. Andere Themengebiete sind zum Beispiel der Desktops und der Embedded-Bereich. Erstmalig wird es dieses Jahr einen Kernel-Track geben, in dem sich interessierte Nutzer über die Entwicklungen im, sowie das eigentliche Programmieren am Kernel informieren können. Das gesamte Programm (leider noch nicht komplett Fertig) findet Ihr auf dieser Webseite. Auch werden dieses Jahr wieder einige Herrsteller (u.a. AMD, Zarafa, Debian) ihre Produkte vorstellen und mit einem Stand vertreten sein. Für das leibliche Wohl wird ebenfalls gesorgt, denn im oberen Stockwerk wird es wieder eine Cafetaria geben in der man zum kleinen Preis Snacks und Getränke kaufen kann. Die letzten 2 Jahre waren auf jedenfall sehr interessant und einige der Vorträge sehr sehenswert. Als Geheimtipp kann ich euch den Vortrag von Hans-Jürgen Schönig über PostgreSQL empfehlen. Dieser war die letzten 2 Jahre, wenn auch nicht der informationsreicheste, jedoch vom Humor und der Durchführung der beste Vortrag der ganzen CLT (Hans-Jürgen FTW Auch die Eintrittspreise sind sehr Human gehalten. Das Wochenendticket kostet 5 EUR, sowie ermäßigt 3 EUR. Es würde mich freuen wenn sich ein paar von euch durch den Artikel anmimieren lassen, die Chemitzer Linux Tage einmal zu besuchen. Bis dahin und eventuell sieht man sich ja auch da. Montag, 14. Dezember 2009[TIPP] lesspipe - Schweizer Taschenmesser für less
Den Reader less benutzt vermutlich jeder Admin mehr oder weniger oft für alle Arten von Textfiles. Für mit Gzip komprimierte Dateien gibt es dann noch zless, was immerhin das Entpacken spart. Manchmal weiss man allerdings nicht gleich, um was für ein File es sich handelt. Und jedes Mal file aufzurufen, ist auch nervig.
Aber dafür gibt es das kleine Bash-Script lesspipe, was zumindest auf Debian und CentOS vorinstalliert ist. Ich denke mal, andere Distributionen haben es auch vorinstalliert. Falls nicht, gibt es hier den Download. Beim Aufruf spuckt lesspipe die benötigten Variablen aus, die gesetzt werden müssen, damit es funktioniert: export LESSOPEN="| /usr/bin/lesspipe %s";Schreibt man diese Zeilen oder eben "eval `lesspipe`" in seine .bashrc, kommt man in den Genuss mit dem gewohnten Aufruf von less eine Vielzahl von Dateitypen ansehen zu können. Eine Liste der Typen gibt es in der README. Dienstag, 1. Dezember 2009Linux resource limits auslesen
Heute mal ein etwas kürzerer Beitrag von mir. Ich stand vor kurzem vor dem Problem die default resource limit Werte meiner Linux-Box auslesen zu müssen, um zu wissen ob ein Programm mit der zu testenden Konfiguration auch wirklich sauber läuft (im speziellen ging es um die Möglichkeit den virtuellen Speicher des Prozesses komplett im Hauptspeicher zu behalten, welches mit mlock() möglich ist, es gibt aber ein resource limit, nämlich RLIMIT_MEMLOCK welches die größe beschränkt). Da ich weder ein Tool, noch sonst irgend etwas gefunden habe, was dies möglich macht, habe ich es einfach selber gecoded
Eventuell benötigt einer von euch das ja irgenwann einmal. Das Tool, welches ein quickhack in C ist Kompiliert bekommt Ihr das ganze via gcc -o getrlimits getrlimits.c.
(Seite 1 von 5, insgesamt 71 Einträge)
» nächste Seite
|
SucheImpressumArchiveKategorien |
Kommentare