[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#987332: aprx automatically starts up with really bad default config



On Sun, Apr 25, 2021 at 03:41:38PM +0300, Heikki Hannikainen wrote:
> On Sun, 25 Apr 2021, Evgeni Golov wrote:
> 
> > On Thu, Apr 22, 2021 at 12:19:57AM +0300, Heikki Hannikainen wrote:
> > 
> > > - Remove N0CALL-1 from the default configuration (comment the line out) so
> > > that it will refuse to start up before configured with the callsign of the
> > > user
> > 
> > Is N0CALL-1 part of the default config aprx ships upstream?
> 
> I am afraid it is. Not sure if debian ships the upstream default config file
> or its own.

Looks like it's shipping upstream, yeah.

> > > - Ensure that the instances which have already been started up like this
> > > will shut down again when upgraded to the next version
> > 
> > Not sure this is easily doable after the fact now, but we at least can
> > prevent new clients from poping up.
> 
> This would be very important to make this happen. Shipping a config with the
> "mycall N0CALL-1" line commented out would probably work.

I am not the maintainer of aprx, just someone who wants to fix a bug,
so I'd prefer not to have the last call on this, but let me give you my
view:

If we change the default config, but let the service enabled, it will
fail to start (which is *technically* what you want, as it will prevent
wrongly configured installations from connecting to you). At the same
time, everyone who updates from Buster to Bullseye (and has the bad old
config) will face a failed upgrade and has to search why it failed, what
they have to fix and then restart the upgrade.

We're not breaking a working service with this approach, but it also
feels weird towards the user (even if we can question why they have aprx
installed, when it's not properly configured -- or is there any use
without the daemon running correctly?).

I think it should be possible to detect the "N0CALL" configurations on
upgrade and disable the service, thus reaching the same state as with my
above change for new installs.

This, plus some documentation in README.Debian would make the user
expirience much better than a failed upgrade?

Evgeni


Reply to: