#dagger query and "x509: certificate signed by unknown authority"

1 messages · Page 1 of 1 (latest)

unreal cloak
#

Hi all,

I'm running behind a corporate ZScaler proxy and have configured my Dagger Engine like so:

$ docker run --rm --name customized-dagger-engine --privileged --volume $PWD/zscaler-root-ca.pem:/etc/ssl/certs/zscaler.pem --env SSL_CERT_FILE=/etc/ssl/certs/zscaler.pem --env GOINSECURE=* registry.dagger.io/engine:v0.9.4

dagger run ... works fine, but when I try to run dagger query (for example: https://docs.dagger.io/194031/kubernetes#step-2-connect-dagger-cli-to-dagger-engine-pod) I get x509: certificate signed by unknown authority when pulling the Go modules (see attached).

Any advice?

📎 dagger-query.txt
calm elbow
#

is this the output of the dagger query command?

#

that's strange. I get a completely different thing when I run that

#

it seems as if you were not running dagger query at ll

unreal cloak
#

Hmm, are you saying that the go mod tidy stuff shouldn't have run at all?

#

BTW, this is also a problem if I try to install modules via dagger mod install

calm elbow
# unreal cloak Hmm, are you saying that the go mod tidy stuff shouldn't have run at all?

yes, I see in your logs that it's trying to upload stuff but this shouldn't happen

│ ▽ host.directory /Users/ABDMA4Q/dev/absa/bison-cloud-platform/dagger/hello-dagger
│ █ [15.32s] upload /Users/ABDMA4Q/dev/absa/bison-cloud-platform/dagger/hello-dagger from L4WX91X9R4 (client id: hsc031rqxnnqjbr4arp0uczbi)
│ ┣ [15.18s] transferring /Users/ABDMA4Q/dev/absa/bison-cloud-platform/dagger/hello-dagger:

unreal cloak
#

Ok, so if I run this in another directory (like /tmp) without a go.mod (guessing) then I get your output

#

Or rather a dagger.json since the dependencies look like the modules it was trying to pull

calm elbow
#

oh, I see. you're running dagger query within a module

#

that's why the engine tries to initialize the module

#

that makes sense

#

I think modules still not work under private repos / corporate proxies. cc @spark talon @frank wolf can you help me to confirm this?

frank wolf
#

No changes on that front. Need to pass through env vars to pipeline the same way and/or custom runner with needed config.

calm elbow
#

but in the modules case it's a bit trickier since we don't have control over the runtime conatiner, right?

spark talon
calm elbow
frank wolf
calm elbow
#

last time I recall that's not implemented and we don't have a way to make it work yet

frank wolf
#

Oh I see. Yes, it's in the roadmap to allow configuring the runtime container but it's not available yet. In the meantime you can create a custom SDK based on an existing one.

#

It's simpler than it sounds 🙂

#

I can make a simple repro, if there's something specific you'd like to see being customized into the container.

#

I realize now that Go doesn't have a proper module runtime ref. It's the only one. Python and NodeJS do though. The idea is you can make a runtime module that depends on another one, define ModuleRuntime and Codegen functions, pass params to dependent runtime module and make your changes. Then use this new module in the sdk field of the actual modules you need to run it with.

unreal cloak
#

Thanks, I think I'll wait for the roadmap features. I'm just getting started with Dagger, so the above sounds quite complex at the moment 😄

calm elbow
marble urchin
#

Can I continue this thread? I'm hitting the same certificate issues in a corporate environment. Things I've tried:

  • Implement ModuleRuntime. Doesn't work because I have to use the go sdk to implement it and the go sdk is what breaks
  • Add the private certs to the engine and embedded go-module-sdk-image.tar. Solves the SSL issues but breaks modules. Calling any module just gives "main object not found"