DroboApp bundle announcement: the Usenet Bundle for FS/5N

Forum History DroboApps
1

Hi everyone,

Today we have something different. This is an announcement for a bundle of apps that are supposed to work together.

Did you know that the FS/5N can be perfect, state-of-the-art media managers? If you combine SABnzbd (downloader), SickBeard (TV show manager), CouchPotato (movie manager), and Headphones (music manager), you can have the Drobo catalog, rename, tag and organize all of your media collection.

All that is needed to start is an SSH connection to the Drobo, and wget from DroboPorts.
Here is the complete list of steps: http://www.droboports.com/app-repository/usenet-bundle

Disclaimer: This is not an endorsement of piracy. Please do not break any laws, and support your local artists.

Warning: The DroboFS does not have enough RAM to run all of these apps together. If you do so, there is a very high chance that your FS will freeze due to out-of-memory kernel panics. Although these do not necessarily cause data loss, there is a chance that it could happen.

As usual questions, suggestions and feedback are welcome.

2

Hi Ricardo,

I’ve decided to give Sabnzb+ another go to install (perviously i’ve been using nzbget)

when i go to start the service I get the following code:

[code]

./service.sh start

Traceback (most recent call last):
File “/mnt/DroboFS/Shares/DroboApps/sabnzbd/app/SABnzbd.py”, line 44, in
import cherrypy
File “/mnt/DroboFS/Shares/DroboApps/sabnzbd/app/cherrypy/init.py”, line 156, in
from cherrypy._cperror import HTTPError, HTTPRedirect, InternalRedirect
File “/mnt/DroboFS/Shares/DroboApps/sabnzbd/app/cherrypy/_cperror.py”, line 3, in
from cgi import escape as _escape
File “/mnt/DroboFS/Shares/DroboApps/python2/lib/python2.7/cgi.py”, line 51, in
import mimetools
File “/mnt/DroboFS/Shares/DroboApps/python2/lib/python2.7/mimetools.py”, line 6, in
import tempfile
File “/mnt/DroboFS/Shares/DroboApps/python2/lib/python2.7/tempfile.py”, line 34, in
from random import Random as _Random
File “/mnt/DroboFS/Shares/DroboApps/python2/lib/python2.7/random.py”, line 881, in
_inst = Random()
File “/mnt/DroboFS/Shares/DroboApps/python2/lib/python2.7/random.py”, line 97, in init
self.seed(x)
File “/mnt/DroboFS/Shares/DroboApps/python2/lib/python2.7/random.py”, line 111, in seed
a = long(_hexlify(_urandom(16)), 16)
OSError: [Errno 13] Permission denied: ‘/dev/urandom’[/code]

3

Yeah… I can tell you are not using my OpenSSH app, are you? :slight_smile:

The permissions on several key devices is messed up on the FS/5N. This is how you fix it:

chmod a+rw /dev/null
chmod a+rw /dev/full
chmod a+rw /dev/random
chmod a+rw /dev/urandom
chmod a+rw /dev/tty
chmod a+rw /dev/ptmx
chmod a+rw /dev/zero
chmod a+rw /dev/crypto

I’m going to add that to the page, as it has been a recurrent problem.

4

Thanks.[hr]

Does this reset after a reboot of the DroboFS? EDIT: after several reboots I’m going to say this is definitely the cause of permissions resetting

I restarted the machine, and could only get it to start again by executing the above commands again. Is there a more permanent way to do this?

5

Can I create a file in the etc/init.d/ directory with the following?

#!/bin/sh

chmod a+rw /dev/null
chmod a+rw /dev/full
chmod a+rw /dev/random
chmod a+rw /dev/urandom
chmod a+rw /dev/tty
chmod a+rw /dev/ptmx
chmod a+rw /dev/zero
chmod a+rw /dev/crypto
6

Nope, that won’t help. The init.d folder does not work like normal Linux distributions.

A more “Drobo-like” solution would be to create a pseudo-DroboApp, that is, a new folder in the DroboApps share, then put a service.sh file in there with that same content. Either that or edit the service.sh files of the usenet apps to add those chmod commands to them.

The thing is that I don’t think that it’ll be necessary to do so, at least until the next firmware upgrade.

7

Ok thanks, I’ll add them to the Usenet apps service.sh file so they happen before the python execution. I’ll let you know how that goes.

I assume from your reply that this is a basic firmware mistake and should be corrected soon from DRI?

On another note, I’ve gone back to NZBget over SABnzb. I find that especially on the FS it seems a little more stable and less of a memory hog. Great port from Ricardo, and if anyone is having problems with SABnzb then please go have a look at NZBget.

8

Well, it has been there since firmware 1.1.1 for the DroboFS, and persists still in the latest firmware for the 5N. I don’t think this is going to be fixed anytime soon.

Thank you for the kind words. I agree with you, I don’t think that SABnzbd is a good match for the FS. Maybe if it is only SABnzbd and one of the other apps it would work, but if you want the trio then NZBget is basically the only choice.

9

I am working through the install instructions for these and I am not sure what I am doing when I get to the following.

[code]cat > service.sh << “EOF”
#!/bin/sh

SickBeard service[/code]

What do I need to know that is different about these than any other commands? Why do I get a < prompt instead of a # prompt after the first line? How should I proceed?

Thanks

10

Sorry about not explaining it better. This is a common Unix trick to create a file and write its content in one pass.

‘cat’ is a command to print a file to the screen. The ‘>’ sign indicates that you want to send the output to the file ‘service.sh’ (and replace it if it exists) instead of the screen. The ‘<<’ sign means instead of reading the input data from another file, you want to use the data that will be typed in. ‘EOF’ indicates the token that will end the text input, and the double quotes mean that the shell should write the text as-is (no variable evaluation, for the geeks out there).

In other words, that line means: “write the text starting on the next line to the file service.sh (replacing it if it exists) just like I type it until you find the characters EOF”.

TL;DR: We’re perverting cat to do the exact opposite that it was supposed to do! :smiley:
Instead of reading from a file to write on the terminal, we’re reading from the terminal and writing to a file.

The ideal way to use it is just to copy the whole block, starting with that line until (and including) the EOF line, and pasting it on your terminal.

11

Nice. Thanks for the education. Now I understand.

After all are installed, do these start automatically on Drobo startup? Or is the issue that dOOski spoke of a few posts back related to that? Just need to know what needs to be done anytime my Drobo reboots.

Thanks

12

The ./service.sh file created by doing the above are the apps startup scripts, so yes they do start on boot. However my problem was that they wouldn’t start on a reboot as the permissions of those files under /dev mentioned were wrong and would allow it to (got errors). I just entered the chmod commands to the startup script to get around this (not sure if it’s the most elegant way of doing so)

13

The engineering term for this is “good enough.” :slight_smile:

14

Is this because of the permissions?

# ./service.sh start
PID file '/mnt/DroboFS/Shares/DroboApps/sickbeard/var/sickbeard.pid' already exists. Exiting.
# ./service.sh status
SickBeard is enabled and stopped
15

I’m not sure what the reason is, but I had the same problem. Deleeting the pid file and starting the service again via ssh solved the problem, but it came back after reboot.

So I edited the ./service.sh file again to add this line to remove the pid file if it existed before startup (if that’s what it’s even doing):

 rm -f ${pidfile}

Infact this is what the whole file is after I made my “bash it with a hammer” modifications. Again not sure if this is the correct way, but it now works flawlessly for me even after reboot.

[code]#!/bin/sh

SickBeard service

chmod a+rw /dev/null
chmod a+rw /dev/full
chmod a+rw /dev/random
chmod a+rw /dev/urandom
chmod a+rw /dev/tty
chmod a+rw /dev/ptmx
chmod a+rw /dev/zero
chmod a+rw /dev/crypto

. /etc/service.subr

prog_dir=dirname \realpath $0``

name=“SickBeard”
version=“1”

python=$DROBOAPPS_DIR/python2/bin/python
pidfile="${prog_dir}/var/sickbeard.pid"
user=sickbrd

create_user() {
grep -q “^${user}” /etc/passwd 1> /dev/null 2>&1
if [ $? -ne 0 ]; then
adduser -S -H -h “${prog_dir}/data” -D -s /bin/false -G nobody “${user}” 1> /dev/null 2>&1
fi
}

start() {
create_user
chown -R ${user} “${prog_dir}”
rm -f ${pidfile}
su ${user} -s /bin/sh -c “${python} ${prog_dir}/app/SickBeard.py --datadir ${prog_dir}/data --daemon --pidfile ${pidfile}”
return 0
}

case “$1” in
start) start_service ;;
stop) stop_service ;;
restart) stop_service ; sleep 3 ; start_service ;;
status) status ;;
*) echo “Usage: $0 [start|stop|restart|status]” ; exit 1 ;;
esac
[/code]

16

Yup, your corrections are pretty much on the spot. I updated the page on DroboPorts to reflect these changes.

17

I feel like I have to mention that this is great! I have been running these 4 applications on my Drobo FS for almost a year now and in the beginning I had to utilize whatever I could find, and some trial and error, to get them set up and working. I have experienced the freezes and lock ups and other things that I was just trying to deal with as best as I could.
Now that ricardo has put them together with install instructions on Droboports, I am actually reinstalling them following his instructions, with hopes that they will work a little better, because they are done the right way as opposed to my “figure it out” way. And the fact that Couchpotato is version 2 is what I am probably most excited about because I just could not get version 2 (couchpotato server) to work at all. Thanks to everyone who works on these things for us!

I am curious about nzbget. If I use it instead of SABnzbd, will I be able to run all the programs at the same time without the freezing / locking up?

18

I am running into a problem somewhere. When I start sickbeard from ssh everything goes fine. But when I stop it, at first it appears to stop correctly. Then 2 or 3 seconds later I get a Traceback as shown below.

# ./service.sh start
# ./service.sh stop
# Traceback (most recent call last):
  File "/mnt/DroboFS/Shares/DroboApps/sickbeard/app/SickBeard.py", line 354, in <module>
    main()
  File "/mnt/DroboFS/Shares/DroboApps/sickbeard/app/SickBeard.py", line 347, in main
    time.sleep(1)
  File "/mnt/DroboFS/Shares/DroboApps/sickbeard/app/sickbeard/__init__.py", line 887, in sig_handler
    saveAndShutdown()
  File "/mnt/DroboFS/Shares/DroboApps/sickbeard/app/sickbeard/__init__.py", line 915, in saveAndShutdown
    os.remove(PIDFILE)
OSError: [Errno 2] No such file or directory: '/mnt/DroboFS/Shares/DroboApps/sickbeard/var/sickbeard.pid'

I must have something going on since I installed before your latest update on DroboPorts. I made the changes to the service.sh file as DroboPorts currently shows. I even tried using d00ski’s service.sh that he posted above and had the same results.

19

This is perfectly harmless.

If you look at service.sh you’ll see that it reuses the content of the file /etc/service.subr. In that file, if you look for “stop_service ()” you’ll find the function that is used to stop a DroboApp. In that function there is a line “rm -f $pidfile”. It is line 183. So what this means is that the DroboApp support scripts will automatically remove the pidfile for you when you stop the app. This is ok, and actually quite helpful.

The problem is that sickbeard itself tries to delete the pidfile as well when it receives a shutdown command. Then we have what is called a race condition between service.sh and SickBeard.py to see who is going to delete the pidfile first. If SickBeard.py deletes the file first, then you get no error message. If service.sh deletes the file first, then you get that error message.

In any case the pidfile is deleted, and sickbeard exited. No harm, no foul. I agree it does look strange, but it is not a problem at all. Unfortunately, I’m not sure how to make the error message go away, since the proper behavior for sickbeard would be to just ignore the fact that the file he was trying to delete is already gone, and not to make a fuss about it.

20

I don’t run headphones, but couch potato and sickbeard work very well with nzbget without any freezeups.

On a side note with nzbget, I do limit my download speed to 2000 Kbps and made several adjustments to the config file to make it less memory intensive (the fs only has a small cpu and little memory to begin with).