trafficsau.de

Nachdem ich heute ne Weile darueber gegruebelt habe, wie ich unter Debian Lenny und suphp sowohl meine vhosts unter /var/www zum laufen bekomme, als auch das phpmyadmin, welches apt nach /usr/share installiert wurde zum laufen zu bekommen kam ich auf folgende Konfigurationsanpassung.
Diese ist noetig, da suPHP aus Sicherheitsgruenden die Ausfuehrung von php Dateien die z.B. root gehoeren und/oder ausserhalb /var/www liegen, Verweigert.

Debian bereitet die /etc/apache2/mods-available/suphp.conf schon richtig vor, im Verzeichniss /usr/share ist suphp also abgeschaltet. Nun hilft es leider nicht, einfach mod_php hinzu zuladen.
Vorher muss man die config des su_php leicht umschreiben nach folgendem Muster:

in der Datei /etc/suphp/suphp.conf die Zeile:

application/x-httpd-php=php:/usr/bin/php-cgi

in:

application/x-httpd-suphp=php:/usr/bin/php-cgi

aendern. Also ein “su” in den apptype hinzufuegen.
Ebenso in der Datei /etc/apache2/mods-available/suphp.conf:

AddType application/x-httpd-php .php .php3 .php4 .php5 .phtml
suPHP_AddHandler application/x-httpd-php

in:

AddType application/x-httpd-suphp .php .php3 .php4 .php5 .phtml
suPHP_AddHandler application/x-httpd-suphp

aendern. Hier also 2 Zeilen zu aendern.

Nun kommen sich die beiden php Arten nicht mehr in die Quere und man kann mit a2enmod php5 modphp wieder zuschalten, sofern man dies noch nicht getan hat.

Mit dieser Aenderung sollte jedes Zentral per apt installiertes script funktionieren, solange nicht vergessen wird, fuer den vhost oder alias die suphp engine abzuschalten, solange es sich nicht in /usr/share befindet.
Warum Debian dies nicht gleich so macht, ist mir allerdings ein Raetsel.

Uebrigens: ich hatte waehrend meiner Tests nen wunderbaren Bug im Firefox gefunden. Bot dieser einmal bei einem alias wie /phpmyadmin/ die index.php zum download an, weil noch kein handler installiert war, cached diese diese Information. Man kann am Server nun konfigurieren was man will…

Schoen, dass Murphy doch so zuverlaessig ist.
Die Tage spielte ich ein wenig mit PXE Boot rum. Ich dachte mir, so ein notboot linux kann nicht schaden, zudem ich zunehmend Rechner ohne CDROM bekomme…

Doku findet sich wie Sand am Meer. Zum testen entschied ich mich der Einfachheit halber fuer dnsmasq und einen TFTP Server fuer OSX. Ersteres sollte mein Fallstrick werden.
Die dnsmasq.conf benoetigt nur ein paar Zeilen:

dhcp-range=192.168.42.200,192.168.42.220,12h
dhcp-host=XX:XX:XX:XX:XX:XX,eeebox,192.168.42.219,infinite
dhcp-option=3,192.168.42.1

Hier fehlt eigentlich nur noch die boot-file anweisung fuers PXE. In einer Doku stand folgendes Beispiel:

dhcp-boot=/pxelinux.0,pos,192.168.1.11

Beim Bootversuch warf meine eee Box allerdings folgenden fehler:

PXE-T02 access violation
PXE-E3c tftp error access violation.

Es brachte mich zur Weisglut, denn die Fehlermeldung ist total Missfuehrend. Ich suchte am TFTPServer und fand nichts, wenn ich tftpget verwendete, bekam ich das bootfile. Nach vielen Versuchen und Vergleichen mit anderen Anleitungen fiel mir dann der / vor dem filename auf…
Eine fuer meine beduerfnisse richtige Version waere dann:

dhcp-boot=pxelinux.0,hermes,192.168.42.42


Nun klappts auch mit dem PXE-Boot via dnsmasq. Weiterfuehrende Doku:

Syslinux (fuers pxelinux.0)
Erklaerung der PXE config files und Demos
GRML ueber PXE booten ohne NFS (sehr elegant, wie ich finde)
Die Debian PXE Doku (und hier ist sogar der Eintrag fuers dnsmasq richtig )

Heutzutage denkt man ja, es gaebe keine erreichbaren Grenzen mehr in Sachen Filesystem u.ae. Tja, ich wurde die Tage wieder auf den Boden der Tatsachen zurueckgeholt. Es fing damit an, dass unsere neuen Server endlich kamen. Aus 6 500Gb Platten sollte ein Array gebaut werden. Soweit, so gut. Beim einrichten fragte mich der Raidcontroller hin und wieder nach 2TB Support aber ich ging beim ersten Versuch doch recht schmerzlos ran und machte ein 2.5TB grosses Raid5.
Die CentOS4.5 Installation lief ohne groessere Probleme durch, nachdem ich das Konzept mit den Driverdisks (im grub mit “linux text dd” booten) verstanden habe und einfach das dd.iso von einem USB Stick laden konnte. Auch partitionieren klappte bestens mit dem Diskwizard. Doch dann kam der erste Bootvorgang. Schwarzes Bild, blinkender Cursor. Thats it.
Nach rumfragen und surfen stellte ich dann fest, dass Grub noch keine 2TB grossen Platten(!), also nicht Partionen, unterstuetzt.
Ok, also zweiter Versuch. Ich legte diesmal 2 RaidVolumes an. eine 50Gb fuers System und den Rest, also 2450Gb fuer Virtuzzo. Auch diesmal klappte die Installation erstmal bestens, der Diskwizard liess mich die Partitionen einrichten und formatieren. Auch das booten klappte jetzt.
Doch dann eine Meldung, dass System /vz, die grosse Partition bzw auf der fuers System zweiten Platte waer kaputt. Ich habe das mal uebergangen und /vz aus der fstab genommen, damit ich endlich mal sehen kann, ob der Rechner sauber laeuft.
Spaeter hab ich dann einfach /vz neu formatiert und mit Speedtests angefangen. Hier war ich doch ueberrascht, was moderne Rechner so hinbekommen. Was mit allerdings nicht direkt auffiel war, dass /vz nur 250Gb gross war… Und hier fing der Spass an. Nach etwas Recherche war schnell klar: Linux Kernel ab 2.6 haben die 2Tb begrenzung nicht. Dafuer aber viele der alten Tools drumrum, wie z.B. Grub oder fdisk. Zu allem ueberfluss koennen die derzeitigen Bootloader nur von einem “msdos disk label” booten. Dieses kann aber auch nur max. 2Tb grosse Platten. Schoene Scheisse.
Doch es gibt natuerlich eine Loesung.
Zunaechst muss man sich von fdisk verabschieden, da dieser nur msdos disk labels bzw partition tables kann.
Parted ist hier gefragt. Doch eine Warnung beim rumexperimentieren: Parted schreibt direkt auf Platte, also nicht erst nach dem bei fdisk bekanntem “w”!!
Der obige Schritt 2 RaidVolumes anzulegen war schonmal notwendig, da wie schon bemerkt, Grub nur von msdos labels booten kann, nicht von GPT (GUID Partition Table, nutzt z.b. auch Apple bei IntelMacs)
Also muessen wir nun die zweite RaidVolume zu GPT umbauen, bei mir ist das /dev/sdb. Unmounten nicht vergessen!

Mit
parted /dev/sdb print
bekommen wir raus, wie es um die disk geometry bestellt ist:

Disk geometry for /dev/sdb: 0.000-2336501.250 megabytes
Disk label type: msdos
Minor Start End Type Filesystem Flags
1 0.031 239348.502 primary ext3 boot
Information: Don't forget to update /etc/fstab, if necessary.

Wie hier zu sehen, Disk label type ist noch msdos. Wir merken uns aber schonmal start und endgroesse der “Platte”.
Nun muessen wir (Achtung, Datenverlust ab hier) mit

parted /dev/sdb mklabel gpt

den label type umstellen und mit

parted /dev/sdb mkpart primary 0 2336501

die Partition wieder anlegen. Die Start und Endwerte uebernehmen wir aus der parted /dev/sdb print Ausgabe. Mit selbigem Befehl kann man auch ueberpruefen, ob alles korrekt gelaufen ist. Ab hier kann man wieder wie gewoehnlich ein filesystem anlegen, in meinem Fall mit mkfs.ext3 -m0 /dev/sdb1 -L/vz

Das -m0 verhindert die gewoehnliche 5% root Reservierung, die hier Platzverschwendung waere. Mit -L schreibe ich ein filesystemlabel mit, welches die z.B. CentOS fstab so moechte. Noch eine Warnung: aeltere fdisks luegen auch jetzte noch mit der disk geometry, neuere verweisen sinnvollerweise direkt auf parted. Also auf keinen Fall mehr benutzen.

Viel Spass mit dem >2TB Volume