Ein Aufruf über telnet der entsprechenden Website lieferte mir immer das richtige Ergebnis, aber weder ein Firefox noch ein IE oder Opera konnten mir die Website anzeigen.

Verschiedene Einstellungen zur Contentauslieferung brachten leider keine Hilfe.

Ein Workaround ist nun, einfach alle Files durch den PHP Prozessor laufen zu lassen:

AddType application/x-httpd-php .php .phtml .php3 .html .htm

Dies ist zwar nicht unbedingt die Ressourcen schonend, allerdings funktioniert Mod Layout anschließend.

Die Logfiles die pipelog.pl anspricht werden aber leider auch nicht vom updateskript nachträglich generiert, also musste Hand angelegt werden:

for i in `ls /etc/apache2/confixx_vhosts`
do
  domains=`grep ServerName /etc/apache2/confixx_vhosts/$i | awk '{print $2}'`
  for j in $domains
  do
    ln -s /var/www/`basename $i .conf`/log/access_log /var/log/apache2/confixx/domains/access/$
  done
done

Ist es nicht schön eine bash zu haben? Nach der Generierung der Links liefen auch die awstats Updates wieder:

for i in `ls /var/www/`
do
  /usr/lib/cgi-bin/awstats.pl -config=$i -update
done

Das Bild im VServer

       ?  ? ?---------  ? ?        ?        ?            ? /var/mail/root

Das Bild außerhalb des VServers:

83363649 437981200 ?r-s--S-wt 8224 7217184 6627360 538976288 Jan 30  1987 root

Das ganze klingt ja schon spannend, allerdings lassen sich diese Dateien anschließend auch nicht mehr löschen, geschweige denn lesen:

~# chmod 600 /var/mail/root
chmod: changing permissions of `/var/mail/root': Operation not permitted
~# rm /var/mail/root
rm: remove write-protected weird file `/var/mail/root'? y
rm: cannot remove `/var/mail/root': Operation not permitted

Da allerdings über dmesg keinerlei Einträge auf einen Fehler im Dateisystem hingedeutet haben, war der einzigste Weg die Dateien zu löschen debugfs zu verwenden:

~# debufs
debugfs:  open -w /dev/sda3
debugfs:  cd /var/mail
debugfs:  rm root
debugfs:  close

Wichtig dabei ist das abschließende close, da ansonsten die Änderungen nicht auf das Dateisystem geschrieben werden.

Nun habe ich dank Matty (http://prefetch.net/blog/) einen entscheidenden Tipp bekommen: http://prefetch.net/blog/index.php/2008/07/09/bashs-built-in-commands/

Ich bin davor noch nicht auf die Idee gekommen mit den Keybindings direkt in der Bash herumzuspielen. Dank ihm konnte ich nun so endlich die “entf” Taste in Solaris verwenden:

bind '"\e[3~"':delete-char

Ab in die .bashrc :)

Vielen Dank matty! Du hast mir das Leben erleichtert.

Jedoch gibt es da auch andere Möglichkeiten, als direkt die Files richtig zu speichern, man mache dies mal einem Kunden klar.

Ich bin letztens über eine Seite gestolpert die nicht nur die Standardvariante mit dos2unix behandelt, sonder auch andere Wege vorschlägt: http://kb.iu.edu/data/acux.html

Mein absoluter Favorit ist hierbei die Perl variante:

perl -p -e 's/\r$//' < winfile.txt > unixfile.txt

Denke das dürfte auch dem einen oder anderen in einer misslichen Lage helfen, denn dos2unix und unix2dos ist nicht auf allen Kisten vorhanden…

http://www.openvcp.org/timeline

OpenVCP setzen auch wir ein um unsere VServer zu steuern.

Es sind in den letzen paar Tagen ein paar nette neue Features dazugekommen, wie zum Beispiel für alle Benutzer ein Rettungssystem für den VServer. Dieser kann nun seinen VServer direkt in ein Rettungssystem booten um eventuelle Fehler am SSH Daemon zu beheben, sodass beim normalen Boot der Login wieder funktioniert.

Ein weiteres Feature ist die Deaktivierung von VServern, so muss nun nicht mehr der einzelne Benutzer gesperrt werden, sondern es ist nun direkt möglich, einen einzelnen VServer zu deaktivieren. Eine durchaus nette Funktion wenn es darum geht Schuldnern den VServer zu sperren.

Nach einer kleinen Betaphase hoffen wir dieses Feature sehr bald all unseren Kunden zur Verfügung zu stellen.

Es zeigte sich nach einem ls auf dessen Homeverzeichniss, dass das Verzeichnis /etc fehle. Da der Kunde mich um eine kurze Fehleranalyse bat, damit sein VServer schnell wieder online kommt.

In /var/log/auth.log zeigte sich zuerst, dass sich root per SSH erfolgreich authentifiziert hatte. Jedoch meinte der Kunde er sei zu dieser Zeit 100% nicht am Rechner gewesen.

Der clou kam dann bei cat /root/.bash_history:

cd ..
ls
cd var
ls
cd kunden/
ls
cd webs/
ls
cd xyz/
ls
wget -r http://www.xyz.de/gallery/
ls
cd www.xyz.de/
ls
rm -all
rm --help
rm -r
rm / -r
ls
ls
cd ..
ls

Tja dies war wohl nicht beabsichtigt. Glücklicherweise hat der Übeltäter seinen Befehl doch sehr schnell abgebrochen, denn die anderen Verzeichnisse gab es noch.

Kurzes Backup der Webpräsenzen und der Kunde durfte seinen VServer neu aufsetzen.

Für mich war die Arbeit somit schnell erledigt, allerdings hat der Kunde nun seine Lektion gelernt wann und wem er anderen Rootrechte gibt.

Klar durch ein einfaches löschen der Datei /etc/apache2/charset ist das Problem immer behoben, denn alle besseren Webapplikationen haben ja im Header den Charset stehen… wieso kann das nur wieder Debian mit Ihren Packages nicht gleich auslassen, damit es immer selbstständig vergeben wird?

Wir armen sysadmins müssen die Schlamperei dann wieder ausbaden…

Aber auch dies wurde geschafft und die Arbeit kann nun weitergehen.

Als erstes muss man sich die Postfix sources besorgen:

cd /root

mkdir postfix

apt-get source postfix

und dann ein kleines Skript bauen:

/root/mailmonitoring.sh

#!/bin/sh
defmail=`perl /root/postfix/postfix-2.3.8/auxiliary/qshape/qshape.pl deferred | grep TOTAL | awk '{print $2 }'`
if [ 100 -lt $defmail ]
then
echo "Attention deferred Mail greater then 100: $defmail" | mail -s "problem" mail@domain.tld
fi

Nur noch mail@domain.tld anpassen und eventuell auch die Zahl 100 in der IF Abfrage

Noch nen kleinen crontab eintrag und dann läuft das minütlich.

crontab -e

*/1 * * * * bash /root/mailmonitoring.sh

Speichern und fertig.

Viel Spaß damit und eine sichere Mailübermittlung.