I haven’t seen many posts on this so not sure what the community thinks about this, but I don’t like to have devices hanging around on my network that aren’t running their most recently patched/updated software for the sake of security concerns.
With that said, I appreciate SSH being locked down out of the box, but on the other hand, it makes it challenging to upgrade the underlying packages (I installed an image dedicated to PiAware) without access to the underlying CLI. I just enabled SSH but wasn’t sure if there was a general practice and understanding about why this administrative function isn’t already cared for by the PiAware dashboard, etc. Seems a little questionable that these updates seemingly aren’t being performed and/or give no way for users to complete those updates out of the box considering the repos are tied to Flightaware as it is already.
The short version is that running an unattended upgrade on a device that might have arbitrary modifications and might be hosted by a user that may know nothing about the internals of the device is mildly terriifying. We really don’t want to break things. For users that are familiar with the system, we also don’t want to stomp on their toes by pushing out system-wide upgrades unexpectedly.
What we do do is add dependencies to piaware-release for security updates that affect unmodified piaware sdcard image installs; we can test that upgrade path and the next piaware upgrade will pull in the dependencies.
For a more general-purpose install you (a) may want to look at a package install rather than a full sdcard image, and (b) you can of course implement your own policy for package updates.
If you have the knowledge then do a standard (headless) setup of a raspberry Pi and add Piaware/Dump1090-fa to it. There are no limitations doing so and ensures you have full control of the unit itself. You can still manage Piaware through MyADSB on the Flightaware site, which works surprisingly well and shows that the software is thought through.
