I am just reporting that the BigBlueButton Open-source Web conferencing tool
is developed using LXD,
http://docs.bigbluebutton.org/install/install.html#running-within-an-lxd-container
1 Like
Big Blue Button works great.
The developers are sticklers for quality. It shows, as BBB is a great web conferencing or teaching tool w white board sharing, private conference rooms for side conversations, note taking, slide presentation etc
It’s also fairly easy to install.
I introduced some school systems to it 4 yrs ago to help them save $$ over their then commercial sw
Hi Simos,
I was wondering if you know from where to download a running BBB lxc container?
thanks
Hi Hector,
I do not think there is such a container image. BBB requires some specific configuration and I think it would be difficult to generalize the setup to make it into a container image.
You can ask at the BBB community if there is such a container image.
Alternatively, you can follow the instructions to build such an image, and them make a script that will automate the task.
I’ve installed big blue button several times over the past few years for remote learning by some schools but not in LXD. Although lately I’ve been thinking about installing it in an LXD container.
I have some time in the next week or so and I might just give it a shot.
I installed BBB last year on LXD on a VPS for testing. It worked well. The only downside was the quality of the audio, which likely was not related to LXD but some other configuration. If someone gives it a go, I would like to hear about the audio quality.
Ok… I just installed BigBlueButton v2.0 (not the new beta) in an LXD ubuntu 16.04 container.
NOTE:
It failed to install in a default “unprivileged” container.
But it succeeded in installing in a “privileged” container.
I have a USB webcam that also has a Mic so after installation I shutdown the BBB container and then executed the following:
$ lxc stop bbb
$ lxc config device add bbb video0 unix-char path=/dev/video0
$lxc config device add bbb video1 unix-char path=/dev/video1
Then exec’d into the bbb container again and had to correct the permissions for the video0 and video1 devices.
# chown root:video /dev/vid*
Notes:
- You will have to use “chown” every time you restart the BBB container.
- I did not have WebRTC support configured/installed so I had to use flash but after that Firefox would work and both the Mic and Video worked.
Chromium would not work for audio or video but then I remembered that Google stripped all support for Flash out of both Chrome & Chromium… so that is to be expected.
So BigBlueButton does work in an LXD container as long as you are using Firefox.
If you have WebRTC implemented then you could use either Chromium or Firefox I guess.
One of the BigBlueButton developers responded to my Post on their User Forum with the suggestion to try BigBlueButton v2.2 (beta) and gave the reasons why here:
I did try this, still had to use a “privileged” container and Chromium/Chrome still did not work for audio or video. But now with v2.2 Firefox only had audio but no video.
So v2.0 of BBB works if you are only using Firefox. But it will only be good until even firefox disables support for Flash.
Brian
Thanks for sharing this. I am not enthused by BBB (seems a very complex piece of software, lots of moving parts) but it’s intesting as a result. About your install it fails with redis-server, it’s bad that they are limiting to Ubuntu 16.04 (it’s a testimony also on how complex their product is) because redis-server installs without problem on a 18.04 container, it’s standard in the distribution while it’s not available in 16.04 (but maybe when they will come at 18.04 they will need a newer redis version…). Possibly the redis install problem could be solved in a similar way than with tcpdump, ie a systemd declaration.
On the sound quality and visual artifacts issues, it’s good to understand that they are real time issues. I tried out a sound app (Asterisk) on a container and I never quite solved the chopped sound issues.
Probably the lack of responsiveness on the network link mattered, but it’s a good idea to fidldle with the CPU priorities (it’s recommended in fact). You see, with sound bandwidth don’t matter a lot, it’s the response time; you can have 10 Mbytes/s for 3 seconds and then a nice 0 for 1/10 of second and have a good download and even web performance, but sound will be horrible. If you don’t have a ping below 40 ms, don’t hope to use a sound based solution and have a nice time about it. And a standard OS like Linux does not a real time system make, not without fiddling
I have not found anywhere a discussion about this kind of problem with LXD; declare that if in a given container some process declares itself as real time, it would be real-time in the host too, but without having to make the container privileged (that’s a big no-no for me)
Thanks for this.
As a sidenote, you do not need to chown every time; the unix-char device accepts now extra parameters and you can set it to the proper owner from within LXD.
I actually have always like BigBlueButton (BBB) because several years ago I learned they are extremely conservative in regards to testing their BBB software which is why they don’t update the base OS version very often. For a web conferencing system used by alot of schools etc I can really appreciate that.
I don’t think its necessarily because of any complexity that they haven’t yet moved to Ubuntu 18.04. 16.04 is still an Ubuntu LTS and still supported by Canonical.
As to sound choppiness on any real-time video/audio system like BBB or Asterisk… if you are on WiFi you have to realize WiFi has inherent problems with latency that sometimes you can deal with and sometimes you can’t. For non-realtime audio/video buffering hides that its occuring but for real-time, a missed packet is a missed packet and choppiness is the result. Using PING to measure real-time response isn’t going to help much beyond looking at the PING Max Deviation (RTT mdev) for RTT (Round Trip Time) but in real-time streams you aren’t always doing round-trip.