systemctl status during podman build
by etc＠balosh.net
Hi, question that I don't understand,
I'd be grateful for explaining or reference to what I should read to get it.
Why during Podman build command
`systemctl enable httpd`
is working
but
`systemctl status httpd`
is not working?
Dockerfile not working:
```
FROM registry.access.redhat.com/ubi8/ubi-init
RUN yum -y install httpd; yum clean all;
RUN systemctl enable httpd;
RUN systemctl status httpd;
```
output of `podman build .`:
```
STEP 2/4: RUN yum -y install httpd; yum clean all;
STEP 1/4: FROM registry.access.redhat.com/ubi8/ubi-init
Build output:
--> 02f6efde590f
--> Using cache 02f6efde590f9fec989c04a01a661d2650b462aeb8e61ad3c0e00aae1b16b1ef
--> Using cache 4f85f566fdee4fd8f5e8058dbf39c5ec9be95a4879d4d9a8c7a77f5b9cadf8a7
STEP 3/4: RUN systemctl enable httpd;
STEP 4/4: RUN systemctl status httpd;
--> 4f85f566fdee
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
```
But!
If I exec into the container when he is running both of them are working.
Working Dockerfile:
```
FROM registry.access.redhat.com/ubi8/ubi-init
RUN yum -y install httpd; yum clean all;
RUN systemctl enable httpd;
```
command:
`podman build . -t x ; podman run -d --name x x ; podman exec -ti x bash -c "systemctl status httpd"`
runs with success
```
STEP 1/3: FROM registry.access.redhat.com/ubi8/ubi-init
STEP 2/3: RUN yum -y install httpd; yum clean all;
--> Using cache 02f6efde590f9fec989c04a01a661d2650b462aeb8e61ad3c0e00aae1b16b1ef
--> 02f6efde590f
STEP 3/3: RUN systemctl enable httpd;
--> Using cache 4f85f566fdee4fd8f5e8058dbf39c5ec9be95a4879d4d9a8c7a77f5b9cadf8a7
COMMIT x
--> 4f85f566fdee
Successfully tagged localhost/x:latest
4f85f566fdee4fd8f5e8058dbf39c5ec9be95a4879d4d9a8c7a77f5b9cadf8a7
214ee56866fc0e7d71b6d152749bdcb65d4e5aadb95dafcebb5661ee20770619
[root@214ee56866fc /]# systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2023-09-19 20:07:22 UTC; 6s ago
Docs: man:httpd.service(8)
Main PID: 30 (httpd)
Status: "Started, listening on: port 80"
Tasks: 213 (limit: 1638)
Memory: 22.3M
CGroup: /system.slice/httpd.service
├─30 /usr/sbin/httpd -DFOREGROUND
├─34 /usr/sbin/httpd -DFOREGROUND
├─35 /usr/sbin/httpd -DFOREGROUND
├─36 /usr/sbin/httpd -DFOREGROUND
└─37 /usr/sbin/httpd -DFOREGROUND
versions:
podman version 4.6.2
on macos ventura 13.5.2
12 hours, 14 minutes
Idmapped volumes in rootful container with userns=auto
by Andre Nathan
Hello
I'm trying to mount a volume in a rootful container using --userns=auto.
This is an NFS volme mounted in the host and then onto the container.
The container should have write access to the volume, so I'm using the
ID mapping options to map the volume owner's UID and GID to 0 in user
namespace and the mount parameters.
These are the NFS exports:
/srv 10.20.3.140/32(rw,fsid=0,no_subtree_check,sync)
/srv/home 10.20.3.140/32(rw,sync,nohide,no_subtree_check)
The NFS server's /home is bind-mounted on /srv/home. The client mounts
the NFS volume on its own /srv:
$ mount | grep nfs
10.20.3.137:/ on /srv type nfs4
(rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.20.3.140,local_lock=none,addr=10.20.3.137)
# ls -l /srv/home
total 4
drwxr-x--- 5 local local 4096 Sep 19 17:36 local
The "local" user's UID and GID (this user was created on both machines
[NFS server and client] with the same UID and GID):
# grep local /etc/passwd
local:x:1000:1000:local:/home/local:/bin/bash
The command I'm using to start the container:
# podman run -d --rm --name foo \
--userns=auto:uidmapping=1000:0:1,gidmapping=1000:0:1 \
-v '/srv/home/local:/home/local:idmap=uids=1000-0-1;gids=1000-0-1' \
quay.io/libpod/alpine_nginx
This results in the following error:
Error: OCI runtime error: crun: mount_setattr `/home/local`: Invalid
argument
Checking the man page for mount_setattr, there are a bunch of reasons
for it to fail with EINVAL, including "MOUNT_ATTR_IDMAP was specified in
attr_clr", so my question is, was this supposed to work?
If it wasn't, is there a way to achieve a writable NFS volume combined
with --userns=auto in a rootful container?
I'm using Ubuntu 22.04 with the Kubic packages:
# podman version
Client: Podman Engine
Version: 4.6.2
API Version: 4.6.2
Go Version: go1.18.1
Built: Thu Jan 1 00:00:00 1970
OS/Arch: linux/amd64
# podman info
host:
arch: amd64
buildahVersion: 1.31.2
cgroupControllers:
- cpuset
- cpu
- io
- memory
- hugetlb
- pids
- rdma
- misc
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon_100:2.1.2~0_amd64
path: /usr/libexec/podman/conmon
version: 'conmon version 2.1.2, commit: '
cpuUtilization:
idlePercent: 99.99
systemPercent: 0.01
userPercent: 0.01
cpus: 48
databaseBackend: boltdb
distribution:
codename: jammy
distribution: ubuntu
version: "22.04"
eventLogger: journald
freeLocks: 2048
hostname: local2
idMappings:
gidmap: null
uidmap: null
kernel: 5.15.0-52-generic
linkmode: dynamic
logDriver: journald
memFree: 263899713536
memTotal: 270361567232
networkBackend: netavark
networkBackendInfo:
backend: netavark
dns:
package: aardvark-dns_1.6.0-0ubuntu22.04+obs34.25_amd64
path: /usr/libexec/podman/aardvark-dns
version: aardvark-dns 1.6.0
package: netavark_1.3.0-0ubuntu22.04+obs22.9_amd64
path: /usr/libexec/podman/netavark
version: netavark 1.8.0-dev
ociRuntime:
name: crun
package: crun_101:1.9-0ubuntu22.04+obs59.11_amd64
path: /usr/bin/crun
version: |-
crun version 1.9
commit: a538ac4ea1ff319bcfe2bf81cb5c6f687e2dc9d3
rundir: /run/crun
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
os: linux
pasta:
executable: ""
package: ""
version: ""
remoteSocket:
path: /run/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
rootless: false
seccompEnabled: true
seccompProfilePath: /usr/share/containers/seccomp.json
selinuxEnabled: false
serviceIsRemote: false
slirp4netns:
executable: ""
package: ""
version: ""
swapFree: 0
swapTotal: 0
uptime: 137h 41m 19.00s (Approximately 5.71 days)
plugins:
authorization: null
log:
- k8s-file
- none
- passthrough
- journald
network:
- bridge
- macvlan
- ipvlan
volume:
- local
registries:
search:
- docker.io
- quay.io
store:
configFile: /etc/containers/storage.conf
containerStore:
number: 0
paused: 0
running: 0
stopped: 0
graphDriverName: overlay
graphOptions:
overlay.mountopt: nodev,metacopy=on
graphRoot: /var/lib/containers/storage
graphRootAllocated: 8340897792
graphRootUsed: 6129999872
graphStatus:
Backing Filesystem: extfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "true"
imageCopyTmpDir: /var/tmp
imageStore:
number: 1
runRoot: /run/containers/storage
transientStore: false
volumePath: /var/lib/containers/storage/volumes
version:
APIVersion: 4.6.2
Built: 0
BuiltTime: Thu Jan 1 00:00:00 1970
GitCommit: ""
GoVersion: go1.18.1
Os: linux
OsArch: linux/amd64
Version: 4.6.2
Thanks in advance,
Andre
14 hours, 32 minutes
Announcement: New Podman pre-release - v4.7.0-rc1
by Lokesh Mandvekar
Happy late Friday all,
Podman v4.7.0-rc1 is now available.
v4.7.0-rc1 brings two shiny new commands:
1. `podman farm` to "farm" out builds to machines running Podman for
different architectures.
2. `podman compose` as a thin wrapper around an external compose provider
such as docker-compose or podman-compose.
along with a host of enhancements to `podman kube`, support for more
Quadlet fields, and lots of bugfixes.
Check out the release page for a full list of features, changes and
bugfixes.
https://github.com/containers/podman/releases/tag/v4.7.0-rc1
Enjoy!
--
Lokesh
Libera, GitLab, GitHub, Fedora: lsm5
Matrix: @lsm5:lsm5.ems.host
GPG: 9E33DD8704CC03E2DEB84D9A1C1EDD7CC7C3A0DD
https://keybase.io/lsm5
2 days, 18 hours
Rootless podman mount capabilities
by Lewis Gaul
Hi,
I'm trying to understand something about how capabilities in rootless
podman work.
How does rootless podman have the capability to set up container mounts
(such as cgroup mounts) given a privileged container itself doesn't? Does
podman deliberately drop caps, or somehow get elevated privileges to do
this?
This is the process tree podman sets up (where bash is the container
entrypoint here):
systemd(1)---conmon(1327421)---bash(1327432)
I'm assuming it's conmon that sets up the container's mounts (via runc in
this case), which is a process running as my user (rootless). How is it
that conmon has the capabilities required (SYS_ADMIN?) to create the
container's cgroup and sysfs mounts but within the container itself this is
not possible?
Thanks for any insight!
Lewis
6 days, 21 hours
Why do use podman machine on Mac?
by Mehdi Haghgoo
The container experience with podman machine on Windows and mac is not optimal because the containers are slow. Mac is a Linux-based OS. So, why can't we create native containers on it as we do on Linux?
That applies to WSL. It's kind of Linux. Why cannot we create native Linux containers on it without resorting to Podman machine and podman clients?
1 week, 6 days
Re: Why do use podman machine on Mac?
by Jason Greene
That’s right Darren. The short answer is “containers are Linux”. The
longer answer is you need two key elements: a Kernel name-spacing facility,
and second a user-land ecosystem. On the former MacOS doesn’t have
something comparable. The closest is App Sandbox, but that is primarily a
syscall/ permission filtering mechanism (something also important for
containers, but only part of the problem). On the latter, this is what we
know of as containers, the user-land is the OS without the kernel, and as
such is very much tied to the kernel implementation. Darwin libraries and
apps use a different ABI and syscall interface than Linux, so basically
every container you use today would be incompatible even if there was
kernel support.
This is the situation with Windows containers (not to be confused with
using Podman on Windows or other container envs that run Linux containers).
Windows containers have kernel support and a win32 user-land, so to produce
them you have to port everything in the image to be native windows code.
They are useful but not anywhere near as predominant, since a big part of
the value is the portability a Linux container brings.
In contrast, WSL2 does run a Linux kernel in a shared VM, and internally it
is using Linux namespaces itself, with all distributions of a user sharing
the same Kernel. They ultimately abandoned the previous syscall emulation
approach since the NT kernel and Linux are just too different and the
behaviors don’t map cleanly. We leverage WSL2 for the Podman on Windows
implementation.
On Sep 7, 2023, at 11:51 AM, Darren Dupre <darren.dupre(a)gmail.com> wrote:
OS X has a Mach kernel and a BSD user land. Don’t think Apple is interested
in adding containers framework to that. I guess someone could write a
kernel extension but it’s a niche use case.
WSL 2 uses a real Linux kernel doesn’t it? But it’s still a VM inside of
Hyper V so I don’t think the performance is any different. WSL 1 is a posix
emulation with binary compatibility but no container support under the
hood.
Correct me if I'm wrong about that.
- Darren
On Thu, Sep 7, 2023 at 11:19 Mehdi Haghgoo via Podman <
podman(a)lists.podman.io> wrote:
> The container experience with podman machine on Windows and mac is not
> optimal because the containers are slow.
> Mac is a Linux-based OS. So, why can't we create native containers on it
> as we do on Linux?
>
> That applies to WSL. It's kind of Linux. Why cannot we create native Linux
> containers on it without resorting to Podman machine and podman clients?
>
>
> _______________________________________________
> Podman mailing list -- podman(a)lists.podman.io
> To unsubscribe send an email to podman-leave(a)lists.podman.io
>
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
1 week, 6 days
Fwd: Re: What to use instead of RemapUsers/RemapUid/RemapGid in Quadlet now?
by jklaiho＠iki.fi
Hi,
(Apologies, my last e-mail I think I accidentally sent to Erik, not the list; missing bits quoted below)
OK, I did not realize that the Remap* commands used --userns behind the scenes, I thought they used --uidmap and --gidmap.
That brings me back to my original need, which I'll reiterate:
"When using a regular host user to run a rootless container, map the container user as the host user."
That's really basic, right? Surely works without PodmanArgs already.
My only addition to that is: "If the container user is root (or sudoed to root), allow it to drop privileges so it can install apt packages."
Still sounds really basic, and where I work, it's really common. If there's problems, we exec into a deployed container and install some troubleshooting tools with apt that the minimalistic image doesn't contain by default. Based on previous discussions, the apt privilege drop needs one extra subordinate UID/GID to be available.
While I'm currently using the Remap* options to achieve these, I'm not married to them – they're just the first thing that I got to work.
I've used PodmanArgs before, but in each case only as a stopgap measure while waiting for an option to appear in Quadlet.
So, hopefully my final question in this thread: is this "map user and allow dropping privileges" scenario doable with the Quadlet UserNS option, or do I need to open an issue?
- JK
> Begin forwarded message:
>
> From: Erik Sjölund <erik.sjolund(a)gmail.com (mailto:erik.sjolund@gmail.com)>
> Date: Tuesday, Sep 05, 2023 at 10:37 AM
> To: Me <jklaiho(a)iki.fi (mailto:jklaiho@iki.fi)>
> Subject: [Podman] Re: What to use instead of RemapUsers/RemapUid/RemapGid in Quadlet now?
>
> Hi,
>
> > Yeah, I'm fairly sure that would work, but am I to understand from your reply
> > that it is not possible to achieve with the UserNS quadlet option the things that the Remap* quadlet options did?
> Correct. It's not possible.
>
> If we just look at the use of --uidmap there is an enormous amount of
> possibilities of how to map those.
> Each container UID can be mapped to an arbitrary "intermediate UID"
> but the mappings must be unique. By that I mean that different
> container UIDs must not be mapped to the same intermediate UID. Also
> different intermediate UIDs must not be mapped to the same container
> UID. The number of possible ways of providing --uidmap corresponds to
> a factorial in mathematics.
>
> See how n! grows with n:
> https://en.wikipedia.org/wiki/Factorial
>
> The argument --userns=keep-id does not carry so much information. For instance
> --userns=keep-id:uid=$uid,gid=$gid
> can only be provided one time and has two numbers.
>
> Another option to consider is
> --userns=auto
> but that option is quite different from --uidmap.
> It provides different functionality.
> The situation is a bit similar to static IP addresses vs dynamic IP
> addresses in DHCP.
>
> I see there is some discussion in
> https://github.com/containers/podman/issues/17984
> and
> https://github.com/containers/podman/pull/17961
>
> Erik
>
>
>
>
> On Mon, Sep 4, 2023 at 9:46 PM jklaiho(a)iki.fi <jklaiho(a)iki.fi> wrote:
> >
> > Hi Erik,
> >
> > Yeah, I'm fairly sure that would work, but am I to understand from your reply that it is not possible to achieve with the UserNS quadlet option the things that the Remap* quadlet options did?
> >
> > If so, why on earth did the Remap* options go away if a) they're still fully supported 'podman run' command-line options, and b) they serve a legit use case that UserNS doesn't fill?
> >
> >
> > - JK
> >
> >
> >
> >
> > On Monday, Sep 04, 2023 at 10:36 PM, Erik Sjölund <erik.sjolund(a)gmail.com> wrote:
> > I think the directive "PodmanArgs" can be used to set podman arguments
> > that don't have any
> > container option counterpart.
> > See man page:
> > https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html
> >
> > Maybe something like this could work?
> > PodmanArgs=--uidmap 0:0:1 --uidmap 100:1:1 --gidmap 0:0:1 --gidmap 65534:1:1
> > (untested)
> >
> > Erik
2 weeks, 1 day
