<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Podman on *scratch*</title>
    <link>https://www.scrivano.org/tags/podman/</link>
    <description>Recent content in Podman on *scratch*</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Sat, 06 Jun 2026 10:03:54 +0000</lastBuildDate>
    <atom:link href="https://www.scrivano.org/tags/podman/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Why do I have two /sys/fs/cgroup in my container</title>
      <link>https://www.scrivano.org/posts/2024-1-26-why-do-i-have-two-cgroup/</link>
      <pubDate>Fri, 26 Jan 2024 14:12:00 +0200</pubDate>
      <guid>https://www.scrivano.org/posts/2024-1-26-why-do-i-have-two-cgroup/</guid>
      <description>&lt;p&gt;It happened a few times in the past that users wonder why they see two &lt;code&gt;/sys/fs/cgroup&lt;/code&gt; mounts in their unprivileged container. When working with unprivileged containers in Podman, users often notice two &lt;code&gt;/sys/fs/cgroup&lt;/code&gt; mounts if the container is not using a new network namespace. The duplication is not a bug but an intentional consequence of how the kernel handles bind mounts that cross user namespace boundaries, combined with the need to provide the container with a writable cgroup view that is scoped to its own slice.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Run containers without pulling images</title>
      <link>https://www.scrivano.org/2019/10/24/run-containers-without-pulling-images/</link>
      <pubDate>Thu, 24 Oct 2019 18:37:23 +0000</pubDate>
      <guid>https://www.scrivano.org/2019/10/24/run-containers-without-pulling-images/</guid>
      <description>&lt;p&gt;CRFS is a Google project that aims at running a container without pre-pulling the image first. The key insight is that in practice a container process only accesses a small fraction of the files in its image, so fetching the entire image before startup wastes both time and disk space. CRFS achieves this through the stargz (Seekable tar.gz) format, which restructures each compressed layer so that individual files can be fetched on demand rather than requiring the entire tarball to be downloaded and extracted upfront.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Rootless resources management with Podman on Fedora 30</title>
      <link>https://www.scrivano.org/2019/05/12/rootless-resources-management-with-podman-on-fedora-30/</link>
      <pubDate>Sun, 12 May 2019 20:36:59 +0000</pubDate>
      <guid>https://www.scrivano.org/2019/05/12/rootless-resources-management-with-podman-on-fedora-30/</guid>
      <description>&lt;p&gt;I have finally opened some PRs for conmon and libpod that enable resources management for Podman rootless containers on Fedora 30 when using crun. This builds on the cgroups v2 delegation support added to crun earlier: Fedora 30 ships a kernel and systemd new enough to support the unified cgroup hierarchy, so with a single kernel command-line option and a small systemd drop-in, unprivileged users can now set memory and CPU limits on their containers without root access.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Rootless Podman from upstream on CentOS 7</title>
      <link>https://www.scrivano.org/2018/10/12/rootless-podman-from-upstream-on-centos-7/</link>
      <pubDate>Fri, 12 Oct 2018 09:14:21 +0000</pubDate>
      <guid>https://www.scrivano.org/2018/10/12/rootless-podman-from-upstream-on-centos-7/</guid>
      <description>&lt;p&gt;This is the recipe I use to build podman from upstream on Centos 7 and use rootless containers. We need an updated version of the shadow utils as newuidmap and newgidmap are not present on Centos 7. The shadow utils are installed using “make install” which is not the clean way to install packages and it also overwrites the existing binaries, but it is fine on a development system. Podman is already present on Centos 7 and in facts we install it so we don’t have to worry about conmon and other dependencies.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Network namespaces for unprivileged users</title>
      <link>https://www.scrivano.org/2018/08/05/network-namespaces-for-unprivileged-users/</link>
      <pubDate>Sun, 05 Aug 2018 13:54:44 +0000</pubDate>
      <guid>https://www.scrivano.org/2018/08/05/network-namespaces-for-unprivileged-users/</guid>
      <description>&lt;p&gt;A couple of weekends ago I’ve played with libslirp and put together &lt;a href=&#34;https://github.com/giuseppe/slirp-forwarder&#34;&gt;slirp-forwarder&lt;/a&gt;. The challenge with network namespaces for unprivileged users is that creating TAP or TUN devices requires privileges in the host network namespace. SliRP sidesteps this by emulating a full TCP/IP stack entirely in user space, so the helper process can forward traffic to the outside world using only normal socket operations, without needing any elevated capability.&lt;/p&gt;&#xA;&lt;p&gt;SliRP emulates in userspace a TCP/IP stack. It can be used to circumvent the limitation of creating TAP/TUN devices in the host namespace for an unprivileged user. The program could run in the host namespace, receive messages from the network namespace where a TAP device is configured, and forward them to the outside world using unprivileged operations such as opening another connection to the destination host. Privileged operations are still not possible outside of the emulated network, as the helper program doesn’t gain any additional privilege that running as an unprivileged user.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
