Zeitzone auf Linux ändern
Die Zeit auf Linux/Unix Systemen läuft tyischer weise in UTC. Die lokale Zeit könnt Ihr einfach wie folgt einstellen:
dpkg-reconfigure tzdata
Die Ausgabe kann dann wie folgt aussehen.

Die Zeit auf Linux/Unix Systemen läuft tyischer weise in UTC. Die lokale Zeit könnt Ihr einfach wie folgt einstellen:
dpkg-reconfigure tzdata
Die Ausgabe kann dann wie folgt aussehen.
Postflix ist ein MTA. Manchmal ist es aus veschiedenen Gründen notwendig die Mailqueue zu reprozessieren.
Die Mailqueue kann man einfach mit “mailq” oder “postqueue -p” abfragen.
Um die Mailqueue zu reprozessieren einfach folgenden Befehl ausführen:
postqueue -f
In den Logs könnt Ihr den Fortschritt verfolgen:
tail -f /var/log/mail.log
Um Dockercontainer über einen VPN Container zu routen muss man nicht viel konfigurieren. Am Beispiel von NordVPN erkläre ich wie ihr andere Container, beispielsweise jDownloader über ein VPN Netzwerk routen könnt.
docker run -ti --cap-add=NET_ADMIN --device /dev/net/tun --name vpn -e RECREATE_VPN_CRON="5 */3 * * *" -e RANDOM_TOP=10 -e USER=<username> -e PASS=<password> -d azinchen/nordvpn
Bei dem obigen aufruf ist es wichtig den Name des Containers zu setzen. In meinem Beispiel “vpn”.
Im Anschluss kann man nun jeden belibigen Container and den VPN Client binden. Im folgenden Beispiel verknüpfe ich einen Debian Container mit dem VPN Client. Hier ist es wichtig –net=container:vpn anzugeben.
docker run -it --net=container:vpn -d debian
Startet man ein traceroute im Debian Container sieht man nun, dass Pakete über den VPN tunnel geroutet werden. Jeder Container kann so über den Tunnel geroutet werden.
Wie kann man per tar direkt auf einen remote Server schreiben? Warum möchte man direkt per tar auf einen remote Server sichern? Diese Fragestellung tritt speziell dann auf, wenn man auf den zu sichernden Server nur wenig verbleibende Disk-Kapazität hat. Typischerweise sind das dann Datenbankserver, oder wie in meinem Fall Webserver, die eine OwnCloud Instanz hosten. Da auch im Web der Festplattenspeicher teuer ist, nutze ich mein NAS zu Hause zu die Daten zu sichern. Hier steht ja in gewissem Maße unbegrenzter Speicherplatz zur Verfügung.
Also gut, dann erzeugen wir ein Archiv und pipen die Ausgabe direkt per SSH auf den Remote Speicher um.
tar zcvf - /var/www/ | ssh -p 22 root@nas.tschoerner.eu "cat > /media/backup/WebServer.tar.gz"
Nun wird das erzeugte Archiv direkt auf den SSH Server umgeleitet.
Müsst Ihr nun ein Backup wieder herstellen, so könnt Ihr das auch, ohne das Archiv kopieren zu müssen:
cd / ssh -p 22 root@nas.tschoerner.eu "cat /media/backup/WebServer.tar.gz" | tar zxvf -
Kürzlich habe ich meinen WebServer umgestellt und betreibe einen Hiawantha Server. Um WordPress zu betreiben, setze ich mal voraus, dass der Server installiert ist (vergleiche hier), und ihr eine Datenbank angelegt habt.
Nun müsst ihr in der Datei /etc/hiawantha/hiawantha.conf die Rewrite-Rule einfügen:
UrlToolkit { ToolkitID = wp-multi Match ^/index\.php$ Return Match ^/([_0-9a-zA-Z-]+/)?wp-admin$ Redirect /$1wp-admin/ RequestURI exists Return Match ^/([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) Rewrite /$2 Match ^/([_0-9a-zA-Z-]+/)?(.*\.php)$ Rewrite /$2 Match .* Rewrite /index.php?$1 }
Jetzt legt Ihr noch ein vHost in der gleichen Konfig an:
VirtualHost { Hostname = XXX.tschoerner.eu,*.XXX.tschoerner.eu WebsiteRoot = /var/www/XXX.tschoerner.eu/public AccessLogfile = /var/www/XXX.tschoerner.eu/log/access.log ErrorLogfile = /var/www/XXX.tschoerner.eu/log/error.log StartFile = index.php TimeForCGI = 60 UseFastCGI = PHP7 # --> PHP Version CustomHeader = X-Frame-Options: sameorigin CustomHeader = Vary: Accept-Encoding RandomHeader = 64 UseToolkit = wp-multi # --> This loads the Rewrite Rule EnforceFirstHostname = yes PreventXSS = yes PreventCSRF = yes PreventSQLi = yes }
Nun noch folgende Verzeichnisse anlegen:
mkdir -p /var/www/XXX.tschoerner.eu/log/ mkdir -p /var/www/XXX.tschoerner.eu/public chown -R www-data:www-data /var/www/XXX.tschoerner.eu
Jetzt WordPress herunterladen:
cd wget https://wordpress.org/latest.tar.gz tar xzf latest.tar.gz cd wordpress mv * ../ cd .. rm -rf wordpress rm -rf latest.tar.gz chown -R www-data:www-data /var/www/XXX.tschoerner.eu
Jetzt Hiawantha einmal neustarten, damit unser vHost erkannt wird.
/etc/init.d/hiawatha restart
Nun kann WordPress installiert werden. Hierzu könnt Ihr einfach eure URL aufrufen, in meinem Fall ist es http://XXX.tschoerner.eu
Wenn ihr WordPress von einem anderen Server umgezogen habt, vergleicht auf den fix der Permalinks.
Kürzlich habe ich wieder auffällige Http Attacken auf meine WebServer gesehen. Es kam hierbei zu keinem großen Problem, jedoch hab ich mir die Frage gestellt, ob es sicherere WebServer Konfigurationen als der üblichen LAMP (Linux, Apache, MySQL/MaraDB, PHP) , LNMP (…,Nginx,…) oder LLMP (…Lighttpd…) gibt. Hierbei bin ich dann auf einen interessanten Vergleich gestoßen. Natürlich muss man bei der Quelle etwas vorsichtiger sein (ist die Hiawatha projekt page), aber durchaus sehr interessamt.
Link: Performance testing while under attack
Typischerweise sind Webserver, welche seltenere verbreitet sind weniger im Punkt der Angreifer. Zudem ist Hiawatha ein WebServer, welcher auf Sicherheit ausgelegt ist. Hiawatha stammt vom Entwickler Hugo Leisink und wurde wie bereits erwähnt auf Sicherheit getrimmt. Out of the box ist er bereits gegen Denial-of-Service-Attacken gewappnet.
Nachfolgen beschreibe ich die Konfiguration von Hiawatha auf Debian Jessie mit Php5 & Php7.
System Vorbereiten, neue PHP Quellen hinzufügen & PHP5/7 installieren:
echo "deb http://packages.dotdeb.org jessie all" | tee -a /etc/apt/sources.list.d/dotdeb.list wget -qO - http://www.dotdeb.org/dotdeb.gpg | apt-key add - apt-get update apt-get remove apache* apt-get install php5 php-pear php5-curl php5-mysql php5-fpm php5-gd mariadb-server libxslt1.1 cron logrotate libpopt0 htop nano apt-get install php7.0-cli php7.0-curl php7.0-dev php7.0-fpm php7.0-gd php7.0-mysql php7.0-mcrypt php7.0-opcache php7.0-mbstring php7.0-zip
Nun den Webserver herunterladen:
cd ~ wget https://files.tuxhelp.org/hiawatha/hiawatha_10.2_amd64.deb dpkg -i hiawatha*
Im Großen und Ganzen war es das auch schon, nun geht es an die Konfiguration. Hierbei werde ich die “Standard” Konfiguration von Php-fpm für Version 5 & 7 nutzen. Beide Versionen stellen nach der Installation einen Unix-Socket bereit. Ich trenne die PHP Konfig hier nicht nach Web/User.
PHP5 Default Socket
/var/run/php5-fpm.sock
PHP7 Default Socket
/run/php/php7.0-fpm.sock
Nun den PHP Interpreter in der Hiawatha Konfig bekannt machen:
FastCGIserver { FastCGIid = PHP5 ConnectTo = /var/run/php5-fpm.sock Extension = php } FastCGIserver { FastCGIid = PHP7 ConnectTo = /run/php/php7.0-fpm.sock Extension = php }
Und im Standard Webserver bekannt machen, unterhalb von:
# DEFAULT WEBSITE # It is wise to use your IP address as the hostname of the default website # and give it a blank webpage. By doing so, automated webscanners won't find # your possible vulnerable website. #
folgendes einfügen:
UseFastCGI = PHP7 # --> für PHP7 oder UseFastCGI = PHP5 # --> für Php 5.6
Anschließend alle Services einmal neustarten:
/etc/init.d/php7.0-fpm restart /etc/init.d/php5-fpm restart /etc/init.d/hiawatha restart
Jetzt noch schnell checken ob Hiawatha auch lauscht:
root@server:~# netstat -anp |grep hiawatha tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 9397/hiawatha tcp6 0 0 :::443 :::* LISTEN 9397/hiawatha tcp6 0 0 :::80 :::* LISTEN 9397/hiawatha
Wenn Ihr nun im Browser folgendes aufruft http://<serverip> sollte sicher Hiawatha wie folgt melden.
Um nun zu testen ob auch PHP funktioniert einfach folgendes ausführen:
echo "<?php phpinfo(); ?>" > /var/www/hiawatha/info.php
Anschließend folgendes im Browser aufrufen: http://<serverip>/info.php
Im besten Fall sieht das Ergebnis wie folgt aus:
Kürzlich stand ich vor dem Problem, dass einer meiner VPS Server immer vom Hoster gestoppt wurde. Dieses Problem tritt häufig auf, wenn bei einem 1 vCPU Server der CPU-load länger als 10 Minuten über 1.00 liegt.
Zur Lösung des Problems habe ich das Tool CPULIMIT entdeckt. Es gibt es auf Ubuntu & Centos / bereits als pre-kompiliertes Paket un kann einfach via apt-get oder yum installiert werden.
yum install cpulimit gawk
Im Anschluss habe ich ein Skript zu start eines Daemon hier /usr/bin/cpulimit_daemon.sh angelegt, mit diesem Inhalt:
#!/bin/bash # ============================================================== # CPU limit daemon - set PID's max. percentage CPU consumptions # ============================================================== # Variables CPU_LIMIT=20 # Maximum percentage CPU consumption by each PID DAEMON_INTERVAL=3 # Daemon check interval in seconds BLACK_PROCESSES_LIST= # Limit only processes defined in this variable. If variable is empty (default) all violating processes are limited. WHITE_PROCESSES_LIST= # Limit all processes except processes defined in this variable. If variable is empty (default) all violating processes are limited. # Check if one of the variables BLACK_PROCESSES_LIST or WHITE_PROCESSES_LIST is defined. if [[ -n "$BLACK_PROCESSES_LIST" && -n "$WHITE_PROCESSES_LIST" ]] ; then # If both variables are defined then error is produced. echo "At least one or both of the variables BLACK_PROCESSES_LIST or WHITE_PROCESSES_LIST must be empty." exit 1 elif [[ -n "$BLACK_PROCESSES_LIST" ]] ; then # If this variable is non-empty then set NEW_PIDS_COMMAND variable to bellow command NEW_PIDS_COMMAND="top -b -n1 -c | grep -E '$BLACK_PROCESSES_LIST' | gawk '\$9>CPU_LIMIT {print \$1}' CPU_LIMIT=$CPU_LIMIT" elif [[ -n "$WHITE_PROCESSES_LIST" ]] ; then # If this variable is non-empty then set NEW_PIDS_COMMAND variable to bellow command NEW_PIDS_COMMAND="top -b -n1 -c | gawk 'NR>6' | grep -E -v '$WHITE_PROCESSES_LIST' | gawk '\$9>CPU_LIMIT {print \$1}' CPU_LIMIT=$CPU_LIMIT" else NEW_PIDS_COMMAND="top -b -n1 -c | gawk 'NR>6 && \$9>CPU_LIMIT {print \$1}' CPU_LIMIT=$CPU_LIMIT" fi # Search and limit violating PIDs while sleep $DAEMON_INTERVAL do NEW_PIDS=$(eval "$NEW_PIDS_COMMAND") # Violating PIDs LIMITED_PIDS=$(ps -eo args | gawk '$1=="cpulimit" {print $3}') # Already limited PIDs QUEUE_PIDS=$(comm -23 <(echo "$NEW_PIDS" | sort -u) <(echo "$LIMITED_PIDS" | sort -u) | grep -v '^$') # PIDs in queue for i in $QUEUE_PIDS do cpulimit -p $i -l $CPU_LIMIT -z & # Limit new violating processes done done
Um das Skript ausführen zu können müssen noch die Berechtigungen geändert werden:
chmod 755 /usr/bin/cpulimit_daemon.sh
Um nun den Job zu starten einfach ein Skript wie folgt unter /etc/init.d/cpulimit anlegen:
#!/bin/sh # # Script to start CPU limit daemon # set -e case "$1" in start) if [ $(ps -eo pid,args | gawk '$3=="/usr/bin/cpulimit_daemon.sh" {print $1}' | wc -l) -eq 0 ]; then nohup /usr/bin/cpulimit_daemon.sh >/dev/null 2>&1 & ps -eo pid,args | gawk '$3=="/usr/bin/cpulimit_daemon.sh" {print}' | wc -l | gawk '{ if ($1 == 1) print " * cpulimit daemon started successfully"; else print " * cpulimit daemon can not be started" }' else echo " * cpulimit daemon can't be started, because it is already running" fi ;; stop) CPULIMIT_DAEMON=$(ps -eo pid,args | gawk '$3=="/usr/bin/cpulimit_daemon.sh" {print $1}' | wc -l) CPULIMIT_INSTANCE=$(ps -eo pid,args | gawk '$2=="cpulimit" {print $1}' | wc -l) CPULIMIT_ALL=$((CPULIMIT_DAEMON + CPULIMIT_INSTANCE)) if [ $CPULIMIT_ALL -gt 0 ]; then if [ $CPULIMIT_DAEMON -gt 0 ]; then ps -eo pid,args | gawk '$3=="/usr/bin/cpulimit_daemon.sh" {print $1}' | xargs kill -9 # kill cpulimit daemon fi if [ $CPULIMIT_INSTANCE -gt 0 ]; then ps -eo pid,args | gawk '$2=="cpulimit" {print $1}' | xargs kill -9 # release cpulimited process to normal priority fi ps -eo pid,args | gawk '$3=="/usr/bin/cpulimit_daemon.sh" {print}' | wc -l | gawk '{ if ($1 == 1) print " * cpulimit daemon can not be stopped"; else print " * cpulimit daemon stopped successfully" }' else echo " * cpulimit daemon can't be stopped, because it is not running" fi ;; restart) $0 stop sleep 3 $0 start ;; status) ps -eo pid,args | gawk '$3=="/usr/bin/cpulimit_daemon.sh" {print}' | wc -l | gawk '{ if ($1 == 1) print " * cpulimit daemon is running"; else print " * cpulimit daemon is not running" }' ;; esac exit 0
Nun noch die Berechtigungen ändern:
chown root:root /etc/init.d/cpulimit
Um das Skript auf CentOs zu starten habe ich es einfach am ende von /etc/rc.config eingefügt. somit wird es nach dem Booten automatisch gestartet und limitiert dann die CPU intensiven Jobs.
Heute habe ich die Zeit genutzt und den 4.6er Kernel für Debian Wheezy, respektive für OpenMediaVault kompiliert.
Bei dieser Version sind die USB Module fest im Kernel, somit könnt Ihr ohne Probleme von einem USB-Stick booten. Zusätzlich habe ich die e1000 Module in den Kernel kompiliert.
Hier könnt Ihr die Kernel herunterladen.
Installieren könnt Ihr die Kernel wie immer mit:
dpkg -i linux*.deb
Viel Spaß damit ….
Hallo,
häufig habe ich gesehen, dass User nach dem Kompilieren eines eigenen Kernels auf das Problem stoßen, dass das System nicht mehr bootet. Im speziellen tritt das Problem bei User auf, bei denen das Root device nicht auf einem SATA,SCSI oder SAS befindet, oder aber der Chipsatz spezielle Treiber braucht. So auch bei mir.
Mein Server bootet von einem USB3 Stick, so dass beim Booten schon das XHCI Modul verfügbar sein muss. Ein typischer Indikator ist die Meldung:
Dropping to shell! modprobe: module ehci-orion not found in modules.dep
Hierzu einfach beim Kompilieren die USB Module, oder aber Chipsatz-Module in den Kernel mit aufnehmen. Beim aus führen von make menuconfig einfach die benötigten Treiber mitkompilieren (als Beispiel USB Block Treiber).
Device Drivers –> USB Support
Heute kurz und schmerzlos. Ich habe Euch einen 4.5er Kernel & 4.4.6er gebaut und hier hoch geladen.
Denkt dran an das max_cstate=1 wenn Ihr einen Nuc oder j1900 habt.
4.5 Kernel Image
4.5 Kernel Headers
Weitere OMV Kernel findet Ihr hier.
LTS Kernel gibts hier!
Die Kernel Unterstützen alle das Booten von USB 2 & 3 Devices!