SABnzdb 1.0.1 server test failure

[apextrooper]

In progress of bringing up a new FreeNAS server:
FreeNAS-9.10-STABLE-201604181743 (74ef270)
24G ECC RAM
Plex & Sickbeard plugins appear to be running normally.
Latest SABnzdb plugin installed 1.0.1 [c257b1b]
Configure & test server with the following results:
[Errno 61] Failed to connect (60, '[Errno 65] No route to host') -1@us-secure.news.demon.com:563
DNS route tested with dig is OK.
The old server is running properly: SABnzdb version 0.7.20 running under FreeNAS-9.2.1.8-RELEASE-x64 (e625626). The old server configuration uses the same user credentials as input to the new server. The old server is in an identical network configuration as the new one behind the same router/firewall.

Searched logs without finding a clue.
The error suggests that the username is not configured properly (the 1@ looks like ssh command string). The user credentials are correctly entered and the account is active (the old server likes it just fine :))

Not sure what to try next to diagnose this problem. Any suggestions?

 

[Joshua Parker Ruehlig]

are you sure the host is entered correctly? should it be newdemon instead of news.demon?

 

[apextrooper]

are you sure the host is entered correctly? should it be newdemon instead of news.demon?

Thanks for the feedback. I typed the error message incorrectly into the post. Yeah I know, bad form. :(

I checked the error message again and it is (this time copy & paste):
[Errno 61] Failed to connect: (60, '[Errno 65] No route to host') -1@us-secure.newsdemon.com:563

I double checked the address from the server web page and it is correct as shown and it is the same address and credentials entered in my old server that is running fine.

DNS finds this name from the host command line:
dig us-secure.newsdemon.com

Dig is not installed in the sabnzdb jail, but I can ping the address given by dig from jail command line. I can also reach the host with ssh from the jail, so I think the path is ok.
The error message looks like it is attempting an ssh connection with the host, but the user name is '1' instead of my username. At first glance dmesg is not showing anything suspicious. Seems the error is coming from SABnzdb.

 

[Joshua Parker Ruehlig]

I have no idea where you are getting ssh from?
Can you ping us-secure.newsdemon.com? You say you can ping the IP but I want to see if you can resolve the hostname from the jail

 

[apextrooper]

The error message is suggestive of an ssh login command. So I just entered: ssh name@us-secure.newsdemon.com -p 563 from the jail command line. (where name is my login name)
I was curious if DNS would resolve the path from the jail. It did in fact resolve it because the server actively refused the login request. (instead of a timeout with path not found)
From this I figured that the name was resolved from the jail and did not proceed further. I can try ping from the jail with the server name (instead of ipv4 address) tonight when I get back to my workstation and see if the name is resolved from ping too.

The reason for the association to ssh is that the '1@' in the error message feels like SABnzdb is not filling in my user credentials properly for the server query. I was just probing this suspicion without much success. Probably a blind alley.
Can I expand the logging function to provide more insight into the process leading up to the error message? Is there an additional place to look for log files (other than /var/log)?

Thinking more about this test procedure: the command line functions were performed by the root user. I should try the same test from the SABnzdb user space to see if the results are the same. I think that this user is called "media" right? (I'll investigate this when I return.)

 

[Joshua Parker Ruehlig]

The error message is suggestive of an ssh login command. So I just entered: ssh name@us-secure.newsdemon.com -p 563 from the jail command line. (where name is my login name)
I was curious if DNS would resolve the path from the jail. It did in fact resolve it because the server actively refused the login request. (instead of a timeout with path not found)
From this I figured that the name was resolved from the jail and did not proceed further. I can try ping from the jail with the server name (instead of ipv4 address) tonight when I get back to my workstation and see if the name is resolved from ping too.

The reason for the association to ssh is that the '1@' in the error message feels like SABnzdb is not filling in my user credentials properly for the server query. I was just probing this suspicion without much success. Probably a blind alley.
Can I expand the logging function to provide more insight into the process leading up to the error message? Is there an additional place to look for log files (other than /var/log)?

Thinking more about this test procedure: the command line functions were performed by the root user. I should try the same test from the SABnzdb user space to see if the results are the same. I think that this user is called "media" right? (I'll investigate this when I return.)

your issue has nothing to do with ssh. I dont think changing the user would make a difference.

maybe you can try a fresh install of sabnzbd in a different jail, enter your Usenet credentials and try the test button.

 

[apextrooper]

Tried that already

 

[apextrooper]

Deleted the plugin again this morning. Deleting the plugin also deletes the jail. I checked in the shell that the data set for the jail was removed. When the plugin is installed again, FreeNAS remembered the storage assignments for the plugin but did not mount the share. I thought that it was a little strange because the file system resources were reported as released. So not sure where the old configuration information was retrieved from. The configuration information for SABnzdb was clear, so I started the wizard in the browser to configure it.

I noticed some interesting behavior in the wizard: the servers password is displayed in the clear. After leaving the wizard, the password is hidden with dots "." in the config window. Probably just a minor bug in the wizard server information capture screen. The server test button from the wizard and from the config screen are still failing. Same error codes as before.

I noticed some other odd behavior from the equipment. The volume used for the jail root is reporting healthy. But there are critical drive errors reported for uncorrectable sectors. Ran an offline test of the drive and it is failing. Ordered a replacement, it will be a minute before it arrives.

A note as why this old drive is in the system. This new system build has 4 new drives as an encrypted ZFS pool. FreeNAS has problems operating jails from an encrypted volume, so I harvested this drive from a boneyard machine to add an un-encrypted volume for the jail root. The point of this story is to describe some of the system reconfiguration actions that brought me to my current state. Also, the first time that the SABnzdb plugin was installed, the jail root was assigned to an encrypted volume... it had the same problem there.

On a side note: The DNS path is resolved by ping from the jail. Same address reported as found with dig from the host.

The nature of the error report from SABnzdb seems like an application configuration problem: something that I have not entered properly or a new configuration setting that is missed. I've deleted and recreated the jail with this plugin three times now and entered the server information each time. I verified the server credentials with the provider and against a currently running SABnzdb installation. I will run this circuit once more, but I'm not expecting a different result.

I'm a bit frustrated at this point, and my next action will probably be more heavy handed. I intend to reload FreeNAS and start the install over once the new drive arrives.
Any other suggestions for resolving this problem?

 

[Joshua Parker Ruehlig]

Deleted the plugin again this morning. Deleting the plugin also deletes the jail. I checked in the shell that the data set for the jail was removed. When the plugin is installed again, FreeNAS remembered the storage assignments for the plugin but did not mount the share. I thought that it was a little strange because the file system resources were reported as released. So not sure where the old configuration information was retrieved from. The configuration information for SABnzdb was clear, so I started the wizard in the browser to configure it.

I noticed some interesting behavior in the wizard: the servers password is displayed in the clear. After leaving the wizard, the password is hidden with dots "." in the config window. Probably just a minor bug in the wizard server information capture screen. The server test button from the wizard and from the config screen are still failing. Same error codes as before.

I noticed some other odd behavior from the equipment. The volume used for the jail root is reporting healthy. But there are critical drive errors reported for uncorrectable sectors. Ran an offline test of the drive and it is failing. Ordered a replacement, it will be a minute before it arrives.

A note as why this old drive is in the system. This new system build has 4 new drives as an encrypted ZFS pool. FreeNAS has problems operating jails from an encrypted volume, so I harvested this drive from a boneyard machine to add an un-encrypted volume for the jail root. The point of this story is to describe some of the system reconfiguration actions that brought me to my current state. Also, the first time that the SABnzdb plugin was installed, the jail root was assigned to an encrypted volume... it had the same problem there.

On a side note: The DNS path is resolved by ping from the jail. Same address reported as found with dig from the host.

The nature of the error report from SABnzdb seems like an application configuration problem: something that I have not entered properly or a new configuration setting that is missed. I've deleted and recreated the jail with this plugin three times now and entered the server information each time. I verified the server credentials with the provider and against a currently running SABnzdb installation. I will run this circuit once more, but I'm not expecting a different result.

I'm a bit frustrated at this point, and my next action will probably be more heavy handed. I intend to reload FreeNAS and start the install over once the new drive arrives.
Any other suggestions for resolving this problem?

it sounds like an application issue and reinstalling probably won't make a difference. I know sabnzbd had another release 1.0.2
I'd check the changelog to see if that fixed any related issues. I'll also build the plugin for it when I get a chance.

 

[apextrooper]

I checked release notes back to SABnzdb 0.7.20 (this is the version that is running on my old server.)
I noticed the following in the release notes for 0.8.0 Beta 6:
SSL protocol by default auto-negotiated with server

While ssh may not be a problem, it looks like a change was made in the default exchange protocol with servers. Could be something up with my selected provider.
Is there a repo of past plugin versions so I can try to regress to 0.7.20 and see if the behavior is any different? (happens to be the one before 0.8.0 beta)
I don't really want to slog through the install from the source repo for the regression ;)

I wonder if I can simply export the plugin from the old server (FreeNAS 9.2.1.8) to the new one. A quick glance at the documentation provides no help for porting plugins from one machine to another. Any suggestions with this process?

 

[Joshua Parker Ruehlig]

The old versions are available here http://download.freenas.org/plugins/9/x64/
You can backup/restore /var/db/sabnzbd which has your config and other metadata.

Possibly you are having SSL issues connecting with your server, maybe you need a local certificate chain available?
These steps should have done that for you https://github.com/josh4trunks/free...lugins/sabnzbd/scripts/post-install.sh#L12-14

 

[apextrooper]

Thank you for the link. I loaded the 0.7.20 plugin and it works properly.:D (well at least the server test succeeds, I need to compete the integration but I do not expect trouble.)

This result sort of closes this question but there is more to do, because I'd like to resolve the problem with the latest version.

Not sure about the local certificate chain issue. I'd have to investigate that further.
This appears that it could be a SABnzdb issue. Shall I take this question to that group? or are you connected with it from the FreeNAS forum?

If this is the end in this forum, please accept my gratitude for your help. Looking back at this thread, there was a lot of work here and you were a huge help!

 

[Joshua Parker Ruehlig]

sabnzbd has its own forum, they might have some experience with that Usenet server

welcome!

 

[apextrooper]

This question has bee posted to the SABnzdb forum:
http://forums.sabnzbd.org/viewtopic.php?f=3&t=20718

 

[jasn]

I posted a response to the SABNzbd forum thread with a possible solution. I was able to correct this for myself by taking a cue from the comments in this thread. Going into Config -> Switches -> Server and changing;

Code:

Allow load-balancing with optimization for IPv6

to

Code:

Allow load-balancing

Then restarting SABNzbd, got everything working correctly.

Good Luck..