Announcement

Collapse
No announcement yet.

Archived: Feed issues with 19-2

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by fr24-pad View Post
    Why do the developers of this package insist on making "ping" a setuid-executable. What happens when someone discovers a bug in ping and you have set it to run as root. Do you really want to be responsible for exposing your users to this kind of security problem?

    Why do you add a user to the system "useradd -r -U fr24 || true" without testing to see if it is already present.

    You make /etc/fr24feed.ini world-writeable "chmod a+w /etc/fr24feed.ini". Seriously?

    I know I'm hammering on you guys, but this is unforgivable. You have a business that uses volunteers as your infrastructure and this is the way you treat their machines.

    Installing "/etc/udev/rules.d/rtl-sdr.rules" in order to " # allow non-root user to access DVB-T hardware" - This does not need to be done as part of the fr24 package. If I'm not mistaken, this is handled by the standard debian package librtlsdr0 which installs /lib/udev/rules.d/60-librtlsdr0.rules.

    /etc/systemd/system/fr24feed.service is still performing updates at start time, touching and changing permissions to other packages' files.

    A new addition "/usr/lib/fr24/unregister_kernel_modules.sh" - Unloading modules with no testing to see what is present or what is running. Sounds like a bad idea.

    Please reach out if you want some help doing this correctly.
    Hi and thanks for your feedback.

    All of these additional activities were added after we switched from running fr24feed as root to a non-privileged user (fr24).
    This was long-awaited and asked by many feeders and you probably wouldn't argue that this is a good change to make.

    However, this came with a variety of unexpected issues due to different user setups, operating systems, broken system packages which were almost impossible to anticipate and test on our test stand. Some of them we are still unable to reproduce.

    To your suggestions,

    1. ping suid bit. On many OS it is set by default and even e.g. on old Jessie versions ping completely fails without suid bit: https://www.raspberrypi.org/forums/v...c.php?t=129242
    There is an option to use setcap instead of suid, but that is risky as requires additional OS support for it. So we've fixed it this way to remediate the problem ASAP and plan to test setcap more thoroughly before introducing it for everyone.

    2. I agree that it might be more clear to check first (from a clear-code perspective), but useradd will fail if a user exists, so I don't completely buy the argument.

    3. Yes, we need to allow both fr24 and pi users to write to this file (to allow signup). Some systems do not have 'pi' user. Could we do better, e.g. creating a group instead? Sure. But for now it just complicates things and though I agree with general security practices, it feels like overengineering things for now. We will definitely come back to this later.

    4. That seems to be correct by checking quickly, it was missed because of two different directories for this config and users reported that the latter not working. Needs more testing and verification, though I can't see it being critical to be honest.

    5. Actions performed on fr24feed.service start:
    - install dump1090 (if needed). As I mentioned few posts earlier, of course there is a way to package this to our repository and install via apt-get directly. No doubt this is a nice way. Unfortunately dump1090 is not our software and there are multiple activities needed to support the repository. We will definitely look into this further, but for now I don't see how this would help to solve anything.
    - unregister dvb-related kernel modules - yes this is done without checks that it is loaded. But even if it is not loaded, could it harm to unload it second time? Do you see usecases when these modules are required for an average user?
    - make directories (if not exists) /run/dump1090-mutability and /var/log/lighttpd - we've seen cases when these apps failed to start in non-root mode if these directories didn't exist
    - chmod world read+write /run/dump1090-mutability to allow both lighttpd and fr24feed (and dump1090 obviously) to access this directory. Could it be done in a more clear way? Sure. And we will definitely return to this after thorough testing.

    I would like to say thank you once again and apologise for any inconvenience, but I wouldn't agree that any of the mentioned items are so bad and critical that we can call them "unforgivable". We've moved away from running things as superuser which to my opinion could potentially cause higher risk. We will of course gradually improve things.

    Comment


    • After my setup auto-updated from 1.0.9-11 to 1.0.9-12 this morning, fr24 was down and a fr24feed-status command showed this:

      pi@piaware:~ $ fr24feed-status
      [ ok ] FR24 Feeder/Decoder Process: running.
      [ ok ] FR24 Stats Timestamp: 2018-02-01 09:40:09.
      [ ok ] FR24 Link: connected [UDP].
      [ ok ] FR24 Radar: T-CYCV22.
      [ ok ] FR24 Tracked AC:.
      [FAIL] Receiver: down ... failed!
      [FAIL] FR24 MLAT: not running ... failed!

      I tried rebooting, also the hack using wget to obtain the rtl-sdr.rules that was posted at some point, but these had no effect. In case it's of help, I saw this in the file /var/log/fr24feed_update.log:

      Get:1 xxxLINKREMOVEDxxx flightradar24/raspberrypi-stable armhf fr24feed armhf 1.0.19-12 [1,215 kB]
      apt-listchanges: Reading changelogs...
      debconf: unable to initialize frontend: Dialog
      debconf: (TERM is not set, so the dialog frontend is not usable.)
      debconf: falling back to frontend: Readline
      debconf: unable to initialize frontend: Readline
      debconf: (This frontend requires a controlling tty.)
      debconf: falling back to frontend: Teletype
      dpkg-preconfigure: unable to re-open stdin:
      Fetched 1,215 kB in 0s (1,793 kB/s)
      (Reading database ... ^M(Reading database ... 5%^M(Reading database ... 10%^M(Reading database ... 15%^M(Reading database ... 20%^M(Reading database ... 25%^M(Reading database ... 30%^M(Reading database ... 35%^M(Reading database ... 40%^M(Reading database ... 45%^M(Reading database ... 50%^M(Reading database ... 55%^M(Reading database ... 60%^M(Reading database ... 65%^M(Reading database ... 70%^M(Reading database ... 75%^M(Reading database ... 80%^M(Reading database ... 85%^M(Reading database ... 90%^M(Reading database ... 95%^M(Reading database ... 100%^M(Reading database ... 40046 files and directories currently installed.)
      Preparing to unpack .../fr24feed_1.0.19-12_armhf.deb ...
      Unpacking fr24feed (1.0.19-12) over (1.0.19-11) ...
      Setting up fr24feed (1.0.19-12) ...
      useradd: user 'fr24' already exists
      mount: / is busy

      (removed link above is because I don't have permission to post links yet...)

      Comment


      • @vinnyspb:
        Right now priority is to fix broken systems, and there are somany different types of custom made systems.

        As far as I am concerned, since my Pi does not contain my bank account or credit card info, or my personal details, I am least bothered about security. What maximum can be hacked? Only fr24key, I can afford to lose it, will get a new key. A malware added? Never mind, will shutdown Pi, slip out microSD card, slip into card reader of Laptop, burn fresh Pi24 image, slip card back into Pi and power up. A total of 15 minutes operation.

        Of course others can have completely different opinion. It is perfectly ok. It is their right.
        Last edited by abcd567; 2018-02-01, 09:52.

        Comment


        • Is there anyone that can help me to fix why I cant see pi-ip/dump1090 ?

          Checked ip-of-pi:8754 everything is OK
          Checked ip-of-pi/dump1090/ >> Unable to load page
          Checked ip-of-pi:8080 >> Unable to load
          pagepi_ip_8754.JPG

          Thanks in advance

          Comment


          • Pi24 auto upgrade from ver 1.0.18-9 to 1.0.19-12 failed, as dump1090-mutability did not get installed although setting was receiver="dvbt".

            Fixed by manually running install script
            Code:
            cd /usr/lib/fr24
            sudo ./install_dump1090.sh
            sudo reboot
            After above fix, all is working OK

            2018-02-01 11.09.36.png 2018-02-01 11.10.44.jpg

            Comment


            • Originally posted by Magnusgallstad
              When I connect to mypiip:8080
              map is showing up in italy ... is there any chanche to get sweden or my gps location ?
              1. Italy is default position of map. Move the map manually to your location (Sweden). Once there, it will be remembered by your browser and next time you go to map, it will show Sweden. If you clear cache of your browser, it will again go to Italy, and you have to manually drag it to Sweden. Then it will stay at Sweden till you again clear browser cache.

              2. The other alternative is that you add latitude and longitude in "Process arguments" (where you have added --net). The process arguments will become like below:
              --net --lat xx.xxx --lon yy.yyyy
              (Replace xx.xxx and yy.yyyy by your actual latitude and longitude)
              "Save" and "Restart"

              This will center map at receiver location.
              It will also start showing 3 circles at 100, 150, and 200nm from receiver.

              Comment


              • Originally posted by Magnusgallstad
                map is showing up in italy ... is there any chanche to get sweden or my gps location ?
                Hej Magnus,

                I can show you (på svenska) how to set it up with an even better map, send me an email at mrmac@fastest.cc

                BR /Marcus
                F-ESDF1, F-ESGG1, F-ESGP1, F-ESNK1, F-ESNV2, F-ESNV3 F-ESSL4, F-ESNZ7, F-LFMN3
                T-ESNL1, T-ESNL2, T-ESGR15
                P-ESIA, P-ESIB, P-ESGF, P-ESSN, P-EFMA
                mrmac (a) fastest.cc

                Comment


                • Originally posted by abcd567 View Post
                  Pi24 auto upgrade from ver 1.0.18-9 to 1.0.19-12 failed, as dump1090-mutability did not get installed although setting was receiver="dvbt".

                  Fixed by manually running install script
                  Code:
                  cd /usr/lib/fr24
                  sudo ./install_dump1090.sh
                  sudo reboot
                  After above fix, all is working OK

                  [ATTACH=CONFIG]9178[/ATTACH] [ATTACH=CONFIG]9179[/ATTACH]
                  Same problem and same fixing worked for me. Now 1.0.19-13 running, feeding data and showing map

                  Thanks a lot

                  Comment


                  • I had to reboot after 1.0.19-13 got installed automatically and killed my feed.

                    This is the 3rd time this happened. I commented out the update cron task in /etc/cron.d/fr24feed_updater.

                    Comment


                    • Originally posted by thehague View Post
                      I had to reboot after 1.0.19-13 got installed automatically and killed my feed.

                      This is the 3rd time this happened. I commented out the update cron task in /etc/cron.d/fr24feed_updater.
                      Please post the diagnostics from http://receiver_ip:8754/diagnostics_dump.tgz
                      This would help us to debug the issue

                      Comment


                      • Originally posted by vinnyspb View Post
                        Please post the diagnostics from http://receiver_ip:8754/diagnostics_dump.tgz
                        This would help us to debug the issue
                        Here you go: https://www.dropbox.com/s/6oh110b6ia..._dump.tgz?dl=0

                        Comment


                        • I have two radars: they are (or I suppose) the same, and one was derived from the first installation of the other.
                          One, T-LIMJ5, updated by itself and always worked. Now it run fr24feed 1.0.19-12.
                          The other one, T-LIMW3, run 1.0.18-9 and when it try to update, it kill the feed: now I commented the cron line and it work, seen it never try to update!

                          If someone need some more info to debug, let me know.

                          Comment


                          • In versions 1.0.19-11, 12 & 13, when I set receiver type avr-tcp, host 127.0.0.1:30002, everything fails.
                            FR24 says Receiver down.
                            All other feeders (Flightaware, Planefinder etc) complain "no program listening to port 30005" and "cannot find dump1090"
                            Maps say "Unable to connect" or sometimes "Ajax call failure"
                            sudo systemctl restart dump1090-mutability did not help.

                            Edited file /etc/default/dump1090-mutability , and changed START_DUMP1090="no" to START_DUMP1090="yes".
                            This enabled start of dump1090-mutability at boot.
                            Rebooted.
                            Still same situation.

                            Further info: It is a PI24 1.0.18-9 image, auto upgraded to 1.0.19-12 yesterday and 1.0.19-13 today.
                            Last edited by abcd567; 2018-02-02, 19:41.

                            Comment


                            • SUGGESTION TO DEVELOPMENT TEAM

                              I feel it will simplify things if fr24feed:
                              • Does NOT install dump1090
                              • Does NOT control or take ownership of dump1090
                              • Does NOT control and change settings of dump1090
                              • Does NOT have option "DVBT"


                              PI24 IMAGE
                              The feeder software (fr24feed) and receiver-decoder software (dump1090-mutability) should be two independent stand-alone Apps PRE-INSTALLED in Pi24 image.


                              CUSTOM INSTALLS
                              For those who have burned their own OS like Raspbian, two independent bash scripts should be offered to user as follows:
                              Bash script 1: Installs fr24feed only
                              Bash script 2: Installs dump1090-mutability v1.14 only.
                              User will have the option to use or not, the script 2, depending on if user already has, or wants to install another version of receiver decoder like modeSDeco2, dump1090-fa, or dump1090-mutability ver 1.15~dev etc.

                              Comment


                              • Originally posted by abcd567 View Post
                                SUGGESTION TO DEVELOPMENT TEAM

                                I feel it will simplify things if fr24feed:
                                • Does NOT install dump1090
                                • Does NOT control or take ownership of dump1090
                                • Does NOT control and change settings of dump1090
                                • Does NOT have option "DVBT"


                                PI24 IMAGE
                                The feeder software (fr24feed) and receiver-decoder software (dump1090-mutability) should be two independent stand-alone Apps PRE-INSTALLED in Pi24 image.


                                CUSTOM INSTALLS
                                For those who have burned their own OS like Raspbian, two independent bash scripts should be offered to user as follows:
                                Bash script 1: Installs fr24feed only
                                Bash script 2: Installs dump1090-mutability v1.14 only.
                                User will have the option to use or not, the script 2, depending on if user already has, or wants to install another version of receiver decoder like modeSDeco2, dump1090-fa, or dump1090-mutability ver 1.15~dev etc.
                                Yes. This would be a good start. There is a reason that different software packages come in separate Debian packages. Mixing them up, and then using non-standard update mechanisms is a recipe for the very disaster that is taking place.

                                Comment

                                Working...
                                X