Point users to security doc instead. Right now it takes a lot of
explaining to describe to users exactly how to validate the binary and
what the output of the tools used means.
For example, this is the output when validating according to the
instructions in this guide and the linked doc:
```
vagrant@linux:/tmp$ gpg --verify nomad_0.8.7_SHA256SUMS.sig
nomad_0.8.7_SHA256SUMS
gpg: Signature made Fri 11 Jan 2019 09:47:56 PM UTC using RSA key ID
348FFC4C
gpg: Good signature from "HashiCorp Security <security@hashicorp.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 91A6 E7F8 5D05 C656 30BE F189 5185 2D87 348F
FC4C
vagrant@linux:/tmp$ shasum -a 256 -c nomad_0.8.7_SHA256SUMS
shasum: ./nomad_0.8.7_darwin_amd64.zip:
./nomad_0.8.7_darwin_amd64.zip: FAILED open or read
shasum: ./nomad_0.8.7_linux_386.zip: No such file or directory
./nomad_0.8.7_linux_386.zip: FAILED open or read
shasum: ./nomad_0.8.7_linux_amd64-lxc.zip: No such file or directory
./nomad_0.8.7_linux_amd64-lxc.zip: FAILED open or read
./nomad_0.8.7_linux_amd64.zip: OK
shasum: ./nomad_0.8.7_linux_arm64.zip: No such file or directory
./nomad_0.8.7_linux_arm64.zip: FAILED open or read
shasum: ./nomad_0.8.7_linux_arm.zip: No such file or directory
./nomad_0.8.7_linux_arm.zip: FAILED open or read
shasum: ./nomad_0.8.7_windows_386.zip: No such file or directory
./nomad_0.8.7_windows_386.zip: FAILED open or read
shasum: ./nomad_0.8.7_windows_amd64.zip: No such file or directory
./nomad_0.8.7_windows_amd64.zip: FAILED open or read
shasum: WARNING: 7 listed files could not be read
```
There are only two lines that matter in all of that output:
```
...
gpg: Good signature from "HashiCorp Security <security@hashicorp.com>"
...
./nomad_0.8.7_linux_amd64.zip: OK
...
```
I feel like trying to teach users how to use and interpret these tools
in our deployment guide may be as likely to reduce confidence as
increase it.
The systemd configs spread across our repo were fairly out of sync. This
should get them on our best practices.
The deployment guide also had some strange things like running Nomad as
a non-root user. It would be fine for servers but completely breaks
clients. For simplicity I simply removed the non-root user references.
* update formatting and add toJSON function with explanation
* edit typo
* Update website/source/guides/operations/vault-integration/index.html.md
Co-Authored-By: Omar-Khawaja <Omar-Khawaja@users.noreply.github.com>
* fixing clarification bullet explaining the use of toJSON
* Add Nomad RA
* Add deployment guide and nav
* Deployment Guide update
* Minor typo fixes
* Update diagrams
* Fixes for review
* Link fixes and typo fix
* Edits following review
- Update image text from "zone" to "datacenter" to match Nomad terminology
- Clean up text based on Preetha's feedback
* Text updates
Based on feedback from Rob
* Update diagrams
* fixing spelling
* Add suggestions from Preetha and Omar
* add vault integration guide in guides section and move current vault integration content to docs section
* complete guide with image
* fix typos
* rename step 6 and fix typos
* fix typos and awkward phrasing along with links
* fix duplicated step #
* fix typo
* fix links so that pages that pointed to the original vault integration content still point there
