Tag Archive for 'Linux'

sshfs – Mounten über SSH

Ich weiß gar nicht, ob Sie’s schon wussten (Rüdiger Hoffmann), aber Dateisysteme können auch sehr einfach über SSH zwischen Servern gemountet werden. Das Schöne an sshfs ist der minimale Installationsaufwand und das keinerlei Freigaben wie beispielsweise /etc/exports (NFS) oder /etc/samba/smb.conf (Samba) gepflegt werden müssen. Da sshfs – wie der Name schon vermuten lässt – auf SSH basiert, bekommt man eine saubere Authentifizierung und Verschlüsselung quasi “für umme” dazu.

Wie funktioniert nun die Raketentechnik?

Auf host-1 wird ein Testverzeichnis mit einer Testdatei vorbereitet. Mehr nicht.

host-1# mkdir /tmp/testfolder
host-1# touch /tmp/testfolder/testfile
host-1# ls /tmp/testfolder/
testfile
host-1#

Um nun auf host-2 das Verzeichnis /tmp/testfolder von host-1 zu mounten wird lediglich sshfs, ein SSH Account auf host-1 und die Zugriffsrechte im Dateisystem von host-1 benötigt.

host2# apt-get install sshfs
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
sshfs
0 upgraded, 1 newly installed, 0 to remove and 57 not upgraded.
Need to get 44.1 kB of archives.
After this operation, 160 kB of additional disk space will be used.
Get:1 http://ftp.de.debian.org/debian/ squeeze/main sshfs amd64 2.2-1 [44.1 kB]
Fetched 44.1 kB in 0s (121 kB/s)
Selecting previously deselected package sshfs.
(Reading database ... 40742 files and directories currently installed.)
Unpacking sshfs (from .../archives/sshfs_2.2-1_amd64.deb) ...
Processing triggers for man-db ...
Setting up sshfs (2.2-1) ...
host2#
host2# sshfs testuser@host-1:/tmp/testfolder /mnt
testuser@host-1's password:
host2#
host2# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
testuser@host-1:/tmp/testfolder
5.0G 701M 4.0G 15% /mnt
host2#
host2# ls /mnt/
testfile
host2#

Letztendlich ist es so einfach das es schon wieder Genial ist icon smile sshfs   Mounten über SSH

share save 171 16 sshfs   Mounten über SSH

Mal sehen wer es versteht…

Da ich heute eigentlich gar keine Lust habe einen Blogpost zu schreiben, euch aber noch einmal auf etwas ganz wichtiges hinweisen möchte, versuche ich es mal mit einer etwas technischen Variante icon wink Mal sehen wer es versteht...

netways-jobs $# who
Linux Consultant (m/w) mit Fokus auf Systems Management
Systems Engineer (m/w)
netways-jobs $#
netways-jobs $#
netways-jobs $# date
Ab sofort
netways-jobs $#
netways-jobs $#
netways-jobs $# cat /proc/modules | grep -i important
Sehr gute Kenntnisse über Linux Systeme und -Netzwerktechnologien
Gute Kenntnisse über linuxbasierte Netzwerküberwachung, insbesondere Nagios und Icinga
Gute Kenntnisse von Webtechnologien wie MySQL, Apache, Heartbeat, LVS, usw.
Gute Kenntnisse in Bash, Perl
Gute Kenntnisse über Windows-Systeme und -Netzwerktechnologien
netways-jobs $#
netways-jobs $#
netways-jobs $# apt-get install lernbereitschaft motivation teamfaehigkeit
netways-jobs $#
netways-jobs $#
netways-jobs $# cat /proc/cpuinfo
processor : 0
cpu family : human
model name : male / female
physical id : 1

processor : 1
cpu family : human
model name : male / female
physical id : 1

processor : 2
cpu family : human
model name : male / female
physical id : 1

processor : 3
cpu family : human
model name : male / female
physical id : 1
netways-jobs $#
netways-jobs $#

Wenn ihr wisst was euch der Author dieses Blogposts vermitteln möchte, solltet ihr euch sofort unter jobs.netways.de bewerben icon smile Mal sehen wer es versteht...

share save 171 16 Mal sehen wer es versteht...

OpenLDAP 2.4.x und die ACL

OpenLDAP ACL

In vergangenen Blogposts habe ich erwähnt welche Möglichkeiten OpenLDAP 2.4.x bei der Replikation bietet und wie man neuerdings weitere Schema zu OpenLDAP hinzufügen kann.
Mit dem dynamischen Backend cn=config hat sich auch das bearbeiten der ACL (Access Control List) verändert.
Unter OpenLDAP < 2.4.x war die slapd.conf die richtige Anlaufstelle um Benutzern, Gruppen etc. den Zugriff auf bestimmte Attribute, Objekte, Teilbäume... zu ermöglichen.
cn=config als dynamisches Backend fordert hier eine neue Vorgehensweise um die ACL zu administrieren.

Generell gibt es zwei Möglichkeiten neue Zugriffsrechte zu definieren oder bestehende zu ändern.

  • Änderungen direkt in das entsprechende Backend-LDIF eintragen (olcDatabase={1}hdb oder olcDatabase={1}bdb).
  • Änderungen über ein separates LDIF File mit ldapadd oder ldapmodify zu importieren.

Wie bei allen Dingen die im Backend geändert werden gilt auch hier, alle Änderungen werden während der Laufzeit übernommen und erfordern keinen Reload des OpenLDAP Daemons.

Nun aber ans Eingemachte…

Bevor wir eine Access Control List aufbauen können, müssen wir wissen wie die Definition auszusehen hat und welche Möglichkeiten der Definition es gibt.
Die Definition einer ACL hat sich zu älteren OpenLDAP Versionen nicht groß geändert und immer den Folgenden grundlegenden Aufbau:

olcAccess: {n} to "what" by "who" "access"

Was in vollendeter Form z.B. so aussehen kann:

olcAccess: {2}to dn.subtree="ou=company,dc=netways,dc=org" by group.exact="cn=admins,ou=users,dc=netways,dc=org" write by * read by anonymous none

Das Beispiel ermöglicht den Mitgliedern der Gruppe “admins” Schreibrechte auf den Inhalt der Organisationseinheit “company”. Andere Benutzer haben Leserechte und Anonyme haben keinerlei Rechte.
Die {2} definiert die Reihenfolge der Verarbeitung. Die Access Control List wird von oben nach unten abgearbeitet. Regeln mit {1} greifen vor Regeln mit {2}, {3} etc… und werden auch so angewendet.
Eine Standardregel, die meist sehr weit oben in der ACL angesiedelt ist, lautet:

{1}to * by self write by dn="cn=admin,dc=netways,dc=org" write by * read

Diese Regel verhindert meist das folgende Regeln überhaupt Wirkungsvoll sind. Die Regel sagt aus das Überall der Benutzer “admin” Schreibrechte hat und jeder andere Benutzer Leserechte hat (und Benutzer auf die eigenen Objekte Schreibrechte haben). Ist diese Regel weit oben in der ACL angesiedelt haben die darauf folgenden Regeln meist keine Wirkung, daher empfiehlt es sich hier die Reihenfolge anzupassen.

Eine sehr detaillierte Anleitung über die Möglichkeiten der Definitionen gibt hier die OpenLDAP 2.4 Dokumentation: http://www.openldap.org/doc/admin24/access-control.html

Die Dokumentation entält, meiner Meinung nach, eine sehr gute und verständliche Beschreibung der “what” Definition:
0: o=suffix
1: cn=Manager,o=suffix
2: ou=people,o=suffix
3: uid=kdz,ou=people,o=suffix
4: cn=addresses,uid=kdz,ou=people,o=suffix
5: uid=hyc,ou=people,o=suffix

dn.base=”ou=people,o=suffix” trifft 2
dn.one=”ou=people,o=suffix” trifft 3 und 5
dn.subtree=”ou=people,o=suffix” trifft 2, 3, 4 und 5
dn.children=”ou=people,o=suffix” trifft 3, 4 und 5

Welche unterschiedlichen Möglichkeiten der “what” “who” und “access” Definition man hat beschreibt das Schaubild unter “8.2. Access Control via Static Configuration”.

Bisschen was aus der Praxis…

Damit dieser Blogpost nicht allzu theoretisch wird ein paar Code snippets die das Thema ACL ggf. etwas leichter machen.

Definitionen zur ACL hinzfügen:

changetype: add
add: olcAccess
olcAccess: to dn.subtree="ou=company,dc=netways,dc=org" by group.exact="cn=admins,ou=users,dc=netways,dc=org" write by * read

Neue Definitionen werden in der Liste ganz am Ende aufgeführt und bekommen immer die höchste Listenzahl {}

Definition in der ACL ändern:

changetype: modify
delete: olcAccess
olcAccess: to dn.children="ou=contacts,dc=netways,dc=org" by * search
-
add: olcAccess
olcAccess: to dn.children="ou=contacts,dc=netways,dc=org" by * write
-

Definitionen abändern erfordert ein “delete: olcAccess” und ein “add: olcAccess”. Die “-” sind im LDIF wichtig.

Definition an bestimmter Stelle in ACL ändern:

changetype modify
delete: olcAccess
olcAccess: {1}
-
add: olcAccess
olcAccess: {1}to dn.children="ou=contacts,dc=netways,dc=org" by * write
-

Hier wird der Inhalt von {1} mit dem neuen überschrieben.

Noch was Gutes zum Schluß…

Das Backend cn=config kann mit der Zeit sehr groß und sehr komplex werden.
Insbesondere dann wenn die ACL sehr groß geworden ist.
Zur Administration des Backends ist es daher Empfehlenswert auf einen gut strukturieren und übersichtlichen LDAP Browser / Editor zurück zu greifen.
Ich verwende sehr gerne Apache Directory Studio oder unter Windows LDAPAdmin.
Eine Verbindung zur cn=config erfolgt über den administrativen Backendbenutzer (meist cn=Manager,cn=config oder cn=admin,cn=config) und über die BaseDN cn=config.

share save 171 16 OpenLDAP 2.4.x und die ACL

Server-Monitoring mit Icinga im aktuellen c’t Sonderheft

ct sonderheft 211x300 Server Monitoring mit Icinga im aktuellen ct SonderheftAnlässlich des 20. Linux-Geburtstags im vergangen September hat sich der Heise-Verlag für Ausgabe des nun siebten Sonderhefts mit dem Schwerpunkt Linux entschieden. Wir freuen uns sehr die Ausgabe mit einem Artikel zum Thema “Server-Monitoring mit Icinga” bereichern zu können.

Schwerpunkt des Artikels ist eher die Überwachung kleinerer Umgebungen oder des eigenen Root-Servers als die großer Enterprise-Umgebungen. Icinga ist aber natürlich für beide Szenarien bestens geeignet und viele grundlegenden Rahmenbedingungen sind letztendlich unabhängig von der Infrastrukturgröße zu beachten.

Der Artikel beschreibt kurz die Installation unter Ubuntu und erläutert dann sehr detailliert die Einrichtung der klassischen Basischecks und der standardmässigen Email-Alarmierung. Für jeden der die Zuverlässigkeit des eigenen Servers kurz und knackig überwachen will ist der Artikel ein Muss icon smile Server Monitoring mit Icinga im aktuellen ct Sonderheft

share save 171 16 Server Monitoring mit Icinga im aktuellen ct Sonderheft

Schorsch erzählt: Ausbildung erfolgreich abgeschlossen

Teil 9 von 9 in der Blogserie Becky + Schorsch erzählen

gmimietz Schorsch erzählt: Ausbildung erfolgreich abgeschlossen

Lange ist es her, aber nun bin ich zurück – mit guten Nachrichten. Heute hatte ich nun meine letzte Prüfung – es war die mündliche Praxisprüfung zu meinem Projekt und ein Fachgespräch zu allgemeinen Ausbildungsthemen. Mein Projekt war die “Integration einer Backuplösung bei einem Kunden der NETWAYS GmbH”. Darin enthalten war die Auswahl und Beschaffung eines Systems, die Einrichtung und Installation des Raid, Netzwerkes und Betriebssystems, sowie natürlich die komplette Einrichtung einer Backupumgebung mit Bacula – auch das Einbinden von den Clients und die Einrichtung eines Webinterfaces war im Projekt inbegriffen.

Für das Setup sollte ich eine Dokumentation in 20-Seitiger Länge und 6-facher Ausfertigung der IHK bereitstellen, dies geschah jedoch schon vor 6 Wochen. Heute war also nur die Präsentation zur Ergänzung der Dokumentation und das Fachgespräch.

Es sind viele Projektbezogene Fragen gewesen, aber auch allgemein zu IT und auch Wirtschaft – denn wer hat es geahnt; der Fachinformatiker ist ein kaufmännischer Beruf. Nach gut 45 Minuten Präsentation und Fachgespräch bekam ich das OK von den Prüfern und konnte meine Sachen wieder zusammen packen. Kurz danach habe ich erfahren, dass ich meine Prüfung bestanden habe. Jetzt bin ich also nicht mehr Junior Systems Engineer sondern “nur” noch Systems Engineer – oder auf Deutsch: Fachinformatiker für Systemintegration.

Außerdem bin ich mit dem Bestehen dieser Prüfung nahtlos in das Angestelltenverhältnis bei NETWAYS übergegangen.

Jetzt fällt mit einem Mal der Prüfungsstress und die Anspannung der letzten 3 Monate ab und ich kann mich wieder der doch bevorzugten Arbeit widmen.

Also dann bis zum nächsten Blog – wahrscheinlich geht’s dann eher um eine technische Lösung


share save 171 16 Schorsch erzählt: Ausbildung erfolgreich abgeschlossen

Backporting – Quick and a bit dirty

debian-logo

Oftmals steht man vor der Problematik, dass man auf seinem Produktivsystem eine aktuellere Version von einem Programm benötigt als sie bereits im Repository der stabilen Ausgabe von Debian vorhanden ist. Für solche Problemfälle gibt es das Backports-Projekt, indem aber natürlich auch nicht alle Pakete enthalten sind, da nur selektiv einzelne Pakete aus dem neuen “testing”-Zweig von Debian gegen ein Stable-Environment gebaut werden.
Häufig werden dann die benötigten Programme in aktueller Version selbst übersetzt und somit aus der Paketverwaltung ausgekoppelt, was das Einspielen von Updates erschwert.

Der direktere Weg ist selbst sich Pakete zu backporten. Dies hat folgende Vorteile:

  • Integration in die Paketverwaltung (Vereinfachung beim Einspielen von Updates oder einem Upgrade)
  • durch die Maintainer an das Debian-System angepasst
  • einfache Weitergabe und Verteilung auf mehreren Systemen

Grundlage bietet zunächst eine chroot-Umgebung, damit das System, auf dem Gearbeitet wird nicht “zugemüllt” wird durch diverse dev-Pakete. Das Anlegen eines chroots ist recht einfach und geschieht mit debootstrap (muss als root ausgeführt werden)

root@localhost:~# mkdir chroot_squeeze
root@localhost:~# debootstrap squeeze chroot_squeeze/ http://ftp.de.debian.org/debian
I: Retrieving Release
I: Retrieving Packages
....

Wenn debootstrap die Umgebung gebaut hat, kann mit chroot chroot_squeeze/ /bin/bash in das chroot gewechselt und ohne Gefahr gearbeitet werden. Weiterer großer Vorteil ist, dass wenn was schief geht und das System “zerschossen” wird, man den chroot-Ordner einfach löscht und neu anlegt.
In der chroot-Umgebung sollten zunächst die /etc/apt/sources.list angepasst und um die Source-Quellen erweitert werden. Empfehlenswert ist es zunächst ersteinmal komplett den stable-Zweig von Debian zu verwenden, um die Build-Dependencies von den Stable-Paketen zu installieren. Hintergrund ist, dass so schon einmal der Großteil der benötigten Pakete installiert wird und später schneller und gezielter die fehlenden Abhängigkeiten aufgelöst werden können.

root@localhost:~# chroot chroot_squeeze/ /bin/bash
root@localhost:/# cd ~
root@localhost:~# mkdir icinga ; cd icinga
root@localhost:~/icinga# apt-get build-dep icinga
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
....

Bei diesem Durchlauf sollten keine Fehler bzgl. Abhängigkeiten auftreten. Anschließend kann der Source-Eintrag in der /etc/apt/sources.list auf testing, unstable oder experimental geändert werden, je nachdem aus welcher Quelle man ein Paket benötigt. Anschließend erneut apt-get build-dep ausführen. Wenn hier Abhängigkeitsprobleme auftreten muss versucht werden diese Aufzulösen. In einigen Fällen kann es bedeuten, dass man zunächst andere Pakete backporten muss, damit die Abhängigkeiten der neuen Version stimmen. In unserem Beispiel von Icinga ist das jedoch nicht der Fall.
Es werden nun die Quellen mittels apt-get source icinga geholt und im Anschluss die Version mittels dch -v angepasst. Hierbei sollte man die Versionierung nehmen, wie sie auch beim Backports.org Projekt genutzt wird (paketname-1.0.2-2~xyz60+1 – genaueres ist aus backports.org zu entnehmen).

root@localhost:~/icinga# vi /etc/apt/sources.list
root@localhost:~/icinga# apt-get update
root@localhost:~/icinga# apt-get build-dep icinga
...
root@localhost:~/icinga# apt-get install devscripts #hier ist dch enthalten
root@localhost:~/icinga# cd icinga-1.4.1
root@localhost:~/icinga/icinga-1.4.1# dch --bpo

Nun öffnet sich ein Editor, der einem gleich die changelog Datei anbietet. Hier sollten noch Name und Email-Adresse angepasst werden und ggf. noch die Distribution (squeeze-backports, squeeze-backports-netways ..)
Nach dem Speichern kann das Paket mittels dpkg-buildpackage gebaut werden. Es kann sein, dass hier ebenfalls noch einmal Abhängigkeiten bemängelt werden, die man anschließend versuchen müsste aufzulösen, was jedoch aktuell und in unserem Beispiel nicht der Fall sein sollte.

root@localhost:~/icinga/icinga-1.4.1# dpkg-buildpackage
dpkg-buildpackage: setze CFLAGS auf Standardwert: -g -O2
dpkg-buildpackage: setze CPPFLAGS auf Standardwert: 
dpkg-buildpackage: setze LDFLAGS auf Standardwert: 
...

Ist der Build-Prozess erfolgreich durchgelaufen, liegen im übergeordneten Ordner die fertigen Debian-Pakete inklusive Quellpakete, welche dann in ein eigenes Repository hochgeladen werden können (bspw reprepro).

Ich möchte noch einmal darauf hinweisen, dass es unter unglücklichen Umständen (sehr große Versionssprünge und Abhängigkeitsprobleme) eine etwas umfangreicheres Unterfangen sein kann, ein Paket zurückzuportieren. Jedoch erntet man dafür die Vorteile und kann seine Ergebnisse mit anderen teilen.

share save 171 16 Backporting   Quick and a bit dirty

Puppet External Node Classifier

Puppet Labs Logo Horizontal Sm 300x87 Puppet External Node ClassifierMit Hilfe von Puppet – einem Open Source Configuration Management System – ist es möglich Clients, Server und virtuelle Maschinen effizient zu installieren, verwalten und zu administrieren. Systeme, die von Puppet verwaltet werden, werden über sogenannte “Node-Definitionen”  in Puppet bekannt gemacht und erhalten hierüber ihre Konfiguration in Form von angefertigten Modulen, Klassen und Ressourcen.

node beispielserver.domain.de {
  include beispielklasse
}

Reguläre Ausdrücke werden ebenfalls unterstützt, um z.B. alle “beispielserver123.domain.de” zusammenzufassen.

node /beispielserver\d+.domain.de/ {
  include beispielklasse
}

In manchen Fällen kann es jedoch auch sinnvoll sein, seine Hosts aus externen Quellen (LDAP, MySQL, usw.) zu beziehen. Zum Beispiel mit einer im Unternehmen bereits existierende CMDB. Puppet bietet mit “External Node Classifier” (ENC) die Möglichkeit, externe Quellen abzufragen. Um ENC zu aktivieren, muss die Puppetkonfigurationsdatei puppet.conf um zwei Zeilen angepasst werden.

[master]
node_terminus = exec
external_nodes = /usr/local/bin/puppet_node_classifier

Anschließend wird Puppet seine Hosts nicht mehr in seiner statischen site.pp suchen, sondern übergibt den anfragenden Hostname an das Skript unter dem angegebenen Pfad. Das Skript kann ebenfalls wie Puppet in Ruby geschrieben sein oder in einer anderen Skript- oder Programmiersprache die YAML unterstützten, z.B Perl, C, PHP u.v.m.

Die Ausgabe des Skripts an stdout in YAML formatiert sieht wie folgt aus und entspricht der Node-Definition im erst genannten Beispiel:

---
classes:
- beispielklasse
...

Außerdem muss das Skript als Return-Status “0″ zurückgeben, damit Puppet die Katalogzuweisung erfolgreich durchführen kann und der Host entsprechend der Anweisungen konfiguriert werden kann.

share save 171 16 Puppet External Node Classifier

Debian Web-Updateverwaltung mit Updian

debian-logo

Wer kennt das nicht: Man betreibt viele Server oder virtuelle Maschinen und immer wieder purzeln Updates herein, welche man dann per Hand einspielen darf. Dafür gibt es viele Lösungen, die einem die händische Arbeit abnehmen. Heute möchte ich gern eine auf Debian-Systeme zugeschnittene Variante vorstellen.
Es handelt sich dabei um die Software Updian, ein kleines Tool, welches in PHP geschrieben wurde.

Das Grundprinzip ist schnell erklärt. Updian prüft via SSH die Server, welche es in seiner Liste vorfindet, ob Updates über apt-get verfügbar sind. Dabei wird im Vorfeld die Paketliste aktualisiert. Das Ergebnis wird im Webfrontend dargestellt und man kann selektiv Server zu einer Update-Queue hinzufügen, welche dann abgearbeitet wird. Alle Operationsschritte, also das Sammeln der Informationen, ob Updates verfügbar sind und das Abarbeiten der Queue werden über einen eigenen Cronjob ausgeführt.
Zusätzlich bietet Updian eine “Multi-SSH” Funktion, welche es erlaubt einen Befehl auf allen Systemen auszuführen.
Wenn der Benutzer es möchte, dann kann Updian auch eine E-Mail versenden, wenn es bei einem Prüfungsdurchlauf feststellt, dass Updates verfügbar sind.

Aber kommen wir nun zur Einrichtung von Updian:

Updian ist recht genügsam und es benötigt lediglich die Pakete php5, php5-cli und einen Webserver, der PHP unterstützt.

root@localhost:~# apt-get install apache2 php5 php5-cli

Die Installation von Updian selbst ist relativ unspektakulär. Auf der Projektseite findet man ein Debian-Paket vor, von dem ich aber auf Grund des Alters abrate (seit 2009 wurden keine Änderungen mehr an der Software getätigt). Statt dessen empfehle ich das .tar.gz-File herunterzuladen und im DocumentRoot vom Apache zu entpacken.

root@localhost:/var/www# wget http://www.robhost.de/updian/updian_v0.2.tar.gz
root@localhost:/var/www# tar xvfz updian_v02.tar.gz

Nach dem Entpacken sollte ein Ordner “updian” vorhanden sein, indem alle Files liegen. Diesen Ordner sollte man dem Benutzer www-data zuordnen, da Updian in dem Ordner selbst Schreibrechte benötigt.

root@localhost:/var/www# chown -R www-data updian/

Updian bietet eine eigene Konfigurationsdatei (config.php), welche man seinen Wünschen anpassen kann.
Im nächsten Schritt wird ein Benutzer angelegt, welcher die Überprüfung der Systeme durchführt, quasi mit dem der Cronjob ausgeführt wird.

root@localhost:/var/www# adduser updian
Lege Benutzer »updian« an ...
.
.
Geben Sie ein neues UNIX-Passwort ein:
.
.
root@localhost:/var/www#

Anschließend benötigen wir einen SSH-Key, den wir auf den Systemen verteilen können, damit sich Updian ohne Passwortabfrage verbinden kann. Bei der Frage nach einem Kennwort oder Passphrase bitte nur die Entertaste drücken, da wir diesen nicht gebrauchen können.

root@localhost:/var/www# su - updian
updian@localhost:~# ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/updian/.ssh/id_dsa): [ENTER]
Created directory '/home/updian/.ssh'.
Enter passphrase (empty for no passphrase): [ENTER]
Enter same passphrase again: [ENTER]
Your identification has been saved in /home/updian/.ssh/id_dsa.
Your public key has been saved in /home/updian/.ssh/id_dsa.pub.
The key fingerprint is:
00:00:00:00:00:01:00:10:00:00:00:a0:00:00:00:00 updian@localhost
The key's randomart image is:
+--[ DSA 1024]----+
| ..oooEoo|

Damit unsere Systeme den Key auch kennen, muss er noch kopiert werden. Dies geht am Besten auf folgendem Wege:

updian@localhost:~# ssh-copy-id -i ~/.ssh/id_dsa.pub root@remoteserver

Damit regelämßig die Queue abgearbeitet wird und die Überprüfung auf Updates statt findet, müssen noch die entsprechenden Cronjobs angelegt werden. Hierbei empfiehlt es sich die datei /etc/crontab zu bearbeiten und folgende Zeilen hinzuzufügen:

0 8 * * * updian php /var/www/updian/cron_collect.php > /dev/null 2>&1
0 9 * * * updian php /var/www/updian/cron_updates.php > /dev/null 2>&1

In dem genutzten Beispiel wird täglich um 8 Uhr überprüft, ob Updates vorhanden sind und täglich 9 Uhr die Queue abgearbeitet.
Jetzt kann man Updian bekannt geben, welche Server es überprüfen soll. Das geht ganz einfach über das Web-GUI unter dem Punkt “Servers”, dazu ein Bild:

updian1 300x280 Debian Web Updateverwaltung mit Updian

Nun überprüft Updian im festgelegten Intervall (Cronjob) ob Updates verfügbar sind und benachrichtigt einen, sofern man dies auch eingestellt hat.
Wenn Updian feststellt, dass es Updates hat, so zeigt es das in der Startseite “Home” an, wo man auch die Möglichkeit hat, einzelne oder alle Server zur Update-Queue hinzuzufügen. Mit einem Klick auf den Servernamen kann man einsehen welche Pakete in einer neuen Version vorliegen.

updian2 300x216 Debian Web Updateverwaltung mit Updian
Ein wichtiger Hinweis noch zum Schluss! Der Entwickler stuft Updian noch als Beta ein und weist auch darauf explizit hin. Bisher konnten wir im alltäglichen Betrieb keine Fehler erkennen und es hat sich in der Praxis bei vielen Systemen bewährt.

share save 171 16 Debian Web Updateverwaltung mit Updian

Spiegeln unter dem roten Hut

drbd logo small Spiegeln unter dem roten HutIn vielen unserer Umgebungen nutzen wir DRBD zur Spiegelung der Festplatten über zwei Server hinweg. So lassen sich Hochverfügbarkeitskonzepte auch ohne den Einsatz einer shared Storage aufbauen.

DRBD wird bei vielen Distributionen schon im Standart Package Repository mitgeliefert. Die Ausnahme der Regel machen hier die “Kommerziellen”.

Bei SuSE Linux Enterprise Server muss dafür die HA Extension gekauft werden. Bei RedHat ist es leider nicht in der Cluster Suite enthalten. Abhilfe schafft hier das CentOS Extra Repository.

rpm --import http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
yum install drbd83 kmod-drbd83

redhat Spiegeln unter dem roten HutDas ganz klappt bis RHEL 5.6 wunderbar, ab Version 6 stehen leider derzeit noch keine RPM Pakete zur Verfügung.
Kein Problem, kompilieren wir uns das ganz doch einfach selbst und weil wir nicht auf den Kopf gefallen sind bauen wir auch direkt RPM Pakete daraus um uns den Schritt für den zweiten Node zu ersparen.

Fangen wir mit den Vorbereitungen für unser DBRD Menü an:

Zutaten bereitlegen

yum install kernel-devel rpm-build gcc bison flex
wget http://oss.linbit.com/drbd/8.3/drbd-8.3.10.tar.gz
tar xzvf drbd-8.3.10
cd drbd-83.10
cp /boot/config-`uname -r` .config

Zutaten verrühren

./configure --with-km --with-utils
make
cd drbd
make clean all

In den Backofen schieben
Als erstes erstellen wir die DRBD Pakete (DRBD, DRBD Utils, DRBD Hearbeat- und Pacemakerskripte, DRDB-Xen etc.) und anschließend das Paket was uns DRBD als Kernel Modul lädt.

make rpm
make km-pm

Verzehr

cd /root/rpmbuild/RPMS/x86_64 (oder i368)
rpm -ivh drbd-*.rpm

Zum Abschluß können die erstellten DRBD RPM Pakete auf den zweiten Node kopiert und installiert werden.

share save 171 16 Spiegeln unter dem roten Hut

MySQL-Testimports beschleunigen

Für Tests ist es oft notwendig, größere Datenmengen in MySQL zu importieren. Abhängig von der Anzahl der INSERTs kann dies vor allem bei InnoDB sehr lange dauern, da jeder einzelne INSERT-Befehl in einer separaten Transaktion ausgeführt wird und MySQL wartet, bis diese per fsync() auf die Festplatte geschrieben wurden.

Im Produktionsbetrieb ist dieses Verhalten notwendig, um sicherzustellen, dass erfolgreich durchgeführte Transaktionen z.B. einen Stromausfall überdauern. Bei Testsystemen auf denen ausschließlich “Wegwerf”-Datenbanken verwendet werden oder beim initialen Einrichten von MySQL-Slaves, kann mit einem Trick etwas Zeit beim Import eingespart werden.

Hierzu gibt es die Library libeatmydata, die für bestimmte Anwendungen die fsync()-Funktionalität deaktiviert. Wie der Name schon andeutet, kann es hierbei zu Datenverlust und irreparabel beschädigten MySQL-Datenbanken kommen, wenn das System crasht, während die Library verwendet wird. Sie sollte daher nur mit Bedacht eingesetzt werden.

Zunächst muss der Sourcecode heruntergeladen und die Library kompiliert werden:

# wget  http://www.flamingspork.com/projects/libeatmydata/libeatmydata-9.tar.bz2
# tar xfj libeatmydata-9.tar.bz2
# cd libeatmydata-9
# make
gcc -shared -Wl,-soname,libeatmydata.so.1  -ldl -o  libeatmydata.so.1.0  eatmydata.c -fPIC
ln -s libeatmydata.so.1.0 libeatmydata.so.1
ln -s libeatmydata.so.1 libeatmydata.so
gcc -o fsynctest fsynctest.c

 

# cp libeatmydata.so* /usr/lib

Um die Library nun nutzen zu können, muss MySQL gestoppt und anschließend mit libeatmydata wieder gestartet werden:

# service mysql stop
# LD_PRELOAD=/usr/lib/libeatmydata.so.1 mysqld &
# disown

Mit Hilfe von pmap kann überprüft werden, ob libeatmydata auch wirklich verwendet wird:

# pmap `pidof mysqld` | grep libeatmydata
00007fa534a2d000      4K r-x--  /usr/lib/libeatmydata.so.1.0
00007fa534a2e000   2044K -----  /usr/lib/libeatmydata.so.1.0
00007fa534c2d000      4K r----  /usr/lib/libeatmydata.so.1.0
00007fa534c2e000      4K rw---  /usr/lib/libeatmydata.so.1.0

Nach dem Import der Daten kann die Library wieder deaktiviert werden, indem MySQL ohne LD_PRELOAD-Umgebungsvariable neugestartet wird:

# mysqladmin shutdown -uroot -p
# service mysql start

Zum Abschluss noch einige Benchmarkergebnisse, die den Effekt von libeatmydata zeigen. Importiert wurden jeweils ein 2GB großer MySQL-Dump mit insgesamt ca. 30 Millionen Datensätzen:

ohne libeatmydata 3 Stunden 12 Minuten
mit libeatmydata knapp über 6 Minuten
share save 171 16 MySQL Testimports beschleunigen