May 2020 - Podman - Podman List Archives

shouldn't the current directory be the default context for "podman build"?
by Robert P. J. Day 12 Dec '24

12 Dec '24

"man podman-build" suggests that the context argument is optional: SYNOPSIS podman build [options] [context] podman image build [options] [context] ... If no context directory is specified, then Podman will assume the current working directory as the build context, which should contain the Containerfile. but if i have a directory with nothing but a Containerfile, i get: $ podman build Error: no context directory specified, and no containerfile specified $ OTOH, specifying context of current directory: $ podman build . STEP 1: FROM alpine:latest ... etc etc ... thoughts? rday

4 5

image signing
by Hendrik Haddorp 29 Mar '21

29 Mar '21

Hi, is OpenPGP the only supported image signing open supported by podman / skopeo or are there other options? Using OpenGPG works quite fine for me so far but in the end we are trying to sign an image using an IBM 4765 crypto card and so far have not figured out how this can play together. thanks, Hendrk

4 12

Getting Docker Discourse running with Podman
by Philip Rhoades 10 Jan '21

10 Jan '21

People, I can run the discourse image with docker, export the container and import it as an image into podman. The script that manages docker discourse containers is: /var/discourse/launcher and is attached. It would be good if it were possible to just replace all the occurrences of "docker" with "podman", fix version numbers etc and be able to use the script - but can any gurus see dockerisms in the script that will cause podman gotchas for this idea? Thanks, Phil. -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: phil(a)pricom.com.au

3 4

API docs are down
by Josh Berkus 11 Jun '20

11 Jun '20

All, Getting this: ========= Something went wrong... Error downloading https://storage.googleapis.com/libpod-master-releases/swagger-latest-master… NetworkError when attempting to fetch resource. Stack trace ReDoc Version: 2.0.0-rc.28 Commit: 18dbd62 ========= Who has the perms to fix the API doc hosting? -- -- Josh Berkus Kubernetes Community Red Hat OSPO

6 7

Update on Podman V2
by Brent Baude 10 Jun '20

10 Jun '20

Update on Podman V2 A few weeks ago, we made an announcement about the development of Podman V2. In the announcement, we mentioned that the state of upstream code would be jumbled for a while and that we would be temporarily disabling many of our CI/CD tests. The upstream development team has been hard at work, and we are starting to see that work pay off. Today, we are very excited to announce: The local Podman v2 client is complete. It is passing all of its rootfull and rootless system and integration tests. The CI/CID tests have been reenabled upstream and are run with each pull request submission. We are now hard at work finishing up some of the core podman-remote functions. Once those functions are complete, we can then begin to run our podman-remote system and integration tests to catch any regressions. We have re-enabled the autobuilds for Podman v2 in Fedora rawhide. As mentioned earlier, the Podman remote client is not complete, so that binary is temporarily being removed from the RPM. It will be re-added when the remote client is complete. As a corollary, the Windows and OS/X clients are also not being compiled or tested. This will occur once the remote client for Linux is complete. We encourage you to pull the latest upstream Podman code and exercise it with your use cases to help us protect against regressions from Podman v1. We hope to make a full Podman v2.0 release in several weeks, once we are confident it is stable. We look forward to hearing what you think, and please do not hesitate to raise issues and comments on this in our [GitHub repository]( https://github.com/containers/libpod/issues) our Freenode IRC channel `#podman`, or to the Podman mailing list. We’re very excited to bring Podman v2.0 to you as it offers a lot more flexibility through it’s new REST API interface and adds several enhancements to the existing commands. If your project builds on top of Podman, we would especially love to have you test this new version out so we can ensure complete compatibility with Podman v1.0 and address any issues found ASAP. Note: This announcement was first released to the Podman mailing list. If you are not yet a member of that community, please join us by sending an email to [podman-join(a)lists.podman.io](mailto: podman-join(a)lists.podman.io?subject=subscribe) with the word “subscribe” as the title.

3 5

Re: Networking / CNI and firewalld (iptables)
by Gordon Messmer 28 May '20

28 May '20

(moving thread back to list, excuse the lack of trimming) On 5/26/20 1:18 PM, Felder, Christian wrote: >> On 26. May 2020, at 19:43, Gordon Messmer <gordon.messmer(a)gmail.com >> <mailto:gordon.messmer@gmail.com>> wrote: >> >> On 5/26/20 1:51 AM, Felder, Christian wrote: >>> When using podman run -p … DNAT rules in the forward chain are >>> automatically created for allowing traffic to the container/pod. >> >> >> I think you might be mixing up two different things. When I run >> "podman run -p" I see a new rule in the PREROUTING chain of the "nat" >> table. I don't see any rules in the FORWARD chain of the "filter" table. > > Sorry. You’re right and I mixed things up. Indeed there is a new rule > in PREROUTING and this is the rule which bypasses the INPUT chain. > I cannot explicitly configure ports on the INPUT chain as the packets > are forwarded to the CNI-HOSTPORT-DNAT target directly. Because you're doing DNAT, you should be looking at the FORWARD chain, not the INPUT chain. As far as I can tell, testing on my system, the FORWARD chain requires an explicit rule to allow external access to container-published ports. I do have a system that doesn't require an explicit rule, because the destination network is part of firewalld's "trusted" zone. It seems likely that you also have a rule that is allowing forwarded traffic. Can you post the complete output of "iptables -L -nv" and "iptables -L -nv -t nat" somewhere that we can view them, if you don't see the rule now? (ip6tables if you're testing connections from an external host over IPv6, of course) >> There are no DNAT rules in the FORWARD chain. > > I mixed this up with adding an explicit rule to the top of the FORWARD > chain as described in this firewalld issue regarding docker. > https://github.com/firewalld/firewalld/issues/556 > > e.g. firewall-cmd --direct --add-passthrough ipv4 -I FORWARD 1 -s > 10.88.2.0/24 -p tcp --dport 636 -j DROP > > but this wouldn’t help either. Let’s forget about that ;-) > >>> Unfortunately this bypasses the input chain which is usually used to >>> explicitly allowing external traffic for a specific service/port. >>> Using podman run -p … the port is world-wide accessible though. >> >> >> That isn't true on my system, as far as I can tell. >> >> >>> One solution is to just bind to the loopback interface using -p >>> 127.0.0.1:XXX:XXX which will ensure that the port is just available >>> on the >>> host system but on the other hand this does not allow using ssh >>> tunnelling for authorised external access. >> >> >> Why wouldn't it allow ssh tunneling? > > You’re right I can tunnel traffic to it, e.g. using > > ssh -M -S ~/.ssh/ssh-ldap3 -f root@centos-8 -L 6636:localhost:636 -N > > which would allow me to access the container from my system on port > 6636 which runs on port 636 on the host centos-8. > > > > My conclusion: > > It’s probably the easiest option to publish to loopback if I wan’t to > limit access just to the host whereas publishing to all interfaces > would still allow external traffic as well without explicitly > configuring the firewall because of the PREROUTING mechanism. > I can still ssh-tunnel traffic to that service when binding to loopback. > > Imho people may not be aware of the INPUT chain being bypassed.

2 4

Integrate Podman in Java integration test with TestContainer
by sylvain.bonnemaison＠ti-mm.com 27 May '20

27 May '20

Hi, In order to use TestContainer framework, I need to use the new REST API. Does io.podman linux daemon provide the service ? Regards.

3 10

Networking / CNI and firewalld (iptables)
by Felder, Christian 26 May '20

26 May '20

Hello, I hope this message finds you guys well. I’ve a question regarding CNI and podman run’s publish flag (-p). When using podman run -p … DNAT rules in the forward chain are automatically created for allowing traffic to the container/pod. Unfortunately this bypasses the input chain which is usually used to explicitly allowing external traffic for a specific service/port. Using podman run -p … the port is world-wide accessible though. One solution is to just bind to the loopback interface using -p 127.0.0.1:XXX:XXX which will ensure that the port is just available on the host system but on the other hand this does not allow using ssh tunnelling for authorised external access. What are best practices for having a container's/pod’s port exposed to the host but having explicitly control whether this should be accessible world-wide or not? Just note I am using podman on CentOS 8 (podman-1.6.4-4.module_el8.1.0+298+41f9343a.src.rpm) Thanks in advance. Christian

3 3

Where is the doc?
by Álvaro Castillo 26 May '20

26 May '20

Hi, I want to access to doc of podman but It's does not exist (?) http://docs.podman.io/en/v1.6.4/Introduction.html Cheers!

6 27

Building a Podman Equivalent to CIS Benchmark for Docker
by Scott McCarty 15 May '20

15 May '20

All, I got a really good question on my blog [1] and I'm wondering if anybody else has started down this path? In a nutshell, the Docker CIS benchmark looks for files in certain place, etc so it's really targeted towards Docker, but I don't see any reason why we couldn't take it and build an equivalent for Podman. Not sure when I might have time to tackle this, but figured it was worth seeing if anybody had started any work around this? [1]: http://crunchtools.com/meeting-cis-benchmark/ Best Regards Scott M -- -- Moving Wordpress, Mediawiki and Request Tracker into containers: http://crunchtools.com/a-hackers-guide-to-moving-linux-services-into-contai… -- Scott McCarty Product Management - Containers, Red Hat Enterprise Linux & OpenShift Email: smccarty(a)redhat.com Phone: 312-660-3535 Cell: 330-807-1043 Web: http://crunchtools.com Using Azure Pipelines with Red Hat Universal Base Image and Quay.io: https://red.ht/2TvYo3Y

1 0