From nobody Fri May 12 15:11:44 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 4QHsg769nCz4B79X; Fri, 12 May 2023 15:11:47 +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 4QHsg73whKz49F0; Fri, 12 May 2023 15:11:47 +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 34CFBj8J042062; Fri, 12 May 2023 10:11:45 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1683904305; bh=LBkS06YnyQ0QJklwhuLjUgsVo2IOIqKuduEl/1qi9i0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=iEGnkv/t09CmXBICZ03wekhxcjyeLgkGk1+dTtxkZTZ0FiSYr6cCU6OAQ4wCFyPuf NPaMttzJYw2cSOmRt+y9ZUTtgNhGZRFuQx4Nn8KXxf5yWkRyVEtKLO3hx+7WOIwg1h so3yDbbOoUZa3mxEwawoYZ3oeuI/h7i0vCsYdLyynSdz3kDBUksEmnTJq/giuajK/y z2ENXF+8jGMYfbv+guVCEsnmdJpBebDFJWHQfRJFyq4pvQ5GqtPtcttHbc5rqeFXMA CeZkB1ojMlSEjptagJAHTd8L06WHifG/0dke5LuPT3wOEbwf629djjAiqlDqGoJ8+6 HTgx3gmA5PR0Q== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id Ty+wFzFXXmRMpAAAs/W3XQ (envelope-from ); Fri, 12 May 2023 10:11:45 -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: Fri, 12 May 2023 10:11:44 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: <07DE4EFF-D9C3-4492-A599-66D72D5DEA8C@karels.net> In-Reply-To: <202305111732.34BHWKdw059416@gndrsh.dnsmgr.net> References: <202305111732.34BHWKdw059416@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: 4QHsg73whKz49F0 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 Rod and I discussed this, and I=E2=80=99m top-posting a summary of a prop= osal that we both support. I=E2=80=99ll 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/hom= e, installing a symlink for /home, and similarly for any other home director= y whose parent has a single component. We propose to remove that code, and= also modify bsdinstall=E2=80=99s zfs script to create a home dataset rath= er than 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=E2=80=99t belong in /usr, and the only reason they= were there is because of the previous root + /usr partitioning. Now the defau= lt is one large partition. Of course, people who want to partition differen= tly 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 elsewher= e. A followup change would be to change various man pages that refer to /usr/home. 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 wrote: >>>> >>>>> On 10 May 2023, at 10:13, Cy Schubert wrote: >>>>> >>>>>> In message , Mit= chell >>>>>> 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=3D36db6b04962a01ff= 7b21592def02d >>>>>>> 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 application= s" >>>>>>>> it should not contain home directories. >>>>>>>>> I do not know when this move to usr came about it was tradition= ally >>>>>>> /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'` i= s: >>>>>>> >>>>>>> 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, crea= te >>>>>>> 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= 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 serv= er. 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 anoth= er >>>>>> 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 moo= ns ago I >>>>>> used the Solaris standard of /export/home, using amd (now automoun= t) 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 sysadmi= n. >>>>>> >>>>>> 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 g= et-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= =2Eg. /home) >>>>> if it does not exist, but if there is no internal slash, pw moves t= he parent >>>>> to /usr. In this case, it makes the symlink from root. zfs is di= fferent, >>>>> in that it includes a usr/home dataset already (created by bsdinsta= ll). > > 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 sep= arate >>>>> 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 dataset= s, in >>>>> the zfs case). >>>>> >>>>> All of this really is a horrible kludge, and it is a house of cards= =2E 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/h= ome. >>> >>> 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= =2E > 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 r= emove the >>>>> code from pw to create the parent directory entirely (which seems s= ensible), >>>>> and create a /home directory for ufs installs. I don't know how we= ll known >>>>> it is that adduser/pw will create parent directories for home direc= tories >>>>> though. This cleanup would change the default location for home di= rectories >>>>> 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 crea= te >> 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 /us= r, >> 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 jus= t > work to effect the knobs. > >> Mike > > -- = > Rod Grimes rgrimes@free= bsd.org