AuthName private
AuthType Basic
AuthUserFile /etc/apache/htpasswd.users
require valid-user

Das an sich ist bisher noch nichts ungewöhliches.

Aber jetzt möchtest du eine einzelne Datei von der Benutzerauthentifizierung ausschließen, weil diese für Jedermann erreichbar sein soll? Um das zu erreichen, muss lediglich folgendes noch in der .htaccess ergänzt werden:

<Files notify.php>
order allow,deny
allow from all
satisfy any
</Files>

Der wichtige Teil hierbei ist allerdings nicht das “allow from all”, sondern das “satisfy any”. Der Standartwert ist “satisfy all”, was bedeutet, dass sowohl die “allow/deny”-Direktiven für die Host basierte authentifizierung als auch die “require”-Direktiven für die Benutzerauthentifitzierung passen müssen. Mit “satisfy any” reicht es, wenn eine der beiden Direktiven erfüllt wird, um Zugriff zu bekommen. Und die Kombination aus “allow from all” und “satisfy any” gibt dann immer Zugriff, da “allow from all” alleine immer Zugriff gewährt.

Mehr über die satisfy-Direktive kann man in der aktuellen Apache Dokumentation unter http://httpd.apache.org/docs/current/mod/core.html#satisfy erfahren

As a first step, i regularly installed Ubuntu on the System. When doing the installation, you will notice that the partition editor shows two hard disks, but one cannot be accessed. This is normal, as those two hard disks are actually identical – they just can be reached over the two different paths and the Kernel just detects them as those two separate disks. But one path is the backup path and cannot be used. After the installation has finished, just reboot into the new system. If booting does not work, check the BIOS setting if booting from the first and from the second hard disk is enabled. Otherwise the system won’t boot if the path over the 2nd controller is the active one.

After logging into your new system, install the multipath tools:

# apt-get install multipath-tools multipath-tools-boot

That was the easy part – now to the configuration.

Next, you need to get the vendor and product strings aswell as the WWN of the volume for configuring multipathd later on. Those can be obtained using the scsi_id program from udev, which is found in /lib/udev.

# /lib/udev/scsi_id --page=0x80 --whitelisted --export --device=/dev/sda
ID_SCSI=1
ID_VENDOR=IBM
ID_VENDOR_ENC=IBM\x20\x20\x20\x20\x20
ID_MODEL=1726-2xx_FAStT
ID_MODEL_ENC=1726-2xx\x20\x20FAStT\x20
ID_REVISION=0617
ID_TYPE=disk
ID_SERIAL=SIBM_1726-2xx_FAStTSX82722212
ID_SERIAL_SHORT=SX82722212

The Output of those “page 0×80″-Identifiers show everything we need for configuring the Controller settings later on. Especially the Values in the Fields ID_VENDOR_ENC and ID_MODEL_ENC are of interest to us. Note that spaces are encoded as \x20, but you can actually shorten the values – multipathd will cope with it. So the Vendor is then “IBM” and the Model “1726-2xx”. For configuring the drives, we need to know the WWN of the Volume. This can be found out using scsi_id again – it is stored in another page:

# /lib/udev/scsi_id --page=0x83 --whitelisted --device=/dev/sda
3600a0b80005a136a0000012e4a91f17b
# /lib/udev/scsi_id --page=0x83 --whitelisted --device=/dev/sdb
3600a0b80005a136a0000012e4a91f17b

As you can see, the WWN of both devices is the same – they are the same volumes on the storage, the only difference is that they are on different paths.

Next, we can finally start writing the config for our multipathing. The daemon already comes with a set of default values which were fine for me needs, so I just configured the device and the multipath. I’ll display my configuration first and explain the settings below.

devices {
    device {
        vendor                  IBM
        product                 "1726-2xx"
        path_checker            rdac
        path_grouping_policy    group_by_prio
        prio_callout            "/sbin/mpath_prio_rdac /dev/%n"
    }
}
multipaths {
    multipath {
        wwid    3600a0b80005a136a0000012e4a91f17b
        alias   system
    }
}

In the devices section there is exactly one device configured – which is our Controller which is reachable over the two different SAS paths. The vendor and product are the values we found out earlier. Finding the right values for the other parameters was just a matter of digging through some manuals (multipath.conf(5) had everything needed). As the DS3200 has an LSI controller, the rdac path_checker and mpath_prio_rdac prio_callout where the right values here.

The next section defines the multipath device itself. the wwid is the identifier we got by quering the devices for their page 0×83 and the alias is a name that the multipath-enabled device nodes will have later.

This is everything needed to configure multipathd. Everything that’s left is to modify the fstab to point to the multipath device nodes and create a new initrd.

Inside /etc/fstab, just replace your old disk entry like /dev/sda1 with the new device node. /dev/sda1 becomes /dev/mapper/system-part1, /dev/sda2 becomes /dev/mapper/system-part2 and so on. If you need to reference the whole drive (e.g. when using fdisk) you specify /dev/mapper/system instead of /dev/sda.

Last thing left is to create a new initrd. Just delete the old one in /boot first and then create a new one for your system:

# cd /boot
# ls initrd.img-2.6.32*
initrd.img-2.6.32-21-server  initrd.img-2.6.32-21-server.old  initrd.img-2.6.32-24-server
# rm initrd.img-2.6.32-24-server
# mkinitramfs -o initrd.img-2.6.32-24-server 2.6.32-24-server

Now the only thing that is left is to reboot your system. Hopefully it will come up with your brand new multipathed configuration

When it does, check if the multipath is working as expected:

# multipath -ll
system (3600a0b80005a136a0000012e4a91f17b) dm-0 IBM     ,1726-2xx  FASt
[size=80G][features=0][hwhandler=0]
\_ round-robin 0 [prio=3][active]
\_ 2:0:1:0 sdb 8:16  [active][ready]
\_ round-robin 0 [prio=0][enabled]
\_ 2:0:0:0 sda 8:0   [active][ghost]

This is what it should look like. The system-Volume is up and running over the path offered via the device “sdb”. If you “pull the plug” or just set the controller to prefer the other Path, the output of “multipath -ll” will reflect this and will show the other path via “sda” as active. I/O Operations might stall for a couple of seconds, but that is way better than a complete system crash and will mostly go unnoted by users anyway.

Still, there are two major problems left:

1. update-grub is not working anymore
2. Your system might show a lot of I/O errors on the console

I sadly have no solution for the first problem. grub-probe just can’t handle the multipath device nodes for now, so after an Kernelupdate, you have to modify the grub.cfg manually. You should edit /usr/sbin/update-grub aswell and just place an “exit 0″ in the 2nd line so the package manager thinks that the command was executed without errors (otherwise the installation of new Kernels will fail).

The second problem is because of udev trying to probe the inactive path for its metadata using blkid. But as that path is offline, it cannot get it and just tries again idefinitely. One way to skip this is to edit the file /lib/udev/rules.d/60-persistent-storage.rules. Around line 68, just replace

KERNEL!="sr*", IMPORT{program}="/sbin/blkid -o udev -p $tempnode"

… with …

KERNEL=="sda*", GOTO="no_run_blkid"
KERNEL=="sdb*", GOTO="no_run_blkid"
KERNEL!="sr*", IMPORT{program}="/sbin/blkid -o udev -p $tempnode"
LABEL="no_run_blkid"

This will skip running blkid on the devices sda and sdb. After editing the file and rebooting, there should be no more I/O-Errors.

If you have any questions or suggestions, don’t hasitate to leave me a comment or write me an E-Mail. Have fun with your multipath configuration!

htop ist ein ncurses-basiertes Terminalprogramm, dass genau wie top laufende Programme anzeigt. Aber wo top aufhöhrt geht htop noch viel weiter:

• killen, renicen von mehreren Prozessen per Tastendruck ohne auch nur an PIDs denken zu müssen
• horizontales und vertikales scrollen
• Maussupport
• anzeige der Prozesse als Baum (finde ich persönlich sehr nützlich)
• verstecken von Kernelprozessen
• und ausserdem ist es noch schön bunt

Links gibt es natürlich den obligatorischen Screenshot. Alles in allem ist htop wohl eine echte alternative zu dem guten alten top und definitiv einen Blick wert, zumal die installation einfach nur ein “sudo apt-get install htop” ist.

Abhilfe schafft tcpdump selbst – es kann die Datei selbständig rotieren, so dass die Dateigröße klein gehalten werden kann. Hier ein Beispiel, um ein Log jede Stunde rotieren zu lassen

tcpdump -pni eth0 -s65535 -G 3600 -w 'trace_%Y-%m-%d_%H:%M:%S.pcap'

-G ist dabei die Zeit in sekunden zwischen den rotationen. -w akzeptiert dann strftime-Platzhalter – bei dem Beispiel würde die Datei z.B. trace_2010-08-30_13:04:55.pcap heißen können. Alle Platzhalter sind in strftime(3) dokumentiert.

Als alternative zum rotieren “nach x Sekunden”, bietet tcpdump mit der Option -C auch die Möglichkeit das Capturefile zu rotieren, wenn eine gewisse Dateigröße erreicht wurde. Um die Dateigröße auf 100MB zu beschränken, kann man folgenden Befehl verwenden

tcpdump -pni eth0 -s65535 -C 100 -w capture

Zusammen mit -C werden bei -w allerdings keine strftime-Platzhalter mehr ausgewertet. Die Dateinamen sind einfach der Reihenfolge nach capture, capture1, capture2, …, capture<n>.

Ein Experiment zeigt, was mit Google passiert, wenn die Gravitation wirk: Google Gravity.

Interressant ist, dass alle Elemente auf der Webseite weiterhin bedienbar sind – versucht einfach etwas zu suchen

Update: funktioniert nicht vernünftig mit Firefox und mit IE gar nicht – ist halt ein Chrome-Experiment.

Jul 11 16:24:56 www1 snmpd[2120]: Connection from UDP: [10.50.0.1]:56686->[10.50.0.11]
Jul 11 16:25:27 www1 snmpd[2120]: last message repeated 965 times

Abhilfe gibt es in der Form, das man dem snmpd sagt, dass er erst ab einem bestimmten Level loggen soll. Bei Debian/Ubuntu findet man die Einstellungen in der Datei /etc/default/snmpd. Die Standarteinstellung für die Optionen für den snmpd sehen dabei momentan so aus:

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1'

Für uns interessant ist im Grunde nur der Parameter “-Lsd”. Dieser besagt, das alles Logging (L) über Syslog (s) Laufen soll, und zwar in die Daemon (d) Facility. “-Lf /dev/null” deaktiviert dazu noch das logging direkt in eine Datei. Um das Logging jetzt auf bestimmte Prioritäten zu beschränken, ändert man das “-Ls” in “-LS”. Der Parameter erwartet vor der Facility jetzt noch eine Priorität, entweder ab welchem Level geloggt werden soll, oder eine von-bis Angabe. Um alles ab Warnungen zu loggen, ändert man den Paramter auf -LS4d. Die komplette Zeile könnte nun so aussehen:

SNMPDOPTS='-LS4d -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid'

Nach einem neustarten des snmpd werden nun die Verbindungen nicht mehr geloggt. Ich merke dabei zur Sicherheit nochmal an, dass ein snmpd niemals “einfach so” übers Internet erreichbar sein sollte, da bis snmp v2 alles einfach nur Klar-Text ist.

Die komplette Dokumentation findet man unter Ubuntu in der manpage snmpcmd(1) unter “LOGGING OPTIONS”.

Das bedeutet, dass VirtualBox einem Gast bis zu 8 virtuelle Bildschirme zur Verfügung stellen kann. Diese werden dann als separate Fenster in dem Host angzeigt. Praktisch ist das vor allem in den Fullscreen und Seamless Modi. Hier “mappt” VirtualBox einen virtellen Monitor auf einen physikalischen. Dadurch hat man dann zum Beispiel einen virtuellen Windows Desktop auch auf beiden Bildschirmen des Linux Hosts.

Die Konfiguration davon ist VirtualBox-typisch gehalten: Bei den Settings einer VM gibt es in der Kategorie “Display” einen neuen Slider “Monitor Count”. Hier einfach die gewünschte Anzahl der virtuellen Bildschirme setzen – idealerweise die Anzahl der Monitore, die man auch angeschlossen hat.

Das Mapping der virtuellen an die physikalischen Monitore kann man an der VM direkt im laufenden Betrieb vornehmen. Entweder über das Menü, oder über die Host-Taste (standartmäßig: rechte STRG) + Pos 1. Dort über das “View”-Menü kann man dann die Mappings an die eigenen Vorstellungen anpassen.

Memcached hat sich auf der anderen Seite hat sich zum cachen von Daten schon mehrfach beweisen und es bietet sich für das Speichern von Sessions direkt an – und das beste ist, dass es dafür schon direkt einen Session-Handler in der PHP-Extension memcached gibt und die Installation davon bei Debian/Ubuntu schon fast trivial ist.

Einen Nachteil hat das ganze allerdings: Man sollte den memcached-Server nicht “mal eben” neu starten, weil dann alle darin gespeicherten Sessions verloren gehen. Um das zu verhindern, muss man allerdings eine Lösung einsetzten die einen persistenten Speicher verwenden, wie z.B. memcachedb oder membase.

Auf dem Server, der die Sessions mittels memcached speichern soll, muss erstmal memcached installiert werden

apt-get install memcached

Auf dem Client (auf dem die PHP-Scripte liegen) jetzt noch die memcached-extension für php installieren

apt-get install php5-memcached

Jetzt muss in der php.ini nur noch eingestellt werden, dass der “memcached”-Handler für php-Sessions verwendet werden soll und welche Adresse der memcached Server hat. Dazu einfach die /etc/php/apache2/php.ini bearbeiten.

[Session]
session.save_handler = memcached
session.save_path = "10.50.0.2:11211"

Sessions werden jetzt unter der IP-Adresse gespeichert, die bei session.save_path angegeben ist. Anstatt einer einzelen IP kann man auch eine Komma-separierte Liste mit IPs angeben, die als Pool verwendet werden, z.B. “10.50.0.2:11211,10.50.0.3:11211″. Die beiden memcached-Server können auch auf der gleichen IP auf unterschiedlichen Ports liegen, allerdings verliert man dadurch den Vorteil, dass einer der Server wegbrechen kann.

Jetzt nur noch den apache neu laden, dass die Einstellungen auch angewendet werden.

apache2ctl graceful

Fertig – ab jetzt werden die Sessions direkt in memcached gespeichert.

Die Gehäuse bekommt man im Shop von Netgate.

Zusätzlich hat er auch noch ein CentOS-Image für ALIX-Boards erstellt, welches passend ist, wenn man mehr machen möchte als nur das Vyatta-übliche Routing und Firewall. Für eine Anleitung und den Download-Link, besucht einfach sein blog (englisch).

Das LTS-Release bietet, im Gegensatz zu den normalen releases, 5 Jahre Updates an. Das ist gerade bei Servern interessant,  bei denen weniger release-updates weniger Kopfschmerzen und weniger Arbeit für den Admin bedeuten. Normalerweise werden solche langen Supportperioden nur bei kostenpflichtigen “Enterprise”-Versionen angeboten, aber bei Ubuntu bekommt man die kostenlos.

Mein System hier werde ich die nächsten Tage dann wohl auch updaten