Dear Maintainer,

btrfs is a gread filesystem. But adduser can not create a
btrfs-subvolume for users home. Please add the functionality for
creating a btrfs-subvolume instead of a directory.

Thank you

Jakob

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-home    use 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

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-home    use 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

Control: retitle -1 use useradd's --btrfs-subvolume-home option
thanks

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

Control: retitle -1 use useradd's --btrfs-subvolume-home option
thanks

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

Hi,

Interesting POV.  (opt-in vs. automatic)

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

Hi,

Interesting POV.  (opt-in vs. automatic)

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

Hi,

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.

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

Hi,

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.

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

Hi,

I now understand your POV and where it came from.

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.)

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.

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.

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

Hi,

I now understand your POV and where it came from.

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.)

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.

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.

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

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

Control: tags -1 wontfix
Control: severity -1 wishlist

Thanks for your understanding. I appreciate that.

Thats how I would do it as well, yes.

Will do.

I think that would be a strong point, yes.

Noted. Thanks for your evaluation and explanation.

Greetings
Marc

Control: tags -1 wontfix
Control: severity -1 wishlist

Thanks for your understanding. I appreciate that.

Thats how I would do it as well, yes.

Will do.

I think that would be a strong point, yes.

Noted. Thanks for your evaluation and explanation.

Greetings
Marc