podman info - field to check whether it's a remote client

[vrothberg]

podman info should have a field indicating whether it's a remote client or not (see kubernetes-sigs/kind#2235 (review)).

[Luap99]

The remoteSocket field is only added by the local client:

$ podman info | grep remoteSocket
  remoteSocket:
$ podman-remote info | grep remoteSocket

[vrothberg]

@Luap99, that's not a reliable source:

~ $ podman-remote info |grep emote
  remoteSocket:
~ $ podman info |grep emote
  remoteSocket:

[Luap99]

It looks like this behaviour changed after v3.1.2.

[afbjorklund]

It would be even more strange if podman-remote didn't have a socket ?

So far we have mostly been using podman version to tell them apart.

$ podman version
Version:      3.1.2
API Version:  3.1.2
Go Version:   go1.15.2
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64
$ podman-remote version
Client:
Version:      3.1.2
API Version:  3.1.2
Go Version:   go1.15.2
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Server:
Version:      3.1.2
API Version:  3.1.2
Go Version:   go1.15.2
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

But it could be good with an explicit field.

Like the current "rootless", or something ?

$ podman info | grep rootless
    rootless: true
$ sudo podman info | grep rootless
    rootless: false

---

Actually we just hardcoded runtime.GOOS != "linux"

Made it hard to test podman-remote on Linux, though...
kubernetes/minikube#8003

But the lack of networking stopped using podman remote.

podman-remote run -p 127.0.0.1:8000:80 -d docker.io/library/nginx
curl http://localhost:8000

[afbjorklund]

@Luap99 :

So if you run podman-remote, it does not have a socket ?

podman-remote info

But if you log in to the machine and run podman local, it does ?

podman machine ssh podman info

@@ -42,6 +42,9 @@
       spec: 1.0.0
       +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
   os: linux
+  remoteSocket:
+    exists: true
+    path: /run/user/1000/podman/podman.sock
   security:
     apparmorEnabled: false
     capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT

That is quite counter-intuitive.

[jwhonce]

@Luap99 @afbjorklund I suggest adding the field host.serviceIsRemote (bool) unless there is an objection. It would be set in the podman client vs. the service. The client already "knows" how it is connecting to libpod (registry.IsRemote()). remoteSocket has come to mean the socket the service is listening on. This is a quick addition and makes it very obvious what is going on.

/cc @rhatdan @baude

[jwhonce]

/cc @vrothberg

[rhatdan]

SGTM

[afbjorklund]

Yes, something new sounds good to me. I guess downstream will have to compare versions or something.

And go back to heuristics, if the podman version is too low - or maybe just when the new field is missing ?

podman version | grep Server

I don't think looking at $CONTAINER_HOST would work anymore, since it could be using a "connection"

[jwhonce]

@afbjorklund FYI A HEAD on /_ping returns the header Libpod-Api-Version which clients could use to determine which method to use.

[afbjorklund]

I think we have mostly given up on using the API for podman, and resort to using the CLI instead...

And it seems to give consistent results, for the older versions (tested with podman1/podman2/podman3)

$ podman-remote info --format "{{.Host.ServiceIsRemote}}"
Error: template: info:1:7: executing "info" at <.Host.ServiceIsRemote>: can't evaluate field ServiceIsRemote in type *define.HostInfo
$ echo $?
125

So one can use the new info feature for podman4 (or whenever it is included), and fall back on version.

We normally call it anyway, not so much for the actual version - but more as a quick way to check it's alive...

$ podman-remote info --format "{{.Host.ServiceIsRemote}}"
true$ echo $?
0

[afbjorklund]

@jwhonce : assuming that podman is the regular daemonless version, where would one send the /_ping ?

Otherwise, we could just look at the binary. If it is podman-remote, it is remote. (not using podman --remote)

So I think the proposed info field for remoteness is fine.

---

If i understand correctly, they had some different original requirements anyway:

		// Unlike `docker info`, `podman info` does not print available cgroup controllers.
		// So we parse "cgroup.subtree_control" file by ourselves.

So maybe they were more interested in cgroupVersion, and some new fields ?

	MemoryLimit     bool     `json:"MemoryLimit"`
	PidsLimit       bool     `json:"PidsLimit"`
	CPUShares       bool     `json:"CPUShares"`

kubernetes-sigs/kind#2233

[aojea]

`I don't think looking at $CONTAINER_HOST would work anymore, since it could be using a "connection"

in the meantime, can we use the env CONTAINER_HOST variable to discriminate?

[afbjorklund]

in the meantime, can we use the env CONTAINER_HOST variable to discriminate?

That was my point, that variable doesn't have to be in use. It could just be config files...

When using the new podman machine for instance, instead of podman-machine env

$ env | grep CONTAINER
$ podman system connection list
Name                         Identity                                    URI
podman-machine-default*      /home/anders/.ssh/podman-machine-default  ssh://core@localhost:34265/run/user/1000/podman/podman.sock
podman-machine-default-root  /home/anders/.ssh/podman-machine-default  ssh://root@localhost:34265/run/podman/podman.sock

So it could be a remote connection, even without CONTAINER_HOST. Or local, with it.

[aojea]

interesting

podman --remote info
Error: cannot connect to the Podman socket, please verify that Podman REST API service is running: Get "http://d/v2.0.0/libpod/_ping": dial unix ///run/user/1000/podman/podman.sock: connect: no such file or directory

does this error guarantees me thath podman can only be used locally?

[afbjorklund]

does this error guarantees me thath podman can only be used locally?

I cannot really parse this sentence. The error means that the service is not running, either it is not available or configured wrong - or the user just forgot to start it (systemctl --user start podman.socket). On some distributions it is disabled by default.

But if you get the error message, it at least means that you were trying to run the remote client. Always something.

[aojea]

yeah, sorry, I typed quickly, what I tried to mean is that if I have that error, that seems to mean that it can only run local, it can't use a remote client

[jwhonce]

@jwhonce : assuming that podman is the regular daemonless version, where would one send the /_ping ?

@afbjorklund I have RESTful API on the brain. Sorry for the noise.

[aojea]

did you mean to close it @jwhonce ? 🤔

[jwhonce]

#10300 will auto-close.