azure: fails with ignition+password auth

Question

azure: fails with ignition+password auth

cgwalters opened this issue 4 years ago · comments

I booted a FCOS VM in Azure with just an Ignition config and --authentication-type password to disable Azure's requirement for SSH keys.

[root@walters-fcos ~]# systemctl status afterburn-sshkeys@core
● afterburn-sshkeys@core.service - Afterburn (SSH Keys)
   Loaded: loaded (/usr/lib/systemd/system/afterburn-sshkeys@.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2020-04-28 15:26:00 UTC; 48s ago
  Process: 903 ExecStart=/usr/bin/afterburn ${AFTERBURN_OPT_PROVIDER} --ssh-keys=core (code=exited, status=1/FAILURE)
 Main PID: 903 (code=exited, status=1/FAILURE)

Apr 28 15:26:00 walters-fcos afterburn[903]: Apr 28 15:26:00.092 INFO Fetch successful
Apr 28 15:26:00 walters-fcos afterburn[903]: Error: failed to run
Apr 28 15:26:00 walters-fcos afterburn[903]: Caused by: writing ssh keys
Apr 28 15:26:00 walters-fcos afterburn[903]: Caused by: failed to get certs
Apr 28 15:26:00 walters-fcos afterburn[903]: Caused by: failed to get certificates
Apr 28 15:26:00 walters-fcos afterburn[903]: Caused by: failed to parse uri
Apr 28 15:26:00 walters-fcos afterburn[903]: Caused by: relative URL without a base
Apr 28 15:26:00 walters-fcos systemd[1]: afterburn-sshkeys@core.service: Main process exited, code=exited, status=1/FAILURE
Apr 28 15:26:00 walters-fcos systemd[1]: afterburn-sshkeys@core.service: Failed with result 'exit-code'.
Apr 28 15:26:00 walters-fcos systemd[1]: Failed to start Afterburn (SSH Keys).

Luca Bruno · Answer 1 · Tue Apr 28 2020 23:57:54 GMT+0800 (China Standard Time)

Thanks for the report.
I think that means that the XML value for this property is not a full-blown URL.
It would be interesting to dump the content of the goalstate response and see what it actually contains.

Colin Walters · Answer 2 · Tue May 19 2020 08:31:56 GMT+0800 (China Standard Time)

Still seeing this in e.g. openshift/installer#3613

Luca Bruno · Answer 3 · Tue May 19 2020 16:11:05 GMT+0800 (China Standard Time)

@cgwalters to the best of my knowledge you shouldn't be seeing this in OpenShift, as by design it is not supposed to use cloud SSH keys (unless that design decision changed at some point).

Colin Walters · Answer 4 · Thu May 28 2020 20:22:34 GMT+0800 (China Standard Time)

@cgwalters to the best of my knowledge you shouldn't be seeing this in OpenShift, as by design it is not supposed to use cloud SSH keys (unless that design decision changed at some point).

Ah, right: https://gitlab.cee.redhat.com/coreos/redhat-coreos/merge_requests/972

Luca Bruno · Answer 5 · Wed Jun 17 2020 00:17:05 GMT+0800 (China Standard Time)

I do suspect we are getting back an empty property value or some other kind of magic marker. If that's indeed the way for the platform to signal "SSH keys are disabled", we should probably gracefully warn and exit without error in that specific case.

Luca Bruno · Answer 6 · Fri Jul 10 2020 19:02:18 GMT+0800 (China Standard Time)

I just checked on a password-auth instance, and indeed there is no Certificates entry in the Configuration stanza. This is how the XML section there looks like:

<Configuration>
  <HostingEnvironmentConfig>http://168.63.129.16:80/...</HostingEnvironmentConfig>
  <SharedConfig>http://168.63.129.16:80/...</SharedConfig>
  <ExtensionsConfig>http://168.63.129.16:80/...</ExtensionsConfig>
  <FullConfig>http://168.63.129.16:80/...</FullConfig>
  <ConfigName>http://168.63.129.16:80/...</ConfigName>
</Configuration>