You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reason behind this error is the change in 0b2969f. The patch for the smarter host resolution ignores the dummy header coming from the ConnectionHelper and seemingly uses limond@localhost:22 as the Host header.
The following code works as there is no @ in the host property in the latest version too:
I think, using a host like host: ssh://limond@localhost:22 should connect to a remote docker daemon just like DOCKER_HOST=ssh://limond@localhost:22 does with the docker cli.
Steps to reproduce
Clone the gist containing the code from above git clone https://gist.github.com/61930b03929d469cb7fff39eb89f1471.git
Install: npm install
pulumi up
The code assumes a running docker daemon and sshd on port 22 as well as a$USER env variable.
Output of pulumi about
CLI
Version 3.67.0
Go Version go1.20.4
Go Compiler gc
Plugins
NAME VERSION
docker 4.2.0
nodejs unknown
Host
OS debian
Version 12.0
Arch x86_64
This project is written in nodejs: executable='/home/limond/.nvm/versions/node/v16.17.1/bin/node' version='v16.17.1'
Current Stack: test
Found no resources associated with test
Found no pending operations associated with test
Backend
Name mainPC
URL file://~
User limond
Organizations
Dependencies:
NAME VERSION
@pulumi/docker 4.2.0
@pulumi/pulumi 3.67.0
@types/node 16.18.30
Pulumi locates its logs in /tmp by default
Additional context
As I wrote above, there is a workaround using the sshOpts property. Still I think it would be a good idea to restore the behavior of 4.0.0 as others will most likely also assume ssh://<user>@<domain> to work as the host property.
I think #580 is a result of this regression but I was not entirely sure and since the thread in this issue goes more into the arm64 direction I decided to open a new issue.
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered:
What happened?
Hello,
I am trying to connect to a remote docker daemon through SSH. Based on the error I get and the Issue #580 I assumed this is not implemented yet.
However, after some digging, I found that there is a problem with using certain symbols in the
host
property of theProviderArgs
since 4.0.1.The following typescript example works for the docker provider in 4.0.0:
However, in 4.0.1 up to the latest release this produces the following error on my debian machine:
The reason behind this error is the change in 0b2969f. The patch for the smarter host resolution ignores the dummy header coming from the
ConnectionHelper
and seemingly useslimond@localhost:22
as the Host header.The following code works as there is no
@
in thehost
property in the latest version too:Expected Behavior
I think, using a host like
host: ssh://limond@localhost:22
should connect to a remote docker daemon just likeDOCKER_HOST=ssh://limond@localhost:22
does with the docker cli.Steps to reproduce
git clone https://gist.github.com/61930b03929d469cb7fff39eb89f1471.git
npm install
pulumi up
The code assumes a running docker daemon and sshd on port 22 as well as a
$USER
env variable.Output of
pulumi about
CLI
Version 3.67.0
Go Version go1.20.4
Go Compiler gc
Plugins
NAME VERSION
docker 4.2.0
nodejs unknown
Host
OS debian
Version 12.0
Arch x86_64
This project is written in nodejs: executable='/home/limond/.nvm/versions/node/v16.17.1/bin/node' version='v16.17.1'
Current Stack: test
Found no resources associated with test
Found no pending operations associated with test
Backend
Name mainPC
URL file://~
User limond
Organizations
Dependencies:
NAME VERSION
@pulumi/docker 4.2.0
@pulumi/pulumi 3.67.0
@types/node 16.18.30
Pulumi locates its logs in /tmp by default
Additional context
As I wrote above, there is a workaround using the
sshOpts
property. Still I think it would be a good idea to restore the behavior of4.0.0
as others will most likely also assumessh://<user>@<domain>
to work as the host property.I think #580 is a result of this regression but I was not entirely sure and since the thread in this issue goes more into the arm64 direction I decided to open a new issue.
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered: