disable VNC

[waynedpj]

ahoy,

first thanks so much for this project, hoping it can help us get CP4SB working on an old server running Alpine.

to save resources i am trying to prevent the x11vnc service from running since VNC will not be used by default. i had renamed the /etc/services.d/app/x11vnc.dep file to x11vnc.dep.off and created a /etc/services.d/x11vnc/down file to prevent it from being started by s6. however upon restarting the container the /etc/services.d/app/x11vnc.dep is recreated and x11vnc is running again under s6-supervise.

i have never used s6 nor docker before so apologies for missing something probably very obvious, but my research has not yet found the answer so any pointers appreciated.

thanks, w

[jlesage]

Dependencies for the app service are re-created during the startup and since it should start last, it depends on all services. So instead you could try to remove the directory /etc/services.d/x11vnc.

Note that you will loose access to the UI through both VNC and the web interfaces.

Also, I'm planning a version where you will have the ability to disable the UI by setting an environment variable. When enabled, the CP UI and all its dependencies (x11vnc, xfvb, nginx, openbox, etc) wont't start.

[waynedpj]

Dependencies for the app service are re-created during the startup and since it should start last, it depends on all services. So instead you could try to remove the directory /etc/services.d/x11vnc.

i tried removing the /etc/services.d/x11vnc as you suggested and indeed x11vnc is no longer running ..

Note that you will loose access to the UI through both VNC and the web interfaces.

.. though again as you said now the CP Desktop UI is not even accessible via the http server :) i was guessing (incorrectly) that the VNC and http interfaces to CP Desktop were not both dependent on VNC.

Also, I'm planning a version where you will have the ability to disable the UI by setting an environment variable. When enabled, the CP UI and all its dependencies (x11vnc, xfvb, nginx, openbox, etc) wont't start.

that would be useful to our situation though i would instead prefer a way simply to start and stop the CP Desktop UI related processes via a docker exec crashplan-pro [start|stop]-ui. for us (and i imagine for others) the CP Service is left running always to monitor and detect file changes, while the need to check in with the Desktop app via http or VNC is not something that happens often, so no need to have all those services running.

i have been playing with s6 in the hopes that there is a way to start/stop these UI services w/o stopping the CP Service, but have not yet found it. should this (i.e. using s6 to start/stop the UI services) work for what we are trying to do?

thanks again for your help and this project.

[jlesage]

What you want to achieve would be easy with more advanced process supervisors, like systemd. But with s6 you would need to create your own script that change content of the service directory and perform the required actions on services (like stopping them).

i would instead prefer a way simply to start and stop the CP Desktop UI related processes via a docker exec crashplan-pro [start|stop]-ui

Note that setting an environment variable of a container can be as easy as executing a command. Some distro like unRAID make it easy to change a container setting. Else, some scripts can be done to automate the process.

[waynedpj]

What you want to achieve would be easy with more advanced process supervisors, like systemd. But with s6 you would need to create your own script that change content of the service directory and perform the required actions on services (like stopping them).

thanks though it seems that the s6-svc command should be able to stop running services. unfortunately this does not work

/$ s6-svc -d app s6-svc: fatal: unable to control app: supervisor not listening

is there something unique about this container's setup which prevents the s6-supervise processes from listening to signals?

finally according to the s6-supervise docs SIGTERM: bring down the service and exit, as if a s6-svc -xd command had been received. however it seems only possible to send a SIGTERM to the s6-supervise process that is managing app, not to the app itself. and if the s6-supervise process is killed then restarting it with dependencies is a problem.

thanks.

NOTE: updated from original comment with latest discoveries!

[jlesage]

thanks though it seems that the s6-svc command should be able to stop running services. unfortunately this does not work

/$ s6-svc -d app s6-svc: fatal: unable to control app: supervisor not listening

is there something unique about this container's setup which prevents the s6-supervise processes from listening to signals?

The s6-svc takes the service directory as parameter. So you would need to run something like:

s6-svc -d /var/run/s6/services/app

finally according to the s6-supervise docs SIGTERM: bring down the service and exit, as if a s6-svc -xd command had been received. however it seems only possible to send a SIGTERM to the s6-supervise process that is managing app, not to the app itself.

Yes, this is how it is expected to work: killing the managed process itself will make s6-supervise to restart it. Killing the s6-supervise process will kill the managed process and the associated s6-supervise process. Thus, management/monitoring also stops.

and if the s6-supervise process is killed then restarting it with dependencies is a problem.

You would need to manually start services in correct order. s6 doesn't have built-in dependencies management...

[apateluk]

Hi, Thanks for the hardwork on bringing this to the community.

Any word on when you think you'll have the option to disable VNC ?

Thankss

[jlesage]

I don't have an ETA, but this feature will depend on the new baseimage I'm working on. I can say that a good amount of work is already done on it.

[scyto]

just so I understand there is no way to disable VNC without also disabling the web UI? thats ok if there isn't i just don't like having VNC running if a normal HTML interface is present and accessible. Nice docker BTW had it running in 5 mins on synology.

[jlesage]

VNC is the only way to access CrashPlan's UI. The web interface is just an HTML VNC client.

[waynedpj]

The s6-svc takes the service directory as parameter. So you would need to run something like:

s6-svc -d /var/run/s6/services/app

aha! i was passing the service directory in my previous example, i was just running that command from within what i thought was the service directory /etc/services.d/app/ . however when i run it with the /var/run/s6/services/app it works. a hint is that while both directories are nearly identical, the true service directory contains both the event/ and supervise/ special directories needed by s6.

is there a reason for the /etc/services.d/ directory in addition to the real one in /var/run/s6/services/?

regardless thanks!

[jlesage]

The services in /etc/services.d/ are the (read-only) "definitions", while /var/run/s6/services/ is the directory structure used by s6 at runtime.

[David-Woodward]

jlesage, I created my own amalgamation of your docker image and the old JrCs docker image that runs headless just like the old days (minus restore functionality) and can be found here.

It's a very basic docker image (no s6-overlay or any other process supervisor) that uses socat to forward ports from the docker container interface to the internal CrashPlan service. I thought you might be interested in taking a look at that implementation as an option in your own project(s) for people to use as a fallback when the VNC/X11 services are shutdown. The relevant source code for that implementation is here.

For anyone else reading this who intends on using my docker image until the feature is added to this project, please note that it's provided more or less as-is with very limited support. I do plan on keeping it up to date with the most recent CrashPlan releases as long as they don't break things too much in future releases, but I created it more as an exercise to help me learn more about Docker. I don't anticipate I'll be using it as my backup solution of choice unless Code42 changes their stance on a few things - as noted in the humongous disclaimer on my project page. :) So, you should probably stick with the jlesage docker image unless you have a good reason not to.

[waynedpj]

@David-Woodward thanks for the reply and sharing your project, looks promising and possibly helpful to simplify things a bit.

@jlesage as you made clear earlier basically we can disable VNC. however without some other way to access the CP GUI there is less of an impetus to do so, besides saving some resources while the the GUI is not needed. thus would you like me to close this issue as solved or keep it open for other questions/updates regarding disabling VNC?

thanks again.