[Notes] [Git][BuildStream/buildstream][jennis/patch_remote_cache_docs] docs: Add helpful notes to artifact server configuration instructions

[James Ennis <gitlab mg gitlab com>]

Title: GitLab

James Ennis pushed to branch jennis/patch_remote_cache_docs at BuildStream / buildstream

Commits:

• b590adf9
  by James Ennis at 2018-10-25T11:57:29Z

  docs: Add helpful notes to artifact server configuration instructions
  
  Also corrected a typo which was referring to bst pull instead of push,
  and fixed the link
  

1 changed file:

• doc/source/using_configuring_artifact_server.rst

Changes:

doc/source/using_configuring_artifact_server.rst

---

...	...	@@ -40,7 +40,7 @@ them in a specific order:
40	40
41	41	When an artifact is built locally, BuildStream will try to push it to all the
42	42	caches which have the ``push: true`` flag set. You can also manually push
43		-artifacts to a specific cache using the :ref:`bst pull command <commands>`.
	43	+artifacts to a specific cache using the :ref:`bst push command <invoking_push>`.
44	44
45	45	Artifacts are identified using the element's :ref:`cache key <cachekeys>` so
46	46	the builds provided by a cache should be interchangable with those provided
...	...	@@ -110,6 +110,13 @@ You can also use a key pair obtained from a trusted certificate authority instea
110	110
111	111	openssl req -new -newkey rsa:4096 -x509 -sha256 -days 3650 -nodes -batch -subj "/CN=artifacts.com" -out server.crt -keyout server.key
112	112
	113	+.. note::
	114	+
	115	+ Note that the ``-subj "/CN=<foo>"`` argument (``/CN`` is the *common name*) should be the public hostname of the server. IP addresses will **not** provide you with
	116	+ working authentication.
	117	+
	118	+ In addition to this, ensure that the host server is recognised by the client. You may need to add the line: ``<ip address>`` ``<hostname>`` to
	119	+ your ``/etc/hosts`` file.
113	120
114	121	Authenticating users
115	122	~~~~~~~~~~~~~~~~~~~~
...	...	@@ -186,7 +193,7 @@ Below are two examples of how to run the cache server as a systemd service, one
186	193
187	194	Here we define when systemd should start the service, which is after the networking stack has been started, we then define how to run the cache with the desired configuration, under the artifacts user. The {{ }} are there to denote where you should change these files to point to your desired locations.
188	195
189		-For more information on systemd services see:
	196	+For more information on systemd services see:
190	197	`Creating Systemd Service Files <https://www.devdungeon.com/content/creating-systemd-service-files>`_.
191	198
192	199	User configuration
...	...	@@ -233,3 +240,7 @@ Pull and push:
233	240	client-cert: client.crt
234	241
235	242	push: true
	243	+
	244	+.. note::
	245	+
	246	+ Equivalent statements can be delcared in a project's configuration file (the ``project.conf``).

—
View it on GitLab.
You're receiving this email because of your account on gitlab.com. If you'd like to receive fewer emails, you can adjust your notification settings.