animetosho / Nyuu

Flexible usenet binary posting tool
225 stars 33 forks source link

Request: better warning system for mismatched config files #9

Closed RollingStar closed 7 years ago

RollingStar commented 8 years ago

Sorry to make so many issues. With the build in the releases page:

NNTP connection failed: Unexpected response to auth pass (code: 482): Username or password incorrect.

With the latest EXE from releases and an overwrite of the new commits:

NNTP connection failed: connect ECONNREFUSED 127.0.0.1:119, reconnecting after 5 second(s)...

Hasn't worked for several days, maybe a week. The builds I'm using are identical to what I was using fine before. I checked the user/pass multiple times and even manually telnetted into the server with the same password, so I think it's okay. Happens on a normal account and a block account. Successfully uploaded with jBinUp on the same account after encountering these issues with nyuu. Things I can think of:

  1. ISP issues, either accidental or malicious blocking of traffic that looks like usenet (but downloads still work)
  2. IPv4 vs v6
  3. SSL (I always enable on nyuu)
  4. the server I use doesn't like something about nyuu or the articles I post, but this is very similar to what I successfully posted with jBinUp (maybe a recent change in article size limit? I haven't tried dropping those parameters down, and I think jBin has lower sizes)
  5. Win10 anniversary update, I can't remember if I got a successful upload since the time my PC became anniversary-ified
animetosho commented 8 years ago

Actually, I really appreciate every issue you raise - it helps a lot in building a solid application, so thanks for the reports! :)

A few questions/points:

It's hard to figure out what your server may be doing from here. Nyuu's authentication procedure is fairly simple: connect, AUTHINFO USER then AUTHINFO PASS. I presume your telnet testing is basically doing the same?

RollingStar commented 7 years ago

After some annoying bughunting, I found your first point was correct. But not for my lack of trying! I specified -C myconfig.js with the options I wanted, including the server. Nyuu seems no longer able to read my alternative config file. :\

I swear I haven't changed anything about my setup. In reality, this cannot be true, but that's what it feels like.

Anyway, to fix it I copy-pasted everything in myconfig.js to the bottom of config.js. I still specify -C C:\mypath\myconfig.js but I doubt it's doing anything. And in config.js, I removed }; and module.exports = {, to join the two files together. I assumed that nyuu would overwrite anything in the first part of the file with stuff from the second part if the variable names overlapped.

animetosho commented 7 years ago

The config file structure has changed since v0.2.4 to accomodate the new multi-server support. Previously, you could only connect to one server (and optionally a different server for checking) but in v0.3.0 Nyuu will be able to connect to multiple hosts at the same time, so a structural change is needed so that multiple servers can be specified.

At this early stage of development, I'm not particularly interested in maintaining backwards compatibility, but I should perhaps at least provide a warning of sorts. I am maintaining compatibility with the CLI arguments of sorts (though I still can't guarantee it), so it may be more ideal to have a batch file set up with the typical options you use. Still, be aware that things may change when upgrading at this stage.

If you're looking to use the config file though, you'll need to port your changes across to the new structure. You can do this by comparing your config file with the stock config.js, using something like WinMerge, then make the corresponding change in a copy of the new version of config.js. For proper operation, you'll need to repeat this every time the stock config.js changes, unfortunately.

I assumed that nyuu would overwrite anything in the first part of the file with stuff from the second part if the variable names overlapped.

This appears to be true in Javascript, however, in this instance, the name has also changed, so the overwriting won't work (and even if you changed the name, it won't work, because the structure of the servers value is different now).

Apologies for the trouble caused. As Nyuu matures, I'll be looking to maintain backwards compatibility more. I'll probably also look into a better config file system (the current one was more of an afterthought as opposed to something meant to be particularly useful :/).

RollingStar commented 7 years ago

Backwards compatibility can be ignored or not worried about much for what looks like a hobby project. I'm fine with it not working, but I didn't get any error messages that explained what was going on. My config is not very detailed so I can port it over fairly easily.

For proper operation, you'll need to repeat this every time the stock config.js changes, unfortunately.

Say the stock config.js is updated with a new option: foo = true. Can I update the stock config.js from the repo and keep specifying -C myconfig.js? From reading the config file, values should be filled from myconfig.js then anything missing comes from config.js. If I'm fine with foo = true, would I need to update the config?

For the future, maybe have something like this in the config? builddate = 2016-10-03 And have nyuu read it?

Warning: expected config builddate 2016-11-05, but got 2016-10-03.
Some config settings may be applied incorrectly, or the program may not work at all.

I use builddate rather than a version check because each repo change does not always get a new version number.

Can I delete / move the default config.js if I want a more easily debuggable setup? Will nyuu just load from -c myconfig.js, then look for required settings in config.js, fail to find them / the file, then fail? And if it doesn't need anything else from config.js (if myconfig.js is up to date and set up correctly), would it work correctly?

animetosho commented 7 years ago

Thanks for your suggestions. I've decided to take a slightly different approach though.

In line with simplifying the default help text, I've decided to move towards a simpler config structure, which is very similar to CLI arguments. In a way, it isn't really better than specifying the arguments in a batch file or alias, but I suppose it's what people are used to.

This should be better with compatibility, since I'm maintaining CLI compatibilty more than config.js

From reading the config file, values should be filled from myconfig.js then anything missing comes from config.js

You are correct.

Can I delete / move the default config.js if I want a more easily debuggable setup?

Nyuu will always read in the default config.js file. The -C option just overrides what's there.

RollingStar commented 7 years ago

Cool.