Citrix Linux VDA Centralized Home Directories – Part 1: Guest Blog Post by Brian Macbeth
Over the last several years, I’ve had the honor of working with a talented and focused engineer named Brian Macbeth. Brian has spent a bit of time working with Citrix’s new Linux VDA technology and has run into a number of limitations in the area of roaming profiles and home directories, that he has resolved using the processes described below. Brian has graciously volunteered to share his experiences with the extended virtualization community in an attempt to further advance the use of Linux VDA in enterprise organizations. Without further ado, below is the guest blog post by Brian Macbeth, feel free to comment below!
If you are deploying shared Linux desktops or published applications with XenApp or XenDesktop, you may have a need to implement centralized home directories to improve the user experience. Until such a time if, or when, Citrix adds profile management functionality into the Linux VDA client, NFS can bridge the centralized home directory gap.
A Linux-based NFS server, such as CentOS, used in this example will service home directories just fine. Save some frustration and forego any attempts to centralize Linux home directories off a SMB/CIFS share or with a Windows NFS server. When using SMB you lose the ability to change file and folder permissions within home directories and when using a Windows NFS server, some issues with Firefox and bash shell configuration files were experienced.
This post is broken up into two parts:
It is assumed the NFS server is domain joined and the VM is provisioned with reliable storage.
If you require iSCSI storage outside of the hypervisor environment, see part 2 for information on configuring a Linux software iSCSI initiator.
Install NFS Package
yum -y install nfs-utils
Configure NFS Related Services
systemctl enable rpcbind
systemctl enable nfs-server
systemctl enable nfs-lock
systemctl enable nfs-idmap
systemctl start rpcbind
systemctl start nfs-server
systemctl start nfs-lock
systemctl start nfs-idmap
Update the firewall configuration to allow clients to access the NFS export:
firewall-cmd –permanent –add-port=111/tcp
firewall-cmd –permanent –add-port=54302/tcp
firewall-cmd –permanent –add-port=20048/tcp
firewall-cmd –permanent –add-port=2049/tcp
firewall-cmd –permanent –add-port=46666/tcp
firewall-cmd –permanent –add-port=42955/tcp
firewall-cmd –permanent –add-port=875/tcp
Create a Shared Folder
Run the following commands to create a folder that will be shared, or “exported” in the Linux world. We are purposely modifying the folder permissions so that everyone can read, write, and execute from the folder. As new user home folders are created within this shared folder, those folders will be automatically secured to only allow the owning user to read, write, and execute.
chmod 777 /nfshome
Export (Share) the nfshome Folder
Edit /etc/exports with your editor of choice and add the following line:
The above export configuration broken down:
|/nfshome||The folder that will be shared/exported|
|10.1.10.0/24||The subnet clients reside in. If you have clients coming from multiple subnets, your export configuration would be:
directory IP_range (options) IP_range (options)
|rw||The folder is exported as read and writable|
|sync||Sync requires that data is committed to storage before responding to clients|
|no_root_squash||Requests from root on the client will be allowed.
NOTE: If no_root_squash is not enabled, home folders will not be properly created due to root’s involvement in home folder creation.
|no_all_squash||Client user ids will not be mapped to an anonymous uid/gid and instead use domain-based uids/gids|
Restart the nfs service:
systemctl restart nfs-server
NFS Client Configuration
It is assumed the NFS client machine is already joined to the domain.
Install NFS Package
yum -y install nfs-utils
If selinux is enabled in your configuration, run the following command to allow NFS home directory functionality and restart the machine:
setsebool -P use_nfs_home_dirs 1
shutdown -r 0
Configure NFS Mount
This example assumes:
- A domain user has already logged on to the machine and the /home/<DOMAIN> folder has been created.
- The exported NFS directory is nfshome and the home directory path is /home/DEMO.
Edit /etc/fstab with your editor of choice and add the following to the end of the file:
nfsserver.fqdn:/nfshome /home/DEMO nfs4 _netdev,vers=4.0,rw,soft,timeo=300,retrans=2,local_lock=none 0 0
The above fstab mount configuration broken down:
|nfsserver.fqdn:/nfshome||NFS server and exported folder path|
|/home/DEMO||Client path the share is mounted to|
|nfs4||Use NFS4 protocol|
|_netdev||Wait for the network stack to be enabled before attempting to mount|
|vers=4.0||NFS version 4|
|rw||Mount as read and write|
|soft||Soft recovery specifies the NFS client will fail after retrans retransmissions have been sent|
|timeo=300||Time the client will wait (1/10 sec) before a retransmission will be sent|
|retrans=2||Number of retries before recovery action|
|local_lock=none||Do not use local locks|
Run the following command to mount the NFS export to /home/<DOMAIN>:
Note: if you experience mount problems, run mount -a -v to see what is happening and review /var/log/messages for any errors.
Run the following command to validate that /home/<DOMAN> is mounted to the NFS export:
Log in as a domain user and validate the following:
- Successful login
- Run df -h to validate the /home/<DOMAIN> is mounted to the NFS share
- cd to /home/<DOMAIN> and run ls -asl and validate that the user’s home directory permissions are secured so that only the user has access to their own folder:
drwx——. 14 DOMAIN\username DOMAIN\domain users
High Availability NFS Services
The NFS server in this example is a stand-alone server which can pose availability issues. Should you have a requirement to implement a high availability NFS home directory solution using Linux clustering, see part 2.