Autor: Marco Firsching

AWStats und Webalizer auf Plesk entfernen

Die beiden Pakete awstats und webalizer über den Plesk Installer (GUI oder CLI) zu entfernen, sollte eigentlich kein Problem sein. Das ganze läuft auch problemlos, allerdings treten dadurch an andere Stelle Probleme auf. Bei mir so geschehen beim Anlegen von Subdomains zu einer bereits bestehenden Domain.

Error: The component AWStats was not installed

Den ersten guten Ansatz brachte Google, bei den Service Plans im entsprechenden „Hosting Plan“ (Default Domain, Default Simple oder eure angelegten Pläne) unter „Hosting Parameters“ die beiden Haken entfernen.

Danach bitte darauf achten, dass alle Domains und die Service Plans „gesynced“ sind. Das sieht man unter „Subscriptions“ und den grünen Haken vor den Domains. Dann kann man mit folgendem Befehl auf der Konsole noch einen kleinen Fallstrick beseitigen:

plesk sbin php_handlers_control --reread

War bei mir nicht der Fall, hat aber laut vielen Foreneinträgen bereits zum Erfolg geführt. Bei mir war das Problem, dass ich bereits AWStats installiert hatte und einige Domains diesen Eintrag noch als „Default“ gesetzt hatten.
Erst nachdem ich in der psa Datenbank den entsprechenden Eintrag auf none gesetzt hatte, lief alles wie am Schnürchen. Anbei der SQL Befehl (Achtung: Bitte in der richtigen Datenbank ausführen!).

USE psa; UPDATE hosting SET webstat='none';

OTRS – Email to big

Nachdem mir vor kurzem OTRS einige E-Mails nicht mehr abgerufen hat, bin ich auf eder Suche danach, auf ein paar mächtige E-Mails mit PDF-Anhang (Einseiter mit 45MB) gestoßen.
Nachdem unsere Gateways bis zu 100MB zulassen, sollten wir die E-Mails auch irgendwann im Ticketsystem finden. Anbei die Settings, welche angepasst werden müssen:

Postfix auf den E-Mail Gateway und dem OTRS
/etc/postfix/main.cf
message_size_limit = 10240000

Auf dem OTRS-Server
/etc/mysql/my.cnf
max_allowed_packet = 100M

In den OTRS Settings
OTRS:
Sysconfig: Core::PostMaster
PostMasterMaxEmailSize 102400

Dienste neu starten nicht vergessen!

Permanent Redirect auf https in der Apache-Config

Regelmäßig stehe ich vor dem Problem, HTTP-Anfragen auf SSL HTTPS umzuleiten. Die einfachste Lösung ist der Einzeiler Redirect permanent / https://www.example.com. Wem dies genügt und wer ohne mod_rewrite auskommt, der kann hier mit dem Lesen aufhören.
Für meine Anwendungsfälle, habe ich hier eine minimalistische Apache V-Host Config hingepackt:

<Virtualhost *:80>
ServerName example.com
ServerAlias *.example.com
DocumentRoot /var/www/html
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
</Virtualhost>

Die drei Zeilen mit „Rewrite“ würden auch problemlos in eine .htaccess-Datei im DocRoot passen. Da besteht allerdings die Gefahr, dass der Webentwickler hier die Hände im Spiel hat und es ist (wenn auch nur minimal bei kleinen Webs oder wenigen V-Hosts) performanter.

MikroTik RSA-Key Login

In meinem letzten Blog-Post habe ich mich mit OpenSSH (ab Version 7.0) und dem SSH-Login bei MikroTik beschäftigt, genauer gesagt mit dem DSA-Algorithmus. Dieser wurde bei OpenSSH neuerdings deaktiviert. Nachdem ich den „Workaround“ eingerichtet und geposted hatte, habe ich mich auf die Suche nach dem RSA Support in der Feature-Liste für die nächsten RouterOS Versionen gemacht. Hätte ich mal lieber im Changelog gesucht, wäre ich auch fündig geworden. Seit RouterOS 6.33 wird RSA beim SSH-Login mit 2048 Bit unterstützt. Das zum Thema „Wer lesen kann ist klar im Vorteil“ oder auch #RTFM, wobei im MikroTik Manual an entsprechender Stelle auch nur DSA erwähnt wird.
Und wenn ich schon dabei bin, teste ich doch gleich mal meinen 4096-bitigen Schlüssel, welchen ich generell für Backups schon erzeugt habe. Funktioniert zu meiner Überraschung.
Und wenn ich eh schon beim „Hardening“ angekommen bin, habe ich noch zwei optionale Parameter für RouterOS gesetzt, welche ich euch ebenfalls empfehlen würde auf dem Terminal zu setzen:

/ip ssh set host-key-size=4096 strong-crypto=yes

MikroTik: SSH Login ab Debian 9.0

UPDATE: Diese Information ist nur noch für ältere RouterOS Versionen vor 6.33 gültig, für neuere Versionen gibt es hier eine ordentliche Lösung.

Nachdem ich vor Kurzem meinen Backup-Server auf das aktuelle Debian 9.0 (stretch) aktualisiert habe, läuft mein Backup-Script für meine MikroTiks nicht mehr. Kein Ein Fall für eine akute Fehlersuche. Meine RouterOS-Config ist im Moment recht statisch, denoch wichtig genug um ein paar Minuten am Wochenende dafür zu opfern. Denn wie heißt es so schön im Buch „Zeitmanagement für Systemadministratoren“ — „Backups, Backups und Backups…“.
Das Backup läuft über SSH mit Key-Authentication mit einem eigenen Script:

#!/bin/bash
MT_HOSTS="mikrotik01.example.com mikrotik02.example.com"
MT_PORT=22
MT_USER=backup
MT_KEY="/root/.ssh/id_dsa"
MT_DIR="/backup/mikrotik"
MT_DATE=$(date +"%Y%m%d-%H%M")
for MT in ${MT_HOSTS}; do
[ ! -d ${MT_DIR}/${MT} ] && mkdir -p ${MT_DIR}/${MT}
ssh -p ${MT_PORT} -i ${MT_KEY} ${MT_USER}@${MT} "/export file=${MT}.rsc"
scp -P ${MT_PORT} -i ${MT_KEY} -B -q ${MT_USER}@${MT}:${MT}.rsc ${MT_DIR}/${MT}/${MT}_${MT_DATE}.rsc
done

Leider akzeptiert MikroTik bisher nur DSA und keine RSA-Keys. Hier liegt auch schon der Fehler: Debian stretch verwendet OpenSSH 7.4 und ab OpenSSH 7.0 wird der DSA-Algorithmus als „weak“ nicht mehr unterstützt. Solange MikroTik keinen RSA-Support implementiert, kann man den DSA-Algorithmus explizit wieder erlauben. Hierfür hab ich im Home-Directory meines Backup-Servers die Config-Datei (~/ssh/config) mit folgender Zeile ergänzt:

PubkeyAcceptedKeyTypes +ssh-dss

Ab dann funktioniert der SSH-Login per PublicKey (und damit mein Backup) wieder tadellos. Alternativ kann auch die Option nur bei dem BackupScript mitgegeben werden. Dafür müssen die SSH Aufrufe im Script mit folgender Option ergänzt werden:

ssh -oHostKeyAlgorithms=+ssh-dss

Quellen:
OpenSSH

Keine Videoausgabe bei VMWare Fusion 8.5 und macOS Sierra (10.12)

Nach einem Update auf die aktuellste VMWare Fusion Version kann es zu einer fehlenden/schwarzen Anzeige beim Video-Output kommen. Die VM startet und ist auch erreichbar, aber über Konsole nur „blind“ zu bedienen.

Der folgende Eintrag am Ende der zugehörigen .vmx-Datei schafft meist Abhilfe:

mks.enableGLBasicRenderer = "FALSE"

Zum editieren hilft der Link aus der KB von VMWare

Editing the .vmx file