Archiv für den Monat: Dezember 2013

Sophos UTM RED Server neu starten (nach Update kein RED Tunnel)

Nach dem Update auf 9.107-33 eines Sophos UTM 320 und eines UTM 220 HA Clusters hat sich der RED Tunnel (UTM-2-UTM) nicht mehr aufgebaut. Reboot der UTM kommt nicht in Frage… Das muss auch anders gehen 🙂 Also per SSH auf beiden UTM eingeloggen und die Dienste neu starten – wie bei jedem anderen Linuxsystem auch.
Dies ist zum einem der „red_server.plc“ und auf der Gegenseite der „red_client.plc„. Mit „ps fax“ kann man herausfinden welche PID (Prozess-ID) der Service hat:

<M> mfs-fw:/root # ps fax

25970 ?        Ss     0:00 red_server.plc
26001 ?        S      0:00  \_ UPLOAD [idle]
26010 ?        S      0:00  \_ Socket-Listener
26753 ?        S      0:00      \_ 3ca217239ab6d5c (1) [217.6.37.234]

Nun den Serverdienst anhalten (killen!):

<M> mfs-fw:/root # kill -9 25970

Danach blieb der Socket-Listener „hängen“:

Diesen muß man auch mit der Brutalomethode killen:

<M> mfs-fw:/root # kill -9 26010

Jetzt wieder den Dienst neu starten:

<M> mfs-fw:/root # red_server.plc

Auf der Gegenseite den „red_client.plc“ neu starten. Ebenfalls mit „ps fax“ herausfinden welche PID der Service hat:

<M> as-fw:/root # ps fax

17067 ?        Ss     0:00 red_client.plc
17122 ?        S      0:00  \_ red_client.plc

<M> as-fw:/root # red_client.plc

Logfile sichten:

<M> as-fw:/root # tail -f /var/log/red.log

Nun sollte der Tunnel wieder aufgebaut sein und Traffic darüber laufen:

red-1

Sophos UTM 9.1 Update 9.107-33

Sophos 9107033
9.107-27 wurde von den Updateservern wegen den Problemen mit dem RED50 Kernel entfernt und durch die aktuelle Version 9.107-33 ersetzt. Wichtigste Änderung für mich: Multipath is routing packets on wrong interface after one load balanced ipsec connection fails.

Nachtrag: Es häufen sich Meldungen das es nach dem Update zu massiven Ausfällen kommt. Bei einigen Usern gibt es keine Probleme – andere berichten von einem Totalausfall (Sophos Forum). Ich selbst betreibe einen UTM 220 HA Cluster, einen virtuellen HA Testcluster in VMware und eine standalone VM UTM mit dieser neuen „Firmware“ ohne Probleme. Diese Systeme sind allerdings nicht unter Last….

Apache Optimierung für Shopware

Für den Shop eines Kunden wurde der Linuxserver mit Apache vollständig auf die Software „Shopware“ angepasst und optimiert. Dazu wurden alle PHP Module auf den neuesten Stand gebracht und die Einstellungen auf die beste Performance optimiert. Ein Update auf PHP 5.5 mit dem ZendOptimizer scheitert zurzeit noch an ionCube. Die aktuellste Version von ionCube ist nur bis PHP 5.4 kompatibel (ioncube_loader_lin_5.4.so). Statt dessen wurde als PHP Accelerator die Software APC verwendet. Diese kann mit PECL (PECL ist ein Repository für PHP Extensions) sehr leicht installiert werden.

Erst einige Voraussetzungen schaffen:
apt-get install php-pear php5-dev libpcre3-dev make

Danach kann die Installation durchgeführt werden:
pecl install apc

Build process completed successfully
Installing ‚/usr/lib/php5/20090626/apc.so‚
Installing ‚/usr/include/php5/ext/apc/apc_serializer.h‘
install ok: channel://pecl.php.net/APC-3.1.13
configuration option „php_ini“ is not set to php.ini location
You should add „extension=apc.so“ to php.ini

Noch kleine Anpassungen und den Apache neu starten:
vi /etc/php5/conf.d/apc.ini
extension=apc.so
apc.shm_size = 512M