Deliver podman through a snap

[abitrolly]

[//]: # kind feature

I've just noted that Ubuntu proposes to install docker as a snap. :O

$ docker

Command 'docker' not found, but can be installed with:

sudo snap install docker     # version 18.06.1-ce, or
sudo apt  install docker.io

See 'snap info docker' for additional versions.

I would rather use podman on Ubuntu. It is not available through standard apt repositories. Now if Docker was packages as a snap then it should be possible to pack podman.

Describe the results you expected:
Run build tools with podman to avoid files owned by root in my project directories.

Additional environment details (AWS, VirtualBox, physical, etc.):
https://snapcraft.io/docker

[abitrolly]

I started the process - https://github.com/abitrolly/podman - time to work on it is limited, though.

[rhatdan]

@lsm5 Could you look into this?

[lsm5]

hi @abitrolly thanks for filing this. I did notice that you had registered podman on the snap store. Just wanted to check if you have prior work already toward this that we could use.

[lsm5]

I started the process - https://github.com/abitrolly/podman - time to work on it is limited, though.

errr sorry I should've read this before posting prior comment. I'll use this and credit you :) . If it can be upstreamed into default libpod, I'll let you know about that.

[abitrolly]

Thanks for reaching out. I am glad you picked this up. There is not enough expertise and focus time for me to complete this idea, and it would be nice to see this working during FOSDEM even if I won't find the way to get there. I tried to replace Docker with podman for cross-platorm automation in user-space. That doesn't completely work, because of #2014, but I hope you can find a way to improve UX there (showing messages when :Z :z is not supplied).

[rhatdan]

@abitrolly What do you want from an SELinux point of view? Podman to check if :Z and :z is not supplied and the mount point is not read/only then check if the label of the mount point is not container_file_t? Print a warning?

[abitrolly]

On Mon, 14 Jan 2019 at 14:51, Daniel J Walsh ***@***.***> wrote: @abitrolly <https://github.com/abitrolly> What do you want from an SELinux point of view? Podman to check if :Z and :z is not supplied and the mount point is not read/only then check if the label of the mount point is not container_file_t? Print a warning?

Ideally users should not think about SELinux until they do something that potentially ruins their system. For example, I heard that relabelling HOME is unsafe operation, and relabeling my project checkout to build it inside of container is not. With a reference list of safe and unsafe operations user can understand the whole issues better. I can understand why I should not relabel HOME (but I forgot), and I don't understand why I should avoid explicit relabelling for project checkout. I think in case of user level containers that golden rule of "the cost of security" is broken - if we sum up all the cases where people lose time (and money), then relabelling HOME (which can be explicitly) avoided probably wastes less time than unreadable container volumes when running build scripts developed on Ubuntu in Fedora. I don't fully understand SELinux and I hope it won't be prerequisite for running `podman`. If I get it right, mount point is always non-readable if :z :Z is not supplied. But if I supply -v, that means I want it to be at least read-only, and in fact read/write. If I understand SELinux correctly, it is limited in the sense that there is only one set of labels and you can't grant privileges for temp file access to some process without ruining existing access rights. If it is not the case, then I want new labels to be applied automatically, because I already specified that I want read-write volume with -v. If there is no way to avoid explicit :z :Z prefixes when running podman with SELinux, then I want it to exit with the error for read-only volumes and print messages for HOME and other dangerous cases in a language that is friendly for users, who don't have the time to learn about Unix rw flags, ACL and that big SELinux thing on top of that.

[rhatdan]

Podman is available via a snap now.

[abitrolly]

@rhatdan I can't find it anymore - https://snapcraft.io/search?q=podman - do you have a link?

[rhatdan]

@lsm5 ^^

[lsm5]

Podman is available via a snap now.

Unlikely, I have the podman name registered on the snap store and I haven't had the time to publish it yet. Unless someone stole it from me and published it.

[abitrolly]

@lsm5does it work? What is required to push it to the --edge channel?

[lsm5]

well I'm still working on the skopeo snap, which will be needed before I can get podman done.

[abitrolly]

@lsm5 let me know if you need help with packing. I've set a pipeline to build and push snaps from Travis CI - https://github.com/yakshaveinc/linux. It fails right now, but if you need that component, I can try to allocate some time/money to get this done.

[abitrolly]

@lsm5 did you manage to snap the skopeo to switch to podman?

[rhatdan]

@lsm5 Any movement on this? @abitrolly Interested in helping?

[lsm5]

On Mon, Aug 05, 2019 at 02:02:21PM -0700, Daniel J Walsh wrote: @lsm5 Any movement on this? @abitrolly Interested in helping?

Not yet, many other distractions, but PPAs seem to work ok for most, so maybe we can have this as a stretch goal, unless community wants to jump in on this.

…

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1915 (comment)

-- Lokesh IRC, GitHub: lsm5 GPG: 0xC7C3A0DD https://keybase.io/lsm5

[abitrolly]

@rnatdan I started the process in https://github.com/abitrolly/podman then Ubuntu staff asked me to hand over the name on official request, so I hoped that you do this. :D

I am interested, but not in my free time as I now use Fedora and there are too many warning about snap with SELinux to use it there.

[lsm5]

@rnatdan I started the process in https://github.com/abitrolly/podman then Ubuntu staff asked me to hand over the name on official request, so I hoped that you do this. :D

Hey, sorry, I guess I was behind nagging ubuntu staff, but then I had a lot of distractions come my way so couldn't get this in.

I am interested, but not in my free time as I now use Fedora and there are too many warning about snap with SELinux to use it there.

Glad to hear you use Fedora :) . @mikeroyal would you be interested in continuing @abitrolly's snap work for podman as well?

[abitrolly]

I didn't do much work there - forking the checklist, placing logos, filling boilerplate. There is already https://snapcraft.io/docs/docker-support-interface and there might be specific hacks that are needed on a system level. https://github.com/abitrolly/podman though is a good start and I would be happy to move it to this organization to collaborate.

[rhatdan]

Getting podman into snap is critical, either open a PR to get this into github.com/libpod, or should we look for others?

[abitrolly]

@rhatdan just fork https://github.com/abitrolly/podman under the name like https://github.com/libpod/snapcraft and I will be able to submit PRs so that we can setup CI.

[rhatdan]

Could you open a PR to add this, then we can get it merged and let you fix it. :^)

[haircommander]

I just did it @rhatdan @abitrolly

[mikeroyal]

Hi @lsm5, I can help you guys out. 👍

[rhatdan]

Thanks @mikeroyal

[cevich]

Fix is in #3969

[cevich]

Monitoring for post-merge success:
https://cirrus-ci.com/build/6163886895529984

[cevich]

There's some (unknown/unexpected) problem with #3969 post-merge. I do not see the new 'upload_snap` task being scheduled (link above). However, looking under one of the running tasks, I can verify that indeed:

CIRRUS_BRANCH=master
...
DEST_BRANCH=master

So the execution condition is met for the task. Investigating...

[cevich]

...I believe this is a bug in Cirrus-CI. I've contacted their support about this and to confirm.

[cevich]

@abitrolly FYI ^^^^^^

[abitrolly]

I've just commented about the same in the fixing PR. Nice to see somebody contacted Cirrus CI already. :D

[cevich]

Update: I know this is a bug/limitation in Cirrus-CI (proven via another PR). The issue is all instances of

    only_if: $CIRRUS_BRANCH != $DEST_BRANCH

and

    only_if: $CIRRUS_BRANCH == $DEST_BRANCH

Will not resolve the RHS. I'm not excited about substituting the branch name for every one, since it adds confusing duplication and will break when future branches/forks are created 😖

i.e. the reason why having $DEST_BRANCH is helpful 🤕

So let's wait a bit to see what their support says.

[rhatdan]

@cevich is this ready to merge?

[cevich]

Thanks for the mention, I was just looking for this issue but couldn't find it. I followed up this morning and got a reply straight away from Cirrus: The only_if bug has been fixed.

I'm watching merges to master to confirm the snap pushing task fires as it should...

[cevich]

...okay, I see the upload task here on this post-merge build: https://cirrus-ci.com/build/5739016533573632 so the Cirrus-CI bug is fixed. Now to see if the upload works...

[cevich]

...Oh gosh 615M of packages to install for both test_build_snap and upload_snap, that's ripe for some optimization, even if just to make it rely less on the network/repositories...

[cevich]

Pushing 'podman_0.11.1.1_amd64.snap'

Hrmmm....well that could be a problem 😄

[cevich]

Okay, the intent is functional.

[abitrolly]

Well, it is possible to beef up Docker image a bit to pre-cache binutils and other compiler tools.