From nobody Sat May 13 20:29:30 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 4QJcgJ3zrVz4BlQp; Sat, 13 May 2023 20:29:32 +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 4QJcgJ21Tdz3vRG; Sat, 13 May 2023 20:29:32 +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 34DKTVnW049084; Sat, 13 May 2023 15:29:31 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1684009771; bh=SGH3BvxU5HRxF8NsaJpGM3JukiKDsJ2EfKreKhbNrbM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=J+DyY1o/keFxnQWITAe0s9+PexjJ2iVCR9w9qnqcSqu/0pH5WZ+sskvpGknrutHhj 5nEzmDiHjLFxvEz8rBOb6J5iZpx+n5KRpbVkTq0UDrSObigwKv86tH4ms6jd32MZWx 95zdMch0rEtgcwP4kP9fzyunCgTYc5h88OKxW2PUyJyLlETBYsk9xVSoPGfORFKGVB mpVrdmeeiGl/6msxd9lPbEizZJnF6rOdxg6DesTo2s2D2VH6c8p+J2G73DIVeZ41RS CpvamCBtpfKUruLwcEiyxRrQRmNFEDSfwi3RFDiaPQdlGtBJ95c03kZ0UsuasaToDY 9xEaxPS893Hzg== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id bBHdBivzX2S6vwAAs/W3XQ (envelope-from ); Sat, 13 May 2023 15:29:31 -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: Sat, 13 May 2023 15:29:30 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: <4DD6D2C9-9F3A-4265-92FA-1B09817634FB@karels.net> In-Reply-To: <202305130043.34D0hAMp065433@gndrsh.dnsmgr.net> References: <202305130043.34D0hAMp065433@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 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4QJcgJ21Tdz3vRG 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 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 direc= tory >> 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 th= an > > 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 t= his >> 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 de= fault >> is one large partition. Of course, people who want to partition diffe= rently >> 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 th= e >> directory, and manually create a /home symlink if desired. If they ha= ve >> a small root file system, they will want to put home directories elsew= here. >> >> 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 >> 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 , M= itchell >>>>>>>> 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=3D36db6b04962a01= ff7b21592def02d >>>>>>>>> 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/D400= 02 >>>>>>>>>>> --- >>>>>>>>>>> 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 applicati= ons" >>>>>>>>>> it should not contain home directories. >>>>>>>>>>> I do not know when this move to usr came about it was traditi= onally >>>>>>>>> /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= =2E >>>>>>>>> >>>>>>>>> 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, cr= eate >>>>>>>>> it under /usr instead, and symlink /basedir -> /usr/basedi= r. >>>>>>>>> >>>>>>>>> Notes: >>>>>>>>> svn path=3D/head/; revision=3D21242 >>>>>>>>> >>>>>>>>> >>>>>>>>> So it has been this way for 26 years at least. I do not know wh= at to say >>>>>>>>> about whether /usr "should" contain it, but it does. >>>>>>>> >>>>>>>> Usually history matters. I can understand not changing it. On th= e 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 se= rver. In >>>>>>>> the Red Hat land at $JOB, /home is its own partition (actually a= n LVM >>>>>>>> volume). In both cases /home is not in /usr because end-users ca= n fill >>>>>>>> /usr. This can be problematic operationally because it's yet ano= ther >>>>>>>> headache to deal with should someone fill the filesystem. Fillin= g /usr is >>>>>>>> more serious than filling /home. >>>>>>>> >>>>>>>> As a point of interest, when I installed my first FreeBSD many m= oons ago I >>>>>>>> used the Solaris standard of /export/home, using amd (now automo= unt) to >>>>>>>> serve my /home. I'm not advocating we do this, it's overkill, bu= t /home >>>>>>>> should not live in /usr. It's a potential headache for any sysad= min. >>>>>>>> >>>>>>>> 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 an= y reviews >>>>> you might creat. >>>>> >>>>>>> The situation is a fair mess. It took me a little while to figur= e out that >>>>>>> the kludge referenced above is in the pw(8) command, which is use= d as the >>>>>>> backend to adduser(8). Neither /home nor /usr/home is in the bas= e 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 bsdins= tall). >>> >>> 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 s= eparate >>>>>>> file systems by default, root was small, and there was no /home b= y default. >>>>>>> However, we now default to a single large file system (with datas= ets, in >>>>>>> the zfs case). >>>>>>> >>>>>>> All of this really is a horrible kludge, and it is a house of car= ds. I'm >>>>>>> amazed that it doesn't break more often. I'm tempted to remove t= he 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 i= s 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 y= ou >>> 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 poin= t? >>>> From all I read the default for pw is already, and should remain /ho= me. >>> Man page bears that out. It has no mention of any symlink or usr/hom= e. >>> >>>> 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 o= n 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 dir= ectories >>>>>>> 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 installatio= ns, not >>>>>>> upgrades. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>> >>>>>> Adding home would require a change to BSD.root.dist, since it's no= t >>>>>> 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 cr= eate >>>> the parent directory for the user directory (and I now think it shou= ld), >>>> 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, chang= e 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 /us= r/home. >>>> Does that seem reasonable? >>> >>> Yes, then the knobs can easily be added, or scripted install should j= ust >>> work to effect the knobs. >>> >>>> Mike >>> >>> -- = >>> Rod Grimes rgrimes@fr= eebsd.org >> >> > > -- = > Rod Grimes rgrimes@free= bsd.org