Announcing PiAware 5!

Thanks! Didn’t have tar1090 but I added it and that worked.

The Raspberry Pi installation used a stock PiAware 4.0 image. (A number of other programmes including graphs1090 were manually installed later although I do not believe that they install anything in the paths that the original packages use.)

Ok, that’s expected behaviour for a piaware sdcard image. There is a piaware-release metapackage which depends on the exact versions of all the components that make up each release; trying to upgrade just one component e.g. dump1090-fa will end up pulling in upgrades of all components to satisfy the metapackage dependencies.

i.e.

  • piaware-release 4.0 depends on (exactly) dump1090-fa 4.0, piaware-support 4.0, piaware 4.0, etc
  • piaware-release 5.0 depends on (exactly) dump1090-fa 5.0, piaware-support 5.0, piaware 5.0, etc
  • upgrading dump1090-fa to 5.0 while you have piaware-release 4.0 installed forces piaware-release to also be upgraded (apt is smart enough to work this out); that in turn forces everything that piaware-release depends on to be upgraded.
1 Like

Thanks for the explanation! Do you have speculation as to why piaware 5.0/piaware-web 5.0 for Raspbian do not give “This version of SkyAware will soon be depcrecated. Visit URL: [local IP Address]/skyaware for the most up-to-date SkyAware interface.” warning in /dump1090-fa/, and root has no link to the new /skyaware/ URI?

Not sure what your setup is - do you mean the package installs?

Yes - I used remote update on original piaware image on Raspberry Pi, although I could see that apt-get install was invoked so they must be the standard Raspbian packages. On the x86 device, I followed abcd567’s scripts that built from the source then installed to replace zenonp’s custom 4.0 build which was also from the source.

I can see that /var/www/html/index.* and /usr/share/dump1090-fa/html/index.html in both systems are updated and identical.

pi@piaware:~ $ md5sum /var/www/html/index.* /usr/share/dump1090-fa/html/index.html 
d64d6fcdfba0fcbebf05dc57ce95c979  /var/www/html/index.html
4ff9d94b342fbd24396eb88f06b289f9  /var/www/html/index.js
dd834d0dd3ec9c3891df38861ac85b16  /usr/share/dump1090-fa/html/index.html

On Debian (/fabian64)

pi@fabian64:~$ md5sum /var/www/html/index.* /usr/share/dump1090-fa/html/index.html 
d64d6fcdfba0fcbebf05dc57ce95c979  /var/www/html/index.html
4ff9d94b342fbd24396eb88f06b289f9  /var/www/html/index.js
dd834d0dd3ec9c3891df38861ac85b16  /usr/share/dump1090-fa/html/index.html

Additionally in both, /var/www/html/index.js definitely only contains links to /skyaware/ and /skyawere978/ and not /dump1090-fa/ and /dump978-fa/ as the previous version does.

Now this is even more baffling. In Raspbian, I see some seemingly unrelated errors shortly before and after lighttpd restart triggered by the update. They stopped long before I manually performed another restart. (Unaware of the errors, my restart was an attempt to induce the new UI behavior. It did nothing.)

  1. Last 4.0 restart

    – Logs begin at Thu 2019-02-14 10:11:59 UTC, end at Sat 2021-03-20 21:18:25 UTC. –
    Mar 11 03:19:30 piaware systemd[1]: Starting Lighttpd Daemon…
    Mar 11 03:19:33 piaware systemd[1]: Started Lighttpd Daemon.

  2. Shortly before automated restart

    Mar 20 01:21:49 piaware systemd[1]: /lib/systemd/system/lighttpd.service:6: PIDFile= references path below legacy directory /var/run/, updating /var/run/lighttpd.pid → /run/lighttpd.pid; please update the unit file accordingly.
    Mar 20 01:21:52 piaware systemd[1]: /lib/systemd/system/lighttpd.service:6: PIDFile= references path below legacy directory /var/run/, updating /var/run/lighttpd.pid → /run/lighttpd.pid; please update the unit file accordingly.

    Mar 20 01:22:12 piaware systemd[1]: /lib/systemd/system/lighttpd.service:6: PIDFile= references path below legacy directory /var/run/, updating /var/run/lighttpd.pid → /run/lighttpd.pid; please update the unit file accordingly.

  3. Automated restarts x 3
    Mar 20 01:22:13 piaware systemd[1]: Stopping Lighttpd Daemon…
    Mar 20 01:22:13 piaware systemd[1]: lighttpd.service: Succeeded.
    Mar 20 01:22:13 piaware systemd[1]: Stopped Lighttpd Daemon.
    Mar 20 01:22:13 piaware systemd[1]: Starting Lighttpd Daemon…
    Mar 20 01:22:13 piaware lighttpd[15439]: 2021-03-20 01:22:13: (plugin.c.190) Cannot load plugin mod_setenv more than once, please fix your config (lighttpd may not accept such configs in future releases)
    Mar 20 01:22:13 piaware systemd[1]: Started Lighttpd Daemon.
    Mar 20 01:22:13 piaware lighttpd[15448]: 2021-03-20 01:22:13: (plugin.c.190) Cannot load plugin mod_setenv more than once, please fix your config (lighttpd may not accept such configs in future releases)
    Mar 20 01:22:14 piaware systemd[1]: /lib/systemd/system/lighttpd.service:6: PIDFile= references path below legacy directory /var/run/, updating /var/run/lighttpd.pid → /run/lighttpd.pid; please update the unit file accordingly.

    Mar 20 01:22:20 piaware systemd[1]: /lib/systemd/system/lighttpd.service:6: PIDFile= references path below legacy directory /var/run/, updating /var/run/lighttpd.pid → /run/lighttpd.pid; please update the unit file accordingly.
    Mar 20 01:22:21 piaware systemd[1]: Reloading Lighttpd Daemon.
    Mar 20 01:22:21 piaware systemd[1]: Reloaded Lighttpd Daemon.
    Mar 20 01:22:21 piaware lighttpd[15448]: 2021-03-20 01:22:21: (plugin.c.190) Cannot load plugin mod_setenv more than once, please fix your config (lighttpd may not accept such configs in future releases)
    Mar 20 01:22:23 piaware systemd[1]: /lib/systemd/system/lighttpd.service:6: PIDFile= references path below legacy directory /var/run/, updating /var/run/lighttpd.pid → /run/lighttpd.pid; please update the unit file accordingly.

    Mar 20 01:22:26 piaware systemd[1]: /lib/systemd/system/lighttpd.service:6: PIDFile= references path below legacy directory /var/run/, updating /var/run/lighttpd.pid → /run/lighttpd.pid; please update the unit file accordingly.
    Mar 20 01:22:27 piaware systemd[1]: Stopping Lighttpd Daemon…
    Mar 20 01:22:27 piaware systemd[1]: lighttpd.service: Succeeded.
    Mar 20 01:22:27 piaware systemd[1]: Stopped Lighttpd Daemon.
    Mar 20 01:22:27 piaware systemd[1]: Starting Lighttpd Daemon…
    Mar 20 01:22:27 piaware lighttpd[15862]: 2021-03-20 01:22:27: (plugin.c.190) Cannot load plugin mod_setenv more than once, please fix your config (lighttpd may not accept such configs in future releases)
    Mar 20 01:22:27 piaware systemd[1]: Started Lighttpd Daemon.
    Mar 20 01:22:27 piaware lighttpd[15867]: 2021-03-20 01:22:27: (plugin.c.190) Cannot load plugin mod_setenv more than once, please fix your config (lighttpd may not accept such configs in future releases)
    Mar 20 01:22:28 piaware systemd[1]: /lib/systemd/system/lighttpd.service:6: PIDFile= references path below legacy directory /var/run/, updating /var/run/lighttpd.pid → /run/lighttpd.pid; please update the unit file accordingly.

    Mar 20 01:22:36 piaware systemd[1]: /lib/systemd/system/lighttpd.service:6: PIDFile= references path below legacy directory /var/run/, updating /var/run/lighttpd.pid → /run/lighttpd.pid; please update the unit file accordingly.

  4. Manual restart. Note that errors stopped shortly after the last automated restart, 12 minutes before this restart.
    Mar 20 01:34:33 piaware systemd[1]: Stopping Lighttpd Daemon…
    Mar 20 01:34:33 piaware systemd[1]: lighttpd.service: Succeeded.
    Mar 20 01:34:33 piaware systemd[1]: Stopped Lighttpd Daemon.
    Mar 20 01:34:33 piaware systemd[1]: Starting Lighttpd Daemon…
    Mar 20 01:34:34 piaware lighttpd[25154]: 2021-03-20 01:34:33: (plugin.c.190) Cannot load plugin mod_setenv more than once, please fix your config (lighttpd may not accept such configs in future releases)
    Mar 20 01:34:34 piaware systemd[1]: Started Lighttpd Daemon.
    Mar 20 01:34:34 piaware lighttpd[25161]: 2021-03-20 01:34:34: (plugin.c.190) Cannot load plugin mod_setenv more than once, please fix your config (lighttpd may not accept such configs in future releases)

The PID location error did not show during update on the Debian system. (The mod_setenv warning appears in both.)

Check your lighttpd config files. Without knowing precisely what modifications you did it’s just a guess, but I’d guess that you’ve modifed your lighttpd config and then didn’t pick up all the upstream changes when upgrading. Same class of error as the tar1090 problems documented elsewhere.

On x86_64 machine when upgrading dump1090-fa from v4.0 to v5.0 by command sudo dpkg -i dump1090-fa_5.0_amd64.deb, it asked me if I want to keep existing config files or want to replace it by package maintainer’s version. I chose to replace it by package maintener’s version.

All is working OK now, but I am wondering if I would have chosen to keep old config, how it would have behaved. Do these config files mentioned by dpkg -i include files inside directory /etc/lighttpd/conf-available and /etc/lighttpd/conf-enabled?

It’ll only ask you if you have modified those files.
Yes those are included.

as :8080 moved from the dump1090-fa.conf to the skyaware.conf means that keeping the old dump1090-fa conf you now have :8080 configured twice which doesn’t work.

Due to dump1090-fa/dump978-fa both defining mod_setenv the mod_setenv module seizes to work.
Thus i needed to modify those config files with tar1090 to make mod_setenv work again.

As the files were edited dpkg/apt will either not ovewrite the config with the new version in unattended mode (FA stats page upgrade) or ask you if you want to overwrite with the default being to not overwrite.

As i’ve written 10 times by now, if you use tar1090, just rerun the tar1090 install script after updating dump1090-fa and it will fix the lighttpd mess.

Edit:
Looking at the lighttpd logs here … they seem normal, loading mod_setenv twice doesn’t cause lighttpd to stop working.

I don’t think this is any lighttpd issue for whacky … just a whacky installation and not updating everything he’s using.

No I did NOT make any changes to lighttpd or dump1090-fa config files

I mentioned in my above post about package maintainer’s version of config files during upgrade of dump1090-fa. However I had some doubt that it occurred with something else, may be dump978-fa or piaware or piaware-web or tcltls-rebuilt.

To make sure, I repeated the upgrade of dump1090-fa on another distro, and it installed new version of config files for dump1090-fa + lighttpd without asking this question. That means it was some other package where this choice of existing vs package maintainer’s was presented.

abcd@debian10:~$ apt policy dump1090-fa
dump1090-fa:
  Installed: 4.0
  Candidate: 4.0
  Version table:
 *** 4.0 100
        100 /var/lib/dpkg/status

abcd@debian10:~$ sudo dpkg -i dump1090-fa_5.0_amd64.deb
[sudo] password for abcd:
(Reading database ... 156590 files and directories currently installed.)
Preparing to unpack dump1090-fa_5.0_amd64.deb ...
Unpacking dump1090-fa (5.0) over (4.0) ...
Setting up dump1090-fa (5.0) ...
Installing new version of config file /etc/default/dump1090-fa ...
Installing new version of config file /etc/lighttpd/conf-available/89-dump1090-fa.conf ...
The user `dump1090' is already a member of `plugdev'.
Enabling lighttpd skyaware module..
Enabling skyaware: ok
Run "service lighttpd force-reload" to enable changes
Restarting lighttpd..

Repeated upgrade from v4.0 to v5.0, but this time made modifications in file /etc/lighttpd/conf-available/89-dump1090-fa.conf BEFORE UPGRADING, as shown below (added an extra line)

alias.url += (
  "/dump1090-fa/data/" => "/run/dump1090-fa/",
  "/dump1090-fa/" => "/usr/share/dump1090-fa/html/"
 # Added extra line below
  "/dump1090-fa/" => "/usr/share/dump1090-fa/html/"
)

 

This time I was asked about config file to keep. I said Y (install the package maintainer’s version). All good now:

abcd@debian10:~$ apt policy dump1090-fa
dump1090-fa:
  Installed: 4.0
  Candidate: 4.0
  Version table:
 *** 4.0 100
        100 /var/lib/dpkg/status
abcd@debian10:~$ sudo dpkg -i dump1090-fa_5.0_amd64.deb
(Reading database ... 156003 files and directories currently installed.)
Preparing to unpack dump1090-fa_5.0_amd64.deb ...
Unpacking dump1090-fa (5.0) over (4.0) ...
Setting up dump1090-fa (5.0) ...

Installing new version of config file /etc/default/dump1090-fa ...

Configuration file '/etc/lighttpd/conf-available/89-dump1090-fa.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** 89-dump1090-fa.conf (Y/I/N/O/D/Z) [default=N] ? Y

Installing new version of config file /etc/lighttpd/conf-available/89-dump1090-fa.conf ...

The user `dump1090' is already a member of `plugdev'.
Enabling lighttpd skyaware module..
Enabling skyaware: ok
Run "service lighttpd force-reload" to enable changes
Restarting lighttpd..

The piaware-web source code at Github shows:
Release 5.0 (master)

However when the package is build using it, the package shows:
piaware-web_3.8.1_all.deb

2 Likes

No it doesn’t. You did something wrong when building.

$ git log -1 --oneline
78d3c91 (HEAD -> master, tag: v5.0, origin/master, origin/HEAD) Release 5.0
$ dpkg-buildpackage -b --no-sign
dpkg-buildpackage: info: source package piaware-web
dpkg-buildpackage: info: source version 5.0
[...]
dpkg-deb: building package 'piaware-web' in '../piaware-web_5.0_all.deb'.

A request for this sort of thing in the future: if you think you’ve run into a bug, can you raise an issue on github rather than confusing the release thread? Thanks.

1 Like

On my Pi3 update I answered with the default “keep existing” and lighttpd stopped working.
Fixed it with wiedehopf tar1090 install.

Oops, looking at commands you have posted, I found my mistake. I followed the pattern of piaware_builder and did this:

git clone https://github.com/flightaware/piaware-web 
cd piaware-web
./prepare-build.sh buster 
cd package-buster
sudo dpkg-buildpackage -b --no-sign

Now I did following, and got correct version piaware-web_5.0_all.deb. Thank you.

git clone https://github.com/flightaware/piaware-web 
sudo dpkg-buildpackage -b --no-sign

I had doubts that this is not a bug but it is due to something I missed, and I wanted to first clear it, rather than making a bug report straightaway.

1 Like

That also works fine here. You had some other error (perhaps you didn’t clean out an old package-buster first).

This is a good illustration of why it’s probably better to raise the issue on github first; it’s not a bug but now we have 4-5 posts on the release thread going back and forth trying to diagnose a bug that doesn’t exist.

2 Likes

No customization with lighttpd.

pi@piaware:~ $ md5sum /etc/lighttpd/lighttpd.conf /etc/lighttpd/conf-enabled/*
c8b83b69abe735eb863854512b7d1f91  /etc/lighttpd/lighttpd.conf
5b57f4e1ea3a44819872a19b677f7b34  /etc/lighttpd/conf-enabled/50-piaware.conf
49ee407afe8966c8bd1254ab1998831b  /etc/lighttpd/conf-enabled/88-dump1090-fa-statcache.conf
13b594d839778845d775e6f55937131c  /etc/lighttpd/conf-enabled/88-graphs1090.conf
c08819655d9f1429bb991a9e8b1d791b  /etc/lighttpd/conf-enabled/89-dump1090-fa.conf
e3aa6136301a7cb8a955f6ffd863a4df  /etc/lighttpd/conf-enabled/89-skyaware.conf

On x86:

pi@fabian64:~$ md5sum /etc/lighttpd/lighttpd.conf /etc/lighttpd/conf-enabled/*
c8b83b69abe735eb863854512b7d1f91  /etc/lighttpd/lighttpd.conf
5b57f4e1ea3a44819872a19b677f7b34  /etc/lighttpd/conf-enabled/50-piaware.conf
49ee407afe8966c8bd1254ab1998831b  /etc/lighttpd/conf-enabled/88-dump1090-fa-statcache.conf
13b594d839778845d775e6f55937131c  /etc/lighttpd/conf-enabled/88-graphs1090.conf
c08819655d9f1429bb991a9e8b1d791b  /etc/lighttpd/conf-enabled/89-dump1090-fa.conf
e3aa6136301a7cb8a955f6ffd863a4df  /etc/lighttpd/conf-enabled/89-skyaware.conf
568434a47d89bb89ecf81c8f9c4e1669  /etc/lighttpd/conf-enabled/90-javascript-alias.conf

(I verified that md5sum operates on dereference source, not the symlink itself.) I cannot tell why there is one more config javascript-alias.conf on fabian64 (or why it is absent on piaware even under conf-available/). But this was an old one and a simple one.

pi@fabian64:~$ ls -l /etc/lighttpd/conf-enabled/90-javascript-alias.conf 
lrwxrwxrwx 1 root root 42 Oct 27 07:53 /etc/lighttpd/conf-enabled/90-javascript-alias.conf -> ../conf-available/90-javascript-alias.conf
pi@fabian64:~$ ls -l /etc/lighttpd/conf-available/90-javascript-alias.conf
-rw-r--r-- 1 root root 56 Jul 28  2013 /etc/lighttpd/conf-available/90-javascript-alias.conf
pi@fabian64:~$ cat /etc/lighttpd/conf-enabled/90-javascript-alias.conf
alias.url += ("/javascript" => "/usr/share/javascript")

Hi there abcd567

Many thanks for your advice. I successfully moved from Stretch to the latest version of Buster. The map now has the ability to show flight numbers on the map as well as work with filters. Interestingly the map is still showing " 5.0-bp09+1"

Cheers
Mark

Clear browser cache: Ctrl+Shift+Delete
Reload browser: Ctrl+F5

 

Updated, but seems to be about the same as it was before. For you next upgrade/update, have you considered improving the aircraft type identification? The main reason I close my piaware window down and go to virtual radar is 90% of the time aircraft type=NA. Then it’s 5 clicks and 2 other webpages just to see what I’m looking at, while flight radar 95% of the time pulls up the aircraft type and even a photo when you select the target. Making the interface and experience better for the folks who are helping feed your data would seem to be a good idea.