Capt.Insano

I have made some changes to how rTorrent & ruTorrent are ran within the container: This should hopefully stop the permission issues that you are having. I have also exposed the ruTorrent directory (/var/www/rutorrent) so it can be mapped your AppData folder, this will result in an easier way of changing ruTorrent settings, adding 3rd party plugins and retaining ruTorrent settings across updates. I am currently in work however so cannot test for a few hours, if you could test it and report back it would be much appreciated. If it still does not work, could you post the output of the following from the folder containing your completed folder. ls -la Thanks, The Capt

Another update: Improved the GIT logic within the container. If a GIT version already exists, it now gets updated instead of recloned. Enjoy.

This container runs on container port 80. This means it is on port 80 internally to the container. Docker allows this to be linked to any external port called host port, the config file defaults it to port 8089 but even this can be changed to any port you want!! This can be ran along side any other Docker you want by making sure the host ports are different.

Great news! Will DockerMan be updated to allow new port range values? Currently adding portA-portB range into DockerMan "Add Container" dialogue will not allow you proceed, even for Docker 1.4.1 to subsequently fail. Thanks!

@jonp Do we know/may I ask if Docker will be updated version 1.5.0 for the unRAID 6 release? Docker 1.5.0 adds the ability to expose port ranges through: EXPOSE [portA]-[portB] in the container Dockerfile and then run containers with the command: docker run .... -p [portA]-[portB]:[portA]-[portB] Currently this is not possible on current Docker (v1.4.1) Would make my ruTorrent container easier for users!!

OP updated: GIT support added to container ruTorrent config improved to remove prev bug (thanks for ideas Sparklyballs!!) Bug report removed from OP: Container working great!! Hope you enjoy!

Release: rTorrent/ruTorrent Container 14/05/15: There are now 2 versions of this container in my repo: "ruTorrent" Container is based on rTorrent 0.9.4 (newest) "LegacyRuTorrent" Container is based on rTorrent 0.9.2 (for compatibilty, some private trackers have not updated to 0.9.4 yet) Hi folks, Ever since moving to unRAID I have been missing the power and flexibilty (including native RSS support) given by rTorrent&ruTorrent as a torrent client. (See the full list of ruTorrent plugins here: ) As a result I have made a rTorrent/ruTorrent container for use with unRAID Docker. Just add my repo: https://github.com/CaptInsano/docker-containers/tree/templates and ruTorrent will be listed as a container option, follow the instructions in the description and you should be up and running. It is based on phusion/baseimage:0.9.16 and it runs on the nginx webserver so is very resource light. I have picked and choosen from various docker rTorrent/ruTorrent containers to make this work well and easily with unRAID. I hope you enjoy!! The Capt. main credits: https://github.com/nuimk/rutorrent smdion Update 04/06/15 Fixes to nginx and php to allow the upload of .torrent files larger than 1MB in size (both containers) Update: 30/05/15 Fix problems with rTorrent 0.9.2 container and DockerMan (underscore in container names = :'() Change unrar-free to unrar for better compatibilty with autotools (ruTorrent plugin) (both containers) Update: 14/05/15 Initial commits for container based on rTorrent 0.9.2 named: "LegacyRuTorrent" to maintain compatibilty with some private trackers. Update: 23/03/15 (Big Update) 1. Updated to latest rTorrent (0.9.4) and libtorrent (0.13.4) in non-Legacy version 2. Added BASIC auth security: (.htaccess file is created in the /config folder) Default username:password is admin:admin To change this edit the .htaccess file, convert username:passwords into encrypted format here: http://www.htaccesstools.com/htpasswd-generator/ Follow the instructions; one username:password per line. Save file and Restart container 3. Added SSL (default https://SERVERIP:8099) This port can be changed in the Container settings The cert is created on container start and creates a generic server.crt in /config/certs All info in this generic cert is set to "unraid" If you want to swap out this cert with your own (advised) then: SSH into your unRAID server, navigate to the certs folder where you have mapped /config go to this link and follow instructions: http://www.akadia.com/services/ssh_test_certificate.html Make sure the output file is named server.crt Note: This can be done from unRAID itself not within the container Restart the container after replacing the server.crt 4. (Finally!!) Fixed umask of torrent user. umask torrent = 0002 Update: 19/03/15 I have changed the structure of the container so that the ruTorrent directory is in /config. This allows manually editing ruTorrent configs, adding 3rd Party ruTorrent plugins and ruTorrent configs are persistent across updates. Update 16/03/15 Improvement to GIT logic, existing GIT versions will get updated instead of recloned. Update 15/03/15 1.This container now has GIT support to update ruTorrent and it's plugins to the latest GIT versions. Simply set EDGE value to 1 (Turn on Advanced View when adding container). To update; Stop and Restart the container. 2. I have also change some ruTorrent settings to work better within Docker.

Thanks for suggestion, but I'm afraid this will not work, looking at the addition suggested to the GO file I checked around my file system and "/usr/local/emhttp/plugins/webGui/phaze.page" does not even exist on my system. Hopefully we will see native support of b12+ within this plugin soon, until then I'll wait!

I have been unable to get this plugin working on 6b12+. I just attempted with 6b14b, I was going to compile VirtualBox for my kernel myself. I installed the plg using the webui but I could not access the plugin settings page, it was just blank even after a restart. Hopefully it will be updated at some stage!

Sorry was away all weekend. Changes look good, merged to master. Thanks Sparklyballs!! For anyone updating, Sparkyballs changes resulted that I needed to update my Username and Passkey via the webUI. EDIT: No longer an issue, I update the template.xml to reflect the new directory structure within the container. Anyone updating: change "/etc/fahclient" to "/config" in the "Edit Docker" popup. The Capt.

@Darqfallen Some score!! Good job! What are the specs of your unRAID machine? You much be flying through the work units to get that score (417268 at time of post) with that few work units done (42 at the of post). You are averaging 9935 points per work unit, that is amazing!! I am only averaging 155 by comparision!! (My CPU: AMD Athlon 64x2 Dual core 4600+ 2.41GHZ) @everyone Incase anyone is interested (I was, I just read it) here is how points are calculated!! Also Team unRAID is doing great everyone!, with only 8 named members we are in the 96th percentile of all Folding@Home Teams ie: We doing better than 95% of all the teams registered with Folding@Home. Thanks to all, hopefully more unRAID users will join us! The Capt.

As stated above you are better off trying smdion's ddsnix from this post.

Not possible in docker I'm afraid. Docker does not support device passthrough. UnRAID itself would need to have the 301.xx NV drivers included for a container to be able to use the device. It should be possible in a Virtual Machine however if your motherboard supports passthrough, maybe have a look at XEN or KVM or the VirtualBox Plugin. The Capt.

/var/cache/ddclient/ddclient.cache is where DDClient stores the details from ddclient.conf so your problem stems from you ddclient.conf; Looks like you have not provided DDClient a way to get your external IP in the ddclient.conf file: NOTE: As we are running inside docker, I find it is better to use an external IP source such as in my example below. eg: my ddclient.conf. # Configuration file for ddclient generated by debconf # # /etc/ddclient.conf daemon=300 # check every 300 seconds timeout=10 syslog=yes # log update msgs to syslog #mail=root # mail all msgs to root #mail-failure=root # mail failed update msgs to root pid=/var/run/ddclient.pid # record PID in file. ssl=yes # use ssl-support. Works with ssl-library use=web, web=checkip.dyndns.com, web-skip='IP Address' server=xxxxxxxxxxxxxxxxxxx protocol=xxxxxxxxxxxxxxx login=xxxxxxxxxxxxxxxxxx password=xxxxxxxxxxxxxxxx MY.DOMAIN.COM try adding the use=web.... line to your ddclient.conf. As this is smdion's topic; If you have any further issues, please use my separate topic in this forum until smdion may choose to update his docker with these fixes http://lime-technology.com/forum/index.php?topic=38146.0 Thanks, The Capt

(I am creating a new topic for this so users of DDClient will be aware of an update.) As reported in smdions Docker Repository Thread here, the DDClient container was not working correctly. I have forked smdion's DDClient container and made some fixes to it: Added missing SSL dependency for DDClient Config file now in correct place with correct symbolic links DDClient now starts as a foreground service from runsv resulting in only one instance running as expected inotify restarts DDClient gracefully on edit of ddclient.conf To get the fixed DDClient Container: First you add https://github.com/CaptInsano/docker-containers/tree/templates to your repo list in the DockerMan page you can add my updated DDClient container. NOTE: The DDClient log on the DockerMan page of unRAID will list the following error: WARNING: file /etc/ddclient/ddclient.conf: file /etc/ddclient/ddclient.conf must be accessible only by its owner (fixed) This can be safely ignored, it is due to the ddclient.conf file being owner by user nobody instead of root to be editable on unRAID shares @smdion Hopefully you will get a chance to pull these changes into your repo for more people to get the fixes. Thanks again for your work. The Capt.

I have forked smdion's DDClient container and made some fixes to it: Added missing SSL dependency for DDClient Config file now in correct place with correct symbolic links DDClient now starts as a foreground service from runsv resulting in only one instance running as expected inotify restarts DDClient gracefully on edit of ddclient.conf To get the fixed DDClient Container: First you add https://github.com/CaptInsano/docker-containers/tree/templates to your repo list in the DockerMan page you can add my updated DDClient container. NOTE: The DDClient log on the DockerMan page of unRAID will list the following error: WARNING: file /etc/ddclient/ddclient.conf: file /etc/ddclient/ddclient.conf must be accessible only by its owner (fixed) This can be safely ignored, it is due to the ddclient.conf file being owner by user nobody instead of root to be editable on unRAID shares @smdion Hopefully you will get a chance to pull these changes into your repo for more people to get the fixes. Thanks again for your work. The Capt.

Every day is a school day!! Thanks for that, I did not know that!

TBH I think my fix is a little hacky; it works, but now multiple instances of the ddclient are started instead of just one (Could result in over polling your DynDNS provider if left running and result in ban). I think the DDClient launch script inside the container repeatedly launches the DDClient by mistake. If you run this temp fix to the DDClient docker container, you should not leave the docker running for long as there will be loads of DDClient instances running. Hopefully we will get a proper fix soon. SSH into unRAID 1: Run docker ps -a 2: The output will list all your docker containers with an identifying number(letters and numbers) at the beginning of each line. eg: My DDClient entry: 44913ba057e4 smdion/docker-ddclient:latest "/sbin/my_init" 7 days ago Exited (0) 6 minutes ago DDClient 3. Run the following replacing the number with the number from your DDClient container in above step: docker exec -i -t 44913ba057e4 /bin/bash 4. You are now at a command prompt inside your DDClient docker 5. Run the following: cp /etc/ddclient.conf /etc/ddclient/ddclient.conf then exit 6. Stop and Restart Docker from UnRAID WebUI. Your log should show: *Starting ddclient... ...done. I now advise you stop the container Let me know if it works for you, The Capt.

From what I can figure looking at the github from this docker, the "Setting up watches" and "Watches established" log messages refer to to inotify not ddclient starting up, but I may be wrong. Hopefully smdion will chime in and offer his advice. The Capt So I assumed that meant it was using my conf file, but it would explain my problem if the above is correct.

Potiential bug report in DDClient Docker: My DDClient was not updating my IP so I rooted around a bit. According to the Dockerfile, the config file link is placed at /etc/ddclient.conf ln -s /config/ddclient.conf /etc/ddclient.conf but the /etc/init.d/ddclient file is set for .conf file to be at /etc/ddclient/ddclient.conf #!/bin/sh # # Start ddclient that provides support for updating dynamic DNS services. # # Submitted by paolo martinelli DDCLIENT=/usr/sbin/ddclient CONF=/etc/ddclient/ddclient.conf PIDFILE=/var/run/ddclient.pid ..... when I copied the conf file from /etc/ddclient.conf to /etc/ddclient/ddclient.conf and restarted the container my IP updated instantly. Hope this helps, Thanks once again for such great docker containers. The Capt.

Just wondering; As Folding@Home has no native scheduling ability, would people be interested in a crontab scheduling option that would allow people schedule times where FAHClient would run @ Light/Medium/Full Power etc.? From what I have been reading on the Folding@Home wiki it should be possible. I am mainly thinking of people who may be avoiding this container due to already running intensive CPU tasks such as Plex etc. and worrying that it would affect their streams during the day. My Idea: If people had the FAHClient running with "Light" CPU use during the day they would notice no problems with other services from their UnRAID server and then maybe change to "Medium" or "High" CPU use during the night when the server is not in use. Ideas Welcome. The Capt.

Have a look here: https://fah-web.stanford.edu/projects/FAHClient/wiki/ClientDifferencesV6ToV7 and https://fah-web.stanford.edu/projects/FAHClient/wiki/ClientUserGuide It gives a list of options that can be added to the config.xml to set it up as you would like. I will add that link to the OP. @All: I finally figured out the correct mounting and saving of the config.xml. (Thank your BRiT!) Update is now out that fixes it. Both the DockerMan .xml and the container have been updated so hit "Reload Info" on DockerMan prior to re-adding Container. Anyway, bumpy ride but hopefully all is well now!! Thanks for being impromptu beta-testers!!

I have a symbolic link between the correct config.xml location (/etc/fahclient/config.xml) to the accessible config.xml location (/config/config.xml) in the firstrun.sh but for some reason the link does not stick. When you do updates via WebUI or Advance Control it updates the /etc/fahclient/config.xml which only sticks around until the contain is updated. I need to figure out why the ln -s /etc/fahclient/config.xml /config/config.xml is not persistent. I will have another look at it tomorrow, really need some sleep.

yeah it turns out that the FAHClient is too slow exiting for the "docker stop" command so a PID file gets left behind, stoping it from running again after restarting the container. I have to make the container delete any pre-existing fahclient.pid file on boot. ...building now

Alright: Seriously sorry about this!! In updating the config.xm with comments etc. l I left a trailing "/" out of one line, resulting in FAHClint not starting. I have built again and now all is well!! People *MAY* need to delete their config.xml and let the container rebuild it on restart.