You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/hub/installation/linux.md
+12-1Lines changed: 12 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -78,4 +78,15 @@ To then clean up the temporary install files:
78
78
rm -rf ./certify-agent*
79
79
```
80
80
81
-
By default the agent will install to `/opt/certify-agent` as a systemd service called `certify-agent` running as user `certify` with config stored at `/usr/share/certify`.
81
+
By default the agent will install to `/opt/certify-agent` as a systemd service called `certify-agent` running as user `certify` with config stored at `/usr/share/certify`.
82
+
83
+
84
+
## General Administration
85
+
### Permissions for local Deployment Tasks
86
+
When using a deployment task (such as *Deploy to Apache*) locally on the same machine as the Hub or Agent, the user the process is running as needs permission to write to your destination paths. By default the install script creates the user and group `certify` which has no special permissions initially.
87
+
88
+
So for example, if you have an Apache install at `/etc/apache2` and you wanted to deploy some certs under that path like `/etc/apache2/certs`, you could permission the directory with:
89
+
90
+
`sudo setfacl -m g:certify:rwx /etc/apache2/certs` (`x` is included to allow directory traversal in this case).
91
+
92
+
You can permission destination paths however you prefer, but you should ensure the process user can write to those paths with a test such as `sudo -u certify touch /etc/apache2/certs/test.pem`
0 commit comments