From nobody Thu May 11 16:57:59 2023 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QHJ494wcKz49TJd; Thu, 11 May 2023 16:58:01 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QHJ49361Dz3FTP; Thu, 11 May 2023 16:58:01 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 34BGw0V4036344; Thu, 11 May 2023 11:58:00 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1683824280; bh=hitU77WqNNGS4LW6BJ+/ZgO+D2fCFEg+odIZWpa8dWU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=N5k0gneRas5fX09SPyt5eyZFSMFVc5uzfC053kp7s/JZktfe7VvTLse1mQlwlqcRG 0zn2dv/bof7ZoEcpcZhqkf435e+cXuwF208SWhiIU42ktiDSwrN+RYWWjg38r+4fUG vRLabZpmAe9uWdQnA36pgO9SgSF+hthD1GugZaa1GDrH6tla/a4JvPcKCjB7wAv0LV 3RmFd04KOlCuZCSg61pfsl/hmalhY+Dlef15un1Y+wL1t2cY/ATm7+QFPFIzaol2ae V82azLJZHpXKZ9HvJi0x2drv0KIElI2B66G6PCm0jO3+9VavUTZijxs3oIK0mAo9Ne uJC6kUmIn1azA== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id /MtvDJgeXWT2jQAAs/W3XQ (envelope-from ); Thu, 11 May 2023 11:58:00 -0500 From: Mike Karels To: rgrimes@freebsd.org Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 36db6b04962a - main - hier(7): document /home/ and /usr/home/ Date: Thu, 11 May 2023 11:57:59 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: <20A9CE7A-0859-4581-8445-60456B1A497B@karels.net> In-Reply-To: <202305111458.34BEwQR9058840@gndrsh.dnsmgr.net> References: <202305111458.34BEwQR9058840@gndrsh.dnsmgr.net> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4QHJ49361Dz3FTP X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 11 May 2023, at 9:58, Rodney W. Grimes wrote: >> On Wed, 10 May 2023 16:48:12 -0500 >> Mike Karels wrote: >> >>> On 10 May 2023, at 10:13, Cy Schubert wrote: >>> >>>> In message , Mitch= ell >>>> 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=3D36db6b04962a01ff7b= 21592def02d >>>>> 4c570dac939 >>>>>>> >>>>>>> commit 36db6b04962a01ff7b21592def02d4c570dac939 >>>>>>> Author: Mitchell Horne >>>>>>> AuthorDate: 2023-05-10 12:53:56 +0000 >>>>>>> Commit: Mitchell Horne >>>>>>> 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 traditional= ly >>>>> /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 >>>>> 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=3D/head/; revision=3D21242 >>>>> >>>>> >>>>> So it has been this way for 26 years at least. I do not know what t= o say >>>>> about whether /usr "should" contain it, but it does. >>>> >>>> Usually history matters. I can understand not changing it. On the fl= ip >>>> side, I cut my UNIX teeth on SunOS 4 and Solaris where /home was /ho= me -- >>>> albeit automounted from /export/home on localhost or some NFS server= =2E In >>>> the Red Hat land at $JOB, /home is its own partition (actually an LV= M >>>> volume). In both cases /home is not in /usr because end-users can fi= ll >>>> /usr. This can be problematic operationally because it's yet another= >>>> headache to deal with should someone fill the filesystem. Filling /u= sr 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 /h= ome >>>> 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 lo= t 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 re= views > you might creat. > >>> The situation is a fair mess. It took me a little while to figure ou= t 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 pa= ckage. >>> adduser defaults to /home/user, and creates the parent directory (e.g= =2E /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 diff= erent, >>> in that it includes a usr/home dataset already (created by bsdinstall= ). >>> In this case, creating a user with /home/user causes the symlink to b= e added >>> as a side effect. >>> >>> I?m sure the kludge was originally done when root and /usr were separ= ate >>> file systems by default, root was small, and there was no /home by de= fault. >>> 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 k= ludge >>> and change the zfs setup to create a home dataset rather than usr/hom= e. > > 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. > "User home location: /home" (This is default) Are you proposing that the default for pw should be set at this point? That doesn=E2=80=99t seem necessary, and I don=E2=80=99t know if it would= work from bsdinstall. > 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. >>> However, if zfs users explicitly configure a home directory under /us= r/home, >>> this would end up in the usr dataset. An alternative would be to rem= ove the >>> code from pw to create the parent directory entirely (which seems sen= sible), >>> 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 directo= ries >>> though. This cleanup would change the default location for home dire= ctories >>> 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=E2=80=99m 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. >> 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 th= e pw default), and then change the various man pages that refer to /usr/hom= e. Does that seem reasonable? Mike