AirNav Systems Forum
AirNav RadarBox and RadarBox24.com => AirNav RadarBox and RadarBox24.com Discussion => Topic started by: AndreasWarby on March 06, 2021, 11:38:33 AM
-
I would like to be able to run /usr/bin/rbfeeder on my Raspberry Pi using a non-privileged account instead of root. I have attempted to do this by creating a user "radarb" and then modifying /lib/systemd/system/rbfeeder.service with "User=radarb" and "Group=radarb" in the [Service] section. I also modified /etc/rbfeeder.ini to write the log file to /home/radarb.
With this configuration, the /usr/bin/rbfeeder program starts up, successfully begins to set up some connections, but then exits with an error code.
I am wondering if anyone has succeeded at running rbfeeder in the way that I am seeking?
Thanks for any help and tips!
Best regards,
Andreas
-
Yes, I tried, but failed.
$ sudo useradd --system rb
$ sudo nano /lib/systemd/system/rbfeeder.service
[Unit]
Description=RBFeeder Service
After=network-online.target
[Service]
User=rb
Type=simple
ExecStart=/usr/bin/rbfeeder
ExecStop=/bin/kill -TERM $MAINPID
Restart=always
[Install]
WantedBy=multi-user.target
$ sudo systemctl daemon-reload
$ sudo systemctl restart rbfeeder
$ sudo systemctl status rbfeeder
● rbfeeder.service - RBFeeder Service
Loaded: loaded (/lib/systemd/system/rbfeeder.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2021-03-06 21:40:38 EST; 11s ago
Process: 11472 ExecStart=/usr/bin/rbfeeder (code=exited, status=1/FAILURE)
Main PID: 11472 (code=exited, status=1/FAILURE)
Mar 06 21:40:38 raspberrypi systemd[1]: rbfeeder.service: Service RestartSec=100ms expired, scheduling restart.
Mar 06 21:40:38 raspberrypi systemd[1]: rbfeeder.service: Scheduled restart job, restart counter is at 5.
Mar 06 21:40:38 raspberrypi systemd[1]: Stopped RBFeeder Service.
Mar 06 21:40:38 raspberrypi systemd[1]: rbfeeder.service: Start request repeated too quickly.
Mar 06 21:40:38 raspberrypi systemd[1]: rbfeeder.service: Failed with result 'exit-code'.
Mar 06 21:40:38 raspberrypi systemd[1]: Failed to start RBFeeder Service.
Changed ownership of the binary from root to rb:
$ ls -l /usr/bin/rbfeeder
-rwxr-xr-x 1 root root 233360 Jun 23 2020 /usr/bin/rbfeeder
$ sudo chown rb:rb /usr/bin/rbfeeder
$ ls -l /usr/bin/rbfeeder
-rwxr-xr-x 1 rb rb 233360 Jun 23 2020 /usr/bin/rbfeeder
$ sudo systemctl restart rbfeeder
STILL FAILED
-
Thanks so much for checking this @abcd567. It seems we have both performed the same steps, with the same (failed) result.
Admittedly, this realization significantly lowers my confidence in hosting rbfeeder on my personal Raspberry Pi in my home LAN. Indeed, all of the other "big" ADS-B feeder receiving organizations have moved away from running in root. One exception (PlaneFinder) can easily be adapted to run under a normal non-privileged user account.
Are there plans to update the rbfeeder software to address this, or is there some other way to achieve this under the existing paradigm?
Thanks and best regards,
Andreas / VA2WBT
-
Admittedly, this realization significantly lowers my confidence in hosting rbfeeder on my personal Raspberry Pi in my home LAN. Indeed, all of the other "big" ADS-B feeder receiving organizations have moved away from running in root. One exception (PlaneFinder) can easily be adapted to run under a normal non-privileged user account.
Yes, that is the right way to do it.
Recently I have also added "User=mm2" in service file of ModeSMixer2. The ModeSMixer2 is provided by it's author in binary format, without any service or config files. The users had to do everything by themselves. Most users were running it manually by typing command with all arguments, or by a bash script containing command & arguments. This bash script was mostly run manually, or by an entry into file rc.local. I wrote a script which creates necessary service and config files for it. If installed by my script, it starts automatically at boot and has all the systemd commands available.
https://github.com/abcd567a/mm2 (https://github.com/abcd567a/mm2)
Are there plans to update the rbfeeder software to address this, or is there some other way to achieve this under the existing paradigm?
It seems RB24 developers have compiled their package in such a way that it requires root to run it.
No idea if & when they will fix it.
.
-
With the help of a good friend who kindly gave me some tips and things to try, I have succeeded at getting rbfeeder to execute using a non-privileged user account ("radarb" in my example below). In addition to modifying the rbfeeder.service file, one will need to specify a log file path in /etc/rbfeeder.ini to which the new account has write privileges. After making these mods, do "sudo systemctl daemon-reload" followed by "sudo systemctl restart rbfeeder", and away you go.
Best regards,
Andreas / VA2WBT
(For reasons I don't understand, I'm unable to share my code (it's telling me to enable Javascript, which is already enabled), so am attempting to provide it via an attachment image.)
-
With the help of a good friend who kindly gave me some tips and things to try, I have succeeded at getting rbfeeder to execute using a non-privileged user account ("radarb" in my example below). In addition to modifying the rbfeeder.service file, one will need to specify a log file path in /etc/rbfeeder.ini to which the new account has write privileges. After making these mods, do "sudo systemctl daemon-reload" followed by "sudo systemctl restart rbfeeder", and away you go.
Best regards,
Andreas / VA2WBT
(For reasons I don't understand, I'm unable to share my code (it's telling me to enable Javascript, which is already enabled), so am attempting to provide it via an attachment image.)
Great!!!
Thank you.
I will suggest following:
(1) The folder to hold logs to be "/var/log/rbfeeder" and modify /etc/rbfeeder.ini as follows:
Default:
log_file=/var/log/rbfeeder.log
Change to:
log_file=/var/log/rbfeeder/rbfeeder.log
(2) Instead of manually creating a folder /var/log/rbfeeder and manually changing its permission, include following three lines in service file to do the job at start of rbfeeder.
ExecStartPre=-/bin/mkdir -p /var/log/rbfeeder/
ExecStartPre=-/bin/chown radarb:radarb /var/log/rbfeeder/
ExecStartPre=-/bin/chmod -R 755 /var/log/rbfeeder/
.
-
That's great to add those extra lines for "/var/log/rbfeeder/". I actually already did something similar for my own implementation, since my /var/log area is a tmpfs (which I'd prefer to use).
I've also recently realized that what we've proposed so far unfortunately breaks MLAT functionality. I saw in the logs a permissions error relating to /run/mlat-client.pid, but adding some analogous ExecStartPre lines does not (alone) seem to do the trick.
More work is required here, I think.
Best regards,
Andreas / VA2WBT
-
I have now sent an email to RB24 software developer Jonis Ceara inviting him to see this thread. Please see attached screenshot.
-
Hi ab cd,
Thanks so much for contacting the developer -- also for your warm welcome! Yes, we are covering overlapping airspace :)
I seemed to have now fixed the broken MLAT functionality by simply following the following instructions, which I gather resulted in mlat-client running using python3.7. I've confirmed that both my rbfeeder and mlat-client processes are running under (my custom created user) radarb.
Instructions for mlat-client (re-)install [originally created by abcd567]:
## Installed required packages (dependencies and build tools)
sudo apt update -y
sudo apt-get install -y git curl build-essential debhelper python-dev python3-dev
## Downloaded source code
cd /home/pi/
git clone https://github.com/mutability/mlat-client.git
## Built mlat-client's installation package
cd /home/pi/mlat-client
sudo dpkg-buildpackage -b -uc
## Above command took some time to build package
## After the package was built, installed it by following command
cd /home/pi/
sudo dpkg -i mlat-client_*.deb
-
Hi Andreas
Glad to know you could solve your mlat problem.
I dont know from where you got those steps to build and install mlat-clent, but it matches word by word with the steps I posted in this forum in July 2019.
https://forum.radarbox24.com/index.php?topic=101771.msg407051#msg407051 (https://forum.radarbox24.com/index.php?topic=101771.msg407051#msg407051)
.
-
I found the instructions in a post from Jan. 2021 by another user who mentioned they received those instructions from RB support: https://forum.radarbox24.com/index.php?topic=101771.msg472651#msg472651
Incidentally, the RB distribution of mlat-client is version 0.2.11. On my device, I have another mlat-client installation used by the ADSBExchange folks, and that is version 0.3.1. I'm curious as to the differences, but have not yet checked any git repositories.
-
I found the instructions in a post from Jan. 2021 by another user who mentioned they received those instructions from RB support: https://forum.radarbox24.com/index.php?topic=101771.msg472651#msg472651
The procedure given in the post you linked is copy-paste of the procedure in my post. This leads me to think of following possibilities
(1) The RB24 Support copy-pasted the procedure from my post and gave it to writer of that post, without mentioning my post, and this is an unfair act on part of Support.
(2) The RB24 Support gave him link to my post, and he copy-pated it from my post, but skipped to metion my post, which is an unfair act on his part.
.
-
Hi Andreas
Regarding mlat-client failing to restart when rbfeeder is restarted, you may please see my this post dated January 24, 2021:
https://forum.radarbox24.com/index.php?topic=104371.msg471821#msg471821 (https://forum.radarbox24.com/index.php?topic=104371.msg471821#msg471821)
-
Hi ab cd,
Thanks for providing all this information. It's great to know the situation, and I agree it's important to get the history and the attributions right. Had I known that code snippet had originated from you, I would of course have mentioned you to give you the full credit. Realizing that posts in this forum are modifiable, I have now gone back to my post and added an explicit reference to you in it.
Best regards,
Andreas / VA2WBT
-
Hi ab cd,
Thanks for providing all this information. It's great to know the situation, and I agree it's important to get the history and the attributions right. Had I known that code snippet had originated from you, I would of course have mentioned you to give you the full credit. Realizing that posts in this forum are modifiable, I have now gone back to my post and added an explicit reference to you in it.
Best regards,
Andreas / VA2WBT
Thank you Andreas.
Did you check following post about mlat-client failing to restart when rbfeeder is restarted by command "sudo systemctl restart rbfeeder"?
https://forum.radarbox24.com/index.php?topic=104371.msg471821#msg471821 (https://forum.radarbox24.com/index.php?topic=104371.msg471821#msg471821)
Please also see the image attached with that post. It is screenshot of my email dated December 13, 2020, to RB24 system developers about this issue.
.
-
Hi ab cd,
Yes, I read your screenshot at that other link -- very good. In the screenshot, you wrote "... upload to GitHub", but I imagine you really meant to write "... download from GitHub." Do I understand that correctly?
All things considered, I'm now pleased to have rbfeeder and mlat-client both working under a simple unprivileged user account on my RPi.
Best regards,
Andreas / VA2WBT
-
Hi ab cd,
Yes, I read your screenshot at that other link -- very good. In the screenshot, you wrote "... upload to GitHub", but I imagine you really meant to write "... download from GitHub." Do I understand that correctly?
I can understand your misunderstanding as you are not aware of full background.
The full statement should have been "Downloaded from my Github site, the mlat-client packages which I have earlier built from source code and have uploded these in February 2020 to my Github site".
Please see following post. It will clear your misunderstanding.
https://forum.radarbox24.com/index.php?topic=101771.msg433591#msg433591 (https://forum.radarbox24.com/index.php?topic=101771.msg433591#msg433591)
.
-
OK, yes, I see that there was some extra history that was the context for that screenshot. The repository that is in the instructions of yours that I found and posted above is now the official 0.2.11 mutability link here: https://github.com/mutability/mlat-client.git
After reinstalling mlat-client as discussed, a subsequent "sudo apt update" suggested that my mlat-client 0.2.11 was in need of an update, but to the same numbered version. I tried this, but then discovered the RB-specific problem returned, i.e. mlat-client would not start due to START_CLIENT="no" in /etc/default/mlat-client.
To at least fix this temporarily, I renamed /etc/apt/sources.list.d/rb24.list to ...rb24.list.disable, which should now prevent the destructive effect of an upgrade. If anyone has any cleaner or permanent solutions, I'd appreciate learning them.
So, back to the topic of this thread: it would be great if RB could "fix" the using of root, since it seems to be easily feasible (and, while at that, also fix the mlat-client distribution issue that abcd567 has raised long ago).
Best regards,
Andreas / VA2WBT
-
After reinstalling mlat-client as discussed, a subsequent "sudo apt update" suggested that my mlat-client 0.2.11 was in need of an update, but to the same numbered version. I tried this, but then discovered the RB-specific problem returned, i.e. mlat-client would not start due to START_CLIENT="no" in /etc/default/mlat-client.
To at least fix this temporarily, I renamed /etc/apt/sources.list.d/rb24.list to ...rb24.list.disable, which should now prevent the destructive effect of an upgrade. If anyone has any cleaner or permanent solutions, I'd appreciate learning them.
Dont delet or rename anything from apt list or gpg key.
A very easy way to prevent RB24 from replacing mlat-client package you built & installed, by package from RB24 repository during any unattended or intentional update/upgrade is to issue following command:
sudo apt-mark hold mlat-client
If your built & installed mlat-client has already been replaced by the one from RB24 repository, purge it out:
sudo apt-get purge mlat-client
## now install again the package you have already built
sudo dpkg -i mlat-client_*.deb
## now mark your package on hold so that it is not again replaced
sudo apt-mark hold mlat-client
.
-
The repository that is in the instructions of yours that I found and posted above is now the official 0.2.11 mutability link here: https://github.com/mutability/mlat-client.git
The mutability's above noted github repository is not a "Full" repository as it does not have any pre-built packages, nor it has any gpg key to add it to RPi's local apt lists. It hosts only source code.
This source code is downloaded to RPi by command "git clone https://github.com/mutability/mlat-client.git". One has then to build mlat-client package locally on his RPi by command "sudo dpkg-buildpackage -b -uc",then install it by command "sudo dpkg -i mlat-client_*.deb".
The RB24 has built their mlat-client package using above source code (possibily customized by RB24) and hosted in their repository alongwith rbfeeder package.
The rbfeeder's install script adds gpg key and file /etc/apt/sources.list.d/rb24.list to RPi. Once this is done both the rbfeeder and mlat-client are downloaded and installed fro RB24 repository by commands "sudo apt-get install rbfeeder" and "sudo apt-get install mlat-client".
.
-
On my github site, no source code is hosted, but it does host packages built from source code of mutability. It also has scripts to automatically download & install these packages, and a README.md file containing how-to.
To see the .deb packages which I have uploaded on my github site, go to this url
https://github.com/abcd567a/mlat-client-package/releases (https://github.com/abcd567a/mlat-client-package/releases)
Click "Assets" to expand it, and it will show the packages I have upliaded. Click any one, and it will be downloaded.
Please see attached screenshot.
-
Thanks very much for those tips! I've taken your advice and have done "sudo apt-mark hold mlat-client" to prevent inadvertent damage to my setup during future upgrading.