A tool that facilitates building OCI images

buildah logo

Buildah - a tool that facilitates building Open Container Initiative (OCI) container images

Go Report Card

The Buildah package provides a command line tool that can be used to

  • create a working container, either from scratch or using an image as a starting point
  • create an image, either from a working container or via the instructions in a Dockerfile
  • images can be built in either the OCI image format or the traditional upstream docker image format
  • mount a working container's root filesystem for manipulation
  • unmount a working container's root filesystem
  • use the updated contents of a container's root filesystem as a filesystem layer to create a new image
  • delete a working container or an image
  • rename a local container

Buildah Information for Developers

For blogs, release announcements and more, please checkout the buildah.io website!

Buildah Demos

Changelog

Contributing

Development Plan

Installation notes

Troubleshooting Guide

Tutorials

Buildah and Podman relationship

Buildah and Podman are two complementary open-source projects that are available on most Linux platforms and both projects reside at GitHub.com with Buildah here and Podman here. Both, Buildah and Podman are command line tools that work on Open Container Initiative (OCI) images and containers. The two projects differentiate in their specialization.

Buildah specializes in building OCI images. Buildah's commands replicate all of the commands that are found in a Dockerfile. This allows building images with and without Dockerfiles while not requiring any root privileges. Buildah’s ultimate goal is to provide a lower-level coreutils interface to build images. The flexibility of building images without Dockerfiles allows for the integration of other scripting languages into the build process. Buildah follows a simple fork-exec model and does not run as a daemon but it is based on a comprehensive API in golang, which can be vendored into other tools.

Podman specializes in all of the commands and functions that help you to maintain and modify OCI images, such as pulling and tagging. It also allows you to create, run, and maintain those containers created from those images. For building container images via Dockerfiles, Podman uses Buildah's golang API and can be installed independently from Buildah.

A major difference between Podman and Buildah is their concept of a container. Podman allows users to create "traditional containers" where the intent of these containers is to be long lived. While Buildah containers are really just created to allow content to be added back to the container image. An easy way to think of it is the buildah run command emulates the RUN command in a Dockerfile while the podman run command emulates the docker run command in functionality. Because of this and their underlying storage differences, you can not see Podman containers from within Buildah or vice versa.

In short, Buildah is an efficient way to create OCI images while Podman allows you to manage and maintain those images and containers in a production environment using familiar container cli commands. For more details, see the Container Tools Guide.

Example

From ./examples/lighttpd.sh:

$ cat > lighttpd.sh <<"EOF"
#!/usr/bin/env bash -x

ctr1=$(buildah from "${1:-fedora}")

## Get all updates and install our minimal httpd server
buildah run "$ctr1" -- dnf update -y
buildah run "$ctr1" -- dnf install -y lighttpd

## Include some buildtime annotations
buildah config --annotation "com.example.build.host=$(uname -n)" "$ctr1"

## Run our server and expose the port
buildah config --cmd "/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf" "$ctr1"
buildah config --port 80 "$ctr1"

## Commit this container to an image name
buildah commit "$ctr1" "${2:-$USER/lighttpd}"
EOF

$ chmod +x lighttpd.sh
$ sudo ./lighttpd.sh

Commands

Command Description
buildah-add(1) Add the contents of a file, URL, or a directory to the container.
buildah-bud(1) Build an image using instructions from Dockerfiles.
buildah-commit(1) Create an image from a working container.
buildah-config(1) Update image configuration settings.
buildah-containers(1) List the working containers and their base images.
buildah-copy(1) Copies the contents of a file, URL, or directory into a container's working directory.
buildah-from(1) Creates a new working container, either from scratch or using a specified image as a starting point.
buildah-images(1) List images in local storage.
buildah-info(1) Display Buildah system information.
buildah-inspect(1) Inspects the configuration of a container or image.
buildah-mount(1) Mount the working container's root filesystem.
buildah-pull(1) Pull an image from the specified location.
buildah-push(1) Push an image from local storage to elsewhere.
buildah-rename(1) Rename a local container.
buildah-rm(1) Removes one or more working containers.
buildah-rmi(1) Removes one or more images.
buildah-run(1) Run a command inside of the container.
buildah-tag(1) Add an additional name to a local image.
buildah-umount(1) Unmount a working container's root file system.
buildah-unshare(1) Launch a command in a user namespace with modified ID mappings.
buildah-version(1) Display the Buildah Version Information

Future goals include:

  • more CI tests
  • additional CLI commands (?)
Owner
Containers
Open Repository for Container Tools
Containers
Comments
  • can buildah run in a docker container?

    can buildah run in a docker container?

    I'd like to use buildah inside a an OpenShift / Kubernetes pod. So I'm testing buildah from inside a docker container however buildah bud and buildah run commands fail with:

    ERRO[0000] 'overlay' is not supported over overlay
    ERRO[0000] 'overlay' is not supported over overlay
    ERRO[0000] backing file system is unsupported for this graph driver
    backing file system is unsupported for this graph driver
    
  • Cirrus: Migrate off of PAPR + Improve testing

    Cirrus: Migrate off of PAPR + Improve testing

    Replace PAPR with 'in_podman' / Cirrus-CI based test. Prepare the groundwork for replacing Homu and Travis with Bors + VM-based testing (set "optional" in this PR). Once this PR is merged, until #2115 is merged: maintainers must carefully/manually merge PRs one-by-one (since the Homu bot will be disabled).

  • buildah bud --cache-from functionality needed

    buildah bud --cache-from functionality needed

    Description buildah bud --cache-from is missing and needs to be provided. This is functionality that Docker has.

    #599 is the parent issue for this issue.

    Output of buildah version:

    Buildah v0.16

  • seccomp: config provided but seccomp not supported

    seccomp: config provided but seccomp not supported

    Description

    When running a command in a container, the process exits with the error :

    container_linux.go:348: starting container process caused "seccomp: config provided but seccomp not supported"
    

    I am not exactly sure it is a bug from buildah itself. I guess I have to somehow enable seccomp, but I don't know how, and it seems to be already enabled :

    $ zgrep SECCOMP /proc/config.gz
    CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
    CONFIG_SECCOMP_FILTER=y
    CONFIG_SECCOMP=y
    

    So it might be an issue completely unrelated to seccomp altogether, but I lack the general knowledge to understand what is wrong, or where to look for clues.

    Steps to reproduce the issue:

    $ sudo buildah from fedora
    Getting image source signatures
    Copying blob sha256:a8ee583972c2295bb76704d4defe5116d5e4dd7ba3767aaa2cc8fcf71088ee06
     82.80 MiB / 82.80 MiB [===================================================] 26s
    Copying config sha256:422dc563ca3260ad9ef5c47a1c246f5065d7f177ce51f4dd208efd82967ff182
     2.29 KiB / 2.29 KiB [======================================================] 0s
    Writing manifest to image destination
    Storing signatures
    fedora-working-container
    $ sudo buildah images
    IMAGE ID             IMAGE NAME                                               CREATED AT             SIZE
    422dc563ca32         docker.io/library/fedora:latest                          Nov 14, 2017 21:07     251 MB
    $ sudo buildah containers
    CONTAINER ID  BUILDER  IMAGE ID     IMAGE NAME                       CONTAINER NAME
    5062084a1ad7     *     422dc563ca32 docker.io/library/fedora:latest  fedora-working-container
    $ sudo buildah run fedora-working-container sh
    container_linux.go:348: starting container process caused "seccomp: config provided but seccomp not supported"
    

    Output of rpm -q buildah or apt list buildah:

    I'm running Arch, and used yaourt to install buildah from git using this PKGBUILD. It builds buildah from the source of this repo, and as I installed it just now (to be sure it isn't an issue already fixed), the version referes to the very last commit (46c1a54) as of now.

    $ pacman -Q | grep buildah
    buildah-git r478.46c1a54-1
    

    Output of buildah version:

    $ buildah -v                                                                                                                                                 
    buildah version 0.11 (image-spec 1.0.0, runtime-spec 1.0.0)
    

    Output of cat /etc/*release:

    LSB_VERSION=1.4
    DISTRIB_ID=Arch
    DISTRIB_RELEASE=rolling
    DISTRIB_DESCRIPTION="Arch Linux"
    NAME="Arch Linux"
    PRETTY_NAME="Arch Linux"
    ID=arch
    ID_LIKE=archlinux
    ANSI_COLOR="0;36"
    HOME_URL="https://www.archlinux.org/"
    SUPPORT_URL="https://bbs.archlinux.org/"
    BUG_REPORT_URL="https://bugs.archlinux.org/"
    

    Output of uname -a:

    Linux etndev 4.14.14-1-ARCH #1 SMP PREEMPT Fri Jan 19 18:42:04 UTC 2018 x86_64 GNU/Linux
    

    Output of cat /etc/containers/storage.conf:

    cat: /etc/containers/storage.conf: No such file or directory
    
  • invalid tar header: unknown

    invalid tar header: unknown

    GKE cluster (1.12.7-gke.10) using the node image cos_containerd is failing to run containers built with buildah and pushed to GCR.

    Failed to pull image "gcr.io/gke-clusters/testing:latest": rpc error: code = Unknown desc = failed to pull and unpack image "gcr.io/gke-clusters/testing:latest": failed to unpack image on snapshotter overlayfs: failed to extract layer sha256:f1b5933fe4b5f49bbe8258745cf396afe07e625bdab3168e364daf7c956b6b81: mount callback failed on /var/lib/containerd/tmpmounts/containerd-mount799987480: archive/tar: invalid tar header: unknown
    
    ➜ cat Dockerfile 
    FROM alpine
    RUN date
    
    Projects/cluster1/test on 🐳 v18.09.5 
    ➜ buildah version
    Version:         1.8.2
    Go Version:      go1.12.4
    Image Spec:      1.0.0
    Runtime Spec:    1.0.0
    CNI Spec:        0.4.0
    libcni Version:  v0.7.0-rc2
    Git Commit:      e23314b1
    Built:           Fri May 10 09:23:56 2019
    OS/Arch:         linux/amd64
    
    Projects/cluster1/test on 🐳 v18.09.5 
    ➜ cat test.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: test
      namespace: default
    spec:
      containers:
      - name: test
        image: gcr.io/gke-clusters/testing:latest
    

    Steps to reproduce the issue:

    1. Build an image using the Dockerfile above with buildah
    2. Push to GCR (or maybe any other container registry?)
    3. kubectl apply -f test.yaml on k8s cluster
    4. Use kubectl describe to view warning event

    Describe the results you received:

    Pod fails to spin up.

    Describe the results you expected:

    I'd expect the pod to pull and run the container.

    Output of rpm -q buildah or apt list buildah:

    ➜ yay -s buildah
    2 aur/buildah-git r1330.391a5bea-1 (+1 0.00%) 
        A tool which facilitates building OCI images
    1 community/buildah 1.8.2-1 (5.4 MiB 23.6 MiB) (Installed)
        A tool which facilitates building OCI images
    ==> Packages to install (eg: 1 2 3, 1-3 or ^4)
    ==> ^C
    

    Output of buildah version:

    Version:         1.8.2
    Go Version:      go1.12.4
    Image Spec:      1.0.0
    Runtime Spec:    1.0.0
    CNI Spec:        0.4.0
    libcni Version:  v0.7.0-rc2
    Git Commit:      e23314b1
    Built:           Fri May 10 09:23:56 2019
    OS/Arch:         linux/amd64
    

    Output of cat /etc/*release:

    NAME="Arch Linux"
    PRETTY_NAME="Arch Linux"
    ID=arch
    BUILD_ID=rolling
    ANSI_COLOR="0;36"
    HOME_URL="https://www.archlinux.org/"
    DOCUMENTATION_URL="https://wiki.archlinux.org/"
    SUPPORT_URL="https://bbs.archlinux.org/"
    BUG_REPORT_URL="https://bugs.archlinux.org/"
    

    Output of uname -a:

    Linux dell 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20 15:00:46 UTC 2019 x86_64 GNU/Linux
    

    Output of cat /etc/containers/storage.conf:

    # This file is is the configuration file for all tools
    # that use the containers/storage library.
    # See man 5 containers-storage.conf for more information
    # The "container storage" table contains all of the server options.
    [storage]
    
    # Default Storage Driver
    driver = "overlay"
    
    # Temporary storage location
    runroot = "/var/run/containers/storage"
    
    # Primary Read/Write location of container storage
    graphroot = "/var/lib/containers/storage"
    
    [storage.options]
    # Storage options to be passed to underlying storage drivers
    
    # AdditionalImageStores is used to pass paths to additional Read/Only image stores
    # Must be comma separated list.
    additionalimagestores = [
    ]
    
    # Size is used to set a maximum size of the container image.  Only supported by
    # certain container storage drivers.
    size = ""
    
    # Path to an helper program to use for mounting the file system instead of mounting it
    # directly.
    #mount_program = "/usr/bin/fuse-overlayfs"
    
    # OverrideKernelCheck tells the driver to ignore kernel checks based on kernel version
    override_kernel_check = "true"
    
    # mountopt specifies comma separated list of extra mount options
    mountopt = "nodev"
    
    # Remap-UIDs/GIDs is the mapping from UIDs/GIDs as they should appear inside of
    # a container, to UIDs/GIDs as they should appear outside of the container, and
    # the length of the range of UIDs/GIDs.  Additional mapped sets can be listed
    # and will be heeded by libraries, but there are limits to the number of
    # mappings which the kernel will allow when you later attempt to run a
    # container.
    #
    # remap-uids = 0:1668442479:65536
    # remap-gids = 0:1668442479:65536
    
    # Remap-User/Group is a name which can be used to look up one or more UID/GID
    # ranges in the /etc/subuid or /etc/subgid file.  Mappings are set up starting
    # with an in-container ID of 0 and the a host-level ID taken from the lowest
    # range that matches the specified name, and using the length of that range.
    # Additional ranges are then assigned, using the ranges which specify the
    # lowest host-level IDs first, to the lowest not-yet-mapped container-level ID,
    # until all of the entries have been used for maps.
    #
    # remap-user = "storage"
    # remap-group = "storage"
    
    [storage.options.thinpool]
    # Storage Options for thinpool
    
    # autoextend_percent determines the amount by which pool needs to be
    # grown. This is specified in terms of % of pool size. So a value of 20 means
    # that when threshold is hit, pool will be grown by 20% of existing
    # pool size.
    # autoextend_percent = "20"
    
    # autoextend_threshold determines the pool extension threshold in terms
    # of percentage of pool size. For example, if threshold is 60, that means when
    # pool is 60% full, threshold has been hit.
    # autoextend_threshold = "80"
    
    # basesize specifies the size to use when creating the base device, which
    # limits the size of images and containers.
    # basesize = "10G"
    
    # blocksize specifies a custom blocksize to use for the thin pool.
    # blocksize="64k"
    
    # directlvm_device specifies a custom block storage device to use for the
    # thin pool. Required if you setup devicemapper.
    # directlvm_device = ""
    
    # directlvm_device_force wipes device even if device already has a filesystem.
    # directlvm_device_force = "True"
    
    # fs specifies the filesystem type to use for the base device.
    # fs="xfs"
    
    # log_level sets the log level of devicemapper.
    # 0: LogLevelSuppress 0 (Default)
    # 2: LogLevelFatal
    # 3: LogLevelErr
    # 4: LogLevelWarn
    # 5: LogLevelNotice
    # 6: LogLevelInfo
    # 7: LogLevelDebug
    # log_level = "7"
    
    # min_free_space specifies the min free space percent in a thin pool require for
    # new device creation to succeed. Valid values are from 0% - 99%.
    # Value 0% disables
    # min_free_space = "10%"
    
    # mkfsarg specifies extra mkfs arguments to be used when creating the base.
    # device.
    # mkfsarg = ""
    
    # use_deferred_removal marks devicemapper block device for deferred removal.
    # If the thinpool is in use when the driver attempts to remove it, the driver 
    # tells the kernel to remove it as soon as possible. Note this does not free
    # up the disk space, use deferred deletion to fully remove the thinpool.
    # use_deferred_removal = "True"
    
    # use_deferred_deletion marks thinpool device for deferred deletion.
    # If the device is busy when the driver attempts to delete it, the driver
    # will attempt to delete device every 30 seconds until successful.
    # If the program using the driver exits, the driver will continue attempting
    # to cleanup the next time the driver is used. Deferred deletion permanently
    # deletes the device and all data stored in device will be lost.
    # use_deferred_deletion = "True"
    
    # xfs_nospace_max_retries specifies the maximum number of retries XFS should
    # attempt to complete IO when ENOSPC (no space) error is returned by
    # underlying storage device.
    # xfs_nospace_max_retries = "0"
    
    # If specified, use OSTree to deduplicate files with the overlay backend
    ostree_repo = ""
    
    # Set to skip a PRIVATE bind mount on the storage home directory.  Only supported by
    # certain container storage drivers
    skip_mount_home = "false"
    
  • podman build tags images in the local registry with a leading localhost/ and docker does not

    podman build tags images in the local registry with a leading localhost/ and docker does not

    Description

    Does podman build have the goal of being a drop-in replacement for docker? If not, feel free to close this issue. If so, the issue is that podman build -t bodhi-ci/f27 tags the resulting image into the local engine with a leading localhost/ in the repository name, and docker does not do this. This results in a difference in how the image must be referenced later when running docker/podman run, because docker run… bodhi-ci/f27 will work, but podman run… bodhi-ci/f27 will not work (and will try to find that image in a variety of external registries).

    Steps to reproduce the issue:

    1. Build a Dockerfile with podman and docker, and use the -t flag.
    2. For example, I've built my Bodhi CI images with -t bodhi-ci/f27 in the examples shown below.

    Describe the results you received:

    $ sudo docker images
    REPOSITORY                          TAG                 IMAGE ID            CREATED             SIZE
    bodhi-ci/f27                        latest              4668aacb1a2a        11 hours ago        1.29 GB
    $ sudo podman images
    REPOSITORY                          TAG      IMAGE ID       CREATED          SIZE
    localhost/bodhi-ci/f27              latest   351ffa92bc74   2 minutes ago    1.34GB
    

    Describe the results you expected:

    $ sudo podman images
    REPOSITORY                          TAG      IMAGE ID       CREATED          SIZE
    bodhi-ci/f27              latest   351ffa92bc74   2 minutes ago    1.34GB
    

    Output of rpm -q buildah or apt list buildah:

    Buildah is not installed, but the text at https://github.com/containers/libpod/issues/new said to file issues with podman build here.

    Output of buildah version:

    See above.

    Output of cat /etc/*release:

    $ cat /etc/redhat-release 
    Fedora release 30 (Rawhide)
    

    Output of uname -a:

    Linux host.example.com 4.19.0-0.rc3.git3.1.fc30.x86_64 #1 SMP Fri Sep 14 18:31:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
    

    Output of cat /etc/containers/storage.conf:

    # This file is is the configuration file for all tools
    # that use the containers/storage library.
    # See man 5 containers-storage.conf for more information
    # The "container storage" table contains all of the server options.
    [storage]
    
    # Default Storage Driver
    driver = "overlay"
    
    # Temporary storage location
    runroot = "/var/run/containers/storage"
    
    # Primary Read/Write location of container storage
    graphroot = "/var/lib/containers/storage"
    
    [storage.options]
    # Storage options to be passed to underlying storage drivers
    
    # AdditionalImageStores is used to pass paths to additional Read/Only image stores
    # Must be comma separated list.
    additionalimagestores = [
    ]
    
    # Size is used to set a maximum size of the container image.  Only supported by
    # certain container storage drivers.
    size = ""
    
    # Path to an helper program to use for mounting the file system instead of mounting it
    # directly.
    #mount_program = "/usr/bin/fuse-overlayfs"
    
    # OverrideKernelCheck tells the driver to ignore kernel checks based on kernel version
    override_kernel_check = "true"
    
    # mountopt specifies comma separated list of extra mount options
    mountopt = "nodev"
    
    # Remap-UIDs/GIDs is the mapping from UIDs/GIDs as they should appear inside of
    # a container, to UIDs/GIDs as they should appear outside of the container, and
    # the length of the range of UIDs/GIDs.  Additional mapped sets can be listed
    # and will be heeded by libraries, but there are limits to the number of
    # mappings which the kernel will allow when you later attempt to run a
    # container.
    #
    # remap-uids = 0:1668442479:65536
    # remap-gids = 0:1668442479:65536
    
    # Remap-User/Group is a name which can be used to look up one or more UID/GID
    # ranges in the /etc/subuid or /etc/subgid file.  Mappings are set up starting
    # with an in-container ID of 0 and the a host-level ID taken from the lowest
    # range that matches the specified name, and using the length of that range.
    # Additional ranges are then assigned, using the ranges which specify the
    # lowest host-level IDs first, to the lowest not-yet-mapped container-level ID,
    # until all of the entries have been used for maps.
    #
    # remap-user = "storage"
    # remap-group = "storage"
    
    [storage.options.thinpool]
    # Storage Options for thinpool
    
    # autoextend_percent determines the amount by which pool needs to be
    # grown. This is specified in terms of % of pool size. So a value of 20 means
    # that when threshold is hit, pool will be grown by 20% of existing
    # pool size.
    # autoextend_percent = "20"
    
    # autoextend_threshold determines the pool extension threshold in terms
    # of percentage of pool size. For example, if threshold is 60, that means when
    # pool is 60% full, threshold has been hit.
    # autoextend_threshold = "80"
    
    # basesize specifies the size to use when creating the base device, which
    # limits the size of images and containers.
    # basesize = "10G"
    
    # blocksize specifies a custom blocksize to use for the thin pool.
    # blocksize="64k"
    
    # directlvm_device specifies a custom block storage device to use for the
    # thin pool. Required if you setup devicemapper.
    # directlvm_device = ""
    
    # directlvm_device_force wipes device even if device already has a filesystem.
    # directlvm_device_force = "True"
    
    # fs specifies the filesystem type to use for the base device.
    # fs="xfs"
    
    # log_level sets the log level of devicemapper.
    # 0: LogLevelSuppress 0 (Default)
    # 2: LogLevelFatal
    # 3: LogLevelErr
    # 4: LogLevelWarn
    # 5: LogLevelNotice
    # 6: LogLevelInfo
    # 7: LogLevelDebug
    # log_level = "7"
    
    # min_free_space specifies the min free space percent in a thin pool require for
    # new device creation to succeed. Valid values are from 0% - 99%.
    # Value 0% disables
    # min_free_space = "10%"
    
    # mkfsarg specifies extra mkfs arguments to be used when creating the base.
    # device.
    # mkfsarg = ""
    
    # use_deferred_removal marks devicemapper block device for deferred removal.
    # If the thinpool is in use when the driver attempts to remove it, the driver 
    # tells the kernel to remove it as soon as possible. Note this does not free
    # up the disk space, use deferred deletion to fully remove the thinpool.
    # use_deferred_removal = "True"
    
    # use_deferred_deletion marks thinpool device for deferred deletion.
    # If the device is busy when the driver attempts to delete it, the driver
    # will attempt to delete device every 30 seconds until successful.
    # If the program using the driver exits, the driver will continue attempting
    # to cleanup the next time the driver is used. Deferred deletion permanently
    # deletes the device and all data stored in device will be lost.
    # use_deferred_deletion = "True"
    
    # xfs_nospace_max_retries specifies the maximum number of retries XFS should
    # attempt to complete IO when ENOSPC (no space) error is returned by
    # underlying storage device.
    # xfs_nospace_max_retries = "0"
    
    # If specified, use OSTree to deduplicate files with the overlay backend
    ostree_repo = ""
    
    # Set to skip a PRIVATE bind mount on the storage home directory.  Only supported by
    # certain container storage drivers
    skip_mount_home = "false"
    
  • Cirrus: Use images from automation_images

    Cirrus: Use images from automation_images

    Depends on: #2885

    What type of PR is this?

    /kind deprecation

    What this PR does / why we need it:

    Previously, VM Images were built from a side-band process tacked onto containers/podman automation. This has recently been split off into it's own repository containers/automation_images. This PR makes use of freshly built images produced using the new workflow. Additionally, to support testing of a runc -> crun transition, both packages are installed in the newly referenced images.

    How to verify it

    Automated tests will pass

    Which issue(s) this PR fixes:

    None

    Special notes for your reviewer:

    None

    Does this PR introduce a user-facing change?

    None

  • Supporting building multi-platform images (podman buildx)

    Supporting building multi-platform images (podman buildx)

    Description

    Supporting building multi-platform images (podman buildx)

    Detail

    This ticket is a request for feature, originally from https://github.com/containers/libpod/issues/3063 .

    docker buildx [1][2] is to enable building and running multi-platform container images. I would like to see that podman has like the feature.

    $ docker buildx build --platform linux/arm64 ...
    

    RHEL 8 started supporting multi arch including ARM 64 bit. Quay 3 started supporting multi arch including ARM 64-bit. [3] So, it might be a good timing for podman to support this feature.

    docker buildx is using QEMU internally to do it. As an another way to achieve this, there is qemu-user-static [4] also using QEMU.

    According to the docker buildx's article [2], maybe both have similar logic in it.

    This fast and lightweight container OS comes packaged with the QEMU emulator, and comes pre-configured with binfmt_misc to run binaries of any supported architecture.

    But docker buildx looks much easier than qemu-user-static.

    • [1] docker buildx GitHub: https://github.com/docker/buildx#building-multi-platform-images
    • [2] docker buildx article: https://engineering.docker.com/2019/04/multi-arch-images/
    • [3] https://www.redhat.com/en/blog/introducing-red-hat-quay-3-registry-your-linux-and-windows-containers
    • [4] qemu-user-static: https://github.com/multiarch/qemu-user-static
  • Fail to build Dockerfile: unpacking of archive failed on file /etc/hosts: cpio: rename

    Fail to build Dockerfile: unpacking of archive failed on file /etc/hosts: cpio: rename

    Description

    I am trying to build a Dockerfile. It builds ok with Docker but fails with buildah.

    Steps to reproduce the issue:

    1. Dockerfile: http://pastebin.test.redhat.com/652536
    2. podman build -t install-test .

    Describe the results you received: Error logs: http://pastebin.test.redhat.com/652525

    Describe the results you expected: Expected it to build (works with Docker).

    Output of rpm -q buildah or apt list buildah:

    buildah-1.3-1.git4888163.fc28.x86_64
    

    Output of buildah version:

    Version:         1.3
    Go Version:      go1.10.3
    Image Spec:      1.0.0
    Runtime Spec:    1.0.0
    CNI Spec:        0.3.1
    libcni Version:  v0.6.0
    Git Commit:      4888163
    Built:           Sun Aug  5 07:31:55 2018
    OS/Arch:         linux/amd64
    

    Output of cat /etc/*release:

    Fedora release 28 (Twenty Eight)
    NAME=Fedora
    VERSION="28 (Workstation Edition)"
    ID=fedora
    VERSION_ID=28
    PLATFORM_ID="platform:f28"
    PRETTY_NAME="Fedora 28 (Workstation Edition)"
    ANSI_COLOR="0;34"
    CPE_NAME="cpe:/o:fedoraproject:fedora:28"
    HOME_URL="https://fedoraproject.org/"
    SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
    BUG_REPORT_URL="https://bugzilla.redhat.com/"
    REDHAT_BUGZILLA_PRODUCT="Fedora"
    REDHAT_BUGZILLA_PRODUCT_VERSION=28
    REDHAT_SUPPORT_PRODUCT="Fedora"
    REDHAT_SUPPORT_PRODUCT_VERSION=28
    PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
    VARIANT="Workstation Edition"
    VARIANT_ID=workstation
    Fedora release 28 (Twenty Eight)
    Fedora release 28 (Twenty Eight)
    

    Output of uname -a:

    Linux localhost.localdomain 4.18.5-200.fc28.x86_64 #1 SMP Tue Sep 4 15:56:14 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
    

    Output of cat /etc/containers/storage.conf:

    # This file is is the configuration file for all tools
    # that use the containers/storage library.
    # See man 5 containers-storage.conf for more information
    # The "container storage" table contains all of the server options.
    [storage]
    
    # Default Storage Driver
    driver = "overlay"
    
    # Temporary storage location
    runroot = "/var/run/containers/storage"
    
    # Primary Read/Write location of container storage
    graphroot = "/var/lib/containers/storage"
    
    [storage.options]
    # Storage options to be passed to underlying storage drivers
    
    # AdditionalImageStores is used to pass paths to additional Read/Only image stores
    # Must be comma separated list.
    additionalimagestores = [
    ]
    
    # Size is used to set a maximum size of the container image.  Only supported by
    # certain container storage drivers.
    size = ""
    
    # Path to an helper program to use for mounting the file system instead of mounting it
    # directly.
    #mount_program = "/usr/bin/fuse-overlayfs"
    
    # OverrideKernelCheck tells the driver to ignore kernel checks based on kernel version
    override_kernel_check = "true"
    
    # mountopt specifies comma separated list of extra mount options
    mountopt = "nodev"
    
    # Remap-UIDs/GIDs is the mapping from UIDs/GIDs as they should appear inside of
    # a container, to UIDs/GIDs as they should appear outside of the container, and
    # the length of the range of UIDs/GIDs.  Additional mapped sets can be listed
    # and will be heeded by libraries, but there are limits to the number of
    # mappings which the kernel will allow when you later attempt to run a
    # container.
    #
    # remap-uids = 0:1668442479:65536
    # remap-gids = 0:1668442479:65536
    
    # Remap-User/Group is a name which can be used to look up one or more UID/GID
    # ranges in the /etc/subuid or /etc/subgid file.  Mappings are set up starting
    # with an in-container ID of 0 and the a host-level ID taken from the lowest
    # range that matches the specified name, and using the length of that range.
    # Additional ranges are then assigned, using the ranges which specify the
    # lowest host-level IDs first, to the lowest not-yet-mapped container-level ID,
    # until all of the entries have been used for maps.
    #
    # remap-user = "storage"
    # remap-group = "storage"
    
    [storage.options.thinpool]
    # Storage Options for thinpool
    
    # autoextend_percent determines the amount by which pool needs to be
    # grown. This is specified in terms of % of pool size. So a value of 20 means
    # that when threshold is hit, pool will be grown by 20% of existing
    # pool size.
    # autoextend_percent = "20"
    
    # autoextend_threshold determines the pool extension threshold in terms
    # of percentage of pool size. For example, if threshold is 60, that means when
    # pool is 60% full, threshold has been hit.
    # autoextend_threshold = "80"
    
    # basesize specifies the size to use when creating the base device, which
    # limits the size of images and containers.
    # basesize = "10G"
    
    # blocksize specifies a custom blocksize to use for the thin pool.
    # blocksize="64k"
    
    # directlvm_device specifies a custom block storage device to use for the
    # thin pool. Required if you setup devicemapper.
    # directlvm_device = ""
    
    # directlvm_device_force wipes device even if device already has a filesystem.
    # directlvm_device_force = "True"
    
    # fs specifies the filesystem type to use for the base device.
    # fs="xfs"
    
    # log_level sets the log level of devicemapper.
    # 0: LogLevelSuppress 0 (Default)
    # 2: LogLevelFatal
    # 3: LogLevelErr
    # 4: LogLevelWarn
    # 5: LogLevelNotice
    # 6: LogLevelInfo
    # 7: LogLevelDebug
    # log_level = "7"
    
    # min_free_space specifies the min free space percent in a thin pool require for
    # new device creation to succeed. Valid values are from 0% - 99%.
    # Value 0% disables
    # min_free_space = "10%"
    
    # mkfsarg specifies extra mkfs arguments to be used when creating the base.
    # device.
    # mkfsarg = ""
    
    # use_deferred_removal marks devicemapper block device for deferred removal.
    # If the thinpool is in use when the driver attempts to remove it, the driver 
    # tells the kernel to remove it as soon as possible. Note this does not free
    # up the disk space, use deferred deletion to fully remove the thinpool.
    # use_deferred_removal = "True"
    
    # use_deferred_deletion marks thinpool device for deferred deletion.
    # If the device is busy when the driver attempts to delete it, the driver
    # will attempt to delete device every 30 seconds until successful.
    # If the program using the driver exits, the driver will continue attempting
    # to cleanup the next time the driver is used. Deferred deletion permanently
    # deletes the device and all data stored in device will be lost.
    # use_deferred_deletion = "True"
    
    # xfs_nospace_max_retries specifies the maximum number of retries XFS should
    # attempt to complete IO when ENOSPC (no space) error is returned by
    # underlying storage device.
    # xfs_nospace_max_retries = "0"
    
    # If specified, use OSTree to deduplicate files with the overlay backend
    ostree_repo = ""
    
    # Set to skip a PRIVATE bind mount on the storage home directory.  Only supported by
    # certain container storage drivers
    skip_mount_home = "false"
    
  • COPY command for ~75M takes several minutes

    COPY command for ~75M takes several minutes

    Description Building a container with a build context of ~75M and around 3700 files takes several minutes to do a COPY . /target-dir. Colleagues using docker have a build time of seconds.

    Checking top or iotop during the build shows very low utilization.

    Steps to reproduce the issue:

    1. time podman build .

    Describe the results you received: Slow build

    Describe the results you expected: Fast build

    Output of rpm -q buildah or apt list buildah: (Giving podman instead, since I don't have buildah installed itself)

    $ rpm -q podman
    podman-1.4.4-1.fc30.x86_64
    

    Output of podman version if reporting a podman build issue:

    $ podman version
    Version:            1.4.5-dev
    RemoteAPI Version:  1
    Go Version:         go1.12.6
    OS/Arch:            linux/amd64
    

    First tested with 1.4.2, updated to see if that helped. Also note: This is pretty weird packaging? The rpm says 1.4.4, I get something tagged 1.4.5-dev?

    Output of cat /etc/*release:

    Fedora release 30 (Thirty)
    NAME=Fedora
    VERSION="30 (Thirty)"
    ID=fedora
    VERSION_ID=30
    VERSION_CODENAME=""
    PLATFORM_ID="platform:f30"
    PRETTY_NAME="Fedora 30 (Thirty)"
    ANSI_COLOR="0;34"
    LOGO=fedora-logo-icon
    CPE_NAME="cpe:/o:fedoraproject:fedora:30"
    HOME_URL="https://fedoraproject.org/"
    DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f30/system-administrators-guide/"
    SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
    BUG_REPORT_URL="https://bugzilla.redhat.com/"
    REDHAT_BUGZILLA_PRODUCT="Fedora"
    REDHAT_BUGZILLA_PRODUCT_VERSION=30
    REDHAT_SUPPORT_PRODUCT="Fedora"
    REDHAT_SUPPORT_PRODUCT_VERSION=30
    PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
    Fedora release 30 (Thirty)
    Fedora release 30 (Thirty)
    

    Output of uname -a:

    Linux - 5.0.16-300.fc30.x86_64 #1 SMP Tue May 14 19:33:09 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
    

    Output of cat /etc/containers/storage.conf:

    $ cat /etc/containers/storage.conf | grep -Pv '#|^$'
    [storage]
    driver = "overlay"
    runroot = "/var/run/containers/storage"
    graphroot = "/var/lib/containers/storage"
    [storage.options]
    additionalimagestores = [
    ]
    size = ""
    override_kernel_check = "true"
    mountopt = "nodev"
    [storage.options.thinpool]
    ostree_repo = ""
    skip_mount_home = "false"
    
  • Build/Push/Pull via HTTP Proxy

    Build/Push/Pull via HTTP Proxy

    Description

    Steps to reproduce the issue:

    1. sudo buildah build-using-dockerfile --file files/latest/Dockerfile

    Describe the results you received:

    Installing packages by apk add hangs with no progress

    Describe the results you expected:

    Installing packages works without any build args passed to buildah - something similar to https://docs.docker.com/network/proxy/

    Possible solutions

    • Use --build-args
    • Use config file

    If you need to pass proxy configuration via --build-args you need to make your build scripts of project XY aware of the HTTP*/http*-variables thus make them depend on the developers environment. So I would prefer to have a config file.

    Example A:

    bin/build-no-config:

    #!/usr/bin/env sh
    
    sudo buildah build-using-dockerfile --file files/latest/Dockerfile --build-arg HTTP_PROXY=http://10.0.2.15:3128 
    

    Example A:

    bin/build-with-config:

    #!/usr/bin/env sh
    
    sudo buildah build-using-dockerfile --file files/latest/Dockerfile
    

    ~/.buildah/config.json:

    {
     "proxies":
     {
       "default":
       {
         "httpProxy": "http://10.0.2.15:3128"
       }
     }
    }
    

    Output of rpm -q buildah or apt list buildah:

    buildah-1.0-1.git1ab80bc.fc28.x86_64
    

    Output of buildah version:

    Version:       1.0
    Go Version:    go1.10.1
    Image Spec:    1.0.0
    Runtime Spec:  1.0.0
    Git Commit:    1ab80bc
    Built:         Mon May  7 16:01:02 2018
    OS/Arch:       linux/amd64
    
    

    Output of cat /etc/*release:

    Fedora release 28 (Twenty Eight)
    NAME=Fedora
    VERSION="28 (Workstation Edition)"
    ID=fedora
    VERSION_ID=28
    PLATFORM_ID="platform:f28"
    PRETTY_NAME="Fedora 28 (Workstation Edition)"
    ANSI_COLOR="0;34"
    CPE_NAME="cpe:/o:fedoraproject:fedora:28"
    HOME_URL="https://fedoraproject.org/"
    SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
    BUG_REPORT_URL="https://bugzilla.redhat.com/"
    REDHAT_BUGZILLA_PRODUCT="Fedora"
    REDHAT_BUGZILLA_PRODUCT_VERSION=28
    REDHAT_SUPPORT_PRODUCT="Fedora"
    REDHAT_SUPPORT_PRODUCT_VERSION=28
    PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
    VARIANT="Workstation Edition"
    VARIANT_ID=workstation
    Fedora release 28 (Twenty Eight)
    Fedora release 28 (Twenty Eight)
    

    Output of uname -a:

    Linux host.example.com 4.16.13-300.fc28.x86_64 #1 SMP Wed May 30 14:31:00 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
    

    Output of cat /etc/containers/storage.conf:

    # storage.conf is the configuration file for all tools
    # that share the containers/storage libraries
    # See man 5 containers-storage.conf for more information
    
    # The "container storage" table contains all of the server options.
    [storage]
    
    # Default Storage Driver
    driver = "overlay"
    
    # Temporary storage location
    runroot = "/var/run/containers/storage"
    
    # Primary Read/Write location of container storage
    graphroot = "/var/lib/containers/storage"
    
    [storage.options]
    # AdditionalImageStores is used to pass paths to additional Read/Only image stores
    # Must be comma separated list.
    additionalimagestores = [
    ]
    
    # Size is used to set a maximum size of the container image.  Only supported by
    # certain container storage drivers.
    size = ""
    
    # OverrideKernelCheck tells the driver to ignore kernel checks based on kernel version
    override_kernel_check = "true"
    
  • [release-1.28] Bump to c/storage v1.43.1 for s390x sigsegv fix

    [release-1.28] Bump to c/storage v1.43.1 for s390x sigsegv fix

    Bump the c/storage to v1.43.1 so this v1.28 branch will have access to the fix for https://bugzilla.redhat.com/show_bug.cgi?id=2140087 - SIGSEGV: segmentation violation on s390x. This was originally fixed with https://github.com/containers/storage/pull/1418 and is being vendored here now as the fix is in the v1.27 branch already.

    Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=2140087

    [NO NEW TESTS NEEDED] Signed-off-by: tomsweeneyredhat [email protected]

    What type of PR is this?

    /kind api-change /kind bug /kind cleanup /kind deprecation /kind design /kind documentation /kind failing-test /kind feature /kind flake /kind other

    What this PR does / why we need it:

    How to verify it

    Which issue(s) this PR fixes:

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?

    
    
  • placeholder: f37 gating tests: failure in --runtime-flag test

    placeholder: f37 gating tests: failure in --runtime-flag test

    Impossible-to-debug failure in f37 gating tests:

    not ok 696 run --runtime --runtime-flag
    # (in test file /usr/share/buildah/test/system/run.bats, line 810)
    #   `[ -n "$output" ]' failed
    # /usr/share/buildah/test/system /var/str
    # # [checking for: docker.io/library/alpine]
    # # [restoring from cache: /var/tmp/buildah-image-cache.5515 / docker.io/library/alpine]
    # Getting image source signatures
    # Copying blob sha256:9d16cba9fb961d1aafec9542f2bf7cb64acfc55245f9e4eb5abecd4cdc38d749
    # Copying config sha256:961769676411f082461f9ef46626dd7a2d1e2b2a38e6a44364bcbecf51e66dd4
    # Writing manifest to image destination
    # Storing signatures
    # $ /usr/bin/buildah from --security-opt seccomp=/var/tmp/buildah_tests.6b1cxe/seccomp.json --quiet --pull=false --signature-policy /usr/share/buildah/test/system/policy.json alpine
    # alpine-working-container
    # $ /usr/bin/buildah run --runtime=crun --runtime-flag=debug alpine-working-container true
    # /var/str
    

    The broken test is being fixed in #4502; until that merges we can't actually know what happened. One possibility is that crun changed somehow, such that debug no longer produces debug output? The test failure suggests that this command:

    $ buildah run --runtime=crun --runtime-flag=debug alpine-working-container true
    

    ...should produce output, but it isn't? Could this be a crun change? A change in how buildah passes the --runtime-flag option?

  • [release-1.24] [CI:BUILD] Cirrus: Migrate OSX task to M1

    [release-1.24] [CI:BUILD] Cirrus: Migrate OSX task to M1

    Migrate our OSX build to a M1 instance, since Cirrus is sunsetting Intel-based macOS instances.

    Signed-off-by: Ashley Cui [email protected] (cherry picked from commit 498b45770ff9d238f95d772efa2a1fd16d941077) Signed-off-by: Lokesh Mandvekar [email protected]

    What type of PR is this?

    /kind failing-test

    What this PR does / why we need it:

    Fixes osx tests in cron run

    How to verify it

    Check the next cron run

    Which issue(s) this PR fixes:

    None

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?

    None
    
  • No way to expose UDP port

    No way to expose UDP port

    Docker’s file EXPOSE https://docs.docker.com/engine/reference/builder/#expose lets explicitly specify that the protocol is UDP.

    Containerfile - https://github.com/containers/common/blob/main/docs/Containerfile.5.md and buildah config --port do not allow for specifying UDP, or at least, the documentation does not say it is possible to expose an UDP port.

    Concerning EXPOSE https://github.com/containers/common/blob/main/docs/Containerfile.5.md says:

    The EXPOSE instruction informs the container engine that the container listens on the specified network ports at runtime. The container engine uses this information to interconnect containers using links and to set up port redirection on the host system.

    To be honest I do not understand how is the EXPOSEd information used by the container engine, apart from letting podman assigned the internal ports to random outside ports.

  • Secret mounts with relative paths do not take WORKDIR into account

    Secret mounts with relative paths do not take WORKDIR into account

    Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

    /kind bug

    Description

    Building a container from Dockerfile with WORKDIR + using --mount=type=secret with relative destination path leads to inconsistent behavior.

    Steps to reproduce the issue:

    1. Create Dockerfile and Makefile:

    Dockerfile:

    FROM docker.io/ubuntu:22.04
    
    WORKDIR /somedir
    
    RUN --mount=type=secret,id=secret-foo,dst=secret1.txt --mount=type=secret,id=secret-bar,dst=secret2.txt \
         printf "PWD=%s\n" "$(pwd)" && ls -la && ls -la / && stat secret1.txt && stat secret2.txt && \
         cp secret1.txt /root/secret-foo.txt && \
         cp secret2.txt /root/secret-bar.txt
    

    Makefile:

    DOCKER ?= docker
    
    .PHONY: build-container
    
    build-container:
    	rm -rf build
    	mkdir build
    	echo "secret:foo" >build/secret1.txt
    	echo "secret:bar" >build/secret2.txt
    	DOCKER_BUILDKIT=1 BUILDKIT_PROGRESS=plain $(DOCKER) build --no-cache --secret id=secret-foo,src=build/secret1.txt --secret id=secret-bar,src=build/secret2.txt -t defanator/example:tag1 .
    	$(DOCKER) run --rm -t -i defanator/example:tag1 cat /root/secret-foo.txt
    	$(DOCKER) run --rm -t -i defanator/example:tag1 cat /root/secret-bar.txt
    	$(DOCKER) rmi defanator/example:tag1
    
    1. Run DOCKER=podman make.

    Describe the results you received:

    Secrets are being created in /, while commands are being executed under /somedir:

    $ DOCKER=podman make
    rm -rf build
    mkdir build
    echo "secret:foo" >build/secret1.txt
    echo "secret:bar" >build/secret2.txt
    DOCKER_BUILDKIT=1 BUILDKIT_PROGRESS=plain podman build --no-cache --secret id=secret-foo,src=build/secret1.txt --secret id=secret-bar,src=build/secret2.txt -t defanator/example:tag1 .
    STEP 1/3: FROM docker.io/ubuntu:22.04
    STEP 2/3: WORKDIR /somedir
    --> 6c8838cf3a4
    STEP 3/3: RUN --mount=type=secret,id=secret-foo,dst=secret1.txt --mount=type=secret,id=secret-bar,dst=secret2.txt      printf "PWD=%s\n" "$(pwd)" && ls -la && ls -la / && stat secret1.txt && stat secret2.txt &&      cp secret1.txt /root/secret-foo.txt &&      cp secret2.txt /root/secret-bar.txt
    PWD=/somedir
    total 0
    drwxr-xr-x.  2 root root  80 Jan  2 10:55 .
    dr-xr-xr-x. 18 root root 100 Jan  2 10:55 ..
    total 8
    dr-xr-xr-x.  18 root   root     100 Jan  2 10:55 .
    lrwxrwxrwx.   1 root   root       7 Nov 30 02:04 bin -> usr/bin
    drwxr-xr-x.   2 root   root      40 Apr 18  2022 boot
    drwxr-xr-x.   5 root   root     340 Jan  2 10:55 dev
    drwxr-xr-x.  31 root   root    1440 Nov 30 02:07 etc
    drwxr-xr-x.   2 root   root      40 Apr 18  2022 home
    lrwxrwxrwx.   1 root   root       7 Nov 30 02:04 lib -> usr/lib
    lrwxrwxrwx.   1 root   root       9 Nov 30 02:04 lib32 -> usr/lib32
    lrwxrwxrwx.   1 root   root       9 Nov 30 02:04 lib64 -> usr/lib64
    lrwxrwxrwx.   1 root   root      10 Nov 30 02:04 libx32 -> usr/libx32
    drwxr-xr-x.   2 root   root      40 Nov 30 02:04 media
    drwxr-xr-x.   2 root   root      40 Nov 30 02:04 mnt
    drwxr-xr-x.   2 root   root      40 Nov 30 02:04 opt
    dr-xr-xr-x. 307 nobody nogroup    0 Jan  2 10:55 proc
    drwx------.   2 root   root      80 Nov 30 02:07 root
    drwxr-xr-x.   6 root   root      80 Jan  2 10:55 run
    lrwxrwxrwx.   1 root   root       8 Nov 30 02:04 sbin -> usr/sbin
    -r--------.   1 root   root      11 Jan  2 10:55 secret1.txt
    -r--------.   1 root   root      11 Jan  2 10:55 secret2.txt
    drwxr-xr-x.   2 root   root      80 Jan  2 10:55 somedir
    drwxr-xr-x.   2 root   root      40 Nov 30 02:04 srv
    dr-xr-xr-x.  13 nobody nogroup    0 Jan  2 05:48 sys
    drwxrwxrwt.   2 root   root      40 Nov 30 02:07 tmp
    drwxr-xr-x.  14 root   root     280 Nov 30 02:04 usr
    drwxr-xr-x.  11 root   root     260 Nov 30 02:07 var
    stat: cannot statx 'secret1.txt': No such file or directory
    Error: building at STEP "RUN --mount=type=secret,id=secret-foo,dst=secret1.txt --mount=type=secret,id=secret-bar,dst=secret2.txt printf "PWD=%s\n" "$(pwd)" && ls -la && ls -la / && stat secret1.txt && stat secret2.txt &&      cp secret1.txt /root/secret-foo.txt &&      cp secret2.txt /root/secret-bar.txt": while running runtime: exit status 1
    make: *** [Makefile:9: build-container] Error 1
    

    Describe the results you expected:

    Successful build + run with secrets created in /somedir:

    % DOCKER=docker make
    rm -rf build
    mkdir build
    echo "secret:foo" >build/secret1.txt
    echo "secret:bar" >build/secret2.txt
    DOCKER_BUILDKIT=1 BUILDKIT_PROGRESS=plain docker build --no-cache --secret id=secret-foo,src=build/secret1.txt --secret id=secret-bar,src=build/secret2.txt -t defanator/example:tag1 .
    containers/podman#1 [internal] load build definition from Dockerfile
    containers/podman#1 sha256:956e81e187c4ea4dc450871b18ae84ab976c49582e3bea65caf50ea0a79a9705
    containers/podman#1 transferring dockerfile: 37B done
    containers/podman#1 DONE 0.0s
    
    containers/podman#2 [internal] load .dockerignore
    containers/podman#2 sha256:7c24936d078707145f864038bef4b8e7b4e5a03304c2868a047c035c62162948
    containers/podman#2 transferring context: 2B done
    containers/podman#2 DONE 0.0s
    
    containers/podman#3 [internal] load metadata for docker.io/library/ubuntu:22.04
    containers/podman#3 sha256:bb6615d6728e62d4ed2a35dd58ee60e0f7b38bf575e6e24f49f6804d1f20ad90
    containers/podman#3 DONE 0.0s
    
    containers/podman#4 [1/3] FROM docker.io/library/ubuntu:22.04
    containers/podman#4 sha256:cdc6c23330729686ac5f85a03a4f1099b9aac0474f5235d6e7014170e77af427
    containers/podman#4 DONE 0.0s
    
    containers/podman#5 [2/3] WORKDIR /somedir
    containers/podman#5 sha256:de48d2aee164955e5a46b60b23669598af66b88de3d5de6d7376cf5b8f7c2a06
    containers/podman#5 CACHED
    
    containers/podman#6 [3/3] RUN --mount=type=secret,id=secret-foo,dst=secret1.txt --mount=type=secret,id=secret-bar,dst=secret2.txt      printf "PWD=%s\n" "$(pwd)" && ls -la && ls -la / && stat secret1.txt && stat secret2.txt &&      cp secret1.txt /root/secret-foo.txt &&      cp secret2.txt /root/secret-bar.txt
    containers/podman#6 sha256:311ee95bba27f37488c9149037523cdf14690b288661537cc5bafca7e2ac4274
    containers/podman#6 0.243 PWD=/somedir
    containers/podman#6 0.246 total 16
    containers/podman#6 0.246 drwxr-xr-x 1 root root 4096 Jan  2 10:55 .
    containers/podman#6 0.246 drwxr-xr-x 1 root root 4096 Jan  2 10:55 ..
    containers/podman#6 0.246 -r-------- 1 root root   11 Jan  2 10:55 secret1.txt
    containers/podman#6 0.246 -r-------- 1 root root   11 Jan  2 10:55 secret2.txt
    containers/podman#6 0.248 total 60
    containers/podman#6 0.248 drwxr-xr-x   1 root root 4096 Jan  2 10:55 .
    containers/podman#6 0.248 drwxr-xr-x   1 root root 4096 Jan  2 10:55 ..
    containers/podman#6 0.248 lrwxrwxrwx   1 root root    7 Aug 15 11:54 bin -> usr/bin
    containers/podman#6 0.248 drwxr-xr-x   2 root root 4096 Apr 18  2022 boot
    containers/podman#6 0.248 drwxr-xr-x   5 root root  340 Jan  2 10:55 dev
    containers/podman#6 0.248 drwxr-xr-x  31 root root 4096 Aug 15 12:13 etc
    containers/podman#6 0.248 drwxr-xr-x   2 root root 4096 Apr 18  2022 home
    containers/podman#6 0.248 lrwxrwxrwx   1 root root    7 Aug 15 11:54 lib -> usr/lib
    containers/podman#6 0.248 drwxr-xr-x   2 root root 4096 Aug 15 11:54 media
    containers/podman#6 0.248 drwxr-xr-x   2 root root 4096 Aug 15 11:54 mnt
    containers/podman#6 0.248 drwxr-xr-x   2 root root 4096 Aug 15 11:54 opt
    containers/podman#6 0.248 dr-xr-xr-x 208 root root    0 Jan  2 10:55 proc
    containers/podman#6 0.248 drwx------   2 root root 4096 Aug 15 12:13 root
    containers/podman#6 0.248 drwxr-xr-x   5 root root 4096 Aug 15 12:13 run
    containers/podman#6 0.248 lrwxrwxrwx   1 root root    8 Aug 15 11:54 sbin -> usr/sbin
    containers/podman#6 0.248 drwxr-xr-x   1 root root 4096 Jan  2 10:55 somedir
    containers/podman#6 0.248 drwxr-xr-x   2 root root 4096 Aug 15 11:54 srv
    containers/podman#6 0.248 dr-xr-xr-x  13 root root    0 Jan  2 10:55 sys
    containers/podman#6 0.248 drwxrwxrwt   2 root root 4096 Aug 15 12:13 tmp
    containers/podman#6 0.248 drwxr-xr-x  11 root root 4096 Aug 15 11:54 usr
    containers/podman#6 0.248 drwxr-xr-x  11 root root 4096 Aug 15 12:13 var
    containers/podman#6 0.249   File: secret1.txt
    containers/podman#6 0.249   Size: 11        	Blocks: 8          IO Block: 4096   regular file
    containers/podman#6 0.249 Device: 94h/148d	Inode: 2           Links: 1
    containers/podman#6 0.249 Access: (0400/-r--------)  Uid: (    0/    root)   Gid: (    0/    root)
    containers/podman#6 0.249 Access: 2023-01-02 10:55:56.046869011 +0000
    containers/podman#6 0.249 Modify: 2023-01-02 10:55:56.046869011 +0000
    containers/podman#6 0.249 Change: 2023-01-02 10:55:56.046869011 +0000
    containers/podman#6 0.249  Birth: -
    containers/podman#6 0.250   File: secret2.txt
    containers/podman#6 0.250   Size: 11        	Blocks: 8          IO Block: 4096   regular file
    containers/podman#6 0.250 Device: 95h/149d	Inode: 2           Links: 1
    containers/podman#6 0.250 Access: (0400/-r--------)  Uid: (    0/    root)   Gid: (    0/    root)
    containers/podman#6 0.250 Access: 2023-01-02 10:55:56.046869011 +0000
    containers/podman#6 0.250 Modify: 2023-01-02 10:55:56.046869011 +0000
    containers/podman#6 0.250 Change: 2023-01-02 10:55:56.046869011 +0000
    containers/podman#6 0.250  Birth: -
    containers/podman#6 DONE 0.3s
    
    containers/podman#7 exporting to image
    containers/podman#7 sha256:e8c613e07b0b7ff33893b694f7759a10d42e180f2b4dc349fb57dc6b71dcab00
    containers/podman#7 exporting layers done
    containers/podman#7 writing image sha256:f767695a2ecb38dc27477fa3c1f0b534233a6ce938eccbf234635921abd610c9 done
    containers/podman#7 naming to docker.io/defanator/example:tag1 done
    containers/podman#7 DONE 0.0s
    
    Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them
    docker run --rm -t -i defanator/example:tag1 cat /root/secret-foo.txt
    secret:foo
    docker run --rm -t -i defanator/example:tag1 cat /root/secret-bar.txt
    secret:bar
    docker rmi defanator/example:tag1
    Untagged: defanator/example:tag1
    Deleted: sha256:f767695a2ecb38dc27477fa3c1f0b534233a6ce938eccbf234635921abd610c9
    

    Running podman with WORKDIR commented in Dockerfile works:

    $ DOCKER=podman make
    rm -rf build
    mkdir build
    echo "secret:foo" >build/secret1.txt
    echo "secret:bar" >build/secret2.txt
    DOCKER_BUILDKIT=1 BUILDKIT_PROGRESS=plain podman build --no-cache --secret id=secret-foo,src=build/secret1.txt --secret id=secret-bar,src=build/secret2.txt -t defanator/example:tag1 .
    STEP 1/2: FROM docker.io/ubuntu:22.04
    STEP 2/2: RUN --mount=type=secret,id=secret-foo,dst=secret1.txt --mount=type=secret,id=secret-bar,dst=secret2.txt      printf "PWD=%s\n" "$(pwd)" && ls -la && ls -la / && stat secret1.txt && stat secret2.txt &&      cp secret1.txt /root/secret-foo.txt &&      cp secret2.txt /root/secret-bar.txt
    PWD=/
    total 8
    dr-xr-xr-x.  17 root   root      80 Jan  2 10:57 .
    lrwxrwxrwx.   1 root   root       7 Nov 30 02:04 bin -> usr/bin
    drwxr-xr-x.   2 root   root      40 Apr 18  2022 boot
    drwxr-xr-x.   5 root   root     340 Jan  2 10:57 dev
    drwxr-xr-x.  31 root   root    1440 Nov 30 02:07 etc
    drwxr-xr-x.   2 root   root      40 Apr 18  2022 home
    lrwxrwxrwx.   1 root   root       7 Nov 30 02:04 lib -> usr/lib
    lrwxrwxrwx.   1 root   root       9 Nov 30 02:04 lib32 -> usr/lib32
    lrwxrwxrwx.   1 root   root       9 Nov 30 02:04 lib64 -> usr/lib64
    lrwxrwxrwx.   1 root   root      10 Nov 30 02:04 libx32 -> usr/libx32
    drwxr-xr-x.   2 root   root      40 Nov 30 02:04 media
    drwxr-xr-x.   2 root   root      40 Nov 30 02:04 mnt
    drwxr-xr-x.   2 root   root      40 Nov 30 02:04 opt
    dr-xr-xr-x. 313 nobody nogroup    0 Jan  2 10:57 proc
    drwx------.   2 root   root      80 Nov 30 02:07 root
    drwxr-xr-x.   6 root   root      80 Jan  2 10:57 run
    lrwxrwxrwx.   1 root   root       8 Nov 30 02:04 sbin -> usr/sbin
    -r--------.   1 root   root      11 Jan  2 10:57 secret1.txt
    -r--------.   1 root   root      11 Jan  2 10:57 secret2.txt
    drwxr-xr-x.   2 root   root      40 Nov 30 02:04 srv
    dr-xr-xr-x.  13 nobody nogroup    0 Jan  2 05:48 sys
    drwxrwxrwt.   2 root   root      40 Nov 30 02:07 tmp
    drwxr-xr-x.  14 root   root     280 Nov 30 02:04 usr
    drwxr-xr-x.  11 root   root     260 Nov 30 02:07 var
    total 8
    dr-xr-xr-x.  17 root   root     100 Jan  2 10:57 .
    lrwxrwxrwx.   1 root   root       7 Nov 30 02:04 bin -> usr/bin
    drwxr-xr-x.   2 root   root      40 Apr 18  2022 boot
    drwxr-xr-x.   5 root   root     340 Jan  2 10:57 dev
    drwxr-xr-x.  31 root   root    1440 Nov 30 02:07 etc
    drwxr-xr-x.   2 root   root      40 Apr 18  2022 home
    lrwxrwxrwx.   1 root   root       7 Nov 30 02:04 lib -> usr/lib
    lrwxrwxrwx.   1 root   root       9 Nov 30 02:04 lib32 -> usr/lib32
    lrwxrwxrwx.   1 root   root       9 Nov 30 02:04 lib64 -> usr/lib64
    lrwxrwxrwx.   1 root   root      10 Nov 30 02:04 libx32 -> usr/libx32
    drwxr-xr-x.   2 root   root      40 Nov 30 02:04 media
    drwxr-xr-x.   2 root   root      40 Nov 30 02:04 mnt
    drwxr-xr-x.   2 root   root      40 Nov 30 02:04 opt
    dr-xr-xr-x. 313 nobody nogroup    0 Jan  2 10:57 proc
    drwx------.   2 root   root      80 Nov 30 02:07 root
    drwxr-xr-x.   6 root   root      80 Jan  2 10:57 run
    lrwxrwxrwx.   1 root   root       8 Nov 30 02:04 sbin -> usr/sbin
    -r--------.   1 root   root      11 Jan  2 10:57 secret1.txt
    -r--------.   1 root   root      11 Jan  2 10:57 secret2.txt
    drwxr-xr-x.   2 root   root      40 Nov 30 02:04 srv
    dr-xr-xr-x.  13 nobody nogroup    0 Jan  2 05:48 sys
    drwxrwxrwt.   2 root   root      40 Nov 30 02:07 tmp
    drwxr-xr-x.  14 root   root     280 Nov 30 02:04 usr
    drwxr-xr-x.  11 root   root     260 Nov 30 02:07 var
      File: secret1.txt
      Size: 11        	Blocks: 8          IO Block: 4096   regular file
    Device: 32h/50d	Inode: 511286      Links: 1
    Access: (0400/-r--------)  Uid: (    0/    root)   Gid: (    0/    root)
    Access: 2023-01-02 10:57:02.245219286 +0000
    Modify: 2023-01-02 10:57:02.245219286 +0000
    Change: 2023-01-02 10:57:02.245219286 +0000
     Birth: 2023-01-02 10:57:02.245219286 +0000
      File: secret2.txt
      Size: 11        	Blocks: 8          IO Block: 4096   regular file
    Device: 32h/50d	Inode: 511287      Links: 1
    Access: (0400/-r--------)  Uid: (    0/    root)   Gid: (    0/    root)
    Access: 2023-01-02 10:57:02.246219299 +0000
    Modify: 2023-01-02 10:57:02.246219299 +0000
    Change: 2023-01-02 10:57:02.246219299 +0000
     Birth: 2023-01-02 10:57:02.246219299 +0000
    COMMIT defanator/example:tag1
    --> 5422152c019
    Successfully tagged localhost/defanator/example:tag1
    5422152c019436fb30262db43c1c58653a88b6077db9293ab30ef10a48cb2ce8
    podman run --rm -t -i defanator/example:tag1 cat /root/secret-foo.txt
    secret:foo
    podman run --rm -t -i defanator/example:tag1 cat /root/secret-bar.txt
    secret:bar
    podman rmi defanator/example:tag1
    Untagged: localhost/defanator/example:tag1
    Deleted: 5422152c019436fb30262db43c1c58653a88b6077db9293ab30ef10a48cb2ce8
    

    Obviously, using absolute paths both in mount dst= option and after in commands also works.

    Additional information you deem important (e.g. issue happens only occasionally):

    100% reproducible, tested in root-less mode only.

    Output of podman version:

    $ podman version
    Client:       Podman Engine
    Version:      4.3.1
    API Version:  4.3.1
    Go Version:   go1.18.7
    Built:        Fri Nov 11 15:24:13 2022
    OS/Arch:      linux/amd64
    

    Output of podman info:

    $ podman info
    host:
      arch: amd64
      buildahVersion: 1.28.0
      cgroupControllers:
      - memory
      - pids
      cgroupManager: systemd
      cgroupVersion: v2
      conmon:
        package: conmon-2.1.5-1.fc36.x86_64
        path: /usr/bin/conmon
        version: 'conmon version 2.1.5, commit: '
      cpuUtilization:
        idlePercent: 99.4
        systemPercent: 0.21
        userPercent: 0.4
      cpus: 16
      distribution:
        distribution: fedora
        variant: cloud
        version: "36"
      eventLogger: journald
      hostname: builder-testrunner-amd64.amp.nginx.com
      idMappings:
        gidmap:
        - container_id: 0
          host_id: 9999
          size: 1
        - container_id: 1
          host_id: 755360
          size: 65536
        uidmap:
        - container_id: 0
          host_id: 9999
          size: 1
        - container_id: 1
          host_id: 755360
          size: 65536
      kernel: 6.0.15-200.fc36.x86_64
      linkmode: dynamic
      logDriver: journald
      memFree: 21277806592
      memTotal: 32932081664
      networkBackend: netavark
      ociRuntime:
        name: crun
        package: crun-1.7.2-2.fc36.x86_64
        path: /usr/bin/crun
        version: |-
          crun version 1.7.2
          commit: 0356bf4aff9a133d655dc13b1d9ac9424706cac4
          rundir: /run/user/9999/crun
          spec: 1.0.0
          +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +WASM:wasmedge +YAJL
      os: linux
      remoteSocket:
        path: /run/user/9999/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: true
        seccompEnabled: true
        seccompProfilePath: /usr/share/containers/seccomp.json
        selinuxEnabled: true
      serviceIsRemote: false
      slirp4netns:
        executable: /usr/bin/slirp4netns
        package: slirp4netns-1.2.0-0.2.beta.0.fc36.x86_64
        version: |-
          slirp4netns version 1.2.0-beta.0
          commit: 477db14a24ff1a3de3a705e51ca2c4c1fe3dda64
          libslirp: 4.6.1
          SLIRP_CONFIG_VERSION_MAX: 3
          libseccomp: 2.5.3
      swapFree: 8589930496
      swapTotal: 8589930496
      uptime: 5h 5m 27.00s (Approximately 0.21 days)
    plugins:
      authorization: null
      log:
      - k8s-file
      - none
      - passthrough
      - journald
      network:
      - bridge
      - macvlan
      volume:
      - local
    registries:
      search:
      - registry.fedoraproject.org
      - registry.access.redhat.com
      - docker.io
      - quay.io
    store:
      configFile: /home/builder/.config/containers/storage.conf
      containerStore:
        number: 1
        paused: 0
        running: 0
        stopped: 1
      graphDriverName: overlay
      graphOptions:
        overlay.mount_program:
          Executable: /usr/bin/fuse-overlayfs
          Package: fuse-overlayfs-1.9-6.fc36.x86_64
          Version: |-
            fusermount3 version: 3.10.5
            fuse-overlayfs: version 1.9
            FUSE library version 3.10.5
            using FUSE kernel interface version 7.31
        overlay.mountopt: nodev,metacopy=on
      graphRoot: /run/user/9999/containers/storage
      graphRootAllocated: 16466038784
      graphRootUsed: 7435571200
      graphStatus:
        Backing Filesystem: tmpfs
        Native Overlay Diff: "false"
        Supports d_type: "true"
        Using metacopy: "false"
      imageCopyTmpDir: /var/tmp
      imageStore:
        number: 240
      runRoot: /run/user/9999/containers
      volumePath: /run/user/9999/containers/storage/volumes
    version:
      APIVersion: 4.3.1
      Built: 1668180253
      BuiltTime: Fri Nov 11 15:24:13 2022
      GitCommit: ""
      GoVersion: go1.18.7
      Os: linux
      OsArch: linux/amd64
      Version: 4.3.1
    

    Package info (e.g. output of rpm -q podman or apt list podman or brew info podman):

    $ rpm -qi podman
    Name        : podman
    Epoch       : 4
    Version     : 4.3.1
    Release     : 1.fc36
    Architecture: x86_64
    Install Date: Mon 02 Jan 2023 05:47:13 AM UTC
    Group       : Unspecified
    Size        : 42535481
    License     : ASL 2.0 and BSD and ISC and MIT and MPLv2.0
    Signature   : RSA/SHA256, Fri 11 Nov 2022 04:37:04 PM UTC, Key ID 999f7cbf38ab71f4
    Source RPM  : podman-4.3.1-1.fc36.src.rpm
    Build Date  : Fri 11 Nov 2022 03:24:09 PM UTC
    Build Host  : buildvm-x86-04.iad2.fedoraproject.org
    Packager    : Fedora Project
    Vendor      : Fedora Project
    URL         : https://podman.io/
    Bug URL     : https://bugz.fedoraproject.org/podman
    Summary     : Manage Pods, Containers and Container Images
    Description :
    podman (Pod Manager) is a fully featured container engine that is a simple
    daemonless tool.  podman provides a Docker-CLI comparable command line that
    eases the transition from other container engines and allows the management of
    pods, containers and images.  Simply put: alias docker=podman.
    Most podman commands can be run as a regular user, without requiring
    additional privileges.
    
    podman uses Buildah(1) internally to create container images.
    Both tools share image (not container) storage, hence each can use or
    manipulate images (but not containers) created by the other.
    
    Manage Pods, Containers and Container Images
    podman Simple management tool for pods, containers and images
    

    Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

    No

    Additional environment details (AWS, VirtualBox, physical, etc.):

    OS details:

    $ cat /etc/os-release 
    NAME="Fedora Linux"
    VERSION="36 (Cloud Edition)"
    ID=fedora
    VERSION_ID=36
    VERSION_CODENAME=""
    PLATFORM_ID="platform:f36"
    PRETTY_NAME="Fedora Linux 36 (Cloud Edition)"
    ANSI_COLOR="0;38;2;60;110;180"
    LOGO=fedora-logo-icon
    CPE_NAME="cpe:/o:fedoraproject:fedora:36"
    HOME_URL="https://fedoraproject.org/"
    DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f36/system-administrators-guide/"
    SUPPORT_URL="https://ask.fedoraproject.org/"
    BUG_REPORT_URL="https://bugzilla.redhat.com/"
    REDHAT_BUGZILLA_PRODUCT="Fedora"
    REDHAT_BUGZILLA_PRODUCT_VERSION=36
    REDHAT_SUPPORT_PRODUCT="Fedora"
    REDHAT_SUPPORT_PRODUCT_VERSION=36
    PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
    SUPPORT_END=2023-05-16
    VARIANT="Cloud Edition"
    VARIANT_ID=cloud
    
  • Generate images in `go` with `buildah`'s API

    Generate images in `go` with `buildah`'s API

    Description

    I am trying to create a go program leveraging buildah to dynamically generate container images to use with docker.

    # main.go
    package main
    
    import (
    	"context"
    	"fmt"
    	"log"
    
    	"github.com/containers/buildah"
    	"github.com/containers/image/v5/oci/archive"
    	"github.com/containers/storage"
    )
    
    func main() {
    	ctx, _ := context.WithCancel(context.Background())
    
    	buildah.InitReexec()
    
    	storeOptions, err := storage.DefaultStoreOptions(true, 1)
    	store, err := storage.GetStore(storeOptions)
    
    	b, err := buildah.NewBuilder(ctx, store, buildah.BuilderOptions{
    		FromImage: "docker-daemon:semgrep:latest",
    	})
    
    	reference := "test"
    	dest, err := archive.ParseReference(reference)
    
    	b.SetHostname("test")
    
    	err = b.Add("/entrypoint.sh", false, buildah.AddAndCopyOptions{}, "entrypoint.sh")
    	b.SetEntrypoint([]string{"/entrypoint.sh"})
    
    	id, ref, digest, err := b.Commit(ctx, dest, buildah.CommitOptions{})
    }
    
    go build -o test.exe main.go
    sudo setcap cap_sys_admin+ep ./test.exe
    sudo ./test.exe
    

    Note that entrypoint.sh exists in the folder I am running test.exe from. Also, I removed the error handling from the code for simplification purposes, but have them locally, and they are all nil at runtime...

    Describe the results you received:

    The above creates a test tar file of the image, which I can import successfully using docker image import test test-image. However, when inspecting the image, I see that some things aren't set:

    $ docker image inspect test-image | jq '.[].Config.Hostname'
    ""
    $ docker image inspect test-image | jq '.[].Config.Entrypoint'
    null
    

    Describe the results you expected:

    I expected the Hostname and Entrypoint values to be the ones that were set through the builder's .SetHostname and .SetEndpoint methods.

    Output of rpm -q buildah

    buildah-1.23.4-2.fc35.x86_64
    

    Output of buildah version:

    Version:         1.23.4
    Go Version:      go1.16.15
    Image Spec:      1.0.1-dev
    Runtime Spec:    1.0.2-dev
    CNI Spec:        0.4.0
    libcni Version:  v0.8.1
    image Version:   5.16.1-dev
    Git Commit:      
    Built:           Mon Jul 11 00:32:33 2022
    OS/Arch:         linux/amd64
    BuildPlatform:   linux/amd64
    

    Output of cat /etc/*release:

    Fedora release 35 (Thirty Five)
    NAME="Fedora Linux"
    VERSION="35 (Cinnamon)"
    ID=fedora
    VERSION_ID=35
    VERSION_CODENAME=""
    PLATFORM_ID="platform:f35"
    PRETTY_NAME="Fedora Linux 35 (Cinnamon)"
    ANSI_COLOR="0;38;2;60;110;180"
    LOGO=fedora-logo-icon
    CPE_NAME="cpe:/o:fedoraproject:fedora:35"
    HOME_URL="https://fedoraproject.org/"
    DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f35/system-administrators-guide/"
    SUPPORT_URL="https://ask.fedoraproject.org/"
    BUG_REPORT_URL="https://bugzilla.redhat.com/"
    REDHAT_BUGZILLA_PRODUCT="Fedora"
    REDHAT_BUGZILLA_PRODUCT_VERSION=35
    REDHAT_SUPPORT_PRODUCT="Fedora"
    REDHAT_SUPPORT_PRODUCT_VERSION=35
    PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
    VARIANT="Cinnamon"
    VARIANT_ID=cinnamon
    Fedora release 35 (Thirty Five)
    Fedora release 35 (Thirty Five)
    

    Output of uname -a:

    Linux pamplemousse.workstation 6.0.9-100.fc35.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Nov 16 17:25:52 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
    
Work with remote images registries - retrieving information, images, signing content

skopeo skopeo is a command line utility that performs various operations on container images and image repositories. skopeo does not require the user

Jan 5, 2023
CLI tool to generate preview images from a zmk .keymap file
CLI tool to generate preview images from a zmk .keymap file

ZMK viewer A work in progress Cli tool to generate preview images from a zmk .keymap file. Installation You can download a pre compiled binary directl

Jan 3, 2023
An experiment building a custom binary protocol for a calculator

Overview Implementation of a calculator service built on a custom protocol on top of TCP Details The server is in main.go, and the client is in client

Nov 28, 2021
Tanzu Framework provides a set of building blocks to build atop of the Tanzu platform and leverages Carvel packaging

Tanzu Framework provides a set of building blocks to build atop of the Tanzu platform and leverages Carvel packaging and plugins to provide users with a much stronger, more integrated experience than the loose coupling and stand-alone commands of the previous generation of tools.

Dec 16, 2022
Package buildinfo provides basic building blocks and instructions to easily add build and release information to your app.
Package buildinfo provides basic building blocks and instructions to easily add build and release information to your app.

Package buildinfo provides basic building blocks and instructions to easily add build and release information to your app. This is done by replacing variables in main during build with ldflags.

Nov 14, 2021
Boilerplate for building a monolighic Go and React application
Boilerplate for building a monolighic Go and React application

Monolithic Go and React Application Boilerplate This repository provides a simple and monolithic service with a server written in Go and frontend with

Dec 19, 2022
A boilerplate for building Gradescope autograders for Go projects.

go-autograder A boilerplate for building Gradescope autograders for Go projects. Getting started This autograder works by running all Go tests in a st

Nov 6, 2022
[Building]Use Go & Vue3 to build an easy blog

Go + Vue3 Study 环境安装 本地环境:Go 1.17 后端框架:Gin 注意Go在使用Go Module的话需要使用修改Go的代理 首先查看Go相关的环境变量 go env 修改Go代理 go env -w Go111MODULE=on go env -w GOPROXY=https:

Jan 25, 2022
This Go based project of Aadhyarupam Innovators demonstrate the code examples for building microservices, integration with cloud services (Google Cloud Firestore), application configuration management (Viper) etc.

This Go based project of Aadhyarupam Innovators demonstrate the code examples for building microservices, integration with cloud services (Google Cloud Firestore), application configuration management (Viper) etc.

Dec 22, 2022
A boilerplate/starter project for quickly building APIs using Golang with Clean Architechture
A boilerplate/starter project for quickly building APIs using Golang with Clean Architechture

A boilerplate/starter project for quickly building APIs using Golang with Clean Architechture

Mar 2, 2022
A reverse-proxy cache for external images used on LinuxFr.org

External images on LinuxFr.org Our users can use images from external domains on LinuxFr.org. This component is a reverse-proxy / cache for these imag

May 14, 2021
A minimalist Go PDF writer in 1982 lines. Draws text, images and shapes. Helps understand the PDF format. Used in production for reports.
A minimalist Go PDF writer in 1982 lines. Draws text, images and shapes. Helps understand the PDF format. Used in production for reports.

one-file-pdf - A minimalist PDF generator in <2K lines and 1 file The main idea behind this project was: "How small can I make a PDF generator for it

Dec 11, 2022
Get and save EroCool.com images

Get and save EroCool.com images

Nov 9, 2021
Eightbit - A converter to create shitty 8-bit like images

eightbit A converter to create shitty 8-bit like images. Usage To install: go in

Jan 8, 2022
Packer Plugin Vagrant - The Vagrant multi-component plugin can be used with HashiCorp Packer to create custom images

Packer Plugin Vagrant - The Vagrant multi-component plugin can be used with HashiCorp Packer to create custom images

Jul 13, 2022
The forgotten go tool that executes and caches binaries included in go.mod files.
The forgotten go tool that executes and caches binaries included in go.mod files.

The forgotten go tool that executes and caches binaries included in go.mod files. This makes it easy to version cli tools in your projects such as gol

Sep 27, 2022
[TOOL, CLI] - Filter and examine Go type structures, interfaces and their transitive dependencies and relationships. Export structural types as TypeScript value object or bare type representations.

typex Examine Go types and their transitive dependencies. Export results as TypeScript value objects (or types) declaration. Installation go get -u gi

Dec 6, 2022
A tool for design-by-contract in Go

gocontracts gocontracts is a tool for design-by-contract in Go. It generates pre- and post-condition checks from the function descriptions so that the

Jan 1, 2023
elPrep: a high-performance tool for analyzing sequence alignment/map files in sequencing pipelines.
elPrep: a high-performance tool for analyzing sequence alignment/map files in sequencing pipelines.

Overview elPrep is a high-performance tool for analyzing .sam/.bam files (up to and including variant calling) in sequencing pipelines. The key advant

Nov 2, 2022