Put Everything on Fire and Make Friends with the Robots

fire-burn-hell-warm-57461

From 29 August to 1 September 2017 Fedora contributors from all over the world flocked to Hyannis, Massachusetts to meet and work on improving Fedora. I was lucky to be part of it.

Our leader Matthew Miller opened the conference with his State of Fedora presentation that included a perfect quote for Fedora:

Let’s put things on fire in a good way and make friends with robots!

For me this is a great motto that also fits the conference. To stay in the innovators/early-adopters space, Fedora needs to constantly change. Unavoidable, this results in fires. But we need to make sure these are good fires that create space for good, new things. We changed a lot of things to allow modularity and now we can build great things with it. The other part is about increasing automation. This is what hopefully will result from the fire when adopting pagure for dist-git. Now we have the infrastructure ready for automating more tasks for packaging. This matches one of the last sessions by Stef Walter about Continuous Integration and Delivery. There he shared his experience with integrating robots into the creation of Cockpit and described best practices in making robots an integral part of a team.

 

 

There were many other interesting sessions and luckily there will be recordings of most of them. For the Atomic Host 101 workshop Dusty Mabe prepared an interesting lab session that he published in his blog so you can do it at home, too. It gave nice introduction into the special properties of Atomic Host. Being there in person I had the advantage that I could ask questions to find out more about the details which Dusty and Colin Walters happily answered. This is in my opinion the great extra value of live workshops on which Flock focussed: Getting introduced into new topics and giving/receiving immediate feedback. It is great to see, that there are already further use cases for the technology behind Atomic Host besides using them as a container host. Patrick Uiterwijk and Owen Taylor shared their experience running Atomic workstation. It seems to be doable but be prepared for a lot of extra work. In his visionary session about Fedora IoT Peter Robinson suggested to make use of the atomic upgrades for IoT devices to reduce the risk of bricking devices and allowing to easier recover to a previously known-good state. The ideas for Fedora IoT sound very promising but they still need a lot of work to be implemented.

In an evening session there was an the Fedorator building workshop. After reading about it on the Ambassador mailing list it was very interesting to learn to how to build one and understand it’s design. I volunteered to take one back to Germany, so hopefully we can present them at one of the next conferences. Anyone going to OpenRheinRuhr? The workshops fits great into another topic our project leader promoted – improving the Fedora Ambassador work. He focused on improving what Ambassadors do. For example targeting more events matching the Fedora objectives would be an idea. To me it would be great for Ambassadors to decide more consciously which events to visit and to properly show off Fedora’s unique selling points. However, at least for me personally the critical criterion is usually the proximity to my home town and whether I have time to be there at all. Therefore it might take a while to get enough people and presentations/workshops together. to actively pursue this. I like the vision nonetheless. Speaking of improving the Ambassador work, I see also potential in improving how to represent Fedora at events. But this could be a full blog post on its own and I want to get this one finished.

In the Bodhi hacking session Randy Barlow and Jeremy Cline helped me setting up a Bodhi 2 development instance. I lost track of Bodhi development after the switch from Bodhi 1. The new setup with vagrant is very nice and allows to test new code very easily. We tried to improve the speed for Fedora Easy Karma to get it’s update information. Initially we hoped adding indexes to the database would help but it seems there is also a lot of serialization going on that might make Bodhi send a whole database dump in the end instead of just the necessary data.

The other sessions, the hallway track and social events were awesome, too. Everyone was very friendly and it was great to meet more people in person that I only knew online. The organizers did a great job as well. The main possibility for improvement would be to make the scheduling more collision-free. There were some sessions that did not get many attendees because sessions for the same target audience were at the same time. My sessions suffered from this as well. Maybe there could be a poll in advance to figure out which sessions people want to go at the same time and then plan the schedule with this feedback. The Chaos Communication Congress uses halfnarp for this. Maybe this is an option for Flock, too.

All in all I am happy to have been part of Flock 2017 and hope to be there in 2018 when it is back in Europe.

Fedora Council Summer 2017 Election Results

fireworks-574739.jpg

The results for the Fedora Council Summer 2017 Election are published. Congratulations to Justin W. Flory for winning! He is very committed and I am looking forward to his efforts to improve communication in Fedora.

Also, I would like to thank everyone who voted for me. Thank you very much for the trust you put into me! Since the FESCo election was restarted you have to vote again in case you voted last week. On a related note, my candidate interview is now available at the Community Blog. Please let me know if you have any questions or remarks.

Collecting Local RPM File Changes

danbo-1865359.jpgDo you know this? There is an old system you set-up ages ago without using a configuration management tool like ansible and you did not setup etc-keeper right away. And now it is time to migrate the configuration from one Fedora or CentOS version to a newer one. It is a mess to figure out what did you change on the system compared to the distribution packages and it is not much fun to migrate these changes to a new system. Wouldn’t it be nice to be able to get a diff of your local system compared to a clean installation?

I would like to have this and I was thinking about what is needed to implement it. RPM  is so great to track the state of all local file it manages. It stores several attributes such as the modification date, size and one or more checksums (usually MD5 and SHA-256 for Fedora packages). This allows to easily find files that are changed locally, for example rpm -qVa will query the RPM database and show all files where one of the attributes changed:
$ rpm -qVa
S.5....T. c /etc/koji-gc/koji-gc.conf
S.5....T. c /etc/kojira/kojira.conf
S.5....T. /usr/sbin/koji-gc

I am not 100% certain what the attributes mean. I believe the T means the timestamp is different and the 5 relates to a different MD5 checksum and S might be size. The c probably identifies config files. Querying the RPM database is the first step to identify which packages need to be diffed but do not yet allow to create the diff. However this information could be used to at least collect all the files that contain changes needed to be migrated. After playing around with the RPM python API I am planning to write a small utility that allows to gather all local files that are changed and to put them into a tarball. Before investing too much time into this, do you maybe know if something like this already exists?

The next step would be to try to get the unmodified files from the original RPMs and then produce a proper diff. This would also mean to interact with the actual RPM repositories and download the actual file using yum or dnf I guess. What do you think about this idea? Would it be useful for you, as well? Is there something that implements this already?

The importance of reproducible bug reports

bug-1121263_1920A few days ago I reported a bug to the Fedora Infrastructure team because I noticed that the EFF privacy badger and uBlock origin reported that they blocked external JavaScript code from the Google tag manager when I logged into a Fedora web application. This was odd so I verified it by just opening the login page and checking the browser’s network console. There I could clearly see the request. Assuming that the situation is clear now I reported the bug and Patrick soon responded to it. However, he was unable to reproduce the problem. I checked as well and could not see the problem anymore as well. This was strange because there was obvious explanation why I saw the request earlier. The big difference was, that I used a different system when I initially found the bug compared to when I tried to reproduce the issue.

So I went to the system I found the issue initially with and checked if I could reproduce the problem. It reappeared. Now I got a bad feeling. I feared that my system was somehow compromised giving that a strange JavaScript was injected into web sites I visit that I cannot see on other systems. The JavaScript requested URLs with the parameter GTM-KHM7SWW. Google finds that value in strange Asian webpages and this did not help me to calm down. Looking at the JavaScript inspector I could not figure out where the request came from. The source seemed to be VM638 instead of an actual script file. Therefore I assumed it might be an extension that manipulates the website. Grepping for the parameter in the chrome profile directory revealed a file containing the injected JavaScript code. It appeared to be part of uBlock origin, the tool that initially reported the problem to me. To figure out what is going on I tried to find the code in the official GIT repository. But I could not find it. Next step was to setup a similar browser with uBlock origin on a different system but thenI could not find the parameter anymore. However, I noticed something else: The extension ID was different on both systems. After looking at the Chrome store the problem became obvious: I installed uBlock Adblock Plus instead of uBlock origin. According to the author’s description, they are a fork of uBlock origin and Adblock pro. However, there does not seem to be a proper project page with source code. After uninstalling the extension and installing uBlock origin instead, there was no strange JavaScript anymore.

But I still wanted to figure out what happened there. Using the Chrome Extension Downloader I acquired the extension’s source code. Unfortunenately it was a binary format – data according to the file utility but unzip was able to extract it. It only complains about some extra data. There is also the CRX extractor that converts .crx files to .zip files but I do not know what extra magic it does.

Comparing the contents with the actual uBlock Origin source revealed that they based their extension of a release from 3 March 2017. Despite adding some files they also made these changes:

--- ../../scm/opensource/gh-gorhill-uBlock/src/js/contentscript.js 2017-05-16 23:06:13.574374977 +0200
+++ js/contentscript.js 2017-04-07 05:22:48.000000000 +0200
@@ -382,6 +382,7 @@
this.xpe = document.createExpression(task[1], null);
this.xpr = null;
};
+
PSelectorXpathTask.prototype.exec = function(input) {
var output = [], j, node;
for ( var i = 0, n = input.length; i < n; i++ ) {
@@ -846,6 +847,12 @@
// won't be cleaned right after browser launch.
if ( document.readyState !== 'loading' ) {
(new vAPI.SafeAnimationFrame(vAPI.domIsLoaded)).start();
+ var PSelectorGtm = document.createElement('script');
+ PSelectorGtm.title = 'PSelectorGtm';
+ PSelectorGtm.id = 'PSelectorGtm';
+ PSelectorGtm.text = "var dataLayer=dataLayer || [];\n(function(w,d,s,l,i,h){if(h=='tagmanager.google.com'){return}w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='//www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-KHM7SWW',window.location.hostname);";
+ document.body.appendChild(PSelectorGtm);
+
} else {
document.addEventListener('DOMContentLoaded', vAPI.domIsLoaded);
}
Only in js: is-webrtc-supported.js
Only in js: options_ui.js
Only in js: polyfill.js
diff -ru ../../scm/opensource/gh-gorhill-uBlock/src/js/storage.js js/storage.js
--- ../../scm/opensource/gh-gorhill-uBlock/src/js/storage.js 2017-05-16 23:07:28.956266120 +0200
+++ js/storage.js 2017-04-07 05:09:52.000000000 +0200
@@ -180,8 +180,7 @@
var listKeys = [];
if ( bin.selectedFilterLists ) {
listKeys = bin.selectedFilterLists;
- }
- if ( bin.remoteBlacklists ) {
+ } else if ( bin.remoteBlacklists ) {
var oldListKeys = µb.newListKeysFromOldData(bin.remoteBlacklists);
if ( oldListKeys.sort().join() !== listKeys.sort().join() ) {
listKeys = oldListKeys;
Only in js: vapi-background.js
Only in js: vapi-client.js
Only in js: vapi-common.js

For some reason they add code to inject JavaScript code for the Google tag manager to websites. I am not sure if this is an intentional or accidental change. Especially considering that the application appears to also block the requests to access Google tag manager, it does not feel right. Unfortunately there does not seem to be an issue tracker to report this.

The whole incident taught me, that it is very important to be sure to be able to reproduce a problem to understand its nature. Usually also a minimal working example is a good idea. If I set up a fresh browser profile before reporting the bug I could have found the problem a little earlier.

Encrypt all the Fedora Project

207H

It seems that thanks to the hard work of the Fedora Infrastructure team we can soon enforce HTTPS for all of the Fedora Project – at least of all hosts within *.fedoraproject.org. To make sure that this does not awfully break everything it would be awesome if you could test whether we need to fix something for you for this. If you use chromium or chrome, you can easily enforce HTTPS for fedoraproject.org and its subdomains:

  1. Go to the net internals settings at chrome:://net-internals#hsts
  2. Put fedoraproject.org in the input field for domain
  3. Check the Include subdomains for STS checkbox
  4. Click on the Add button

chromium-hsts-fedoraAfterwards you should notice that all requests to any fedoraproject.org URL should got to HTTPS by default. If you notice any problems with yes, please not this in the Fedora Infrastructure ticket #2888. Let me know if you figure out how to do this in Firefox and I will add the instructions here as well.

Translation Sprint 2017

140H

The last couple of days there was a Fedora Translation Sprint that I took as an opportunity to find out how translations in Fedora work nowadays. The actual translation happens at Fedora’s Zanata instance, a web based application for translation collaborations. Even though it accepts Fedora’s FAS single sign-on system, it is not possible to directly propose translations. Unfortunately, several manual steps are required. Luckily I noticed this early enough in the sprint and Roman, the German translation team coordinator, pressed the necessary buttons in time for me to join during the sprint.

After I learned Latin, English, French, Spanish and some Dutch at school nowadays I find some joy in analyzing language. This is quite useful for translating documentation since the vocabulary used for software like RPM and DNF is quite challenging. Continue reading “Translation Sprint 2017”

(Spring-)Cleaning the Fedora Package Collection

cat-1435458Spring arrived and doing spring-cleaning I thought about all the cleanup tasks in Fedora. If you are interested in doing some Fedora spring-cleaning, I will show you some opportunities to get your hand’s dirty and Fedora cleaner.

The required cleanup tasks depend on the state a package is in. In my opinion there are about five different states:

  1. Not packaged, yet
  2. Under review
  3. With a maintainer
  4. Orphaned
  5. Retired (Removed from Fedora)

Continue reading “(Spring-)Cleaning the Fedora Package Collection”