FESCo Election: Interview with Till Maas (till)

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, June 7th and closes promptly at 23:59:59 UTC on Wednesday, June 13th, 2018.

Interview with Till Maas (till)

  • Fedora Account: till
  • IRC: tyll (found in #fedora-releng #fedora #fedora-devel #fedora-admin #fedora-apps #fedora-social #fedora-de #epel)
  • Fedora User Wiki Page

Continue reading “FESCo Election: Interview with Till Maas (till)”

Council Election: Interview with Till Maas (till)

This is a part of the Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, May 31st and closes promptly at 23:59:59 UTC on Wednesday, June 6th, 2018.

Interview with Till Maas (till)

  • Fedora Account: till
  • IRC: tyll (found in #fedora-releng #fedora #fedora-devel #fedora-admin #fedora-apps #fedora-social #fedora-de #epel)
  • Fedora User Wiki Page

Continue reading “Council Election: Interview with Till Maas (till)”

Fedora Classic or is it Traditional?

automobile-automotive-beetle-163809

In FESCo ticket 1878, Matthew, our project leader, suggested to find a different name for the Everything directory that used to contain all pieces used to build all the other parts of the Fedora artifacts because there are now other artifacts that do things differently such as Fedora Modularity or Fedora Atomic. Also there are other artifacts such as Fedora Copr. Therefore it is nowadays only almost Everything. Regardless of the name we will choose for this directory, this also made me realize, that there is no name for Fedora artifacts that used to be Everything or the packages formerly known as Fedora. How would you call it? Is it Fedora Classic? Fedora Traditional? Does this have a negative connotation to you? Does it maybe mean, that there will be no Fedora Classic in five years? I am looking forward to your comments.

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.

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.