Archive
Flock 2015 – Report Day0 and Day1
Day 0:
I almost missed my flight at the san jose airport, My flight was supposed to take off by 2:55. There was a big queue at the airport around 2:30 pm. I cleared TSA around 2:40 pm. It was tight!
Met Major Haydon(major.io) at the Chicago midway (MDW) airport. Major was a keynote speaker at flock. He works for rackspace. The flight from chicago landed about 12:45 am in the morning at Rochester. We took a cab to the hotel. The hotel is 10 minutes from the airport. My roommate aditya was jetlagged and was already sleeping. Managed to slip into the bed without waking him up!
Day 1:
FPL (fedora project leader) Matt Miller did his usual state of the union in the morning. As the name implies it is about the current state of fedora project. More details about the state of union can be seen at http://fedoramagazine.org/state-fedora-2015-edition/
Koschei – Continuous integration for fedora
The next talk i attended was Koschei – Continuous integration for fedora packages by mikolaj. koschei is a CI system that schedules koji builds and make sure that fedora packages are sane all the time. https://github.com/msimacek/koschei. koschei uses koji scratch builds. The scheduler of koschei is intelligent enough to schedule these builds when koji slaves are not busy.
The main motivation of koschei is to find FTBFS early and inform maintainers. The production instance of koschei is here https://apps.fedoraproject.org/koschei. More details about this presentation is here https://github.com/msimacek/koschei/blob/master/doc/pp/koschei.tex
Koji 2.0
Mike McLean (https://fedoraproject.org/wiki/User:Mikem) wrote the first line of code when dinosaurs were still alive :). Now he has plans to clean up koji under koji 2.0 project. koji is used to build packages for fedoraproject, it has many roles (rpm building, compose etc).
Mike wants to use python 2.6 for koji-2.0. It will also has support for python 3.0 using python-six. Most of the audience including me suggested that python 2.7 as it is the latest stable in 2.x release. Mike explained that he wants to support koji-client on RHEL6 which comes with python 2.6.
Luke Macken in the audience went even further and suggested that the server side of koji should drop support for python 2.x and entirely written using python 3.0.
some of the koji 2.0 proposed features include,
- build namespaces (re-building same nvr again and again)
- json-rpc
- content generators (https://fedoraproject.org/wiki/koji/ContentGenerators)
- other type of build process to feed into koji
- robust metadata import
- Following build types are proposed
- rpm builds
- maven builds
- windows builds
- image builds
- + ???
Mike’s email about koji2.0 to koji-devel mailing list is available here https://lists.fedorahosted.org/pipermail/koji-devel/2015-June/000000.html
His talk sides are available here https://mikem.fedorapeople.org/Talks/flock-2015-koji-2.0/
Reproducible builds using koji
Reproducing koji builds was scheduled at 2:30 pm, It was the 3rd talk of the day.
In this talk Mike Mclean talked about debian’s reproducible build project
https://wiki.debian.org/ReproducibleBuilds. Builds are not (binary) reproducible because of following reasons,
- Timestamps embedded into binaries during build time
- Usage pseudo-random numbers to generate code data
- Umask/uid
- uname, hostname, username
- locale
- Timezone
Mike was really appreciative of the debian reproducible build project. The debian team is actively upstreaming their patches. Some one in the audience noted that debian still allows builds created on developer workstations to be uploaded and deployed to repositories. So by having reproducible builds the binaries are easily verifiable.
Then Mike went on to talk about what it would take to make builds reproducible on koji He talked about using task-id/repo-id to preserve the state of repo’s and recreating them at a later point. He also noted that the rpm metadata included in the rpm package makes it impossible to reproduce.
One of the audience suggested that the metadata could be moved out of the
package in future to enable reproducible builds. Mike noted that he is very busy with koji-2.0 work and does not want to spend more time on making builds reproducible. However he was open to helping out someone who is willing to take on this challenge. Any takers?
Super privileged containers
The last talk of the day i attended was about ‘super privileged containers’ by Dan Walsh. Dan, showed lot of funny gif’s about selinux and docker before starting the presentation.His presentation is available here https://dwalsh.fedorapeople.org/Presentations/SPC/
RedHat’s atomic host doesn’t support yum install. Redhat customers often want some utlity to be included in the atomic host and Redhat wants atomic host to be minimal as possible. As you one can see these two goals are competing with each other. The current rule to include an utlity in the atomic host is to prove that it won’t work in a container.
Customers want to ship an application that will manage a host or manage other containers. Enter Super privileged container aka SPC.
A super privileged container must have the following
- It should be a privileged container
- will enable all capabilities (CAP_*) in the container
- disable selinux separation (it will lie in the container)
- disable user namespace;
- disable mounting read only file systems;
- Allow creation of linux devices.
- Specific namespaces like network, ipc and pic should be disabled
respectively using (‘–net=host;–net=ipc,–pid=host) - SPC should mount /run into /run of the container and let container process to communicate with system dbus, systemd, or even docker daemon (docker run -v /run:/run)
- The entire host file system should be shared inside the container using
docker run -v /:/host -e HOST=/host.
To do all these, you have to run a big docker command:
"/usr/bin/docker run -t -i --rm --privileged -v /:/host -v /run:/run -v
/etc/localtime:/etc/localtime --net=host --ipc=host --pid=host -e HOST=/host
-e NAME=fedora-spc -e IMAGE=fedora fedora /bin/sh"
As you can see this is a big command, redhat has introduced a ‘rheltools’ container image with project atomic. This tools image includes strace,gdb,sosreport and other tools The atomic command now allows users to run containers in SPC mode.
'atomic run --spc rheltools /bin/sh'
The big docker command now is encapsulated into a small atomic command.
Atomic command wraps os-tree as well,
– atomic host upgrade
– atomic host rollback
– atomic host status
Today there is not a good way to tell your users how to run the container you created. Some container may need special privileges for example ntpd needs –cap_add SYS_TIME; Without SYS_TIME ntpd container will break; To solve this problem redhat has introduced container image labels. Redhat added labels patch to docker which allows developer to create labels during container build time.'LABEL RUN docker -d -n ntpd --cap_add SYS_TIME IMAGE'
Now, ‘atomic run ntpd’ will automatically read this image json metadata and run the container appropriately.
Dan also distributed his container coloring book at the talk. If you want a pdf version of it please see http://bit.ly/1KuB1c6 (pdf). If you haven’t see his selinux coloring book checkout http://bit.ly/1K4Kueu. These books are designed by mairin duffy.
After the conference, we had a game night where we played board games until 11 pm
Conference Report – Flock 2014
This years Flock conference was held at Prague, czech republic. This was my first trip to the Europe. I needed a Visa for this trip unlike my American friends. I got the visa in the last minute from the Consulate of czech republic, Los Angeles. The Visa officer needed an insurance of minimum 50000 Euro with Medical reparation and Evacuation converge. My company Yahoo was able to get that sorted in time. I attended lot of talks and workshops at Flock. I took notes on some of the sessions i attended. Here is my conference report
Status of COPR build service – by Miroslav suchy
https://fedorahosted.org/copr/wiki/UserDocs
https://copr.fedoraproject.org/
COPR is an automatic build system to build rpms. COPR allows users to select
Arch and system (target) , accepts src.rpm from the user and generates binary
rpms in the backend and creates repo as well.
Unlike koji COPR doesn’t need a ‘fas’ account to build rpms. Technically any one
can build rpms on COPR.
Due to public nature of COPR it uses Virtual Machines to build rpms. A virtual machine
is setup and mock is used inside the VM to build the rpm.
COPR currently runs on openstack. There are 1381 projects, 25k builds, 250 G of data,
and 1 TB/month data transfered in COPR as we speak. Koji/OBS was evaluated to use in
COPR but the decided against it for some reasons. OBS signing daemon might be used
with COPR to sign rpms in future.
* Mock is kind of slow, there is a GSOC project to speed it up using LVM snapshots *
* Radek Holy is working on docker for rpm builds *
It is important to note that redhat software collections are built on COPR. There
is a jenkins plugin available for COPR which lets users to trigger COPR builds
from jenkins. There is a copr-cli available to builds.
ARM architecture support, package signing are in future TODO.
Here is the video of the talk
UEFI – The great satan and you – by Adam
I am a fan of UEFI. I have been closely following UEFI development and support in Linux for a while. If you do not know about UEFI, Adam Williamson has an impressive write up about it at https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/
Adam started with what is UEFI and then moved on to explain how older BIOS works. Adam’s talk focused on Desktop machines
How BIOS work?
– Boots the 1st sector of disk
– Chainloading
– The bootloader is sneaked in between MBR and the partition
UEFI
– Defines an EFI executable format.
– EFI executable is copied into FAT filesystem and the firmware can read it
– UEFI boot manager is used to change the boot order and EFI variables.
– There is a fallback path if the EFI executable is not found on the specified path
– Supports BIOS mode named CSM. CSM is going away soon.
Adam proposed following tests to tell if your machine is UEFI?
– Machine is Windows 8 pre-installed. Then it is must have UEFI in it.
– The “firmware” has mouse support then it is UEFI (BIOS can’t do that sh*t)
Adam showed some screenshots of crazy UEFI firmware UI implementations that makes identifying it more difficult for the user.
While multibooting adam asked the users to install both OS in same mode. Mixing BIOS (CSM) and UEFI is discouraged and unsupported in Fedora.
Adam then proposed following special commands to write a USB stick with EFI support
– dd: use dd on usb sticks
– livecd-iso-to-disk: pass –efi –format -reset-mbr
– liveusb-creator: well..it might work
– DO NOT use Unetbootin
Adam then revealed that, Peter Jones and Matthew Garret lobbied Microsoft to enable option to disable secure boot. They even have weekly calls. The engagement with microsoft has been very professional. Microsoft takes UEFI signing seriously.
I asked peter about completely removing microsoft key from the firmware. He said it is a “bad” idea because ROM based firmwares won’t load and they are signed by the Microsoft key. He also mentioned that there is a complex workaround to this problem. The workaround is generating the hash of the firmware and adding it to the shim whitelist.
Here is the video of the talk
Fast OS Deployment with Anaconda – By Arun S A G (me)
I presented and showed a demo on how to deploy operating systems fast on bare metal
machines. The entire talk was well received by the anaconda team.
The demo showed installations of a Fedora 21 (pre release) VM which took 2 minutes
to complete. Most of the audience were pleasantly surprised.
- There were some interesting thoughts and area for improvements came out of this talk
- RedHat developer proposed me to make use of the cloud kickstart file which has very minimal set of package
- Peter Jones suggested that anaconda can/should be modified to produce tarballs as one of the build targets (anaconda right now supports iso targets)
- Most of the installation time was spent on generating ramdisk. So peter suggested we should pre-generate the ramdisk and include it in the tarball.
- rpmdb cache needs to be removed from the tarball.
- Adam williamson asked me to share some sample kick-start files from work so that we can well test different use cases before releasing anaconda.
- Automating the biosboot partition during the installation process was discussed
Here is the video of my talk
Overall it was a wonderful conference. Thanks Yahoo and RedHat for sponsoring my travel and accommodation. It was good to see lot of volunteers again and i had a good time in Prague, Czech republic. I am looking forward to Flock 2015
Flock 2013 – Fedora at Yahoo
This is kind of a late post. I spoke at Flock. It was about “Fedora At Yahoo!” – How we use Fedora in desktops and laptops at Yahoo!
Here is the presentation http://sagarun.fedorapeople.org/misc/FedoraAtYahoo.pdf