Hi, > -----Original Message----- > From: Marc Haber <mh+debian-packa...@zugschlus.de> > To: Osamu Aoki <os...@debian.org> > Cc: 863...@bugs.debian.org, 863751-submit...@bugs.debian.org, Nicholas D > Steeves > <s...@debian.org> > Subject: Re: Bug#863751: Add --btrfs-subvolume-home option to adduser > Date: Tue, 8 Mar 2022 14:21:09 +0100 > > Hi, > > On Tue, Mar 08, 2022 at 07:16:57PM +0900, Osamu Aoki wrote: > > I was thinking opt-in only. > > > > I mean to add an opt-in --btrfs-subvolume-home option to adduser so > > the user can use this feature if he requests. I didn't think beyond. > > (I didn't test it on non-btrfs system so I don't know the answer to > > your question. Whoever specifies it in command line, he should know > > it.) > > I had a sane default in mind. As times have changed and maintainer / > developer resources are scarce, adduser primarily sees itself as a > policy wrapper to help package maintainers to create their package > accounts in their maintainer scripts without violating policy. Offering > account creation capabilities to the local admin has been pushed into > the background in the last decades.
I now understand your POV and where it came from. > I'd say then if the local admin wants to use a feature that adduser > doesnt offer, they are free to use other tools such as useradd directly > to get what they want. Yes. That's basically what I do here trivially. (I still use adduser. After whole standard d-i installation, I rename the primary user's home directory from root account on console and create subvolume in place and copy data into it.) > > As I come to think of this, since it is trivial to check FS of /home > > in adduser in advance by calling a basic shell command as: > > > > ``` $ stat -f -c %T /home btrfs ``` , adding this feature as an > > automatic option for pertinent system is an interesting thought for > > adduser too. > > I am reluctant to add filesystem specific code to adduser, as writing > automated tests is probably hard. I think it causes some dependency increase and resource drain for you. (I don't think it is so exotic to do this.) TBH, I am not pushing this patch after hearing back from you. I now think the best action is to label this as "wontfix" on condition until followings become about to be reached. * Linux kernel supports btrfs as its primary filesystem over ext4. * useradd manpage (not -h output) explicitly includes this option. * Debian installer considers to support btrfs as root filesystem as out-of-box feature and this becomes a required feature of installation process. When these things are on horizon, this feature may be desirable one to have for user to make sharpshoots of their data easily. > I would think more about adding this if having account-specific btrfs > subvolumes per _system_ account would be a valid feature to have AND if > useradd is smart enough to not error out or spew warnings if one tries > to create a btrfs subvolume on non-btrfs volumes. At th moment, I am not > convinced that this is worth spending developer / maintainer time on. As I see many so-called _system_ accounts in /etc/passwd, their home directory are everywhere under /var, /bin, /usr/bin, ... It they become separate btrfs subvolume, making snapshot script will be nightmare to address all. So it's bad idea to do so unless some rare maintainer script specifically request so (sbuild, apt-cacher-ng may be good candidate if their maintainer wishes but most _system_ account using /nonexistent, /bin . /var/... as home directory shall not use this to maintain easy snapshot recoverable system). Anyway, practically that kind of question happens only when debian-installer start supporting installation of system root on btrfs subvolume as default and some packages start taking advantage. Your concern for your time is valid one to reject this patch. > Would it help to have an "useradd-extra-options" command line option and > configuration file setting that causes their respective contents to > be added to useradd's command line verbatim? Which other commands would > need a respective foo-extra-options option? > As I said above, I don't see such benefit under current situation for most of _system_ accounts. This is useful mostly for user accounts. Currently, Debian can be installed and booted from btrfs subvolume using d-i but that requires a lot of manual tweakings. Compared to them, user's home directory as btrfs subvolume is a minor non-essential tweak. Regards, Osamu
