rpi-connect 1.0 used to be a globally-enabled user service which meant it had symlinks in /etc/systemd/user/default.target.wants and /etc/systemd/user/rpi-connect.service.wants. This meant the various systemd services would come up for any user slice but had the downside that individual users couldn't opt out, i.e. running systemctl --user disable rpi-connect.service wouldn't do anything for a regular user because it wouldn't touch the symlinks in /etc/systemd/user.
rpi-connect 2.0 switches to an opt-in, individually-enabled user service by having symlinks in ~/.config/systemd/user/default.target.wants and ~/.config/systemd/user/rpi-connect.service.wants instead. This way, users have to explicitly opt in to using Connect (either by using the new "Turn On Raspberry Pi Connect..." option in the new panel plugin or using the new "rpi-connect on" CLI) and they can then choose to opt-out on an individual user basis.
The tricky bit was trying to preserve the 1.0 behaviour (Connect on for all users) for upgrading users so the upgrade process will attempt to replace your global symlinks with ones for every user. This is why you're seeing it be enabled for root and kali in the output from apt. In reality, that means symlinks have been placed in the home directories for your root and kali user but nothing will happen unless there is a systemd user slice running for that user. You can happily bin those symlinks either by running "rpi-connect off" as those users or deleting the individual files.
You shouldn't need to do this more than once as nothing will automatically re-enable Connect for a user unless you're calling "rpi-connect on" or using the UI as that user.
rpi-connect 2.0 switches to an opt-in, individually-enabled user service by having symlinks in ~/.config/systemd/user/default.target.wants and ~/.config/systemd/user/rpi-connect.service.wants instead. This way, users have to explicitly opt in to using Connect (either by using the new "Turn On Raspberry Pi Connect..." option in the new panel plugin or using the new "rpi-connect on" CLI) and they can then choose to opt-out on an individual user basis.
The tricky bit was trying to preserve the 1.0 behaviour (Connect on for all users) for upgrading users so the upgrade process will attempt to replace your global symlinks with ones for every user. This is why you're seeing it be enabled for root and kali in the output from apt. In reality, that means symlinks have been placed in the home directories for your root and kali user but nothing will happen unless there is a systemd user slice running for that user. You can happily bin those symlinks either by running "rpi-connect off" as those users or deleting the individual files.
You shouldn't need to do this more than once as nothing will automatically re-enable Connect for a user unless you're calling "rpi-connect on" or using the UI as that user.
Statistics: Posted by paulmu — Mon Nov 04, 2024 11:51 am