07:54 <andi-> Florian[m]: Prometheus alerted auf Basis der Werte. Also bspw. Netzwerkdurchsatz in der letzten Minute kleiner 1Mbit/s UND ein systemd Service ist gestorben.

07:55 <andi-> Du beziehst dich immer auf Zeitfenster und beschreibst damit deine Regeln. Nur weil ein ICMP Paket verloren ist gibt es nicht gleich einen Alarm

12:29 <musicmatze> Guten Tag. Kann mir jemand erklären wie ich nginx als reverse-proxy nutze um verschiedene services zu reverse-proxen? Ich hab keine Ahnung von netzwerkkram und so und bräuchte eine stepbystep anleitung

12:29 <musicmatze> Idee ist das ich unter "serviceA.mydomain.tld" einen service hab und unter "serviceB.mydomain.tld" und so weiter

12:32 <Florian[m]> musicmatze: was für services so?

12:33 <musicmatze> mastodon, matrix, riot, writefreely (wenn ichs gepackaged bekomme), ttrs, taskserver, ipfs, gitolite, nextcloud, ... evtl weitere

12:35 <Florian[m]> dann ist meine Anleitung für Matrix und Riot mit Nginx davor n guter Startpunkt: https://nixos.org/nixos/manual/index.html#module-services-matrix

12:36 <musicmatze> :-) den hab ich benutzt :-)

12:36 <musicmatze> s/den/die/

12:36 <musicmatze> aber verstehen tu ich nicht alles ... vielleicht nochmal konzentriert drüber lesen

12:40 <Florian[m]> grundsätzlich funktioniert das alles so, dass du dir für jeden Dienst einen virtualHost definierst, wichtig ist es gibt 3 Kategorien von Diensten: A) Statische Dateien serven, z.B. Riot, da macht nginx die ganze Arbeit, B) Dynamische Dateien (z.B. PHP-Zeugs), da leitet nginx dann Anfragen wie `musicmatze.de/index.php` an einen PHP-Ausführungsdings wie php-fpm weiter, z.B. Nextcloud so wie das NixOS-Modul funktioniert

12:40 <Florian[m]> und C) Dienste die ihren eigenen vollständigen Webserver mitbringen, der dann auf einem privaten Port horcht und an den Ngnix alles nur durchreicht, z.B. Matrix-Synapse.

12:41 <Florian[m]> alles was in je eine Kategorie fällt konfiguriert sich sehr ähnlich, übrigens nur Kategorie C ist das was man tatsächlich „Reverse Proxy“ nennen würde.

12:41 <musicmatze> aha, danke! .. also muss ich jetzt mal gucken für was ich was brauch

12:42 <musicmatze> bei gitolite brauch ich denke ich nichts davon, weil das ja über ssh angesprochen wird

12:42 <musicmatze> und ein git-frontend will ich glaub ich nicht

12:42 <musicmatze> wenn ich mal sourcehut laufen lass ist dass dann ja was anderes

12:47 <Florian[m]> gitolite funktioniert ohne webfrontend? cool, was kann das dann, so im Vergleich zu nem raw repository was über ssh in ner Ecke liegt?

12:56 <Florian[m]> der Rest ist Konfig-Kleinklein, den man natürlich auch braucht damit alles funktioniert, aber hier ist die eigentliche Verteillogik.

12:59 <musicmatze> Florian: gitolite ist ein repository-manager. Du hast ein repo wo config und ssh keys drin liegen und die pushst du zu gitolite. Dieses legt automatisch repositories dann an für dich. Ausserdem hat gitolite so ziemlich das beste permission-management überhaupt was git hosting angeht. So geschichten wie "diese user dürfen nur auf diesen branch pushen" oder es gibt glaub auch "Diese user dürfen nur pushen wenn die

12:59 <musicmatze> änderungen in diesen subdirectories vom repository sind" und so

13:00 <musicmatze> vielen Dank!

13:33 <Florian[m]> nice, das muss ich mir dann mal anschauen, ich hab aktuell n gitea am laufen aber eigentlich brauch ich garkein webinterface wenn das eh nur ich mach oder andere Leute die git&ssh können. Ich hab tatsächlich bis jetzt immer gedacht gitolite == gitweb

13:47 <musicmatze> ne, gitolite != gitweb

13:47 <musicmatze> und gitolite is wahnsinnig geil

13:47 <musicmatze> man kann natürlich auch ein frontend dazu schalten (wie ich zum Beispiel auf git.imag-pim.org gemacht hab mit cgit - im Hintergrund läuft aber ein gitolite das die auth macht)

13:49 <Florian[m]> ah, das erklärt meine Konfusion.

22:14 <Ox4A6F> Ja, hab auch gitolite gerne.