Non-obvious extra argument to new podman --remote

[afbjorklund]

current (V1)

systemctl --user start io.podman.socket
export PODMAN_VARLINK_ADDRESS=unix:/run/user/1000/podman/io.podman

 podman version
Version:            1.9.3
RemoteAPI Version:  1
Go Version:         go1.13.8
OS/Arch:            linux/amd64
 podman-remote version
Client:
Version:            1.9.3
RemoteAPI Version:  1
Go Version:         go1.13.8
OS/Arch:            linux/amd64

Server:
Version:            1.9.3
RemoteAPI Version:  1
Go Version:         go1.13.8
OS/Arch:            linux/amd64

development (V2)

systemctl --user start podman.socket
# hacked the podman.service unit to run /usr/local/bin/podman2 instead of /usr/bin/podman

 podman2 version
Version:      2.0.0-dev
API Version:  1
Go Version:   go1.13.8
Git Commit:   3f026eb6a682a68e69f9376b72157a8f084e575c
Built:        Sat Jun 13 17:53:06 2020
OS/Arch:      linux/amd64
 podman2 --remote version
Error: unrecognized command `podman2 version`
Try 'podman2 --help' for more information.
 podman2 --remote podman version
Client:
Version:      2.0.0-dev
API Version:  1
Go Version:   go1.13.8
Git Commit:   3f026eb6a682a68e69f9376b72157a8f084e575c
Built:        Sat Jun 13 17:53:06 2020
OS/Arch:      linux/amd64

Server:
Version:      2.0.0-dev
API Version:  0
Go Version:   go1.13.8
Git Commit:   3f026eb6a682a68e69f9376b72157a8f084e575c
Built:        
OS/Arch:      linux/amd64

So it seems that I have to give an extra argument, after the -r ?

Seems like the actual value doesn't really matter (foo, bar, etc)

[afbjorklund]

Maybe I was a bit early, and that podman-remote should still be used... ?

I was under the impression that everything was supposed to use podman

[afbjorklund]

Side note: fixed the missing timestamp for server in PR #6599

[rhatdan]

Well we plan on supporting both. Podman-remote is a bit thinner the regular podman, but there is no reason that regular podman can not get the job done on a remote machine. I am not sure how well this is working yet, since most people are just testing with podman-remote.
We probably need to implement another test where podman is testing in --remote mode.

[afbjorklund]

I guess we will have same problem anyway, to educate Linux users to add --remote.

Unless we want everyone (including Mac and Win users) to always add the extra flag.
Which I assume that we don't want to do, for the same reason of renaming the binary.

So basically we will still have these different tabs in the docs, with slightly different content:

{{% tabs %}} {{% tab "Linux" %}}

podman-remote help

{{% pageinfo color="info" %}} Note: On Linux the remote client is called "podman-remote", while the local program is called "podman". {{% /pageinfo %}}

{{% /tab %}} {{% tab "macOS" %}}

podman help

{{% pageinfo color="info" %}} Note: On macOS the remote client is called "podman", since there is no local "podman" program available. {{% /pageinfo %}}

{{% /tab %}} {{% tab "Windows" %}}

podman help

{{% pageinfo color="info" %}} Note: On Windows the remote client is called "podman", since there is no local "podman" program available. {{% /pageinfo %}}

{{% /tab %}} {{% /tabs %}}

Which means that we might as well continue to use podman-remote instead.

Then we don't have to divide it further, to split between 1.6 and 2.0 podman clients.
They can just run podman-remote, and it will run varlink (v1) or rest (v2) as preferred.

The main addition is to export both PODMAN_VARLINK_BRIDGE and CONTAINER_*.

And figure out how to do the access to the podman.sock, when not using sudo...
The obvious approaches being allowing ssh as root - or adding a "podman" group.

SocketMode=0660

[rhatdan]

On 6/16/20 14:17, Anders Björklund wrote: I guess we will have same problem anyway, to educate Linux users to add |--remote|. Unless we want everyone (including Mac and Win users) to always add the extra flag. Which I assume that we don't want to do, for the same reason of renaming the binary.

No podman-remote the `podman` installed on windows/MAC will have this enabled by default. On Linux we might still ship a podman-remote command, but in containers.conf there is a "remote" option, that could be turned to true, which would switch traditional `podman` to run as --remote by default.  Then if you wanted to run podman locally you would have to execute podman --remote=false.

…

So basically we will still have these different tabs in the docs, with slightly different content: |{{% tabs %}} {{% tab "Linux" %}} podman-remote help {{% pageinfo color="info" %}} Note: On Linux the remote client is called "podman-remote", while the local program is called "podman". {{% /pageinfo %}} {{% /tab %}} {{% tab "macOS" %}} podman help {{% pageinfo color="info" %}} Note: On macOS the remote client is called "podman", since there is no local "podman" program available. {{% /pageinfo %}} {{% /tab %}} {{% tab "Windows" %}} podman help {{% pageinfo color="info" %}} Note: On Windows the remote client is called "podman", since there is no local "podman" program available. {{% /pageinfo %}} {{% /tab %}} {{% /tabs %}} | Which means that we might as well continue to use |podman-remote| instead. Then we don't have to divide it further, to split between 1.6 and 2.0 podman clients. They can just run podman-remote, and it will run varlink (v1) or rest (v2) as preferred. The main addition is to export *both* PODMAN_VARLINK_BRIDGE and CONTAINER_*. And figure out how to do the access to the |podman.sock|, when not using |sudo|... The obvious approaches being allowing ssh as root - or adding a "podman" group. |SocketMode=0660| — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6598 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPIPQ5ZWW5Q536WQUI5M2DRW6ZKRANCNFSM4N5BUT6Q>.

[afbjorklund]

I suppose a config file could also be used, right now it is using shell variables...
(mostly since it is modeled after docker-machine, which used this config method)

Haven't really understood yet if $CONTAINER_HOST overrides running locally,
or if you still need to add --remote even with this (remote) environment variable set.

[afbjorklund]

Upgraded to v2.0.0, but now it shows an error instead:

 podman2 --remote podman version
Error: Get http://d/v1.0.0/libpod../../../_ping: dial unix ///run/user/1000/podman/podman.sock: connect: no such file or directory

There is a /run/user/1000/podman/podman.sock socket

Setting $CONTAINER_HOST explicitly and adding the extra fake argument sems to be working. But non-obvious ?

 export CONTAINER_HOST=unix:/run/user/1000/podman/podman.sock
 podman2 --remote podman version
Client:
Version:      2.0.0
API Version:  1
Go Version:   go1.13.8
Git Commit:   eec482cae3289ecaad45c602629657da7062ce9c
Built:        Sun Jun 21 09:58:54 2020
OS/Arch:      linux/amd64

Server:
Version:      2.0.0
API Version:  0
Go Version:   go1.13.8
Git Commit:   eec482cae3289ecaad45c602629657da7062ce9c
Built:        Sun Jun 21 09:58:54 2020
OS/Arch:      linux/amd64

Using podman-remote still works without any workarounds, so I guess that will be the recommended approach.

Maybe remove this misleading "flag" statement from the release notes ? Or add some more info on how to use it ?

The Podman command now supports remotely connections via the REST API using the --remote flag.

https://github.com/containers/libpod/releases/tag/v2.0.0

[afbjorklund]

Not sure what actually happened behind the scenes, but my $CONTAINER_HOST had nothing to do with it.
I think the unix:// is part of the syntax, so it should have been unix:///run/user/1000/podman/podman.sock

Now it is back to the original:

 podman2 --remote version
Error: unrecognized command `podman2 version`
Try 'podman2 --help' for more information.
 podman2 --remote podman version
Client:
Version:      2.0.0
API Version:  1
Go Version:   go1.13.8
Git Commit:   eec482cae3289ecaad45c602629657da7062ce9c
Built:        Sun Jun 21 09:58:54 2020
OS/Arch:      linux/amd64

Server:
Version:      2.0.0
API Version:  0
Go Version:   go1.13.8
Git Commit:   eec482cae3289ecaad45c602629657da7062ce9c
Built:        Sun Jun 21 09:58:54 2020
OS/Arch:      linux/amd64

Without any extra workarounds.

So it more like the systemctl --user is unstable, sometimes it times out and sometimes it doesn't start.
Looks like the socket comes and goes, and there are a lot of the "podman2 system service" spawned.

[afbjorklund]

Also, using the -r flag runs locally. Need to use --remote to run remotely.

  -r, --remote                    Access remote Podman service (default false)

[afbjorklund]

Now it seems like podman --remote works, but that podman-remote stopped working ?

[rhatdan]

They are both working for me?

[afbjorklund]

It was running locally for me with 2.0.1 but will a new issue if I can reproduce

[afbjorklund]

@rhatdan
Seems to be broken in the Ubuntu 20.04 package, since it is not using make:

[  110s] GOPATH=/usr/src/packages/BUILD GO111MODULE=off /usr/bin/go generate ./pkg/varlink/...
[  110s] GOPATH=/usr/src/packages/BUILD GO111MODULE=off /usr/bin/go build -tags 'apparmor exclude_graphdriver_devicemapper seccomp systemd varlink' -ldflags '"-X main.buildInfo=1593196710"' -o bin/podman github.com/containers/libpod/cmd/podman
[  161s] GOPATH=/usr/src/packages/BUILD GO111MODULE=off /usr/bin/go build -tags 'apparmor exclude_graphdriver_devicemapper seccomp systemd varlink remoteclient' -ldflags '"-X main.buildInfo=1593196710"' -o bin/podman-remote github.com/containers/libpod/cmd/podman

https://build.opensuse.org/package/live_build_log/devel:kubic:libcontainers:stable/podman/xUbuntu_20.04/x86_64

Therefore it is still using "remoteclient" build tag, instead of the new "remote"

9263ed2

[mheon]

@lsm5 Poke - looks like we need a build update for the OBS podman-remote packages