Ich habe keine Kunden
danke für die einordnung. klar, als alleiniger nutzer kann ich meinen server beliebig zunageln, drei hürden aufstellen und den rest vermienen. hilft dann auch nur zuhause strom und hardware investitionen zu sparen.
Beiträge von hoedlmoser
-
-
Sobald Tailscale installiert ist, kann man also m.E. den eingehenden SSH Zugang unterbinden
wie kommen Deine kunden zb auf ihr webroot?
-
Also denkt daran, folgendes zu ergänzen, UDP Regeln mit Source Ports für:
heißt aber auch ich kann mit src port 53 alle deine udp services nutzen.
-
skeptisch was die neue Entwicklung betrifft
der beste *nix desktop ist immernoch MacOS <duckundweg/>
-
unterstützt
TIL jigasi, da könnte ich ja per Jitsi mit dem post-lieferanten eine unterhaltung an der türsprechstelle führen.
-
So sehr gehn die Meinungen auseinander...
wir können gern eine stricherliste machen wie oft wer hier wegen mail oder udp aufschlägt.
-
Der Befehl gibt mir nichts auf der Konsole aus
dann installier mal jitsi-videobridge2 nach. ich versteh zwar nicht warum die nicht mitgezogen wird, aber ein versuch ist es wert.
-
Fehlermeldung
nachdem Du ja immer die videobridge in verdacht hattest, ist die eh installiert?
Codeapt-cache policy jitsi-videobridge2 | grep Installedund Du hast auch alle ports offen, die jitsi benötigt? https://jitsi.github.io/handbook/docs/…e-your-firewall
-
oida, ernsthaft, die policies kann man nur hinzufügen/entfernen wenn man die firewall aktiviert hat? von dem unsinn ausgehend standardmäßig smtps und submission zu blockieren will ich erst gar nicht reden. ich bin da raus. sowas will man nicht verwenden!
-
Es ist ja nicht das erste Mal dass ich Jitsi installierte.
hör auf herumzuschwurbeln! zeig das kommando mit dem Du jitsi installiert hast. zeige bitte zusätzlich die entsprechenden apt sources für jitsi. nochmal, eine reguläre installation von jitsi-meet zieht die jitsi-videobridge2 mit und die hängt von openjdk-17-jre-headless ab welches es in Debian 12 gibt.
-
begann ich erneut Jitsi zu installieren
wie installierst Du jitsi?
denn jitsi-meet hängt von jitsi-videobridge2 (version 2, in worten: zwei) ab. eigentlich sollte sich diese paket mit jitsi mitinstallieren. es gibt also keinen grund eine veraltete videobridge manuell zu installieren!
Coderoot@cup:~# apt-cache depends jitsi-meet jitsi-meet PreDepends: jitsi-videobridge2 Depends: jicofo Depends: jitsi-meet-web Depends: jitsi-meet-web-config Depends: jitsi-meet-prosody Recommends: jitsi-meet-turnserverund die jitsi-videobridge2 hängt dann auch von einer in Debian 12 verfügbaren openjdk ab.
Coderoot@cup:~# apt-cache depends jitsi-videobridge2 jitsi-videobridge2 |PreDepends: <openjdk-11-jre-headless> |PreDepends: <openjdk-11-jre> |PreDepends: openjdk-17-jre-headless PreDepends: openjdk-17-jre -
temurin Pakete
besser deinstallieren und aus den apt sources entfernen, bevor sie mit den openjdk paketen kollidieren.
-
Ohh Gott, es liefert als Ergebnis mehr als 10.000 zulässige Zeichen pro Beitrag.
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.
hinzufügen?
korrekt, genau so!
-
apt install temurin-17-jdk
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
Codeapt-cache show temurin-17-jdk | grep Provides -
ihr wollt mit publikum leiden und scheitern? sieht bisher alles aus wie ein unfall: nicht schön, man muß aber irgendwie hinsehen.
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.
Code
Alles anzeigenroot@cup:~# cat /etc/debian_version 13.3 root@cup:~# apt-cache depends jitsi-videobridge2 jitsi-videobridge2 |PreDepends: <openjdk-11-jre-headless> |PreDepends: <openjdk-11-jre> |PreDepends: openjdk-17-jre-headless PreDepends: openjdk-17-jre |PreDepends: libssl3 libssl3t64 PreDepends: <libssl1.1> |Depends: debconf Depends: <debconf-2.0> cdebconf debconf Depends: procps Depends: uuid-runtime Depends: ruby-hocon Conflicts: jitsi-videobridge Recommends: libpcap0.8 libpcap0.8t64 Replaces: jitsi-videobridge root@cup:~# apt policy openjdk-17-jre-headless openjdk-17-jre-headless: Installed: 17.0.18+8-1~deb12u1 Candidate: 17.0.18+8-1~deb12u1 Version table: *** 17.0.18+8-1~deb12u1 500 500 http://security.debian.org bookworm-security/main amd64 Packages 100 /var/lib/dpkg/status 17.0.17+10-1~deb12u1 500 500 http://mirror.de.leaseweb.net/debian bookworm/main amd64 Packages -
Also Kinder hast du dann schonmal keine...
da liegst Du falsch.
ich will einfach dieses dealerhafte anfixen unserer kinder mit microsoft produkten nicht unterstützen. die sollen gefälligst textverarbeitung und nicht microsoft word lehren.
-
Die müsste nun das richte Paket sein
warum machst Du es Dir selbst so schwer? mit einer manuellen installationen dieses packages verpaßt Du jegliche security updates.
nimm Debian 12 einfach in die apt ressources dazu und fertig.
-
pragmatische
habe ich in post #2 schon angeführt, nur die op ist an einer lösung nicht interessiert.
Wieder Debian 12 für Jitsi verwenden habe ich kein Interesse.
-
Wenn da auch Lizenzen dranhängen: Kleineren, Gemeindeverwalteten Schulen schenken (z.B. Grundschulen):
keine ahnung, das waren noch diese klebelizenzen auf den rechnern. und an schulen gebe ich sowas sicher nicht weiter, sollen die dort was gescheites lernen und sich nicht von microsoft abhängig machen lassen. also ab in den schredder damit oder konfetti mit dem locher machen.
-
von Sun/Oracle das .den Paket für jre-17 gedownloadet und installiert.
also dem gegenüber bevorzuge ich auf Debian 12 zu bleiben oder in einem Debian 13 die sourcen für Debian 12 zu belassen. bei fremdquellen ist immer ungemach vorprogrammiert. und ich dachte Du suchst nach einer pragmantischen lösung und nicht nach problemen.
