Troubleshooting BigBlueButton Server

What is BigBlueButton?

BigBlueButton (BBB) Server is an opensource video conferencing/desktop sharing/presentation server that runs on a Linux box which is what we needed at our office. It is composed of a collection 15 or more opensource technologies. BigBlueButton also supports PowerPoint presentations and PDF (up to 100 pages) viewing across a Client/Server Web App. Making it easy to demonstrate software, have presentations, or meetings across a multi-platform environment found in many businesses across the globe. It is compatible with Windows, Macintosh, and Linux OS to match typical or technical attendees out there.

This was exactly what my office was looking for. First we considered a few other commercial products like Teamviewer but the price of it was rather hefty. So we were considering other options and I was assigned the task. An open source product was the prefect candidate for our situation.

How easy was the installation process?

This installation of BBB was not as advertized at least for our circumstances. On its site, the steps clearly say that the installation process takes less than 15 minutes; however, this is greatly, no i mean astronomically under-estimated as the installation of the virtualization, the unpacking of Ubuntu Server, and all necessary components for the server to function properly took me a good 5 hours to download on our congested T1 line. One thing that the provider did correctly was to package the vital components together. If I didn't have them collectively like this who knows I still might be downloading the endless list of software and services. But all kidding aside, the process was slow to a crawl so had to put the sucker on autopilot for the day.

Necessary troubleshooting:

After the rather lengthy installation, our first issue arose when trying to obtain an IP from our DHCP server. This was smoothly diverted by the troubleshooting section.

A quick: "sudo bbb-conf --setip ", and a "sudo bbb-conf --clean", restarted the server. Everything looked fine.

After 2 days waiting in anticipation, BigBlueButton Server was finally up running. But under closer examination in testing out the server, it was noticed that the voice conferencing feature was disabled for some reason.

A quick search through the Knowledge Base provided a check command (sudo bbb-conf --check) or the debugging utility (sudo bbb-conf --debug) and identified a problem with the voice conferencing server (using FreeSWITCH), the sip server's IP. For some reason the IP was not set when the --setip command was issued from the previous troubleshooting. The IP was never set to obtain the IP from our DHCP server and still the original static IP address remained:

***OUTPUT***

"$ sudo bbb-conf --check ... # The IP address (192.168.10.12) set for sip.server.host in # /usr/share/red5/webapps/sip/WEB-INF/bigbluebutton-sip.properties # does not match the local IP address (10.0.2.15). ..."

Changing the "sip.server.host" lines in the file "bigbluebutton-sip.properties" was the idea presented in one of the issues that users had. However, there was no clear way on how to do this. I tried changing the line in VI editor but something was blocking the file from writing the changes. I initially thought that the reason for the block was because the server was still running. So, after turning off the server (sudo bbb-conf --stop), I repeated the process of editing the "bigbluebutton-sip.properties" file and guess what; it still reset itself back to its original state. After looking over it with a co-worker, it was later discovered that the file permission did not allow us to write to the file. It made no sense to me at the time because I was logged in as the root but still had to try everything to get it up and working. So from there, I first changed the permissions from 744 to 774 (sudo chmod 774 bigbluebutton-sip-properties). This would give the group read, write, and execute permissions as well as the owner. I repeated the process and it still would not work.

By then I was frustrated with the thing, it was time to we went all for broke.

(WARNING: This next step should be done with the server taken offline. It allows anyone access to read, write, and execute the file.) Taking the server off-line first for security purposes, I then changed all of the permissions to 777. Edited the file in the VI, saved, and crossed our fingers. After I set the permissions back to the original state of 744, started up the server and tried the application.

After all our efforts it was finally up and running the way we intended.