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…

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 )

So traf es mich diese Nacht. Eigentlich wollte ich nur schnell 3 Maschinen mit Virtuozzo updates versehen, denn alleine das rebooten der Maschinen ist schon Horror – mit einer guten Stunde muss man schon rechnen. Doch dann kam alles ganz anders, nach dem reboot sah ich nur ein

Container 1 started: : Container 1 start failed [FAILED]

und das ganze nochmal fuer alle anderen VPSe.
Nach Versuchen, die VPS von Hand zu starten, erntete ich das:

Running vzquota on failed for Container 1 [3]

Also quota von Hand ausfuehren. “vzctl –verbose start 1″ gibt einem hier die entsprechende commandline. Und sieh an, quota meckert ueber ein “busy filesystem” – nur kann das nicht sein, denn ich habe ja gerade frisch gebootet. ->

vzquota : (error) Quota on syscall for id 1: Device or resource busy

Auch ein strace half nicht wirklich weiter.
Minuten des Horrors spaeter kam mir dann die Erleuchtung. Koennte es ein Problem mit den libraries sein? glibc moeglicherweise?
Ein “yum update” brachte mein CentOS wieder auf ne aktuellere glib welches das Problem mit den quotas dann behob. Tolle show, so etwas will man in der Nacht. Programmierer, lasst euch bessere Fehlermeldungen einfallen, bzw besseres errorhandling!!

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

Dieses Phaenomen hab ich nun auf 2 grundverschiedenen Debian Etch Installationen. Einmal nahezu leer und einmal schon mit nen paar Paketen installiert.
Ein Blick in die /tmp/autoinstaller3.log zeigt die komplette APT Fehlermeldung. Beim zweiten Server liegt es lediglich am fehlenden bind9 Paket.
“apt-get install bind9” _vor_ der Plesk Installation behebt also dieses Problem. Kann der Autoinstaller das nicht selbst??

Wie dem auch sei, der zweite Server weigert sich immernoch. Das Log sagt was seltsames:

The following packages have unmet dependencies:
psa: Depends: psa-php4-configurator (>= 1.3.0) but it is not going to be installed or
psa-php5-configurator (>= 1.3.0) but it is not going to be installed
psa-updates: Depends: psa-php4-configurator (>= 1.3.0) but it is not going to be installed or
psa-php5-configurator (>= 1.3.0) but it is not going to be installed

Das heisst also, Plesk Pakete koennen selbst keine Abhaengigkeiten loesen? Tolle Show. Also weiter im Text, ich habe PHP5 auf dem Rechner. Will heissen, ich versuche rauszufinden, welche dependencies das “psa-php5-configurator” Paket hat. Garnicht so einfach, das gibt es naemlich nicht!
“psa-php4-configurator” hingegen will ein paar PHP4 Pakete. Nach einem “apt-get install php4-common php4-domxml php4-gd php4-mysql php4-imap php4-cli php4-curl libapache2-mod-php4” kann der Autoinstaller “psa-php4-configurator” auch installieren.
Die Installation laeuft nun also durch.

Schoen, dass ich nun PHP4 Leichen im System habe fuer ein Pleskmodul, welches vermutlich nichtmal mehr gebraucht wird.
Grosse bitte an SW-Soft: Wenn ihr meine Supportanfrage schon ignoriert, und ich bin nicht der Einzige, dann raeumt wenigstens fuer 8.2.2 die .debs auf… Danke.

UPDATE:
mit folgendem Eintrag in der /etc/apt/sources.list kann man den psa-php5-configurator nachinstalliern:
deb http://autoinstall.plesk.com/debian/PSA8 etch all
dann ein:
apt-get update && apt-get install psa-php5-configurator

Es kommt mir siedent heiss…. Der neue Windows Terminal Server Client fuern Mac “uebersetzt” Apfel C fuer die Gewohnheitstiere zu CTRL C……… 8 Stunden Arbeit fuer die Katz und die Kunden springen im Dreieck. Heissa, letzte Nacht hatte ich 2h Schlaf. Diese Nacht garkeinen. Prima Tag

Achja: Danke Microsoft!

Wie kommt man da drauf? Minutenlanges googlen… Selbst in /usr/share/doc/uw-imapd/README.Debian steht nichts diesbezgl.

Dem ist leider nicht so, also setze ich da mal ausserhalb vom Apachen an. Wie waere es, einfach per cron alle x Minuten durch die Prozessliste zu gehen und zu schauen ob ein userscript laenger als x minuten laeuft? Nichts einfacheres als das. Soviel zur Theorie. Nach so einigem gecode kam ich dann zu diesem ersten script:


#!/bin/bash
# script zum ueberwachen von zu lange laufenden scripten
# killt alle scipte (ausser whitelist) nach $maxruntime minuten
#
hostname=$(hostname)
maxruntime=1
minuserid=10000
if [ "$1" != "" ] ; then debug=1 ; fi

for i in $(find /proc -maxdepth 1 -uid +$minuserid -type d -cmin +$maxruntime)
do
cmdline=$(cat $i/cmdline)
proftptest=$(fgrep proftpd $i/cmdline)
if [ "$proftptest" = "" ] ; then
uid=$(stat -c%U $i)
if [ "$debug" = "1" ] ; then
echo $cmdline von user $uid laeuft laenger als $maxruntime minute"(n)"
else
echo | mutt root -s "$cmdline von user $uid laeuft auf $h
ostname laenger als $maxruntime minute(n)"
fi
else
if [ "$debug" = "1" ] ; then
echo $proftptest laeuft
fi
fi
done


Klar, im ersten Versuch killt es noch nichts, sondern mailt erstmal die Verstoesse. Nach den ersten paar Minuten im cron fiel mir allerdings auf, dass viele Kunden cgi upload scripte haben und dergleichen. Hier muss ich also die “whitelist” noch ein wenig aufbohren, nach einem proftpd alleine zu checken reicht wohl nicht
Das endgueltige script werde ich wohl im Downloadbereich posten.

nein… das kann nicht sein… wir haben jetzt alle Passwörter Geändert… haben uns mit unserer Sicherheits-Abteilung Einen 2.ten Cleanen FTP-Upload PC gerichtet… um solche Dinge nicht nochmal zu erleben. Bitte schauen Sie sich das an.!!!

schoene “Sicherheits-Abteilung”

Ich koennte heulen… Nun gibt es schon so schoene Sachen wie CSS und ich denk mir, Browserunterschiede sollten kein Problem mehr sein. Also setz ich mich ran und fummle an nem bisserl schoenerem startx Theme rum. Soweit, so gut.

Nach Stunden rumfummeln steht das Theme in Firefox und ich schaue es mir (wieder!) in Safari an – und werde herb ueberrascht. Er scheint keine Aenderungen angenommen zu haben, auch nach dem X-ten shift-reload nicht. Nach dem XX-ten shift-reload sehe ich hin und wieder einige Aenderungen, dann wieder nicht. Was zur Hoelle ist hier los? Warum hat der Safari solche Probleme, wenn sich mal ein stylesheet aendert? Erst nach einem kompletten Neustart frisst er die Aenderungen.

Bei sowas bin ich dann wieder froh, dass es nur ein Hobby ist und mir keine Kunde im Nacken sitzt, der mir Haarklein vorschreibt, wie es auszusehen hat

Wie auch immer, die neuen Themes sind nun scharf. Sowohl meine Gallery als auch die Hauptseite (nach startx) sehen nun gleich aus.

Die Themes basieren auf das WordPress Revolution Theme und dessen port zu Coppermine von chylly.de. Ich habe allerdings bei Beiden den viewport etwas breiter gemacht und z.B. die sidebar gefixt. Warum beide relative Positionen fuer die sidebar nehmen bei einem sonst statischen Layout ist mir allerdings schleierhaft.

PS: IE7 ist nen Arschloch und kann mich mal.

15 min spaeter bekam ich eine Beschwerdemail.

Es wird von wiederholten Ausfaellen gesprochen. Ausserdem von den obligatorischen Anwaelten die den Verdienstausfall einklagen sollen. Ein Blick auf die Webseite des Kunden laesst mich fragen aufkommen… In der Simpsons Internet Folge gabs Counter, die rueckwaerts zaehlten – Hier wohl auch

Ok, dann frag ich mal die Statistik, was sie ueber den Server zu berichten hat.

uh, kein Ausfall in den letzten 7 Tagen. Nichtmal einen im Monat Maerz. Not Bad… einer unser besseren Server
Und nein, Nagios laeuft nicht im selben RZ!

Wieviel Langeweile muss man also haben, um SO schnell zu reagieren?
Das war natuerlich nicht die einzige Mail dieser Art… Eventuell stumpfe ich ueber Ostern ab

Es stellt sich natuerlich schnell heraus, dass der Server als solches einwandfrei tut – nur hat er kein Netz. Das ist natuerlich schlecht fuer so einen Server

Nur… warum ist das Netz weg? Vom (virtuellen) Server zur HW Node gehts prima. Ein traceroute von Aussen macht schnell klar, es geht bis zum Switch des Datacenters und nicht weiter. Nach 3 Telefonaten und Ansagen wie “Nein, hier ist alles in Ordnung”, versuchte ich die IP-Adresse mal auf einem anderen Server. Gleiches Ergebniss. Mitlerweile sind fast 2 unschoene Stunden vergangen. Ich fuhr den Server nun zum x-ten mal wieder hoch, da fiel mir ein, dass ich die IP ja noch auf dem Test-Server aktiv habe. Aber was passiert? Der Datacenter Switch entscheidet sich, die IP auf meinem Test-Server zu blocken und gibt damit die IP fuer den eigentlichen Server wieder frei.

Tolle Show. Hab ich mich nicht mit Ansagen wie “Nein, hier ist alles in Ordnung” abwimmeln lassen? Naja egal, erstmal Feierabend machen.

Zuhause angekommen stelle ich mit Schrecken fest, dass nun ist die naechste IP-Adresse weg. Langsam schon etwas angenervt, merke ich, dass das Datacenter Gateway auf der IP “sitzt” und sie fuer sich beansprucht. Diesen Fehler hatte ich, gerade bei der Adresse schon mehrmals. Mail an den Support mit der Bitte doch einfach mal die IP wieder freizuschalten. Warten… und noch mehr warten… Nix passiert. 2 stunden spaeter noch ne mail… nix. Ich raste langsam aus und schreibe eine etwas kritischere Mail. Ne Stunde spaeter bekomme ich Antwort auf die erste Mail, mit einem Inhalt, der mich von den Socken haut. Nach sage und schreibe 6 (!) Stunden bekomme ich lapidar gesagt, man sehe die IP-Adresse xx auf MAC Adresse yy – Sorry Jungs, aber DAS weiss ich selbst. Die IP ist natuerlich immernoch geblockt. Da ich jetzt auf 180 war und es ausserdem spaet in der Nacht schrieb ich meinem Kompagnon eine kurze Schilderung der Sache mit dem Hinweis, wenn ich jetzt noch einmal dahin mailen muss, werde ich Ausfaellig.

Morgens um 8 rief er an und fragte laessig, ob ich denn schon meinen Trick mit dem doppelt belegen der IP probiert hatte.
Fluchtend wuchtete ich mich zum Rechner und 5 min spaeter war der Server wieder zu erreichen.

Aber nun mal unter uns… warum “denkt” dieser verdammte Switch dauernd, IP Adressen belegen zu muessen und vorallem, warum schnallt das Datacenter das nicht? Ich freu mich schon auf den netten Anruf am Montag.

Ich denke, der Mechanismus, der hier am Rad dreht ist eine Eigenschutz Funktion des RZ. Irgendwie muss natuerlich gewaehrleistet werden, dass Kunde A nicht sich einfach so eine IP von Kunde B schnappen kann. Tut er das, wird er automatisch geblockt. Sinnvoll. Allerdings sollte der Switch bitte nicht zum selbstlaeufer werden und wild rumsperren OHNE dass sich irgendwas an der Netzstruktur aendert.

Interessant ist auch, warum ich diese Sperrung wieder umgehen kann, wenn ich einfach die IP-Adresse absichtlich doppelt vergebe….

Nein, mal im Ernst. Frueher hatte man ein Raid, selten groesser als ein DLT, ok, compression mit eingerechnet. Womit darf man sich heute rumschlagen? Tja… der totale Overkill.

Folgende Aufgabenstellung:

• 40 Server, á ca. 50Gb
• 3 Backupmaschinen, á ca. 1,4tb Platten.
• 1x pro Woche Fullbackup
• Taeglich incrementelles Backup.
• 2 Saetze vorhalten.

Und nun das grosse Manko – Die Backupmaschinen haben kein Gigabit Interface Grob gerechnet geben alle Server schonmal ein Vollbackup Aufkommen von 2tb. Damit ist die haelfte meiner totalen Kapazitaet schon aufgebraucht. Allerdings durfte ich in diversen Tests feststellen, dass gzip hier noch einiges bringt.

Naechstes Problem – Die reine Datentransferzeit von der HardwareNode zum Backupserver ist immens… Eine der groessten Maschinen, ca. 60gb, benoetigt fuer einen Durchlauf in etwa 4-5 Stunden! Und das Nachts…

Ich habe mich entschlossen, pro Nacht im Schnitt 2 Rechner pro Backupserver voll zu sichern. d.h. 300 gb pro Nacht. Herrlich… Hinzu kommen noch, nach den Vollbackups, 34 incrementelle Backups, im Schnitt also 11 Server pro Backupserver , á ca. 500mb incrementelle Daten. Also alles in allem nochmal 150gb. Will heissen, ich schiebe 450gb daten pro Nacht 7 Tage die Woche durch Rechenzentrum…

Und zu allem Ueberfluss wird mein Backupspeicherplatz sehr sehr knapp… Aber ich hoffe ja noch auf den Compressionfaktor.

Alles in Allem ist das schon eine ganz schoen kranke scheisse… und warum das alles? Weil nen RZ es nicht schafft die richtige, kaputte Platte im Raid auszuwechseln und den resync trotz wohl mehrmaliger Warnungen trotzdem forced? Nein, Backup muss ja sein… aber das hier ist echter Overkill…