Wie man einen eigenen Collabora Server für Nextcloud in Docker und hinter einem Nginx Reverse Proxy korrekt startet

Um innerhalb von Nextcloud so eine Art Google-Docs betreiben zu können, benötigt man zum einen die Nextcloud-Office-App, aber auch einen extra Server (Collabora), der quasi als Backend für das Office dient. Letztendlich handelt es sich da um eine Headless Open-Office Instanz, wenn ich das richtig verstanden habe.

Im besten Fall betreibt man Nextcloud ohnehin auf dem eigenen Server innerhalb von Docker, dann sollte die Kommunikation mit dem Collabora Server kein Problem sein.

Da in meinem Beispiel die Nextcloud Instanz von Hetzner gehosted wird, war es notwendig, dass der Collabora Server über das Internet kontaktiert wird und eben nicht im gleichen Netzwerk hängt. Und da ist die Dokumentation etwas schwammig bzw. einfach falsch. Denn in der Dokumentation, die man so im Netz finden kann, wird gesagt, dass man eine Environment-Variable namens “domain” definieren muss, die dann ein Regex der Nextcloud Domain enthält (damit nur Requests von dieser Domain bearbeitet werden).

Der entsprechende Code wurde aber geändert, sodass mehrere Nextcloud Server auf Collabora zugreifen können. Statt “domain” muss die Environmentvariable “aliasgroup1” heißen und sie enthält die komplette Domain inkl Portangabe (Durch Komma getrennt kann man mehrere URLs übergeben).

Beispiel:

aliasgroup1=https://meine.domain.com:443

In meinem konkreten Beispiel habe ich die Konfiguration, dass auf dem Server für Colabora Docker mit dem allseits bekannten Lets Encrypt Nginx Companion läuft. Das nette an diesem Setup ist, dass man allen weiteren Docker Containern auf diesem Server nur drei Env-Variablen mitgeben muss und schon erstellt und verwaltet das System automatisiert die Lets Encrypt Zertifikate.

In dieser Kombination ist es wichtig, Collabora mitzuteilen, dass es sich nicht um SSL kümmern soll, was man mit der Env-Variable

extra_params=--o:ssl.enable=false --o:ssl.termination=true

erreicht. Ausserdem muss der Collabora Container im privileged Modus laufen!

Mein Setup in Ansible sieht dann letztenlich so aus:

- docker_container:
    name: collabora
    image: collabora/code
    state: started
    detach: yes
    restart_policy: always
    privileged: yes
    expose:
      - 9980
    env:
      aliasgroup1: https://nextcloud.domain.com:443
      VIRTUAL_HOST: office.domain.com
      LETSENCRYPT_HOST: office.domain.com
      VIRTUAL_PORT: "9980"
      LETSENCRYPT_EMAIL: ich@meins.de
      extra_params: "--o:ssl.enable=false --o:ssl.termination=true"

Das Equivalent auf der Console sollte dann so aussehen:

docker run --name=collabora --env=aliasgroup1=https://nextcloud.domain.com:443 --env=VIRTUAL_HOST=office.domain.com --env=LETSENCRYPT_HOST=office.domain.com --env=VIRTUAL_PORT=9980 --env=LETSENCRYPT_EMAIL=ich@meins.de --env='extra_params=--o:ssl.enable=false --o:ssl.termination=true' --privileged --expose=9980 --restart=always --detach=true collabora

Wenn das erledigt ist und der Server läuft, kann man in Nextcloud den Admin Bereich öffnen und dort auf den Punkt “Office” gehen. Hier stellt man den Collabora Server ein und klickt auf Speichern:

Anschließend geht man in Nextcloud auf den “Dateien” Tab und klickt dann oben auf das Plus, um eine neue Datei zu erzeugen:

Anschließend öffnet man das Dokument und sollte nun die Office Oberfläche sehen. Falls eine Fehlermeldung kommt, und man es “später nochmal versuchen soll”, geht auf den Server wo Collabora läuft und schaut in die Logs des Containers.

Wenn ihr da irgendwas von

Terminating connection. Error: No acceptable WOPI hosts found matching the target host [nextcloud.domain.com] in config.

seht, dann habt ihr die Domain in der Environment Variable nicht korrekt übergeben. Überprüft vor allem, ob es sich überhaupt um die gleiche Domain wie in der Fehlermeldung handelt. Diese ist in jedem Fall die korrekte Domain und sollte so auch in der “aliasgroup1” drin stehen!

[Quicktip] Geteilte Fotoalben erscheinen nach iPhone-Wechsel als leer

Nachdem ich auf ein neues iPhone gewechselt bin, sind in meiner Fotos App ein paar meiner geteilten Fotoalben einfach leer geblieben. Ich glaube sogar alle waren auch von mir erstellt worden. Alles, was man sehen konnte, war das “Plus Zeichen” zum Hinzufügen von neuen Bildern, so als ob man das Album gerade erst erstellt hat. Auf allen meinen anderen Geräten mit dem gleichen iCloud Account waren sie weiterhin da.

Um das Problem (hoffentlich) zu beheben, kann man folgendes versuchen:

  • Fotos App beenden (richtig beenden, mittels Task Manager!)
  • Iphone Homescreen –> Einstellungen –> oben auf euren Namen tippen –> iCloud –> Fotos
  • “Geteilte Alben” ausschalten
  • auf den Homescreen wechseln
  • eine Minute warten
  • Iphone Homescreen –> Einstellungen –> oben auf euren Namen tippen –> iCloud –> Fotos
  • “Geteilte Alben” wieder einschalten
  • Fotos App öffnen

Die geteilten Alben sollten nun zeitnah erscheinen und zumindest bei mir waren dann auch alle wieder mit Bildern gefüllt.

MacOS Update Probleme auf Monterey mit APFS

Zu meiner Schande muss ich gestehen, dass mein privates Macbook irgendwann auf MacOS Mojave hängen geblieben ist. Ich hatte vor ein paar Monaten mal ein Upgrade auf Big Sur probiert, allerdings war der Rechner danach unbrauchbar, weil er nicht mehr gebootet hat. Nach einem ca. 8h oder so andauernden Recovery mittels Timemachine war er wieder einsatzbereit, aber mir war die Lust auf Updates vergangen.

Dieses Problem wollte ich nun endgültig mit dem Umstieg auf MacOS Monterey angehen und lösen. Also habe ich den Installer runtergeladen und wollte die Installation starten – als ich direkt die Fehlermeldung bekam, dass für die Installation ein Datenträger mit APFS notwending ist.
APFS ist ein alternatives Dateisystem, welches von Apple mit MacOS High Sierra verteilt wurde. Eigentlich sollte in Mojave der Datenträger automatisch dahin konvertiert werden (was sogar on-the-fly) gehen sollte, aber irgendwie ist das bei mir nicht passiert. Warum auch immer.

Um die Conversion nachträglich machen zu können, muss man den Mac im Recovery Modus starten, dann das Disk-Utility/Festplattendienstprogramm starten. Dort wirft man die Mac Festplatte aus, markiert sie und klickt dann auf Edit/Bearbeiten und “convert to apfs”. Anschließend wird das System umgestellt. Blöd nur, dass genau das den Fehler verursacht, dass man anschließend nicht mehr booten kann (Stichwort: “Running bless to place boot files failed”). Man könnte MacOS nach der Konvertierung nochmal drüber installieren, aber da Mojave nicht mehr installiert werden kann ging auch das nicht mehr für mich 😂

Die Lösung habe ich dann hier gefunden: https://www.tecklyfe.com/boot-failures-after-converting-macos-ssd-to-apfs/

Ich vermute mal dass das Problem irgendwie mit UEFI oder so zusammen hängt, jedenfalls muss man ein Pre-Boot Environment von Hand anlegen, damit der Bootvorgang wieder reibungslos funktioniert. Und das geht so:

  • Den Mac mit gedrückter Command+R Tastenkombi starten
  • Utilities > Terminal
  • diskutil apfs list ausführen und schauen, welche Nummer und welche UUID die Festplatte eures Macs hat – sie sollte “Macintosh HD” oder so heißen
  • Anschließend (natürlich ohne die eckige Klammer, als z.B. disk2:
    diskutil apfs addVolume disk[Festplatten-NUMMER] apfs Preboot -role B
  • Anschließend dieses Verzeichnis anlegen, wobei die xxx… durch die UUID, die ihr euch in Punkt 3 angesehen habt hier eintragt:
    mkdir -p /Volumes/Preboot/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/System/Library/CoreServices
  • cp -RP /Volumes/MACINTOSH HD/System/Library/CoreServices /Volumes/Preboot/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/System/Library/CoreServices
  • Mittels folgendem Commands repariert ihr nun den Pre-Boot-Eintrag. Ersetz hier das disk2s1, falls deine Partition eine andere Nummer hat:
    diskutil apfs updatepreboot disk2s1
  • Abschließend kannst du nun mit Bless den Boot-Eintrag setzen lassen:
    bless --folder /Volumes/MACINTOSH HD/System/Library/CoreServices --bootefi --verbose
  • Neu starten

[Quicktip] Mac OS ignoriert die Reihenfolge von Netzwerkanschlüssen und benutzt immer nur Wifi

Meine beiden Macbooks – eins mit Mojave und eins mit Big Sur – haben an meinem Schreibtisch das gleiche Problem: Wifi/Wlan wird immer bevorzugt verwendet. Ich merke das mit spontanen Aussetzern in Videokonferenzen, oder wenn ich im Netzwerk nicht mit dem gewohnten Gigabit Speed Kopieraktionen machen kann. Meine Vermutung ist, dass es mit meinem verwendeten USB-C Hub mit Netzwerkanschluss zu tun hat.

Normalerweise hat man in Mac OS die Möglichkeit, die Priorität für Netzwerkanschlüsse festzulegen und damit eigentlich genau mein Problem zu lösen:

Wie man sehen kann ist das WLAN unterhalb vom Thunderbold und eben meinem USB Gigabit Adapter angesiedelt. Und trotzdem wird es immer wieder bevorzugt verwendet.

Ich könnte das Wlan natürlich einfach abschalten, was ich auch getan habe, aber dann kann ich das Macbook nicht mehr mittels Apple Watch entsperren und Airdrop funktioniert auch nicht.

Nun bin ich auf die Idee gekommen, mit den Netzwerkumgebungen zu spielen, und siehe da, man kann sie zumindest als Workaround nutzen. Die Netzwerkumgebungen unter Mac OS sind eine Möglichkeit, dass man verschiedene IP Settings in seinem Mac speichern kann, sodass man z.B. schnell zwischen den Settings für die Arbeit und daheim wechseln kann.

Ich habe mir also zwei Netzwerkumgebungen “Schreibtisch” und “Unterwegs” angelegt. In der für mich relevanten Gruppe “Schreibtisch” belasse ich das Ethernet wie es ist. Schlaue Leute würden nun einfach den WLAN Apapter in der “Schreibtisch” Umgebung rauswerfen, allerdings deaktiviert sich dann das WLAN komplett und ich kann eben nicht meine Apple Watch zum Entsperren und Airdrop nutzen.

Also habe ich den Adapter drin gelassen, aber bei den IP Einstellungen für das Wlan folgendes gemacht:

Diese Einstellungen bewirken, dass der Mac sich zwar zu dem Wlan verbindet oder es zumindest versucht, allerdings weder eine IPv4 noch IPv6 bekommt. Aber: die Wlan Funktion bleibt aktiviert. Mit diesem “Hack” wird dauerhaft nur die Ethernet-Verbindung verwendet, aber ich habe trotzdem die Vorzüge von Airdrop und Apple-Watch Entsperrung 👌

Übrigens: sobald man Netzwerkumgebungen angelegt hat, kann man diese über einen neuen Menüpunkt im “Apfelmenü” schnell umschalten:

 

Jetzt muss ich nur noch etwas Zeit finden, damit ich per Automator-Script erkenne, ob der Ethernet-Adapter verwendet wird oder nicht und dementsprechend die Umgebung automatisch umschalte…

Telegraf kann SNMP Daten vom Ubiquiti Edge Router Max nur teilweise abrufen

Aktuell versuche ich per Telegraf über das SNMP Protokoll die Daten meines Routers abzugreifen und diese in eine InfluxDB zu packen, damit ich die Daten dann in Grafana überwachen kann. Soweit klappt das auch, aber sobald ich meine Glasfaser mal ausnutze und mit vollen 250Mbit einen Download laufen habe, dann setzt Telegraf mit solchen Meldungen aus:

E! Error in plugin [inputs.snmp]: agent ---: gathering table ifXTable: performing bulk walk for field ifAlias: Request timeout (after 4 retries)

Sprich, er bekommt Timeouts beim Abrufen der Daten. Nach langem hin und her sieht es wohl so aus, als ob der Parameter “max_repetitions = 50” das Problem verursacht. Stellt man diesen auf 20 oder nur 15, dann gehen die Fehler auf einmal weg und man kann auch in kürzeren Intervalen Abfragen tätigen.

Meine Config sieht aktuell so aus:


[[inputs.snmp]]
# List of agents to poll
agents = [ "IP_DES_SNMP_SERVERS" ]
# Polling interval
interval = "60s"
# Timeout for each SNMP query.
timeout = "10s"
# Number of retries to attempt within timeout.
retries = 5
# SNMP version, values can be 1, 2, or 3
version = 2
# SNMP community string.
community = "global"
# The GETBULK max-repetitions parameter
max_repetitions = 15
...

Die ganze Config, mit der man einen Ubiquiti Edge Router auslesen kann, findest du hier: https://grafana.com/grafana/dashboards/1756 unter “Collector Configuration Details”.

Wie man sich in Whatsapp selber schreiben kann und das Ganze als Datenaustausch nutzt

“Warum sollte man das wollen?” dachte ich mir auch, als ich diese Funktion das erste mal im Chatprogramm Slack gesehen hatte. Aber wenn man etwas drüber nachdenkt, ist es gar nicht so blöd. Man kann sich über mehrere Geräte hinweg relativ einfach Notizen schreiben oder Dateien austauschen, und man kann auch einfach Dinge wie Formatierungen, Emoticons usw. ausprobieren bevor man sie jemand anderem schickt.

In Whatsapp geht das so erstmal nicht, man kann sich aber eines Tricks bedienen. Dazu legt man eine neue Gruppe an, und lädt (zwangsweise) irgendeine Person in diese Gruppe ein. Sobald die Gruppe angelegt ist, schmeißt man diese Person wieder aus der Gruppe heraus und ist ab diesem Moment alleine in der Gruppe. Und das war es schon – das ist nun euer Chat, in dem ihr euch selbst schreiben könnt bzw. den nur ihr sehen könnt.

Wenn man nun noch https://web.whatsapp.com verwendet, dann kann man so relativ leicht auch Daten zwischen mehreren Computern austauschen – und das ohne irgendeine Software auf den entsprechenden Rechnern zu installieren. Einfach im Browser die Adresse aufrufen, einmalig mit der Whatsapp App auf dem Handy den QR-Code Scannen und schon kann man auf diesem Rechner Whatsapp nutzen und somit auch in die eben angelegte Gruppe schreiben sowie Dateien hochladen.

PS: Wenn ihr das Ganze nutzt um Bilder zu versenden, dann beachtet bitte, dass Whatsapp die Bilder die ihr sendet verkleinert. Wollt ihr originale versenden, dann müsst ihr z.B. zip Dateien verwenden.

Cyberpunk 2077 Glitch: Takemura ruft an

Nach meinem anfänglichen Reinfall mit der Xbox Version von Cyberpunk 2077 und dem anschließenden Umstieg auf einen richtigen Gaming PC zocke ich das Spiel nun sehr gerne. Bisher wurde ich von heftigen Bugs verschont, aber nun hat es mich getroffen.

Und zwar geht es um die Mission „Down the Road“, bei der wir auf einen Anruf von Takemura warten. Sein Anruf kam bei mir direkt nach einer anderen Mission, allerdings wurde er automatisch angenommen und dann passierte: nichts. Takemura starte mich die ganze Zeit an (siehe Screenshot), aber sagte keinen Ton. Für das Spiel war die ganze Zeit das Telefonat aktiv, sodass man nicht speichern konnte, das Handy konnte nicht verwendet werden und so einige andere dinge waren gesperrt. Sprich, das Spiel wurde nahezu unspielbar.

 

 

Nach einer erweiterten Recherche im Netz gab es Hinweise, dass man ein Savegame möglichst weit vor diesem Event laden sollte und dann eben nochmal spielen sollte, in der Hoffnung, dass der Bug nicht nochmal auftritt. Aber mehrere Stunden Spiel zu wiederholen um dann trotzdem das Risiko zu haben, dass der Fehler erneut passiert? Da hatte ich keine Lust drauf 😂

Irgendwann habe ich dann einen workaround gefunden: man muss mehrere Nebenmissionen durchführen, bis scheinbar irgendwann eine dabei ist, bei der auch jemand anruft. So richtig hab ich es auch nicht herausgefunden. Es bietet sich wohl an in der Wüste im östlichen Teil der Karte daran zu arbeiten.

Jedenfalls habe ich dort mehrere Nebenmissionen gemacht und irgendwann auch Panam besucht und siehe da – genau als ich sie ansprach verschwand Takemura auf einmal und das Spiel war wieder bedienbar. Das ist der ungefähre Weg aus diesem Problem, so ähnlich hatte es der Typ auch beschrieben, bei dem ich diese Lösung gefunden habe. Ich hoffe es hilft weiteren Leuten 🙂

Und bevor jemand mit Patches usw kommt: das Ganze passierte bei mir auf Patch 1.1, also der aktuellsten Version 🤷🏻‍♂️

Wie man die komplette Wikipedia auf einen Raspberry Pi bekommt

Für Gegenden mit schlechter Internetanbindung oder aber für den Katastrophenfall wäre es doch ganz nett, wenn man die komplette Wikipedia offline auf einem kleinen Raspberry Pi vorhalten könnte. Mittels der Kiwix Software ist dies möglich.

Und so setzt du das Ganze auf:

Lade dir unter

https://download.kiwix.org/release/kiwix-tools/

das entsprechende tar herunter – für Raspberry Pi wäre das dann aktuell

kiwix-tools_linux-armhf-3.1.2-4.tar.gz

und entpacke das Ganze in einen beliebigen Ordner auf dem Raspberry Pi.

Unter

https://wiki.kiwix.org/wiki/Content_in_all_languages

findest du die offline Dumps der jeweiligen Wikipedia Sprachen in unterschiedlichsten Varianten. Die (englische) Erklärung zu den Varianten (min, max, usw.) findest du hier: https://download.kiwix.org/zim/README

Für die meisten Leute dürften folgende Links relevant sein (und auf eine 128gb Karte inkl. Betriebssystem passen):

Wikipedia Deutsch (komplett)

Wikipedia Englisch (ohne Bilder)

Neben diesen kompletten Dumps gibt es auch die Möglichkeit, nur einzelne Unterbereiche/Themenbereiche der jeweiligen Sprache zu laden. Man kann beliebig viele Pakete laden und auf den Raspberry Pi werfen, die Kiwix Software macht dann alles zusammen verfügbar.

Leg die heruntergeladenen zim Dateien in einen beliebigen Ordner auf dem Raspberry Pi.

Anschließend legst du eine systemd Startdatei für den Kiwix Server unter

/etc/systemd/system/kiwix.service

mit folgendem Inhalt an:

[Unit]
Description=kiwix

[Service]
User=kiwix
Group=kiwix
ExecStart=/[PFAD_ZUM_ENTPACKTEN_TAR]/kiwix-serve -p 8080 /[PFAD_ZU_DEN_HERUNTERGELADENEN_ZIM_DATEIEN]/wikipedia_de_all_maxi.zim /[PFAD_ZU_DEN_HERUNTERGELADENEN_ZIM_DATEIEN]/wikipedia_en_all_nopic.zim
Restart=on-failure
RestartSec=30s
TimeoutSec=30s

[Install]
WantedBy=multi-user.target

Und schließlich aktivierst du den neu erstellten Service noch:

systemctl daemon-reload
systemctl enable kiwix.service
systemctl start kiwix.service

Damit wird der Server so eingerichtet, dass er jedes mal automatisch startet, sobald der Raspberry Pi gestartet wird.

Im Anschluss kannst du unter der IP des Raspberry Pi auf Port 8080 bzw. auf ihm selbst mit http://127.0.0.1:8080 auf die Wikipedia zugreifen – und das völlig offline.

Um die Daten auf den neuesten Stand zu bringen reicht es, einfach die neuen zim Dateien zu laden und den Server einmal neu zu starten.

Docker meldet Chain DOCKER does not exist

Wenn docker beim Starten neuer Container die Meldung

Chain 'DOCKER' does not exist

ausgibt, dann bedeutet dies, dass für Docker keine IP-Talbes rules hinterlegt sind. Vermutlich kann das passieren, wenn man mit docker system prune aufräumt, so richtig sicher bin ich da aber auch nicht.

Falls der Fehler bei dir auch auftritt, kannst du ihn mit folgenden 3 Commands mittles root Permission auf dem entsprechenden Server lösen:


iptables -t nat -N DOCKER
iptables -t nat -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
iptables -t nat -A PREROUTING -m addrtype --dst-type LOCAL ! --dst 127.0.0.0/8 -j DOCKER