sind wir nicht alle ein wenig Bluna… oder Masochisten.
Nach der Meldung von Christian, das Update auf 2.2.10 sei problemlos durchgelaufen, habe ich es doch gewagt, und tada
Reloading nginx.service using systemd
Adding nginx.service to autostart using systemd
Synchronizing state of nginx.service with SysV init with /lib/systemd/systemd-sysv-install…
Executing /lib/systemd/systemd-sysv-install enable nginx
Job for nginx.service failed because the control process exited with error code. See „systemctl status nginx.service“ and „journalctl -xe“ for details.
dpkg: error processing package bbb-record-core (–configure):
subprocess installed post-installation script returned error exit status 1
Processing triggers for initramfs-tools (0.122ubuntu8.16) …
update-initramfs: Generating /boot/initrd.img-4.15.0-99-generic
Processing triggers for libc-bin (2.23-0ubuntu11) …
Errors were encountered while processing:
bbb-html5
bbb-record-core
E: Sub-process /usr/bin/dpkg returned an error code (1)
@irrlicht
Wie hast du das denn schließlich wieder zum Laufen gekriegt, oder spackt das immer noch bei dir?
scheint es tatsächlich gefixt zu haben, zumindest mal auf der Konsole kamen nun keine Fehlermeldungen mehr beim dist-upgrade und auch bbb-conf --check zeigt keine potentiellen Probleme.
Mal eine Konferenz testen…
BTW: Beim Update hat er mir jetzt BBB 2.2.11 angezeigt
Furthermore, you can re-run the same command later to update your server to the latest version of BigBlueButton 2.2.
Schließlich habe ich mir ein Update-Script gebastelt, das BBB, Greenlight und bbb-exporter (für das Monitoring) in einem Aufwasch updatet. Wenn ihr Interesse habt, kann ich es hier gerne veröffentlichen.
Bisher liefen alle Updates damit problemlos durch. Ich nutze zudem auch die apply-config.sh.
Viele Grüße
Christoph
Edit: Ein Reboot war bei diesen Update-Prozessen auch noch nie notwendig. Ich bin mittlerweile auf 2.2.10 und hatte keine Probleme mit dem letzten Update.
Hab jetzt mal den aktuellen Firefox 76.01 probiert, da tut alles.
Mein „rolling relase“ rollt also nicht so richtig, Firefox 68.8 scheint bei webrtc mal etwas abgehaengt, da kommt „ESR“ als Bumerang zurueck.
#!/bin/bash
wget -qO- https://ubuntu.bigbluebutton.org/bbb-install.sh | bash -s -- -v xenial-22 -s bbb.example.org -e mail@example.org -g -c turn.linuxmuster.net:secret
cd /etc/nginx/sites-available
cp bigbluebutton bigbluebutton.bak
cp bigbluebutton.final bigbluebutton
cd /root/greenlight
docker pull bigbluebutton/greenlight:v2
docker-compose down
docker-compose up -d
cd /root/bbb-exporter
docker pull greenstatic/bigbluebutton-exporter:latest
docker-compose down
docker-compose up -d
systemctl reload nginx.service
Die Datei bigbluebutton.final entspricht meiner nginx-Config, in der auch die Änderungen für bbb-exporter und netdata enthalten sind. Diese Datei wird beim Update nämlich leider auch überschrieben. Der Update-Prozess ist leider in der Tat nicht sehr durchdacht.
Edit: Die Parameter für das bbb-install-Skript müssen natürlich an die eigenen Bedürfnisse angepasst werden.
Wenn ich mir bbb-install.sh anschaue, dann graut es mir davor, das alle paar Tage auszufuehren. Das ist ein Moloch aus 1110 Zeilen, da sind hartkodierte Versionsnummern drin, das muss also immer neu per wget geholt werden.
Ich hab keine Ahnung, wieso die das nicht einfach nur per apt abwickeln, das BBB-Repository ist doch sowieso eingepflegt.
Mich wuerde es nicht wundern, wenn da beim Zusammenspiel zwischen apt und dem Skript mal was in die Hose geht oder man das alte Installskript aus Versehen nimmt oder oder oder…
Zu viele Wege nach Rom.
Wieso kopierst Du nach dem Skript bigbluebutton nach bigbluebutton.bak? Dann ist doch schon alles kaputt
Wieso kopierst Du nach dem Skript bigbluebutton nach bigbluebutton.bak?
Dann ist doch schon alles kaputt
er sichert damit die nginx sitedefinition, wie sie das script
bereitstellt, bevor er seine .final drüber klatscht.
Wenn was nicht paßt, kann er im „orginal“ nachschauen.
Und nur für’s Protokoll: bei uns laufen die Updates auf den Hetzner-Servern ohne Probleme und Warnungen. Es ist bisher auch nie ein bbb-config --setip notwendig gewesen. Nach einem Upgrade aus den Paketquellen wurde BBB automatisch neu gestartet und war danach wie gehabt erreichbar.
Es mag also bei manchen (manuellen?) Konfigurationen hilfreich sein, zwingend notwendig ist es nicht.
Da sind ja um die 20 Pakete mit BBB-Inhalten vorhanden, wenn da nur ein Teil aktualisiert wird, dann wird auch nur ein Teil ueberschrieben - glaub ich zumindest.
Die TURN-Server-Config hat’s mir schon zweimal ueberschrieben, man merkt ja auch kaum, wenn die nicht mehr ok ist.
Hast Du die apply-config.sh noch am Start?
Das ist ja auch so ein Konstrukt, kopiert jedes Mal beim Start von BBB irgendwelche essentiellen Konfigdateien ueber die so gut wie immer identischen vorhandenen - oder hab ich das falsch verstanden?
Hallo Harry,
Tatsächlich scheint es so, dass die Konfigurationsdateien nicht wie oft unter /etc üblich beibehalten, sondern zugunsten der Stabilität (was ich nicht schlecht finde) auf Standardwerte zurückgesetzt werden. Darum haben die dieses Konstrukt mit apply-config.sh gebaut. Da passiert aber nichts Geheimnisvolles. Diese Script wird einfach bei einem Neustart von BBB ausgeführt.
Man kann jetzt in diesem Skript Dateien kopieren oder mit sed bestimmte Einstellungen überschreiben. Das führt dazu, dass diese auch nach einem Update noch bzw. wieder da sind.
Läuft alles so, wie beschrieben. Klar wäre eine einzige, updatefeste Einstellungsdatei auch nett. Aber BBB besteht aus so vielen einzelnen Komponenten, ich glaube nicht, dass das wirklich besser funktionieren würde. So muss ich mir einmal Gedanken machen, was ich bei meinem System abweichend vom Standard geändert haben will, das in apply-config verewigen, dann läuft es. Und ich habe nur eine Datei, in der ich Änderungen vornehmen muss, wenn sich mal etwas ändert. Ganz doof finde ich das nicht
auch bei mir lief das Update auf 2.2.11 soeben mit meinem oben geteilten Update-Skript problemlos durch. Wenn man mal das Zusammenspiel aus BBB, Greenlight, bbb-exporter und netdata verstanden hat und die apply-config.sh ordentlich konfiguriert hat, dann flutscht das Update durch. Ich gebe dir aber recht. Bis man seine Konfiguration angepasst hat, ist es echt ein Gefrickel…
ich hab jetzt drei bbb server upgegreaded per apt dist-upgrade
Bei allen drei hat das upgrade per apt den Fehler gebracht, dass
bbb-html5 nicht konfiguriert werden könne.
Ein bbb-conf --check
brachte, dass bbb den servernamen in der
/etc/nginx/sites-availible/bigbluebutton nicht finden kann, weil der
Wert leer ist.
In der Datei steht auch tatsächlich:
server ;
ganz oben.
In der Datei stand aber vorher an dieser Stelle
server meinedomain.de;
Ich hab das wieder reingeschrieben und apt dist-upgrade nochmal laufen
lassen: dann war alles gut.
Man muss bei tests immer dran denken, dass bbb eine ganze Weile braucht
bis es bereit ist.
Ja, das hat mir auch schon mehrere Schweissausbrueche beschert.
Das Hauptproblem ist ja, dass BBB ein solcher Moloch von verschiedenen Diensten ist, dass man bei Fehlern erstmal ziemlich doof dasteht, ich komm mir da vor wie ein Anfaenger.
Gesternabend kamen ja dann auch noch ein paar Zusatzpakete zu 2.2.11.
Seltsam, dass es diese Probleme manchmal gibt, mal überhaupt nicht - bei uns wird da definitiv nichts überschrieben und wir haben da auch nichts verändert. Hat es evtl. mit der Struktur von /etc/nginx/sites-available/bigbluebuttonzu tun? Ich hänge sie mal an. Vielleicht wird die Datei nur ersetzt, wenn BBB sie nicht sauber parsen kann…?
Viele Grüße
Thomas
server {
listen 80;
listen [::]:80;
server_name <korrekte-fqdn>;
listen 443 ssl;
listen [::]:443 ssl;
ssl_certificate /etc/letsencrypt/live/<korrekte-fqdn>/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/v/privkey.pem;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers "ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS:!AES256";
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/ssl/dhp-4096.pem;
access_log /var/log/nginx/bigbluebutton.access.log;
# Handle RTMPT (RTMP Tunneling). Forwards requests
# to Red5 on port 5080
location ~ (/open/|/close/|/idle/|/send/|/fcs/) {
proxy_pass http://127.0.0.1:5080;
proxy_redirect off;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffering off;
keepalive_requests 1000000000;
}
# Handle desktop sharing tunneling. Forwards
# requests to Red5 on port 5080.
location /deskshare {
proxy_pass http://127.0.0.1:5080;
proxy_redirect default;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
include fastcgi_params;
}
# BigBlueButton landing page.
location / {
root /var/www/bigbluebutton-default;
index index.html index.htm;
expires 1m;
}
# Include specific rules for record and playback
include /etc/bigbluebutton/nginx/*.nginx;
#error_page 404 /404.html;
# Redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /var/www/nginx-default;
}
# BigBlueButton Exporter (metrics)
location /metrics/ {
auth_basic "BigBlueButton"; # The contents of this can be anything
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass http://127.0.0.1:9688/;
proxy_redirect default;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
include fastcgi_params;
}
# Netdata Monitoring
location /netdata/ {
auth_basic "BigBlueButton"; # The contents of this can be anything
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass http://127.0.0.1:19999/;
proxy_redirect default;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
include fastcgi_params;
}
}
