Soeben in einer Log gefunden:

postfix/smtpd warning: network_biopair_interop: error reading 5 bytes from the network: Connection reset by peer

Ich wusste schon immer, dass der Einsatz von Linux biologisch wertvoll ist :)

date -d @timetsamp

Also beispielsweise:

~$ date -d @1320057181
Mo 31. Okt 11:33:01 CET 2011

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.

gestern ist unser erster Server mit mehr als 500 GB an Festplatten Speicherplatz online gegangen. Der Server ist ein modifizierter managed Server Profi Dual Core Power! dem zwei zusätzliche Festplatten eingebaut wurden.

Die Installation lief auch ohne irgendwelche Schwierigkeiten, allerdings kam es dann doch bei “df” zu kleinen komplikationen:

~$ df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda2             876G  2.8G  829G   1%

/ udev                   10M   32K   10M   1% /dev

Da scheint wohl eine Umrechnungsroutine nicht so 100%ig zu funktionieren.

Solange die Adresseierung problemlos möglich ist, ist mir dieser kleine Anzeigefehler ziemlich egal ;)
Aber laut den Spezifikationen von ext3 sollte dies ja ohne Probleme möglich sein.

Dann wollen wir doch mal schauen wie sich das weiterhin verhällt.