maxhoesel-ansible/ansible-collection-smallstep

feature: eliminate "expected error" on bootstrap

Closed this issue · 5 comments

eengstrom commented

When bootstrapping a new host the first time, there will always be two "expected errors":

  1. checking if step-cli is installed:
TASK [maxhoesel.smallstep.step_bootstrap_host : Look for step_cli_executable] ****************************************************
fatal: [odysseus]: FAILED! => {"changed": false, "cmd": "step-cli version", "msg": "[Errno 2] No such file or directory: b'step-cli': b'step-cli'", "rc": 2}
...ignoring

TASK [maxhoesel.smallstep.step_cli : Download and extract step-cli archive] ******************************************************
changed: [odysseus]
  1. checking if the root cert is installed:
TASK [maxhoesel.smallstep.step_bootstrap_host : Check if cert is already installed] ******************************************
fatal: [odysseus]: FAILED! => {"changed": false, "cmd": ["step-cli", "certificate", "verify", "/etc/step/certs/root_ca.crt"], "delta": "0:00:00.062226", "end": "2021-07-21 12:46:09.637063", "msg": "non-zero return code", "rc": 1, "start": "2021-07-21 12:46:09.574837", "stderr": "failed to verify certificate: x509: certificate signed by unknown authority", "stderr_lines": ["failed to verify certificate: x509: certificate signed by unknown authority"], "stdout": "", "stdout_lines": []}
...ignoring

TASK [maxhoesel.smallstep.step_bootstrap_host : Install CA cert into trust stores] *******************************************
changed: [odysseus]

While minor, and I know it's doing the right thing, it takes me by surprise and takes me a second to remember that these are "expected".

Any chance we could find a different way to do the check so that the error is not produced, but the end result is the same?

maxhoesel commented

I would be fine with replacing that task, but I'm not sure whether there's a simple solution that doesn't error out. I know that the x509_certificate_info module from community.crypto can do this, but I don't think this justifies pulling in an entire collection as a dependency.

One option would be to write our own _info module that returns the values from step-cli inspect + a valid field based on the output from step-cli verify. That would eliminate the need for an external dependency and remove the direct call to step-cli.

eengstrom commented

I agree that using community.crypto seems like overkill, but minimally we could use stat to see if the files even exist before running the commands. More steps, I know, but appears cleaner.

I may try to get to this yet this week.

(meta comment - I added another "expected error" to the description)

  • 👍1
strarsis commented

The "error" message when the binary can't be found can be confusing at first (one think there was an actual error during the run).

strarsis commented

@maxhoesel: Would this be reason enough for a new release?

maxhoesel commented

Yes. I'm still working on some other changes, but once those are merged I am going to push a new release, probably within the next few days

  • 👍1