@reconfigure_ssl errors can lock out wizards about fuzzball

[WolfWings]

As someone coming back to FBMuck after many years absence, my thought is the 'alternative port' solution is likely the best IMHO.

Make direct changes to the SSL tuning only apply to the alternate port, with a separate command just for applying the 'alternative port' settings to the 'live port' ones instead, with no direct way to apply changes to the live port.

That would keep the code from exploding in complexity, current workflow would work with one additional '@apply_ssl' command or whatever is decided on. And for graceful failure if the alternative port allocation fails the only thing it would break is the @reconfigure_ssl command, so the MUCK as a whole will still load and can give 'in-game' errors to the wizards that try to use the command so they can get things fixed.

Could wizards actually be locked out because of this?
ssh account@muckserver
nc localhost nontlsporthere
(or use telnet instead of nc if so desired)

[tanabi]

@wyld-sw asked me to weigh in.

My 2 cents are, this sounds like a lot of work for an edge-case sort of thing. If we do anything, we should validate the SSL configuration better at @ tune time or at @ reconfigure_ssl time if necessary. If you lock yourself out of the MUCK... the worst case is you send a TERM signal to shut it down clean, and start it back up again on a not-secure port, fix it, put it back.

If it's not this way already, the SSL settings should only be changeable by One to avoid people without shell access from mussing up the joint. It may already be this way (didn't check).