Tag Archiv für FreeBSD

Lösung des Problems von Postfix mit der OpenSSL Option ZLIB

Vor knapp 2 Wochen habe ich meinen Mailserver von FreeBSD 9.3 auf FreeBSD 10.2 umgezogen. Ich hatte so ziemlich alles vorher getestet, allerdings nicht die Verschlüsselung des Mailverkehrs von Postfix und Dovecot, weil das offizielle Zertifikat auf den Hostnamen ausgestellt war, der zum Zeitpunkt des Testens noch auf dem alten Server konfiguriert war. Da das offizielle StartSSL Zertifikat 2 Tage nach dem Umzug ausgelaufen wäre, habe ich mir ein neues ausstellen lassen und das dann gleich auf dem neuen Server aktiviert. Als dann der Produktivbetrieb auf dem neuen Server startete, produzierten  die SMTP und SMTPD Prozesse von Postfix plötzlich beunruhigend viele Abstürze mit Signal 11:

Dec 10 16:17:10 saruman kernel: pid 72535 (smtpd), uid 125: exited on signal 11
Dec 10 16:18:49 saruman kernel: pid 72552 (smtp), uid 125: exited on signal 11
Dec 10 16:18:49 saruman kernel: pid 72556 (smtp), uid 125: exited on signal 11
Dec 10 16:18:49 saruman kernel: pid 72557 (smtp), uid 125: exited on signal 11
Dec 10 16:18:50 saruman kernel: pid 72553 (smtp), uid 125: exited on signal 11
Dec 10 16:18:50 saruman kernel: pid 72555 (smtp), uid 125: exited on signal 11
Dec 10 16:18:50 saruman kernel: pid 72551 (smtp), uid 125: exited on signal 11
Dec 10 16:18:50 saruman kernel: pid 72550 (smtp), uid 125: exited on signal 11
Dec 10 16:18:51 saruman kernel: pid 72554 (smtp), uid 125: exited on signal 11
Dec 10 16:19:44 saruman kernel: pid 72542 (smtpd), uid 125: exited on signal 11
Dec 10 16:28:18 saruman kernel: pid 72785 (smtpd), uid 125: exited on signal 11

Nach einigem Ausprobieren (Deaktivieren sämtlicher Postfixerweiterungen wie Postgrey, Amavisd-New, dccifd, policyd-weight), Neukompilieren von Postfix mit allen Paketen, von denen es selber abhängig ist, und natürlich ausgiebigen Netzrecherchen bin ich auf diesen Thread der Postfix-User ML gestoßen und die schon 2 Jahre alte und für ein 2.9er Postfix unter FreeBSD 9.2 vorgeschlagenen Lösung, die OpenSSL Kompression beim Bauen von OpenSSL wegzulassen hat mir aktuell auch noch geholfen. Nachdem ich erst OpenSSL ohne ZLIB Option und dann Postfix neu kompiliert hatte, traten keine Signal 11 Crashs mehr auf.

Ergänzung zum Beitrag Core-Dumps beim Apache Start mit aktiviertem PHP

Welche Auswirkungen die falsche Reihenfolge der PHP Module in der extension.ini haben kann, zeigte sich heute an dem FreeBSD 10 Server, den ich gerade als  Nachfolger aufsetze:

===>>> Starting build for ports that need updating <<<===

===>>> Launching child to install comms/pear-Horde_ActiveSync

===>>> All >> comms/pear-Horde_ActiveSync (1/8)

===>>> Currently installed version: pear-Horde_ActiveSync-2.19.0
===>>> Port directory: /usr/ports/comms/pear-Horde_ActiveSync

===>>> Starting check for build dependencies
===>>> Gathering dependency list for comms/pear-Horde_ActiveSync from ports
===>>> Dependency check complete for comms/pear-Horde_ActiveSync

===>>> All >> pear-Horde_ActiveSync-2.19.0 (1/8)

===>  Cleaning for pear-Horde_ActiveSync-2.19.3
===>   pear-Horde_ActiveSync-2.19.3 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by pear-Horde_ActiveSync-2.19.3 for building
===>  Extracting for pear-Horde_ActiveSync-2.19.3
=> SHA256 Checksum OK for Horde/Horde_ActiveSync-2.19.3.tgz.
===>  Patching for pear-Horde_ActiveSync-2.19.3
===>   pear-Horde_ActiveSync-2.19.3 depends on file: /usr/local/share/pear/.channels/pear.horde.org.reg - found
===>   pear-Horde_ActiveSync-2.19.3 depends on executable: pear - found
===>  Configuring for pear-Horde_ActiveSync-2.19.3
===>  Staging for pear-Horde_ActiveSync-2.19.3
===>   Generating packing list with pear
*** Signal 11

Stop.
make: stopped in /usr/ports/comms/pear-Horde_ActiveSync

===>>> make stage failed for comms/pear-Horde_ActiveSync
===>>> Aborting update

===>>> Update for comms/pear-Horde_ActiveSync failed
===>>> Aborting update

===>>> You can restart from the point of failure with this command line:
       portmaster <flags> comms/pear-Horde_ActiveSync devel/pear-Horde_Core archivers/pear-Horde_Pack textproc/pear-Horde_CssMinify www/pear-Horde_Dav databases/pear-Horde_Db mail/pear-Horde_Imap_Client devel/pear-Horde_Timezone

Nachdem ich auch hier die Reihenfolge der Module entsprechend abgeändert hatte, lief das Update problemlos. Ein Core Dump mit Signal 11 habe ich sonst bislang nur bei defektem Ram oder ähnlichem erlebt. Deshalb wäre ich hier normalerweise nie auf die Idee der falschen Ladereihenfolge der PHP Module gekommen.

Core-Dumps beim Apache Start mit aktiviertem PHP

Seit einiger Zeit kämpfte ich nach nahezu jedem Update von Apache oder PHP damit, daß anschließend mein Webserver beim Starten mit Core Dump die Grätsche machte. Ich habe dann eigentlich immer erstmal PHP komplett deaktiviert, damit die Websites die ohne PHP laufen, nicht beeinträchtigt wurden. Dann habe ich so lange verschiedene PHP Module neu kompiliert, bis es irgendwann wieder ging. Das war teilweise ein langes, nerviges Vorgehen und vor allem war mir trotz ausführlichem Googlen weder die echte Ursache noch die wirkliche Lösung ersichtlich. Das Problem äußerte sich neben dem kommentarlosen Crash des Indianers durch folgende Einträge im PHP-Log:

[15-Oct-2014 01:07:42 Europe/Berlin] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20121212/memcache.so' - /usr/local/lib/php/20121212/memcache.so: Undefined symbol &quot;php_session_create_id&quot; in Unknown on line 0
[15-Oct-2014 01:07:42 Europe/Berlin] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20121212/memcached.so' - /usr/local/lib/php/20121212/memcached.so: Undefined symbol &quot;ps_globals&quot; in Unknown on line 0
[15-Oct-2014 01:07:43 Europe/Berlin] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20121212/igbinary.so' - /usr/local/lib/php/20121212/igbinary.so: Undefined symbol &quot;ps_globals&quot; in Unknown on line 0
[15-Oct-2014 01:07:43 Europe/Berlin] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20121212/soap.so' - /usr/local/lib/php/20121212/soap.so: Undefined symbol &quot;ps_globals&quot; in Unknown on line 0
[15-Oct-2014 01:07:43 Europe/Berlin] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20121212/wddx.so' - /usr/local/lib/php/20121212/wddx.so: Undefined symbol &quot;ps_globals&quot; in Unknown on line 0

Heute habe ich dann scheinbar besser gesucht bzw. bin endlich auf die offizielle Seite des Moduls gegangen und habe dort tatsächlich die Lösung gefunden:

Abstürze und Startprobleme von PHP können auftreten, wenn die Recode-Extension nach einer der beiden Extensions mysql oder imap geladen wird. Wenn die Recode-Extension vor den genannten anderen geladen wird, tritt das Problem nicht auf.

Nachdem ich das Modul in der /usr/local/etc/php/extensions.ini von fast letzter an die zweite Stelle verschoben hatte, klappte es auch wieder problemlos mit dem Starten des Indianers!

Ich hoffe, damit ist dieses Problem für immer erledigt.

Macken der Rossmann Fotoservice Software (Version 2.6)

Wir wollen aus Karins Blog ein Photobuch erstellen und hatten uns für die Rossmann Fotoservice Software entschieden, da wir mit Rossmann bei Digitalphotos eigentlich ganz gute Erfahrungen gemacht haben. Aber als Karin ihr erstes Photobuch speichern wollte, da funktionierte das nicht, denn beim Laden am nächsten Tag waren alle ausgesuchten Photos verschwunden und eigentlich nichts mehr von der bisherigen Arbeit übrig. Ich habe es dann auch probiert und als ich das Problem sofort reproduzieren konnte, habe ich mir sämtliche Konfigurationsoptionen vorgenommen, aber nichts hat bewirkt, daß ein gespeichertes Photobuch wieder ladbar war. Beim genauen Beobachten des Speicherns konnte ich dann feststellen, daß zunächst in einem Unterverzeichnis mit dem gleichen Namen wie die Photobuch pbf- Datei alle benutzten Photos als File_XYZ.jpg und das Cover als CoverPreview.jpg gespeichert wurde. Aber in dem Moment, wenn das Speichern beendet ist, verschwinden sämtliche Dateien in dem Unterverzeichnis und die Software findet beim nächsten Laden die referenzierten Dateien nicht mehr. Na gut, was macht man als Systemadministrator üblicherweise bei so einem Problem? Man versucht als erstes, statt auf dem Server lokal zu speichern und siehe da: Lokal hat es sofort einwandfrei funktioniert! Kommt wahrscheinlich sehr selten vor, daß Privatleute ihre Daten auf einem Netzlaufwerk speichern, wobei das sicher angesichts des Billig-NAS Booms in Zukunft häufiger wird. Vielleicht kommt die Software auch einfach nicht mit einem Sambashare unter FreeBSD klar. Aber das halte ich eher für unwahrscheinlich. Was an der Software auch sehr nervig ist: Wenn man sie startet, dann sucht sie in einem separaten Fenster nach Updates. Während dieser Updatesuche, die recht lange dauert, kann man die Software nutzen und noch weitaus schlimmer: Wenn man während dieser Zeitspanne etwas anderes machen will und zu einem anderen Task wechselt, dann drängelt sich dieses Updatefesnter mehrfach wieder in den Vordergrund, was wirklich ätzend ist, wenn man dabei z.B. gerade Texte schreibt: Murks, Murks, Murks! Aber wenigstens ist der Workaround für das Speicherproblem halbwegs annehmbar: Zunächst lokal speichern und dann pbf-Datei samt Unterverzeichnis per Hand auf den Server kopieren. Ach ja, auf dem Laptop von Karin (WinXP SP3) stürtzt das Programm auch noch mehrmals pro Tag ab. Da aber alle 5 min automatisch gespeichert wird, ist das nur ärgerlich und nervig, aber nicht so dramatisch.

ACPI unter FreeBSD abschalten

In der loader.conf:
hint.apic.0.disabled=“1″
eintragen und rebooten.

Konvertieren von Dateien mit DOS-Zeilenumbrüchen (^M) unter FreeBSD

Immer wieder hat man Dateien, bei denen man das DOS-Zeilenende ^M los werden will, vor allem wenn es um Webseiten geht, egal ob html oder php. Früher unter Linux oder dem 4er FreeBSD habe ich dafür immer dos2unix genommen, aber beim 6er FreeBSD ist der Port verschwunden und der Port /usr/ports/converters/dosunix erzielt zwar das gleiche Ergebnis, aber dazu muß man erst je eine Zieldatei mit anderem Namen erstellen und dann diese Datei in den ursprünglichen Namen umbenennen. Deshalb habe ich dann meistens doch andere Varianten gewählt, sobald ich mehr als 2 Dateien so bearbieten mußte. Wie üblich gibt es dazu wieder mehrere Möglichkeiten, die im FreeBSD Diary ausführlich beschrieben sind:

  • Der Perl-Klassiker: perl -pi -e "s:^V^M::g" <filenames>
  • cat <filename1> | tr -d "^V^M" > <newfile>
  • sed -e "s/^V^M//" <filename> > <output filename>
  • Die vi-Lösung: 1. hit the ESC key und 2. :%s/^V^M//

Meistens habe ich in letzter Zeit die perl und die sed-Variante genutzt. Aber im FreeBSD Diary Artikel findet sich ganz am Ende noch der Hinweis, daß das Programm dos2unix jetzt im Port /usr/ports/converters/unix2dos steckt. Und damit habe ich dann endlich wieder mein geliebtes altes dos2unix, mit dem das Konvertieren der Dateien in einem Rutsch geht (dos2unix *.php *,html *.css *.js). Da habe ich wohl beim Umstieg auf das 6er FreeBSD am Anfang nicht gut genug gesucht.

Port trotz bekanntem Security Advisory installieren (Meldung „has known vulnerabilities“ beim portupgrade)

Wenn sich ein Port nicht updaten oder installieren läßt, weil eine Sicherheitslücke bekannt geworden ist und deshalb portaudit eine Installation oder ein Update verhindert, dann kann man sich darüber mit der Systemvariabelen DISABLE_VULNERABILITIES hinwegsetzen. Als Extremtippfauler habe ich mir dazu dann noch folgende Aliase für root eingerichtet:

port-no-vuln    setenv DISABLE_VULNERABILITIES true
mpicf   make DISABLE_VULNERABILITIES=true package install clean
pupf    setenv DISABLE_VULNERABILITIES true && portupgrade -abyvR

sshguard konfigurieren und aktivieren

Nach der Installation des sshguard-Ports ist noch folgendes notwendig, damit es auch wirklich Angreifer blockt:

Einrichtung der pf-Firewall unter FreeBSD: http://sshguard.sourceforge.net/doc/setup/blockingpf.html

Die Beschränkung des blockierten Verkehrs auf den ssh-Port 22 hat bei mir mit der Zeile

block in quick on $ext_if from <sshguard> to any port 22 label "ssh bruteforce"

nicht funktioniert, sondern nur die Variante mit der allgemeinen Blockierung allen Traffics mit dieser Adresse (also die Zeile oben ohne "to any port 22"). Es macht aber in meinen Augen eh keinen Sinn, nur den Port 22 zu schützen. Wenn jemand mehr oder weniger stümperhaft einzudringen versucht, dann sollte man ihm keine weiteren Versuche auf anderen Ports geben! Ich habe dann noch folgenden Alias für mich eingerichtet, damit ich schnell sehen kann, welche Adressen momentan blockiert sind:

alias sblock 'pfctl -Tshow -tsshguard'

Ich habe auch noch ein touch /etc/hosts.deny ausgeführt, weil sshguard teilweise das Fehlen dieser Datei angemeckert hatte, aber ich nehme an, daß sich diese Meldung nach dem Umstieg auf den sshguard-pf Port eigentlich eh erledigt hatte.

Whitelisting von Adressen: http://sshguard.sourceforge.net/doc/usage/whitelisting.html

SCCS – Versionskontrolle für Konfigurationsdateien

Unter FreeBSD gibt es einen Port von CSSC (/usr/ports/devel/cssc) als SCCS-Klon. Eine gute und knackige Einführung dazu findet man von Oliver Fromme hier.