FlightAware Discussions

git: /flightaware/piaware/blob/master/package/piaware.tcl


I was browsing piaware git and stumbled into github.com/flightaware/piaware/ … iaware.tcl

I got scared when I saw e.g. these:

  • proc reboot {}
  • proc halt {}
  • proc update_operating_system_and_packages {}
  • proc upgrade_raspbian_packages {}
  • proc upgrade_raspbian_kernel {}

I have piaware 1.17-1 package installed in my Raspi and service piaware running. I use this Raspi for a number of things, piaware being just one of those.

Is my raspi vulnerable to piaware.tcl? Could piaware authors explain when those “horrible” (my view, not a fact) functions are run?

I’m curently 2 millimeters away from service stop piaware && apt-get --purge remove piaware

Did you know that rpi-update (in proc upgrade_raspbian_kernel {}) is a quick hack that has no understanding of or integration with the package manager and uses non-stable files that overwrite files installed by stable packages (from packages libraspberrypi0 libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc raspberrypi-bootloader)?


And why github.com/flightaware/piaware/ … health.tcl seems to send detailed information about my system to FA?

CPU temperature and filesystem usage are certaily not relevant for a flight tracking service in my opinion.


I think much of this is aimed at installs where it’s a dedicated receiver (e.g. using the prepared image) that may not be maintained much locally - in which case, remote health monitoring / upgrades does make some sense.
But, yes, it makes no sense for installs where it’s just one component on a shared system. Probably the remote management bits would be better placed in a separate daemon that’s packaged separately.

Hmmmmm… Concerning. :open_mouth:

That’s and I look forward to the replies.

Hi. There is a remote update capability but it is disabled by default when piaware is installed as a Debian package or installed from source code via the github repo. piaware-config must be invoked with certain options to enable it. Recognizing that people who install the package or from source may have all sorts of other stuff running on their machine, we wouldn’t dare update a machine without permission which is why we disabled it by default and we wrote the code in a straightforward manner so people can prove this for themselves and a little later in this message I’ll tell you how to do that.

If manual updates are enabled then soon users will be able to trigger a few actions on their Pi from the FlightAware website. Specifically they will be able to

  • Restart piaware

  • Restart dump1090

  • Reboot

  • Halt

  • Update piaware

  • Update dump1090

  • Update all other packages

  • Update the Raspbian operating system

Enabling automatic updates allows FlightAware also to do these things. For people who install the piaware SD card image the remote update capability is enabled by default and this is appropriate for that use case because people who install the SD card image are very unlikely to use the SD card image as a jumping off point for building and adding and changing software on their Pi. Even so, they can disable either or both types of updates as it’s their machine and we completely respect that and that is reflected in our software.

For most people, even logging into the Raspberry Pi is a problem, and they’re definitely not setting up a reverse tunnel to be able to login to their Pi over the Internet across their NATted router or whatever. A PiAware system can be setup and put online without even a keyboard or a monitor or a login over ssh and as the easier we make it to setup, the more people do it. (the SD image is by far the most popular way of setting up piaware). But the problem then is it’s a pain to update. People have to burn a new card image. Remote update fixes that for them.

Even many people who have installed from the package or source will find the ability to go to the website and trigger a reboot or restart of piaware or dump1090 to be really handy.

So for the Debian package and for installing from source, you have to do a “piaware-config -autoUpdate 1 -manualUpdate 1” to enable either or both capabilities and they can be disabled by invoking that with 0 for either or both options.

You can confirm that updates even if commanded remotely will not be honored unless enabled on the Pi by inspecting the update_check method in /usr/lib/fa_adept_packages/fa_adept_client.tcl and how update_check is invoked from handle_update_request. I promise you there is no path through the code that can trigger those actions unless one or both of those update flags are present and configured by you, locally, on your device.

I knew it was hackish but I’ve been using it without any problems. If there’s a better way to do it then we’ll switch to that.

If there’s a problem with your feed, there’s an “anomalies” section on your stats page that tells you what the problem is and a few pointers to help you fix it, like:

  • Your device isn’t connected
  • Your version of PiAware is old
  • Your system’s time is wrong
  • Your CPU is overheating
  • Your SD card is full
  • etc

It’s all harmless stuff to help make it easier for people to run PiAware with no downside. And as you observed, it’s all open source, so maybe the solution is to better document the context in the source so it’s not weird when people come across it.

Yes there is.

sudo apt-get --purge remove rpi-update
sudo apt-get update
sudo apt-get install --reinstall libraspberrypi0 libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc raspberrypi-bootloader
sudo debsums -s # “/usr/share/doc/dphys-swapfile/changelog.Debian.gz” is a packaking bug and the only allowed output
sudo shutdown -r now # or reboot, whatever is your preference

I’d personally run also apt-get (dist-)upgrade before debsums, but the above gets rid of rpi-update.

My understanding is that rpi-update is needed for two reasons only: testing new (bleeding edge) firmware releases, or if one needs to use an older firmare release. I doubt piaware usage falls in either of those categories, latest stable firmware & kernel should be OK.

karl & dbaker, thanks for goopd replies. Now I understand your reasons for the functionality, especially for the SD card image users, some of them might not be very familiar with Linux in general and debian based system maintenence in particular (neither am I, I’m more a yum/systemctl guy myself), so the web page based remote admin is handy, especially if all the Raspi does is piaware.

However, I’m not personally comfortable running current piaware in my Raspi. I made the difficult decision and stopped & uninstalled it. I am really sorry about this.

I want something like this:

  • simple component that does only what it needs to do, and relies on other simple components to provide the services it needs (like dump1090)
  • runs without root privileges unless it REALLY needs those (IMHO something is already wrong if you need to run something like piaware as root)
  • does not restart or reboot anything, there are separate watchdog components if monitoring/restarts are REALLY needed (IMHO there is something wrong if restarts/reboots/watchdogs/etc. are likely to be needed, my experience is that Raspi is as reliable platform as any decent Linux distro in a good HW)
  • honors my and my systems privacy, and sends only data that is 100% relevant to the thing it is doing (e.g. service it is providing/using)
  • behaves like expected in the system it is running (e.g. logs go to /var/log/ and not to a ramnom place llike /tmp/ (that is cleared every on reboot?))
  • system-wide configuration is under /etc, and no passwords in the configuration (see curent /root/.piaware)
  • avaiilable from a repository so I don’t need to install and update individual .deb packages
  • allow piaware to use dump1090 from a different host, and perhaps ability to read more than one dump1090 (that are enough co-located)

When I have a little extra time, I’ll try do something similar obj has done, and modify/strip piaware to fit my needs and make a single binary (or two if faup1090 must be separate) to be able to continue contributing to FA. Part of the reason is a personal problem I have, I have been exposed to all kinds of bloatware with Windows much too much, so when I do something as a hobby, I want to get it right, or I don’t do it at all.


I really wish you wouldn’t go, Paavo. To go further, please don’t go. You’ve provided real value in your short participation and you’re the kind of guy that we know would care for your site and put up an antenna and write about the experience and help other people in the forums and stuff like that. We’re building a community here and there’s a place for you in it and you are appreciated and respected. We’re not some tiny startup yet you’ve got the CEO and CTO replying to your postings early on Sunday morning.

It is a lot of work to do everything you outlined. Some of it I can agree to do soon, some if it later, and some of it we won’t do or will do in some different way you also might not agree with. Fine-grained control of whether or not we are allowed to read the CPU temperature, I don’t accept that there is any insight that can be gained from that to hack you or whatever, and so I don’t see the point. All the ideas you outlined would be months of work and if we made them a piaware 1.0 requirement, it would not even have been released yet, and while you might say well good then, there’s a creative tension between features and shipping and businesses that try to come down entirely on the side of features tend to go out of business without shipping a product. There is a lot more nuance to this than I’ve expressed, but I’m out to write a forum posting, not a book. -karl

You can do this already with a bit of manual work by running dump1090 in --net-only mode on the host running piaware, then using nc to feed data to it from other hosts.
You also get a combined web view, which is handy.
I do this to aggregate two receivers on different hosts - see this post

I’ve been meaning to build a little utility that does nothing but aggregate data from receivers, handling reconnection etc, but I keep getting distracted…

Hi karl,

I won’t go forever, I’ll start my feeder again when I’m happy about the software.

I worded my expectation already, but I’ll try again to make it more simple:

  • run it as non-root user
  • no restarts/reboots (even self-restarts need a strong technical reason)
  • no monitoring or data colelction except what is read from dump1090
  • no remote control/monitoring capabilities whatsoever
  • ADS-B data is the only data that goes out
  • ports (if any) are open only on lo interface
  • log file go to standard /var/log/
  • log rotation need to be done the normal way (log, log.1, log.2.gz etc.)
  • feeder sits on top of the dump1090 I prefer to use
  • system-wide configuration is under /etc
  • no plain-text passwords in the configuration

I do realise this is not something that everybody wants or needs, it’s just something that I need in order to participate.

All in all, what I want is just the feeder, nothing extra. Preferably from a repo but I can take deb packages if necessary.

I’ll do that myself if I can (have not yet cloned the git and tried, but based on what obj said in the other thread I think this is possible), but I’d certainly like it if there was a fork/version of piaware service (or just a binary) going this direction (and if there was, i’d be more than willing to contribute).

whether or not we are allowed to read the CPU temperature, I don’t accept that there is any insight that can be gained from that to hack you or whatever

My dayjob is somewhat related to big data, and you’d be surprised how much one can conclude by combining bits and pieces of different data and info over time. But it is more the principle that I don’t see the connection between the CPU temperature of my system and the ADS-B data that my feeder receives and sends to a flight tracking service.

All the ideas you outlined would be months of work and if we made them a piaware 1.0 requirement

The piaware releases are not my primary concern, but I understand the point. Of course you do what is the the best for the most, and it’s you that need to manage the conflicting requirements (typically; time vs. quaility vs. features vs. cost), I can wait until “its is done” before I start my FA feeder again.

I do appreciate the straight replies, I’ll be back, hopefully soon.


Is it possible to remove the dependency ‘raspi-copies-and-fills’ from armhf-package in future?
it is specific for raspi and a lot of users run piaware on other hardware, getting trouble on every update…
seems ‘raspi-copies-and-fills’ is not essential to run the package…?
Or is there another solution/repository to get from?

Also 100% agree with the statement from ptl. its a simple explanation what to to…


It’s not essential. We don’t have any measurement of the difference it makes on piaware. Probably not a lot. I’ve gone ahead and removed it from the list of dependencies so the next piaware release won’t require it. -karl