Updates

Tags:
Ich habe eine Mailingliste eingerichtet, in die automatisch Zusammenfassungen aller Softwareupdates des Servers gemailt werden.
Wenn also mal wieder plötzlich Anwendung XYZ nicht mehr geht, sollte man mal einen Blick ins Archiv der Liste werfen oder Selbige am besten gleich abonieren.
Tags:
  • Ich habe das Intervall des Cronjob für die Generierung der Webstatistiken auf 20 Minuten hochgesetzt und um 2 Minuten verschoben. Dadurch fallen die Updates der Statistiken (immerhin werden dafür 17 Prozesse - und damit auch 17 Perl-Instanzen - gleichzeitig gestartet) nicht mehr mit den sonstigen Jobs zusammen und das System wird weniger belastet.
    • Alt: xx.00 xx.10 xx.20 xx.30 xx.40 xx.50 Uhr
    • Neu: xx.02 xx.22 xx.42 Uhr
  • Unter dem Punkt Cacti oben im Menü kann man jetzt ein paar Statistiken zu den Diensten abrufen, die auf der Kiste laufen.
  • Der Kernel wurde mal wieder aktualisiert, weshalb ein Reboot nötig war.
Tags:
Es läuft jetzt ein NTP-Server, der a) permanent die Uhr aus dem Netz synchronisiert (technisch: durch Modulation der Timerfrequenz) und b) die Zeit via NTP veröffentlicht.

So man sowieso die Uhrzeit synchronisiert (ich weiss, Windowsler machen sowas nicht ;)), kann also auch die 217.20.127.79 oder einer der diversen Namen, die auf den Server auflösen, verwendet werden:
Quote:
sascha@koma:~$ sudo ntpdate quadcamping.de
 9 Jan 20:50:21 ntpdate[23756]: adjust time server 217.20.127.79 offset -0.050325 sec

/e: habe ihm der Vollständigkeit halber zusätzlich den Namen ntp.quadcamping.de spendiert (DNS kann dauern).

Update:
Habe den Server zum öffentlichen NTP-Pool als Stratum 3 hinzugefügt, Statistiken gibts hier.
Tags:
MySQL auf Version 4.1 geupdatet.
Sollten Probleme auftauchen -> .

Quote:
sascha@susi20nackt:/etc$ dpkg -p mysql-server-4.1 | grep Version
Version: 4.1.13a-3
Tags:
BTW: Gestern habe ich PHP geupdated.
Scheinbar haben sich irgendwelche wichtigeren Sachen geändert und so spuckte z.B. das Webmailscript massenhaft 'notice' + 'warning' aus.

Daher hab' ich alle PHP Meldungen komplett unterdrückt (die normalerweise in den HTML-Output geschrieben werden) und in ein entsprechendes Logfile umgeleitet, einfach um die damit verbundenen Layoutkrankheiten etc. loszuwerden.

Das Problem an der Sache ist, dass, wenn jemand seine Scripte debuggen möchte oder einfach nur mysteriöse Fehler auftreten, er die Fehlermeldungen nicht mehr direkt im Browser sieht. :( Um das halbwegs abzufangen, stelle ich das PHP-Log [red]hier online[/red].

Nachteile:
  • Das Logfile wird wöchentlich rotiert, ist daher womöglich recht groß und Daten vor dem jeweilig letzten Sonntag (da werden die 'weekly'-Logs rotiert) sind schon weg. Allerdings halte ich gezippte Versionen einen Monat lang vor und die Logs sind auf Anfrage natürlich von mir zu bekommen.
  • Fehler können ungesehen "untergehen"
  • Ich hab keine Ahnung wie PHP das macht, aber normalerweise werden (gepufferte) Streams nur in bestimmten Abständen (spätestens wenn der Puffer voll ist) 'geflusht' (und damit auf Platte geschrieben), daher könnten Verzögerungen zwischen dem Auftreten des Fehlers und dessen Manifestation im Logfile auftreten.
Inhalt abgleichen