Re: git: 36db6b04962a - main - hier(7): document /home/ and /usr/home/

From: Mike Karels <mike_at_karels.net>
Date: Sat, 13 May 2023 23:00:44 UTC
On 13 May 2023, at 17:48, Rodney W. Grimes wrote:

>> On 12 May 2023, at 19:43, Rodney W. Grimes wrote:
>>
>>>> Rod and I discussed this, and I?m top-posting a summary of a proposal that
>>>> we both support.  I?ll leave the last message from the list below for
>>>> reference.  Our consensus is that the main problem is the code in pw(8)
>>>> (used by adduser, and hence bsdinstall) that interprets /home as /usr/home,
>>>> installing a symlink for /home, and similarly for any other home directory
>>>> whose parent has a single component.  We propose to remove that code, and
>>>> also modify bsdinstall?s zfs script to create a home dataset rather than
>>>
>>> Small nit,  zfs already creates the data set as $POOL/usr/home, this
>>> would change to $POOL/home.
>>>
>>>> usr/home.  adduser presents a default home directory using /home, so this
>>>> will continue to agree.  As Rod said at the start of this thread, home
>>>> directories really don?t belong in /usr, and the only reason they were
>>>> there is because of the previous root + /usr partitioning.  Now the default
>>>> is one large partition.  Of course, people who want to partition differently
>>>> can do whatever they want.
>>>>
>>>> It will still be possible for admins to create home directories in
>>>> /usr/home, they will just have to do so explicitly for pw to create the
>>>> directory, and manually create a /home symlink if desired.  If they have
>>>> a small root file system, they will want to put home directories elsewhere.
>>>>
>>>> A followup change would be to change various man pages that refer to
>>>> /usr/home.
>>
>> The changes are now in review:
>>
>> https://reviews.freebsd.org/D40085	pw change to use the specified dir
>> https://reviews.freebsd.org/D40086	bsdinstall change to create /home
>> 									rather than /usr/home dataset on ZFS
>> 		Mike
>
> Need one more to backout the changes to hier(7)?

Two or three more, I see other references too.  I’ll make sure that these
are generally accepted first.

		Mike
>>
>>>> On 11 May 2023, at 12:32, Rodney W. Grimes wrote:
>>>>
>>>>>> On 11 May 2023, at 9:58, Rodney W. Grimes wrote:
>>>>>>
>>>>>>>> On Wed, 10 May 2023 16:48:12 -0500
>>>>>>>> Mike Karels <mike@karels.net> wrote:
>>>>>>>>
>>>>>>>>> On 10 May 2023, at 10:13, Cy Schubert wrote:
>>>>>>>>>
>>>>>>>>>> In message <ba22a75d-06c0-371e-603e-7ded9d1dca97@freebsd.org>, Mitchell
>>>>>>>>>> Horne w
>>>>>>>>>> rites:
>>>>>>>>>>> On 5/10/23 11:19, Rodney W. Grimes wrote:
>>>>>>>>>>>>> The branch main has been updated by mhorne:
>>>>>>>>>>>>>
>>>>>>>>>>>>> URL: https://cgit.FreeBSD.org/src/commit/?id=36db6b04962a01ff7b21592def02d
>>>>>>>>>>> 4c570dac939
>>>>>>>>>>>>>
>>>>>>>>>>>>> commit 36db6b04962a01ff7b21592def02d4c570dac939
>>>>>>>>>>>>> Author:     Mitchell Horne <mhorne@FreeBSD.org>
>>>>>>>>>>>>> AuthorDate: 2023-05-10 12:53:56 +0000
>>>>>>>>>>>>> Commit:     Mitchell Horne <mhorne@FreeBSD.org>
>>>>>>>>>>>>> CommitDate: 2023-05-10 13:25:17 +0000
>>>>>>>>>>>>>
>>>>>>>>>>>>>      hier(7): document /home/ and /usr/home/
>>>>>>>>>>>>>
>>>>>>>>>>>>>      Reviewed by:    imp
>>>>>>>>>>>>>      MFC after:      1 week
>>>>>>>>>>>>>      Sponsored by:   The FreeBSD Foundation
>>>>>>>>>>>>>      Differential Revision:  https://reviews.freebsd.org/D40002
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>   share/man/man7/hier.7 | 10 ++++++++++
>>>>>>>>>>>>>   1 file changed, 10 insertions(+)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/share/man/man7/hier.7 b/share/man/man7/hier.7
>>>>>>>>>>>>> index ff11289436a1..b6759dd6e65b 100644
>>>>>>>>>>>>> --- a/share/man/man7/hier.7
>>>>>>>>>>>>> +++ b/share/man/man7/hier.7
>>>>>>>>>>>>> @@ -90,6 +90,10 @@ file descriptor files;
>>>>>>>>>>>>>   see
>>>>>>>>>>>>>   .Xr \&fd 4
>>>>>>>>>>>>>   .El
>>>>>>>>>>>>> +.It Pa /home/
>>>>>>>>>>>>> +user HOME directories.
>>>>>>>>>>>>> +This is a symlink to
>>>>>>>>>>>>> +.Pa /usr/home/
>>>>>>>>>>>>
>>>>>>>>>>>> /usr is "contains the majority of user utilities and applications"
>>>>>>>>>>>> it should not contain home directories.
>>>>>>>>>>>>> I do not know when this move to usr came about it was traditionally
>>>>>>>>>>> /home.
>>>>>>>>>>>> I do not know why /usr/home even exists, it is not needed by
>>>>>>>>>>>> anything I am aware of.  If we have a compatible link it
>>>>>>>>>>>> should be, usr/home -> ../home and /home should be the
>>>>>>>>>>>> directory.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I agree that /usr/home is strange, and is unique (?) to FreeBSD.
>>>>>>>>>>>
>>>>>>>>>>> The oldest commit in the output of `git log --grep '/usr/home'` is:
>>>>>>>>>>>
>>>>>>>>>>> commit f2400d465896a8e4f6fdc57eba840cf49b25bbbd
>>>>>>>>>>> Author: David Nugent <davidn@FreeBSD.org>
>>>>>>>>>>> Date:   Fri Jan 3 04:42:18 1997 +0000
>>>>>>>>>>>
>>>>>>>>>>>      Implemented /home -> /usr/home symlink kludge.
>>>>>>>>>>>      If home basedir would be created in the root partition, create
>>>>>>>>>>>      it under /usr instead, and symlink /basedir -> /usr/basedir.
>>>>>>>>>>>
>>>>>>>>>>> Notes:
>>>>>>>>>>>      svn path=/head/; revision=21242
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So it has been this way for 26 years at least. I do not know what to say
>>>>>>>>>>> about whether /usr "should" contain it, but it does.
>>>>>>>>>>
>>>>>>>>>> Usually history matters. I can understand not changing it. On the flip
>>>>>>>>>> side, I cut my UNIX teeth on SunOS 4 and Solaris where /home was /home --
>>>>>>>>>> albeit automounted from /export/home on localhost or some NFS server. In
>>>>>>>>>> the Red Hat land at $JOB, /home is its own partition (actually an LVM
>>>>>>>>>> volume). In both cases /home is not in /usr because end-users can fill
>>>>>>>>>> /usr. This can be problematic operationally because it's yet another
>>>>>>>>>> headache to deal with should someone fill the filesystem. Filling /usr is
>>>>>>>>>> more serious than filling /home.
>>>>>>>>>>
>>>>>>>>>> As a point of interest, when I installed my first FreeBSD many moons ago I
>>>>>>>>>> used the Solaris standard of /export/home, using amd (now automount) to
>>>>>>>>>> serve my /home. I'm not advocating we do this, it's overkill, but /home
>>>>>>>>>> should not live in /usr. It's a potential headache for any sysadmin.
>>>>>>>>>>
>>>>>>>>>> With ZFS the solution is easy. With UFS based systems there are a lot of
>>>>>>>>>> other factors that go into how we install the "default" from the get-go.
>>>>>>>>>
>>>>>>>
>>>>>>> First off, thank you Mike for looking at this closer.  Add me to any reviews
>>>>>>> you might creat.
>>>>>>>
>>>>>>>>> The situation is a fair mess.  It took me a little while to figure out that
>>>>>>>>> the kludge referenced above is in the pw(8) command, which is used as the
>>>>>>>>> backend to adduser(8).  Neither /home nor /usr/home is in the base package.
>>>>>>>>> adduser defaults to /home/user, and creates the parent directory (e.g. /home)
>>>>>>>>> if it does not exist, but if there is no internal slash, pw moves the parent
>>>>>>>>> to /usr.  In this case, it makes the symlink from  root.  zfs is different,
>>>>>>>>> in that it includes a usr/home dataset already (created by bsdinstall).
>>>>>
>>>>> I am proposing we fix this.  More below.
>>>>>
>>>>>>>>> In this case, creating a user with /home/user causes the symlink to be added
>>>>>>>>> as a side effect.
>>>>>>>>>
>>>>>>>>> I?m sure the kludge was originally done when root and /usr were separate
>>>>>>>>> file systems by default, root was small, and there was no /home by default.
>>>>>>>>> However, we now default to a single large file system (with datasets, in
>>>>>>>>> the zfs case).
>>>>>>>>>
>>>>>>>>> All of this really is a horrible kludge, and it is a house of cards.  I'm
>>>>>>>>> amazed that it doesn't break more often.  I'm tempted to remove the kludge
>>>>>>>>> and change the zfs setup to create a home dataset rather than usr/home.
>>>>>>>
>>>>>>> Or make it a menu option(s):
>>>>>>> if (zfs) "Create a user home dataset?" (default yes)
>>>>>>> if (ufs) "Create a user home directory?" (default yes)
>>>>>>
>>>>>> Are you suggesting that bsdinstall should do this?  For ufs, there is no
>>>>>> need.
>>>>>
>>>>> Yes I am suggesting that bsdinstall should have a knob to turn
>>>>> on (by default) and off the creation of a "home dataset/directory"
>>>>> as you well need that if you choose to add users during a bsdinstall
>>>>> run, or you may not want a /home at all (currently not possible) as you
>>>>> have other mechanisms for dealing with it.
>>>>>
>>>>> The need for this is just as valid for ufs as it is for zfs.
>>>>>
>>>>>>
>>>>>>> 	"User home location: /home" (This is default)
>>>>>>
>>>>>> Are you proposing that the default for pw should be set at this point?
>>>>>> From all I read the default for pw is already, and should remain /home.
>>>>> Man page bears that out.  It has no mention of any symlink or usr/home.
>>>>>
>>>>>> That doesn?t seem necessary, and I don?t know if it would work from
>>>>>> bsdinstall.
>>>>>
>>>>> No, this has nothing to do with pw directly, this is simply the path
>>>>> of the dataset(zfs)/directory(ufs) that bsdinstall should create IFF
>>>>> you sayd yes to the create question.  At present this is hardcoded
>>>>> into bsdinstall as:
>>>>> 	/usr/home
>>>>> 	/home -> /usr/home
>>>>>
>>>>> I am advocating that this should all be controllable from menu.
>>>>>
>>>>>>
>>>>>>> As far as I am concerned the symlink can just die....
>>>>>>
>>>>>> I agree, but that requires a change to pw.  It creates the symlink on the
>>>>>> first account creation using /home.
>>>>>
>>>>> I am missing something here, pw creates the symlink yuk.
>>>>> As far as I was aware the only think that created a symlink
>>>>> /home -> /usr/home was bsdinstall.
>>>>>
>>>>>>
>>>>>>>>> However, if zfs users explicitly configure a home directory under /usr/home,
>>>>>>>>> this would end up in the usr dataset.  An alternative would be to remove the
>>>>>>>>> code from pw to create the parent directory entirely (which seems sensible),
>>>>>>>>> and create a /home directory for ufs installs.  I don't know how well known
>>>>>>>>> it is that adduser/pw will create parent directories for home directories
>>>>>>>>> though.  This cleanup would change the default location for home directories
>>>>>>>>> to /home, which makes more sense.  It would require documentation, e.g. in
>>>>>>>>> the release notes.  The changes would only affect new installations, not
>>>>>>>>> upgrades.
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Adding home would require a change to BSD.root.dist, since it's not
>>>>>>>> currently in there.  Only usr is present.
>>>>>>>
>>>>>>> It should *not* be in the etc/mtree/BSD.*.dist files at all.
>>>>>>> And it is not on my 13.1R system.  It would not need to be
>>>>>>> in BSD.root.dist either, this is a *post distribution* created
>>>>>>> directory/dataset.
>>>>>>
>>>>>> I?m curious why you think this.  But if pw retains the ability to create
>>>>>> the parent directory for the user directory (and I now think it should),
>>>>>> there is no need for a /home by default.
>>>>>
>>>>> Because there is no need for /home in a base distribution until
>>>>> you add a user, and that is a site specific change.  What in
>>>>> the base system *needs* /home?
>>>>>
>>>>>>>> IMHO changing pw would be a reasonable approach.
>>>>>>>
>>>>>>> I am mixed on this.... it more or less does the right
>>>>>>> thing, and if a user specifies /tmp/foolishidea/home/$USER
>>>>>>> that is on them.   No one said all users homes must be
>>>>>>> in the same location.
>>>>>>
>>>>>> Except for moving parent directories with a single component under /usr,
>>>>>> and creating a symlink for them...
>>>>>>
>>>>>> My current plan is to change pw not to move things under /usr, change the
>>>>>> zfs setup to use a home dataset rather than usr/home (corresponding to the
>>>>>> pw default), and then change the various man pages that refer to /usr/home.
>>>>>> Does that seem reasonable?
>>>>>
>>>>> Yes, then the knobs can easily be added, or scripted install should just
>>>>> work to effect the knobs.
>>>>>
>>>>>> 		Mike
>>>>>
>>>>> -- 
>>>>> Rod Grimes                                                 rgrimes@freebsd.org
>>>>
>>>>
>>>
>>> -- 
>>> Rod Grimes                                                 rgrimes@freebsd.org
>>
>>
>
> -- 
> Rod Grimes                                                 rgrimes@freebsd.org