Local user builds to use with conventional Linux distributions

[vkhodygo]

Is your feature request related to a problem? Please describe

Current versions of Klipper and Moonraker both revolve around using RPi of some sort as a dedicated server machine.
Unfortunately, chip shortage and bloody scalpers make buying one nigh impossible.

I use an old laptop with Archlinux onboard, there are some issues here though.

• I'd like not to use KIAUH as it - for lack of a better word - contaminates the system. We have package managers exactly for that. I don't mind such approach, but that's when the only purpose of your machine is printing. In this case discarding the install is probably acceptable.
• VMs and docker containers are extremely greedy and require too much maintenance. Docker is a security hole.
• AUR packages are manageable, but install multi-user services. That results in extra groups, users, weird permissions, Klipper writing directly to your root partition, you name it. I had a working installation, but I couldn't copy .gcode files to the destination directory. Lack of permissions, they said, but didn't specify how to resolve this.

Describe the solution you'd like

Use the Force, Luke systemctl --user and service templates. I've updated the aforementioned AUR packages, the results are right below.

Klipper is up and running, my ~/ now contains all required files and directories. There is still some tweaking to be done, but after two days of config testing and rebuilding I'm pretty satisfied with the result.

Moonraker though is a bit different. I have an instance starting, but it fails to connect to the one of Klipper. The log says something about [No User], still, I failed to find the source of this problem. Sending a GET request from the terminal via curl works just fine, I get a [_TRUSTED_USER_] response.

I attach some logs and my build files (see below) just in the case someone wants to reproduce this abomination.

Describe alternatives you've considered

Buying another machine, but I've already heavily invested into the printer, enough wasting my money for the time being.

Additional information

moonraker.2022-04-16.log
klipper.log
printer.txt
moonraker.txt
moonraker.tar.gz
klipper.tar.gz
klipper_systemd.log
moonraker_systemd.log

[Arksine]

I'm moving the discussion from the PolicyKit thread to here, since that issue isn't the proper venue for debating new features, removing features, or changing Moonraker's method of installation. I'm going to respond your feedback here, but first I must address the elephant in the room: This change isn't feasible for 99.9% of Moonraker installations. While running systemd --user is fine on a desktop, it will not work without an active session. This defeats the purpose of headless SBCs, as users would be required log into a session, start Moonraker, and keep the session open.

I did some research and it is possible to control services started with systemctl --user start without elevated privileges.

Your proposed solution seems to be that all other services are run as user services as well. However Moonraker has no control over how they are installed. Thus, this requires all applications in Klipper ecosystem, not just Moonraker, to make these changes. Making this change directly to Moonraker would thus break this functionality with existing apps.

I still do not understand why you need to implement package update here though.
Automatic Linux update is and was never recommended, since there might be changes requiring your approval. In addition, giving an app rights to control system packages doesn't look secure to me.

My position is that this is redundant and should be removed. We have package managers exactly for that. It would also make the process of distribution and code maintenance much easier.

Moonraker's linux update isn't automated, it requires that the user actively accept an update. It uses packagekit in the same way as several other front ends, the difference is that it doesn't run on a desktop. While updating the system isn't a "requirement", updating Moonraker's dependencies is if one wishes to update Moonraker itself. Furthermore, this functionality is only redundant if you intend to install Moonraker on a Desktop, its absolutely useful for users running Moonraker headless. Security is debatable, it isn't possible to do potentially insecure operations such as add new repositories. It is possible, indirectly, to install new packages, but to install malicious packages it would be necessary to circumvent protections provided by the repositories themselves. An attempt to install packages that require approval beyond what is granted by PolKit would result in an error. In short, I disagree with your proposal that it should be removed. That said, its entirely optional, and you need not configure it in moonraker.conf.

Finally, I suspect that Moonraker still needs PolKit permissions to restart/shutdown the system when run with --user.

FWIW, there is nothing wrong creating a new install method that runs Moonraker, Klipper, etc on a desktop as --user. In this scenario it is unlikely that Moonraker's privileged functionality is necessary. This would be a KIAUH like project, and IMO not something that is specific to Moonraker or necessarily belongs in the Moonraker repo.

[vkhodygo]

I must address the elephant in the room

Your point is absolutely fair, however, this approach works only for existing users of Klipper/Moonraker.
Finding and buying a new RPi is pretty much impossible nowadays. Anecdotal evidence, but I've been waiting for my order for about two months already. I checked the product page some time ago and it was saying something about mid-2023.
Any new member of the community has much better chances of buying/reusing an old laptop or desktop for like £30. There are also people using VMs for that sort of activity, but that's somewhere in between two poles.

it will not work without an active session

Could lingering help in this situation?

Thus, this requires all applications in Klipper ecosystem, not just Moonraker, to make these changes

I'm not sure you need to change anything else aside from Klipper and Moonraker, but this requires further investigation.

Moonraker's linux update isn't automated, it requires that the user actively accept an update.

What's the difference between Moonraker and a conventional package manager then?

While updating the system isn't a "requirement", updating Moonraker's dependencies is if one wishes to update Moonraker itself.

Partial system update is considered as bad practice in some Linux circles.
Still, that wasn't a proposal, but a suggestion of a sort.
One more thing here: do you update Moonraker manually?

Finally, I suspect that Moonraker still needs PolKit permissions to restart/shutdown the system when run with --user.

systemctl doesn't need the --user flag to restart the system, I'm not sure how the permissions work here though. What do I miss here?

This would be a KIAUH like project, and IMO not something that is specific to Moonraker or necessarily belongs in the Moonraker repo.

No problem, but I'd like to get your help with this.
I tried as you've already seen, but my installation of Moonraker fails to see Klipper. I strongly suspect that this due to some flags missing/service names being different, however, I failed to find the exact spot in the code.

[Arksine]

Your point is absolutely fair, however, this approach works only for existing users of Klipper/Moonraker.

To be fair, I think most users are ok with installing Moonraker in containers or in a VM. I also believe that the current installation method would work on a desktop. I understand that you don't prefer these options, which is a valid opinion, but it certainly possible for new users to install Moonraker on a desktop PC.

Could lingering help in this situation?

It could work, however I'm not sure that there is an advantage of configuring a lingering user over the current installation method. It seems to defeat the purpose of user sessions.

I'm not sure you need to change anything else aside from Klipper and Moonraker, but this requires further investigation.

It isn't necessary to manage other services to get a working installation, but it is be necessary to support this in Moonraker's official install method. Moonraker can manage the MoonCord, KlipperScreen, Telegram, and webcamd services. It is also possible to configure Moonraker to update other applications installed as system services, after which the service may need to be restarted.

What's the difference between Moonraker and a conventional package manager then?

Moonraker is not a package manager, it provides a front end for the existing package manager through PackageKit. It allows users to know when new packages are available and initiate an upgrade without having to login and use the cli. As mentioned previously, it is 100% optional, but many requested and use this functionality.

systemctl doesn't need the --user flag to restart the system, I'm not sure how the permissions work here though. What do I miss here?

Systemctl isn't used to restart the system, logind is. PolKit permissions are necessary to execute the logind commands over dbus. That said, like package management this is 100% optional and not required to get a working installation.

Partial system update is considered as bad practice in some Linux circles.
Still, that wasn't a proposal, but a suggestion of a sort.
One more thing here: do you update Moonraker manually?

Moonraker doesn't do a partial system update, however it can install new dependencies. Moonraker notfies front ends when an update is available. It is up to the user to initiate an update. If the update manager is not configured then updates must be done manually.

No problem, but I'd like to get your help with this.
I tried as you've already seen, but my installation of Moonraker fails to see Klipper. I strongly suspect that this due to some flags missing/service names being different, however, I failed to find the exact spot in the code.

I am willing help insofar as I can answer specific questions about Moonraker. I doubt you are experiencing an issue in the code, Mooraker only cares about the name of the unix socket. Moonraker should log when permissions aren't adequate, so if it can't connect the most likely scenario is that the unix socket isn't there. If it is there, you can use Klipper's whconsole.py debugging script to attempt to connect and send commands to Klipper.

The [no user] entry does not refer to the linux user, it refers Moonraker's user management enabled through the authorization section. Since the landing page doesn't require authorization it never sets a user for the request. All other APIs will show the current user, whether it be one created through a front end, the API_KEY_USER, or TRUSTED_USER, depending on the authorization configuration. Needless to say, this isn't related to your issue of being unable to connect to the Unix Socket.

[The-Monkey-King]

I ask since no movement has taken place from the author as to if they are still experiencing the issue(s) and that the request would break moonraker for 99.9% of all users - that this open enhancement be closed.

It has been over 16 months.