SABnzbd Forums

Hi,

How about a file to import and/or export News Server Settings into SAB? It should be a universal format, that can be used by all newsserver providers and newsserver clients.

Reasons:
1) I run SABnzbd on different machines (netbook, laptop, desktop) each with a few newsservers. I find it annoying (and error-prone) to type/copy/paste in the newsserver settings on each machine. The proposed file would solve this.
2) newsserver providers could use this format the give their clients the right newsserver settings.

With the proposed file supported by SABnzbd, you could import all your newsserver with a mouse click. (Just like you import a NZB to get all post pointers)

The file should contain:
- newsserver FQDN
- account/password
- max number of threads
- port
Optional:
- name for nameserver setting (for example: "ipv6 xsnews - sanderj")
- retention time
- SSL yes/no

Maybe the file could contain more than one server, for example a newsprovider providing both SSL and non-SSL-servers, and for exporting all SAB-newsserver-settings in one file.


Format of the file could XML, JSON or INI-style.
Extension could be .NSS (NewsServer Settings)

Below is an example in INI-style, stolen from sabnzbd.ini, leaving out the non-relevant stuff.

I guess it's quite easy to write a (separate) prototype python script that can import and export newsserver setting, but I'm especially interested in the thoughts of others.

So: Looking forward to your comments.


[servers]
[[newszilla6.xs4all.nl - nousername]]
username = ""
name = newszilla6.xs4all.nl
connections = 3
ssl = 0
host = newszilla6.xs4all.nl
password = ""
port = 119
[[news.lightningusenet.com - blabla]]
username = blabla@lightningusenet.com
name = news.lightningusenet.com
connections = 5
ssl = 0
host = news.lightningusenet.com
password = blalba
port = 119

Nice idea, but I'd rather use XML format.

One side effect that I do worry about is security.
Currently, both the web UI and the API do not send passwords, but asterisks.
So currently there is no way to get at any password, except if you have
direct access to the sabnzbd.ini file.
This feature would mean a way to get at the passwords.
Any suggestions?

shypike wrote:
Nice idea, but I'd rather use XML format.

OK. Can you explain why XML is better in this case? More formatting / checking?

shypike wrote:
One side effect that I do worry about is security.
Currently, both the web UI and the API do not send passwords, but asterisks.
So currently there is no way to get at any password, except if you have
direct access to the sabnzbd.ini file.
This feature would mean a way to get at the passwords.
Any suggestions?

Do you mean this: someone else (with access to the SAB webinterface) could export the password to a plain text file?

EDIT:

If so, the solution could be: a WebGUI button to export to settings.NSS into the same directory as sabnzbd.ini (and thus not directly downloadable). You'll have then the same level of security.

Shypike,

What do you think about my solution (see the EDIT in the previous post)?

It's noted. But not for 0.6.0.

shypike wrote: It's noted. But not for 0.6.0.

I don't want to hurry you, but I would like to do things myself (with your advice). For example: would this be a good XML format:

Filled out it would like this:

That would do, except it's common practice to use lowercase keywords.
And it's better to use the names of the INI file.

Personally I would like to replace the sabnzbd.ini file with an XML file too.
Then we could also get rid of the INI file module.

BTW how useful is this?
I think you could write a small Python or Perl script to extract/insert
the [[servers]] section from the INI file.
The intended audience isn't very big.

shypike wrote:
BTW how useful is this?
I think you could write a small Python or Perl script to extract/insert
the [[servers]] section from the INI file.
The intended audience isn't very big.

Well, my goal/hope is that newsserver providers like eweka, xsnews, giganews, etc, could send their settings via such a .NSS files. That would be good for the business.

Do you agree?

I could contact such a provider, and ask them.

In that case, you should include the retention time too

BTW: some apps (like SpotNet) come with a database of provider settings.