Re: strawman proposal: homed directories for users

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 9 Oct 2024, at 10:04, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote:

On Tue, Oct 08, 2024 at 06:14:29PM +0100, Barry Scott wrote:
On 4 Oct 2024, at 16:05, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote:

Hi folks,

I was recently doing a bunch of test reinstalls of Fedora [1],
looking to see if it's complicated to retain the user directories
during a reinstall. The answer is, sadly, that it's possible only with
some manual tinkering. This is a known problem [2].

With a little bit of trickery, Anaconda will let the "home" subvolume
be and install the system to a new "root" subvolume, so user data is
preserved. But then after a reboot a new user will be created, because
the old user is not hooked up into /etc/passwd.

We actually have a partial solution for this: systemd-homed.
With systemd-homed the information about the user is maintained in the
user directory/subvolume/partition, e.g. /home/username.homedir.
After a reinstall, ideally nothing needs to be done and the user
account is ready to be used.

I like the idea of being able to reinstall and keep the /home.
But I'd rather not use systemd-homed to get the feature.
I already have full-disk-encryption for security.

What about having the necessary meta data in a per user file in /home
and read that when doing the reinstall?

I would have /home/barry and /home/barry.metadata for example.

What you describe is pretty much the proposal you were replying to,
just with different paths. You'd have (unencrypted)
/home/barry.homedir/ and /home/barry.homedir/.identity and
systemd-homed would create /home/barry/ with a bind mount.

You mention FDE, but the proposal was explicitly about homed homes
without encryption at the homed level. This kind of setup is often
used with FDE.

I'll search for the docs on this style of use. Thanks for the heads up.

Barry



Zbyszek
-- 
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

-- 
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux