Terminal umschalten mit dem Befehl “chvt”

In der Regel schaltet man mit der Tastenkombination <STRG>+<ALT>+<F1> … <F2> …

usw. die TTY-Konsolen durch.

Dabei gibt es auch die Möglichkeit, mit dem Befehl

chvt 1

nach TTY1 zu wechseln und mit

chvt 2

zu TTY2, und so weiter…

Wo macht das Sinn?

Nun, zum einen, wenn man beim Tippen “schnell” mal wechseln möchte, oder wenn man einen Konsolenwechsel in ein Script einbauen will.

Seid gegrüßt
Alf

Flattr this!

Ansible – Simple IT Automation

Hallo Leute,

sobald mehrere Server zum verwalten sind, muss man sich die Frage stellen wie man das Ganze bessere organisieren kann. Dazu gibt es viele Möglichkeiten, ich will euch heute aber diesbezüglich “Ansible” vorstellen. Ich habe Ansible jetzt seit über einem Jahr selber im Einsatz und bin sehr zufrieden damit, es nimmt einem wirklich viel Arbeit ab, vor allem bei immer wiederkehrenden Aufgaben wie Updates installieren usw.

Mit Ansible ist es möglich sogenannten “Playbooks” zu erstellen. Das sind im Prinzip Rezepte wie bei “Puppet” und “Chef”. Der Vorteil ist aber, dass Ansible keine Installation auf den Servern benötigt, es arbeitet über SSH. Nur auf dem Client (in meinem Fall mein MacBook Pro) muss Ansible installiert werden. Ansible ist eine Python Anwendung, funktioniert also auf allen Systemen.

Installation

Ich werde in dieser Anleitung mit meinem MacBook Pro arbeiten, alle Befehle und Einstellungen funktionieren aber auch genauso auf einem Linux Client. Die Installation ist schnell erledigt:

Debian

pip install ansible

OS X

brew install ansible

Inventory File

Das “Inventory File” ist die Konfigurationsdatei der Hosts die mit Ansible gesteuert werden sollen. Ich habe einen Ordner unter

~/ansible

und darin habe ich meine “Playbooks” und meine “hosts” Datei (also das Inventory File). Dies sollte in der “.bashrc” hinzugefügt werden, sonst muss man bei jedem Ansible Befehl “-i PFAD-ZUM-INVENTORY-FILE” angeben. Also

vim ~/.bashrc

und folgende Zeile einfügen und an eure Umgebung anpassen

export ANSIBLE_HOSTS=/Users/lewis/ansible/hosts

In dem File könnt ihr jetzt verschiedenen Gruppen anlegen, zum Beispiel eine für alle Debian Server (für das Update Playbook) eine Java8 Gruppe für alle Server die eine Java8 Installation benötigen usw. In dieser Anleitungen arbeiten wir mal mit diesen 2 Beispielen. Hier mal das “hosts” (Inventory File) für diese 2 Gruppen:

[debian]
GLaDOS.aperture.lab:2233     	ansible_ssh_user=root    # GLaDOS
wheatley.aperture.lab:2233  	ansible_ssh_user=root    # wheatley
caroline.aperture.lab:2233    	ansible_ssh_user=root    # caroline

[java]
caroline.aperture.lab:2233      ansible_ssh_user=root    # caroline

In der ersten Spalte steht der Servername (kann auch eine IP Adresse sein), dahinter ist der SSH Port, falls ihr in eurem lokalen Netzwerk seid und den Standartport 22 verwendet könnt ihr “:2233” entfernen, anderfalls auf euren SSH Port anpassen.

Die zweite Spalte gibt den User an mit dem sich Ansible auf dem Server verbinden soll, wenn diese Spalte nicht gesetzt ist, verwendet Ansible automatisch den User mit dem man auf dem Client angemeldet ist. In meinem Fall wäre das “LEWIS” und diesen User gibt es auf den Servern gar nicht. Die dritte Spalte ist für Notizen bzw. Kommentaren, muss nicht gesetzt werden.

Playbook

Ein Playbook ist schnell erstellt und auch relative einfach zu bearbeiten. Es gibt eine sehr gute Dokumention für Ansible und für so gut wie alles was man in der IT Verwaltung braucht ein Module. So wie eben auch ein apt-get Module. Das erste Beispiel wird das Upgrade Playbook.

vim ~/ansible/upgrade.yml

Mein Upgrade Playbook schaut so aus:

---
- hosts: debian
  user: root

  tasks:

    - name: apt update
      action: apt update_cache=yes

    - name: apt install
      action: apt upgrade=dist force=yes

Der Punkt “hosts” gibt an welche Gruppe im Inventory File angesprochen werden soll. User ist in diesem Fall überflüssig da wir den User schon im hosts File angegeben habe, ich lasse es aber immer in meinem Playbooks drinnen. Danach sind die Tasks zu definieren die gemacht werden sollen.

Im Grunde wird ein “apt-get update” und ein “apt-get dist-upgrade” gemacht.

Um dieses Playbook auszuführen, geben wir einfach diesen Befehel ein und schon bekommt man eine nette Übersicht was erledigt wurde:

ansible-playbook upgrade.yml

Output:

Ansible Playbook Output #1

Hier sieht man das alle Systeme in diese Gruppe auf dem aktuellen Stand sind und keine Änderungen vorgenommen wurden. Bei Änderungen würde man das dann im “Recap” sehen unter “changed=1” bzw. würde sich die Farbe von gelb auf orange ändern.

Ich verbinde dieses Playbook mit “apitcron”, jedesmal wenn ich eine Mail bekomme das Updates verfügbar sind, führe ich das Playbook aus und schon sind alle Server wieder auf dem aktuellsten Stand.

Das zweite Beispiel ist das Playbook um Java8 zu installieren, diese Packet gibt es ja noch nicht in der offiziellen Debian Repository, da wir das aber immer wieder mal brauchen habe ich mir dafür ein Playbook geeschrieben, es geht ja nichts um automatisierung :)

vim ~/ansible/java8.yml

Dieses Playbook ist schon etwas komplizierter, im Grunde aber genauso einfach und verständlich:

---
- hosts: java
  user: root

  tasks:

    - name: check if required packages are installed
      action: apt name={{ item }} state=latest update_cache=yes
      with_items:
        - python-software-properties

    - name: add java repository to sources.list
      action: apt_repository repo='deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main' state=present

    - name: accept license for java
      action: shell echo oracle-java8-installer shared/accepted-oracle-license-v1-1 select true | /usr/bin/debconf-set-selections

    - name: apt update
      action: apt update_cache=yes

    - name: apt install
      action: apt pkg=oracle-java8-installer state=latest install_recommends=yes force=yes

    - name: set env
      action: apt pkg=oracle-java8-set-default state=latest install_recommends=yes force=yes

Hier wird eine Repository hinzugefügt, die Oracel Lizenz akzeptiert und dann Java8 installiert. Der Output sieht dann so aus:

Ansible Playbook Output #2

Zusammenfassung

Wie man sieht hat Ansible viele Vorteile und erleichtert den Arbeitsaltag, vorallem bei wiederkehrenden Aufgaben von denen wir ja alle genügend haben. Man kann mit ein wenig herumspielen eigentlich alles automatisieren da es für alles Module gibt und auf “GitHub” und co. findet man auch schon viele fertige Playbooks die man übernehmen kann.

Hier noch eine Link Liste:

peace
LEWIS

Flattr this!

rdiff-backup – Die Linux TimeMachine

Hallo Leute,

ich suchte vor einiger Zeit lange nach einem geeigneten Backupsystem für unsere Linux IT Landschaft. Wir hatten damals bacula im Einsatz; dies hat uns überhaupt nicht zugesagt. Danach schrieb ich eigene Shell Backupscripts, was zwar funktionierte, aber sehr mühsam zu warten war und somit auch nicht ideal war.

Im Grunde waren folgende Punkte wichtig:

  • Inkrementelle Backups (Platz sparen bzw. Bandbreite sparen)
  • Voll automatisiert
  • Einfach und verständlich in der Konfiguration

im Grunde also eine Art “TimeMachine” für Linux. Durch Zufall stieß ich dann endlich auf rdiff-backup – dies war ein Heureka für mich. Zuletzt hatte ich das gefunden was ich seit Monaten suchte. Wir setzen rdiff-backup jetzt seit knappen 2 Jahren ein und waren nie glücklicher. Auch die schlechten Gefühle am Abend sind jetzt weg. Noch dazu verwenden wir mein “offsite-backup-script”.

rdiff-backup ist im Grunde eine Kombination aus rsync, ssh und einem klugen Shell Script.

Zur Installation

“rdiff-backup” muss auf dem Backupserver sowie auf dem zu sichernden Server installiert werden.

apt-get install rdiff-backup

das wars auch schon bezüglich Installation.

Konfiguration

Die Konfiguration ist kinderleicht und funktioniert auch leicht und übersichtlich wenn man mehrere Server sichern will.

Zuerst erstellt man einen SSH Key auf dem Backupserver (Server A) und fügt diesem auf dem zu sichernden Server (Server B) ein.

Danach erstellt man ein “ssh-konfiguration file” unter dem Benutzer der dann das Backup ausführen soll (in diesem Fall root):

vim /root/.ssh/config

Hier fügen wir dann alle Server im folgendem Format ein:

Host serverB
HostName serverB.example.com
Port 22
User root

danach die Datei speichern und schließen.

Nun solltet ihr auf dem Backup Server via

ssh serverB

auf den zu sichernden Server zu kommen (ohne Passwort und weitere Angaben). Funktioniert das können wir fortfahren.

Der letzte Schritt ist ein Script anlegen, welches “rdiff-backup” ausführt und die Backups macht:

vim /root/scripts/rdiff-backup.sh

#!/bin/bash

# Lokales Backup
rdiff-backup /etc /srv/backups/serberA/etc/

# Remote Backup
rdiff-backup serverB::/etc /srv/backups/serverB/etc

Das Script muss man natürlich an seine Anforderungen anpassen. Die Verzeichnisse müssen schon erstellt worden sein (/srv/backups/serverB/etc usw) ansonsten funktioniert “rdiff-backup” nicht.

Danach speichern und das Script ausführbar machen:

chmod +x /root/scripts/rdiff-backup.sh

und via

crontab -e
30 1 * * * sh /root/scripts/rdiff-backup.sh

als Cronjob hinzufügen. Ihr könnt das Script auch jederzeit manuell ausführen, danach findet ihr in eurem Backupverzeichnis immer die aktuellen Files sowie die Inkrementellen Files (diese müssen via einem Befehl wiederhergestellt werden)

Kleiner Tipp: Fügt “10 22 * * * dpkg -l > /etc/dpkg_list” in euren Contab hinzu, damit wisst ihr bei einem Totalausfall eures Servers immer genau welche Pakete/Libraries installiert waren und spart so viel Zeit beim Wiederherstellen.

Wiederherstellung

Zum Wiederherstellen eines Verzeichnisses könnt ihr entweder den Ordner auf wieder auf den Server kopieren (im Backupordner sind immer die aktuellsten Files) oder ihr verwendet den “rdiff-backup” Befehl dafür:

#Stellt ein aktuelles Backup wieder her
rdiff-backup -r now serverB::/etc /srv/backups/serverB/etc

#Stellt das Verzeichnis wieder her wie es vor 10 Tagen war
rdiff-backup -r 10D serverB::/etc /srv/backups/serverB/etc

Backups löschen die älter als X Tage sind

Falls ihr ältere Backups nicht mehr benötigt, dafür aber den Speicherplatz, könnt ihr mit

rdiff-backup --force --remove-older-than 12W /srv/backups/serverB/etc

alle Inkrementellen Daten löschen die älter als 12 Wochen sind.

Links

Hoffe ihr habt so viel Freude mit diesem Backupsystem wie ich es habe

peace
LEWIS

Flattr this!