Bug#987332: aprx automatically starts up with really bad default config
On Sun, 25 Apr 2021, Evgeni Golov wrote: On Sun, Apr 25, 2021 at 03:41:38PM +0300, Heikki Hannikainen wrote: This would be very important to make this happen. Shipping a config with the "mycall N0CALL-1" line commented out would probably work. 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. Right, a failed upgrade would not be good. 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?). There is no use of the daemon when it is running with its default config. It doesn't do anything useful, it just connects to the server and sits there. To make it useful, the config needs to be updated with a correct callsign, some configuration to attach it to a radio interface, and possibly beaconing config. 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. Right, something like a grep for the bad "^mycall\s+N0CALL-1" would be a suitable trigger. - Hessu
Bug#987332: aprx automatically starts up with really bad default config
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. - 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. - Hessu
Bug#987332: aprx automatically starts up with really bad default config
Package: aprx
Version: 2.9.0+dfsg-2
I just noticed that many of the aprs2.net APRS-IS servers have a whole lot of
aprx 2.9.0 clients connected using the N0CALL-1 dummy callsign, having sent
zero packets. There are probably hundreds of these clients, T2UKRAINE currently
and T2FINLAND has 67. I didn't even check other servers (there's a
hundred).
After some looking around I found out that the aprx package in Debian these
days has the following flaw:
If you just install it ("apt install aprx"), it will start up automatically and
by default, and it will actually connect to the APRS-IS network using the dummy
callsign (which one should never use) and stay connected.
I suspect this bug came up in aprx (2.9.0+dfsg-2), right here:
- Update aprx.default to remove environment STARTAPRX variable for
daemon enable/disable for Debian Policy ยง 9.3.3.1
- Update aprx.init script to remove /etc/default check for daemon
enable/disable
The old default was that it did not automatically start up before
STARTAPRX was manually adjusted in /etc/default/aprx.
Please release a high-priority update which shuts down these clients which have
been automatically started up by this change.
- Have it not start up by default after installation, before it is configured
- 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
- Ensure that the instances which have already been started up like this will
shut down again when upgraded to the next version
Assuming that these clients run with the default configuration file
supplied, one fix would be to intentionally break the default
configuration file so that the startup fails. If the user has not modified
the config file, an upgrade would replace it.
Thank you!
- Hessu, OH7LZB (aprs.fi, aprsc server author)
