Request for input


Recommended Posts

Hi guys,

 

I've been having a play around with getting a docker container to run an instance of nZEDb (could probably also be adapted for newznab), it's basically the phusion base image with apache, php, python etc (all of the requirements detailed for nZEDb).

 

So far it seems to be working ok, but I'm in a quandary about how to handle the actual nZEDb processing, more specifically making it so that it is easy to log in and view what is going on.

 

The basic process is that nZEDb had a tmux session going which controls the updating of binaries and processing releases etc.

 

As it stands now, I have a script which is run at container startup which kicks off the tmux session. I also am running the container with the enable-insecure-key flag so that I can ssh in and then run "tmux a" to attach to the session that was started.

 

It seems to work, and from the phusion docs I see that I can make the insecure key option be enabled by default. But that comes with a big warning that it shouldn't be used in a production environment.

 

So does anybody have any suggestions on an alternative? What would be really nice is if you could just do a "docker attach <container>" and see the tmux session. But I haven't been able to get that to work. If I have the tmux session be kicked off by runit then when you detach from it, it goes into a loop of trying to restart it but failing because the session already exists.

 

Second best would be to have a bash session available when you run docker attach, but I have no idea how to get that working.

 

One thing I did think of was having a volume specified that could be set to link to a key file on the host, that during startup gets enabled in the container - something like "-v /boot/nzedb.key:/user.key" and then on startup the container looking for /user.key and doing the necessary to hook it up to the ssh daemon.

 

Anybody have any thoughts?

Link to comment

Yeah I was aware of being able to pass in a key, but that is when the container is built - so it wouldn't be much more useful than using the insecure key.

 

You only need to build the container once though. The real advantage here is that you're using a unique key instead of a public (insecure) one. Or maybe I'm missing something?

Link to comment

Yes I only need to build the container once. But if I ever plan on making it available for anybody else who is interested I'm sure they'd prefer to use their own key, or not rely on having to use a key at all.

 

For my personal use I'm happy to use the insecure key. Just trying to think ahead with a view to giving something back to the community.

Link to comment

Yeah that's an option for those who are happy to build themselves from the dockerfile, but it doesn't help in the case of a prebuilt image downloaded from the docker hub.

 

I'll probably look into the possibility of a key being provided through a volume mount and incorporated at run time.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.