Merge branch 'docs/remove-home-nfs' into 'master'

Remove recommending moving the home dir to NFS

See merge request gitlab-org/gitlab-ee!10816

doc/administration/high_availability/nfs.md

@@ -145,7 +145,6 @@ mountpoint
 └── gitlab-data
     ├── builds
     ├── git-data
-    ├── home-git
     ├── shared
     └── uploads
 ```
@@ -158,16 +157,11 @@ configuration to move each data location to a subdirectory:
 
 ```ruby
 git_data_dirs({"default" => { "path" => "/gitlab-nfs/gitlab-data/git-data"} })
-user['home'] = '/gitlab-nfs/gitlab-data/home'
 gitlab_rails['uploads_directory'] = '/gitlab-nfs/gitlab-data/uploads'
 gitlab_rails['shared_path'] = '/gitlab-nfs/gitlab-data/shared'
 gitlab_ci['builds_directory'] = '/gitlab-nfs/gitlab-data/builds'
 ```
 
-To move the `git` home directory, all GitLab services must be stopped. Run
-`gitlab-ctl stop && initctl stop gitlab-runsvdir`. Then continue with the
-reconfigure.
-
 Run `sudo gitlab-ctl reconfigure` to start using the central location. Please
 be aware that if you had existing data you will need to manually copy/rsync it
 to these new locations and then restart GitLab.
@@ -197,14 +191,13 @@ are empty before attempting a restore. Read more about the
 
 ## Multiple NFS mounts
 
-When using default Omnibus configuration you will need to share 5 data locations
+When using default Omnibus configuration you will need to share 4 data locations
 between all GitLab cluster nodes. No other locations should be shared. The
-following are the 5 locations need to be shared:
+following are the 4 locations need to be shared:
 
 | Location | Description | Default configuration |
 | -------- | ----------- | --------------------- |
 | `/var/opt/gitlab/git-data` | Git repository data. This will account for a large portion of your data | `git_data_dirs({"default" => { "path" => "/var/opt/gitlab/git-data"} })`
-| `/var/opt/gitlab/.ssh` | SSH `authorized_keys` file and keys used to import repositories from some other Git services | `user['home'] = '/var/opt/gitlab/'`
 | `/var/opt/gitlab/gitlab-rails/uploads` | User uploaded attachments | `gitlab_rails['uploads_directory'] = '/var/opt/gitlab/gitlab-rails/uploads'`
 | `/var/opt/gitlab/gitlab-rails/shared` | Build artifacts, GitLab Pages, LFS objects, temp files, etc. If you're using LFS this may also account for a large portion of your data | `gitlab_rails['shared_path'] = '/var/opt/gitlab/gitlab-rails/shared'`
 | `/var/opt/gitlab/gitlab-ci/builds` | GitLab CI build traces | `gitlab_ci['builds_directory'] = '/var/opt/gitlab/gitlab-ci/builds'`

doc/administration/high_availability/nfs_host_client_setup.md

 # Configuring NFS for GitLab HA
 
-Setting up NFS for a GitLab HA setup allows all applications nodes in a cluster 
+Setting up NFS for a GitLab HA setup allows all applications nodes in a cluster
 to share the same files and maintain data consistency. Application nodes in an HA
 setup act as clients while the NFS server plays host.
 
 > Note: The instructions provided in this documentation allow for setting a quick
-proof of concept but will leave NFS as potential single point of failure and 
-therefore not recommended for use in production. Explore options such as [Pacemaker 
+proof of concept but will leave NFS as potential single point of failure and
+therefore not recommended for use in production. Explore options such as [Pacemaker
 and Corosync](http://clusterlabs.org/) for highly available NFS in production.
 
 Below are instructions for setting up an application node(client) in an HA cluster
@@ -40,7 +40,7 @@ In this setup we will share the home directory on the host with the client. Edit
 /home <client-ip-address>(rw,sync,no_root_squash,no_subtree_check) <client-2-ip-address>(rw,sync,no_root_squash,no_subtree_check) <client-3-ip-address>(rw,sync,no_root_squash,no_subtree_check)
 ```
 
-Restart the NFS server after making changes to the `exports` file for the changes 
+Restart the NFS server after making changes to the `exports` file for the changes
 to take effect.
 
 ```sh
@@ -57,7 +57,7 @@ inside your HA environment to the NFS server configured above.
 
 ### Step 1 - Install NFS Common on Client
 
-The nfs-common provides NFS functionality without installing server components which 
+The nfs-common provides NFS functionality without installing server components which
 we don't need running on the application nodes.
 
 ```sh
@@ -67,7 +67,7 @@ apt-get install nfs-common
 
 ### Step 2 - Create Mount Points on Client
 
-Create a directroy on the client that we can mount the shared directory from the host. 
+Create a directroy on the client that we can mount the shared directory from the host.
 Please note that if your mount point directory contains any files they will be hidden
 once the remote shares are mounted. An empty/new directory on the client is recommended
 for this purpose.
@@ -86,7 +86,7 @@ df -h
 
 ### Step 3 - Set up Automatic Mounts on Boot
 
-Edit `/etc/fstab` on client as below to mount the remote shares automatically at boot. 
+Edit `/etc/fstab` on client as below to mount the remote shares automatically at boot.
 Note that GitLab requires advisory file locking, which is only supported natively in
 NFS version 4. NFSv3 also supports locking as long as Linux Kernel 2.6.5+ is used.
 We recommend using version 4 and do not specifically test NFSv3.
@@ -108,7 +108,6 @@ git-data.
 
 ```text
 git_data_dirs({"default" => {"path" => "/nfs/home/var/opt/gitlab-data/git-data"}})
-user['home'] = '/nfs/home/var/opt/gitlab-data/home'
 gitlab_rails['uploads_directory'] = '/nfs/home/var/opt/gitlab-data/uploads'
 gitlab_rails['shared_path'] = '/nfs/home/var/opt/gitlab-data/shared'
 gitlab_ci['builds_directory'] = '/nfs/home/var/opt/gitlab-data/builds'
@@ -118,17 +117,17 @@ Save the changes in `gitlab.rb` and run `gitlab-ctl reconfigure`.
 
 ## NFS in a Firewalled Environment
 
-If the traffic between your NFS server and NFS client(s) is subject to port filtering 
-by a firewall, then you will need to reconfigure that firewall to allow NFS communication.  
+If the traffic between your NFS server and NFS client(s) is subject to port filtering
+by a firewall, then you will need to reconfigure that firewall to allow NFS communication.
 
-[This guide from TDLP](http://tldp.org/HOWTO/NFS-HOWTO/security.html#FIREWALLS) 
-covers the basics of using NFS in a firewalled environment. Additionally, we encourage you to 
-search for and review the specific documentation for your OS/distro and your firewall software. 
+[This guide from TDLP](http://tldp.org/HOWTO/NFS-HOWTO/security.html#FIREWALLS)
+covers the basics of using NFS in a firewalled environment. Additionally, we encourage you to
+search for and review the specific documentation for your OS/distro and your firewall software.
 
-Example for Ubuntu:  
+Example for Ubuntu:
 
-Check that NFS traffic from the client is allowed by the firewall on the host by running 
-the command: `sudo ufw status`. If it's being blocked, then you can allow traffic from a specific 
+Check that NFS traffic from the client is allowed by the firewall on the host by running
+the command: `sudo ufw status`. If it's being blocked, then you can allow traffic from a specific
 client with the command below.
 
 ```sh