Lokale Time Machine Snapshots blockieren Speicherplatz

Kürzlich hatte ich den Plan, ein ca. 100GB iPhone Backup zwischenzeitlich auf dem Mac anzufertigen. Meinem Plan stand nach einem kurzen Blick auf den freien Diskspace des Finders eigentlich nichts im Wege, denn dieser zeigte noch 120 GB freien Speicherplatz an. Nachdem sich das Backup aber mit einem bisher unbekannten Fehler verabschiedete, machte ich mich einmal auf die Suche, was mein Mac denn so eigentlich macht.

Ein Kurzer Blick im Terminal bestätigte mir allerdings viel weniger freien Platz auf der Platte, als der Finder es tat. So waren hier nur noch 55 GB frei. Wie kann das sein?

Zunächst einmal öffnet ihr euer Terminal im Mac und gebt folgendes Kommando ein

df -h

Der Mac zeigt nun in aller Regel in der ersten Zeile die Informationen der Mac-Festplatte (Gegenkontrolle Anhand der Size-Spalte) an. In der Spalte Available steht der noch zur Verfügung stehende Speicherplatz. Sollten sich diese Werte im Finder und im Terminal erheblich unterscheiden, macht es Sinn, die Snapshots unter die Lupe zu nehmen.

Warum Snapshots?

Sollte das Time Machine Backup Volume (z. B. wenn man im Urlaub ist) nicht verfügbar sein, fertigt der Mac lokale Snapshots an. Ein solcher Snapshot schützt zwar nicht vor Datenverlust bei einem Hardwareschaden, wohl aber bei unbeabsichtigten Löschen – also die haben schon Ihre Daseinsberechtigung und fertigen zuverlässig auch ohne Backupvolume im Hintergrund eine Art Sicherung an. Normaler Weise gibt der Mac nach und nach die Snapshots frei, wenn er merkt, dass der Platz benötigt wird. Das ist wahrscheinlich auch der Grund, warum der Finder die Snapshots von der Kalkulation des freien Speicherplatzes excludiert.

Habe ich auch Snapshots?

Sofern ein Time Machine Backup läuft, wird diese Funktion aktiviert. Allerdings tritt sie nur in Kraft, wenn das Backup-Volume nicht verfügbar ist. Am besten prüft man das kurz über das Mac-Terminal mittels Eingabe des folgenden Kommandos. Es listet alle vorhandenen Snapshots der Primärplatte auf.

tmutil listlocalsnapshots /

Möchte man nun einmal solche Snapshots entsorgen, so lässt sich das mit folgendem Kommando erledigen

sudo tmutil thinLocalSnapshots / 10000000000 4

Kurze Erklärung hierzu: / Bezieht sich wieder auf das soeben ermittelte Volume (also die primäre Festplatte, das braucht man in aller Regel nicht ändern), 10000000000 bezieht sich auf den “purgeamount” also die Menge, in diesem Beispiel sind das 10 GB. Um mehr freizugeben, Zahl auf beliebigen Wert in Byte erhöhen, oder Kommando mehrfach ausführen. Die 4 steht für die “urgency”, also die Dringlichkeit. 1 ist hier die höchste, aber 4 reicht eigentlich auch zum Löschen.

Nachhaltig verhindern, lassen sich lokale Snapshots auf den Apple-Geräten mit folgendem Kommando:

sudo tmutil disablelocal

Alternativ Time Machine nicht mehr nutzen, oder dafür sorgen, dass die Backupvolumes immer verfügbar sind.

Georg Mimietz

Autor: Georg Mimietz

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

SNMP Netzwerk Monitoring

Huhu!

Heute möchte ich euch ein wenig in die Welt von SNMP Monitoring mit Icinga 2 entführen. Da man leider nicht immer einen Switch mit SNMP zur Hand hat, verwende ich eine GNS3 Netzwerk Umgebung sowie eine CentOS 7 Maschine für Icinga 2.

Doch was ist den dieses SNMP überhaupt, was kann das? Zunächst SNMP steht für Simple Network Message Protocol (RFC 1157) und wurde mit dem Gedanken entwickelt Netzwerkgeräte wie Drucker, Router, Switche und vermutlich irgendwann auch Toaster per IoT von einem Zentralen Punkt im Netzwerk aus überwachen bzw. steuern zu können. SNMP an sich besitzt nicht wirklich viel Magie es beschreibt im Endeffekt wie Datenpakete aussehen können. Damit Icinga 2 (Managmentstation) den Switch (Agent) fragen kann, wie es ihm den heute so geht. Die eigentliche Magie ist die sogenannten Managment Information Base, umgangssprachlich auch MIB genannt.

Die MIB kann man sich wie einen großen Baum vorstellen, dessen Äste und Blätter mit Hilfe von eindeutigen OIDs gebildet werden. Die Blätter die an unseren Ästen hängen sind Objekte wie ein Lüfter, oder eine Festplatte und können als als OID so aussehen: 1.3.6.1.4.1.1.4.

Nach viel Techbabbel kommt nun wenig Kaboom (Practical Examples). An Hand des Beispiel möchte ich euch ein Grundgerüst an die Hand geben, wie man bequem und ohne Geräte spezifisches Plugin ein SNMP Monitoring unter Icinga 2 einfach realisieren kann.

Im ersten Schritt holen wir uns alle OIDs samt Beschreibung vom Gerät, in meinem Fall von einem VyOS Router:

snmpwalk -Os -v 1 -c public 192.168.174.131 >> /tmp/snmpwalk_desc
snmpwalk -v 1 -c public 192.168.174.131 >> /tmp/snmpwalk_oid

Für das Beispiel wähle ich drei OIDs aus:

.1.3.6.1.2.1.2.2.1.2.1
.1.3.6.1.2.1.2.2.1.2.2
.1.3.6.1.2.1.2.2.1.2.3

Mit dem Director hab ich ein Template und Service angelegt, welches auf das Check_Plugin/Kommando check_snmp zurückgreift. Die ausgewälten OIDs werden Kommasepariert per Costume Attribut “snmp_oid” mitgegeben:

template Service "snmp" {
    check_command = "snmp"
    max_check_attempts = "3"
    check_interval = 1m
    retry_interval = 20s
}
object Service "Interfaces" {
    host_name = "vyos"
    import "snmp"
    vars.snmp_label = "Interfaces"
    vars.snmp_oid = ".1.3.6.1.2.1.2.2.1.2.1,.1.3.6.1.2.1.2.2.1.2.2,.1.3.6.1.2.1.2.2.1.2.3"
}

Nach dem ausbringen der Konfiguration sollte das ganze folgendermaßen aussehen:

 

Tipp am Rande:
Falls euer Gerät nicht auf Öffentlichen MIBs aufbauen sollte, wie hier im Beispiel, bekommt ihr die im Regelfall vom Hersteller bereitgestellt. Die MIB wird einfach zu den bereits existierenden hinzugefügt und dann ist alles wie gehabt! 🙂

Damit verabschiede ich mich und wünsche wie immer viel Spass beim Implementieren!

Max Deparade

Autor: Max Deparade

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn er nicht gerade fieberhaft auf sein neues Macbook wartet.

MySQL-Datenbanken verwalten mit Sequel Pro

MySQL-Datenbanken verwalten mit Sequel Pro

Eines meiner meist genutzten Apps am Mac ist Sequel Pro. Das kann man kennen, muss man aber nicht. Daher liest man – wenn man möchte – in den folgenden Zeilen eine kurze Vorstellung.

(more…)

Florian Strohmaier

Autor: Florian Strohmaier

Mit seinen Spezialgebieten UI-Konzeption, Prototyping und Frontendentwicklung unterstützt Florian das Dev-Team bei NETWAYS. Trotz seines Design-Backgrounds fühlt er sich auch in der Technik zuhause. Gerade die Kombination aus beidem hat für ihn einen besonderen Reiz.

Fresh from the shelf

Hi !

This week I will take a little look into three command line tools which I find very nice for daily use on a server where we have almost no interface except the command line.

The first tool I would like to bring to your attention is a file explorer for the command line.

Ranger

Ranger is a finder/explorer/nemo/nautilus replacement for the command line with a simple but straight forward file management approach. It uses the almost everywhere liked miller columns and i personally like it more than the midnight commander but that is a personal preference.
I also like the extensibility as an example you can extend ranger with poppler for pdf support or mutool whatever is available for your distro.

It can be easily installed and can be just started from it’s own directory so no big installation fuzz. Simply unpack and start ranger.
(more…)

David Okon

Autor: David Okon

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

For a Handful of (Vagrant) Boxes

Servus alle miteinand,

Wer kennt das folgende Szenario nicht? Mit viel neuer Software, welche gerade (manuell) getestet werden muss, dachte ich mir, ich baue mal schnell eine Vagrant Box auf Basis von Debian 9, um Tests unter einem Stretch durchzuführen.

Falsch gedacht !!

Anstelle eines libvirt install auf der Kommandozeile und eines tar-Befehls zum Packen des eigentlichen Box-Images,
musste ich mit einer kleinen Widrigkeiten im Bereich der Netzwerkkonfiguration kämpfen.

Aber eins nach dem anderen.
Fangen wir mit dem Image für die libvirt Maschine an:

virt-install --name=linuxconfig-vm \
--vcpus=1 \
--memory=1024 \
--cdrom=/tmp/debian-9.4.0-amd64-netinst.iso \
--disk size=10 \
--os-variant=debian9

Dies war noch der unproblematische Teil der Installation.
Danach erfolgt in der VM das nachziehen von Berechtigungen für den Vagrant User.

sudo visudo -f /etc/sudoers.d/vagrant
vagrant ALL=(ALL) NOPASSWD:ALL

Hinzufügen des Vagrant public Keys:

mkdir -p /home/vagrant/.ssh
chmod 0700 /home/vagrant/.ssh
wget --no-check-certificate \
https://raw.github.com/mitchellh/vagrant/master\/keys/vagrant.pub \
-O /home/vagrant/.ssh/authorized_keys
chmod 0600 /home/vagrant/.ssh/authorized_keys
chown -R vagrant /home/vagrant/.ssh

Wenn man nicht so Wach war, um rechtzeitig im Installationsmenü schon SSH mitzuinstallieren, muss es per Hand nachgeholt werden:

sudo apt-getinstall -y openssh-server
sudo nano /etc/ssh/sshd_config
AuthorizedKeysFile %h/.ssh/authorized_keys

Danach kann das System so präpariert werden, wie man es benötigt.

Das Image der VM noch verkleinern und in box.img umbenennen:

qemu-img convert -c -O qcow2 debian9.qcow2 small.qcow2
mv small.qcow2 box.img

Alles handlich verpacken und dem Vagrant Box Store hinzufügen:

tar czvf debian9.box ./metadata.json ./Vagrantfile ./box.img
vagrant box add --name debian9 debian9.box

Hier allerdings fingen meine Probleme an.
Nach dem Packen der Box, dem Hinzufügen zum Boxstore und einem Erwartungsvollen “vagrant up” erhielt ich “==> default: Waiting for domain to get an IP address…”, was zu keinem Erfolg führte und ich wahrscheinlich jetzt immer noch warten würde.

Nach einem erneuten Hochfahren der VM mit dem virt-manager und nachschauen, ob das network device fehl konfiguriert ist, konnte ich keinen Fehler feststellen.

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

Gefühlte Jahrtausende von Recherche später, wurde mir folgendes klar:

Debian hat in neuen Versionen eine Änderung der Device-Namen vorgenommen.
Vagrant wartet vergeblich auf “eth0”, weil ein network device Namens “ens21” existiert, wenn ich die VM mit “vagrant up” starte.

Also zurück in die VM und das folgende Kommandos abgesetzt:

sudo nano /etc/default/grub

Im Editor dann folgende Anpassungen vornehmen:

GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

Damit das auch greift, muss abschließend die Konfiguration für den Grub-Bootmanager neu erstellt werden:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Reboot. “vagrant up” und Tada … Spannung Trommelwirbel => Tusch ! Die VM erhält eine IP und startet wie man es schon von Anfang an erwartete.

Ich hoffe ich konnte damit den ein oder anderen vor dem Verlust von allzuviel Lebenszeit bewahren.

Ein sonniges WE wünscht

David Okon

Autor: David Okon

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

Konfiguration mit Lsyncd synchronisieren

Hallo!

Heute möchte ich euch ein Tool vorstellen mit dem man relativ einfach, sicher und in nahezu realzeit Konfiguration auf andere Systeme und umgekehrt synchronisieren kann. Das Tool hoert auf den Namen Live Syncing (Mirror) Daemon, oder kurz gefasst Lsyncd.

Als erstes möchte ich etwas auf die Magie von Lsyncd eingehen, damit man einen Eindruck bekommt wie das Tool arbeitet und was für Möglichkeiten sich ergeben. Lsyncd verwendet unter Linux inotify und unter MacOS FSEvents um Änderungen am Verzeichnissbaum zu beobachten. Anhand dieses “Monitorings” kann Lsyncd feststellen, ob Änderungen im zur synchronisation bestimmten Verzeichnis passiert sind. Ist dies der Fall, startet Lsyncd die synchronisation mit den zuvor entsprechend gesetzten Parametern. Die Parameter sind z.B. welches Verzeichniss von soll wohin repliziert werden und welches Protokoll soll dafür genutzt werden z.B. rsync.

Kommen wir zum interessanteren Teil die Installation und Konfiguration von Lsyncd. In den meisten Distributionen ist Lsyncd bereits als fertiges Paket vorzufinden. Für die demonstration verwende ich eine CentOS 7.x Maschine in VirtualBox auf einem Laptop.

Vorbereitung/Installation (CentOS 7.x)

Zunächst installieren wir das lsyncd Paket mittels YUM und generieren bzw. verteilen anschließend unseren SSH-Key den wir später für Lsyncd nutzen.

[root@lsyncdemo ~]# yum install lsyncd
[root@lsyncdemo ~]# ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/root/.ssh/id_ed25519): /root/.ssh/id_lsync
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_lsyync.
Your public key has been saved in /root/.ssh/id_lsyync.pub.
The key fingerprint is:
SHA256:ntsHfyqPkwffQ3IPMUkZ6kIOMdSBqVhREwgag7V1TgI root@lsyncdemo
The key's randomart image is:
+--[ED25519 256]--+
| oE.+.+=B=.. .o |
|. * =o o+. .o |
| o o... . .. . |
| . . + . + |
| S o . o |
| . .o.. + |
| o * = o |
| o+.= + .|
| . o*oo . |
+----[SHA256]-----+
[root@lsyncdemo ~]# ssh-copy-id -i /root/.ssh/id_lsync i2node01

Konfiguration

Nun kommen wir zur Konfiguration unseres Lsyncd, hierfür existiert genau eine Konfigurationsdatei unter /etc/ (equivalenter pfad osx) mit dem Namen lsyncd.conf. Für unser Beispiel synchronisiere ich Verzeichnis mit Konfiguration auf meinen Icinga2 Master (i2node01).

[root@lsyncdemo ~]# vi /etc/lsyncd.conf
<...
- sync{default.rsyncssh, source="/var/www/html", host="localhost", targetdir="/tmp/htmlcopy/"} //Beispiel Konfiguration entfernen

+ sync{ //Icinga Configuration
+  default.rsync, //Wir nutzen rsync zum Synchronisieren
+  source="/home/mdeparade/icinga2/scripts", //Das Quellverzeichnis
+  target="i2node01:/etc/icinga2/scripts", //Das Zielverzeichnis
+  rsync={rsh ="/usr/bin/ssh -l root -i /root/.ssh/id_lsync", owner = true, perms = true,}
+ }
...>

Kurze Erläuterung: Die letzte Zeile unserer Konfiguration gibt rsync noch ein paar Informationen mit: Wir bauen einen SSH-Tunnel als Benutzer root auf, mit dem SSH-Key “id_lsync”, anschließend sagen wir noch das alle Berechtigungen der Dateien/Verzeichnisse erhalten bleiben sollen.

Abschluss

Nachdem wir Lsyncd mit Konfiguration versorgt haben, können wir diesen direkt starten und Überprüfen ob unser Synchronisation auch ordnungsgemaess funktioniert:

[root@lsyncdemo ~]# cat /etc/lsyncd.conf
----
-- User configuration file for lsyncd.
--
-- Simple example for default rsync, but executing moves through on the target.
--
-- For more examples, see /usr/share/doc/lsyncd*/examples/
--
sync{
default.rsync,
source="/home/mdeparade/icinga2/scripts",
target="i2node01:/etc/icinga2/scripts",
rsync={rsh ="/usr/bin/ssh -l root -i /root/.ssh/id_lsync", owner = true, perms = true,} 
}
[root@lsyncdemo ~]# systemctl enable lsyncd --now
[root@lsyncdemo ~]# systemctl status lsyncd
● lsyncd.service - Live Syncing (Mirror) Daemon
 Loaded: loaded (/usr/lib/systemd/system/lsyncd.service; enabled; vendor preset: disabled)
 Active: active (running) since Fri 2018-04-09 10:49:36 BST; 1s ago
 Main PID: 1477 (lsyncd)
 CGroup: /system.slice/lsyncd.service
 └─1477 /usr/bin/lsyncd -nodaemon /etc/lsyncd.conf

Apr 09 10:49:36 lsyncdemo systemd[1]: Started Live Syncing (Mirror) Daemon.
Apr 09 10:49:36 lsyncdemo systemd[1]: Starting Live Syncing (Mirror) Daemon...
[root@lsyncdemo ~]# ll /home/mdeparade/icinga2/scripts
total 4
-rw-r--r--. 1 root root 5 Apr 09 10:52 test.conf
[root@lsyncdemo ~]# ssh -i /root/.ssh/id_lsync -l root 192.168.56.11 ls /etc/icinga2/scripts
test.conf
[root@lsyncdemo ~]# exit
logout
Connection to blog.netways.de closed.

Eindrücke aus Bayern: Die Alpen

Max Deparade

Autor: Max Deparade

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn er nicht gerade fieberhaft auf sein neues Macbook wartet.