Never heard of such a thing, just like _martin. I've been using a dedicated file system mounted on /home, and /usr/home doesn't even exist on my machine, and everything works fine. Unix has a long history that a user's home directory can be pretty much anywhere, as long as it is correctly recorded in /etc/passwd, and the $HOME environment variable is set. I've worked on small machines (where user "bob" will have his home directory on /home/bob), and on gigantic machine (clusters) where the home directory of user bob in group f13 of division ec might be /h/ec/f13/bob. Comes down to ease of administration.
Is there any documentation that states that user's home directories need to be in a specific place? "Man hier" doesn't mention it at all. I think FreeBSD by itself doesn't care at all.
On the workstation that contains the pool with the /export/home, should I access it via a symbolic link as Mjölnir suggested or mount it for consistency with the access from other computers?
Good question. Try this argument: Be consistent. Is the machine that exports the home directory primarily a login machine, where users would log in just as usual, and it's a place they can do work just like on the other machines? Then I would say: Put the home directories there in /home, export it from there (there is no rule that exported file systems have to be in /exports), and on the client machines, mount it as /home. Then users can't even tell the difference, and that's good.
On the other hand, if the exporting machine had separate home directories (/export/home is not used on it), then it would make sense for it to have /export/home for things it exports via NFS, and a separate /home for people to get work done locally, I don't think that's what you want.
Regarding the symbolic link, I cannot find the quote anymore, as best as I recall it alleged that such was necessary for UFS and has persisted ever since. But it is now three of you, who claim no issues, so I will not worry about it.
Therefore, I deleted the symbolic link; though I do not understand how can /usr/home not exist; on all my machines it had been created automatically. But, since it does not serve any purpose anymore, I deleted it too.
As an experiment, when I was creating a user, I had pointed his directory to the /export/home/username and it works as expected.
Regarding the symbolic link, I cannot find the quote anymore, as best as I recall it alleged that such was necessary for UFS and has persisted ever since.
As far as I can remember /usr/home was the 'norm' on FreeBSD, most plain installs still set it that way. On Linux it was more common to use /home. That's the reason why a symlink from /home to /usr/home was made. But essentially, it doesn't really matter as long as the home directory entries of a user account is correct. Although you might find some braindead code in the wild that assumes it's /home.
At work we manage around 800+ Linux servers and have NFS home directories for system admins, application hosting and developers (no real 'users', they don't get anywhere near a login on an actual machine). Home directories are exported from /exports/rhome and mounted on client machines on /rhome using autofs(5) (the Linux equivalent, it's the same thing). As long as directory services sets the home directory correctly when creating accounts things just work out.
Not if you explicitly created /home and it is a separate filesystem.
On my systems I use ZFS and boot environments. As /usr is under a bootenv (changes with the boot env), having /usr/home as physical location of home is really not desired.
My setup is (shortened for brevity):
If you change the location (or pick something non-standard) it's a good idea to run adduser -C, then you can set the default location of the home directory for new users.
Not if you explicitly created /home and it is a separate filesystem.
On my systems I use ZFS and boot environments. As /usr is under a bootenv (changes with the boot env), having /usr/home as physical location of home is really not desired.
My setup is (shortened for brevity):
To avoid confusing newbies, you should include or weave in zfs get -rt filesystem canmount in that listing.
IMHO /usr & /var should not be inside pool/ROOT/xyz, since /usr only provides a mountpoint for it's children /usr/{home,ports,src}, which can be shared by all boot environments. Those who run different versions e.g. release & stable will know how to adjust properly, and the children of /var should be shared by all BEs anyway; whereas I like the idea to put /usr/local on a separate dataset under pool/ROOT/xyz. I have to add this only holds true for non-concurrent BEs; if you run BEs concurrently via bhyve(8) or another VM manager, your setup is an appropriate method to separate the machine's filesystems. Additionally, I put all shared port's entries under /var into their own dataset to separate them from the root pool/ROOT/xyz, so they can be shared among all BEs. Care has to be taken, because some directories & files under /var can not be shared, but should be either in each BE's root / (default), or in their own dataset under pool/ROOT/xyz/var.
The installer's default ZFS setup can be looked up easily: whereis bsdinstall, so fgrep -iA 30 -m 1 'Default ZFS datasets' /usr/src/usr.sbin/bsdinstall/scripts/zfsboot
# Default ZFS datasets for root zpool
#
# NOTE: Requires /tmp, /var/tmp, /$ZFSBOOT_BOOTFS_NAME/$ZFSBOOT_BOOTFS_NAME
# NOTE: Anything after pound/hash character [#] is ignored as a comment.
#
f_isset ZFSBOOT_DATASETS || ZFSBOOT_DATASETS="
# DATASET OPTIONS (comma or space separated; or both)
Yes. I made the symlink /usr/home -> ../home/ only to be sure that misbehaving scripts or apps work well. Although it might be more reasonable to not cover that, but let them fail & file in a bug report, should that happen.
I disagree about the BE layout. I really don't want to share {ports,src} with other boot environments. Same goes with the /usr/obj and /var as ports files, among others, reside there. Many times even minor jump (e.g. 12.1->12.2) requires building ports again (virtualbox is a good example). Boot environment in my setup provides the isolation I'm used to from Solaris.
I will add that I'm not claiming my way is the best way but for sure I was happy I set it the way I did when I hit bugs and issues during updates/upgrades.
I agree on /usr/src, since it should hold that specific version's source tree. I put that in it's own datasets anyway (/src/{12.2-REL,{12,13}-STABLE,14-CURRENT}) and mount_unionfs(8) below /usr/src (which itself resides on the rootfs /).
/usr/obj is on the rootfs by default; since it should really be /var/obj, I changed that. Of couse it is tied to the /usr/src tree, so it doesn't have it's own dataset, but is on the rootfs. It can have a shared dataset, if one builds from a user account with source trees named like above, union-mounted into the user's $home.
most of /var is on the rootfs by default; but you can and should share /var/log, /var/mail and such (see the default setup) among all BEs, and all data files & directories under /var, that can be shared. E.g. a network monitor logs network traffic into /var/db/ntopng. This can be shared by all BEs, and no traffic gets lost, no matter which BE runs. You see the same data in all BEs. That's what I meant. I.e. pool/var/db serves to provide a mountpoint, but has canmount=off; thus many files and directories are on the rootfs, but those that can be shared have their own dataset.
/usr/ports is the same for all versions, as long you stick to either quarterly or latest. I put both in pool/ports/{latest,quarterly} and union-mount below /usr/ports, so I can have a BE_1 seeing quarterly, and another BE_2 seeing latestports(7).
If you have plenty of diskspace and don't mind duplicated or "lost" data & wasted space, it's of course reasonable to decide to KISS and have the setup like you showed above. But IMHO splitting off shared data from the pool/ROOT/* does not make maintenance more complex, and the work to set it up is only done once. The "disadvantage" is a minor flaw: I have plenty of zfs(8) datasets. I don't mind, that's exactly what zfs(8) was designed for.
Good question. Try this argument: Be consistent. Is the machine that exports the home directory primarily a login machine, where users would log in just as usual, and it's a place they can do work just like on the other machines? Then I would say: Put the home directories there in /home, export it from there (there is no rule that exported file systems have to be in /exports), and on the client machines, mount it as /home. Then users can't even tell the difference, and that's good.
Regarding the boot environment (BE), I had read a lot about it, and the conclusion that I arrived at was, that there is not one "best" organization, it does depend on person's intended use. Since I am an unsophisticated user and use the BE only for preventing disasters, I have a mix between yours. That is I share come of the /var directories /var/log, /var/mail, /var/crash as well as /usr/ports for the reason Mjölnir enumerated, as well as some others.
On a different note, after I bothered all of you with the all the questions, I am now starting to doubt the whole concept. My main goal was to share the data. However, I forgot that the user's home also has a lot of configuration settings. So, I am not sure whether/how it works, since the environments are different, e.g., server vs workstation.
Not all has been in vain though, as I have learnt a lot.
On a different note, after I bothered all of you with the all the questions, I am now starting to doubt the whole concept. My main goal was to share the data. However, I forgot that the user's home also has a lot of configuration settings. So, I am not sure whether/how it works, since the environments are different, e.g., server vs workstation.
As already noted above, you can use the variables described in auto_master(5) (OSNAME, OSREL,...) to cope with that. IIRC there are some examples in the manpage or somewhere in /etc/autofs and/or /usr/share/examples? Of course you can combine that with mount_unionfs(8) or nullfs(5). I.e. a Mac sees other config files as a FreeBSD system, but they both share the same data otherwise (through a unionfs), like your .pdf docs etc..
Mjölnir This would be a nice beer debate about the zpool setup. But as it's not what OP asked I leave it be.
mefizto Well, that's what I told you in the beginning - shared home is probably not worth it. But you can still use NFS and automounter to mount your data across clients. Do you have installation medias ? You could create tank/depot, mount it on server to /export/depot, export it and let all the clients mount it. For this purpose automounter is really a nice feature. Do you have your projects you work on? Create tank/projects and export it to other clients. And so on ..
You can also commit on a common convention to organize user's data (~/Desktop, ~/Documents, ~/Music, ~/Videos, ~/Movies, ...) and export & import all these for each user. Then everything else (mainly: config files) is local on each client, but that other data is common on all clients. This is probably the easiest setup.
I think your suggestions are the direction I will take as it is clear from the discussion to be a better arrangement. My current understanding is that I do not need to export the entire storage pool but only a data-set, e.g.,storage/design. If I will confirm it by experiment that would (partially) achive my objective.
The second part of the objective is to prevent inadvertent storage of shared data into the users' /home. Perhaps there is a way to achieve it by setting permissions on the /home, something like mounting a drive containing OS read only and remount it read/write only for maintenance.
No. RTFM the Handbook etc. or peek above into the spoiler of ZFS default setup: pool/usr has canmount=off, it serves to provide a mountpoint base for it's children. /usr/{{,s}bin,share} are not child datasets of /usr. Thus, they live on the root filesystem.
No. RTFM the Handbook etc. or peek above into the spoiler of ZFS default setup: pool/usr has canmount=off, it serves to provide a mountpoint base for it's children. /usr/{{,s}bin,share} are not child datasets of /usr. Thus, they live on the root filesystem.
You're right, of course . Sorry for this little misunderstanding.
You meant to say, of course, that "it provides a mountpoint only for its (ZFS) children (such and such)". Much depends on where you put the word "only" in your sentence LOL. Because the term "children" also applies to its own subdirectories, in a broader sense.
Correct would be to say: since pool/usr's property canmount=off, it serves only to bequeath ZFS properties to it's child datasets (which can be overridden); it's a hollow dataset. /usr/{{,s}bin,share} are ordinary directories & not ZFS datasets, thus this does not apply to them.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
But as it's not what OP asked I leave it be. 