Getting rpi-connect-lite to work

Community Tutorials
1

Hi dear community,

Today I installed DietPi the first time in order to resurrect on old Raspberyy Pi 1 B+ in order to use it as a WiFi-ethernet-bridge and DCHP-server on the ethernet subnet side (with dnsmaq).

Knowing that DietPi-Dashboard also provides a web-console, I still liked the ease of (remote) use of pi connect through rpi-connect-lite but struggled a bit to get it working as there seem to be a few differences compared with Raspberry Pi OS.

After a bit of fiddling, this is how I got it up and running and I hope this may be useful for someone else with a similar desire. A few things need to be set up manually still after the initial run but this could possibly also scripted in /boot/Automation_Custom_Script.sh but I did not have the time yet to piece this together so far.

  • in dietpi.txt:
    • add rpi-connect-lite to AUTO_SETUP_APT_INSTALLS
    • set AUTO_SETUP_AUTOMATED=1
    • set AUTO_SETUP_AUTOSTART_LOGIN_USER=dietpi (optional, plus I also renamed the user but that should not make any difference here)
  • in the meantime, log into https://connect.raspberrypi.com/settings and create a new auth key.
  • after the initial install has completed, get a user prompt and run (as user!)
    • sudo systemctl unmask systemd-logind
    • sudo systemctl start dbus systemd-logind
      • note: I did not need to install dbus as it was already installed, probably pulled in as a dependency of rpi-connect-lite?
    • rpi-connect on
    • rpi-connect signin --auth-key=rpuak_<rest-of-your-auth-key>
    • sudo loginctl enable-linger $USER
      • this step differs from what most Raspberry Pi OS tutorials out there mention; omitting sudo (+ $USERat the end) here will let the command fail as DietPi lacks polkitd / pkttyagent. With this construct however, one can avoid installing those packages.

Afterwards, my Pi running DietPi was showing up in the devices section of pi connect and I was able to open a remote shell into it. :partying_face:

2

So rpi-connect seems to start a systemd --user service as executing user? That indeed requires:

  • “lingering”, hence a persistent systemd --user instance up at boot, else systemctl --user services cannot start at boot, and when started manually, would stop the moment the user logs out.
  • systemctl access for non-root users generally requires systemd-logind, which requires dbus.
  • And loginctl as non-root user indeed requires polkitd, which can be also installed via:
    sudo apt install polkitd

So rpi-connect allows to access the executing user’s console from a web UI at connect.raspberrypi.com?

It should be actually possible to setup the service as system service, running as intended user, without the lingering overhead, hence without the need for logind and dbus. But the package ships the units as user services only. Would be an interesting experiment:

sudo cp -a /usr/lib/systemd/user/rpi-connect* /etc/systemd/system
sudo sed -i '/^\[Service\]/a\User=dietpi' /etc/systemd/system/rpi-connect*
sudo systemctl daemon-reload
sudo systemctl start rpi-connect-signin rpi-connect

Instead of a hardcoded user, it could be turned into instantiated units, so that systemctl start rpi-connect@dietpi works, to start (and in case enable) it as any user. That way root/sudo remains in charge to enable and start the services, but it is otherwise similarly simple to start it for any user, without dedicated systemd --user service manager instance, and the extended permissions/policy capabilities needed to manage such.

EDIT: And yes, the rpi-connect-lite package pull in dbus-user-session as dependency. Indeed the D-Bus user session is needed as well, for non-root users to communicate with their systemd --user instance via systemctl.

As can be seen, this model is overall quite complex: D-Bus, an additional user D-Bus instance, an additional systemd user instance, logind, polkitd to allow users enable their systemd user instance permanently via lingering. 4 additional services which are all about granting extended permissions and communication setup, to start the 1 actually wanted service. And with minimal changes, it would be possible without these 4 additional services. But granted, that if you install a desktop environment, all this is needed anyway. So it only makes a difference on non-GUI/headless systems.