Beiträge von Paul

Prima, freut mich zu hören

Zitat von Bud

Sollte ich statt http:// nicht lieber https:// in die Conf schreiben?

Nein, das ist schon ok. Das ist ja nur das Protokoll ins "Backend", sprich die Verbindung von Apache zu dem Node Webserver. Die läuft unverschlüsselt. Ist aber ok, ist ja derselbe Server. Die Verbindung zum User ist ja dann https. Daher passt das schon. Sonst müsste dein Wikijs selbst auch nochmal SSL terminieren. Wäre technisch möglich, wäre in diesem Fall aber unnötig.

Die Reihenfolge ist in diesem Fall egal, da brauchst du dir keine Gedanken machen.

Achso. Ja, wenn du dein Wiki über https erreichen willst, musst du dafür natürlich auch einen vHost mit Port 443 konfigurieren (analog zu 80). In diesem wird dann aber auch der Pfad zum SSL Zertifikat benötigt. Ich dachte, dir geht es erst einmal nur um die generelle Erreichbarkeit über Port 80. Aber moderne Browser gehen mittlerweile ja direkt auf https, sobald das der Server unterstützt. Daher bekommst du in diesem wohl auch die Apache Status Seite. Hast du denn bereits ein Zertifikat erfolgreich beantragt? Denn ohne kannst du den Port 443 vHost nicht konfigurieren.

Ich würde aber als erstes mal mit curl die Seite auf der Shell aufrufen und schauen, was da zurück kommt, zumindest um dein reverse proxy Setup zu verifizieren.

Super. Das ist doch schon mal gut. Die Datei wird also geladen. Die Reihenfolge spielt bei den Ports keine Rolle. Wenn du auf Port 80 zugreifst, dann sollte der vHost auch geladen werden. Die wird in der Ausgabe nur alphabetisch anhand des Dateinamens angezeigt.

Zitat von Bud

Leider funktioniert mein Reverse Proxy mit Apache nicht.

Was passiert denn, wenn du die Seite aufrufst? Was genau funktioniert denn nicht?

Zitat von Bud

In /etc/apache2/sites-available/

Code: apache2 -t -D DUMP_VHOSTS

bud@netcup:~$ sudo apache2 -t -D DUMP_VHOSTS
[Tue Sep 12 10:29:52.120864 2023] [core:warn] [pid 1443791] AH00111: Config variable ${APACHE_RUN_DIR} is not defined
apache2: Syntax error on line 80 of /etc/apache2/apache2.conf: DefaultRuntimeDir must be a valid directory, absolute or relative to ServerRoot

DefaultRuntimeDir ist ${APACHE_RUN_DIR}

In /etc/apache2/envvars habe ich dazu folgendes gefunden:

Code

export APACHE_RUN_DIR=/var/run/apache2$SUFFIX

Und daraus werde ich dann spätestens nicht mehr schlau...

Edit: Ich verstehe nicht, warum mein Apache bei dem Fehler problemlos läuft. Das macht doch keinen Sinn, oder?

Ich vermute, Apache liest die /etc/apache/envvars nur, wenn du den apache2ctl Befehl ausführst. Könnte sein, dass apache2 selbst das gar nicht berücksichtigt (nur ein Schuss ins Blaue). Kannst du die gleichen Befehle mal mit apache2ctl ausführen?

Ich habe in meiner apache2.conf "DefaultRuntimeDir" gar nicht explizit gesetzt. Evtl. ging es daher bei mir.

Zitat von Bud

Ich bin mir leider auch nicht sicher, wo ich auf der Suche ansetzten soll. Wie finde ich heraus, ob die Datei example.com.conf überhaupt beachtet wird?

Wo hast du die Datei denn abgelegt?

Es gibt hier ein paar Befehle, die dir beim Debugging hilfreich sein könnten:

apache2 -t -D DUMP_VHOSTS

und

apache2 -t -D DUMP_INCLUDES

Falls es dort nicht auftaucht, stimmen evtl. die Berechtigungen der Datei nicht oder sie ist an der falschen Stelle abgelegt worden.

Ist das ein Port, den Docker verwaltet? Das erklärt dann auch, warum firewalld den nicht blockt. Docker schreibt ja seine eigenen iptables/nftables Regeln und "überschreibt" deine vorkonfigurierten Regeln. Am einfachsten kannst du das umgehen, wenn du die bind ip einfach auf 127.0.0.1 setzt. Statt "-p 51820:51820/udp" kannst du "-p 127.0.0.1:51820/51820/udp" verwenden. Dann ist der Port generell nicht von außen erreichbar (unabhängig der eingesetzten Firewall). Alternativ kann in Docker auch statt einer bridge das host network ausgewählt werden. In diesem Fall greifen dann auch wieder deine normalen Firewall Regeln.

Zitat von mainziman

eine Gesichte gibt es - der Grund - wieso Lets Encrypt SSL-Zertifikate nur 90 Tage/3 Monate gültig sind:

sollte ein Server gehackt werden und daraus beides - public und private Key - entwendet werden,

dann können diese im Worst-case nur 90 Tage f. Mißbrauch verwendet werden.

Das ist ein Argument, das ich nie nachvollziehen konnte. Wenn der Key weg ist, ist er weg. 90 Tage lange "Unfug" betreiben, ist eigentlich schlimm genug. Dann wäre es auch egal, wenn das Zertifikat 180 Tage oder 360 Tage lang gültig wäre. In 90 Tagen kann so viel passieren, das ist nun echt kein Sicherheitsgewinn mehr, wenn nach 90 Tagen das Zertifikat abläuft. Das gleiche Argument habe ich auch schon nie beim Passwort-Wechsel verstanden. Wenn jemand mit einem Admin Passwort in einer Firma sich 90 Tage lang austoben kann, bringt der Wechsel nach 90 Tagen eigentlich auch nichts mehr. Dann ist so viel Schaden entstanden, dass hier sowieso alles neu gemacht werden muss.

Da muss ich gerade an Gitlab denken, die ebenfalls mit den letzten Updates eingeführt haben, dass "Personal Access Tokens" nur noch maximal 1 Jahr lang gültig sind. Darüber rege ich mich jetzt noch auf und habe angefangen meine eigene Gitlab Instanz aufzulösen, weil es Szenarien gibt, wo das nun wirklich nicht sinnvoll ist (z.B. bei einem simplen Mirror).

Es mag zwar in deren Umfeld nicht vorkommen, aber es gibt durchaus Admins, die passen auf ihre Keys/Passwörter ganz gut auf.

Zitat von aRaphael

Danke für die Einschätzung.

Aber teste es ruhig selbst auch mal. Gibt sicher auch viele, die das mögen. Man sieht es nur außerhalb es RedHat Ökosystems so gut wie gar nicht, was halt auch irgendwie daran liegt, dass RedHat immer eine eigene Wurst braten muss. Statt Kubernetes müssen sie OpenShift entwerfen. Was zwar irgendwie schon noch Kubernetes ist, auf der anderen Seite aber wieder nicht, weil es eigene CLI Tools hat, eigene Python Extensions, statt einem Ingress kommt hier eine Route zum Einsatz, ...

Ich habe ja beruflich durchaus auch viel damit zu tun. Wenn man nicht 100% in der RedHat Welt leben möchte, ist das mittlerweile echt nervig geworden. Erinnert mittlerweile stark an das Apple Ökosystem. Das funktioniert im Grunde auch nur, wenn man nur die Geräte von Apple verwendet. Aber gerade hier bei uns in der Open Source Community ist man sowas eigentlich nicht gewöhnt.

Zitat von aRaphael

Ist schon jemand auf podman umgestiegen?

Ich hatte es es sogar über ein Jahr produktiv im Einsatz. Bin dann letztendlich aber wieder genervt auf auf Docker umgestiegen. Letztendlich muss man sagen, dass Podman primär für den Desktop / Workstation interessant ist. Auf einem Server macht das wenig Sinn. Ist wirklich nett, wenn schnell mal was lokal testen möchte. Dauerhaft einen Podman Container laufen zu lassen, halte ich für wenig sinnvoll. Dann lieber gleich richtig in die Kubernetes Welt eintauchen und etwas wie microk8s oder k3s einsetzen. Läuft auch mit wenig Ressourcen, hat aber nicht die vielen Nachteile von Podman. Podman ist im Grunde Docker ohne den Daemon. Stattdessen arbeitet man hier mit Systemd Service Files um die Container am Laufen zu halten. Aber gleichzeitig gibt es immer noch die Podman CLI (podman start/stop) mit der man die Container administrieren kann. Wenn dann gleichzeitig der Systemd Service läuft, kommt sich das ständig in die Quere. Podman gibt es im Grunde nur, weil RedHat einen Zickenkrieg gegen Docker geführt hat und dann irgendwas eigenes auf den Markt werfen musste.

Port 80 wirst du für die Letsencrypt HTTP Challenge benötigen (falls du nicht die DNS Challenge verwendest). Daher wirst du den Port schon deshalb kaum komplett zumachen können. Wie hoedlmoser schon erwähnt ist hat hier ein Redirect von von http auf https die gängige Praxis.

Wikijs basiert ja auf NodeJS. Bis vor kurzem war es nicht möglich Wikijs mit NodeJS >=18 zu starten (das haben sie mit dem letzten Update korrigiert). Wenn man vorher ein Debian 12 hatte, konnte man das also nicht mit dem NodejS aus den normalen Debian Repos zum Laufen bekommen (NodeJS 18). Gerade bei solchen Situationen kann es schnell zu einer ziemlichen Bastelei werden, wennn man auf einem Server dann eine andere NodeJS Versionen installieren muss. Hier ist es dann z.B. deutlich angenehmer, wenn man einfach den Container startet, der die entsprechenden Abhängigkeiten selbst mitbringt und den Host an sich "sauber" hält. Gerade Wikijs ist eigentlich ein schönes Beispiel für eine sinnvolle Docker Installation, zumal sich hier die Konfiguration auch wunderbar mit ENV Variablen setzen lässt.

Der RS 1000 SE würde Teil vom Bud -Netz werden um endlich eine Hintertür im Postfix von tab zu finden

Uptime Robot Nutzer hier? Da gibt es wohl demnächst eine Änderungen in dem Free Plan.

Zitat

Hi there!

At UptimeRobot, we're always looking to improve our products, so we introduced new plans. Unfortunately, we had to make some changes to our free plan:

* You will no longer be able to add these integrations: Slack, Telegram, Microsoft Teams, Webhook, Zapier, and PagerDuty.️

* Email & phone alert contacts are limited to just one contact each and only two simultaneous logins to the mobile app. ️

Hab das immer ganz gerne mit der Telegram Notification genutzt. Aber vielleicht ein guter Zeitpunkt für eine Uptime Kuma Migration.

Zitat von Bud

Keine Ahnung wie ich darauf gekommen bin... Aber vielen vielen Dank Paul

Ich bekomme bei der Wiki.js-Installation zwar folgende Fehlermeldung...

EACCES: permission denied, mkdir '/home/sudouser/wikijs/data/cache'

...aber ich meine, ich habe eine mögliche Lösung gefunden. Ich probiere es mal aus und melde mich dann, für den Rest des Abends geb ich euch erstmal frei

Prima! In dem Systemd Service File hast du ja angegeben unter welchem User der Dienst laufen soll (Normalerweise sollte jeder Dienst auch seinen eigenen User und sein eigenes Home Verzeichnis haben - z.B. /var/lib/wikijs - aber das ist ein anderes Thema für später.). Dieser User sollte dann auch der Owner des Verzeichnisses sein, in dem du die Wiki Installation getätigt hast. Vermutlich dürfte daher folgendes schon reichen

sudo chown -R <USER> /home/sudouser/wikijs

Dabei ist <USER> der User, den du in dem Service File angegeben hast (evtl. sogar dein sudouser, was zwar ungünstig wäre, aber technisch zumindest funktioniert). Ggfs. dann noch den "data" Ordner selbst erstellen (mkdir /home/sudouser/wikijs/data). Könnte auch sein, dass er den cache Ordner nicht erstellen kann, weil data schon fehlt.

Ha, da haben wir es doch.

127.0.0.1:3000

Das heißt, der Dienst hört ausschließlich auf 127.0.0.1. Von extern kommst du da also gar nicht drauf. Egal wie deine Firewall konfiguriert ist. Das musst du in der lokalen wikijs config.yml ändern. Standardmäßig sollte das eigentlich auf 0.0.0.0 stehen. Hast du da was geändert? Ansonsten könntest du das mal machen und den Wert "bindIP" entsprechend setzen.

Nachdem du den Dienst mit dem Systemd Service gestartet hast, konntest du dich immer noch nicht lokal (über 127.0.0.1) verbinden? Solang das nicht funktioniert, brauchst du den externen Zugriff gar nicht zu testen. Da müssen wir mal ansetzen. Du bist mir auch immer noch die Ausgabe von "ss -tulpn" schuldig

Sind das vielleicht die ganzen neuen Server von Bud ?

Poste bitte nochmal die Ausagabe des ersten Befehls. Es sieht nämlich eher so aus, als ob dein node server gar nicht mehr läuft. Wenn du den manuell über die Shell startest, musst du die Session natürlich offen lassen, sonst ist mit dem Beenden natürlich auch der node server wieder weg. Um ihn im Hintergrund laufen zu lassen, solltest du noch ein systemd service für wikijs anlegen: https://docs.requarks.io/install/linux (unter run as a service)

Was sagt denn

ss -tulpn

und

ufw status verbose

Geht es denn lokal?

telnet 127.0.0.1 3000

Achso, was natürlich auch noch sein könnte. Hört denn dein PostgreSQL überhaupt auf der IP? Schau mal in der postgresql.conf, was in

listen_addresses

eingetragen ist und passe das ggfs. an in

listen_addresses = '127.0.0.1'