The Crowdrender image's docker CLI options don't support use on a local network well

[Jeducious]

What's up?

After recently trying to help someone get a container up and running that uses the containers on a locally hosted compute cluster running linux, I came to realise our support of this particular use case sucks.

In detail, what exactly is the problem

There are some gotcha's that need addressing;

• First, there's the problem of running multiple containers, one on each computer node (assuming that's what most folk would do).
• Then, there's the problem of securing containers so only the person who creates them has the ability to use them, this is important if you want to expose your docker instance to the internet. Useful if you plan to connect from a remote location, and you don't want to run a VPN.

Dealing with the first issue, Crowdrender's addon currently has a bad design when it comes to the handling of docker images. This is because an image will always have the same hardware uuid everywhere its run, and this isn't great because that hardware uuid is how your Crowdrender client tells machines apart. So off the bat, if each container runs the same image, then you can only really connect to one of those at a time from a master or client.

Then there's the issue of making sure your containers can't be hijacked by the unscrupulous hackers out there. This was taken care of by allowing users to specify the -ak option when starting a server that will set an access key (secret), only known to the person setting up the container. Any request reaching the server running in the container that doesn't have the key is dropped.

When dealing with both of these issues, we, or rather I acted on the misguided belief that killing two birds with one stone is always a good idea, word to the wise, its not.

The -ak option was used to set a secret AND to modify the hardware uuid. Bad idea.

Fast forward to having the "local" env var for running a Crowdrender container on a local network, this sort of worked. Basically it just didn't set the hardware uuid at all. But what this meant was that now, only one container can truly be used at a time on the local network. Boo.

Of course you can set the -ak option to fix this, but then you can run into another problem. The secret that is set, an be invisible to you, the person setting up the container if you set local=false and don't specify the machine_uuid env var. Yep, that's right, the secret, or -ak option is populated by the override value for the hardware uuid. See how confusing this all is?

Anyways, with an invisible secret, all is not lost, you can still use all your hardware, but, your client/master MUST be logged in to your cloud account, cause otherwise, you won't get the secret set for that server sent to you from your cloud account. And the connection will just fail with no information about why. GREAT.

what shall be done about this!?!

This is going to require an update to both the scripts run inside the container to start a crowdrender server, and the software of the server. Basically I am going to introduce a new option that only overrides the hardware uuid, and the current -ak option will only set the secret. This will allow those who wish to use the addon on an isolated, local network the ability to override the hardware uuid of the image and run as many containers as they like and be able to use all of them, not internet or account required.

I am also removing the "local" environment variable and its effects. Instead, I'll document the crowdrender CLI properly in the readme.md file here in the cr_docker repo and just pass through the options as env vars. Basically this will just expose the add-on's CLI to the docker run command, and anyone will then be able to run the addon as they see fit. If they want to set a secret, they can, if they need to override the hardware uuid, they can (although it will be overridden by default with a freshly generated uuid each time so things work out of the box with less envs required for the docker run cmd).

This should make the user experience less terrible.

[Jeducious]

Theres a new branch created for this here.