Spontan würder ich eher sagen, dass das die Abnahmeumgebung ist... würde ich mit vorsicht genießen, sowas. 
Mit servercontrolpanel.de fährst du am sichersten - das ist definitiv die Produmgebung.
Beiträge von whoami0501
-
-
Je mehr ich hier über Jitsi lese, desto weniger möchte ich so ein Teil irgendwo administrieren müssen!
(Muss ich zum Glück auch nicht. Und werde ich freiwillig auch nicht machen.)Och naja, man muss erstmal seinen Ekel überwinden, dann geht es eigentlich...
Das Ding hat gefühlt n Eigenleben - wenn man das halbwegs verstanden hat, hat man das Ding auch recht angenehm unter Kontrolle.
-
Falls du die interface_config.js meist: Einfach via nginx ein Alias anlegen und mit nach /etc/jitsi/meet/ schmeißen
Meine ich. Aber chattr tuts jetzt auch...
Betrifft auch noch einige andere Dateien in dem Verzeichnis, von daher.
-
Ok, läuft jetzt wieder. Statt der angesagten 1,5 Stunden hat das mal locker 7,5 Stunden gedauert. Ärgerlich. So was sollte eigentlich halbwegs zuverlässig abschätzbar sein. Auf das eingestellte Support-Ticket hatte ich nach drei Stunden leider auch noch keine Antwort.
Nur mal kurz zum Abschätzen, damit man da nicht evtl. selbst mal reinrennt.
Um welchen Server mit welchen Storage (SAS o. SSD) hat es sich gehandelt?
Wie voll war die Festplatte?
Und speicherst du eher viele kleine Dateien oder wenige große Dateien?
Hattest du gerade vorher Snapshots gelöscht?
EDIT: Tipp fürs nächste mal - vor der Storage Optimierung mal ein fstrim -a machen. Falls du ZFS nutzt, da gibts das auch, heißt bloß anders - kann ich dir bei Bedarf aber raussuchen! Damit tust du Betriebssystemseitig ungenutzte Teile der Festplatte freigeben und wenn du das ausführst, sollte auch die Nutzungsanzeige im SCP wieder stimmen.
-
handelt es sich um Daten im /etc-Verzeichnisbaum?
Jitsi scheint, wenn ein Update per z.B. apt kommt, alle Einstellungen und Änderungen in /usr/share/jitsi-meet/* mit den Standarddateien zu überschreiben.
vlt. ein Designfehler, die Config vom Rest zu trennen; ich mein wenn das die Website ist, und man da in einem HTML, JS od. sonstwas noch etwas konfigurieren kann, dann ist das irgendwie nicht logisch;
Da hast du natürlich wahr - an Jitsi gibt es technisch so einige Designfehler, wenn du micht fragst. Das ist eine .js Datei mit einigen Konfigurationsdirektiven für das Frontend. Hat schon mit der Website zu tun, ist aber trotzdem eine Konfiguration.
Zweifelsfrei ein Designfehler, wie du selbst sagst...
-
Ist da nicht der Paketmanager schuld? Ich weiß nicht wie Debian/Ubuntu das machen aber wenn ich unter openSUSE eine Config bearbeitet hab, legt er die neue Upstream-Config unter program.conf.rpmnew ab. Mit rpmconfigcheck kann man überprüfen, ob es neue Config gibt.
Fedora/RedHat macht das auch so, ist ja wie openSUSE RPM-basiert.
https://www.linux.com/news/dealing-rpmnew-and-rpmsave-files/
Jain. Das ist quasi die "Website" von Jitsi und die wird scheinbar nicht als Config anerkannt, sondern als Anwendungsdaten. Aber da kann man trotzdem noch Dinge einstellen und machen und tun. Das ist das Problem... daher bügelt der da einfach drüber...
Bei Konfigurationen fragt einen apt, aber nicht bei Anwendungsdaten. Ich meine da fragen yum/dnf oder zypper auch nicht. Wäre ja auch irre.
-
Nur als kleiner Hinweis für Jitsi Nutzer:
Jitsi scheint, wenn ein Update per z.B. apt kommt, alle Einstellungen und Änderungen in /usr/share/jitsi-meet/* mit den Standarddateien zu überschreiben.
Backup hat zwar geregelt, aber ich werde meine geänderten Dateien in diesem Verzeichnisjetzt mal mit chattr sichern - hoffe das schützt mich vor weiteren Verlusten.
-
Jemand ne Idee wie ich debuggen kann, wieso ein Request welches von einem NGINX verarbeitet wird reproduzierbar in unregelmäßigen Abständen exakt 3 Sekunden länger dauert als sonst?
Am Backend liegts (scheinbar) nicht, da das verhalten bei einem curl direkt auf die Anwendung nicht eintritt. Es scheint ein Problem vom NGINX zu sein...
Benutzt du den Rate Limiter?
Oder - andere Gedanke, sind nicht geüngend Worker Prozesse da, sodass der Request auf einen freien Slot warten muss? Oder passiert das vielleicht zufällig nur, wenn zeitgleich ein anderer ressourcenintensiver Task läuft?
-
whoami0501 Da gibt es schon offene Issues. Fehlt nur noch, dass einer der Entwickler überhaupt irgendwie drauf reagiert: https://github.com/jitsi/jitsi-meet/issues/582 . Ich denke da kommen zur Zeit die Issues schneller rein, als das da koordiniert abgearbeitet werden kann.
Ja klar. Das ist ja jetzt auch nichts, was man selber nicht fixen könnte. Aber dafür mangelt es ein bisschen an Dokumentation...
Jemand, der das mal manuell aufgebaut hat und sich das mit mir evtl. mal zusammen anschauen würde, wäre für mich daher halt gerade optimal.
-
Dafür gibts doch den Parameter --no-install-recommends
Also, sprich:
Codeapt install --no-install-recommends jitsi-meetMit dem Parameter –no-install-recommends wird das Überschreiben bestehender Serverkonfigurationen bzw. das Korrupieren existierender Serversysteme verhindert.
Das ist bei mir hart in apt konfiguriert (gehört bei mir standardmäßig zum Hardening eines Debian Systems dazu) und ist auch nicht das Problem.
Der macht nichts kaputt, der bringt bloß Standardkonfigurationen mit, bei denen man heulend wegrennen möchte. Der nginx ist bei Jitsi von Haus aus dafür konfiguriert, TLS 1, TLS 1.1 und TLS 1.2 zu nutzen. TLS 1.2 ist ja i.O., aber bei den anderen beiden bekomme ich nen Krampfanfall.
Und auch so gefallen mir die Sicherheitssettings nicht. Mag mir z.B. auch meine SSL certs selbst ziehen, da ich ECDSA statt RSA nutzen mag.
So viel zum Thema Sicherheit auf jeden Fall.
-
Hat jemand von euch mal eine Jitsi Instanz komplett händisch mit der manual install Dokumentation aufgebaut?
Nachdem ich gesehen habe, was das quick-install setup für eine sicherheitsmäßigen Unfall auf dem Server veranstaltet (ich sag nur TLS Einstellungen am nginx), habe ich da absolut kein Vertrauen mehr in den ihren Installer.
Aber die manual install Doku wirkt sehr... lustlos. Wirkt irgendwie sehr unvollständig, hätte da an einigen Stellen viele Fragen.
-
Die Alternative klingt interessant, aber wie mache ich das?
Ich habe aktuell nur die Fritzbox und ein Raspberry-NAS.In dem Fall - nimm diesen Client und pack ihn auf dein RasPi NAS. Ich glaube, das ist das einfachste für dich.
-
Das ist so nicht richtig.
Man kann das ausführen wo immer man möchte. Dabei muss mann allerdings irgendwoher die IP bekommen, die man übermitteln will.
So ein Script führt am ende auch nur ein curl-befehl aus, der dann ist nix anderes als ein "hallo dns server.. schreib mal die IP xyz an die domain foo.bar" macht.. und diese Aufgabe kann von überall erledigt werden. Die frage ist, wie die IP in diesen curl-aufruf reinkommt. und das kann so ein script auch anderweitig bekommen/auslesen. z.b. durch ping eines DHCP-Hosts im LAN.Sinnvoller wäre aber vermutlich mit der haupt-IP zu arbeiten und den suffix anzupassen, statt was im LAN anzupingen. Oder direkt den DHCP zu fragen.
Ja und Nein.
Der Agent, welchen ich nutzte, macht folgendes:
--> curl ipapi.tld<-- eigene öffentliche IP Adresse
--> CCP API - hier ist meine öffentliche IP, setzt die für folgende Domain mit folgender Subdomain
<-- Joa, mach ichIn dem Fall muss man immer das von dem Gerät ausführen, dessen IPv6 man haben mag.
Alternative: An sich sollte man bei IPv6 ja SLAAC nutzen und da kannste dir ja mit der MAC Adresse des entsprechenden Interfaces per EUI64 den Suffix zusammenschrauben. Das verbunden mit dem aktuellen Präfix könnte man dann auch nehmen, da ist das dann richtig. -
Habt ihr eine Idee, ob man mit Anpassungen irgendwie die IPv6 des NAS statt der FitzBox übermitteln kann?
Ah - kenne das Problem, hatte ich auch schon.
Man muss seinen DynDNS "Daemon" bzw. das Updater Script immer von dem Gerät aus ausführen, dessen IPv6 Adresse auch im DynDNS stehen soll. Sprich, du musst das Script direkt auf deinem NAS laufen lassen.
-
Wir haben den Fehler schon gefunden. Layer 8, im Dateinamen hat ein s gefehlt.
Geht halt den Menschen wie den Leuten, kennen wir ja alle...
-
Kann es sein, dass Netcup da gerade Schwierigkeiten hat?
Frag doch einfach mal den Netcup Support. Dafür ist er da.
Wir können hier nur mutmaßen.
-
https://erfurter-fernverkehrs-logistic.de/index.php?rege…-zum-nachlesen/
hier möchte ich dieses "index.php?" raushaben. das ist bei allen angelegten seiten.
Huh, jemand aus der Gegend.
Kumpel schickt mir sein Beispiel morgen.
Habe derweil nochmal selbst geschaut - eigentlich müsste es wie hier beschrieben gehen, probier das mal aus. Wenn du es damit nicht hinbekommst, kannst du mir mal ne PN schreiben.
-
Alles anzeigen
Ich hatte das auch, in ähnlicher Konfiguration kürzlich
Ubuntu mit mailcow-dockerized drauf.
War alles ein bisserl zu klein: 1vCPU. 2GB RAM, 20GB Disk, kein Swap
Irgendwann ging dann garnix mehr, nur reboot hat geholfen.
Da das aber nur ein Testsystem ist und der Server in Kürze abgeschaltet wird, habe ich da nicht weiter dran rumgeschraubt
War alles doch zu klein für mailcow-dockerized und swap sollte auch sein (War aber so vorgegeben (nicht netcup)).
Meine Kuh läuft auf einem VPS Karneval (VPS 500 G8 mit mehr Storage). Zu den 4GB RAM hab ich noch 4 GB Swap dran. Damit gibt es keine Probleme - auch kein rspamd, der sich ewig vermehrt oder sowas.
ctrlF Deine Netzwerkkonfiguration hattest du jetzt komplett statisch gemacht, ja?
-
Das heißt also das mann wohl mit diesem heßlichem "index.php?" leben muß oder wie?
Weil bekomme das einfach nicht raus und das nerft.
So lange du dein Webhosting irgendwie zum Benutzen von Apache2 überredest oder besser gesagt nicht auf nginx only arbeitest, kannst du das meines Wissens per .htaccess file umbiegen.
Ich meine ein Kumpel von mir betreibt das, wenn ich mich recht entsinne, hier in einem Webhosting auch produktiv. Ich frag ihn mal.
-
Meinst du ohne ECC? Ich will das Ding für Proxmox mit ZFS nutzen. Habe gelesen ZFS ohne ECC ist nicht so klug.
Die 32GB ECC Riegel sind billiger als die 2x 16GB ECC Riegel. Ich habe mal die gewählt die offiziell in der Liste vom MB Herstller stehen.
Mein Proxmox hier daheim läuft jetzt seit ein zwei Jahren mit ZFS ohne ECC RAM. Läuft ganz normal. Für irgendwelche hyperkritischen Businessanwendungen würde ichs vielleicht nicht machen, aber hier zuhause mache ich mir da ehrlich gesagt nicht so sehr Gedanken drum...
