August 24, 2016
I came back from Karlsruhe last week, where GUADEC 2016 took place.
It was a wonderful event. Even though it was only my second GUADEC, I felt at home in this community, meeting with old and new friends.
The talks were excellent, but a few really resonated with me:
- Cosimo tooks us for a fascinating dive into the anatomy of Endless OS, explaining how they built Endless OS out of ostree, and soon flatpak;
- Bradley told us about why he doesn't use GNOME but everyone else should, which reminded us why GNOME is so important to bring software freedom to everybody, not just us geeks;
- Jonathan's An asynchronous internet for GNOME, about the Internet-related constraints they face when deploying Endless computers, which are the same as what we face with Bibliothèques Sans Frontières / Libraries Without Borders;
- Rosanna gave us a look behind the curtain — how the Foundation runs, which made it clear I had no idea how the Foundation actually works behind the scenes; (but now I do!)
- Owen showed us how we could rework the desktop distribution, presenting an exciting possible future for GNOME with ostree and flatpak;
Of course the most interesting discussions are sometimes the ones you have outside of the planned presentations, and probably one of the best for me was when Stef Walter showed me the amazing work they've done on the Cockpit project, especially since I should be able to reuse a lot of that for my work with Bibliothèques Sans Frontières.
Other than that I spent quite some time hacking on a few things:
- I reworked
flatpak-builderhandles git submodules as that was blocking us from building GNOME Games nightly flatpaks;
- I also fixed and improved the
flatpak-buildermanifests for GNOME Games and Nautilus. Hopefully we'll get nightlies for the two apps real soon;
- I made various improvements to the GNOME Games code, among which using libsoup instead of gvfs-http (as the latter doesn't work well inside a flatpak sandbox), improving the resume dialog, better handling failures to resume a game, and inhibiting the screensaver/logout while playing;
- I fixed exempi to make it support the build API, which makes it much easier to build inside a flatpak;
Overall, I spent most of the week on flatpak-related issues, which is a technology I'm growing to love more and more, and which could revolutionize the way we distribute applications for the Linux desktop.
And all those fixes allowed me to spend most of the trip back home playing in GNOME Games, running from a flatpak build of git master, with a PS3 gamepad. Obviously that's the only reason I worked on all of this! 😜
All in all, this GUADEC was a huge success, thanks to the efforts of the organization team.
Looking forward to the next one in Manchester!
I’ve been using Amazon S3 as a CDN for the LVFS metadata for a few weeks now. It’s been working really well and we’ve shifted a huge number of files in that time already. One thing that made me very anxious was the bill that I was going to get sent by Amazon, as it’s kinda hard to work out the total when you’re serving cough millions of small files rather than a few large files to a few people. I also needed to keep track of which files were being downloaded for various reasons and the Amazon tools make this needlessly tricky.
I signed up for the free trial of S3stat and so far I’ve been pleasantly surprised. It seems to do a really good job of graphing the spend per day and also allowing me to drill down into any areas that need attention, e.g. looking at the list of 404 codes various people are causing. It was fairly easy to set up, although did take a couple of days to start processing logs (which is all explained in the set up). Amazon really should be providing something similar.
For people providing less than 200,000 hits per day it’s only $10, which seems pretty reasonable. For my use case (bazillions of small files) it rises to a little-harder-to-justify $50/month.
I can’t justify the $50/month for the LVFS, but luckily for me they have a Cheap Bastard Plan (their words, not mine!) which swaps a bit of advertising for a free unlimited license. Sounds like a fair swap, and means it’s available for a lot of projects where $600/yr is better spent elsewhere.
Does anybody have a Devo RC transmitter I can borrow for a few weeks? I need model 6, 6S, 7E, 8, 8S, 10, 12, 12S, F7 or F12E — it doesn’t actually have to work, I just need the firmware upload feature for testing various things. Please reshare/repost if you’re in any UK RC groups that could help. Thanks!
As you might know, Fedora released its 24th version at the end of June! Recently, the Fedorans in Singapore had a party to celebrate the release. The release party was not only to celebrate its release, but also to commemorate Fedora’s open source journey so far. We invited people from different diverse background to join us for a night of fun and open conversations (Singapore is a cosmopolitan country!)
We had a RSVP of over 50 folks and expected more to join in. We set up the Fedora banners and were also ready to give out DVDs and stickers. However, on the day itself, there was a dropout rate of 60% and only around fifteen folks turned up. Most of the folks that turned up were students interested in learning more about Fedora. Nevertheless, it was a cozy and warm party that everyone felt pretty comfortable with.
Getting Singapore party started
Everyone had some pizzas, chips and drinks before the talks began. Strange thing that happened: one of the pizza delivery men got into a traffic accident and had his arm badly injured. The pizza company had to redo the pizzas and send another guy down. Hope he’s okay now. As for the talks, we had two talks lined for the party: a Fedora release talk and a Tails talk. The release talk was done by one of ambassadors in Singapore, Huiren Woo.
Interactive learning about Fedora
Our release party talk was focused on community and collaboration whilst still covering the new features and improvements in Fedora 24. At the end of the talk, we had a fun quiz to test out the knowledge of our audience and also to see if they were engaged in listening. We made use of an educational quiz tool, Kahoot, and allowed everyone to participate and win prizes. The top prize was a copy of The Open Organization with a signature from Jim Whitehurst.
These people were very smart and paid good attention to our talk! The other players also had lots of fun playing the quiz; some used nicknames such as “Bill Gates” and MSP (acronym for Microsoft Student Partner). At first, “Bill Gates” was leading the game but fortunately (and unfortunately), he lost to the tougher questions and got the 3rd prize, which was a copy of the OpenSource.com 2015 yearbook and Catalyst-In-Chief.
At the end of all the talks, most of the folks stayed behind and continued having conversations in small groups. We talked about B-tree filesystem (BTRFS), encryption, Wayland, Tor, and many more! Overall, it was quite a successful event with many engaged Fedorans. Thank you everyone for joining us for our release party!
ImageFactory is a tool, built on Oz, that is suitable for generating various types of operating system and cloud images. These images can be generated in a variety of different formats. Those include the Docker image format and the qcow2 image format.
This article shows you how to build a Fedora Rawhide image in Imagefactory, then run it in a container via Docker. In the next article, you’ll see how to do the same thing, except with building qcow2 images for VMs.
Why Build a Fedora Rawhide Image?
Fedora Rawhide is, as you know, a constantly evolving version of the Fedora operating system that has nightly updates. While you can technically upgrade your OS to Rawhide, most users prefer to stick to the latest Fedora release because Rawhide is not 100% guaranteed to be stable. Still, you may want to test various tools and software on Rawhide, or even play around with Rawhide to see what it has to offer. In these cases, you will likely find container images and VMs useful and appealing.
This section gives a brief overview of ImageFactory and how it works. This is not a comprehensive overview of the tool. Instead, the main purpose of this section is to get you comfortable with how this tool works on a high level.
Before we begin, make sure that you have installed a working version of ImageFactory. If you are unsure how to install and setup ImageFactory,
$ sudo dnf install imagefactory imagefactory-plugins-TinMan imagefactory-plugins-Docker
What do I need to build an image?
You will need two files: a kickstart file and a template.
The Kickstart file is used to tell ImageFactory what to install and how to install it. Below is the official Kickstart file for creating a (minimal) Fedora docker base image: https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-docker-base.ks
To download the file to your current directory,
$ wget https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-docker-base.ks
The template is used to tell ImageFactory which OS you want to install (version, architecture, etc.) and where to install it from. It essentially describes what to build. An example template can be seen below:
<template> <name>fedora-rawhide</name> <os> <name>Fedora</name> <version>26</version> <arch>x86_64</arch> <install type='url'> <url>https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/</url> </install> <rootpw>password</rootpw> </os> </template>
Templates can have either a .tdl or a .xml extension. (Note: You may want to change the root password to something more secure.)
Modifying Oz to work with ImageFactory
Since ImageFactory is built on Oz and you may not have enough RAM available in Oz to generate an image, you will have to modify your Oz configuration, which is located at /etc/oz/oz.cfg.
Here is the default oz.cfg file:
[paths] output_dir = /var/lib/libvirt/images data_dir = /var/lib/oz screenshot_dir = /var/lib/oz/screenshots # sshprivkey = /etc/oz/id_rsa-icicle-gen [libvirt] uri = qemu:///system image_type = raw # type = kvm # bridge_name = virbr0 # cpus = 1 # memory = 1024 [cache] original_media = yes modified_media = no jeos = no [icicle] safe_generation = no
Edit the line which says #memory = 1024 and change the value to 2048. That should be sufficient to build an image. You can run this command to replace the line:
$ sudo sed -i -e 's/# memory = 1024/memory = 2048/' /etc/oz/oz.cfg
Building a Docker container image
The general command for building a base image is:
# imagefactory --debug base_image --file-parameter install_script <kickstart> <template> --parameter offline_icicle true
- The install_script parameter is self explanatory — it tells Imagefactory which files it should use to build your image with.
- The offline_icicle parameter tells Oz (via Imagefactory) to use features of libguestfs to mount the image offline, chroot into it, then execute an RPM command. (Normally, Oz derives this information by launching a throwaway version of your image, ssh-ing into it, then running an RPM command. However, because we are building a container image, the actual output is not something that can be booted as a VM, which is why we must derive the ICICLE “offline”.)
This process will take more than 10 minutes to run if you do not have a cached copy of the rpms in ImageFactor. Otherwise, it should take anywhere from 5-10 minutes to complete.
Once the process is finished, it prints the ID of the image you just created. The final output will look something like this:
============ Final Image Details ============ UUID: 17206f41-5bd8-4578-84b9-a3fffc1cd168 Type: base_image Image filename: /var/lib/imagefactory/storage/17206f41-5bd8-4578-84b9-a3fffc1cd168.body Image build completed SUCCESSFULLY!
Note: If the image build fails, then most likely Rawhide is broken — in which case, you may want to run the tutorial using the latest Fedora release. At the time of this article, that’s Fedora 24. The URL for the F24 repository is https://dl.fedoraproject.org/pub/fedora/linux/releases/24/Everything/x86_64/os/. You can replace this URL with the URL in the template above. (Be sure to change the Fedora release number, etc. so your image information is accurate!) On the other hand, if you receive an SELinux error, then try running
setenforce 0 in your terminal.
Preparing the image for Docker
Next, we need to “docker compress” our image in order to prepare it for loading into Docker:
# imagefactory --debug target_image --id <UUID> docker --parameter compress xz
This time, replace UUID with the UUID printed out, not the Image filename.
Once this process completes, you now have your Docker base image!
To load your new image into Docker:
docker load -i full/path/to/compressed/image/filename
August 23, 2016
Open source is the new trend. When major corporations are moving towards open architecture by using open source tools and even pushing their internal projects into open source, it makes your contributions especially worthy. But before starting with contributing, many people face the same common set of questions. How they can start, how should they introduce themselves in the community, and where they can contribute. To answer these questions, I planned a session on free and open source software (FOSS) and Fedora at the in Delhi, India.
During the planning phase, I got in touch with Sumantro, who is himself an open source enthusiast and contributing to various open source projects including the Fedora Project. With his help, we planned the agenda for the session and gathered the resources to conduct the session. On 12th August, 2016, this session on FOSS and Fedora was conducted to:
- Answer these questions
- Bring up new people in the open source arena
- Show where they can contribute, learn and make an impact
Starting the day in Delhi
The session started with small questions. People who have tried their hands on contributing to open source shared what problems they faced during their journey. The answers to the questions ranged from having issues working with the codebase of the projects to problems in figuring out where to start from.
During the session, the main focus was to make the participants aware about what FOSS is and how it is beneficial to the community. The common misconception about freeware and FOSS being the same was also cleared during the session. During the session, a brief overview was presented to the participants about how they can start with their open source journey. We walked them through from identifying the project where they want to contribute to sending their introduction mails in the mailing lists of the project. The session moved on with the topic about where the participants can contribute and what areas of contribution they can work in (both technical and non-technical). Awareness was raised that a contributor doesn’t need to possess the knowledge of coding to get started with contributions in the project.
After the introductory session on FOSS, we went ahead with our agenda and introduced the Fedora Project and the community behind it: what the Fedora Project is, what its mission is, and how the participants can get started with Fedora. The participants were guided upon how they can create their identity on the Fedora Project by signing up on FAS. They could then use that identity to get access to various Fedora applications and resources. The session on Fedora moved on with the introduction on how the contributors can get to the mailing list and introduce themselves to the community. There, they can get help about starting their contributions. The main focus during the session on Fedora was to introduce the participants to the Fedora Quality Assurance (QA) team and release validation testing.
Extending on the basic idea, we introduced Bodhi and package testing. Through a live demonstration, participants learned how they can start with package testing. The demo consisted of how to log into Bodhi using FAS and then enabling the
updates-testing repository on Fedora to get the packages in testing. An overview of the karma system was provided to the participants where they were told about what karma points mean and how they should give karma. The session proceeded with an overview of release validation and why it is important. The different development channels in Fedora, like Rawhide and branched, were introduced to the participants and what they mean. A demo of release validation using
relval was provided to the participants.
Introducing Git and more questions
The next session for the event was focused on getting started with Git. Git is a version control system used by many individuals and corporations to manage their source code. It also keeps track of the changes made by other developers. During this session, participants were introduced with a basic Git workflow. How they initialize a Git repository, add a remote repository, and pull the project source code. Participants guided to making their first Git commits and how it all works. This included covering the associated benefits of this type of system. Moving on with the Git session, participants were introduced to how various open source projects use version control systems like Git to manage their source code and accept contributions.
The event ended with an open question-and-answer session. Participants asked a variety of questions regarding open source projects. These questions consisted of things like availability of paid opportunities in open source, competitions in open source, and more. Answering these questions, participants learned about programs like Google Summer of Code, various conferences that are organized by the open source projects, and the recognition model used by these projects.
Author credits: Saurabh Badhwar
August 22, 2016
I had one Raspberry Pi3 in my home office (actually it was missing for few months). Found it two nights back, and decided to put it in use. Best part is the on-board WiFi. This means I can put it anywhere in the house, and still access it. I generally use Raspbian on my Pi(s), so did the same this time too. After booting from a fresh SD card, did the following to install Music Player Daemon.
$ sudo apt-get update $ sudo apt-get upgrade $ sudo apt-get install mpd $ sudo systemctl enable mpd $ sudo systemctl start mpd
This got MPD running on the system, the default location of the songs directory is /var/lib/mpd/music. You can setup the location in /etc/mpd.conf file. But this time when ever I changed a song, the service stopped. I had to restart the service. After poking around for sometime, I found that I have to uncomment the following from the mpd.conf file.
I also changed the value of mixer_type to software, that enables volume control from the software. After a restart everything worked as planned. I have MPD clients on my phone (and also even on Anwesha’s phone, and on mother-in-law’s tablet), and also on laptop.
The above is the screenshot of the client on phone. On my Fedora laptop I installed a new client called cantata.
$ sudo dnf install cantata
If you have any tips on MPD, or on similar setups, feel free to comment, or drop a note on twitter/mail. Happy music everyone.
Looks like a fast release cycle. Issue #119 was important enough to force another quick bugfix release. This should be the last release in the 0.5.x milestone. New IPC, CentOS and RHEL 7 compatibility comming in the next!
- Fixed unknown descriptor type handling
Many thanks to the following people for contributions to this release and to the USBGuard project:
If you are using Fedora or the USBGuard Copr repository, run:
$ sudo dnf update usbguard
Signed release tarball can be downloaded from the USBGuard release page at GitHub:
Today, I am pleased to announce my new role as the Fedora Magazine editor-in-chief. After deciding to shift focus to other areas of the Fedora Project, I am receiving the torch from Ryan Lerch. Ryan has helped lead the Magazine, edit pieces from other contributors, contribute his own pieces, and decide strategic direction for the Magazine.
He leaves big shoes to fill, but I hope to offer my own leadership, creativity, and direction in coming years as well. I’d like to thank both Ryan, Paul Frields, and Remy DeCausemaker for their mentorship and guidance towards becoming involved with Fedora and the Magazine. I’m excited to have the opportunity to help guide the Fedora Magazine in how it fits with the rest of Fedora.
History of the Magazine
The Fedora Magazine began in late 2013, replacing the former publication, Fedora Weekly News. The Magazine delivers all official news and announcements for the Fedora Project, covers how-to guides on using software available in Fedora, and other general tips and tricks for using Fedora. The Magazine has had a large number of contributors assist in getting it off the ground and to where it is now.
A special thanks goes out to Ryan, Paul, and Chris Roberts for helping bring the Magazine to where it is today. There are surely many more names than these too worth mentioning, but it would be impossible for me to cover them all here.
Write for the Magazine!
Want to write your own article for the Magazine? Know a useful piece of software you want to share with other Fedora users? Want to write about how using Fedora made something easier for you? Or maybe your own “top 5” list of tools for doing an everyday task? Come write for us! If you’re interested, check out this guide about writing an article, and then how to write a pitch for the Magazine team to review.
The fourth annual Flock conference for Fedora contributors took place from August 2nd-5th in Krakow, Poland. Over 200 developers and enthusiasts from different continents met to learn, present, debate, plan, and celebrate. Although Fedora is the innovation source for a major Red Hat product (Red Hat Enterprise Linux), this event received “gold” level sponsorship from a sister community — openSUSE. openSUSE serves the same function for SuSE Linux Enterprise as Fedora does for RHEL. SUSE showed the fellowship that rules in the open source world, which is why we love it!
The first two days of Flock centered around presentations. The first step was to present numbers showing the past year’s accomplishments. This was day one’s opening keynote by Fedora Project Leader Matthew Miller. The number of contributors has reached 2000 and is growing. Miller also shared his goals for the upcoming year: convert to Python 3, start implementing modularity, and develop Fedora Hubs.
Then the day turned into dozens of breakout sessions.The hottest topics were containers, Project Atomic, security, outreach efforts, community building, and team updates and plans from around the Fedora community. In the evening, people could stay in the Flock hotel to play board games, or travel to the city center for guided tours. The guides were funny and taught us a lot about Polish culture and history. You’d never believe why they decided to keep a big city tower in a time when citizens so poor they were breaking buildings to sell bricks.
On day two, a second keynote was delivered by Radosław Krowiak about teaching programming for children at Akademia Programowania in Krakow. The talk was about much more than just programming, though; it was about creativity. Krowiak stated that scientific subjects like engineering, math, or physics, aren’t taught in creative environments and aren’t considered cool. Therefore, kids don’t realize how important these subjects are. Still, what was the most awe-inspiring “aha” moment of this session? The results of a creativity test designed for NASA by George Land. According to Land’s testing, by reaching adulthood, we only retain 2% of the creativity we had as five-year-olds.
Krowiak explained most educational systems strip us of inventive thinking and implant a conventional “This is how it’s always been done” mindset. The setting for this talk was perfect, since Flock offers a solution to this problem. The conference helps you join a community that creates original hacking solutions for collaboration. That community is also part of the driving force in the major industry of the century. Once again, dozens of sessions rounded out the day. The evening program of day two was a boat trip on a river in Krakow. Could it get more awesome?
The last two days shifted from theory to practice, and from ideas to planning. The workshop schedule started with the largest group of lightning talks yet at Flock. On days three and four, you could build your first module, a kernel, an official OpenShift Origin instance on Fedora, a Fedora badge, or a Fedora containers library. Alternatively, you could help plan Fedora security, documentation, budget, marketing, Fedora infrastructure, or meet the Fedora Ambassadors Steering Committee (FAMSCo). The sequence of three evening events ended with class, in a local Krakow brewery.
Flock organizers went to great effort to land a first class event. The community showed they go the extra mile to make attendees feel welcome and help you get involved. Are you creative? Do you like learning new technology and meeting new people? Are you good with languages? If you answered at least one yes, Fedora can be for you.
Here are some parting comments from attendees:
It was amazing event with a lot of information. Thanks to everybody and remember that #fedoralovespython! — Lumír Frenzy Balhar
Feeling the post-#flocktofedora mix of energized and exhausted. Thanks to everyone who makes this conference so amazing every year! — Matthew Miller
It was amazing [sic] to be part of it! — Redon Skikuli
For more details, check out the videos, a list of blog posts written about Flock, pictures, or the Twitter feed. You can explore contributor options, read a contributor guide (or a shorter PDF guide), or try Fedora itself. You can also contact the Marketing team.
I can't think of anyone I mentored where a paycheck wasn't involved. There are people in the community I've given advice to, sometimes for an extended period of time, but I would hesitate to claim I was a mentor. Now I think just equating this to a paycheck would be incorrect and inaccurate. There are plenty of mentors in other organizations that aren't necessarily getting a paycheck, but I would say they're getting paid in some sense of the word. If you're working with at risk youth for example, you may not get paid money, but you do have satisfaction in knowing you're making a difference in someone's life. If you mentor kids as part of a sports team, you're doing it because you're getting value out of the relationship. If you're not getting value, you're going to quit.
So this brings me to the idea of mentoring in the community.
The whole conversation started because of some talk of mentoring on Twitter, but now I suspect this isn't something that would work quite like we think. The basic idea would be you have new young people who are looking for someone to help them cut their teeth. Some of these relationships could work out, but probably only when you're talking about a really gifted new person and a very patient mentor. If you've ever helped the new person, you know how terribly annoying they become, especially when they start to peak on the Dunning-Kruger graph. If I don't have a great reason to stick around, I'm almost certainly going to bail out of that. So the question really is can a mentoring program like this work? Will it ever be possible to have a collection of community mentors helping a collection of new people?
Let's assume the answer is no. I think the current evidence somewhat backs this up. There aren't a lot of young people getting into things like security and open source in general. We all like to think we got where we are through brilliance and hard work, but we all probably had someone who helped us out. I can't speak for everyone, but I also had some security heroes back in the day. Groups like the l0pht, Cult of the Dead Cow, Legion of Doom, 2600, mitnick, as well as a handful of local people. Who are the new heroes?
Do it for the heroes!
We may never have security heroes like we did. It's become a proper industry. I don't think many mature industries have new and exciting heroes. We know who Chuck Yeager is, I bet nobody could name 5 test pilots anymore. That's OK though. You know what happens when there is a solid body of knowledge that needs to be moved from the old to the young? You go to a university. That's right, our future rests with the universities.
August 21, 2016
Tomorrow, August 22, 2016, marks the end of the Google Summer of Code 2016 program. This year, I participated as a student for the Fedora Project working on my proposal, “Ansible and the Community (or automation improving innovation)“. You can read my original project proposal on the Fedora wiki. Over the summer, I spent time learning more about Ansible, applying the knowledge to real-world applications, and then taking that experience and writing my final deliverable. The last deliverable items, closing plans, and thoughts on the journey are detailed as follows.
The last deliverable items from my project are two (2) git patches, one (1) git repository, and seven (7) blog posts (including this one).
At the end of the summer, I was using a private cloud instance in Fedora’s infrastructure for testing my playbooks and other resources. One of the challenges towards the end of my project was moving my changes from my local development instance into a more permanent part of Fedora’s infrastructure. For these reasons, I had some issues with running them in a context and workflow specific to Fedora’s infrastructure and set-up (since I am not a sponsored member of the Fedora system administration group).
My current two patches were submitted to my mentor, Patrick. Together, we worked through some small problems with running my playbook in the context of Fedora’s infrastructure. There may still be some small remaining hoops to jump through for running it in production, but any remaining changes to be made should be minor. The majority of the work and preparation for moving to production is complete. This is also something I plan to follow up on past the end of the GSoC 2016 program as a member of the Fedora Infrastructure Apprentice program.
Reflection on GSoC 2016
As the program comes to a close, there’s a lot of valuable lessons I’ve learned and opportunities I’m thankful to have received. I want to share some of my own personal observations and thoughts in the hopes that future students or mentors might find it useful for later years.
Planning your timeline
In my case, I spent a large amount of time planning my timeline for the project before the summer. Once the summer began, my original timeline was too broad for having smaller milestones to work towards. My timeline on the student application was more broad and general, and while it covered the big points, it was difficult to work towards those at first. Creating smaller milestones and goals for the bigger tasks makes them easier to work through on a day-by-day basis and helps add a sense of accomplishment to the work you are doing. It also helps shape direction for your work in the short-term and not just the long-term.
For an incoming Google Summer of Code student for Fedora (or any project), I would recommend creating the general, “big picture” timeline for your project before the summer. Then, if you are accepted and beginning your proposal, spend a full day creating small milestones for the bigger items. Try to map out accomplishments every week and break down how you want to reach those milestones throughout the week. I started using TaskWarrior with an Inthe.AM Taskserver to help me manage weekly tasks going into my project. But it’s important to find a tool that works for you. You should reach out to your mentor about ideas for tools. If possible, your mentor should also have a way to view your agenda and weekly tasks. This will help make sure your goals are aligned to the right kind of work you are doing for an on-time completion.
I think this kind of short-term planning or task management is essential for hitting the big milestones and being timely with your progress.
Consistent and frequent communication is also essential for your success in Google Summer of Code. This can be different depending on the context of how you are contributing to the project. For a normal student, this might just be communicating about your proposal with your mentor regularly. If you’re already an active contributor and working in other areas of the project, this might be spending extra time on communicating your progress on the GSoC project (but more on that specifically in the next section).
Regardless of the type of contributor you are, one thing is common and universal – be noisy! Ultimately, project mentors and GSoC program administrators want to be sure that you are spending the time on your project and making progress towards accomplishing your goals. If you are not communicating, you will run the highest risk of failing. How to communicate can vary from project to project, but for Fedora, here’s my personal recommendations.
Even for someone like me who spends a lot of time writing already, this can be a difficult thing to do. But no matter how hard it is to do it, this is the cornerstone for communicating your progress and leaving a trail for future students to learn from you as well. Even if you’ve had a difficult week or haven’t had much progress, take the time to sit down and write a post. If you’re stuck, share your challenges and share what you’re stuck on. Focus on any success or breakthroughs you’ve made, but also reflect on issues or frustrations you have had.
Taking the time to reflect on triumphs and failures is important not only for Google Summer of Code, but even looking past that into the real world. Not everything will go your way and there will be times where you will be face challenges that you don’t know how to resolve. Don’t burn yourself out trying to solve those kinds of problems alone! Communicate about them, ask for help from your mentors and peers, and make it an open process.
Whether in a public channel, a meeting, or a private one-on-one chat with your mentor, make sure you are both active and present in IRC. Make sure you are talking and communicating with your mentor on a regular basis (at a minimum, weekly). Taking the time to talk with your mentor about your challenges or progress is helpful for them so they know what you’re up to or where you are in the project. It also provides a chance for them to offer advice and oversight into your direction and potentially steer you away from making a mistake or going into the wrong direction. It is demotivating when you’ve spent a lot of time on something and then later discovered it either wasn’t necessary or had a simpler solution than you realized.
Make sure you are communicating often with your mentor over IRC to make your progress transparent and to also offer the chance for you to avoid any pitfalls or traps that can be avoided.
Hang out in the development channels
As a Fedora Google Summer of Code student, there are a few channels that you should be present in on a regular basis (a daily presence is best).
- Any specific channel for your project, e.g.
A lot of development action happens in this channels, or people who can help you with problems are available here. This also provides you the opportunity to gain insight into what the communication in an active open source project looks like. You should at least be present and reading the activity in these channels during the summer. Participation is definitely encouraged as well.
Balancing project with open source contributions
I think my single, most difficult challenge with Google Summer of Code was balancing my proposal-specific contributions with the rest of contributions and work in the Fedora Project. I believe I was a minority of Google Summer of Code students who applied for the program as an active member of the project almost a full year before the program began. Additionally, my areas of contribution in Fedora before GSoC were mostly unrelated to my project proposal. My project proposal mostly aligned with my intended degree and education I am pursuing. A lot of the technology I would be working with was new to me and I had minimal knowledge about it before beginning the summer. As a result, this presented a unique set of challenges and problems I would face throughout my project.
The consequences of this were that I had to spend a lot more time researching and becoming familiar with the technology before advancing with creating the deliverable items. A great resource for me to learn about Ansible was Ansible for DevOps by Jeff Geerling. But I spent more time on learning and “trying out the tech” than I had anticipated.
This extra time spent on research and experimentation were in tandem to my ongoing contributions in other areas of the project like Community Operations, Marketing, Ambassadors, the Diversity Team, and as of recently, the Games SIG. Balancing my time between these different areas, including GSoC, was the biggest challenge to me over the summer (along with a separate, part-time job on weekends). A separation of time to different areas of Fedora became essential for making progress on my project. What worked well for me was setting short-term goals (by the hour or day) that I wanted to hit and carry out. Until those goals were reached, I wouldn’t focus on anything other than those tasks.
I’m both thankful and grateful to those who have offered their mentorship, time, and guidance for me to be a member of the GSoC Class of 2016. Special thanks go to Patrick Uiterwijk, my mentor for the program. I’ve learned a lot from Patrick through these past few months and enjoyed our conversations. Even though we were both running around the entire week, I’m glad I had the chance to meet him at Flock 2016 (and hope to see him soon at FOSDEM or DevConf)! Another thanks goes to one of my former supporting mentors and program administrator Remy DeCausemaker.
I’m looking forward to another year and beyond of Fedora contributions, and can’t wait to see what’s next!
Fim da primeira Campus Party Weekend Recife. Vinte e seis horas de conteúdo e diversos temas.
Nesta edição não tivemos nada específico sobre nossa comunidade, mas o contato com pessoas de outros grupos é sempre bem proveitoso.
Bom dia com GNU.
PH Santana fala sobre GNU, GPL, free software e open source.
Palestra sobre o protagonismo no empoderamento das mulheres na tecnologia e programação, casos de sucesso, recursos/aplicações da linguagem, como incluir e manter mulheres na tecnologia e porque todos deveriam aprender Python.
August 20, 2016
Das FESCO (Fedora Steering Comitee) hat am Donnerstag beschlossen, das für die Workstation-Variante von Fedora 25 Wayland der standardmäßig verwendete Displayserver sein soll. Es soll aber auch weiterhin die Möglichkeit geben, X als Displayserver zu verwenden. Den übrigen Desktop-Spins von Fedora bleibt es freigestellt, welchen Displayserver sie standardmäßig nutzen.
FESCO behält sich jedoch auch die Option vor, diese Entscheidung rückgängig zu machen, falls im weiteren Verlauf der Entwicklung von Fedora 25 Fehler in Wayland auftauchen sollten, die einen Einsatz als standardmäßigen Displayserver nicht (mehr) rechtfertigen.
Update 2017-08-21 10:07: Der Link zum FESCO-Ticket im Artikel wurde korrigiert.
Fedora Pune Meetup for the month of August 2016 happened today at our usual location. We had in total 12 people turning out for the meetup.
This time the event was mostly foccused around re-writing the GNU C Library Manual using reStructuredText and Sphinx. This task was decided during the release event that we had last month. We did create a Etherpad link to maintain the status of the task1.
The aim is to build a modern version, good looking version of the GNU C Library Manual.
If you are planning to contribute, ping /me (sayan) or kushal in #dgplug channel on Freenode.
This summer has been really amazing, I learnt a lot and worked crazy hours it has been a crazy yet amazing ride. I am not going to stop working on open source projects and with Pagure it is something really close to my heart.
There are a few things left but I can conclude that I am able to achieve what I wanted to at the beginning of this program , but there is never a feeling of satisfaction it is just like you want to achieve the best possible and most beautiful solution.
Pagure has CI integration which was one of my major goals to achieve and with the coming release it will be out and will be usable to people. This gives me immense pleasure to say that the foundation of CI was laid by me although Pingou kind of wrote a lot after that but that helped me to learn the depth of thinking one needs to have when you are working on a feature like this.
I also worked on Private Repo feature which took more time than expected and it was pretty challenging to achieve , this feature is in feature branch and it may get merged after it is checked in the staging first.
It was so challenging that I got stuck on a data fetching problem from the database , we use Sqlalchemy as ORM in Pagure. I went through a lot of ups and downs at times I was about to give up but then I get some small part of it and Pingou has been so amazing mentor he never spoon fed me instead he asked the right question the moment he ask something the idea bulb use to glow.
I still remember struggling with Xapian and Whoosh. This was again a very big task and still is , it requires a lot of time to optimize it to a level where it doesn’t slow the site. I gave a lot of time on it but since I few other goals and various issue to solve so I eventually moved on to those just to come back.
Pagure pages is one of the last goals that I worked on recently and there are discussion pending over it.
At a glance I was able to achieve a lot of the big goals on my proposal and still work has to be done, and I will continue to work on achieving various other goals. Few links that I want to share :
This kinds of makes me feel happy that I have around 102 commits on the master branch now and I believing I will be working a lot more on Pagure to bring a lot of cool and useful feature to it. In case you have any suggestion feel free to file issues on Pagure.
To be really frank I am not at all sad that GSoC is getting because I have received so much love and inspiration from Fedora Community that contributing to projects has actually become my daily routine the day I don’t commit code, review patches or comment on issues I start feeling something is missing .
And some of my fellow GSoCers said That’s all folks! ;)
davidlt has done an amazing job building RISC-V RPMs: https://github.com/rwmjones/fedora-riscv/tree/master/stage3-built-rpms
# ldconfig /usr/lib64 /usr/lib /lib64 /lib disk cannot read 4096 bytes @1544056832!
This is in the HTIF / SD-card access layer which we have full source for so at least it can be fixed.
I love Fedora Badges. I'm not saying all I do is to get more badges, but it's a great motivator. One thing that somewhat miss a guidance on what options I have, what should I do to get another badge, how much activity will it need.
Fedora Project is not the only community that awards badges to its members. For example Stack Overflow has badges as well. In you Stack Overflow profile you can see which badge you are likely going to get next and how much progress you have made on that.<figure> <figcaption>Badges on Stack Overflow</figcaption> </figure>
Is it possible to do something like this for Fedora badges? Turns out it kind-of is. There actually is [a related issue] filed for the awesome Fedora Hubs project to show options of next badges.
All this actually relies on having information about badge paths, but until it's available in production, it can be reasonably hacked based on badge name and a short list of exceptions.
First thing that comes to mind is to simply look at statistics of the badges. The ones that are awarded more often are most likely the easiest to get. Let's start from that by finding the 5 most common badges that I don't have yet.
However, just taking that is not a particularly good suggestion: in my case 3 out of these badges turn out to be "have FAS account for at least X years". I'm slowly getting there, but there's not much I can do to speed this up. It makes sense to only show the first badge from each series.
Progress towards next badge
Before we can estimate progress on getting a badge, it is important to understand how the badges are awarded. The system is based on the messaging bus1. The fedbadges service listens to the bus and every time it sees a message, it checks it against the rules it has defined.
The process starts with a simple check on the message content to make sure that the message is connected to some badge. If it is, more complex checks are performed. These checks either communicate with pkgdb or datanommer, the service that archives old messages.
Now obviously I'm not keen on reimplementing the whole rule engine. Fortunately, it is possible to reuse the code from fedbadges. All badges that I care about for this part only need the datanommer integration, so that is a big help.
The biggest issue I faced with this is the fact that fedbadges connects directly to datanommer's database. I can't do that. My workaround was to write a script that would download all messages related to me from datagrepper and store them locally. This works reasonably well for me personally, but trying to get the messages for someone who is active for a longer time is going to be an issue.
Unfortunately, the list of messages related to a particular user is not enough for all badges: Bodhi has badges for other people voting on your updates. Therefore we also need all messages related to updates a person creates.
Another problematic badge is the Cookie one: the number of cookies you have get's reset every release cycle, so despite the number 8 above, I actually only have 1 right now.
I want it too
If you want to experiment with this code, I put it on Pagure as my-next-badge. There are instructions in README. I didn't try to optimize this in any way (yet), so it needs a lot of memory as all the messages must fit there. In my case, it is about 40 MiB. For other people, it might be significantly more. By "more" I mean it can easily be several gigabytes.
If you decide to try this, please note that the script is a hack that may not always be correct. It may try to convince you that you satisfy conditions for some badge even if you don't have it. Take it with a grain of salt.<section class="footnotes">
Well, almost. Some badges are awarded manually. We can ignore that here.↩
August 19, 2016
Hi folks! We are having another ‘onboarding’ video call to help new Fedora QA recruits get started tomorrow. Sumantro will be leading the call, I’ll try and stop by if I can. To join the call, just keep this piratepad open. The call agenda is shown there and it will be used for notes when the call is happening, plus there’s a chat panel. Ten minutes before the call starts, Sumantro will post the URL for people to join. Then just join the call and follow along! Please make sure to mute yourself on the call when you’re not talking.
Thanks everyone, and welcome to the group, new members!
Después de postergarlo por mucho tiempo y tras haber adquirido algo de experiencia al crear con Jekyll las web de HackLab Almería y Club de Cacharreo me he animado a descartar al viejo Lameblog y ponerme manos a la obra. Si se nota alguna inconsistencia en mi web tened la seguridad de que es culpa mía. Y no me refiero al diseño, que es algo que ya doy por perdido.
Algo fantástico de Jekyll es que puedes migrar un blog al menos a través del fichero RSS del antiguo. Y por ahora parece funcionar divinamente.
Una inconsistencia a la que tristemente renuncio a corregir son las URI/permalinks originales, que además son las que usa Disqus para recuperar los comentarios. Como Lameblog se hacía algo de lío al generar las URIs con la localización ES pues se ha quedado todo un poco guarro y ahora me parece un lío arreglarlo. Por otro lado voy a procurar a no eliminar contenido de las URIs antiguas por los (pocos) enlaces externos que pudiera haber. Perderé los comentarios, sí, en las versiones nuevas de las entradas pero realmente no son demasiados y deberían seguir accesibles en las antiguas.
PD: Finalmente me he puesto a migrar los comentarios del blog alojados en Disqus. Afortunadamente parece que el proceso está bastante bien implementado y en mi caso, ya que no me he atrevido a especificar unas reglas que indiquen la transformación de las URIs antiguas a las modernas he seguido el procedimiento manual en el que descargas un fichero CSV con las entradas (URIs) que Disqus ha registrado en la columna A para añadir en la B la nueva. En mi caso han sido más de 500 pero, OjO, 500 URIs no significan 500 comentarios ni por asomo. De hecho una de las cosas que he verificado es el poco interés que despierta mi blog por los pocos comentarios o recomendaciones recibidos :_( En fin.
El caso es que he querido verificar cada una de las URIs si eran dignas de ser migradas y sólo se me ha ocurrido un procedimiento manual que básicamente he gestionado con esta línea de bash:
for a in `cat olea-2016-08-21T20-27-31.368505-links.csv ` ; do chrome "$a" && read -p "pulsa Enter" ;done
Donde olea-2016-08-21T20-27-31.368505-links.csv es el fichero CSV descargado. El porqué del read es para evitar que se abran 500 solapas en el navegador.
En la práctica han sido muy pocas las URIs que he indicado migrar (20 o 30 máximo) porque no había más comentarios ni recomendaciones. A continuación, siguiendo las instrucciones de Disqus he subido el fichero CSV revisado y he esperado a que fuera procesado. Y listo.
En realidad me ha costado un poquito más porque ha cambiado el código que Disqus proporciona para integración y al final he encontrado este precioso código jekyll de Joshua Cox que ha terminado por resolver toda esta parte.
Ale, a disfrutarlo con salud.
We recently interviewed Alfonso Savio on how he uses Fedora. This is part of a series here on the Fedora Magazine where we profile Fedora users and how they use Fedora to get things done. If you’re interested in being interviewed for a further installment of this series you can contact us on the feedback form.
Who is Alfonso Savio?
Alfonso Savio is a man of many talents. Alfonso works for the National Cancer Institute of Naples and started using Linux in 2004 with Fedora Core 3. He’s a systems integrator, systems and network administrator, project and database manager, and software developer. However, his official title is ICT Manager of the Clinical Trials Unit.
Alfonso’s team analyzes data from clinical trials to advance scientific research in the fight against cancer. The team comprises physicians and data managers. He is the sole person in his department using Linux for his primary desktop. Hence, he’s an open source trailblazer.
His childhood inspirations include comic book character and arch enemy of Superman Lex Luthor. His favorite movies are It’s a Wonderful Life by Frank Capra and Creator by Ivan Passer. This may explain his belief in miracles, and the fact that men don’t need super powers to triumph. He values honesty, seriousness, wisdom, optimism and curiosity in other people. His interest in computers started with an Atari VCS 2600. Savio’s first professional work utilized MS DOS 3.3, QuickBasic, Novell Network and BTrieve DBMS.
The Fedora community
Alfonso gets involved in the Fedora community by finding bugs and promoting Linux based on Fedora. However, his path to Fedora traveled through many different distributions. He has a special fondness for PCLinuxOS. “I have to mention a distro that finally made me choose GNU/Linux as my favorite OS, is PCLinuxOS 2007 and its creator Bill Reynolds,” he said. Nowadays, Alfonso is a strong believer in Fedora and Red Hat. “The Fedora Project is stable and well supported by the community and Red Hat,” he continued. “I think Fedora is the distro going in the right direction to make GNU/Linux a valid alternative to other operating systems.”
Alfonso’s mobile workstation is equipped with a Core i7 processor, 1 TB SSD, 16 GB of RAM, and a GeForce 555M graphics card. His desktop workstation runs on a Xeon E3, 32 GB of RAM, 1 TB SSD, and a AMD Radeon R9 390 graphics card.
At work Alfonso maintains four production servers with Fedora. His physical backup server uses rsync and Samba shares. He also has a physical Ruby on Rails server with Passenger and MariaDB for data. Then, his two virtualized servers use KVM/QEMU. The first, a Ruby on Rails server, uses Passenger and MariaDB. The second, a mail server, uses the IredMail system.
Alfonso also runs Fedora 21 to 24 on various computers. He uses Mate as a preferred desktop. His favorite software includes:
- Midnight Commander
- DBeaver DB Manager
- The Ruby programming language
- Aptana Studio 3
- Libreoffice for documents
- Vinagre as a VNC remote desktop client
- Virtual Machine Manager for managing KVM/QEMU VMs
- Filezilla as an FTP client
- Pluma as a graphical text editor
- Nano as a command line text editor
- MariaDB as a DBMS
- GwenView for organizing and viewing pictures
If you are a terminal geek you will always want to do things using terminal😉. And when it comes to Atomic host, YES you will have to do stuffs using terminal.
If you don’t know about Atomic, you must visit http://www.projectatomic.io
This post will describe how to setup and use IRC client on Atomic host. This will be applicable for any Cloud host also.
Irssi is a terminal based IRC client for Unix/Linux systems. And the best part is we will not need to setup things manually because we have containers.
Let’s Get Stared:
I am using Fedora Atomic host here. Get Fedora atomic host from here: https://getfedora.org/en/cloud/download/atomic.html
Make Sure you have Docker installed.
Copy the Dockerfile from here: https://github.com/trishnaguha/Fedora-Dockerfiles/blob/irssi/irssi/Dockerfile
docker build -t username/irssi .This will build image.
There after you just need to run the container
docker run -it username/irssi.
After you start the container you will see something like this:
Let’s join a channel
You will find the Irssi Commands here: Irssi Commands.
No próximo dia 20 e 21 de agosto, acontecerá a primeira Campus Party Weekend, na cidade do Recife - PE.
A Campus Party todo mundo já conhece, mas essa versão “Weekend” é novidade. O evento foi reduzido para diminuir custos, simplesmente isso.
Nesta edição não haverá espaço reservado para comunidades, mas com certeza estarei lá com alguns pendrives e DVD’s, pronto para instalar o Fedora 24 para quem quiser. \o/
Umas das coisas que mais me fascinam, é admirar o céu noturno. A Lua, as estrelas, os planetas… opa, pára tudo! Como assim planetas?
Pois é, isso mesmo, dos sete planetas do nosso sistema solar, cinco são visíveis a olho nu, em determinadas épocas do ano.
Sim, certo, mas e como faço pra saber?
Fácil, lhes apresento o Stellarium, um planetário de código aberto e gratuito para o seu computador. Ele mostra um céu realista em três dimensões, da forma como você o vê a olho nu, com um binóculo ou com um telescópio.
Com ele você poderá aprender mais sobre o espaço, localizar estrelas, planetas, constelações, aglomerados, galáxias e até mesmo satélites artificiais. Mas claro, tudo dentro do limite da simulação, pois infelizmente na realidade, a poluição luminosa nos priva de muitas belezas do céu.
E depois de um pouco de conversa, vamos instalar essa maravilhosa ferramenta no nosso Fedora 24
Via terminal: $ sudo dnf install -y stellarium
Ou buscando na loja do Gnome.
Após a instalação o ícone estará no menu de aplicativos, abra e configure sua localização, simples assim.
Precisa de outro sistema operacional, mas não quer fazer dual boot? Gosta de fazer experiências com vários sistemas mas cansou de tropeçar nas “caixas” por aí?
Então segue essa dica ;-)
1º - $ sudo dnf install -y libvirt virt-manager
2º - $ service libvirtd start
Pronto, seu Virt-Manager já está instalado!
Para executar via terminal:
Ou se preferir basta procurar o atalho ‘Gerenciador de Máquinas Virtuais’ no menu aplicativos e adicionar aos favoritos.
A história da distro Red Hat Linux, no início até os dias atuais, vídeo do canal Toca do Tux.<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="https://www.youtube.com/embed/zr67VlMqsrk" width="560"></iframe>
Esses são alguns swags do projeto Fedora que eu tenho.
Capa do celular
Adesivo da tampa do notebook
Adesivos internos do notebook
August 18, 2016
Days 3 and 4 were reserved for workshops. Also, during these 2 days, people continued to split into smaller groups to discuss matters of their own interests, and so did I. However, I caught up with some of the presenters to ask them about the outcome of their sessions and you can read that at the end of this article. But to be fair – if you want to read something about Flock, feel free to browse the blogs that emerged in the first post-Flock week, listed here:
- me (general information) WordPress
- Amita Sharma (Diversity Panel) ami
- Bee (CommOps and metrics) networksfordata
- Sylvia Sánchez (Lailah) (translator, designer) crossingtheair
- Ratnadeep Debnath (FOSS developer and evangelist) rtnpro
- Kevin Fenzi (Fedora Infrastructure Lead) Kevin’s Musings
- Radek Vokal (packages for Fedora & Modularity) </linux>
- Scott Collier (Containers/OpenShift perspective) Notes on tech, mostly…
- Masha Leonova (Fedora Design Team) WordPress blog
- Sinny Kumari (Fedora packager group) Sinny’s blog
- Maria “tatica” Leandro (Fedora diversity – women in Open Source) tatica.org
- Randy Barlow (Fedora Engineering, Erlang) electronsweatshop
- Alex Eng (Zanata) LoOnEs
- Pravin Satpute (Internationalization Engineer) blog link
- Adam Miller (Fedora packager) blog link
- Josh Boyer (Fedora kernel) blog link
- Pierre-Yves Chibon or Pingou (French documentation, packager) blog link
- Brian Exelbierd (Containers, Atomic, event organizer) even the horse knew
- Ryan Lerch (Interaction designer, Inkscape, Blender…) blog link
- Miroslav Suchy (packager, creator of Copr) blog link
Here are my notes from the two guys I talked to.
Led by Brian Exelbierd, the Fedora Docs Learn and Hack session turned out to be more learn and discuss and not learn and hack. Brian shared the outcomes from the Fedora Docs FAD in May 2016 and started a discussion around topic based writing and tooling. There was a lot of sharing of ideas and questions about how we move forward. In general the idea of changing the style of the documents and how we build and publish them was well received. Questions for discussion in the future revolve and how to get there in a manner that makes sense for the project. Brian will be posting an update about the Docs situation at this Comms blog soon.
In parallel with Brian, Christoph Wickert led the Meet your FAmSCo team planning workshop. What is FAmSCo? It stands for the Fedora
Ambassadors Steering Committee and has existed for about ten years.
Their mission is to support the Fedora Ambassadors program. The group
of presenters gave status reports and went through several ongoing
issues, some of which the APAC community is facing:
- We need to have a clearer idea of our target audience. As
conferences are more topic-oriented, we need to created different
marketing messages for the individual target audiences such as
students, Python/Ruby developers, system administrators etc.
- We continue to work on the idea of the Fedora Outreach Steering
Committee (FOSCo), a new body that coordinates the efforts of the
ambassadors, the marketing group, the design team, CommOps and other
outreach focused groups in Fedora. In long term, FOSCo should replace
FAmSCo and take over all it’s duties, but to do that, we need to work
on the structure and get support from more groups.
- FAmSCo and the ambassadors mentors are looking to improve the
mentoring process, but we will not lower the bar. Quality is more
important then quantity, even in countries where the Fedora community
and user base still needs to grow.
- FAmSCo strives to support emerging local communities at the best, be
it financially, logistically, with manpower or simply by giving
I also talked to Justin Flory, Matthew Miller, and Langdon White; but I’ll write about that later. Expect something here or on Fedora magazine soon.
Tenho um raspberry pi 2 model b e segui os passos dessa wiki abaixo para instalar o Fedora ARM no Raspberry, e deu certo.
Screenshots depois de instalado e configurado, usei o Fedora ARM LXDE Desktop:
dnf upgrade 2
Página inicial do Firefox do Fedora ARM
Acessando um canal do youtube (AcreLinux)
Assistindo a um vídeo no youtube
Acessando o meu site
Last week, it became public that there is an attack against Secure Boot, utilizing one of Microsoft’s utilities to install a set of security policies which effectively disables bootloader verification.
I still believe Secure Boot is dead. Here's why. https://rol.im/securegoldenkeyboot/—slipstream/RoL (@TheWack0lian) August 9, 2016
In the announcement, the authors liken the this vulnerability to a “secure golden key”, referencing the Washington Post Editorial Board’s suggestion of cryptographic back doors in their wildly misguided apologia on cell phone decryption from 2014. On social media, one author has gone so far as to declare Secure Boot dead. The trade press has widely covered this as a leak of signing keys, and as such treated this as a major vulnerability with long-term implications for the ability to stop bootkits.
Rumours of My Death
The implication of a signing key leak is a strange analogy to make, since no such key has been made public, as is the declaration that this renders Secure Boot “dead”. Clear descriptions of what has actually gone wrong have been published elsewhere, and while these are vulnerabilities, they don’t defeat1 the Secure Boot mechanism. The vulnerabilities are in the interaction of Microsoft’s bootloaders and other tools. As such, Secure Boot can be used to block those binaries, mitigating the issue and stopping exploitation.
In response, UEFI is distributing an updated version of the Secure Boot revocation list, aka dbx. dbx is used to remove previously granted access from a UEFI driver or application, or from a signing certificate, declaring that signature invalid or signatures with the blacklisted certificate to be invalid. This update adds 64 new individual signature entries into dbx, raising the total to 77. The policy for issuing dbx updates has always been stated as requiring well known public vulnerabilities or active exploitation in the wild, so some entries may be for Microsoft bootloaders, while some are plausibly batched updates for minor vulnerabilities in more obscure tools—vendor drivers and tools which may have vulnerabilities but are not well known.
Obviously, a major malfunction has occurred
There has been some confusion about exactly what has been blacklisted, as the original discoverers of the vulnerability note on their updated website:
I checked the hash in the signature of several bootmgrs of several architectures against this list, and found no matches. So either this revokes many “obscure” bootmgrs and bootmgfws, or I’m checking the wrong hash.
As I’m sure they know, they did not check the wrong hash. It appears Microsoft has only added dbx entries to blacklist bootloaders for their ARM-based Windows RT platforms, on which you can normally not disable Secure Boot. This seems to indicate that either Microsoft does not believe x86 machines are vulnerable2, or that their threat model has defined this as a major problem on one platform because you can’t disable Secure Boot there, but not on the other, where you normally can. It’s also likely that the threat model takes into consideration whether they believe the exploit can be used manually or is automatable, and on whether local presence is required at any point of the exploit. Part of the impetus for such distinctions lies in the economics of dbx entries.
When you update dbx, the system firmware performs a special append operation which adds any entries in the new list which are not in the existing list into the persistent storage, and the resulting value represents the combined set of entries. On a typical system, that storage is a different region of the same flash part as the system firmware. That flash part is as small as the vendor can possibly make it, due to market pressure to minimize the cost of goods sold for system’s components, to keep the marginal revenue as high as possible. In a market where pennies per machine can determine profitability, the difference between shipping 10000 64Mb W25Q64FV chips at $0.65132/per vs the 128Mb W25Q128FV at $1.05315 is a decision that will receive significant scrutiny. Even one-off machines for firmware developers often ship with the smaller part3.
The result is that the governing principle for the minimum size of a flash part you can ship winds up being the Windows logo requirements, because the Windows logo certification includes participation with Microsoft marketing programs, thus increasing revenue. Those requirements mandate that in order to use the Windows logo, systems must implement particular UEFI features, have certain defaults, et cetera. On the subject of the flash part, they say:
Reserved Memory for Windows Secure Boot UEFI Variables. A total of at least 64 KB of non-volatile NVRAM storage memory must be reserved for NV UEFI variables (authenticated and unauthenticated, BS and RT) used by UEFI Secure Boot and Windows, and the maximum supported variable size must be at least 32kB. There is no maximum NVRAM storage limit.<footer>System.Fundamentals.Firmware.UEFISecureBoot msdn.microsoft.com/en-us/…</footer>
Prior to this update, the shared dbx list was 13 entries, all SHA-256 hashes of individual binaries, for a total of 680 bytes4. This update adds 64 new entries, also all SHA-256 hashes of individual binaries, which brings the size up 775 entries taking 3780 bytes. This update is 9.5% of the guaranteed available space, and 11.5% is now in use. The good news, though, is that each binary only needs to be blacklisted once; any new exploit in the same binary is covered by the same entry.
I say we take off and nuke the site from orbit. It’s the only way to be sure.
Burning through a cool 10% of the space in one afternoon is obviously not a sustainable plan, so you can see why one might conclude that this is a death knell to Secure Boot. I don’t think that’s the case. There is more we can do. In the worst case scenario, all signing keys are re-generated, every vendor updates all their boot media, UEFI drivers, and whatnot to have new signatures, and updates are issued to wipe dbx completely6, add a dbx entry for the signing certificate, and add a new signing certificate to db7. That’s clearly the nuclear option, and there are some better options.
Currently the Microsoft bootloaders are signed by a certificate with
CN=Microsoft Windows, which is issued by
CN=Microsoft Windows Production PCA
2011, and it in turn is issued by Microsoft’s CA,
Certificate Authority 2010, a self-signed CA certificate. The PCA certificate
in the middle of this chain is required by Windows logo requirements to be in a
For other UEFI binaries, such as drivers and bootloaders which aren’t from
Microsoft, the signing chain is different: they’re signed by
Windows UEFI Driver Publisher, which is issued by
UEFI CA 2011, and it is issued by
CN=Microsoft Corporation Third Party
Marketplace Root, which is a self-signed CA certificate. As in the Windows
case, it’s the CA cert in the middle of the chain which is in the system’s
This organization means it’s possible to have a slightly smaller nuclear option than just blacklisting everything—all of the Windows bootloaders can be blacklisted without blacklisting everything else. That’s obviously still not a palatable solution for Microsoft for this exploit, but it hints at changes in policy by the Signing Service and the CA that could help keep this situation from recurring.
As a first step, every organization getting anything signed should be under a signing cert unique to them, and those certificates should be periodically retired and replaced. Organizations that get a large number of binaries signed should be subdivided into different signing certificates and cycled more often, possibly with an intermediate CA certificate. That would enable blacklisting of either individual signing certificates or intermediate CAs8, removing relatively broad swathes of applications en masse, rather than having to blacklist individual binaries.
This is all more overhead, but the cost of generating more certificates, storing them appropriately on HSMs, and choosing which to use on a per-binary basis pales in comparison to the prospect of filling up the flash part with dbx entries. In this setup, the ARM Windows 8.1 RT signatures could have been issued by a series of signing certificates each issued by a single intermediate CA specific to that product. This could have been one entry in the blacklist. It would not have affected other versions of Windows or other products. It would have blacklisted the exact same list of binaries, taking up 76 bytes.
Or even directly involve…↩
It certainly seems that x86 is vulnerable.↩
I’ve had vendors mail me the larger one and tell me to replace it before applying a test update. Good thing I’ve got that hot air rework station handy.↩
Many systems have one or two more entries the system vendor has blacklisted, but they’re generally for binaries signed by that vendor’s own signer, not the UEFI signing service, and so they’re not part of the common blacklist.↩
This figure assumes that it’s 3
EFI_SIGNATURE_LISTheaders, followed by 9, 4, and 64 entries, respectively. It’s conceivable that some well engineered firmware could re-write that as one header followed by 77 entries, since they’re all of the same type, which would make this only 3724 bytes. The UEFI Spec is silent on this optimization. I suspect nobody is using it, and really 56 bytes is not on the scale of problem we’re facing. Also most people don’t say “well engineered firmware” very often.↩
I don’t think this will work at all with any OS’s current tooling, but that’s a surmountable problem.↩
The whitelist that goes along with dbx.↩
Certificates have a section containing the really important stuff called the To-Be-Signed data. The signature by the cert’s issuer is actually a cryptographic signature on the hash of this data. Secure Boot allows blacklisting of the TBS hash for a cert, which again is a single SHA-256 hash.↩
From: "Bob Smith" firstname.lastname@example.org
Date: Thu, 18 Aug 2016 01:56:16 +0200
To: A Mailing List email@example.com
Subject: Re: some subject
A long, long, long, time ago as in before 1988.. many mailing list software programs would unsubscribe you if you did exactly what Bob did above. When an email went to the list software it would look through all the text and if it found the words unsubscribe it would do that. Of course if you sent an email using that word for some other reason you ended up off the list with little idea why. The next version of the mailing list software would just do this if the unsubscribe was by itself like Bob did above. This worked "ok" in the world of RFC822 where what you saw is what you sent and nothing special was added. It didn't work for in the world of MIME, HTML or other formats (say not an ARPA email but a BITNET email) as the Internet became "mainstream" around 1994 or so. At this point a lot of people were accidentally unsubscribing or being maliciously unsubscribed by trolls who would forge emails saying they were firstname.lastname@example.org but weren't.
By the time the third generation of mailing list software came around in 1998, most software does allow for a naked unsubscribe to get you off the list. Instead you either have to go to a specific webpage and unsubscribe or have to email a specific alias that will start the process of un-subscription. For the web it is usually a multi step process of you go to link, you log in, you unsubscribe and you get a confirmation email that you were unsubscribed. For the email address you will usually get an email sent to you asking if you really want to unsubscribe and if you do email back with a special one time code included in the email. This is all because of the ever present malicious troll problem of people who think it is loads of fun to harass people either because that person exists or for the 'lols' which they seem to trade under their bridges for self-validation.
Which brings us back to how do I know how to really unsubscribe from a list. Every email has a bunch of 'hidden' headers that are included which tell various software where the email maybe came from and where it is going. It will also tell software extra data like how to display it and can contain things like how to subscribe, find an archive or unsubscribe. The current standard way this is done is with List-Id: headers. Here are some examples:
Mailing-List: contact email@example.com; run by ezmlm
List-Help: mailto:firstname.lastname@example.org, http://sourceware.org/ml/#faqs
So from the above we have an unsubscribe for ezmlm mailing list system which is to send an email to a specific email address. For the Fedora lists we use Mailman 3 which has both a mailing list address and a web page to go to start the unsubscribe process.
How do you find these hidden headers? It depends on the mail software you are using. Most of them have some sort of "Show original" or "Show Source" which will pop up a new window which will show a lot of headers. In other mailing list software, you will see a button which says "unsubscribe" which will look for the headers and then fire off the things it says in there.
[Edited 2016-08-18] I realized I completely forgot the obvious way to unsubscribe from Mailman lists. At the bottom of every email from a Mailman email list contains the follow:
That link at the bottom is all you need to click on to get on the road to un-subscription. You will be directed to a page that will ask you to login. You can do so through one of several methods which will get you to a page that looks like this
devel mailing list
Flock was held in Krakow this year, so the traveling was a sort of easy for me. Krakow is just 350 km from Brno which is about 3.5 hours by car. The conference was again organized in the hotel where almost everyone stayed. The same setup was already in Rochester last year and people appreciated it. It’s very convenient. You don’t have to travel to the venue, you can sneak out to have a nap, which is super useful if you’re fighting jet lag, and you can use hotel facilities such as a gym or swimming pool.
I had one talk and one hackfest at Flock. The talk was about Fedora SWAG. I’m still quite a lot involved in SWAG production for the EMEA region and it was a pleasure to state that the things have improved since the last year and a lot of ideas we had at Flock in Rochester actually got implemented.
The hackfest I organized was about writing AppStream metadata for application add-ons. I started the initiative in December and since then dozens of add-ons appeared in GNOME Software because they got AppStream metadata. The hackfest was partly a workshop because it took me quite a while to explain everyone what to do to make an add-on appear in the default app catalog in Fedora. I also learned new things. Richard Hughes who is very involved in upstream AppStream and works on GNOME Software participated and I, for example, learned that the way I had added keywords in metadata XML files was wrong. And Richard learned that I was doing it wrong because it was not documented anywhere.
I also attended many other talks. Matthew Miller’s keynote on the state of Fedora Project was very informative. I’m happy to see Fedora grow and I’m especially happy that our team plays a big part in it (Workstation makes ~80% of all ISO downloads). My boss Christian Schaller had a talk on Workstation which was pretty interesting, but because my team is deeply involved in many of the Workstation initiatives there was not much new to me. I also enjoyed talk by Jonathan Dieter who has run Fedora on 100+ computers in a high school in Lebanon and it was very interesting to listen to what it takes to use Fedora in such a deployment. Jonathan also noted that he hasn’t had a single major issue with Fedora in the last 3-4 years. Improved quality of Fedora was a theme that repeated in many other talks.
What was the main topic of the conference was modularity. Langdon presented a progress of this initiative. I must say I knew very little about it and I was quite surprised that the planned solution is built around RPM rather around increasingly popular containers.
I also met Pawel Hajdan of the Google Chrome team. Conversations with him very very informative and interesting for other Red Hat desktop team members, too. We discussed AppStream metadata for Chromium, Chromium for Flatpak, Chrome on RHEL etc.
Just a couple of days after I returned home from Flock I travelled to GUADEC which is the primary conference for GNOME users and developers. I didn’t have any talk or workshop, but a couple of my reports spoke there. This time the traveling was a bit more difficult. We went by train, had to take 6 of them, and traveled 1000 km. But the whole Brno crew made it to Karlsruhe sound and safe.
There were many talks by Endless people. I’m really happy that Endless increases its investment in GNOME. It’s always better to have several major corporate contributors. Endless also proves that it’s possible to build a different shell on the top of GNOME, make your own UX story and still use most of the GNOME components.
I really enjoyed Owen Taylor’s talk on Fedora Atomic Workstation. Read-only OS, all apps in containers, development environment separated from the system… tt will be a radical change, but with a lot of potential benefits. I also like that Owen already has a clear idea about it and an already working prototype.
On Monday, I attended a Flatpak BoF. I expected it’d be mostly about portals, but portals were mentioned just briefly. Most of the discussion was about some centralized Flatpak repository. Someone suggested something called FlatHub which would be a place for Flatpak repositories where developers can build and distribute their apps, something like Copr for Flatpak. This can’t be exposed to average users though. We want to avoid a mess of 10 builds of GIMP without guaranteed quality. So there needs to be something called FlatStore where only approved and trusted developers can distribute their apps. So only GIMP developers themselves would be able to distribute GIMP there. There were many practical obstacles discussed. Should we build everything on store servers or allow developers upload binaries (building some desktop apps could be very resource hungry), who should run such a store (GNOME Foundation, FreeDesktop.org, a company?), how distributions will accept something that is built outside their control etc.
I enjoyed all days of both conferences. Very well organized, but still with the “for contributors by contributors” feeling. GUADEC 2017 will be in Manchester. Where Flock 2017 is going to be held is yet to be announced. The only certainty is that it will be in North America, so much more travelling for me next year, but I hope to visit both again.
We are currently in a 4 week Modularity Sprint #10, the usual 2 week sprint got extended due to FLOCK and pre-FLOCK developer meetings.
As you can see in the 'In Progress' and 'Complete' columns on our Taiga board, lots of tiny and larger pieces are coming together.
The following text describes how various parts of the Modularity infrastructure work together. Ralph Bean shows these connections in his Modularity infrastructure diagram.
Module build tasks can be submitted to orchestrator (rida) either by posting a short yaml text into the REST API or with 'fedpkg module-build'. The orchestrator will then download and parse the module description file, check the dependencies and schedule koji builds for missing components. The build process can be monitored with the Build Pipeline Overview (BPO) component and the final result will be fed into the Product definition center (PDC) which is a webapp and API designed for storing and querying product metadata.
All of the above is already done and in a usable state after this sprint, although not all patches have been added to the upstream repositories yet. Same features are still missing, but we'll continue adding them in the upcoming weeks.
Langdon demoed how all this works from a user perspective during his talk  at FLOCK in Krakow. Unfortunately a recording of his talk isn’t available on YouTube yet. Nils and Adam therefore put together a similar demo, you’ll find it in the Fedora Modularity channel on Youtube
I have a great news for those of you with a MacBook Pro 15″ 2015 (MacBook 11,4 and 11,5)!
As you might have noticed, when running Linux on this machine, it can’t be suspended, shut down, and you can’t even control brightness of the display. These issues have been reported a while ago, and yes, there are some patches, but they didn’t make it to the production code.
Suspend and shutdown: https://bugzilla.kernel.org/show_bug.cgi?id=103211#c172
So I took those patches, applied them to the kernel in Fedora and built it in my Copr project.
How to make it running on your machine? First, download and install Fedora 24. Then you just need to enable my Copr project and install the patched kernel:
$ sudo dnf copr enable asamalik/MacBook-kernel $ sudo dnf install kernel-4.6.6-300.AdamsMacBookSleepBrightness.fc24
Reboot your machine with the patched kernel, and that’s it!
I will try to keep the repo updated, so you will be able to update kernel as usual.
I’ve spent a few days adding support for upgrading the firmware of the various wireless 8Bitdo controllers into fwupd. In my opinion, the 8Bitdo hardware is very well made and reasonably priced, and also really good retro fun.
Although they use a custom file format for firmware, and also use a custom flashing protocol (seriously hardware people, just use DFU!) it was quite straightforward to integrate into fwupd. I’ve created a few things to make this all work:
- a small
libebitdolibrary in fwupd
- a small
ebitdo-toolbinary that talks to the device and can flash a vendor supplied
- a ebitdo fwupd provider that uses libebitdo to flash the device
- a firmware repo that contains all the extra metadata for the LVFS
I guess I need to thank the guys at 8Bitdo; after asking a huge number of questions they open sourced their OS-X and Windows flashing tools, and also allowed me to distribute the firmware binary on the LVFS. Doing both of those things made it easy to support the hardware.
The result of all this is that you can now do
fwupd update when the game-pad is plugged in using the USB cable (not just connected via bluetooth) and the firmware will be updated to the latest version. Updates will show in GNOME Software, and the world is one step being closer to being awesome.