PODMAN_HOST should match DOCKER_HOST uri format

[ssbarnea]

DOCKER_HOST can also be used with URIs to define exactly how to connect to a host, like DOCKER_HOST=ssh://root@address.

This feature is key for providing a good user experience because it allows users to use the tool without having to modify CLI arguments or API calls (docker-py loads it implicitely) in scripts/tools.

This was initially described in #2276 which was closed, even if it was not really implemented.

[rhatdan]

Seems like a reasonable request.
@baude @jwhonce WDYT?
@ssbarnea a PR would help this along.

[baude]

we have similar environment variables just not called DOCKER_HOST or PODMAN_HOST. Is the actual name required here?

[rhatdan]

The question I would have is, would the use of a URI be easier for users to descover then a bunch of different Environment variables.

[ssbarnea]

I think that a single URI variable provides more flexibility and is also more future proof. When using multiple variables there is always the need to introduce new ones,... like add protocol, add SSL escpace options, .... --- this is why I think an URI is more appropriate (not to mention that it does not clutter the user env). Switching credentials is would be just one set instead on N-sets-unsets.

I think that docker did the same thing initially where DOCKER_HOST was only the hostname but later they realized that they need more and upgraded it.

There is no special requirement for using proposed name, you are free to use PODMAN_URI or whatever think is more appropriate.

I would like to have the time to make the PR myself but I am afraid I am overloaded till December, at least. Maybe someone else can step in.

[afbjorklund]

Setting DOCKER_HOST assumes that it will talk the docker protocol, while it will be varlink...

And we have already used PODMAN_HOST for the hostname (sans scheme and username)

See #1824

PODMAN_USER=root
PODMAN_HOST=address
PODMAN_PORT=22
PODMAN_IDENTITY_FILE
PODMAN_IGNORE_HOSTS=false

[baude]

Ok, this is already implemented with Podman. The environment variable is PODMAN_VARLINK_ADDRESS. It was used specifically in the early remote client days and is used in the remote ci tests for both root and rootless tests of the remote client.

Makefile:276:           export PODMAN_VARLINK_ADDRESS=unix:$$SOCK_FILE; \
Makefile:277:           ./bin/podman varlink --timeout=0 $$PODMAN_VARLINK_ADDRESS &>/dev/null & \
contrib/cirrus/rootless_test.sh:34:export PODMAN_VARLINK_ADDRESS=unix:/tmp/podman-$(id -u)
docs/tutorials/remote_client.md:71:$ PODMAN_VARLINK_ADDRESS="tcp:127.0.0.1:1234" bin/podman-remote images
pkg/adapter/client.go:29:       } else if address := os.Getenv("PODMAN_VARLINK_ADDRESS"); address != "" {
test/e2e/libpod_suite_remoteclient_test.go:71:  os.Unsetenv("PODMAN_VARLINK_ADDRESS")
test/e2e/libpod_suite_remoteclient_test.go:75:  os.Setenv("PODMAN_VARLINK_ADDRESS", addr)
test/utils/utils.go:74:         env = append(env, fmt.Sprintf("PODMAN_VARLINK_ADDRESS=%s", p.VarlinkEndpoint))

The URI only supports the socket language right now but could possibly be expanded. The complimentary environment variable is the PODMAN_VARLINK_BRIDGE which allows you to specific the bridge command.

I think it could be possible to make the URI honor ssh but it is nowhere near a priority right now so help fromt he community would be appreciated.

[afbjorklund]

What do you think about #4161 ? Still can't get PODMAN_VARLINK_BRIDGE to work interactively.

$ eval $(podman-machine env --varlink)
$ podman-remote run -it busybox
Error: client must use upgraded connection to attach

However, using the patched podman-remote it works fine when setting all 5 of the env variables:

$ eval $(podman-machine env)
$ ./bin/podman-remote run -it busybox
/ #

---

EDIT: I was trying to write "bridge", but ended up writing "address". Duh 🤦‍♂️

[afbjorklund]

Here is the comparison of environment variables, between docker-machine and podman-machine:

export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.100:2376"
export DOCKER_CERT_PATH="/home/anders/.docker/machine/machines/default"
export DOCKER_MACHINE_NAME="default"
# Run this command to configure your shell: 
# eval $(docker-machine env)

export PODMAN_USER="root"
export PODMAN_HOST="127.0.0.1"
export PODMAN_PORT="38053"
export PODMAN_IDENTITY_FILE="/home/anders/.local/machine/machines/box/id_rsa"
export PODMAN_IGNORE_HOSTS="true"
export PODMAN_MACHINE_NAME="box"
# Run this command to configure your shell: 
# eval $(podman-machine env)

It would be possible to add a PODMAN_URI, but I don't think varlink (nor ssh) supports ssh:// ?

[afbjorklund]

@ssbarnea : are you OK with using two variables instead of one ? PODMAN_USER/PODMAN_HOST

[sshnaidm]

Actually it's two variables: PODMAN_VARLINK_ADDRESS and combination of PODMAN_USER/PODMAN_HOST.
If we use tcp connection to varlink we need to use PODMAN_VARLINK_ADDRESS, if unix socket via SSH then PODMAN_USER/PODMAN_HOST. Is it right? Please correct me if I'm wrong.
Also there are --username user --remote-host host CLI options that can be used with podman-remote to connect to varlink unix socket via SSH, but I don't find how to connect with command options to TCP varlink. Is it available only with PODMAN_VARLINK_ADDRESS=tcp:host:port environment variable?

[afbjorklund]

That sounds about right.

I'm not sure if you are supposed to use tcp: directly, due to the lack of authentication and encryption ? In the examples it is only used to access a local tcp tunnel, which is then using ssh for the transport:

https://github.com/containers/libpod/blob/master/docs/tutorials/remote_client.md#remote-node-setup

$ ssh -L 127.0.0.1:1234:/run/podman/io.podman root@remotehost
$ PODMAN_VARLINK_ADDRESS="tcp:127.0.0.1:1234" bin/podman-remote images

[sshnaidm]

I think tcp: is great for local testing, also docker supports it too.
I think maybe PODMAN_VARLINK_ADDRESS can be expanded to options like ssh://user@host so that we don't need to calculate it depending on protocol.
Just:

PODMAN_VARLINK_ADDRESS="tcp:127.0.0.1:1234" bin/podman-remote images
PODMAN_VARLINK_ADDRESS="ssh://user@remote_host:remote_port" bin/podman-remote images

Or maybe to introduce a new variable like PODMAN_REMOTE_HOST
Then you need to care about one variable only, it makes life easier :)

[github-actions]

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

[sshnaidm]

So, is it possible to have one variable for remote connection configuration like it's in docker?

[afbjorklund]

Should be trivial to add yet another variable, and parse it as a fallback.

[rhatdan]

@afbjorklund or @ssbarnea could you open a PR for this feature?

[ssbarnea]

@rhatdan Sorry but until #4511 is fixed I have few incentives to implement such feature. Once that one is sorted I will probably try to raise a PR as I want to make it easier to everyone to use podman.

[afbjorklund]

I need all 4 variables (for podman-machine) so adding another one does not help me (need port and key)

[github-actions]

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

[rhatdan]

@ssbarnea Are you still interested in this one?