FUTURE FEATURE REQUESTS & UPDATES - Data Sharing

Hi all,

Please include all feature requests and suggestions for data sharing here. Please note that the two high priority platforms are Raspberry Pi and Windows. OSX and Linux will depend on number of requests received!

Not sure if this feature request belongs here or in the website-thread:
Receiver coverage map with better resolution (google maps) would be nice. Selectable option for coverage on different flightlevels (+/-)

Not sure if this feature request belongs here or in the website-thread:
Receiver coverage map with better resolution (google maps) would be nice. Selectable option for coverage on different flightlevels (+/-)

This already exists, it’s called Virtual Radar Server and will take a feed from your FR24 box or dongle and give you range rings for different heights, along with logging and details of all aircraft tracked.

I don't know where to submit comments to the fr24 devs so I'm doing it here...

While it's great that the fr24feed package has been updated to use systemd, it seems to be a beta test. There are a few questionable things going on (some due to the change and some previously existing):

1. A cron-job runs the update script every day at 7:00. This is what apt-get is for. Many people already have an established routine for performing updates, often including change control to avoid broken software! Running a parallel update process, with STDERR and STDOUT redirected to /dev/null so that nobody ever sees any problems with the script, does not seem like best practice. This should, at least, be optional when installing.

2. The /etc/systemd/system/fr24feed.service file contains elements that break other software. Creating and changing ownership of /run/dump1090-mutability breaks existing stand-alone dump1090-mutability installations. If this is required for a bundled version, then do some checking first at time of installation and decide whether to include this. if receiver="avr-tcp" in /etc/fr24feed.ini, then there is no need to touch /run/dump1090-mutability at all. Yes, I know the script looks for the string dvbt (if grep -q dvbt /etc/fr24feed.ini), but in some cases it will be there, commented out. This is not a robust test. At least evaluate the fr24feed.ini file and then test the value of $receiver.

3. Changing another process' log directory to be writeable by everyone (ExecStartPre=-/bin/chmod a+rwx /var/log/lighttpd) is a very bad idea. It will allow someone to create a link to another file and potentially over-write something sensitive or critical. Very, very bad idea.

4. Enforcing package dependancies in the update script doesn't seem like a good idea. Why not create the appropriate entry for dump1090-mutability in the apt sources file and declare the dependancy in the fr24feed package. The system infrastructure is there, it just needs to be used.

Do the fr24feed package developers read this? I'm sure there are lots of people that can help them make their system better, currently it looks like it was created by a developer and not a system administrator.

I don't know where to submit comments to the fr24 devs so I'm doing it here...

Do the fr24feed package developers read this? I'm sure there are lots of people that can help them make their system better, currently it looks like it was created by a developer and not a system administrator.

Constructively yours,
Len

Once in a blue moon. Possibly get better from emailling spport.

Last edited by Oblivian; 2018-01-20 at 12:27.

Posts not to be taken as official support representation - Just a helpful uploader who tinkers