In order to stop processing on failure to copy certificate
to remote side, fail on error of scp command.
Signed-off-by: Andreas Bießmann <andreas@biessmann.org>
In order to detect errorneous scripts on remote side, catch return code
and handle it respectively.
Signed-off-by: Andreas Bießmann <andreas@biessmann.org>
Reviewed-by: Ross Shen @sjtuross
This set the owner of script to ssh user, have the comment line in script
as real comment and removes policy since this is set from current user,
at least for RouterOS 7.x.
Signed-off-by: Andreas Bießmann <andreas@biessmann.org>
As the script is applying the fullchain which includes three certificates,
delete all of them before applying updated certificate.
Signed-off-by: Andreas Bießmann <andreas@biessmann.org>
Previously the deploy hook config was stored in the account config.
This seems odd and adds unnecessary limitations to the hook.
Now we're using the correct _*deployconf() functions to read and
write the deploy hook config.
This escapes special characters used in POSIX sed to prevent mismatches.
e.g. `SYNO_Certficiate=*.example.com` would not match a description of
"*.example.com" and would look to match any number of double quotes (the
last character in the sed regex prior to certificate description),
followed by any single character, followed by "example", followed by any
character, followed by "com".
After this change, it will properly match `*.example.com` and not
`""zexamplefcom`.
Additionally we now store the certificate description as base64 encoded
to prevent issues with single quotes.
Tested on DSM 7.0-41222 (VDSM) and DSM 6.2.4-25556 (DS1515+).
As noted by @buxm, previous fix didn't work for all versions of DSM 6.
The better fix appears to be simply not outputting the "as_default"
parameter unless we are doing something with the default certificate.
For some DSM installs, it appears that setting the "default" flag to the
string "false" actually sets it to true. This causes Synology to set
the last updated certificate to be the default certificate. Using an
empty string appears to still be accepted as a false-y value for DSMs
where this isn't happening and corrects the behavior in the cases that
it was.
Credit to @Run-King for identifying the fix and @buxm for reporting.
When using vault_cli with a kv2 path, it isn't working. I have the following error:
```
WARNING! The following warnings were returned from Vault:
* Invalid path for a versioned K/V secrets engine. See the API docs for the
appropriate API endpoints to use. If using the Vault CLI, use 'vault kv put'
for this operation.
```
The new way to write data is to use `vault kv put`, it is compatible with kv1 and kv2.
Ref: https://www.vaultproject.io/docs/commands#reading-and-writing-data
```
The original version of K/V used the common read and write operations. A more advanced K/V Version 2 engine was released in Vault 0.10 and introduced the kv get and kv put commands.
```
* fix: unifi deploy hook also update Cloud Key nginx certs
When running on a Unifi Cloud Key device, also deploy to
/etc/ssl/private/cloudkey.{crt,key} and reload nginx. This
makes the new cert available for the Cloud Key management
app running via nginx on port 443 (as well as the port 8443
Unifi Controller app the deploy hook already supported).
Fixes#3326
* Improve settings documentation comments
* Improve Cloud Key pre-flight error messaging
* Fix typo
* Add support for UnifiOS (Cloud Key Gen2)
Since UnifiOS does not use the Java keystore (like a Unifi
Controller or Cloud Key Gen1 deploy), this also reworks
the settings validation and error messaging somewhat.
* PR review fixes
* Detect unsupported Cloud Key java keystore location
* Don't try to restart inactive services
(and remove extra spaces from reload command)
* Clean up error messages and internal variables
* Change to _getdeployconf/_savedeployconf
* Switch from cp to cat to preserve file permissions
Jordan ERNST