Beiträge von Borgqueen

Zitat von hoedlmoser

da sind multiple versionen drinnen, deshalb wird da der output recht groß, sorry, das hatte ich nicht bedacht.

temurin-17-jdk stellt aber nur java-* zur verfügung, leider hängt jitsi von openjdk-* ab. also da ergibt sich kein match.

korrekt, genau so!

Wenn ich die Debian 13 sources.list mit den source.list Einträgen der von Debian 12 zusätzlich erweitere, muss ich dann die temurin Pakete wieder deinstallieren bevor ich nach einem vorsorglichen reboot des Server erneut versuche Jitsi bzw. nur die videobridge mit den korrekten Dateien durch Nach- bzw. Neuinstallation von Jitsi zu versorgen?

Denn nachdem was Du über jdk von temurin aufgeklärt hattest, müsste in meinem Fall die installierten jdk temurin Paket nun obsolet sein.

Zitat von hoedlmoser

ich wiederhole mich, man nehme einfach ein Debian 13 mit zusätzlich den Debian 12 apt sourcen (der zustand ergibt sich übrigens zu einem bestimmten zeitpunkt bei jedem Debian upgrade!). dann sieht das so aus, alles aufgelöst und verfügbar. keine fremdpakete, keine fremd-repos und keine handstände.

Da ich es nicht ganz verstehe, muss ich nun wirklich Mal sehr naiv nachfragen. Meinst Du ich muss unter Debian 13 in der

/etc/apt/sources.list

zusätzlich von Debian 12

deb http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
deb-src http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware

deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
deb-src http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware

# bookworm-updates, to get updates before a point release is made;
# see https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports
deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware
deb-src http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware

hinzufügen?

Zitat von hoedlmoser

also wenn temurin kein provides für openjdk-17-jre liefert können die abhängigkeiten von jitsi nie aufgelöst werden!

was leifert denn

Code

apt-cache show temurin-17-jdk | grep Provides

Ohh Gott, es liefert als Ergebnis mehr als 10.000 zulässige Zeichen pro Beitrag.
Ich hatte versucht das Ergebnis per Code las Spoiler zu posten.

Somit verbleibt von den Jitsi Lösungen nur noch Docker.

Da kann ich mich nun Mal (bis dato keine Kenntnisse mit Docker) auf die Suche machen nach einer Anleitung wie ich unter Debian 13 Jitsi in Kombination micht Apache2 unter Docker zum laufen bringe.

Denn nach 25 Jahre Jahre Apache tue ich mir (so lange ich Apache verwenden kann) nginx nicht an.

Ich hatte vor 1 oder 2 Jahren Mal versucht von Apache auf nginx zu wechseln. Nachdem mehreres nicht lief verwendete ich sehr gerne wieder meinen geliebten Apache.

Zitat von TobiasH

Schade, dann reicht diese Lösung wohl nicht.

Warum werden da eigentlich noch openjdk Pakete von Version 11 benötigt? Es gibt zwar auch temurin-11-jdk, aber das wird bei dem fehlenden Paket auch nicht helfen.

(Man könnte mit bastelei ein Dummy-Paket "openjdk-11-jre-headless" mit equivs erstellen, dann würde es sich installieren lassen, aber ob die Videobridge dann läuft....)

Aktuell kann ich bei Jitsi (wenn es nicht verbindet) wohl nichts kaputt machen. Daher habe

apt install temurin-17-jdk
apt install temurin-8-jdk

zusätzlich installiert und die Jitsi-Dienste + den Apache restartet um zu sehen was passiert.

Die 8er und 17er Versionen wurden ohne Fehlermeldungen installiert. Und die Videobridge hat nach wie vor das selbe zu nörgel was ihr fehlt um fehlerfrei zu laufen.

Ich verstehe nicht warum die Entwickler von Jitsi bei openjdk so hinterher hinken.

Nun habe ich das empfohlene Repository installiert und auch wie beim Link erwähnt das

apt install temurin-17-jdk

Danach Jitsi installiert. Dieses Mal erschienen keine Fehlermeldungen und es generierte mit auch unter site-avible/ die conf Datei der vhost für Jitsi.

Als ich danach bei Jitsi Url aufrief erschien die Seite ohne Fehler.

Jedoch als ich mit (Kamera und Mikro eingeschaltet einen Chat-Room erstellen wollte erschien folgende Fehlermeldung (siehe Screenshot).

jitsi-verbindungsfehler-20260126.png

Dann testete ich woran es liegen konnte und fand folgendes heraus

sudo apt-get -y install jitsi-videobridge
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Auflösen von Abhängigkeiten… Fehler!
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 jitsi-videobridge : Hängt ab von (vorher): openjdk-8-jre-headless ist aber nicht installierbar oder
                                             openjdk-11-jre-headless ist aber nicht installierbar
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.
E: The following information from --solver 3.0 may provide additional context:
   Unable to satisfy dependencies. Reached two conflicting decisions:
   1. jitsi-videobridge:amd64=1126-1 is selected for install
   2. jitsi-videobridge:amd64=1126-1 Hängt ab von (vorher) openjdk-8-jre-headless | openjdk-11-jre-headless
      but none of the choices are installable:
      [no choices]

Nun gibt es weitere (noch ältere File die Jitsi möchte und nicht bekommt.

Irgendwie fühle ich mich aktuell total verzweifelt.

Es fing so schon an als es mir Jitsi ohne Fehlermeldungen installierte und dann bekomme ich Verbindungsfehler weil die videobridge nicht alles bekam was sie gerne hätte.

Zitat von Patrick0815

Sind vertrauenswürdig: https://de.wikipedia.org/wiki/Adoptium

Danke für die Info

Auch wenn ich seit Debian 11 Debian verwende, hatte ich bis dato keine zusätzlichen Repository, außer jenen die es mir bei Installationen wie z.B. bei Signal Messenger (bei Rechner zu Hause) dann automatisch hinzugefügt wurden.

In den 18 Jahren in denen ich Red Hat basierende Distributionen verwendete da nutzte ich Repository wie. Z. B. Epel und Mock.

Zitat von TobiasH

Borgqueen , kann es sein, das du mein Beitrag übersehen hast?

Dann sollte sich

erledigt haben und man bekommt auch Sicherheitsupdates via apt.

Oh ja, es hatte sich mit meinem letzten Beitrag überschnitten und ich hatte nicht mehr aktualisiert da ich ein Telefonat entgegen nahm welches länger ging.

Und dieses Adoption antfafactoriy (aus dem Link von Dir) ist vertrauenswürdig? Ich frage weil ich es bis dato nicht kenne.

Ich war gerade nochmals am googeln. Die müsste nun das richte Paket sein

https://packages.debian.org/bookworm/amd64/openjdk-17-jre/download

um es als OldStable unter Debian 13 zu installieren und in Abfolge dann Jitsi installieren. Denn dieses Mal habe ich das Paket bei Debian direkt gefunden.

Zitat von -Manu-

Die pragmatische Lösung wäre, zunächst auf Debian 12 zu bleiben. Das wird ja noch bis 10.06.2026 supported....und danach noch LTS bis Juni 2028.

Wenn das Ding nur für Jitsi ist, zeitgleich Debian 12 noch eine Weile bis EOL hat....warum dann upgraden, wenn Jitsi hier (noch) Probleme macht?

Es macht doch alles, was es soll....und ist supported in Bezug auf Sicherheitspatches.

Ich würde das entspannt solange aussitzen, bis Jitsi das geregelt hat....scheint ja logischerweise sehr viele zu betreffen.

Ich bin mittlerweile mit 11 von 13 Rechner (4 davon im RZ) zwischen November und heute komplett auf Debian 13 (Neuinstallationen) umgestiegen und die 2 verblieben Rechner sind ältere Books (werde ich auch noch auf Debian 13 umstellen) auf denen ich kein Jitsi laufen lassen kann.

Ich verwende seitdem Debian 11 Bullseye herauskam Debian. Hatte bis dato noch nicht so ein Problem wie ich es aktuell mit Jitsi erlebe.

Zitat von hoedlmoser

das ist kein hexenwerk. und man lernt mit der herausforderung.

Das schreibst Du so locker vom Hocker.

Mein Autismus ist not amused, wenn durch Herausforderungen Routinen sollen angepasst/umgestellt werden.

Zitat von hoedlmoser

welche genau, ich hab hier beim upgrade von Debian 12 auf 13 keine festellen können.

Ich hatte mir auf der Seite von Sun/Oracle das .den Paket für jre-17 gedownloadet und installiert.

In Folge Jitsi installiert. Und während man im Schnellgang so gut man es mitbekam mitlesen könnte, während Jitsi seine Komponenten installierte taichte Mal was auf was ignoriert wurde.

Als Jitsi installiert war, war zwar das Jitsi und prosody Verzeichnis installiert. Auch das Verzeichnis unter /User/share.

Aber unter site-avible legte es mir nicht die von der vhost Datei an.

Als Folge hattte ich dann jre-17 und Jitsi wieder komplett auf dem Server deinstalliert.

Zitat von tab

Das sehe ich auch als die relativ beste Lösung an, auch wenn ich Docker bisher eher meide. Jedenfalls, aus meiner Sicht bastelst du dir ansonsten einen BBB-Server-Only. Also einen Server, der außer BBB besser nichts am Laufen hat.

Irgendwo meine ich gelesen zu haben, dass deine Meetings nicht mehr so viele Teilnehmer haben wie früher. Und genau das, was Olivetti da schreibt ist auch meine Überlegung.

Ich wollte seit der Corona-Zeit auch unbedingt eine Videokonferenz-Software selbst hosten auf einem Root-Server. Bin dann aber wieder davon abgekommen, weil ich das eher noch seltener benutzen würde und es einen Server blockieren würde, bei dem ich mir zudem noch Sorgen um die Ressourcen, und die Sicherheit machen müsste.

Nachdem ich mittlerweile zur (pflegeleichten) Verbesserung der Mail-Zustellbarkeit für einige Absenderadressen (ca 10, bis zu 50 wären wohl möglich) sowieso Mailbox.org nutze für 30,-€ jährlich, nutze ich für die gelegentlichen Videokonferenzen eben das OpenTalk dort, das im Tarif sowieso enthalten ist. Sollen die das dort ruhig vorhalten und pflegen. Ich glaube bis zu 10 Teilnehmer wären da möglich.

Was Jitsi betraf, so war dies bedingt Corona der Hauptgrund wieso ich anfing mir Server in Rechenzentren anzumieten. Für mich und auch für Vereine in denen ich einst Mal tätig war. Werde dieses Jahr 60 Jahre alt und habe vor 4 Jahren begonnen ehrenamtlich und bei Vereine step by step kürzer zu treten. Das sollen jüngere m. M. n. jüngere machen.

Bei Server im RZ bleibe ich. Denn ich habe ja auch meine CMS, Clouds, Mattermost etc. am laufen.

Was die Sicherheit von Jitsi betraf, hatte ich mich intensiv damit beschäftigt und sehr früh begonnen meine Jitsi-Server nicht als offenen Jitsi-Server laufen zu lassen. Denn ich konfigurierte Jitsi bei mir so, dass man für Jitsi einen Zugang haben musste um Chat-Räumne zu eröffnen.

Bedingt der vielen Zeit die ich in Konfiguartion von Jitsi steckte würde ich am liebsten Jitsi, wenn möglich bald wieder weiter verwenden.
Docker mir graut es davor. Weil neu / alles fremd.

Diese jährlich für 30,-- € Lösung mit OpenTalk wäre, wenn Jitsi weiter bei mir scheitert eine Alternative.

Zitat von hoedlmoser

dann lass einfach die debian 12 sourcen noch drinnen. dann nimmt er das "veraltete" openjdk aus dem bookworm repo. der rest rennt auf trixie.

Das war nach zuvor googeln meine erste Lösung die ich am Samstag versuchte und scheiterte damit bei der Installation.
Denn es installierte mir zwar Jitsi. Jedoch lietste es während der Installation Fehler auf.
Bedingt dessen hatte ich Jitsi wieder deinstalliert und erstellte in Folge diesen Thread im Forum.

Zitat von hoedlmoser

übrigens, jitsi gäbe es auch in einem docker container, da müßtest Dich um solche abhängigkeiten gar nicht kümmern.

Das wäre die letzte Hoffnung die mir verbleibt.

Bis dato habe ich nur eine Anwendung die mit Docker im Hintergrund für Nextcloud läuft.

Und dies war eine Docker Kommandozeile die ich eingeben musste und es läuft.

Fakt ist leider, ich kenne mich mit Docker nicht aus.

Zitat von Homwer

Wenn dich Debian 12 am Jitsi stört, dann ist BBB KEINE Alternative. Das hätte gerne Ubuntu 22....

Bei mir gibt es 2 Grundsätze:

• nur mit Debian
• nur mit Apache2

Zitat von Homwer

Ich verwende einfach Debian 12, bis es eine Lösung für 13 gibt.

Diese Gedanken kreisen (seitdem ich lesen musste dass BBB nur auf Ubuntu aufbaut) ebenso in Kopf.

Hallo Jupp74,

lässt sich BigBlueButton auch mit Apache installieren an Stelle von nginx?

Zitat von Jupp74

Hier noch die CPU-Load und die CPU-Auslastung während eines Meetings mit 4 Teilnehmern und 4 aktiven Kameras vom Freitag Abend...

Spoiler anzeigen

BBB_load.png

BBB_cpu_usage.png

Danke, sehr interessant.

Laut Daten

müssten meine zwei RS 1000 G12 Ultra NUE BW25 etwas mehr Power als Dein VPS 1000 haben.

Dann könnte ich es durchaus wagen BigBlueButton Mal zu installieren. Größere Meetings habe ich eh noch selten. Zu Zeiten als ich mit Jitsi (vor 5 Jahre) anfing und ehrenamtlich noch engagiert war, waren die Meetings, insbesondere während Corona noch größer was die Anzahl der Teilnehmer betraf.

Zitat von Jupp74

Ich habe BigBlueButton hier auf einem VPS 1000 laufen. Wri machen reglmäßig Konferenzen mit 4 Teilnehmern und vier aktiven Kameras. Das funktioniert gut.

Wie viele Teilnehmer der Server verkraftet und bei wie vielen Kameras er aussteigt, kann ich nicht sagen...

Danke für die Info.

Hallo Olivetti,

Danke für den Link.

So wie ich auf die schnelle gelesen habe ist Opentalk sehr kostenspielig wenn man länger als 30 Minuten Videokonferenz abhalten möchte.

Und in wie weit man das selbst hosten kann muss ich in Ruhe Mal durchlesen. Wenn ich es gefunden habe.

Heute Abend surfe ich eh nur mit meinem Mäusekino. Muss Mal demnächst alles zu Opentalk am Schreibtisch am Monitor durchlesen.

Generell sind ISP froh wenn sie genügend Glasfaser Anschlüsse bekommen.

Wenn ich (wenn auch nicht nett) zu so Maßnahmen greifen müsste wiee Peering, dann würde ich es bei DSL Anschlüsse verwenden und nicht bei Glasfaser.

Noch dazu ist seit Jahrzehnte bekannt, dass gerade beim Durchschnitt von Kupferkabel-Kabel, bei je mehr Kunden am Netz in einem Gebiet die Leistung herunter geht.

Ich verwende kein Cloudflare!