Non-obvious extra argument to new podman --remote #6598

afbjorklund · 2020-06-13T16:27:48Z

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)

The text was updated successfully, but these errors were encountered:

afbjorklund · 2020-06-13T16:37:32Z

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 · 2020-06-13T19:48:45Z

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

rhatdan · 2020-06-15T13:51:20Z

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 · 2020-06-16T18:16:58Z

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 · 2020-06-17T12:59:56Z

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 · 2020-06-17T14:58:25Z

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 · 2020-06-21T08:16:22Z

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 · 2020-06-21T08:30:23Z

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 · 2020-06-21T08:34:20Z

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

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

* --remote, --url and --identity are now anchored to podman command. Subcommands should no longer have issues * TraverseChildren now set to V1 expectations * Latest flag now has helper function. Now has consistent usage. * IsRemote() uses cobra parser to determin if --remote is given * Moved validation functions from parser pkg to validate pkg * Fixes containers#6598 Fixes containers#6704 Signed-off-by: Jhon Honce <[email protected]>

afbjorklund · 2020-06-29T20:58:31Z

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

rhatdan · 2020-06-30T10:19:32Z

They are both working for me?

afbjorklund · 2020-06-30T11:52:37Z

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

afbjorklund · 2020-06-30T13:45:31Z

@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 · 2020-06-30T13:48:33Z

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

* --remote, --url and --identity are now anchored to podman command. Subcommands should no longer have issues * TraverseChildren now set to V1 expectations * Latest flag now has helper function. Now has consistent usage. * IsRemote() uses cobra parser to determin if --remote is given * Moved validation functions from parser pkg to validate pkg * Fixes containers#6598 Fixes containers#6704 Signed-off-by: Jhon Honce <[email protected]> <MH: Fixed import issues> Signed-off-by: Matt Heon <[email protected]>

afbjorklund changed the title ~~Non-obvious extra argument to new podman remote~~ Non-obvious extra argument to new podman --remote Jun 21, 2020

afbjorklund mentioned this issue Jun 22, 2020

location of the --remote flag breaks commands. #6704

Closed

jwhonce mentioned this issue Jun 22, 2020

Fixes --remote flag issues #6716

Merged

jwhonce self-assigned this Jun 24, 2020

jwhonce added the remote Problem is in podman-remote label Jun 24, 2020

openshift-merge-robot closed this as completed in #6716 Jun 29, 2020

afbjorklund mentioned this issue Jul 5, 2020

Alternative to sudo, for remote podman #6809

Closed

afbjorklund mentioned this issue Jul 18, 2020

podman --remote does not work #7010

Closed

afbjorklund mentioned this issue Aug 30, 2020

podman remote flag/overlay check (regression?) #7487

Closed

github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 23, 2023

github-actions bot locked as resolved and limited conversation to collaborators Sep 23, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Non-obvious extra argument to new podman --remote #6598

Non-obvious extra argument to new podman --remote #6598

afbjorklund commented Jun 13, 2020 •

edited

Loading

afbjorklund commented Jun 13, 2020

afbjorklund commented Jun 13, 2020

rhatdan commented Jun 15, 2020

afbjorklund commented Jun 16, 2020

rhatdan commented Jun 17, 2020 via email

afbjorklund commented Jun 17, 2020

afbjorklund commented Jun 21, 2020

afbjorklund commented Jun 21, 2020

afbjorklund commented Jun 21, 2020

afbjorklund commented Jun 29, 2020

rhatdan commented Jun 30, 2020

afbjorklund commented Jun 30, 2020

afbjorklund commented Jun 30, 2020

mheon commented Jun 30, 2020

Non-obvious extra argument to new podman --remote #6598

Non-obvious extra argument to new podman --remote #6598

Comments

afbjorklund commented Jun 13, 2020 • edited Loading

current (V1)

development (V2)

afbjorklund commented Jun 13, 2020

afbjorklund commented Jun 13, 2020

rhatdan commented Jun 15, 2020

afbjorklund commented Jun 16, 2020

rhatdan commented Jun 17, 2020 via email

afbjorklund commented Jun 17, 2020

afbjorklund commented Jun 21, 2020

afbjorklund commented Jun 21, 2020

afbjorklund commented Jun 21, 2020

afbjorklund commented Jun 29, 2020

rhatdan commented Jun 30, 2020

afbjorklund commented Jun 30, 2020

afbjorklund commented Jun 30, 2020

mheon commented Jun 30, 2020

afbjorklund commented Jun 13, 2020 •

edited

Loading