Offizielles FHEM Docker Basis Image für verschiedene Plattformen

Begonnen von Loredo, 28 Juli 2018, 21:24:57

Vorheriges Thema - Nächstes Thema

maddhin

Zitat von: Otto123 am 29 Dezember 2021, 23:13:46
Das Original Docker Basis Image ist "kaputt", steht auf den vielen Seiten zuvor auch mehrfach beschrieben. Wenn man da npm aktualisiert ist es irgendwann weg. Entweder zerstörst Du den Container, und machst ihn neu und dann KEIN npm Update, oder Du nimmst wie kadettilac89 schrieb gleich das Image von cooltux ;)

Zitat von: kadettilac89 am 29 Dezember 2021, 17:35:03
Ansonsten mehr Input. Auf welcher Hardware läuft Docker? Ist die Weboberfläche erreichbar?

Ahh, das ist schade. Bisher hatte das Image problemlos funktioniert und läuft seit 1+ Jahren auf einem RPI. D.h. bis auf das mit Alexa jetzt, gab es keine Probleme und es läuft alles.

Ehrlich gesagt, weiß ich gar nicht, wie man npm / das Image aktualisiert. Das muss man wohl über apt-get update / upgrade im Container selbst anstoßen? Ich habe Docker bewußt gewählt, weil es so viel einfacher ist, ein docker-compose zu basteln als alles selbst zu installieren. Meine Linux Kenntnisse sind beschränkt und es ist für mich immer sehr zeitaufwendig was zu installieren bzw. irgendwelche Installations- und Konfigurationsprobleme zu lösen.

Exkurs
Ich persönlich finde Docker eine geniale, moderne Möglichkeit FHEM auch Leuten mit beschränkten Linux Kenntnissen zugänglich zu machen. Gerade auch um MySQL, MQTT, Homebridge, Alexa(!), etc einfach zu integrieren, was nicht trivial ist. Auch um eine einfache bzw. einfach zu bedienende (Cloud-)Backup-Lösung wie z.B. Duplicati anzubieten. Dass da das original FHEM-Image "bockt" ist natürlich "suboptimal". Eigentlich sollte das Docker-Image gepusht werden.
Exkurs Ende

Kann ich jetzt die Docker-compose einfach vom Fhem- auf das cooltux-Image ändern und die Konfiguration und Daten bleiben bestehen?

Alternativ: Wie würde ich das Alexa-Fhem Docker Image integrieren? Der Alexa-Fhem Container sollte ja eigentlich funktionieren, aber irgendwie findet FHEM Alexa-Fhem wohl nicht.

slupus

Zitat von: Init am 25 November 2021, 12:33:44
Beim Starten habe ich aber das Problem, dass die Berechtigungen nicht gemäß Environment-Definition gesetzt werden.

Ich habe das gleiche Problem. Bei mir betrifft es die Berechtigung aber auch die Ports. Ich habe jetzt verschiedene Konfigurationen durchprobiert, um die Environment-Definition mitzugeben (mit ', ", :, = oder vorangestelltem -).
In meiner Prod Umgebung funktioniert aber bspw. die Übergabe des USB Devices und die Änderung des Logfiles.
Anbei der yml Auszug  für die Testumgebung:

version: '3.3'
services:
    fhem-test:
        container_name: fhem-test
        restart: 'always'
        ports:
            - "8084:8084"
        volumes:
            - '/opt/docker/fhem-test:/opt/fhem'
        environment:
            # - 'APT_PKGS=package1 package2'
            - LOGFILE=./log/fhem-%Y-%m.log
            - FHEM_PERM_DIR:0754
            - FHEM_PERM_FILE:0644
            - UMASK=0033
            - TZ=Europe/Berlin
            - TELNETPORT=7073
        network_mode: host
        image: ghcr.io/fhem/fhem-experimental:dev


Hier noch der Auszug des Container Logs (frisch aufgesetzt):

Preparing initial start:
1. Installing FHEM to /opt/fhem
2. Patching fhem.cfg default configuration
3. Adding pre-defined devices to fhem.cfg
Preparing user environment ...
1. Creating group 'fhem' with GID 6061 ...
2. Enforcing GID for group 'bluetooth' to 6001 ...
3. Creating user 'fhem' with UID 6061 ...
4. Creating log directory /opt/fhem/./log ...
5. Enforcing user and group ownership for /opt/fhem to fhem:fhem ...
6. Enforcing file and directory permissions for /opt/fhem ...
7. Correcting group ownership for /dev/tty* ...
8. Found GPIO: Correcting group permissions in /dev and /sys to 'gpio' with GID 6002 ...
9. Found I2C: Correcting group permissions in /dev to 'i2c' with GID 6003 ...
10. Updating /etc/sudoers.d/fhem-docker ...
11. Adding gateway.docker.internal to /etc/hosts ...
12. Adding host.docker.internal to /etc/hosts ...
13. Pre-authorizing SSH to Docker host for user 'fhem' ...
14. Updating SSH key pinning and SSH client permissions for user 'fhem' ...
Preparing configuration ... done
Starting FHEM ...
2021.12.30 12:44:35.036 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m.log
2021.12.30 12:44:35.037 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2021.12.30 12:44:35.037 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2021.12.30 12:44:35.037 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2021.12.30 12:44:35.044 1: Including fhem.cfg
2021.12.30 12:44:35.264 1: WEB: Can't open server port at 8083: Address already in use. Exiting.


Hat jemand eine Idee, was wir falsch machen?

Wernieman

Wie schon Otto sagte, mach nicht EIN docker-compose.yml, sondern für jedes "Projekt" eines. z.B. muß Portainer nicht im gleichen Projekt wie fhem sein. Schließlich steuer fhem nicht Portainer und Portainer auch nicht fhem (sondern "nur" den Container"). Macht es übersichtlicher und sogar "sicherer" ...

Ich mag an diesem Container nicht, das er eine "Eierlegende Wollmichsau" ist. Er kann vieles, ist dadurch aber auch sehr groß und schwierig zu Warten.
Auch erfolgt eine Aktuallisierung innerhalb des Containers ... und eben nicht dadurch, das man den Container tauscht ... aber DAS ist ein anderes Thema.

Da der Container von Cooltux ein "fork" des "Originalen" von Loredo, sollte es so funktionieren. Ansonsten mach es wie bei Docker-Upgrade üblich:
1. Container stoppen
2. Verzeichnis sichern (bzw. Verzeichnisse)
3. docker-compose editieren (Hinweis s.o.)
4. Container starten
Bei Problemen
5. Container stoppen, 4. Rückgängigmachen, 2. zurückspielen, Container starten

Edit:
War eine Antwort auf maddhin Beitrag ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Wernieman

Gekürtzter Beitrag
Zitat von: slupus am 30 Dezember 2021, 12:58:37

        ports:
            - "8084:8084"

Hier noch der Auszug des Container Logs (frisch aufgesetzt):

Preparing initial start:
2021.12.30 12:44:35.264 1: WEB: Can't open server port at 8083: Address already in use. Exiting.

Hat jemand eine Idee, was wir falsch machen?

Mit der Portangabe sagst Du nur Docker, NICHT fhem, das der Port 8084 von extern erreichbar sein soll, also von außerhalb der Docker-Welt. Die Fehlermeldung sagt dagegen aus, das fhem den Port 8083 nicht öffnen kann. Hast Du noch etwas auf dem Port 8083 laufen? Was sagt die fhem.cfg dazu?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Otto123

#1384
Zitat von: maddhin am 30 Dezember 2021, 12:41:10
Ehrlich gesagt, weiß ich gar nicht, wie man npm / das Image aktualisiert. Das muss man wohl über apt-get update / upgrade im Container selbst anstoßen? Ich habe Docker bewußt gewählt, weil es so viel einfacher ist, ein docker-compose zu basteln als alles selbst zu installieren. Meine Linux Kenntnisse sind beschränkt und es ist für mich immer sehr zeitaufwendig was zu installieren bzw. irgendwelche Installations- und Konfigurationsprobleme zu lösen.
...
Kann ich jetzt die Docker-compose einfach vom Fhem- auf das cooltux-Image ändern und die Konfiguration und Daten bleiben bestehen?
Ja.
Du änderst in deiner docker-compose.yml die Zeile mit dem fhem image auf:
   image: ghcr.io/fhem/fhem-experimental:dev

und machst ein docker-compose pull
docker-compose up -d
damit macht er den fhem container neu, deine FHEM bleibt.
Der separate pull Befehl sorgt für geringe down time deines containers, er zieht damit erstmal nur das Image.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

maddhin

Zitat von: Wernieman am 30 Dezember 2021, 13:05:52
Wie schon Otto sagte, mach nicht EIN docker-compose.yml, sondern für jedes "Projekt" eines. z.B. muß Portainer nicht im gleichen Projekt wie fhem sein. Schließlich steuer fhem nicht Portainer und Portainer auch nicht fhem (sondern "nur" den Container"). Macht es übersichtlicher und sogar "sicherer" ...

Ich mag an diesem Container nicht, das er eine "Eierlegende Wollmichsau" ist. Er kann vieles, ist dadurch aber auch sehr groß und schwierig zu Warten.

Das ist richtig, wenigstens Portainer und auch Duplicati gehören in eigene Container. Aber bei Duplicati bin ich daran gescheitert root-access zu bekommen, weil ich das "System" d.h. Zusammenspiel zwischen Docker, FHEM-Container, etc. nicht richtig verstehe (was natürlich durch mehr googeln gelöst werden kann). Duplicati in den FHEM-Container zu packen war die billige Variante - wobei ich ohnehin nur FHEM sichern möchte.

Ganz sicher ist meine docker-compose hier nicht als Paradebeispiel zu nehmen. Ich hatte aber keine bessere "Basis"-docker-compose gefunden und kenne mich mit Docker auch nicht gut aus, um das alles richtig zu machen. Ich bin schon froh, dass diese docker-compose mit dem RPI sauber läuft. Nur an Alexa ist es wohl gescheitert.

Wobei ich jetzt nicht weiß, ob die Wartung einfacher ist. Im Grunde macht die docker-compose doch einen stack aus mehreren einzelnen Containern, oder? D.h. man muss so oder so jeden Container warten. Wenn man natürlich MQTT, Homebridge, etc. gleich über "environment" in den FHEM container packen kann, wäre das viel besser. Gibt es dazu irgendwo Anleitungen?
Andererseits sind einzelne Container ggf auch gut, weil man dann bei Problemen schnell und leicht MQTT, etc. neu aufsetzen kann und man nicht in der FHEM Installation rumfummeln muss.



Wernieman

Mit docker-compose.yml baust Du eine Gruppe von Containern. Mit mehreren docker-compose.yml, am besten in jeweils neuem Verzeichnis, hast Du dann mehrere "Gruppen". Der Vorteil ist, das Du z.B. eine Gruppe runterfahren/warten kannst, ohne die anderen "zu belästigen".

Nur mal als Hinweis:
Bei mir läuft u.A. fhem, nextcloud, calibre, mailu-Mailserver, phihole, apt-cache, wheb-Server, lirc-Deamon, graylog, zabbix jeweils in eigenen docker-compose.yml. Damit bestehen einige Projekte aus mehr als einen Containern (z.B. Mail-Server aus 9). Wenn alles in EINER docker-compoise.yml, währe es nicht mehr zu warten. Und außerdem, "sehen" die Container sich nicht gegenseitig, was sogar die Sicherheit erhöht ....
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

kadettilac89

OT: vor allem an die "Main" Supporter wie Wernieman, Otto123, Cooltux, ...

würde es nicht Sinn machen, für Docker einen eigenen Forum-Knoten zu machen und die Probleme in eigene Posts zu trennen? Wenn ich mir die letzten Posts ansehe haben wir eigenständige Probleme, einmal Berechtigung von sluplus, das npm-Thema von maddhin ... die Themen haben nur wenig mit dem hier verwendeten Image zu tun sondern mehr wie man Docker bedient. Im 100-seitigen Thread sind sicher viele Informationen aber diese findet keiner mehr.

Außerdem wird es unübersichtlich wenn mehrere Probleme parallel supportet werden. Man muss immer aufpassen, dass man auf das richtige antwortet

... just my2cents ...

Wernieman

Du hast Recht. Nur ... eigentlich müssten dafür immer ein Neuer Thread aufgemacht werden. Solche Monsterthreads führen zu keiner Lösung mehr.

Nur die Maintainer können nichts dran ändern, das User lieber an Thread anhängen, als neue Aufmachen. Ist jetzt kein reines Docker-Thread-Problem ... sondern eines, von den Benutzern des Forum ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

slupus

Zitat von: Wernieman am 30 Dezember 2021, 13:10:09
Mit der Portangabe sagst Du nur Docker, NICHT fhem, das der Port 8084 von extern erreichbar sein soll, also von außerhalb der Docker-Welt. Die Fehlermeldung sagt dagegen aus, das fhem den Port 8083 nicht öffnen kann. Hast Du noch etwas auf dem Port 8083 laufen? Was sagt die fhem.cfg dazu?
Das war mir nicht bewusst. In der cfg stand natürlich 8083 (darauf läuft meine Prod Umgebung). Das abgeändert und die Testumgebung ist erreichbar.

Bleibt dennoch die Frage, was mit den Berechtigungen ist und wie diese greifen. Oder habe ich auch hier etwas nicht verstanden? Ich würde erwarten, dass das Verzeichnis auf dem Host entsprechend der Environment-Werte gesetzt wird. Leider sieht es aber wie folgt aus, hätte aber gerne 0754 für Verzeichnisse und 0644 für Files:

drwxr-x--- 15 6061 6061   4096 Dec 30 14:36 .
drwxr-xr-x  9 pi   root   4096 Dec 30 11:41 ..
-rw-r-----  1 6061 6061 369405 Nov 24 21:44 CHANGED
drwxr-x---  3 6061 6061   4096 Dec 30 11:53 .config
-rw-r-----  1 6061 6061  42987 Nov 24 21:44 configDB.pm
drwxr-x--- 52 6061 6061   4096 Nov 24 21:54 contrib
-rw-r-----  1 6061 6061  18092 Nov 24 21:44 COPYING
drwxr-x---  3 6061 6061   4096 Nov 24 21:54 demolog
drwxr-x---  4 6061 6061   4096 Dec 30 12:44 docs
drwxr-x---  6 6061 6061  20480 Dec 30 12:44 FHEM
-rw-r-----  1 6061 6061   2205 Dec 30 14:36 fhem.cfg
-rw-r-----  1 6061 6061   2205 Dec 30 14:36 fhem.cfg.bak
-rw-r-----  1 6061 6061    516 Dec 30 12:44 fhem.cfg.default
-rw-r-----  1 6061 6061  25544 Nov 24 21:44 fhem.cfg.demo
-rwxr-----  1 6061 6061 169103 Nov 24 21:44 fhem.pl
-rw-r-----  1 6061 6061  18092 Nov 24 21:44 GPL_V2.txt
-rw-r-----  1 6061 6061  28513 Nov 24 21:44 HISTORY
drwxr-x---  3 6061 6061   4096 Nov 24 21:54 lib
drwxr-x---  2 6061 6061   4096 Dec 30 14:36 log
-rw-r-----  1 6061 6061  44779 Nov 24 21:44 MAINTAINER.txt
-rw-r-----  1 6061 6061   5073 Nov 24 21:44 Makefile
drwxr-x---  3 6061 6061   4096 Dec 30 11:53 .npm
-rw-r-----  1 6061 6061     25 Nov 24 21:44 .proverc
-rw-r-----  1 6061 6061    935 Nov 24 21:44 README_DEMO.txt
-rw-r-----  1 6061 6061    374 Nov 24 21:44 README.SVN
drwx------  2 6061 6061   4096 Dec 30 14:36 .ssh
drwxr-x---  3 6061 6061   4096 Nov 24 21:54 t
drwxr-x---  3 6061 6061   4096 Nov 24 21:54 thirdparty
-rw-r-----  1 6061 6061   2693 Nov 24 21:44 UPGRADE
drwxr-x---  6 6061 6061   4096 Nov 24 21:54 webfrontend
drwxr-x---  8 6061 6061   4096 Nov 24 21:54 www

kadettilac89

Zitat von: slupus am 30 Dezember 2021, 14:44:13
Bleibt dennoch die Frage, was mit den Berechtigungen ist und wie diese greifen. Oder habe ich auch hier etwas nicht verstanden? Ich würde erwarten, dass das Verzeichnis auf dem Host entsprechend der Environment-Werte gesetzt wird. Leider sieht es aber wie folgt aus, hätte aber gerne 0754 für Verzeichnisse und 0644 für Files:


Wenn der Container neu erstellt wird, gibt das Script eine Meldung aus die auf das Ändern von Berechtigung hinweist? Siehst du die, welche Meldung wird da ausgegeben?

Wernieman

User innerhalb Docker <> User Außerhalb Docker.
In der Docker-Compose steht kein User-Mapping.

Man sollte sich auch klar sein, wie Unix User überhaupt darstellt. In der Passwd steht zu jedem User eine ID-Zahl. Diese wird in der Datei gespeichert. Wenn Du also Wissen willst, welchem User eine Datei gehört, mußt das System die passwd nach der User-ID durchsuchen und dann den namen anzeigen. Da der Docker-FHEM-user scheinbar bei Dir die ID 6061 bekommt und natürlich in der System passwd diese User-ID nicht vergeben ist, zeigt er eben die ID an.

Edit:
Mal wieder zu langsam ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Otto123

#1392
@sluplus network_mode: host
Damit wird nach meinen bescheidenen Kenntnissen das portmapping witzlos :)
Der Fehler kommt daher das auf deinem Host Port 8083 schon in Betrieb ist?

ich meine das muss so?
          - FHEM_PERM_DIR=0754
          - FHEM_PERM_FILE=0644

und ich rücke immer nur 2 Zeichen ein ;) ob das entscheidend ist weiß ich nicht. Ich habe die Regeln auch nicht zu 100% verstanden
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

slupus

Zitat von: kadettilac89 am 30 Dezember 2021, 14:55:27
Wenn der Container neu erstellt wird, gibt das Script eine Meldung aus die auf das Ändern von Berechtigung hinweist? Siehst du die, welche Meldung wird da ausgegeben?
Leider keine Meldung, die mir weiterhilft:

Preparing user environment ...
1. Creating group 'fhem' with GID 6061 ...
2. Enforcing GID for group 'bluetooth' to 6001 ...
3. Creating user 'fhem' with UID 6061 ...
4. Creating log directory /opt/fhem/./log ...
5. Enforcing user and group ownership for /opt/fhem to fhem:fhem ...
6. Enforcing file and directory permissions for /opt/fhem ...
7. Correcting group ownership for /dev/tty* ...
8. Found GPIO: Correcting group permissions in /dev and /sys to 'gpio' with GID 6002 ...
9. Found I2C: Correcting group permissions in /dev to 'i2c' with GID 6003 ...
10. Updating /etc/sudoers.d/fhem-docker ...
11. Adding gateway.docker.internal to /etc/hosts ...
12. Adding host.docker.internal to /etc/hosts ...
13. Pre-authorizing SSH to Docker host for user 'fhem' ...
14. Updating SSH key pinning and SSH client permissions for user 'fhem' ...



/entry.sh: line 518: [: missing `]'
Preparing configuration ... done

Starting FHEM ...
2021.12.30 14:56:42.042 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2021.12.30 14:56:42.042 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2021.12.30 14:56:42.042 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2021.12.30 14:56:42.042 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m.log
2021.12.30 14:56:42.049 1: Including fhem.cfg
2021.12.30 14:56:42.246 3: WEB: port 8084 opened
2021.12.30 14:56:42.286 2: eventTypes: loaded 34 lines from ./log/eventTypes.txt
2021.12.30 14:56:42.603 3: AptToDate (fhemServerApt) - defined
2021.12.30 14:56:43.197 3: telnetPort: port 7073 opened
2021.12.30 14:56:43.197 1: Including ./log/fhem.save
2021.12.30 14:56:43.217 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2021.12.30 14:56:43.217 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2021.12.30 14:56:43.218 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2021.12.30 14:56:43.218 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m.log
2021.12.30 14:56:43.219 1: Messages collected while initializing FHEM:SecurityCheck:
  telnetPort is not password protected
  WEB is not password protected

Protect this FHEM installation by defining an allowed device with define allowed allowed
You can disable this message with attr global motd none

2021.12.30 14:56:44.607 1: usb create starting
2021.12.30 14:56:44.646 1: usb create end
2021.12.30 14:56:44.648 0: Featurelevel: 6.1
2021.12.30 14:56:44.648 0: Server started with 11 defined entities (fhem.pl:25197/2021-11-07 perl:5.028001 os:linux user:fhem pid:4073)


Zitat von: Wernieman am 30 Dezember 2021, 14:58:22
Man sollte sich auch klar sein, wie Unix User überhaupt darstellt. In der Passwd steht zu jedem User eine ID-Zahl. Diese wird in der Datei gespeichert. Wenn Du also Wissen willst, welchem User eine Datei gehört, mußt das System die passwd nach der User-ID durchsuchen und dann den namen anzeigen. Da der Docker-FHEM-user scheinbar bei Dir die ID 6061 bekommt und natürlich in der System passwd diese User-ID nicht vergeben ist, zeigt er eben die ID an.
Der User 6061 is ja der default User des Docker Containers. Den will ich gar nicht ändern, sondern es sollen lediglich andere Rechte vergeben werden, damit die Dateien auch von anderen Usersn gelesen werden können.
Das versuche ich mit folgendem zu erreichen:

        environment:
            - FHEM_PERM_DIR=0754
            - FHEM_PERM_FILE=0644
            - UMASK=0033

Der Container setzt aber leider immer 0640, was dem default entspricht.

Zitat von: Otto123 am 30 Dezember 2021, 15:05:29
@sluplus network_mode: host
Damit wird nach meinen bescheidenen Kenntnissen das portmapping witzlos :)
Der Fehler kommt daher das auf deinem Host Port 8083 schon in Betrieb ist?
Danke Otto, habe ich vorhin in deinem Blogbeitrag gelesen, aber noch nicht abgeändert. Wie geschrieben läuft meine Prod Umgebung von FHEM auf Port 8083

Wernieman

Ahhh .... Du meinst also "Bug im FHEM-Container" ... denn von Docker werden diese Variablen nicht verwaltet
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html