search

fullstory / calamares-settings-aptosid

aptosid theme and settings for the Calamares Installer
0 stars 0 forks source link

Add support for systemd-homed #5

Open kel-mo opened 1 week ago

kel-mo commented 1 week ago

There exists: https://github.com/calamares/calamares/issues/1554

... and it contains no meaningful development.

We would need to patch user.conf handlers to select the user home tooling of adduser vs homectl for linux targets: https://github.com/calamares/calamares/blob/calamares/src/modules/users/Config.cpp https://github.com/calamares/calamares/blob/calamares/src/modules/users/Config.h https://github.com/calamares/calamares/blob/calamares/src/modules/users/users.conf

Then we would need to patch the code which creates the user: https://github.com/calamares/calamares/blob/calamares/src/modules/users/CreateUserJob.cpp

And for starters we would just be replacing the tooling like for like. After that's working the following enhancement would need to be considered:

We would need to handle the case that user selects an existing /home in the partitioning tool and perhaps create a/extend the /home migration handler.

An alternative approach would be to let Calamares do it's thing and create an initial user using adduser, only to migrate it to a systemd-homed after the fact with homectl. That would be less desirable solution to the above for upstream, but might be an option for prototyping the solution prior to attempting tight integration into the C++/QT codebase.

Reference materials: https://systemd.io/HOME_DIRECTORY/ https://systemd.io/CONVERTING_TO_HOMED/ https://wiki.archlinux.org/title/Systemd-homed

kel-mo commented 5 days ago

After attempting to integrate the simplest of systemd-homed integrations into the fll live boot, I have learned that this will be even trickier to implement via Calamares.

homectl is typically ran interactively and prompts the user for a password. Manual pages imply that credentials can be passed on by some magic json (https://systemd.io/USER_RECORD/). Perhaps the password can be passed in by stdin. homectl must be run in an environment where systemd is PID 1. The password is then used for any of the luks based home configurations - which must be handled separately to disk or partition based luks encryption the user may have configured in the partitioning module. It may accept an external device as a target, but currently not a partition until it is enhanced to be aware of GPT structures.

The easiest starting point would be to treat the live media as a pre-installation environment and use the username= cheatcode (ideally) or create a live systemd-homed /home for migration to the installation path along with public and private host keys.

Autologin option that systemd-homed offers is not functional for even non encrypted plain directory /home so the choice would need to be taken away from the GUI. systemd-homed should not be offered if the installation if / or separate /home is defined in the partitioning stage.

kel-mo commented 5 days ago

This might allow for the pre-existing live user to be migrated to the install without resorting to too many hacks: https://github.com/systemd/systemd/issues/30136

Ultimately, I think systemd-homed needs to bake for a little while longer and receive a bunch of enhancements before putting too much effort into offering it as an option.