Using podman-remote instead of pypodman, for podman-machine

[afbjorklund]

/kind feature

Note: It's hard to use podman-remote instead of the previous pypodman,
due to the lack of environment variables (some of them missing entirelly).

Here is the current configuration:

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"

Trying to map these into parameters, but there is no param for the -i flag.
Normally SSH is transferred over a local port, rather than using the VM's IP.

The current workaround is to use the PODMAN_VARLINK_BRIDGE,
but unfortunately that doesn't work for running interactive sessions with:

export PODMAN_VARLINK_BRIDGE="/usr/bin/ssh -F /dev/null -o ConnectionAttempts=3 -o ConnectTimeout=10 -o ControlMaster=no -o ControlPath=none -o LogLevel=quiet -o PasswordAuthentication=no -o ServerAliveInterval=60 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected] -o IdentitiesOnly=yes -i /home/anders/.local/machine/machines/box/id_rsa -p 38053 sudo varlink bridge"

$ podman-remote run -it alpine
Error: client must use upgraded connection to attach

Would it be possible to make podman-remote compatible with the above variables ?
(And add a configuration option, that would pass the correct -i to the ssh command)

	return fmt.Sprintf(
		`ssh -p %d -T %s@%s -- /usr/bin/varlink -A \'/usr/bin/podman --log-level=%s varlink \\\$VARLINK_ADDRESS\' bridge`,
		port, remoteConn.Username, remoteConn.Destination, logLevel)

One more complication is the hardcoded locations of the commands on the remote end.
For instance, when running tiny core linux then additional software is under /usr/local.

sh: /usr/bin/varlink: not found

tc@box:~$ which varlink
/usr/local/bin/varlink
tc@box:~$ which podman
/usr/local/bin/podman

Couldn't we just let the remote system find them in the PATH ? Workaround was runtime symlinks.

---

Eventually, once all the various above issues are worked around - it does work OK in the end...

$ podman-remote --username=$PODMAN_USER --remote-host=$PODMAN_HOST --port $PODMAN_PORT run -it alpine
Trying to pull docker.io/library/alpine...
Getting image source signatures
Copying blob sha256:9d48c3bd43c520dc2784e868a780e976b207cbf493eaff8c6596eb871cbd9609
Copying config sha256:961769676411f082461f9ef46626dd7a2d1e2b2a38e6a44364bcbecf51e66dd4
Writing manifest to image destination
Storing signatures
/ #

I copied my ssh key to the /root/.ssh/authorized_keys, due to the lack of -i parameter.
It also warned me that the server at random-port had changed its host key: (Again)

The authenticity of host '[127.0.0.1]:38053 ([127.0.0.1]:38053)' can't be established.
ECDSA key fingerprint is SHA256:0697eMVSJIEHK2LXDkE9R6R7QnHxbBkdZOaavBqz0Bs.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[127.0.0.1]:38053' (ECDSA) to the list of known hosts.

That is where the PODMAN_IGNORE_HOSTS comes in handy, until host keys are fixed.
It just causes the connection to use the regular workarounds for ignoring any host keys:

-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null

[rhatdan]

Yes those seem very reasonable, open a PR for them.

[afbjorklund]

Here is the improved usage:

$ eval $(podman-machine env)
$ podman-remote version
Client:
Version:            1.6.1-dev
RemoteAPI Version:  1
Go Version:         go1.12.10
OS/Arch:            linux/amd64

Service:
Version:            1.6.0-dev
RemoteAPI Version:  1
Go Version:         go1.12.10
OS/Arch:            linux/amd64

[rhatdan]

very cool. Would this work on a MAC?

[afbjorklund]

It should (any Unix), but come to think of it I forgot to pass the parameters to my Windows implementation... There is also a long-standing request to write a more "native" Mac driver.

Currently the included options are still VirtualBox and QEMU, but there are some plugins.
For the Mac, the requested driver is Xhyve (or Docker's HyperKit), and for Win it is Hyper-V.

Have tested an older version with VirtualBox 5 and with "qemu-system-x86_64" on OS X.
But haven't gotten around to building the podman-machine-driver-xhyve, or qemu with hvf.

The Windows users are reporting some issues when using the bridge, maybe DOS things ?
It was tested successfully on Windows 7, but I did use a proper bash shell (through MSYS)