Konvertierung des alten ext4 Dateisystems zum btrfs Dateisystem

Da das Datei-System Btrfs schon einige Zeit als “stable” (stabil) angesehen wird, möchte ich hier kurz beschreiben, wie man sein bestehendes ext4 Dateisystem zum btrfs Dateisystem konvertieren kann.

Bevor man mit der ganzen Prozedur anfängt, sollte man sein ext4 Dateisystem einem Filesystem-Check unterziehen um eventuelle Fehler auszumachen.
Ich boote dazu mein System mit einem Live-CD USB-Stick von einer beliebigen Linux Distribution, damit alle Partitionen nicht eingehängt (mounted) sind
So lassen sich alle Filesystem-Checks gut durchführen.
# fsck.ext4 -f /dev/sdX

Gehen wir jetzt mal von einem intakten ext4 Dateisystem aus, kann man jetzt (voraus man hat auch ein Backup erstellt) mit der Konvertierung zum neuen btrfs Dateisystem beginnen.

Wer so eine Konvertierung zum ersten Mal macht, sollte eine andere Partition als der root-Partition wählen, da bei dieser noch weitere Nacharbeiten zu erledigen sind.

Prüfen, ob die btrfs-tools installiert sind:
# # rpm -qa | grep btrfs --> rpm-based Linux Distros
btrfsprogs-4.5.3-6.3.x86_64

# dpkg -l | grep btrfs --> deb-based Linux Distros
ii btrfs-tools 3.12-1ubuntu0.1

Mit folgendem Befehl startet man die Konvertierung:
ca. 20% freier Speicherplatz sollte für die Konvertierung vorhanden sein.
# btrfs-convert /dev/sdX
Es wird automatisch ein btrfs subvolume erstellt das sich ext4_saved nennt erstellt, das eine spätere Rückkonvertierung zum alten ext4 Dateisystem ermöglicht.

Nach erfolgreicher Konvertierung muss man diese Partition einhängen und noch den mountpoint Typ im der Datei ‘/etc/fstab’ abändern:
mount /dev/sdX /mnt
# vim /mnt/etc/fstab
z.B
UUID=e52d7524-230c-413e-9c26-8c94b94c34b2 /home btrfs defaults 0 0

Man ändert hier von ext4 auf btrfs und speichert die Datei wieder ab. Anschließend erfolgt eine Neustart des Systems
um abschließend die Funktion zu testen.

Mit folgendem Befehl wird die Rückkonvertierung zu ext4 ermöglicht:
# btrfs-convert -r /dev/sdX

So nun kann man das neue Datei-System auf Herz und Nieren testen, für mich hat es den Langzeittest schon bestanden, da ich es fast überall seit langem auf meinen Systemen einsetze, z.B RAID5 beim Server oder auch als home-Partition, die automatische Snapshot-funktion mit Snapper finde ich besonders gelungen. Bei SUSE Enterprise Server oder openSUSE-Leap/Tumbleweed ist es Standard als root-Filesystem.

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer.

In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren

Icinga Web 2 Modul fileshipper imports im Director

Es werden viele Importe im Icinga Web 2 Modul Director via Ldap / SQL-Ressource getätigt, aber viele übesehen eine einfache Möglichkeit bestehende Dateien mittels Icinga 2 Modul “fileshipper” in den Icinga Web 2 Director zu importieren. Wie man dieses umsetzt werde ich an einem einfachen Beispiel, einer CSV-Datei hier beschreiben.

Zuerst muss man sich das Fileshipper-Modul von Github per “git clone” oder .zip-Datei herunterladen und in dem Verzeichnis '/usr/share/icingaweb2/modules/' ablegen und anschießend das Verzeichnis in “fileshipper” umbennen, denn sonst erkennt es Icinga Web 2 als Modul nicht an.
# cd /usr/share/icingaweb2/modules/ && git clone https://github.com/Icinga/icingaweb2-module-fileshipper.git
oder
# cd /usr/share/icingaweb2/modules/ && unzip master.zip

Anschließend muss das neu installierte Modul noch aktiviert werden,  mit dem icingacli Kommando:
# icingacli module enable fileshipper
icingacli module list
MODULE VERSION STATE DESCRIPTION
director 1.3.1 enabled Director - Config tool for Icinga 2
doc 2.4.1 enabled Documentation module
fileshipper 1.0.0 enabled Fileshipper for Icinga Director
monitoring 2.4.1 enabled Icinga monitoring module

Es geht aber aber auch über die Icinga Web 2 –  Oberfläche siehe Screenshot:

Nachdem das Modul installiert und aktiviert ist kann es losgehen. Zuerst erstellt man das Verzeichnis “fileshipper” unter # mkdir /etc/icingaweb2/modules/fileshipper und erstellt eine import.ini Datei in der das Verzeichnis angeben wird, wo sich die zu importierenden Dateien (.csv) liegen.
[fileshipper files]
basedir = "/usr/local/share/"

Dann wird im Icinga Web 2 => Director => Automation => Add Import Source

ein Name des zukünftigen Imports z.B fileshipper-import-hosts vergeben und bei Source “Import from files (fileshipper) ausgewählt.

Jetzt muss die neue Import-Quelle noch modifiziert werden z.B. so:

Ich denke das Bild ist selbsterklärend und Bedarf keiner weiteren Erklärung.

Jetzt kann man einen Import run starten in dem man auf die Import-Source fileshipper-import-hosts und Trigger Import Run auswählt.

Nun sollte in der Voransicht (Preview) die importierten Hosts sichtbar werden.

Um jetzt aus diesen RAW-Daten Icinga 2 konforme Objekte werden zu lassen brauchen wir eine Sync-Rule die man z.B.so anlegt:


Hier wird in der Maske angeben, welcher Typ (Host-Objekt) daraus werden soll und ob bereits existierende Daten ersetzt (replace) oder zusammengeführt (merge) werden sollen.
Mit Purge können bereits existierende Daten gelöscht werde, JA oder NEIN.

Im Kartei-Reiter “Properties/Eigenschaften” werden die Felder vom Import (Source/Quelle) den Icinga 2 konformen Zielen (Destination) zugeordnet:

Danach kann der Sync-Run der erstellten Sync-Rule gestartet werden und bei erfolgreichen Lauf, werden Konfigurations-Dateien erstellt und sind bereit für den Director zu deployen.

Im Activity-Log kann der Vorgang nochmals überprüft werden, bevor man die Konfiguration per Director deploy übernehmen kann.

So jetzt sollten nach erfolgreichem Deployment die Hosts im Icinga Web 2 unter Hosts sichtbar sein.

 

Im Rahmen einer Icinga 2 Fundamentals Schulung, die wir anbieten, werden auch noch weitere Import-Quellen besprochen und praktisch vollzogen.

Unter anderem haben wir noch weitere Schulungen zu Open Source Themen im Portofolio, einen Überblick bekommen Sie hier bei NETWAYS-Schulungen.

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer.

In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren

PNP4Nagios RRD Single/Multiple Storage

pnp4nagiosFür alle die das Nagios Plugin PNP4Nagios mit Icinga2 einsetzen, werden eventuell schon über folgende Fehlermeldung gestolpert sein,
oder noch stolpern:

/var/log/messages:
NPCD[65119]: ERROR: Executed command exits with return code '7'

/var/log/pnp4nagios/perfdata.log:
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Timeout after 15 secs. ***
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Deleting current file to avoid NPCD loops
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Please check your process_perfdata.cfg
Einstellung:
'/etc/pnp4nagios/process_perfdata.cfg'
Option
RRD_STORAGE_TYPE = SINGLE

Ab der PNP-Version 0.6 ist es möglich, die Performance-Daten nicht in einer einzelnen RRD-Datenbank (SINGLE), sondern in mehreren RRD Datenbanken (MULTIPLE) zu speichern.
Diese Einstellung in der Konfigurations-Datei sollte NICHT global verändert werden, da PNP4Nagios nach dieser Umstellung auf MULTIPLE sofort beginnt, neue RRD-Files anzulegen. Alte Daten gehen damit sofort verloren!

Auf Grund der Performance ist es nicht sinnvoll, global mit RRD_STORAGE_TYPE = MULTIPLE zu arbeiten, da die Anzahl der RRD-Datenbanken und somit auch der Disk-I/O während der Updates sich vervielfachen würde. Deshalb sollte man überlegen, welche Nagios Checks mit dieser Einstellung gefahren werden.
Bestehende RRD-Datenbanken können über einen Konverter (Perl-Skript) '/usr/libexec/pnp4nagios/rrd_convert.pl' konvertiert werden.

Folgende Ausgabe bekommt man bei Ausführung des Perl-Skriptes:

Usage: /usr/libexec/pnp4nagios/rrd_convert.pl --check_command=
--cfg_dir= [ --list_commands ]
[ --dry-run ]
[ --tmp_dir= ]
[ --no_structure_check ]

Schaut dann so in etwa aus:

rrd-convert

# sudo -su icinga /usr/libexec/pnp4nagios/rrd_convert.pl --cfg_dir=/etc/pnp4nagios/ --check_command=disk --dry-run

Search pattern disk
XML Files analyzed 129
XML Files found 7
XML Files without RRD 0
Old XML Files ignored 0
Number of unique check_commands 15
Dry run? [YES]
Temp Directory /tmp/rrd_convert

This is only a 'dry run'. The new RRD Files are stored in '/tmp/rrd_convert'

Start Converter [n|y]?:y
File 1/7
RRDtool dump to /tmp/rrd_convert/icinga2-disk__.dump
Manipulating /tmp/rrd_convert/icinga2-disk__.dump
............ done 47999 lines
Restoring File
/tmp/rrd_convert/icinga2/disk____.rrd
... done
File 2/7
RRDtool dump to /tmp/rrd_convert/icinga2-disk.dump
Manipulating /tmp/rrd_convert/icinga2-disk.dump
............ done 48424 lines
Restoring File
/tmp/rrd_convert/icinga2/disk__tmp_vagrant-puppet_manifests-a11d1078b1b1f2e3bdea27312f6ba513.rrd
/tmp/rrd_convert/icinga2/disk__vagrant.rrd
/tmp/rrd_convert/icinga2/disk__.rrd
/tmp/rrd_convert/icinga2/disk__boot.rrd
/tmp/rrd_convert/icinga2/disk__home.rrd
/tmp/rrd_convert/icinga2/disk__tmp_vagrant-puppet_modules-41d422e93c9413f221fcbaa64a7964b7.rrd
... done
DONE

Schauen Sie doch einfach mal auf unserer Webseite vorbei, wir biete Schulungen zu vielen interessanten OpenSource-Themen an.

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer.

In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren

Vagrant-Box mit Icinga2 mit Icingaweb2 aufsetzen

Vagrant-Box mit Icinga2 mit Icingaweb2 aufsetzen

virtualboxAls Entwickler und Systemadministrator kommt man öfters nicht um eine Testmöglichkeit herum.
Eine VM mit einem Hypervisor seiner Wahl aufzusetzen ist meistens sehr zeitaufwendig um kleinere Tests nachzustellen.
Eine einfache und schnelle Möglichkeit bietet hier sich eine Vagrant-Box vom Internet herunter zu laden oder sich ein Git-Repositoriy mit einem vorgefertigten Image zu clonen.
Wie man sich so eine Vagrant-Box per Git cloned werde ich hier beschreiben.

 

Vorraussetzung: Virtualbox-Pakete + GIT sollten installiert sein (Virtualbox wird hier als Provider benutzt):

~ # rpm -qa | grep virtualbox
virtualbox-5.0.18-216.2.x86_64
virtualbox-guest-tools-5.0.18-216.2.x86_64
virtualbox-host-kmp-default-5.0.18_k4.1.12_1-216.2.x86_64
virtualbox-qt-5.0.18-216.2.x86_64
virtualbox-guest-kmp-default-5.0.18_k4.1.12_1-216.2.x86_64
git-2.6.6-7.1.x86_64

Info: Die Version kann von den verschiedenen Distributionen variieren.

Als nächsten müssen wir das Git-Repository lokal clonen
Dazu ins home – Verzeichnis in der Shell seiner Wahl wechseln
Ein Verzeichnis seiner Wahl anlegen:
mkdir git z.B

und in diesem Verzeichnis folgendes Kommando ausführen als user versteht sich:

~ # git clone https://github.com/Icinga/icinga-vagrant
Klone nach 'icinga-vagrant' ...
remote: Counting objects: 5172, done.
remote: Total 5172 (delta 0), reused 0 (delta 0), pack-reused 5172
Empfange Objekte: 100% (5172/5172), 1.53 MiB | 569.00 KiB/s, Fertig.
Löse Unterschiede auf: 100% (1929/1929), Fertig.
Prüfe Konnektivität ... Fertig.

So das wars auch fast schon 🙂

Jetzt z.B in das Verzeichnis Icinga2x-cluster wechseln
~ # cd icinga-vagrant/icinga2x-cluster/

Anschließend nur noch die Vagrant-Box starten:
~ # vagrant up

Nun kann es eine Weile dauernd bis die Box gebaut wird, wenn keine Fehler aufgetreten sind kann man sich per ssh connecten.
~ # vagrant ssh
[vagrant@icinga2 ~]$

Weitere vagrant Kommandos:

vagrant help    -> Listet weitere Kommandos von vagrant auf
vagrant halt  -> fährt  die Vagrant-Box herunter  (shutdown)
vagrant reload -> starten die Vagrant-Box neu (reboot)

Login-Information bekommt man direkt auf:
https://github.com/Icinga/icinga-vagrant/

Icingaweb2 nach erfolgreichen Login:

Screenshot_20160603_105621

Viel Spaß beim testen, basteln und herumspielen 🙂

Es lohnt sich auch immer mal unser Schulungsangebot sich anzuschauen.

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer.

In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren

Btrfs / snapper und Tools

Über dieses Datei-System und seine Tools wird ja viel geredet und spekuliert, ich möchte heute ein bißchen Praktisches und Kommandos zeigen und was man im Alltag gut brauchen kann.

Vorraussetzung ist das das Paket btrfs-procs und Abhängigkeiten installiert sind, das ist auch schon alles.

man btrfs zeigt die Möglichkeiten von btrfs und die Optionen/Schalter die es gibt.

Partitionen und UUID’s kann man so anschauen:
root:~ # btrfs filesystem show /      -> oder  abgekürzt btrfs fi sh /
Label: none uuid: 957ad303-786f-4456-95b6-1942e5d1943d
Total devices 1 FS bytes used 23.90GiB
devid 1 size 40.00GiB used 26.63GiB path /dev/sda2

————————

Speicherplatz-Belegung:
root ~ # btrfs fi df /
Data, single: total=23.01GiB, used=22.75GiB
System, DUP: total=64.00MiB, used=16.00KiB
Metadata, DUP: total=1.75GiB, used=1.14GiB
GlobalReserve, single: total=400.00MiB, used=0.00B

————————

btrfs scrub start /
liest alle Daten vom Root Filesystem und verifiziert / prüft die Checksum der Dateien im Filesystem

btrfs scrub status /
gibt den derzeitigen Status von scrub ob es Fehler in den Checksums gibt z.B.
scrub status for 957ad303-786f-4456-95b6-1942e5d1943d
scrub started at Tue Apr 5 13:35:17 2016 and finished after 00:04:16<
total bytes scrubbed: 25.03GiB with 0 errors

————————

Es gibt noch mehr Schalter z.B subvolume mit dem Subvolumes aufgelistet erzeugt werden können.
root:~ # btrfs subvolume list /
ID 257 gen 115 top level 5 path @
ID 258 gen 13814 top level 257 path @/.snapshots
ID 259 gen 13839 top level 258 path @/.snapshots/1/snapshot
ID 260 gen 4138 top level 257 path @/boot/grub2/i386-pc

————————

So kommen wir jetzt mal zu Snapper (Snapshot-Tool)

http://snapper.io/

Snapper wird bei SLES (SUSE) oder openSUSE automatisch mit installiert fürs Root-Dateisystem aktiviert, so das sofortige Änderungen am System als neuer Snapshot gespeichert werden. Diese werden normalerweise unter „/.snapshots/0 angelegt.

Für andere Linux-Distributionen wie Debian und Fedora muss wahrscheinilich installiert werden.

root:~ # snapper list
Type | # | Pre # | Date | User | Cleanup | Description | Userdata
-------+-----+-------+--------------------------+------+---------+-----------------------+--------------
single | 0 | | | root | | current |
single | 1 | | Fri Mar 4 13:01:15 2016 | root | | first root filesystem |
single | 2 | | Fri Mar 4 13:14:12 2016 | root | number | after installation | important=yes
pre | 3 | | Fri Mar 4 13:25:06 2016 | root | number | zypp(zypper) | important=yes
post | 4 | 3 | Fri Mar 4 14:00:49 2016 | root | number | | important=yes

————————

Konfig anschauen:
root:~ # snapper get-config
Key | Value
-----------------------+------
ALLOW_GROUPS |
ALLOW_USERS |
BACKGROUND_COMPARISON | yes
EMPTY_PRE_POST_CLEANUP | yes
EMPTY_PRE_POST_MIN_AGE | 1800
FSTYPE | btrfs
NUMBER_CLEANUP | yes
NUMBER_LIMIT | 10
NUMBER_LIMIT_IMPORTANT | 10
NUMBER_MIN_AGE | 1800
SUBVOLUME | /
SYNC_ACL | no
TIMELINE_CLEANUP | yes
TIMELINE_CREATE | no
TIMELINE_LIMIT_DAILY | 10
TIMELINE_LIMIT_HOURLY | 10
TIMELINE_LIMIT_MONTHLY | 10
TIMELINE_LIMIT_WEEKLY | 0
TIMELINE_LIMIT_YEARLY | 10
TIMELINE_MIN_AGE | 1800

Eine tolle ausführliche Beschreibung zu weiteren Funktionen gibt’s auf:

https://en.opensuse.org/openSUSE:Snapper_Tutorial

————————

Schönste Funktion: ROLLBACK

mit snapper rollback snapshotnumber kann man das System auf einen älteren Stand zurücksetzen..

Falls ein Update oder andere System-Probleme z.b nach einer Paket-Installation  (Kernel) fehlschlägt oder das System nicht mehr  funktionstüchig ist, kann man auf den letzten Snapshot, das System wieder auf den Stand vor dem Fehler  zurückdrehen.

Es wird vor dem Rollback noch ein Snapshot von dem „aktuellen Stand”(defeketen) gemacht und dann auf dem gewünschten Snapshot zurückgerollt.

Diese Rollback-Funktion geht nur mit dem BTRFS Datei-System und nur beim Root-Filesystem.

Es ist auch möglich von einer anderen Partition z.B. /home einen Snapper -Config zu erstellen um so automatische Snappschüsse von Home-Verzeichnis zu erhalten.

snapper -c home create-config /home
Um Dateien von einem älteren Snapshot vom /home/.snapshots/1/.. zu bekommen, muss man sich den Snapshot mounten:

mount -o subvolid=XY /dev/sdXY /mnt/

Die subvolid bekommt man durch:

root:~ # btrfs subvolume list /
ID 257 gen 115 top level 5 path @

————————

Unterschiede von zwei Snapshots:
root:~ # snapper diff 3..4 | head
Binary files /.snapshots/3/snapshot/bin/tar and /.snapshots/4/snapshot/bin/tar differ
--- /.snapshots/3/snapshot/boot/.vmlinuz-4.1.15-8-default.hmac 1970-01-01 01:00:00.000000000 +0100
+++ /.snapshots/4/snapshot/boot/.vmlinuz-4.1.15-8-default.hmac 2016-01-21 10:52:47.000000000 +0100
@@ -0,0 +1 @@
+e8eaf8b2f82bb5549f9be63183feeb09ae6e5f87d737c56ee7d00d38cfa882d6
--- /.snapshots/3/snapshot/boot/System.map-4.1.15-8-default 1970-01-01 01:00:00.000000000 +0100
+++ /.snapshots/4/snapshot/boot/System.map-4.1.15-8-default 2016-01-21 10:03:17.000000000 +0100
@@ -0,0 +1,74925 @@
+0000000000000000 D __per_cpu_start
+0000000000000000 V irq_stack_union

Welche Dateien zwischen Snapshots hinzugekommen sind:

root:~ # snapper status 3..4 | head
c..... /bin/tar
+..... /boot/.vmlinuz-4.1.15-8-default.hmac
+..... /boot/System.map-4.1.15-8-default
+..... /boot/config-4.1.15-8-default
+..... /boot/do_purge_kernels
c..... /boot/grub2/grub.cfg
c..... /boot/initrd
c..... /boot/initrd-4.1.12-1-default
+..... /boot/initrd-4.1.15-8-default
+..... /boot/symvers-4.1.15-8-default.gz

————————

Löschen von Snapshots:
snapper delete 25

snapper delete  25-30  -> löscht snapshots 25 bis 30

Ich persönlich finde das Tool Klasse, es hat mir schon mal sehr wichtige Daten gerettet.

Giv’ em a try!!

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer.

In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren