Project

General

Profile

Actions

Bug #18785

closed

[installer] single host/single hostname installer broken with let's encrypt enabled

Added by Ward Vandewege almost 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Target version:
Start date:
02/28/2022
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
-
Release relationship:
Auto

Description

On the 2.3-release branch, tip (d09550506dbd31b92e53b4e861924e49027acabb), when configuring a single host single hostname with Let's Encrypt enabled:

Setting up salt-minion (3004+ds-1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/salt-minion.service → /lib/systemd/system/salt-minion.service.
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for libc-bin (2.31-13+deb11u2) ...
 *  INFO: Salt installed!
Synchronizing state of salt-minion.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable salt-minion
Removed /etc/systemd/system/multi-user.target.wants/salt-minion.service.
Cloning formulas
Writing pillars and states
sed: can't read /srv/pillars/nginx_download_configuration.sls: No such file or directory
sed: can't read /srv/pillars/nginx_collections_configuration.sls: No such file or directory
[ERROR   ] Specified SLS 'aws_credentials' in environment 'base' is not available on the salt master
[ERROR   ] Template was specified incorrectly: False
[ERROR   ] Specified SLS 'letsencrypt' in environment 'base' is not available on the salt master
[ERROR   ] Template was specified incorrectly: False
[CRITICAL] Pillar render error: Specified SLS 'aws_credentials' in environment 'base' is not available on the salt master
[CRITICAL] Pillar render error: Specified SLS 'letsencrypt' in environment 'base' is not available on the salt master
[INFO    ] Loading fresh modules for state activity
local:
    Data failed to compile:
----------
    Pillar failed to render with the following messages:
----------
    Specified SLS 'aws_credentials' in environment 'base' is not available on the salt master
----------
    Specified SLS 'letsencrypt' in environment 'base' is not available on the salt master
Removing .psql file

Files

test-single-host.tar.gz (177 KB) test-single-host.tar.gz Single host test on aws+le Javier Bértoli, 02/25/2022 10:53 PM

Subtasks 1 (0 open1 closed)

Task #18807: Review branch 18785-single-host-single-name-with-letsencryptResolvedWard Vandewege02/28/2022

Actions

Related issues 1 (0 open1 closed)

Copied to Arvados - Bug #18791: [installer] single host/single hostname installer broken with custom certsResolvedWard Vandewege

Actions
Actions #1

Updated by Ward Vandewege almost 3 years ago

  • Status changed from New to In Progress
Actions #2

Updated by Ward Vandewege almost 3 years ago

  • Description updated (diff)
Actions #3

Updated by Ward Vandewege almost 3 years ago

  • Copied to Bug #18791: [installer] single host/single hostname installer broken with custom certs added
Actions #5

Updated by Javier Bértoli almost 3 years ago

  • Assigned To changed from Ward Vandewege to Javier Bértoli
Actions #6

Updated by Javier Bértoli almost 3 years ago

Rewrote the code as discussed with @cure. Branched from #18791 and modified to manage different certs depending on single/multiple hostnames.

Tested locally on vagrant, with snakeoil certs, and it passes.
Tested on AWS, with a single instance VM and LE certs and it passes.

CAVEAT: LE, by policy, does not issue certificates to AWS domain names, so a valid, non-aws domain name needs to be assigned to the node.

Attached are the config files used for testing and the output file of the run, following instructions described in https://doc.arvados.org/install/salt-single-host.html

Actions #8

Updated by Ward Vandewege almost 3 years ago

Javier Bértoli wrote:

Rewrote the code as discussed with @cure. Branched from #18791 and modified to manage different certs depending on single/multiple hostnames.

Tested locally on vagrant, with snakeoil certs, and it passes.
Tested on AWS, with a single instance VM and LE certs and it passes.

CAVEAT: LE, by policy, does not issue certificates to AWS domain names, so a valid, non-aws domain name needs to be assigned to the node.

  • Well, that seems like a worthwhile thing to add to our documentation. Maybe something like this:
Please note: When using AWS, EC2 instances can have a default hostname that ends with `amazonaws.com`. Let's Encrypt has a blacklist of domain names for which it will not issue certificates, and that blacklist includes the `amazonaws.com` domain. In order to use Let's Encrypt certificates on AWS EC2, you will need to bring your own domain name and point a hostname in that domain at your EC2 instance.

Attached are the config files used for testing and the output file of the run, following instructions described in https://doc.arvados.org/install/salt-single-host.html

  • in `tools/salt-install/config_examples/single_host/single_hostname/states/snakeoil_certs.sls` line 5-6
+# WARNING: This file is only used for testing purposes, and should not be used
+# in a production environment

Just remove that please. It's not true (who are we to assume the user's purpose?) and it doesn't convey any useful information here. The issues with self-signed certificates are pretty obvious/visible and any caveats belong in the documentation.

  • in `tools/salt-install/local.params.example.single_host_single_hostname`
+# If you going to provide your own certificates for Arvados, the provision script can
+# help you deploy them. In order to do that, you need to set `SSL_MODE=bring-your-own` above,
+# and copy the required certificates under the directory specified in the next line.
+# The certs will be copied from this directory by the provision script.
 # The directory to check for the config files (pillars, states) you want to use.
 # There are a few examples under 'config_examples'.
 # CONFIG_DIR="local_config_dir" 

All these comments are confusing. The "next line" is another comment, so... From all this I can't actually say where the certs need to go. Is the definition of CUSTOM_CERTS_DIR simply missing? The example in
tools/salt-install/local.params.example.single_host_multiple_hostnames has even more comments but also a line defining CUSTOM_CERTS_DIR.

  • For the single host `bring-your-own` certificates case, please add to the docs where the cert file needs to go and what it should be called.

I'm still doing testing but overall it looks good with the above changes. I'll update this when I am done testing.

Actions #9

Updated by Javier Bértoli almost 3 years ago

Addressed comments on commits 3d3790ee6..3a26616ce, branch 18785-single-host-single-name-with-letsencrypt

Actions #10

Updated by Ward Vandewege almost 3 years ago

I pushed a number of followon changes, ready for another look in fc1bcfc9058f6bcdcbfe22fef7c85ef2b683af76 on branch 18785-single-host-single-name-with-letsencrypt.

Actions #11

Updated by Ward Vandewege almost 3 years ago

Added a test for the presence of /etc/cloud/cloud.cfg.d in 0eb3e44248cce822c97aff3882be37830ca9502b on branch 18785-single-host-single-name-with-letsencrypt

Actions #12

Updated by Javier Bértoli almost 3 years ago

@cure, it lgtm.

Actions #13

Updated by Ward Vandewege almost 3 years ago

  • Status changed from In Progress to Resolved

Thanks, merged into the 2.3-release branch, and into main.

Actions #15

Updated by Peter Amstutz almost 3 years ago

  • Release set to 49
Actions

Also available in: Atom PDF