Solved Is it possible to create Solaris-like /home /export/home structure?

M

mefizto

Greetings all,

my current computer comprises a (smallish) SSD, containing the OS and applications, and a separate hard-drives organized into a storage pool. Both zfs. I would like to have an /export/home structure on the storage pool, which would store the data, and mount it on a /home on the SSD. Is there a way to achieve this, and at the same time prevent any data to be created/stored at the /home?

Kindest regards,

M
 
mefizto said:
I would like to have an /export/home structure on the storage pool, which would store the data, and mount it on a /home on the SSD. Is there a way to achieve this, and at the same time prevent any data to be created/stored at the /home?
Click to expand...
Easiest way to do this is with nullfs(5).
Code: 
/export/home /usr/home nullfs rw 0 0
Note I'm using /usr/home here. On FreeBSD /home is commonly a symlink to /usr/home where home traditionally lives.
 
Hi SirDice,

thank you for the response. I am not sure how to interpret your answer, so perhaps I have not been clear in my explanation or, I am not understanding correctly.

I had just re-installed the FreeBSD on the SSD under system. I intend to create the /home here:
Code: 
# zfs create -o mountpoint=/home system/home
I had also created a zfs pool storage. I would like to create the /export/home/usr here, but not mount it:
Code: 
zfs create -o mountpoint=none storage/export/home

As I understand Solaris has an auto-mounter, that detects when a user logs in on any of the user's computers and mounts the /export/home/usr to the /home on that computer. Since FreeBSD does not have like utility, I was mounting the /export/home/usr manually. The problem was, that sometimes I forgot, and created files in /system/home and next time when I did remember, I was surprised that my thusly created files were not there.

Kindest regards,

M
 
And why not simply adjust the symlink instead? rm /home && ln -s export/home /home Note the target has not leading slash /, so when you put that SSD in another system, usually with altroot set (see zpool(8)), the link will not point to the new host's /export/home. Usually that's what you want. Since it's a symlink, you can easily point it anywhere when it's needed.
 
you can set mountpoint=/export/home (it's children will inherit that as base) and canmout=noauto and use the FreeBSD automounter.
 
I have my home directories in export because I am generally using NFS to share them between multiple computers. Isn't that primarily what /export is for?

Come to think of it, now I am not sure why Solaris did put home there, especially for local accounts.
 
That was pre-ZFS era, when you couldn't NFS-export via ZFS properties. mefizto, are you sure you want two /home structures, one on the base system's zpool & another one on the storage zpool? Why? And if you don't have plenty of user's, automounting is just one more level of complexity, that might do more harm than good. You can do that, the automounter doesn't detect login, but when a path is accessed, the path is automounted. But why? Where's the benefit?
 
mefizto said:
As I understand Solaris has an auto-mounter, that detects when a user logs in on any of the user's computers and mounts the /export/home/usr to the /home on that computer.
Click to expand...
This is typically done with NFS home directories. Not with local file systems. That said, you can use the same nullfs(5) trick, you're going to need to mount /exports/home because you need a filesystem to mount. It either needs to be NFS exported or through a local nullfs(5) mount. But it's going to need to be mounted either way.

mefizto said:
Since FreeBSD does not have like utility
Click to expand...
It has something similar, called autofs(5)/automount(8). You typically let it automount /usr/home/<username> from a central NFS storage server. autofs(5) can, simply put, automatically mount something if you try to access the directory. Which could be triggered by a user logging in and accessing their home directory for example.
 
Hi Mjölnir,

thank you for your response. It seems that I am still not explaining the motivation correctly. The purpose of the /export/home being on a pool separate from the system is several-fold. First, the data is protected by the pool redundancy; second, the data is in a central location, and third, it will simplify the backup. Let us say that I will work from a diffent location and computer_2 from where the computer_1 is located. I can use the computer_2 and be assured that I am accessing the centrally located /home.

That is, I can share the FILE]/export/home[/FILE] among a plurality of computers as kpedersen suggested.

I definitely do not want two /home structures, that was the problem with my previous setup as (in-artfully) explained.

Hi kpedersen,

thank you for your response. Yours is exactly the scenario I am envisioning. Can you please share details of your setup?

From what I understand (perhaps incorrectly) is that the /home is a mount-point for the /export/home.

Hi SirDice.

thank you for your response. Perhaps it is my lack of understanding for being unable to follow your reasoning. Are you saying that the /export/home is mounted somewhere (on the pool?) and is being remounted to either a local system or remote computer?

Kindest regards,

M
 
mefizto said:
Are you saying that the /export/home is mounted somewhere (on the pool?) and is being remounted to either a local system or remote computer?
Click to expand...
Exactly. It's mounted locally under /export/home on a sever. Automounter has the map defined for /home and acts upon it. If the server and client are the same there's a possibility for some optimization (local mount). Backbone protocol for this is NFS.
Personally I never liked this on Solaris. It made sense in certain environments possibly with the help of NIS but for home use I opt for having shared data directory (central server keeps data and exports it to clients, users are defined per client bases).
 
Hi _martin,

thank you for your answer. Again, that is what I want to achieve - share a centrally located data.

However, I am more and more confused. For example, why is it a problem, whether the data is located at a computer that can also use it? Also, if the centrally located data is exported to clients as you have suggested, how else to do it, but via a sharing protocol (NFS, CIFS)?

I am in no way married to my proposed scheme, in fact it was the problem with it that prompt me to ask for a better scenario.

So, if you can suggest a better way, I would be grateful.

Kindest regards,

M
 
Your initial question was about the /home and to achieve what Solaris does on FreeBSD server. FreeBSD is capable of that. To sum up what others already said:
a) mount ZFS fileset on a server, /export/home/ seems like a reasonable location
b) enable automount(8) and set the indirect home map in auto_master(5)
c) export fileset to clients

It all depends on your environment, clients and the actual setup. Shared home works nicely on corporate networks with homogenous setup because users are usually alike and clients (computers in this sense) do the alike job. This does ease the administration.

Are your clients all the same? Will you mix maybe Linux/BSD clients ? Even simple shell profile customization can turn into pain if you start mixing clients. What happens when server is not reachable, etc..

That's why I prefer, in home usage, to have local users only. Shared data is mounted via NFS mostly. Windows clients do have samba available (with small overhead and help of nullfs). Linux clients use autofs with direct maps to mount these dirs.

You can set the directory hierarchy as you like and see fit.
 
The automounter knows about some variables that can be used in the map to deal with the issues mentioned by _martin. The question is if you want to invest the time & efforts to do that in a 3 laptop 4 person SOHO network.
 
Hi _martin,

thank you again for your reply.

You are, of course, correct in what was my initial thought, because the main problem with my previous set-up was the possibility to create data in /home, when the /export/home was not mounted, which, I thought would be corrected by a Solaris-like automounter.

The motivation for central accessible data (/home is dues to the fact that my clients are not all the same. My backup server, the mentioned workstation and laptop use FreeBSD, but I need a Windows machine, because many engineering applications (MathCAD, LTSpice, Solidworks), have no counterparts. Consequently, I had a different files at different machines and administering them (for backup and some sharing - photos, was a nightmare.

Based on the foregoing, there are two themes (1) centralized storage and (2) prevention of creating data outside of the centralized storage (the later perhaps not being achievable for the laptop when on travel).

Thus, what is the problem with the proposal of having the /export/home for the shared data on the workstation and export it via NFS to the laptop and via samba to the Windows machine? In that regard, what is the purpose of the "small overhead and help of nullfs" that you referred to? I can mount a data-set on Windows machine?

Hi Mjölnir,

as already noted several times, I am not wedded to my scheme. But, yes, I want to have a centralized storage for the reason explained in the response to _martin.

Kindest regards,

M
 
When the command adduser(8) is run, it asks which home directory you want it to be in. It is capable of creating the directory /export/home/chosenname/. If you already have that directory made or username made, you may not want to use this.

You can also manually create a directory to be mounted, then mount it on the device and partition you want through fstab(5).

/home is a symbolic link to /usr/home. You can change this to be a symbolic link to /export/home, by carefully deleting the link and creating a new one, if that's what you want to do.
 
Ok, quick example. As I do have /home already I'll set /users to be the shared home. Prep the FS:
Code: 
zfs create -o mountpoint=/export/users rpool/users
zfs sharenfs='-alldirs -network 192.0.2.0/24' rpool/users
Set the autofs:
Code: 
# grep -vE '^$|^#' /etc/auto_master
/users     auto_users    -nobrowse
#

# grep -vE '^$|^#' /etc/auto_users
*    fbsd12:/export/users/&
#

Make sure /etc/rc.conf is set:
Code: 
nfs_server_enable="YES"
autofs_enable=YES

Start the daemons:
Code: 
# /etc/rc.d/nfsd start
# /etc/rc.d/automountd start

Verify NFS is exporting:
Code: 
# showmount -e
Exports list on localhost:
/export/users                      192.0.2.0
#

Create user. I don't remember how Solaris did this, I'm using kinda workaround here when creating user:
Code: 
pw user add martin -s /bin/csh -m -d /export/users/martin
pw user mod martin -d /users/martin

Using client to login:
Code: 
(client)$ ssh martin@fbsd12
martin@fbsd12:~ $ pwd
/users/martin
martin@fbsd12:~ $
 
Hi sidetone,

I appreciate your attempt to help. Maybe I have not been clear, but I do understand how to create the required structures. I just was unsure how to manage them to avoid the problem that I was describing. So, I am not certain, how your post helps. Can you please clarify?

Hi _martin,

thank you very much for the example. This will work for the clients accessing the shared data via NFS.

If you still have the patience, can you explain what I asked in the previous post, i.e., the reason for using mullfs for the Windows clients?

Kindest regards,

M
 
As I mentioned, all my users are local users and no user has anything in profile that would source something from remote location.

For my Windows clients I'm using samba that's set in jail. Example of such share in smb4.conf
Code: 
[cloud]
    comment = cloud
    path = /smb/martin/cloud
    read only = no
    public = no
    valid users = martin
Now jail got this share from server using nullfs mount where /storage/on/server/cloud is the actual ZFS fileset:
Code: 
/storage/on/server/cloud    /path/to/jail/and/smb/martin/cloud    nullfs    0 0
nullfs is used here to mount the fileset into different location(s). It is also mounted elsewhere used for other purposes. You can use one fileset and mount it to different locations.
 
mefizto said:
thank you for your response. Yours is exactly the scenario I am envisioning. Can you please share details of your setup?
Click to expand...
Possibly much of it (i.e setting up the NFS server itself) is best explained here in the NFS section of the handbook:
https://docs.freebsd.org/en/books/handbook/network-servers/#network-nfs

The handbook also uses /home as an example of a directory to export.

And then as you create a user, just set the home directory to be in the mounted /exports/home.
If you already have a user home on the NFS server, I find it easier to just use the same ID for the user on other machines as you add the new user (no need to copy across the skel files a second time) rather than attempt mapping user ids.
 
Greetings all,

I have few more questions.

On FreeBSD /home is a symbolic link to /usr/home. I have read that some applications rely on such convention. Should I thus not adhere to this convention and mount the FILE]/export/home[/FILE] under /usr/home/?

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?

Kindest regards,

M
 
I don't use symlink for /home and didn't use it for many years (15+). I'm not aware of any application that would require this either (why even?). Historically it made sense why it is as such (the same way why there is /usr/bin and /bin.
Let's say it's matter of personal preference. In some very special cases necessity.
 
I have /home beeing a zfs(8) dataset, deleted the symlink in the root / filesystem, but added ln -s ../home/ /usr/home (note the trailing / @../home/). No issues whatsoever. This ought to be a safe setup. freebsd-update(8) did never complain about that setup.
 
You must log in or register to reply here.
Back
Top