Update auf TYPO3 4.6 + Debian Lenny

Nur mal eben für zwischendurch für alle, die Debian auf ihrem Server laufen haben und auf die aktuellste Version von TYPO3 aktualisieren wollen. Diese verlangt PHP in der Version 5.3 oder höher. Debian Lenny (stable) kommt aktuell aber nur mit 5.2.x. Um dieses Problem zu beseitigen kann man sich eines zweiten Repositories bedienen, das für die stable Releases auch aktuellere Versionen gebräuchlicher Pakete bereit stellt.

Zunächst in der /etc/apt/sources.list folgendes eintragen:

deb http://php53.dotdeb.org lenny all
deb-src http://php53.dotdeb.org lenny all

(für alle die “stable” anstelle von “lenny” in ihrer sources.list haben, entsprechend hier anpassen).
Anschließend bringen die bekannten befehle das ersehnte PHP 5.3 auf den Server:

apt-get update
apt-get upgrade

Mutt löscht eMails schnell und sauber

Welcher Systemadministrator kennt das nicht: Ein Service wird als bestimmter Benutzer installiert und läuft dann so vor sich hin ohne signifikante Ausfallerscheinungen, ggfs. noch unter Beteiligung eines Cron-Jobs. Irgendwann bekommt man mit (z.B. durch logwatch), dass das Postfach dieses Benutzers plötzlich ein bisschen umfangreicher geworden ist. Ein Blick in die Mailbox verrät, es handelt sich um Ausgaben des Cron-Jobs, die nach Beendigung jedes Durchlaufs per eMail an den Cron-Job Besitzer zugestellt werden. Man erhält also recht viele, kleine, hutzelige eMails, im aktuellen Fall 64000. Mit einem eMail-Client jede einzeln zu löschen dauert vermutlich ewig. Mit ‘mutt’ läßt sich das aber recht elegant lösen.

Shift+d
~s .*

Mit Shift+d (also einem großen D) wechselt man in einen Modus in dem man eine Löschregel angeben kann. In unserem Fall prüfen wir den Betreff (~s) und löschen alles (.*). Auf diese Weise könnte man z.B. auch alle Mails löschen die “SPAM” in ihrer Betreffzeile enthalten (.*SPAM.*).

Lust auf mutt bekommen?

Für weiterführende Informationen bzgl. mutt und der verwendbaren Patterns seien euch folgende URLs ans Herz gelegt:
mutt patterns
mutt manual

PostgreSQL update problem on CentOS

Als ich heute in meiner Linux-VM auf die aktuelle pgdg postgreSQL Version aktualisieren wollte, wurde ich mit folgender Fehlermeldung abgespeist:

warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID e8e345b8
pgdg84/gpgkey
Public key for pgdg-centos-8.4-2.noarch.rpm is not installed

Das Problem liegt darin begründet, dass die Maintainer ihre Pakete mit einem neuen vereinheitlichten Key signieren, der allerdings bei einem Update nicht sofort vorliegt. Es gibt die Möglichkeit das Paket herunterzuladen und es nicht über yum sondern direkt per rpm zu installieren. Zum anderen kann man den Key auch auf dem Server einspielen und danach den Update-Prozess erneut starten. Zweitere Methode ziehe ich persönlich vor:

  1. Den Key hier runterladen: CMD-PGDG-KEY
  2. Als User root folgenden Befehl ausführen: rpm –import CMD-PGDG-KEY
  3. Update erneut starten: yum update

Wer sich für die erste Variante interessiert, kann die Schritte hier nachlesen.

Komische Standardeinstellung Apache+Debian Etch

Durch einen Serverabsturz bin ich heute auf eine etwas verwirrende Standardeinstellung im Apache gestoßen, die laut einigen Foren offenbar nur Debian Etch betrifft.

MaxRequestsPerChild 0

macht den Apache in einigen Situationen zu einem Speicherfresser. Das ganze geht soweit, das der Kernel keinen neuen Speicher mehr allociieren kann, kein Speicher mehr für andere Anwendungen zur Verfügung steht und das System damit lahmgelegt wird. Das ganze äußert sich zunächst dadurch das außer PING nichts mehr funktioniert. Ein Server reboot richtet dann wieder alles, allerdings ist es dann nur eine Frage der Zeit, bis das Problem erneut zuschlägt. Wer in seinem “syslog” Meldungen finden, die wiefolgt aussehen:

kernel: Mem-info:
kernel: Node 0 DMA per-cpu:
kernel: cpu 0 hot: high 0, batch 1 used:0
kernel: cpu 0 cold: high 0, batch 1 used:0
kernel: Node 0 DMA32 per-cpu:
kernel: cpu 0 hot: high 186, batch 31 used:179
kernel: cpu 0 cold: high 62, batch 15 used:49
kernel: Node 0 Normal per-cpu: empty
kernel: Node 0 HighMem per-cpu: empty
kernel: Free pages:        8012kB (0kB HighMem)
kernel: Active:117054 inactive:113464 dirty:0 writeback:0 unstable:0 free:2003 slab:5445 mapped:1 pagetables:11467
kernel: Node 0 DMA free:3996kB min:24kB low:28kB high:36kB active:3980kB inactive:3840kB present:6556kB pages_scanned:9555 all_unreclaimable? yes
kernel: lowmem_reserve[]: 0 993 993 993
kernel: Node 0 DMA32 free:4016kB min:4016kB low:5020kB high:6024kB active:464236kB inactive:450016kB present:1017008kB pages_scanned:1088596 all_unreclaimable? yes
kernel: lowmem_reserve[]: 0 0 0 0
kernel: Node 0 Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
kernel: lowmem_reserve[]: 0 0 0 0
kernel: Node 0 HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
kernel: lowmem_reserve[]: 0 0 0 0
kernel: Node 0 DMA: 1*4kB 1*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 3996kB
Feb 24 15:19:42 catfish kernel: Node 0 DMA32: 2*4kB 15*8kB 9*16kB 5*32kB 10*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 4016kB
kernel: Node 0 Normal: empty
kernel: Node 0 HighMem: empty
kernel: Swap cache: add 3754206, delete 3754206, find 550796/967590, race 100+121
kernel: Free swap  = 0kB
kernel: Total swap = 2104504kB
kernel: Free swap:            0kB
kernel: 261872 pages of RAM
kernel: 5006 reserved pages
kernel: 46543 pages shared
kernel: 0 pages swap cached
kernel: printk: 180 messages suppressed.
kernel: oom-killer: gfp_mask=0x201d2, order=0
kernel:
kernel: Call Trace:
kernel:  [<ffffffff802a666e>] out_of_memory+0x33/0x216
kernel:  [<ffffffff8020e020>] __alloc_pages+0x220/0x2a9
kernel:  [<ffffffff80210db1>] __do_page_cache_readahead+0x95/0x206
kernel:  [<ffffffff8022683e>] sync_page+0x0/0x42
kernel:  [<ffffffff8025cad3>] io_schedule+0x28/0x33
kernel:  [<ffffffff8022683e>] sync_page+0x0/0x42
kernel:  [<ffffffff8025cd6a>] __wait_on_bit_lock+0x5b/0x66
kernel:  [<ffffffff8023d749>] __lock_page+0x5e/0x64
kernel:  [<ffffffff802116ed>] filemap_nopage+0x148/0x314
kernel:  [<ffffffff80208718>] __handle_mm_fault+0x375/0x91a
kernel:  [<ffffffff8020a69c>] do_page_fault+0x39d/0x706
kernel:  [<ffffffff8025c35e>] thread_return+0x0/0xe7
kernel:  [<ffffffff802588e5>] error_exit+0x0/0x84

der sollte mal in sein Apache Konfigurationsfile schauen und darüber nachdenken den besagten Wert z.B. wiefolgt abzuändern:

MaxRequestsPerChild 100

Damit wird verhindert, dass der Prozess Amok läuft, denn nach 100 Requests wird er einfach abgesetzt und ein neuer tritt an seine Stelle. Mal sehen, ob das jetzt auch hilft…