Rationalising the UID and GID of bigbluebutton user in Scalelite containers

[lightweight]

This pull request covers my tweaks to the Scalelite Dockerfile to set the UID and GID both to 997 as seems to be the default set via the bbb-install script for BBB instances. I have also included a quick script for building an deploying our containers that someone else can easily repurpose.

Note - this approach has not (yet) solved my recording problems, but I think it'll make it possible to create a robust solution when I finally get all the pieces into place.

Reasoning

I have found it difficult (and likely dangerous) to manage recordings on instances of BBB, created using the bbb-install script on Ubuntu 16.04 hosts, sitting behind a combined Scalelite and Greenlight load balancer (running in Docker via Docker-Compose).

I have succeeded in setting up NFS and having Scalelite see the same recordings file system as my two BBB "workers". But I haven't got the processing of recordings working properly using the existing Scalelite documentation plus insights from #83, #129, #147, and other issues. I noticed that some people had got the recordings working properly. I've managed to create a few published recordings by manually pushing raw recordings through the process via bbb-record and changes of ownership for the files and directories involved, but I have not yet had any recordings "published" without resorting to sudo -n -u bigbluebutton bash /var/bigbluebutton/scalelite_batch_import.sh.

It appears some folks have managed to get it working (I'm not sure how, to be honest - I suspect some undocumented umask fiddling or xattr or similar)... by making the whole /var/bigbluebutton/* world read & writeable... but even that is, I suspect, temporary.

The main source of problems seems to be the difference in UID, GID of bigbluebutton in the Docker containers (1000, 1000) and on the BBB workers (997, 997). The recommendation in #147 involves using a separate group (this is where, I think, some tricky user mapping or umasks would be necessary) but that seems unnecessarily complicated.

My approach is to set the UID and GIDs for the bigbluebutton user in the Scalelite Docker containers.

Caveat

This implementation might be slightly better if it used ENV variables or some other mechanism to abstract the actual UID and GIDs in the event that people are using some other system for implementing the BBB works that doesn't result in the specific UID and GID I've used. But in that case, they'll be no worse off than they are with the default Scalelite Docker containers' choice of 1000, 1000.

[davidpesce]

Hi @lightweight - Take a look at this section of the scalelite documentation - https://github.com/blindsidenetworks/scalelite/blob/master/sharedvolume-README.md#setting-up-directory-structure-and-permissions

When doing these commands be sure to note whether they are performed on each of the bbb servers or on scalelite. Hopefully that helps get you to where you need to be!

[lightweight]

Thanks @davidpesce - yes, I did do those, but it still creates an awkward situation where the files written by, say, a bbb server, are written by the bigbluebutton (UID=997) user, and group (GID=997) rather than the recommended "scalelite-spool" group... in which case things fall apart unless the user/group are changed. People have simply chmodded the dirs to 777 which, of course, isn't particularly desirable. I'm just thinking that all of these complexities can be removed if the UID and GID of the bigbluebutton users in the Scalelite containers is also 997:997 rather than 1000:1000... (that still leaves the Red5 written stuff, but that seems less onerous). Although perhaps I'm missing something...