Use exitcode other than 0 when a (rsync)source can not be used about routinator

[partim]

We believe that loosing ROAs for unavailable servers is better than loosing updates from available servers. As a case in point, the Chinese repository was unavailable for quite some time (as in: months).

I am, however, happy to add a config option to force an abort in case any of the servers cannot be reached.

[timbru]

I believe that such a knob would allow any incompetent or malicious delegated CA (or to be precise publication server) to DoS the system. So, I would urge that this is not used at all, or with extreme prejudice.

[partim]

Fair point!

Also note that rsync failing doesn’t mean that server’s data is ignored. Whatever is there already is still used. So if the rsync server has a short outage, you probably won’t even notice, unless, of course, this is the first time you run Routinator.

[tuxis-ie]

I would like to investigate if a repo is down, and maybe it is my own fault. I think an option where you get a warning about unreachable sources with another exit-code is useful. I understand the design choices before, but imho this it too silent.

[timbru]

If you are talking about a one-off validation run, like with the 'vrps' sub-command, then I can see your point. However, if the routinator is running as a daemon as with the 'rtrd' option, then I think it would make more sense to have a dedicated status end-point that reports on repo availability.

[mahtin]

I’d vote for this to be a command-line/config-file option. A user may want to run in “strict mode” (whatever that means).

Additionally, I’d remind all that exit codes are vital to any automation framework - independent of which path to exit.

[tuxis-ie]

I'm talking about the vrps command indeed.

[partim]

We’ll add a command line option to the vrps command.