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

Ein Test mittels “quotaoff /” und “quotaon /” sagten, dass alles in Ordnung sei. Der Test mittels “quotaon -p -u /” lieferte das gewünschte Ergebnis:

user-Quota auf / (/dev/###) ist an

Selbst manuelles setzen der quotas führte zum Erfolg und das quota war aktiv.

Nun was war das Problem mit Confixx?

Letztendlich kamen wir auf die Lösung: Confixx prüft nicht etwa den Rückgabewert von quotaon -p -u / sondern erwartet den String “on”, sprich die englische Variante.

ein “unset LANG” und ein erneutes “quotaon -p -u /” brachten nun das on zu Tage:

user quota on / (/dev/###) is on

Ruft man nun die admin.pl mit nicht gesetzter locale auf kann quota auch direkt aktiviert werden.

Ist es nicht schön wenn Software plötzlich neue Dinge kann?

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.