New unMENU packages for SABnzbd, Sick Beard and Couch Potato


Recommended Posts

  • Replies 221
  • Created
  • Last Reply

Top Posters In This Topic

Hello,

 

I have not been able to get Couch Poatato to work. I manually installed Sickbeard and SABNZBD about a month ago (prior to these new packages). Now I am interested in CP.

 

I followed the instructions, downloaded the 2 files and copied them to /boot/packages. In unMenu I installed Couch Potato with the default variables.

 

install-dir: /mnt/cache/.couchpotato

install-host: 0.0.0.0

install-port: 8083

 

But when I go to Tower:8083 or 192.168.0.201:8083, it did not find anything.

 

I ran manually  both of these commands with the same results:

 

 

nohup python /mnt/cache/.couchpotato/CouchPotato.py -d & 

python /mnt/cache/.couchpotato/CouchPotato.py

 

After that command, I get a nohup.out file that reposrt the following:

 

/mnt/cache/.couchpotato/app/config/configApp.py:147: Warning: 'with' will become a reserved keyword in Python 2.6
Traceback (most recent call last):
  File "/mnt/cache/.couchpotato/CouchPotato.py", line 38, in <module>
    from app.config.configApp import configApp
  File "/mnt/cache/.couchpotato/app/config/configApp.py", line 147
    with open(self.file, 'wb') as configfile:
            ^
SyntaxError: invalid syntax

 

The contents of my syslog shows the following:

Mar  4 04:40:01 Tower syslogd 1.4.1: restart.
Mar  4 11:04:36 Tower shfs: shfs_setxattr: setxattr: /mnt/disk5/downloads/nzb/CouchPotato r29.zip (95) Operation not supported
Mar  4 11:31:12 Tower in.telnetd[17195]: connect from 192.168.0.190 (192.168.0.190)
Mar  4 11:31:12 Tower login[17196]: ROOT LOGIN  on `pts/0' from `192.168.0.190'
Mar  4 11:34:34 Tower in.telnetd[17236]: connect from 192.168.0.190 (192.168.0.190)
Mar  4 11:34:34 Tower login[17237]: ROOT LOGIN  on `pts/1' from `192.168.0.190'
Mar  4 11:49:40 Tower kernel: mdcmd (26): spindown 3
Mar  4 11:58:34 Tower usermod[17791]: change user `nobody' shell from `/bin/false' to `/bin/bash'
Mar  4 11:58:34 Tower su[17792]: +  root-nobody

 

Sickbeard and SABNZBD are each installed in respective subdirectoies in /mnt/cache/.custom/.

 

Any help or advice would be greatly appreciated. I am a semi-newbie.

 

Thanks,

 

H.

 

 

 

Link to comment

BUMP

 

mrmachine, have you installed the vm to test the install or replicate the problem?  I'm running unraid 4.7 with unmenu, openssl and transmission as the only other addons I've installed.

 

Sorry, I haven't yet had the time to figure out how to get unRAID 4.7 running in a VM under OS X to test this. Did you have any luck resolving the issue on your own?

 

Cheers.

 

Link to comment

Small problem here,  installed Sickbeard (Am working up to the others) all working well but now am getting prompted for a username and password when I try to login to http://server:8081

 

Get this error report

 

401 Unauthorized

You are not authorized to access that resource
In addition, the custom error page failed:
ValueError: invalid literal for int() with base 10: '401 Unauthorized'

Traceback (most recent call last):
  File "/mnt/cache/_sickbeard/cherrypy/_cprequest.py", line 657, in respond
    self.hooks.run('before_handler')
  File "/mnt/cache/_sickbeard/cherrypy/_cprequest.py", line 99, in run
    hook()
  File "/mnt/cache/_sickbeard/cherrypy/_cprequest.py", line 59, in __call__
    return self.callback(**self.kwargs)
  File "/mnt/cache/_sickbeard/cherrypy/lib/auth_basic.py", line 86, in basic_auth
    raise cherrypy.HTTPError(401, "You are not authorized to access that resource")
HTTPError: (401, 'You are not authorized to access that resource')

 

Anybody got any ideas?  Have updated Sickbeard via the link in the application and it has been running fine.

 

I'm a linux newb so not really sure where to go from here.  Has done it before so I just started from scratch to resolve it.  Don't really want to have to do that again.

 

Thanks

 

Neil

Link to comment

Small problem here,  installed Sickbeard (Am working up to the others) all working well but now am getting prompted for a username and password when I try to login to http://server:8081

 

Get this error report

 

401 Unauthorized

You are not authorized to access that resource
In addition, the custom error page failed:
ValueError: invalid literal for int() with base 10: '401 Unauthorized'

Traceback (most recent call last):
  File "/mnt/cache/_sickbeard/cherrypy/_cprequest.py", line 657, in respond
    self.hooks.run('before_handler')
  File "/mnt/cache/_sickbeard/cherrypy/_cprequest.py", line 99, in run
    hook()
  File "/mnt/cache/_sickbeard/cherrypy/_cprequest.py", line 59, in __call__
    return self.callback(**self.kwargs)
  File "/mnt/cache/_sickbeard/cherrypy/lib/auth_basic.py", line 86, in basic_auth
    raise cherrypy.HTTPError(401, "You are not authorized to access that resource")
HTTPError: (401, 'You are not authorized to access that resource')

 

Anybody got any ideas?  Have updated Sickbeard via the link in the application and it has been running fine.

 

I'm a linux newb so not really sure where to go from here.  Has done it before so I just started from scratch to resolve it.  Don't really want to have to do that again.

 

Thanks

 

Neil

 

Could be a bug in the Sick Beard code. Once Sick Beard is installed you can update it to the latest code from the Sick Beard interface. Did you already upgrade it?

 

Link to comment

I believe the username and password are stored in plain text in the config.ini file. Makes it pretty easy to just open the file and figure out the issue.

 

Peter

 

Thanks Peter,

 

That worked a treat, weirdly it seems to have taken a username and password I use for a website login, wondering if it's a firefox issue?

Link to comment

Hi,

 

thanks for the script.

First I made the port-mistake (below 1024).

Then SSL wasn't working. I investigated and it seems SAB needs pyopenssl > 0.6

 

so I changed the package in the script:

 

# pyopenssl

PACKAGE_EXTRA_URL http://repository.slacky.eu/slackware-13.1/system/pyopenssl/0.10/pyopenssl-0.10-i486-2sl.txz

PACKAGE_EXTRA_FILE pyopenssl-0.10-i486-2sl.txz

PACKAGE_EXTRA_MD5 ec0944e7c6327febcc231eeb017fcca5

 

# install pyopenssl

PACKAGE_INSTALLATION if [ ! -d /usr/lib/python2.6/site-packages/OpenSSL ]; then

PACKAGE_INSTALLATION  if [ ! -f /boot/packages/pyopenssl-0.10-i486-2sl.txz ]; then

PACKAGE_INSTALLATION    echo "Required dependency, pyopenssl-0.10-i486-2sl.txz, has not been installed. Please install it before installing SABnzbd."

PACKAGE_INSTALLATION    exit

PACKAGE_INSTALLATION  else

PACKAGE_INSTALLATION    installpkg /boot/packages/pyopenssl-0.10-i486-2sl.txz

PACKAGE_INSTALLATION  fi

PACKAGE_INSTALLATION fi

 

and everything is working :D

just in case someone has the same problem.

 

ah and if someone alters the packages in the .conf the .manual_install has to be deleted.

 

Paul

 

 

Link to comment

First I made the port-mistake (below 1024).

Then SSL wasn't working. I investigated and it seems SAB needs pyopenssl > 0.6

 

Nice catch. I've updated all three scripts with a note that the install port must be higher than 1024, and updated pyopenssl for SABnzbd.

 

Cheers.

 

Link to comment

I'm having a bit of trouble.  I got sabnzbd+ downloaded and installed.  When I click on the user script to start the server, it responds:

 

"mkdir: cannot create directory `': No such file or directory chown: invalid argument: `' SABnzbd started. "

 

I can't get the browser to connect to that port, and unmenu's ps info button doesn't show it among the running processes.  The only thing that I changed from the defaults is that I installed it to /mnt/disk/downloads/.sabnzbd/ which is a reiserfs formatted SNAP drive that loads on boot.

 

Any idea what could be wrong?  It looks like it's trying to create a directory with an empty directory name...  ???

 

Solution: It looks like, for some reason, the log_dir line in sabnzbd.ini didn't get added. I'm not sure what the cause could be, but I added that directory manually and now it's working.

Link to comment

Solution: It looks like, for some reason, the log_dir line in sabnzbd.ini didn't get added. I'm not sure what the cause could be, but I added that directory manually and now it's working.

 

Thanks. The SABnzbd package was writing the log line to the wrong file (config.ini instead of sabnzbd.ini). This has been fixed in the latest version. I've also added debug information to the install and start/stop scripts.

 

Link to comment

Sounds great!

 

I am having one other issue with Sick Beard.  I managed to get it installed and it seems to be up and running.  However, when I try to "Add Shows" and then Add Existing Shows, it won't let me navigate to anything in the /mnt/user/ or /mnt/diskX/ directories.  I just click on /mnt/ and then user/ and it simply sits there like I didn't click anything at all.  I can navigate pretty much anywhere else on the filesystem just fine, including the SNAP-mounted drive that Sick Beard lives on.

 

I thought maybe a permissions issue, but I didn't see any errors in the log.  I can't figure out why it can't navigate there.  I can navigate there from the console, or over SMB from another machine.

 

Any ideas?

Link to comment

I am having one other issue with Sick Beard.  I managed to get it installed and it seems to be up and running.  However, when I try to "Add Shows" and then Add Existing Shows, it won't let me navigate to anything in the /mnt/user/ or /mnt/diskX/ directories.  I just click on /mnt/ and then user/ and it simply sits there like I didn't click anything at all.  I can navigate pretty much anywhere else on the filesystem just fine, including the SNAP-mounted drive that Sick Beard lives on.

 

I thought maybe a permissions issue, but I didn't see any errors in the log.  I can't figure out why it can't navigate there.  I can navigate there from the console, or over SMB from another machine.

 

Sounds like a permissions issue. Sick Beard will (or should) be run as nobody:users and your shares should be owned by nobody:users and have rwxrwx--- permissions for directories and rw-rw---- permissions for files (at least with 5.0 beta 4 -- I haven't tested any other versions).

 

If you're using a different version of unRAID then you might need to change the start/stop script so that it runs as the correct user and ensure that all your shares and Sick Beard files are owned by the correct user/group with the correct permissions.

 

Link to comment

I am having one other issue with Sick Beard.  I managed to get it installed and it seems to be up and running.  However, when I try to "Add Shows" and then Add Existing Shows, it won't let me navigate to anything in the /mnt/user/ or /mnt/diskX/ directories.  I just click on /mnt/ and then user/ and it simply sits there like I didn't click anything at all.  I can navigate pretty much anywhere else on the filesystem just fine, including the SNAP-mounted drive that Sick Beard lives on.

 

I thought maybe a permissions issue, but I didn't see any errors in the log.  I can't figure out why it can't navigate there.  I can navigate there from the console, or over SMB from another machine.

 

Sounds like a permissions issue. Sick Beard will (or should) be run as nobody:users and your shares should be owned by nobody:users and have rwxrwx--- permissions for directories and rw-rw---- permissions for files (at least with 5.0 beta 4 -- I haven't tested any other versions).

 

If you're using a different version of unRAID then you might need to change the start/stop script so that it runs as the correct user and ensure that all your shares and Sick Beard files are owned by the correct user/group with the correct permissions.

 

 

Hmm... both Sick Beard and Sabnzbd are correctly running as "nobody".  All of the mounted volumes are owned by root:root, even the SNAP drive that works.  However, the permissions on the SNAP drive are drwxr-xr-x and the permissions on all the unraid array shares is drwx------.  So, that would seem to suggest that this is a permissions issue.

 

I know that drwxr-xr-x can be set using chmod 755, but is it safe to run that on the UnRAID array drives?  If my Linux is up to snuff, I guess I'd just do chmod -R 755 /mnt/disk1

?

Link to comment

I'm on the latest stable: Version 4.7.

 

Yes, perhaps this is something that has changed.  How difficult is it to change the user the apps run as?  Would I be correct in making the following changes, and the equivalent changes for sabnzbd+?

 

Original:

PACKAGE_INSTALLATION echo "        chown -R nobody:users . \"\$LOG_DIR\"" >> /etc/rc.d/unraid.d/rc.unraid_sickbeard
PACKAGE_INSTALLATION echo "        usermod -s /bin/bash nobody > /dev/null 2>&1" >> /etc/rc.d/unraid.d/rc.unraid_sickbeard
PACKAGE_INSTALLATION echo "        su nobody -c \"python SickBeard.py --daemon > /dev/null 2>&1\"" >> /etc/rc.d/unraid.d/rc.unraid_sickbeard

 

Run as root:root

PACKAGE_INSTALLATION echo "        chown -R root:root . \"\$LOG_DIR\"" >> /etc/rc.d/unraid.d/rc.unraid_sickbeard

PACKAGE_INSTALLATION echo "        usermod -s /bin/bash root > /dev/null 2>&1" >> /etc/rc.d/unraid.d/rc.unraid_sickbeard

PACKAGE_INSTALLATION echo "        su root -c \"python SickBeard.py --daemon > /dev/null 2>&1\"" >> /etc/rc.d/unraid.d/rc.unraid_sickbeard

 

Thanks for your help.  These scripts are great.

Link to comment

I'm on the latest stable: Version 4.7.

 

Yes, perhaps this is something that has changed.  How difficult is it to change the user the apps run as?  Would I be correct in making the following changes, and the equivalent changes for sabnzbd+?

 

Original:

PACKAGE_INSTALLATION echo "        chown -R nobody:users . \"\$LOG_DIR\"" >> /etc/rc.d/unraid.d/rc.unraid_sickbeard
PACKAGE_INSTALLATION echo "        usermod -s /bin/bash nobody > /dev/null 2>&1" >> /etc/rc.d/unraid.d/rc.unraid_sickbeard
PACKAGE_INSTALLATION echo "        su nobody -c \"python SickBeard.py --daemon > /dev/null 2>&1\"" >> /etc/rc.d/unraid.d/rc.unraid_sickbeard

 

Run as root:root

PACKAGE_INSTALLATION echo "        chown -R root:root . \"\$LOG_DIR\"" >> /etc/rc.d/unraid.d/rc.unraid_sickbeard

PACKAGE_INSTALLATION echo "        usermod -s /bin/bash root > /dev/null 2>&1" >> /etc/rc.d/unraid.d/rc.unraid_sickbeard

PACKAGE_INSTALLATION echo "        su root -c \"python SickBeard.py --daemon > /dev/null 2>&1\"" >> /etc/rc.d/unraid.d/rc.unraid_sickbeard

 

Thanks for your help.  These scripts are great.

 

The scripts run as root already, which is why we need chown, usermod and su to run the application as nobody. If you need to run it as root under 4.7, just remove those lines. If you want to try and save your existing install rather than re-installing, you can make the appropriate changes to the .manual_install and .auto_install files, and manually `chown -r root:root` the install and log directories.

 

Link to comment

I've done quite a bit of searching for .manual_install and .auto_install, and I can't seem to find them.  I don't seem them referenced in any of the scripts either, so there were no clues there.  Where are they located?

The *.manual_install file is named after the actual package file (e.g. SABnzbd-0.5.6-src.tar.gz.manual_install) gets created in the packages folder when installing the package.

 

The *.auto_install file likewise gets created when enabling automatic re-install after reboot.

 

Link to comment

I've already set up these three apps using the wiki article http://lime-technology.com/wiki/index.php?title=Install_Python_based_servers, but the stop button doesn't seem to work for me, so I'd like to use your .conf's to update my install to what would seem to be the currently accepted install practices for these apps. I briefly parsed through your scripts to see if I could just quickly replicate your start/stop buttons, but it looked a little more complicated than I wanted to manually work through. If I just put your .conf's in the unmenu package installer and run them, am I going to blow up my currently functioning install?

 

Thanks,

Jonathan

unRaid 4.4.2 Pro with 10 data drives and a cache.

Link to comment

I've already set up these three apps using the wiki article http://lime-technology.com/wiki/index.php?title=Install_Python_based_servers, but the stop button doesn't seem to work for me, so I'd like to use your .conf's to update my install to what would seem to be the currently accepted install practices for these apps. I briefly parsed through your scripts to see if I could just quickly replicate your start/stop buttons, but it looked a little more complicated than I wanted to manually work through. If I just put your .conf's in the unmenu package installer and run them, am I going to blow up my currently functioning install?

 

Thanks,

Jonathan

unRaid 4.4.2 Pro with 10 data drives and a cache.

 

Maybe. I also note that you're using unRAID 4.4.2. Some people have had problems using these scripts in 4.7, and I assume that 4.4.2 would be the same (or maybe even more problems). I think these are mostly due to unRAID 5.0 using different permissions for shares, meaning we need to run the apps as nobody:users which is not necessary on older versions.

 

You could try installing these packages to different locations and on different ports (keeping your old installs intact). If it works, you can migrate your cache/db/settings to the new install. If it doesn't work, you can alter the rc and start/stop scripts to suite your existing install.

 

Link to comment

I've done quite a bit of searching for .manual_install and .auto_install, and I can't seem to find them.  I don't seem them referenced in any of the scripts either, so there were no clues there.  Where are they located?

The *.manual_install file is named after the actual package file (e.g. SABnzbd-0.5.6-src.tar.gz.manual_install) gets created in the packages folder when installing the package.

 

The *.auto_install file likewise gets created when enabling automatic re-install after reboot.

 

 

I wasn't able to get back to this until today, but I made the modifications you suggested.  I didn't want to reboot, so I also changed the scripts in /etc/rc.d/unraid.d/ as mentioned.  I commented out those first two lines, but just removed the "su nobody -c" part from that third line.

 

Fired up both sabnzbd and sickbeard, and I can navigate directories properly in sickbeard.  For those of you on 4.7, I think that's the fix.  I don't know if it's too much to ask, but is there a way to do a version check to select between the two cases?  That might be nice for people still on the stable builds.

 

Thanks for all your help and for creating these scripts.  Even with the hiccup, it still saved me tons of time.  I spent probably a full day getting sickbeard set up on my Mac the first time, so these are a huge time saver!

 

Edit:  Actually, it looks like that only worked in the script in rc.d.  When I rebooted, neither server was restarted and Unmenu shows it as not being installed.  It looks like the autoinstall script must have failed.  I'm trying to figure out why.

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.