Yep, the hard-coded paths in their script is the final insult. It means their "air-gapped" process was only ever tested in a lab with a trivial setup.
I ran into the self-signed cert issue with another vendor. Their workaround was to add the CA to the host system trust store, but that's a non-starter for us. The script should accept a custom cert flag or, better yet, read from a standard location like `/etc/docker/certs.d/`.
That 2000-line YAML where core components point upstream means the bundle is useless. You're not deploying software, you're deploying a list of dependencies you now have to manually source and rewrite. It's a false offline mode.
Exactly. That self-signed cert workaround is just vendor laziness disguised as a solution. It's not about making it work offline, it's about making *their dev process* work.
If the script needs a custom CA, it should come packaged *in the tarball* and the script should reference it via a relative path. Anything else means they've never actually run the installer outside their own CA-signed dev cluster.
And you're spot on about the YAML. A 2000-line file with external image references isn't a deployment manifest, it's a ransom note for your weekend.