From nobody Wed May 10 21:48:12 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 4QGpYY0sKlz4BSMC; Wed, 10 May 2023 21:48:17 +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 4QGpYX55pYz3P0R; Wed, 10 May 2023 21:48:16 +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 34ALmDqt028430; Wed, 10 May 2023 16:48:13 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1683755294; bh=006RAXHuawOWLd4F9HXLwM2hiMU32gSQO6rhdW/lRSc=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=OXYo+5yM2OzJ8wfPda5yYIvvBRIiCeRYUmx2Adjy32j7VM6+fy64GlmpzuiRDG/Se OD6wFAv2uHwVLnRXdnbbgoViVZ0+7lDo38xDH34m4ooRg0KyhRDx6kWBW8Iue6azNw 0s5fZp1JmZjZw65Mq13FBDh1pSpzAmU1Khh0sxhayvRX1tHJeZxJgTcDb5JwIR7ofo 1GhiNTe2G6+XvzTCiq13nkMy7O1B87cvy0HIS785cnGVjuRRqj8bZqXXvn1iXyA5mB JpiBLfcupTL4s1DFXDxv43sffwbvpyXGvUE5PkOQrF4GmN4P2u2U3rzJX88fTF9qxt HT+bE8YjYO+QQ== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id w0T3Hx0RXGQMbwAAs/W3XQ (envelope-from ); Wed, 10 May 2023 16:48:13 -0500 From: Mike Karels To: Cy Schubert Cc: Mitchell Horne , rgrimes@freebsd.org, 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: Wed, 10 May 2023 16:48:12 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: <4367FD0A-76AC-4E98-A133-E50D8CF841C7@karels.net> In-Reply-To: <20230510151313.9E7A6111@slippy.cwsent.com> References: <202305101419.34AEJf1x054239@gndrsh.dnsmgr.net> <20230510151313.9E7A6111@slippy.cwsent.com> 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: 8bit X-Rspamd-Queue-Id: 4QGpYX55pYz3P0R 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 10 May 2023, at 10:13, Cy Schubert wrote: > In message , 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 >>>> 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 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 >> 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. 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). 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. 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? Mike