Author Archives: erdo

Proxmox/LXC Mount lokale Ordner in Unprivileged Container

Es gibt mehrere Gründe, warum man lokale Ordner in einen LXC Container mounten muss. Zb:

  • Im Backup ausschließen
  • zwischen LXC teilen

Ich habe keine offizielle oder inoffizielle Dokumentation gefunden welche meinen Vorgehensweise dokumentiert (Stand: 09/2019), daher unter Vorbehalt behandeln!

Umsetzung

Proxmox # pct stop 100

Proxmox # mkdir /opt/mountdir
Proxmox # pct set 100 -mp0 /opt/lxc/100/mountdir,mp=/opt/mountdir
Proxmox # pct start 100

LXC # ls -la /opt/mountdir
      drwxr-xr-x  9 nobody nogroup  4096 Sep 20 20:01 /opt/mountdir

Proxmox # chown -R 100000:100000 /opt/lxc/100/mountdir/

LXC # ls -la /opt/mountdir
      drwxr-xr-x  9 root root  4096 Sep 20 20:01 /opt/mountdir

Hinweise

  • Das Ganze funktioniert auch mit anderen UID/GID. Im Grunde 100000+UID/GID. Also UID 1001 wäre dann 101001.
  • Die UID/GID müssen nicht im Host-System vorhanden sein! LXC mappt die intern korrekt.
  • Ab diesem Moment kann man die Berechtigung auch innerhalb der VM korrekt setzen!

Relevante Host Konfiguration

Die folgenden Einstellungen im Proxmox-Linux dürften relevant sein, diese sollten aber von Proxmox bei der Installation vorgenommen worden sein!

cat /etc/subuid
root:100000:65536

cat /etc/subgid
root:100000:65536

Weiterführende Literatur

Die Lösungsansätze sind anders wie bei mir!
Aber als weiterführende Literatur hilfreich.

https://wiki.archlinux.org/index.php/Linux_Containers#Enable_support_to_run_unprivileged_containers_(optional)

https://pve.proxmox.com/wiki/Unprivileged_LXC_containers

[ansible] Mit dictonaries arbeiten

Wichtig: getestet mit Ansible 2.4.2.0

Wenn man in Ansible Variablen deklarieren möchte, kann es der Übersichtlichkeit halber interessant sein, diese in Dictionaries anzulegen. Beispielsweise wenn man mit mehreren Umgebungen arbeitet  – Test/vProd/Prod – und Fachanwendungen auf Server „taggen“ möchte. Sprich eine List wo steht auf welchen Server die einzelnen Fachanwendungen installiert sind.

Deklaration

Ort der „vars“-Datei

wir deklarieren eine neue Variablen-Datei
<ansible-root>/vars/main.yml
oder mit Rollen
<ansible-root>/roles/<role-name>/vars/main.yml

Alternativ:

Inhalt der Datei

Auf diese Weise kann man ein „Host-Tagging“ bewerkstelligen.
Sprich man deklariert, auf welchen Servern eine bestimmte Anwendung installiert ist, und führt hier entsprechende Task’s aus.

Anwendung

Einen Parameter abfragen

Ergebnis:

Parameter und Host abfragen

Jetzt wird es ein wenig komplizierter, wir wollen einen Parameter und einen bestimmten Server abfragen.
Achtung! Eignet sich nur wenn man einen bestimmten Server sucht! Nicht für eine Gruppe von Servern.

Tipp: Variablen werden ohne Klammern deklariert

 

Alle hosts ausgeben

Ergebnis:

Loop over dictonary

Um mit allen Werten zu arbeiten bietet sich folgende Vorgehensweise an:

Ergebnis:

Task auf host „taggen“

Auf diese Weise kann man deklarieren, dass ein Task auf dem aktuellem Server nur ausgeführt wird, wenn er in einer entsprechenden Liste deklariert wurde.

Oder auf Klardeutsch:
Wenn host_a NICHT in den hosts von anwendung_a aufgelistet ist, würde der Task nicht auf diesem Host ausgeführt werden.

Zum nachlesen:

Hier wird das gut erklärt finde ich:
https://stackoverflow.com/questions/31566568/double-loop-ansible

[Ansible] Mehrere Parameter innerhalb einer Datei ändern

Ich habe im Internet ein wirklich schönes Beispiel für einen Ansible-Task gefunden um mehrere Parameter zu setzen.

Quelle: https://stackoverflow.com/questions/24334115/ansible-lineinfile-for-several-lines

 

systemd-resolved und TLD

Unter einem frisch installiertem Ubuntu 17.04 musste ich feststellen, dass Top-Level-Domain (TLD) nicht nicht im DNS Such Suffix berücksichtigt wurden.

Beispiel:
server1  wurde nicht aufgelöst, obwohl .abc in den DNS Domain’s aufgelistet war.
server1.abc hingegen wurde erkannt

server2 (server2.test.abc) wurde hingegen korrekt aufgelöst.

Die Lösung:

Die korrekte Konfiguration des Systemd-resolvers kann man hiermit prüfen:

Hierzu gibt es einen aktuellen Bug:
https://github.com/systemd/systemd/issues/6224

 

Apache Wartungsseite schalten

Die (perfekte) Wartungsseite zu schalten ist eine Kunst für sich. zB wenn man verhindern möchte, dass die URL umgeschrieben wird oder das der Browser die Wartungsseite cacht.

Hier ein Beispiel, wo per per Datei die Wartungsseite aktiviert/deaktiviert werden kann:

# Wartung
RewriteCond /var/www/maintenance.enable -f
RewriteCond %{REQUEST_URI} !^/(wartung)/
RewriteRule ^.*$ /wartung/index.html [R=503,L]
ErrorDocument 503 /wartung/index.html
Header Set Cache-Control „max-age=0, no-store“

Proxmox: LXC – Container Speicherplatz verkleinern

Wer schon einmal versucht hat, den Speicherplatz eines LXC-Containers unter Proxmox zu verändern, wird überrascht feststellen, dass man zwar Speicherplatz hinzufügen, jedoch nicht entfernen kann.
Beispiel: 50GB root-Partition soll auf 30GB verringert werden ..

Das klappt tatsächlich nur über ein löschen und neu anlegen des Containers!

Hier ein Einzeiler dafür:


mit „–rootfs local:8“ gibt man die neue Größe in GB an.

Process Management – TicketStateSet

Update:

Admin ->  Ticket Settings -> States
Hier sieht man ebenfalls die existierenden Staten. Und in der URL sieht man die ID …

Ich finde die Datenbank aber dennoch übersichtlicher …

Wer sich in OTRS mit Process Managment auseinandersetzt, stößt irgendwann auf den Punkt „Transition Action“ -> „TicketStateSet“.

Hiermit kann man Tickets mit Status beenden, eröffnen auf Pending setzen, …
Problematik hierbei -> man muss den genauen Namen / ID des Status kennen! Mit hat die offizielle Dokumentation von OTRS leider nicht weitergeholfen, hier war nur dokumentiert wie man den Wert ändert, aber nicht auf welchen Wert … (Stand Mai 2016).

Kurz und knapp, nach einiger Recherche habe ich herausgefunden, dass die Ticket-Staten in der Datenbank – Tabelle „ticket_state“ – abgelegt werden …

Weiterlesen »

Entfernte CheckMK-Agents überwachen (ssh/tls)

CheckMK-Agents sinf auf Pull ausgelegt, sprich der CheckMK-Server baut eine Verbindung zum Client auf und fragt die Daten ab. Dies geschieht unter Linux traditionell per xinetd oder ssh.

Das Verfahren funktioniert aber nicht, wenn der Agent nicht im Intranet hängt und keine SSH-Verbindung hergestellt werden kann/soll. (oftmals. aus Security-Gründen).

check_mk_remote

Hierfür wurde die Community-Erweiterung „check_mk_remote“ entwickelt, welche den Agent-Output in eine Datei umleitet und diese per scp auf den CheckMK Server überträgt. Die Auswertung erfolgt dann durch einen Host-spezifischen Datasource.

https://github.com/FlorianHeigl/nagios/tree/master/check_mk/check_mk_remote

Für das Verfahren von check_mk_remote ist eine passwortlose Authentifizierung, sowie ein öffentlich zugängiger SSH-Server erforderlich. Beides kann sicher betrieben werden, jedoch ist der Konfigurationsaufwand nicht zu unterschätzen und sicherheitstechnisch bedenklich, vor allem weil es 100 Kleinigkeiten zu bedenken gibt.

check_mk_push

Als Alternative habe ich eine Methode entwickelt, um den Agent-Output per https statt ssh zu übertragen.
Das Prinzip ist identisch, nur der Übertragungsweg ein ganz anderer.

Vorteile gegenüber check_mk_remote

  1. Keine aufwendige SSH-Konfiguration.
  2. keine spezielle Firewall-Freischaltung (es wird nur Port 443 benötigt, ssh ist oftmals gesperrt)
  3. Firmeninterner Web-Proxy kann benutzt werden (inkl. Authentifizierung)

Weiterlesen »

Google Drive als Backup-Lösung

Ich suche seit einiger Zeit einen günstigen Web-Storage um externe Backups meiner zahlosen Projekte  anzulegen. Hat mich selbst überrascht, aber Google ist hier mit ABSTAND! der billigste Anbieter, bei 3$/Monat für 100GB kann man echt nicht meckern ..

Ich bin bei weitem kein Freund von der Datenkrake Google, trotzdem ist google.de meine Standart-Suchmaschine und Android mein Pflicht-OS für’s Smartphone …

Trotzdem schaufel ich meine Backups nur PGP-verschlüsselt in die Google-Cloud!

Installation unter Debian 8

Zum synchronisieren mit google-drive benutze ich „drive“ von twodopeshaggy.
https://launchpad.net/~twodopeshaggy

Weiterlesen »

[Proxmox] V4 – Befehl in jedem LXC-Container ausführen

Ich habe einen Quick-and-Dirty Weg gefunden, einen Befehl in sämtlichen (laufenden!) LXC-Container auszuführen.

Auf dem Proxmox-Host-System:

In meinem Beispiel würde das check-mk Plugin apt auf in allen Containern in das (bestehende) Unterverzeichnis 14400 verschoben werden.

Tipp: Falls ihr einen Befehl mit Parametern ausführen wollt müsst ihr das mitteilen!

Beachtet das „–„

<\/body>