Development

I’ve spent some of the last weeks working on a replacement for runC, the most used/known OCI runtime for running containers. It might not be very well known, but it is a key component for running containers. Every Docker container ultimately runs through runC. Having containers running through some common specs allow some pieces to be replaced without having any difference in behavior. The OCI runtime specs describe how a container looks like once it is running, for instance it lists all the mount points, the capabilities left to the process, the process that must be executed, the namespaces to create and so on. ...

It is still an ongoing work not ready for production, but the upstream version of OpenShift origin has already an experimental support for running OpenShift Origin using system containers. The “latest” Docker image for origin, node and openvswitch, the 3 components we need, are automatically pushed to docker.io, so we can use these for our test. The rhel7/etcd system container image instead is pulled from the Red Hat registry. This demo is based on these blog posts www.projectatomic.io/blog/2016/12/part1-install-origin-on-f25-atomic-host/ and www.projectatomic.io/blog/2016/12/part2-install-origin-on-f25-atomic-host/ with some differences for the provision of the VMs and obviously running system containers instead of Docker containers. ...

bubblewrap is a sandboxing tool that allows unprivileged users to run containers. I was recently working on a way to allow unprivileged users, to take advantage of bubblewrap to run regular system images that are using systemd. To do so, it was necessary to modify bubblewrap to keep some capabilities in the sandbox. Capabilities are the way, since Linux 2.2, that the kernel uses to split the root power into a finer grained set of permissions that each thread can have. Together with Linux namespaces it is fine to leave unprivileged users the possibility to use some of them. To give an example, CAP_SETUID, which allows the calling process to make manipulations of process UIDs, is fine to be used in a new user namespace as the set of permitted UIDs is restricted to those UIDs that exist in the new user namespace. ...

Every programmer at some point gets in touch with the Brainfuck programming language and how surprising is that very few instructions are needed to have a Turing complete language, 6 is the case of Brainfuck (plus other 2 for I/O operations). I have recently found an old project of mine that I have used to learn how to write a GCC frontend, it took a while to adapt it to work with a newer GCC version. The code is available on github. The only positive side of this project, if any, is that it can be easily used as a starting point on how to add a frontend to GCC, or in this case, to compile a Brainfuck interpreter written in Brainfuck! ...

rpm-ostree, used together with OStree, is a powerful tool to generate immutable images for .rpm based systems, why not to use it for generating Docker images as well? rpm-ostree already supports the generation of a Docker container tree, that can be feed to Docker almost as it is; ostree-docker-builder instead is a new tool to make this task simpler. The following JSON description is enough to create an Emacs container using rpm-ostree based on Fedora-22. ...

coming as a surprise, this year we have got 4 students to work full-time during the summer on wget. More than all the students who have ever worked for wget before during a Summer of Code! The accepted projects cover different areas: security, testing, new protocols and some speed-up optimizations. Our hope is that we will be able to use the new pieces as soon as possible, this is why we ask students to keep their code always rebased on top of the current wget development version. ...

This tutorial shows how to create a QCOW2 image that can directly imported via virt-install to test out Fedora 22 Atomic starting from a custom OStree repo. To create the image, we are going to use both rpm-ostree and rpm-ostree-toolbox. Ensure they are installed as well as Docker, libvirtd and Vagrant-libvirt. The first phase consists in generating the OStree repo that is going to be used by the image. We can use directly the files from the fedora-atomic project as: ...

These are the steps to setup the current website in a Docker container: 1 2 3 4 wget -O- https://github.com/docker/compose/releases/download/1.2.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose mkdir wordpress cd wordpress 1 2 3 4 5 6 7 8 9 10 db: image: mysql:5.5 environment: MYSQL_ROOT_PASSWORD: "A VERY STRONG PASSWORD" web: image: wordpress:latest ports: - "80:80" links: - db:mysql 1 /usr/local/bin/docker-compose up