New feeder. Some suggestions.

Discussion in 'Feeding' started by heliosh, Jan 31, 2018.

  1. heliosh

    heliosh New Member

    1) It is not neccessary to run the feeder as user root. I don't feel comfortable when a program which has open ports runs with root privileges.
    2) Why no deb package or apt repository? the "install script" in the git repository isn't a very elegant way.

    Thanks.
     
    Last edited: Jan 31, 2018
  2. MDA

    MDA Administrator Staff Member

    Install script comes from Joe Prochazka.
    If you feel uncomfortable please report this issue directly to Joe.
     
  3. James

    James Guest

    Thanks for feeding!

    Feel free to maintain a .deb repository if you like.

    The main reason for simple bash script is simplicity - adsbexchange is going to always open the code to the community. Feeding is easy at it's base it is 3 steps.

    #1 install dump1090
    #2 install mlat client
    #3 send dump1090 and mlat-client output to feed.adsbexchange.com

    There is nothing going on that one cannot see and look at. Creating a .deb or a binary defeats this purpose - it also adds more burden to the maintainers of the site.

    As mentioned above, the script was written by a community member and is not supported officially. But I do see and understand your issue with root.

    https://github.com/jprochazka/adsb-exchange/blob/master/setup.sh

    There is the script. Feel free to fork it, change to your desires, and share.

    #1 it must be run as root because it installs things. So script is going to ask for root privileges anyway.

    Lines: 48 & 49
    sudo apt-get update
    sudo apt-get install -y curl

    Line 158
    sudo dpkg -i mlat-client_${MLATCLIENTVERSION}*.deb

    #2 It creates several files in the home directory. No root needed here.

    dsbexchange-mlat_maint.sh
    adsbexchange-netcat_maint.sh

    #3 scripts are then executed at startup from rc.local

    Lines 187+
    Lines 238+
    # Add a line to execute the mlat-client maintenance script to /etc/rc.local so it is started after each reboot if one does not already exist.

    If you don't like rc.local scripts running as root, then you can try to de-escalate them. Change pi to whatever user you want.

    su pi -c 'command &'

    #5 If the thoughts are that making a binary and/or a .deb that you can't see what code is running or what it's doing is somehow more secure and better for you than actually seeing what the scripts are doing, then I am not sure of the purpose.

    I have no desire to maintain a binary or a .deb or a repository. ADSBexchange will give you server space if you want to take this on and support it. Send me a message.

    I should also note that in the latest versions of the custom image that is coming this week or next. Some scripts are no longer ran as root. Some scripts require root. I will try clean those up by removing what needs to be root to another script perhaps .. but this is secure enough for most everything.

    It is more insecure that ssh is enabled at all.

    Screenshot_2018-02-01_00-15-23.png
     
  4. James

    James Guest

    I see why community member script is running them as root. A non root user cannot write to /run in this case /var/run - therefore there are a few solutions.

    mkdir as root
    chown to pi
    run dump1090

    You could also configure dump1090 to write only to /var/run/user/1000 ... 1000 being uid of user running ...

    I'm not sure of the start order or when this directory is there and usable.

    Obviously adding all these cases and configuration complexities will add to the potential things that can go wrong during the install.

    Many feeders have no linux PC, no linux knowledge, and some even very little technical knowledge - so simplicity above all else is required for sanity purposes. Less moving parts means less to go wrong when setting up.
     
    MDA likes this.
  5. MDA

    MDA Administrator Staff Member

    Fully agree.
    Some questions on this forum are really (not stupid but showing lack of basic knowledge).