Archiv nach Kategorien: Allgemein

LetsEncrypt-Wildcard SSL-Zertifikate mit Domain-Offensive

ACHTUNG NOCH IM AUFBAU

Noch als Azubi im Jahre 2010 hatte ich den Auftrag bekommen einen günstigen und guten Anbieter für Domains zu suchen. Ich bin bei Domain-Offensive gelandet, mittlerweile habe ich selbst mehrere Domains dort.

Da ich zig Sub-Domains im Einsatz habe (Stichwort „name-based virtual hosts“) bin ich irgendwann auf Wildcards Zertifikate gewechselt. Diese benutze ich sowohl für meine Webserver, als auch für meinen eMail-Server.

Domain-Offensive bietet mittlerweile selbst eine API für LetsEncrypt an.
Doku: https://www.do.de/wiki/LetsEncrypt_-_Entwickler

Ich habe hierfür simple Bash-Scripte erstellt, mit welchen man – über die API – Wildcard-Zertifikate anlegen und aktualisieren kann. Der Trick hierbei ist, dass temporäre _acme-challenge.* DNS-Einträge erstellt werden.

Certbot installieren

Ich möchte hier nicht im Detail auf die Installation von Certbot eingehen, nur der Tipp am Rande, das eine aktuelle Version von Certbot benötigt wird. Ganz alte Versionen unterstützen noch keine Wildcard Zertifikate

Zum Zeitpunkt des Artikels setze ich Certbot 1.8.0 aus dem sid-Repo ein.

DomainOffensive-API-Key

Zuerst erstellen wir einen API-Key, Details siehe API-Doku.
https://www.do.de/account/letsencrypt/

Der API-Key gilt pro Account, nicht pro Domain!

Anlegen der Ordner+Scripte

Hier kommt nun mein customizing…

## Ordnerstruktur anlegen
mkdir -p /opt/letsencrypt/{hooks,logs,scripts}

/opt/letsencrypt/scripts/new_domain.sh

#!/bin/bash
## Script für neue Domains

for domain in "$@"
do
        echo $DOMAINS
        [ -n "${DOMAINS}" ] && DOMAINS="${DOMAINS},"
        DOMAINS="${DOMAINS}${domain}"
done

[ -z ${DOMAINS} ] && { echo "No domain given"; exit 1; }

certbot certonly --server https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges dns --manual-auth-hook "/opt/letsencrypt/hooks/authenticator.sh" --manual-cleanup-hook "/opt/letsencrypt/hooks/cleanup.sh" -d "${DOMAINS}"

/opt/letsencrypt/hooks/authenticator.sh

#!/bin/bash
## https://certbot.eff.org/docs/using.html

## Token from do.de
APITOKEN="<YourDOApiTokenHere>"

DOMAIN="_acme-challenge.$CERTBOT_DOMAIN"

echo "$(date +'%Y-%m-%d %T') curl-XPUT \"https://www.do.de/api/letsencrypt?token=${APITEKEN}&amp;domain=${DOMAIN}&amp;value=${CERTBOT_VALIDATION}"\" >> /opt/letsencrypt/logs/hook_authenticator.log

curl -XPUT "https://www.do.de/api/letsencrypt?token=${APITOKEN}&amp;domain=${DOMAIN}&amp;value=${CERTBOT_VALIDATION}" >> /opt/letsencrypt/logs/hook_authenticator.log 2>&amp;1

/opt/letsencrypt/hooks/cleanup.sh

#!/bin/bash
## https://certbot.eff.org/docs/using.html

## Token from do.de
APITOKEN="<YourDOApiTokenHere>"

DOMAIN="_acme-challenge.${CERTBOT_DOMAIN}"

curl -XPUT "https://www.do.de/api/letsencrypt?token=${APITOKEN}&amp;domain=${DOMAIN}&amp;action=delete"

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

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

 

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 „–„

[Tomcat] Applikation als Startseite

Wenn man bei Tomcat eine .war deployt (zB. mysite.war), heißt der im Verzeichnis /webapps erstellte Order – und somit auch die URL – entsprechend dem Dateinamen der .war Datei (in diesem Beispiel also /mysite/).

Es gibt nun mehrere Möglichkeiten, dieses anzupassen:

  • Apache Proxy vorschalten, in meinen Augen die schönste Variante. Wird von professionellen Webhostern bevorzugt eingesetzt.
  • die mysite.war vor dem deployen umbennen in ROOT.war (groß/kleinschreibung beachten!)
    • ACHTUNG! Einige (schlecht programmierte) Anwendungen arbeiten mit absoluten Pfaden und benötigen die URL /mysite/ …
  • eine HTML-Weiterleitung von / auf /mysite/, für mich eine durchaus aktzeptable Lösung, welche auch gerne von professionellen Anwendungen eingesetzt wird.
    • Hier eine Beispielsdatei für die Weitereitung:

 

Youtube-Channel als RSS-Feed

Seit der Abschaltung der Youtube v2 API sind ca 90% aller Tipps zum generieren von YouTube-Feeds veraltet.

Ich habe nach einer umfangreichen Google-Suche in einem Gast-Kommentar tatsächlich noch eine brauchbare Lösung gefunden.

https://www.youtube.com/feeds/videos.xml?channel_id=CHANNELID
https://www.youtube.com/feeds/videos.xml?user=USERNAME

Hinweis: Der Feed funktioniert (im ownCloud-RSS-Reader) ist jedoch laut dem RSS-Validator von W3C extrem Mangelhaft (nett ausgedrückt …) Beispielweise kann der Mozilla/Firefox interne Feed-Reader das Datum der einzelnen Posts überhaupt nicht auslesen, bei user=3Dudelsack3 zB. sind alle Posts von <heute>, nur die Uhrzeit variiert … Zum Glück pflegen die meisten Feed-Reader eigene (interne) DBs!

<\/body>