settings.network.https-proxy

[brian-morrissey]

Path to page with content (do not include domain name):
/en/os/1.26.x/api/settings/network/

What content is incorrect?
Currently has an https-proxy example of

[settings.network]
https-proxy = "1.2.3.4:8080"

What should the content say or communicate?
This does not work on Bottlerocket OS 1.29.0 (aws-k8s-1.31) when using a launch template with user data defined

Template Config:

  [settings.network]
    no-proxy = ["localhost", "127.0.0.1", "169.254.169.254", ".internal,s3.amazonaws.com", ".s3.us-east-1.amazonaws.com", "api.ecr.us-east-1.amazonaws.com", "dkr.ecr.us-east-1.amazonaws.com", "ec2.us-east-1.amazonaws.com", "10.0.0.0/16", ".amazonaws.com"]
    https-proxy = "10.0.5.67:8080"

Serial Console Error:

Starting Generate additional settings for Kubernetes...
[    9.515344] pluto[1048]: thread 'main' panicked at aws-smithy-experimental/src/hyper_1_0.rs:259:49:
[FAILED] Failed to start Generate additional settings for Kubernetes.
See 'systemctl status pluto.service' for details.
[    9.570493] pluto[1048]: Unable to parse HTTPS proxy as URL: RelativeUrlWithoutBase
[DEPEND] Dependency failed for Applies settings to create config files.
[    9.690248] pluto[1048]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[DEPEND] Dependency failed for Bootstrap Commands.
[DEPEND] Dependency failed for Bottlerocket initial configuration complete.
[DEPEND] Dependency failed for Isolates configured.target.
[DEPEND] Dependency failed for Sets the hostname.
[DEPEND] Dependency failed for Send signal to CloudFormation Stack.

If https-proxy = "10.0.5.67:8080" is changed to https-proxy = "http://10.0.5.67:8080" in the launch template all is okay.

Not entirely sure if this should be documentation or if it is more of a user experience consistency issue since it works elsewhere without http:// specified like in 'apiclient set settings.network.https-proxy="10.0.5.67:8080"'

[ginglis13]

Hi @brian-morrissey , thanks for the issue. This looks like a real bug in Bottlerocket itself - we made some changes to pluto in bottlerocket-os/bottlerocket-core-kit#213 to support Bottlerocket FIPS variants that I initially thought introduced this regression. I've repro'd on Bottlerocket 1.29.0 nodes, but on older nodes before we switched to aws-smithy-experimental for pluto, I see:

[  OK  ] Finished User-specified setting generators.
         Starting Generate additional settings for Kubernetes...
[    8.785520] pluto[1106]: Unable to parse '10.0.5.67:8080' as URL: relative URL without a base
[FAILED] Failed to start Generate additional settings for Kubernetes.

But, it looks like this behavior has been around since bottlerocket-os/bottlerocket@6a66851 (Bottlerocket 1.17.0) which first introduced auth handling in pluto for https-proxy.

As you mention, prepending the URL scheme directly is a workaround. I opened a PR with the fix here bottlerocket-os/bottlerocket-core-kit#339