SchlagwortUbuntu

tar auf einen remote Server per ssh

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 -

 

Limit CPU usage on Linux

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.

Quelle: http://ubuntuforums.org/showthread.php?t=992706

Debian/Ubuntu bootet nicht, da das Root Device nicht gefunden werden kann

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

2016-03-04 13_18_41-Photo Station 6

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

2016-04-10 11_40_0 2016-04-10 11_40_50 2016-04-10 11_41_15

 

Apache für LOW Memory VPS/Raspberry Pi optimieren

Apache und LOW Memory vertragen sich ja nicht so wirklich, deshalb eines Vorweg, man sollte wenn man nich unbedingt Apache braucht, auf Alternative wie nginx oder Lighttpd setzen. Ich betreibe eigentlich nur auf allen meinen kleineren Systemen (<2GB Ram) nur nginx und (<256MB Ram) lighttpd. Hier haben ich auch einen Link zu einer Low Memory LLMP Konfiguration.

Nichts desto trotz benötigt man manchmal unbedingt einen Indianer, und so kann man ihn auch auf einem Low Mem Server betreiben.

Also wie gesagt ist das größte Problem der Speicher den der Apache braucht. In der Konfigurationsdatei
/etc/apache2/apache2.conf kann man die Einstellungen tunen.

nano /etc/apache2/apache2.conf

In der Konfigurationsdatei dann folgende Konfiguration vornehmen:

<IfModule mpm_prefork_module>
    StartServers          1
    MinSpareServers       1
    MaxSpareServers       3
    MaxClients           10
    MaxRequestsPerChild 3000
</IfModule>
 
<IfModule mpm_worker_module>
    StartServers          1
    MinSpareThreads       5
    MaxSpareThreads      15 
    ThreadLimit          25
    ThreadsPerChild       5
    MaxClients           25
    MaxRequestsPerChild 200
</IfModule>

Des weiteren empfiehlt sich das Timeout zu reduzieren. KeepAliveTimeout sollte nicht mehr als 15 (Sekunden) betragen.

Nach diesen Einstellungen ist Apache schon wesentlich genügsamen. Jetzt sollte man noch nicht benötigte Module deaktivieren. Mit diesem Befehl seht Ihr alle Apache Module.

apache2ctl -M

Bildschirmfoto 2015-11-15 um 12.21.51

Um beispielsweise einen WordPress Blog zu hosten brauch man folgende Module (wie gesagt, WordPress läuft auch unter nginx & Lighttpd).

LoadModule dir_module modules/mod_dir.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule mime_module modules/mod_mime.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule alias_module modules/mod_alias.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule rewrite_module modules/mod_rewrite.so

Um ein Modul zu deaktivieren kann man entweder die Konfigurationsdatei oder aber folgenden Befehl ausführen:

# Modul aktivieren
a2enmod module_name
#Modul deaktivieren
a2dismod module_name

Anschließend noch den Apache neu starten und Spaß haben.

MySQL Dump richtig Importieren

mysqlJetzt noch ein schneller Tip für heute. Wie bekommt man den MySQL Dump wieder richtig eingespielt? Ich habe immer wieder
das Problem, dass dieses ä,ö und ü nicht korrekt wiederhergestellt werden.

Eigentlich ist es ganz einfach, wenn er Dump im utf8 Format erzeugt wurde, das einfach beim Import mit angeben.

mysql -u root -p --default-character-set=utf8 database < database.sql

 

samba4 als Backup DC für Windows Server 2012 R2

ubuntulogoWenn Ihr, wie auch ich, ein Active Directory zu Hause betreibt, liegt das Bedürfnis von Ausfallsicherheit Nahe. Gerade wenn es um die Zentrale Einrichtung von Benutzern und auch Passwörtern geht steht der Sicherheitsgedanke im Vordergrund. Egal ob der primäre Domainenkontroller auf Windows setzt oder auf Linux, so funktioniert das Setup des 2ten Domainkontrollers gleich.

Der Einfachheit halber gehe ich davon aus, dass die eingesetzte Distribution bereits ein Samba 4 mitbringt. Zu empfehlen it ein Samba > 4.2 da es sonst mit Windows 8/10 und dem Credential Manager zu Problemen kommen kann. Ich persönlich empfehle den Einsatz von Ubuntu oder aber Debian. Bei Debian ist Jessie (v8) oder aber Ubuntu 14.04/15.04/16.04 (Testing) zu empfehlen. Ist ein aktuelles Samba nicht verfügbar, so könnt Ihr in meinem Compileguide ein aktuelles Samba selbst kompilieren.

Nun geht es mit der Installation mit Samba los, hierzu benötigt Ihr natürlich root Rechte.

sudo apt-get update
sudo apt-get install samba

Anschließend entfernen wir die distributionseigene Konfiguration.

cd /etc/samba
mv smb.conf smb.conf.bak

Eigentlich ist die Arbeit jetzt erledigt, wir müssen jetzt nur noch der Domaine beitreten und unser Samba zum AD Controller promoten. Wenn alle DNS Einträge passen, geht es jetzt los:

sudo samba-tool domain join <Domain> DC -Uadministrator --realm=<FQD> --server=<running DC>

Example
samba-tool domain join home.tschoerner.eu DC -Uadministrator --realm=home.tschoerner.eu --server=frankfurt.home.tschoerner.eu

Wenn alles durchgelaufen ist, hat euer Linux nun folgende Rollen:

  • Backup AD Controller
  • DNS Server

Raspberry Pi Images auf SD brennen unter Linux/OSX

Aktuell liegen der Einfachheit halber die Raspberry Distributionen als Image vor. Häufig stellt man sich nun die Frage, wie bekomme ich das Image nun auf die SD-Karte. Unter Windows kann man einfach das Tool Win32-DiskImager nutzen, welches sich zu schreiben von Images als auch zu lesen eignet.

Unter OS X oder Linux findet man deutlich weniger Information zu diesem Thema, aber eigentlich geht es hier noch viel eifacher. Hat man das Image heruntergeladen, liegt es typischerweise als “.img” Datei vor. Jetzt kann man das Image einfach mid dd auf die SD Karte schreiben. dd ist bereits bei OS X und auch bei Linux im minimal Umfang enthalten.

sudo dd bs=1M if=/home/felix/Downloads/2014-12-24-wheezy-raspbian.img of=/dev/mmcblk0

 

lxc usb passthru

Heute mal etwas ausführlicher, deshalb noch ein weiterer Blog zum Thema LXC.

Zuhause habe ich noch einen Farblaser von Samsung. Leider hat der Laser weder einen Netzwerkanschluss noch versteht er AirPrint beziehungsweise Google Cloud Print. Nichts einfacher als das dachte ich mir, und erzeugt einen Ubuntu LXC Gast. Im Anschluss habe ich die Konfiguration des Containers wie folgt bearbeitet. Nach einem Neustart des Containers war das USB gerät, in meinem Fall der Drucker, verfügbar.

lxc.cgroup.devices.allow = c 189:* rwm
lxc.mount.entry = /dev/bus/usb dev/bus/usb none bind,optional,create=dir

 

lxc Gast mit neuen Ubuntu releases

So nachdem ich lange Zeit nichts mehr gebloggt habe, ist es mal wieder Zeit.

Kürzlich stand ich vor dem Problem, dass ich auf meinem LXC Host (ubuntu 14.04.3 LTS) keine test “releases” von Ubuntu als Gast anlegen konnte.
Obwohl alle Vorbedingungen erfüllt waren, konnte ich kein “xenial” Gast erzeugen. Debootstrap endete immer mit einer Fehlermeldung.

Da ich noch ein weiteres Problem mit dem Erzeugen von Container hatte beschloss ich zunächst einmal das Erzeugungsskript zu ersetzen. Hierzu habe ich das aktulle lxc-ubuntu aus den Git geladen:

sudo su
cd /usr/share/lxc/templates/
mv lxc-ubuntu lxc-ubuntu.bak

wget https://raw.githubusercontent.com/lxc/lxc/master/templates/lxc-ubuntu.in
mv lxc-ubuntu.in lxc-ubuntu
nano lxc-ubuntu

Im Anschluss noch die Pfad Variablen wie im Original Skript setzen.

Leider half das nur bedingt. Ich konnte nunmehr wieder alle releases erzeugen, außer xenial. Hierzu fehlte noch ein symbolischer link im debootstrap Ordner.

sudo su
cd /usr/share/debootstrap/scripts/
ln -s gutsy xenial

Im Anschluss war es kein Problem ein Gast auf Basis von Ubuntu Xenial zu erzeugen

sudo su
lxc-create -n tokio -t ubuntu -- --release xenial

Viel Spaß beim testen von Ubuntu Xenial.