Bug#863751: Add --btrfs-subvolume-home option to adduser
Control: tags -1 wontfix Control: severity -1 wishlist On Wed, Mar 09, 2022 at 10:05:26AM +0900, Osamu Aoki wrote: > > -Original Message- > > From: Marc Haber > > To: Osamu Aoki > > Cc: 863...@bugs.debian.org, 863751-submit...@bugs.debian.org, Nicholas D > > Steeves > > > > 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. Thanks for your understanding. I appreciate that. > > 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.) Thats how I would do it as well, yes. > 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. Will do. > * Debian installer considers to support btrfs as root filesystem as out-of-box > feature and this becomes a required feature of installation process. I think that would be a strong point, yes. > > 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). Noted. Thanks for your evaluation and explanation. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#863751: Info received (Bug#863751: Add --btrfs-subvolume-home option to adduser)
Hi, I should have checked my typos more. Important corrections are: WRONG: make sharpshoots of their data easily. CORRECT: make snapshots of their data easily. WRONG: It they become separate btrfs subvolume, CORRECT: If they become separate btrfs subvolume, (There are many other errors such as 3rd person singular "s" for verbs ...) Osamu
Bug#863751: Add --btrfs-subvolume-home option to adduser
Hi, > -Original Message- > From: Marc Haber > To: Osamu Aoki > Cc: 863...@bugs.debian.org, 863751-submit...@bugs.debian.org, Nicholas D > Steeves > > 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
Bug#863751: Add --btrfs-subvolume-home option to adduser
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'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. > 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 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. 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? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#863751: Add --btrfs-subvolume-home option to adduser
Hi, Interesting POV. (opt-in vs. automatic) > -Original Message- > From: Marc Haber > To: Osamu Aoki , 863...@bugs.debian.org, > 863751-submit...@bugs.debian.org > Cc: Nicholas D Steeves > Subject: Re: Bug#863751: Add --btrfs-subvolume-home option to adduser > Date: Tue, 8 Mar 2022 07:46:58 +0100 > > Control: retitle -1 use useradd's --btrfs-subvolume-home option > thanks > > On Sun, Feb 21, 2021 at 08:52:39PM +0900, Osamu Aoki wrote: > > The current useradd since 2019 has --btrfs-subvolume-home option. > > How does this option behave if the parent of the new home directory is > not on btrfs? adduser could add this option to all useradd calls but > this would only be possible if useradd will _silently_ ignore the option > if the parent directory is not btrfs and of course create a normal > directory in that case. If the operation is not silent, package > maintainers are going to redirect adduser's output to /dev/null which is > not desired from adduser's pov. > > Greetings > Marc 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.) 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. Osamu
Bug#863751: Add --btrfs-subvolume-home option to adduser
Control: retitle -1 use useradd's --btrfs-subvolume-home option thanks On Sun, Feb 21, 2021 at 08:52:39PM +0900, Osamu Aoki wrote: > The current useradd since 2019 has --btrfs-subvolume-home option. How does this option behave if the parent of the new home directory is not on btrfs? adduser could add this option to all useradd calls but this would only be possible if useradd will _silently_ ignore the option if the parent directory is not btrfs and of course create a normal directory in that case. If the operation is not silent, package maintainers are going to redirect adduser's output to /dev/null which is not desired from adduser's pov. Greetings Marc
Bug#863751: Add --btrfs-subvolume-home option to adduser
control tags -1 patch
thanks
The current useradd since 2019 has --btrfs-subvolume-home option.
$ useradd -h
Usage: useradd [options] LOGIN
useradd -D
useradd -D [options]
Options:
...
--btrfs-subvolume-homeuse BTRFS subvolume for home directory
...
(Yes, its manpage may need to be updated)
All we need is to add it to the adduser wrapper.
Here is my first try to add it. Please use this as a starting place.
I don't know if this option should be used for --system or not. Now it
is enabled. Please consider this point before adding this feature for
bulleseye+1=Bookworm
Regards,
Osamu
diff -Nru adduser-3.118.orig/adduser adduser-3.118/adduser
--- adduser-3.118.orig/adduser 2021-02-21 16:42:37.759786880 +0900
+++ adduser-3.118/adduser 2021-02-21 20:04:33.622833589 +0900
@@ -103,6 +103,7 @@
our $special_home = undef;
our $special_shell = undef;
our $add_extra_groups = 0;
+our $btrfs_subvolume_home = 0;
# Global variables we need later
my $existing_user = undef;
@@ -141,6 +142,7 @@
"conf=s" => \$configfile,
"no-create-home" => \$no_create_home,
"add_extra_groups" => \$add_extra_groups,
+ "btrfs-subvolume-home" => sub { $btrfs_subvolume_home = 1 },
"debug" => sub { $verbose = 2 } ) ) {
&usage();
exit RET_INVALID_CALL;
@@ -434,8 +436,13 @@
$shell = $special_shell || '/usr/sbin/nologin';
$undouser = $new_name;
my $useradd = &which('useradd');
-&systemcall($useradd, '-d', $home_dir, '-g', $ingroup_name, '-s',
- $shell, '-u', $new_uid, $new_name);
+if($btrfs_subvolume_home || $config{"btrfs_subvolume_home"}) {
+&systemcall($useradd, '--btrfs-subvolume-home', '-d', $home_dir, '-g',
+$ingroup_name, '-s', $shell, '-u', $new_uid, $new_name);
+} else {
+&systemcall($useradd, '-d', $home_dir, '-g', $ingroup_name, '-s',
+$shell, '-u', $new_uid, $new_name);
+}
if(!$disabled_login) {
my $usermod = &which('usermod');
&systemcall($usermod, '-p', '*', $new_name);
@@ -524,8 +531,13 @@
$shell = $special_shell || $config{"dshell"};
$undouser = $new_name;
my $useradd = &which('useradd');
-&systemcall($useradd, '-d', $home_dir, '-g', $ingroup_name, '-s',
- $shell, '-u', $new_uid, $new_name);
+if($btrfs_subvolume_home || $config{"btrfs_subvolume_home"}) {
+&systemcall($useradd, '--btrfs-subvolume-home', '-d', $home_dir, '-g',
+$ingroup_name, '-s', $shell, '-u', $new_uid, $new_name);
+} else {
+&systemcall($useradd, '-d', $home_dir, '-g', $ingroup_name, '-s',
+$shell, '-u', $new_uid, $new_name);
+}
&invalidate_nscd();
create_homedir (1); # copy skeleton data
diff -Nru adduser-3.118.orig/AdduserCommon.pm adduser-3.118/AdduserCommon.pm
--- adduser-3.118.orig/AdduserCommon.pm 2021-02-21 16:42:37.759786880 +0900
+++ adduser-3.118/AdduserCommon.pm 2021-02-21 17:24:07.189406049 +0900
@@ -212,6 +212,7 @@
$configref->{"skel_ignore_regex"} = "dpkg-(old|new|dist)\$";
$configref->{"extra_groups"} = "dialout cdrom floppy audio video plugdev users";
$configref->{"add_extra_groups"} = 0;
+ $configref->{"btrfs_subvolume_home"} = 0;
foreach( @$conflistref ) {
read_config($_,$configref);
diff -Nru adduser-3.118.orig/adduser.conf adduser-3.118/adduser.conf
--- adduser-3.118.orig/adduser.conf 2021-02-21 16:42:37.759786880 +0900
+++ adduser-3.118/adduser.conf 2021-02-21 17:12:48.397892674 +0900
@@ -80,6 +80,9 @@
# option above will be default behavior for adding new, non-system users
#ADD_EXTRA_GROUPS=1
+# Setting this to something other than 0 (the default) will cause adduser
+# to use BTRFS subvolume for home directory
+#BTRFS_SUBVOLUME_HOME=1
# check user and group names also against this regular expression.
#NAME_REGEX="^[a-z][-a-z0-9_]*\$"
diff -Nru adduser-3.118.orig/doc/adduser.8 adduser-3.118/doc/adduser.8
--- adduser-3.118.orig/doc/adduser.8 2021-02-21 16:42:37.763786931 +0900
+++ adduser-3.118/doc/adduser.8 2021-02-21 17:03:41.383307131 +0900
@@ -285,6 +285,9 @@
.B \-\-add_extra_groups
Add new user to extra groups defined in the configuration file.
.TP
+.B \-\-btrfs-subvolume-home
+Use BTRFS subvolume for home directory.
+.TP
.B \-\-version
Display version and copyright information.
diff -Nru adduser-3.118.orig/doc/adduser.conf.5 adduser-3.118/doc/adduser.conf.5
--- adduser-3.118.orig/doc/adduser.conf.5 2021-02-21 16:42:37.763786931 +0900
+++ adduser-3.118/doc/adduser.conf.5 2021-02-21 17:19:54.070588588 +0900
@@ -137,6 +137,10 @@
\fBEXTRA_GROUPS\fB
This is the list of groups that new non-system users will be added to.
By default, this list is 'dialout cdrom floppy audio video plugdev users games'.
+.TP
+\fBBTRFS_SUBVOLUME_HOME\fB
+Setting this to something other than 0 (the default) will cause adduser
+to use BTRFS subvolume for home directory
.SH NOTES
.TP
\fBVALID NAMES\fB
