Just Fedora Planet

The next big things, 2017 edition.

Posted by Paul Frields on February 09, 2017 03:37 PM

The post The next big things, 2017 edition. appeared first on The Grand Fallacy.

Along with several people on the Fedora Engineering team, I recently attended the DevConf.cz 2017 event. The conference has grown into an amazingly successful gathering of open source developers. Most attendees live in Europe but there were some from every continent. The coverage spanned all the big open source buzz-generating technologies. Session topics included containers, PaaS, orchestration and automation, and DevOps.

One of the most frequent topics I heard at and around the conference was CI — continuous integration. The idea of CI isn’t new in and of itself. Many open source projects put it to use already. If you do any work on Github, you’ve already seen it at work. (Also notably, OpenStack features one of the biggest and arguably most successful at-scale efforts.) However, it hasn’t taken strong root in Fedora, yet.

Based on the discussions I had and heard at DevConf.cz, that’s likely to change soon. Why? Well, for one thing, Fedora still breaks too often. This is especially (but not exclusively) true about Rawhide. But in many cases, we can easily understand these breakages. That means we can detect and prevent them before they occur. While update testing in Bodhi helps in the case of stable releases, that’s not a cure-all. That process still depends heavily on manual efforts that aren’t guaranteed. Moreover, those efforts form a gate of several days at a minimum, between building, karma, and tagging. This process no longer scales with new, fast-moving deliverables like Fedora’s edition of the Atomic Host. One size no longer fits all. We need a more flexible, automated approach.

What does that mean? For Fedora, the CI concept means gating on automated tests that guarantee some level of validity to a change. These tests are run prior to introducing changes into a tree, ostree, module, container, etc. That way, we don’t pass breakage on to the consumer.  But we can message that breakage back to the maintainer directly. The maintainer then quickly acts to fix the issues. And they see more immediate results from their fix.

We must do some work in the Fedora infrastructure to make this process work for Fedora contributors (maintainers especially). Some app work is also required to support our packaging and deliverables. We must make sure it’s easy for people to contribute to tests. Maintainers need to easily understand the status of their build requests. And of course the community must be able to continue contributing to higher levels of testing that make for a better Fedora. So CI isn’t the end of the story. It’s just another strong link in a chain of improvements.

Fortunately, we’re well situated to do great work here. For instance, the Fedora Infrastructure team already plans to front our dist-git package control with Pagure. (You probably know Pagure is a full-featured collaborative git forge.) This ensures the Fedora dist-git acts as a source for CI, tested with each new proposed change. But we believe this is unlikely to cause more complexity. Packagers can expect to use tools they already know. Furthermore, they could use the popular, effective pull request model to maintain packages and develop testing. This lowers the bar to contribution while maintaining high quality.

Another point in our favor is the entire Fedora application infrastructure has been running on the fedmsg messaging bus for years. We already can orchestrate and coordinate a huge number of automated activities around events involving our apps. Therefore a higher level of continuous integration and testing is well within our grasp.

Of course, this blog post is light on details. (What else would you expect from a manager?) 😛 Those details are obviously important. As the least technical person in the Fedora Engineering team, though, I’m the last person you’d want to describe them in detail. But the folks in the Infrastructure community team will be launching a series of discussions on the mailing list to explore those details.

We’re all passionate about making Fedora better. So hearing feedback from our contributors and colleagues at DevConf.cz has us very excited and enthusiastic about this next level. I encourage you to get involved and contribute constructively to the discussions!

Holiday Break 2016.

Posted by Paul Frields on December 08, 2016 06:31 PM

The post Holiday Break 2016. appeared first on The Grand Fallacy.

It’s sad I don’t get more time to post here these days. Being a manager is a pretty busy job, although I have no complaints! It’s enjoyable, and fortunately I have one of the best teams imaginable to work with, the Fedora Engineering team.

Since we’re coming to the close of another calendar year, I wanted to take a moment to remind people about what the holidays mean to availability. I’m going to crib from an earlier post of mine:

My good friend John Poelstra is fond of saying, “It’s OK to disappoint people, but it’s not OK to surprise them.” That wisdom is a big reason why I like to set expectations over the holidays.

Working at Red Hat is a fast paced and demanding job. Working full time in Fedora is itself demanding on top of that. These demands can make downtime at the holiday important for our team. At Red Hat, there’s a general company shutdown between Christmas and the New Year. This lets the whole organization relax and step away from the keyboard without guilt or fear.

Of course, vital functions are always staffed. Red Hat’s customers will always find us there to support them. Similarly, our Fedora infrastructure team will monitor over the holidays to ensure our services are working nominally, and jump in to fix them if not.

Some people like to spend time over the holidays hacking on projects. Others prefer to spend the time with family and friends. I’ve encouraged our team to use the Fedora vacation calendar to mark their expected “down time.” I encourage other community members to use the calendar, too, especially if they carry some expectations or regular responsibilities around the project.

So all this to say, don’t be surprised if it’s harder to reach some people over the holidays. I’m personally taking several weeks around this holiday shutdown as time off, to relax with my family and recharge for what’s sure to be another busy year. Whatever your plans, I hope the holiday season is full of joy and peace for you and yours.

New layout for PEAR packages

Posted by Remi Collet on December 05, 2016 12:03 PM

The /usr/share/pear directory, used for installation of PEAR extensions on Fedora and Enterprise Linux , contains a lot of files which should not be stored there. Especially because this folder in part of the default include_path.

Starting with Fedora 18, this gets better.

1. Documentation

Extensions store their documentation in /usr/share/pear/doc.

This directory is moved (since Fedora 15) in /usr/share/doc/pear (value of %{pear_docdir} macro).

No impact on existing packages as, by definition, documentation is not necessary for use.

2. RPM metadata

RPM packages store their metadata, a copy of package.xml from project's archive, for registering the extensio in the /usr/share/pear/.pkgxml.

This directory is moved to /var/lib/pear/pkgxml (value of %{pear_xmldir} macro).

No impact on old packages, as the path is hardcoded in the RPM (evaluated during its build).

3. Unit tests

Unit tests provided by each extension are installed in /usr/share/pear/test.

This directory is moved to  /usr/share/tests/pear (valule of %{pear_testdir} macro).

No impact on old packages, as these files are not required for use. Despite, a rebuild is preferred.

4. Data

Extensions data are stored  in /usr/share/pear/data.

This directory is moved to /usr/share/pear-data (value of %{pear_datadir} macro).

No impact on old packages or manually installed extensions, in fact, this value is evaluated during RPM build, or manual installation of an extension and result is harcoded in the scripts. Of course, existing content is preserved. A rebuild is also preferred.

5. PEAR metadata

PEAR installer store its metadata in various folders: /usr/share/pear/.registry, .channels, .depdb, and .filemap.

As this is alive data, this clearly should not be stored there. See the FHS.

Its move to /var/lib/pear is planed, and is the subject of a RFC for PEAR project, mainly because it requires significant change to the code.

So, for now, it is not moved.

6. Conclusion

Changes are done in php-pear-1.9.4-11.

A huge work have been done in Fedora 18 (and will be soon backported to remi repository). More than one hundred of packaged extensions have been rebuilt.

More work are needed for metadata, especially to insure a smooth upgrade from current layout. I will see when this become possible (Fedora 18 or 19), according to upstream answer, time needed for the change, and distribution schedule.

To be continued...

PHP and Arch specific Requires/Provides

Posted by Remi Collet on December 05, 2016 12:03 PM

This entry explain the recent changes in PHP packages available in rawhide (and soon in fedora 15) about Arch specific Provides and Requires.

1. Package dependencies

All sub-packages automatically have 2 provides (for a while).

For example : php-mysql and php-mysql(x86-64)

All virtual provides from php have been fixed to also provides both

For example : php-mysql provides php-mysqli and php-mysqli(x86-64) 

So a web application or a pear package (which are noarch) will still use

Requires: php-mysql

But a C extension could use

Requires: php-mysql%{?_isa}

Of course all dependencies between sub-packages of php, already use Arch requires :

For example : php-mysql requires php-common(x86-64)

2. ABI compatibility check

The old provides are still present

php(api) = 20090626
php(zend-abi) = 20090626
php-pdo-abi = 20080721

But new Arch specific provides are available and used by default when a package is build

php(api) = 20090626-x86-64
php(zend-abi) = 20090626-x86-64
php-pdo-abi = 20080721-x86-64

So, there is no need to change the PHP Guidelines, packages which use

Requires: php(zend-abi) = %{php_zend_api}
Requires: php(api) = %{php_core_api}

will works with old provides (so there is no need to rebuild any package now).

When a package is rebuilt, it will use the new Arch specific ones.

The old provides will be removed when a new ABI will hit rawhide (php 5.4.0 ?), so when a rebuild will be mandatory.

Note : in the same way, php requires httpd-mmn = 20051115-x86-64 which is provided by httpd

3. Target version

This changes are only planned for fedora >= 15 (php-5.3.5-3)

So, if you need to add a %{_isa} to your package, this must be fedora >= 15 only. But in all cases, you will have to maintain 2 versions of your spec, or a conditional requires, because of EPEL (and git is your friend).

This have been discussed on the fedora-php-devel mailing list.

Comments are welcome.

PHP and Apache Security, SetHandler vs AddHandler

Posted by Remi Collet on December 05, 2016 12:03 PM

In official PHP packages in Enterprise Linux and Fedora <= 17, the engine was activated by the AddHandler directive. With Fedora 18, or for the users of my repository it is now activated by the SetHandler directive.

Some explanations.

Old version (in the /etc/httpd/conf.d/php.conf file)

AddHandler php5-script .php

As written in Apache documentation, the suffix presence, anywhere in the file name, will activate the engine. This can raise a security problem, in a public upload space, when a lack of control will allow a user to send an image.php.png file and execute it.

New version, recommended (§8) by PHP project documentation:

<FilesMatch \.php$>
    SetHandler application/x-httpd-php

Now, only a final suffix will activate the engine. So security is improved (even if I really think that giving the control on uploaded file name to the user is really a huge design error). I haven't notice any performance change.

Warning, this change may breaks some configurations.

In the case when you want to allow users to upload .php files in a public space, but deactivate the php engine (as on this blog).

With old configuration, you just have to remove the handler (and probably change the mime type):

<Directory /path/to/blog/public>
    RemoveHandler .php
<Files ~ "\.php$">
ForceType text/plain

This configuration will not work anymore, and must be changed.

For example, I use (and also enable the colorized output of sources for this space) :

<Directory /path/to/blog/public>
<FilesMatch \.php$>
    SetHandler None
ForceType text/plain
<FilesMatch \.phps$>
    SetHandler application/x-httpd-php-source

Ex : twit.php ou twit.phps

So, if you upgrade from Fedora 17 to Fedora 18, or if you update from PHP 5.3 to PHP 5.4 using my repository, don't forget to check and fix all your httpd configuration files.

Wheee, another addition.

Posted by Paul Frields on September 19, 2016 07:18 PM

The post Wheee, another addition. appeared first on The Grand Fallacy.

I’m thrilled to announce that Jeremy Cline has joined the Fedora Engineering team, effective today. Like our other recent immigrant, Randy Barlow, Jeremy was previously a member of Red Hat’s Pulp team. (This is mostly coincidental — the Pulp team’s a great place to work, and people there don’t just move to Fedora automatically.) Jeremy is passionate about and has a long history of open source contribution. We had many excellent applicants for our job opening, and weren’t even able to interview every qualified candidate before we had to make a decision. I’m very pleased with the choice, and I hope the Fedora community joins me in welcoming Jeremy!

Another addition.

Posted by Paul Frields on June 06, 2016 07:43 PM

The post Another addition. appeared first on The Grand Fallacy.

I’m extremely happy to announce that Randy Barlow has joined the Fedora Engineering team, effective today. Randy was previously a member of Red Hat’s team working on technologies like Pulp. You can find his fingerprints in many upstream repositories as a frequent contributor. This is fortunate for our team, since Randy will be contributing both to our applications infrastructure and to our release team. His experience with Pulp may come in handy too, since it may play a part in making next-generation Fedora content available to the public. I hope the Fedora community will join me in welcoming Randy!

Fedora Engineering team opening, April 2016.

Posted by Paul Frields on April 08, 2016 09:45 PM

The post Fedora Engineering team opening, April 2016. appeared first on The Grand Fallacy.

My day job, as you probably know, is at Red Hat, where I manage the Fedora Engineering team. Our team provides engineering and design services for the Fedora Project, a collaborative community project which is the upstream source for a number of influential products. Not the least of these is Red Hat Enterprise Linux, of course.

We now have a job opening for a senior engineer in the USA to be part of our team.

About the job

Collaborating with the rest of the team, the community at large, and your colleagues in Red Hat, you’ll:

  • Build tools and web services that will in turn build a more modular next-generation Fedora
  • Do full-stack development, with a hand in everything from working with designers, to architecting and writing code, to deploying in test/stage/production, to maintenance and enhancement
  • Automate, automate, automate all the things
  • Co-create and develop our next community engagement system, Fedora Hubs
  • Stay tuned into exciting work going on throughout Red Hat related to platform and other technologies
  • As with all Fedora Engineering jobs, communicate openly and continually with the whole community, and build community around everything you do using open source best practices

About the Fedora Engineering team

Our team uses a lot of Python (flask and sqlalchemy currently rank highly), and we’ll be expanding outward in the future where it makes sense. We create code upstream that is widely consumable beyond just Fedora, and we deploy our work on both Red Hat Enterprise Linux and Fedora.

We do that work openly: collaboration via git repositories, rapid and constant communication via IRC, frequent discussion through our mailing lists, and gathering and building community around our work. Simply put, we love open.

Who we’re looking for

The right candidate is a team player, positive and constructive, fully engaged and passionately committed to delivering results with their colleagues, wherever they might be. This is a senior position, so we’re looking for someone who’s a proactive, detail-oriented self-starter, and has the ability to lead from the side on a few projects. We want you to be really good at Python and being Pythonic, and hopefully have some similar high-level language experience like Ruby or Java where you can help us grow, too.

Not interested in working in a Red Hat office? No sweat. We’re a distributed team, and this job is perfect for an experienced remote candidate. Remote doesn’t mean aloof, though. You need to be somewhat of a people person to crush this job, because good open source means collaboration. We meet up at least once a year as a team for Flock, but we work together constantly online.

I would be remiss in not pointing out this position back-fills some mighty big shoes. That’s why I’ve outlined some ideas for who we’re looking for in this post. That being said, you’ll also be working for a manager who’s a super guy. Just check the sidebar of this blog for proof. In all seriousness though, we all care about our teammates’ success, so you’re never on your own when you need a hand.

And don’t forget, Red Hat is consistently rated one of the best and most innovative places to work.

Enough already, where do I apply?

Does this job sound interesting to you? Make sure you read the full description of the job, and then apply online.

Contributing to Pagure made easy.

Posted by Paul Frields on April 05, 2016 12:24 AM

The post Contributing to Pagure made easy. appeared first on The Grand Fallacy.

I don’t get as much of a chance these days to do things like patches or other technical contribution. But I had some time free the other day and used it to stick my hands directly into a cool project, Pagure (pronounced roughly “pag-yOOR,” or listen here). You may have read about Pagure in this Fedora Magazine article a few months back.

It was tremendously easy to get Pagure, fix a bug, test the fix, and contribute it back (see my pull request here). I specifically looked for “easyfix” bugs, since I knew I didn’t have a lot of time to spend to help. So I decided to work on this issue, a button showing up when it shouldn’t.

First I forked the repo in Pagure. Then I cloned my new fork, and set it up as documented in the README. In the clone, I checked out a new branch using the issue number as a name, issue839.

To track down the fix, I ran the app locally and duplicated the error. I looked at the CSS style containers for the button and some of the surrounding elements. Using that information, I did a text search on the code to find the file that was generating the button. Then I simply applied some logic to find the fix for the problem, even though I wasn’t really familiar with the code involved.

Thankfully Pagure has a test suite, so I could also check that my fix didn’t break any of the tests. Then I committed and pushed my changes, and made a pull request using the button in Pagure’s web page.

I also learned something useful. Since I forked the repo to do my fix and make a pull request, if I force-pushed changes using git to my branch from which I made the pull request, the pull request was automatically updated with the changes! This is probably expected by people who do this all the time, but since I’m new at it, I was excited.

Bugs like this are something that just about anyone with a small amount of beginning programming skill could fix. Pagure even has other bugs like this waiting for people to handle. Maybe one of them is waiting for you! 😉

Travels, 2016.

Posted by Paul Frields on February 03, 2016 12:06 PM

The post Travels, 2016. appeared first on The Grand Fallacy.

I realized that some folks around the Fedora community may wonder why they don’t see me around as often this week and next week. I’m still alive and well, but I’m traveling in the Czech Republic. I’m currently in Brno for some Red Hat departmental meetings. Following that, I’ll be attending the Devconf.cz event. Then I’ll be back in the Brno office for a few days of other work and team meetings. I’ll be back in my home office on Monday, February 15th and around as usual at that point.

Fedora summer 2016 internships.

Posted by Paul Frields on October 28, 2015 06:29 PM

The post Fedora summer 2016 internships. appeared first on The Grand Fallacy.

There are three USA internship positions open at Red Hat on the Fedora Engineering team. These internships are all available this coming summer (2016). Read below for some more details.

I feel like my recent blog posts have all been about openings. But it’s nice to be able to offer them. Each internship on our job site is linked in the bullets below, so you can apply for any for which you feel qualified.

  • Software engineering internship – This internship focuses primarily on Python software development. You’ll take designs and build them into widgets for our Fedora Hubs project. You’ll collaborate with our applications team on back-end technology for the community. You’ll also work with our infrastructure team on production deployment. This internship also includes other related projects, not limited to just Hubs. The intern is preferably in Westford, MA for the summer. But that’s not strictly required for a well-qualified candidate with experience working in a global open source project. (In other words, if you can succeed at keeping touch daily with the team as a remotee, don’t let the location throw you.)
  • User experience and design internship – This intern will work directly with our designers Máirín Duffy and Ryan Lerch on research and design for Fedora projects such as Hubs. You’ll do user research and work on improving interaction in our web apps and other associated projects. You’ll collaborate with the other interns, our whole development team, and the Fedora community at large. This job is in Westford, MA.
  • Web development internship – This intern will work primarily (but not exclusively) on web apps at the front end. You’ll turn design into reality, and streamline existing applications to designer specs to build a more unified project. As with our other internships, you’ll be able to explore and work on other projects too. You’ll work with our design team, the community Websites team and our application developers to create and improve web tools our contributors will use for years. This job is preferably in Westford, MA for the summer. But we’ll consider remote for an exceptionally qualified candidate.

These jobs should end up being quite competitive. So I encourage you to get your application in as soon as you can!

Last year, we were fortunate to have superb interns who produced fantastic results. Meghan Richardson worked on many of the initial designs for Hubs in its early stages, interviewing potential users and then creating the workflows and feel for this new tool. Nate Yazdani worked on statscache, which compiles data from our messaging bus to make it available quickly to other apps, without constantly crushing our data store.

Red Hat is a fantastic company at which to intern, and we pride ourselves on an open and inclusive culture. These are not “fetch coffee” jobs — you’ll work on real problems alongside real experts.

We can’t wait to see what you can do!

Outreachy internship available

Posted by Paul Frields on October 16, 2015 03:00 PM

The post Outreachy internship available appeared first on The Grand Fallacy.

Here’s a fantastic opportunity in open source for folks from underrepresented backgrounds. The Fedora Engineering team has an Outreachy internship available December 2015 to March 2016. Applications are being accepted at the Outreachy site. The deadline is 1900 UTC Monday, November 2, 2015.


Are you familiar with Outreachy? It’s a program designed to boost participation in open source by underrepresented groups. My employer, Red Hat, is sponsoring this internship.  The Fedora Project, which my team at Red Hat supports, is proud to partner in offering it. This Fedora internship is an opportunity to work directly with our senior software engineers on a major project called Fedora Hubs.

Hubs is an initiative to bring better and more timely information to Fedora’s large community of participants and contributors. Several of our engineers will collaborate with you throughout the internship period on this project. We’ll use Hubs as a foundation for regular, daily mentoring of our Outreachy intern. You’ll use best of breed technologies like Python, Bootstrap, jinja templates, and more. Best of all, you’ll work alongside the team in real time.

You can read more about the internship and qualifications here on our wiki. The page also has general information about Fedora, such as our mission and how we work together.

But this internship isn’t just extending your skills, or working with awesome people. (Even though that’s a great incentive!) It’s also about bringing the open source way to thousands of people. This project lets contributors build sub-communities, or hubs, around their interests. “Standing on the shoulders of giants” is one of the greatest benefits of open source. The same goes for using open source to build communities. It’s a natural fit and a wonderful outcome for a successful internship.

Are you interested in diving deeper into Hubs, to see what this internship is about? Check out this recent blog post from our own Máirín Duffy on the purpose, design, and mockups of the Hubs project.

We’re looking forward to seeing your application. Remember the deadline is 7pm in UTC time on Monday, November 2, which is mid-day for any USA applicants.

Flock 2015 thoughts.

Posted by Paul Frields on August 18, 2015 04:37 PM

The post Flock 2015 thoughts. appeared first on The Grand Fallacy.

Getting started at Flock

Like everyone on the Fedora Engineering team, I was in Rochester for the Flock conference last week. After several flight delays on our direct flight from DCA to Rochester, Justin Forbes, Ricky Elrod, and I finally arrived a little after 9:00pm — about four hours late. Thankfully Josh Boyer came to pick us up at the airport.

Flock had a team of organizers within OSAS (and Josh also assisted throughout). As a former FUDCon organizer, though, I know the value of extra hands showing up to do work. Since old habits die hard, I showed up expecting to help out behind the scenes. That means I didn’t get to see a huge amount of content I was personally interested in. But in return hopefully everyone had a smoother Flock experience, especially speakers.

When I arrived, I reported to Tom Callaway, Ruth Suehle, and Josh. They got the conference rooms opened, and I helped set up the speaker workstations. We worked pretty late, well after midnight. Things were looking a little bleak at that point, with execrable network bandwidth, no projectors, no screens, and no audio for the ballroom.

Fears and worries abate

Nevertheless, the next morning Josh and I got up early and grabbed coffee at nearby Tedward’s. This place was a godsend, although their 7:00am opening time forced us to walk around a bit until we could get in.

We went down to do some additional setup. The organizers had worked with Remy DeCausemaker to get a bunch of loaner projectors from RIT so we’d be ready for the first sessions at 10:00am. (EDIT: According to Remy, Tim Duffy and Dan Schneiderman are the heroes of this particular day; see comments below.) So at least our speakers would be in OK shape. I helped Josh and Tom get everything ready in those rooms, while Ruth made sure registration and other logistics were under control. I missed Matthew Miller’s keynote, but I’d seen at least some of the material previously.

After lunchtime, things continued to drastically improve. The rental projectors showed up, along with small screens for each room and big speakers for the ballroom. The wireless internet improved quite a bit when a switch flip occurred due to our conference starting up. (It was dismal Tuesday night!) We had all the speakers trained on how to record their talks locally, to get around the constrained network bandwidth.

Suddenly things were looking up! Not surprisingly, the Fedora Engineering team dinner that night at The Old Toad was much more enjoyable. Since I wasn’t overly worried about the conference experience for the speakers and attendees any longer, it was easier to relax and enjoy the company of the team. I was so happy that we were able to get together in one place, since we really only get to do that once a year. (Incidentally, our friend Stephen Smoogen was absent from Flock due to family commitments — we missed you, Smooge!)

<figure class="wp-caption alignleft" id="attachment_4622" style="width: 1024px">Fedora contributors at Flock gather at Victoire for dinner<figcaption class="wp-caption-text">Fedora contributors at Flock gather at Victoire for dinner</figcaption></figure>

I continued to monitor speaker rooms most of Wednesday and Thursday. I managed to make it to a couple sessions where I wasn’t sure there would be any senior Fedora leadership around. For example, I attended the Fedora Magazine session by Chris Roberts as well as most of the Fedora Hubs session by Máirín Duffy and Meghan Richardson.

I attended and loved Major Hayden‘s (of Rackspace fame) Thursday keynote on fighting impostor syndrome. It was one of the most practical that I’ve seen on this topic. I feel impostor syndrome is just a fancy way to refer to insecurity, a common trait for conscientious people. But that doesn’t make the strategies Major outlined any less useful or thoughtful. He gave a great talk — engaging and humorous without diluting the material. If you have a chance to invite him to a conference to speak, definitely do so!

I gave my own talk on Remote Ninjutsu on Thursday afternoon. The slides for the talk are here, although the video will be more useful for context. All the Flock 2015 videos are supposed to be available at some point in the next couple of weeks. Stay tuned for announcements about them.

The Thursday night social event at the Strong National Museum of Play was fantastic. It was a great way to blow off steam and enjoy the company of fellow Fedorans. I’m not sure how the organizers managed to find such a perfect venue!

Workshops and Flock wrap-up

On Friday I enjoyed the keynote by Jon Schull of eNable, the community that is flipping the script on prosthetics provision through 3D printing. It was a very moving look at how people are applying open source to make the world better for people in need.

Then the workshops beckoned. Now that I’d finished my Flock duties helping speakers and attendees, I was able to attend several sessions that were relevant to me personally, including the Fedora/CentOS rel-eng joint session, and my own on revamping the Flock software stack.

Once again, the Friday night social event at the George Eastman House was marvelous. It was a beautiful, grand mansion and the tour was quite interesting. I’d love to go back there sometime to see the exhibits I missed!

<figure class="wp-caption alignleft" id="attachment_4625" style="width: 1024px">The music parlor in the George Eastman House<figcaption class="wp-caption-text">The music parlor in the George Eastman House</figcaption></figure>

Flock conferences are always especially great for their hallway track. So many discussions can be had or progressed that way with high bandwidth. The challenge is always to move that discussion to a transparent context if it involves people not present, though. I’ve been seeing many trip reports from people’s blogs about Flock, and resulting list discussions, so I think that process is well underway.

Of course, that means Flock is a very engaging event. It takes a lot of attention and brainpower to shift focus for all those conversations! As a result, by Saturday afternoon I know I was fairly exhausted — in a good way, though. Several other people I know felt likewise, and commented on how well the conference had gone. In fact, I heard a number of comments that this was the best Flock, and even Fedora premier event, yet. The OSAS folks deserve special recognition for pulling off a fantastic conference.

Sunday started with a couple meetings, including with Matthew Miller and Jan Ku?ík, our new Fedora program manager. Then, after seeing a few other friends and colleagues off, I got to the airport. I relaxed in a lounge over beers with Kevin Fenzi, Jan Zeleny, and Stephen Tweedie, before we went to our respective flights. Then after a quick flight home, it was the usual “fun” making my way down I-95 from the airport to home. Monday morning was right around the corner…

Here’s to another great Flock, and to doing it again next year!

<figure class="wp-caption alignleft" id="attachment_4627" style="width: 1024px">Flock attendees wind down after the conference ends... with more hacking!<figcaption class="wp-caption-text">Flock attendees wind down after the conference ends… with more hacking!</figcaption></figure>

How to quickly migrate mail from Evolution to Thunderbird with Dovecot

Posted by Christoph Wickert on May 24, 2015 12:08 PM

Fedora 22 is just around the corner and while upgrading my machine, I decided to completely ditch Gnome’s Evolution in favor of Mozilla Thunderbird. I had already switched a while back, but still had tons of mail in an old local Evolution account I wanted to migrate.

Unfortunately all HowTos I found on the web assume Evolution would store mail in the mbox format, while it switched to maildir in version 3.2.0. MozillaZine suggests to first convert maildir to mbox and then import the resulting files with the ImportExportTools extension. Why so cumbersome if there is the excellent Dovecot IMAP server that can read both maildir and mbox?

Migrating mail with Dovecot is straight forward. Quit Evolution and install dovecot:

yum install dovecot

Then set it to use Evolution’s local storage as mail location:

echo "mail_location = maildir:~/.local/share/evolution/mail/local/" \
 >> /etc/dovecot/conf.d/10-mail.conf
service dovecot start

Fire up Thunderbird, configure a new account for your user on localhost and copy over all mail from this account to the “Local folders”. There you go!

Protected: Freewrite 2015-05-13

Posted by Toshio Kuratomi on May 13, 2015 01:33 PM

This post is password protected. You must visit the website and enter the password to continue reading.

The most important Flock Talk

Posted by Toshio Kuratomi on May 05, 2015 04:09 PM

I was just voting on FLOCK talks and happened upon this talk proposal:

What does Red Hat Want?

It’s no secret that many Fedora participants work for Red Hat. Or that Red Hat provides funding for the Fedora Infrastructure. There have been many conspiracy theories over the years centering on what, exactly, does Red Hat want out of Fedora in return. This talk, by the Red Hat VP who runs the RHEL engineering team, proposes to address that eternal question. What does Red Hat want? Join Denise Dumas to learn what Red Hat is working on next and how we would like to work with the Fedora community

In my time working for Red Hat on Fedora I often found that the Fedora Community was operating in a vacuum.  We wanted to run a Linux Distribution that we had a stake in and a chance to modify to our needs.  We also knew that Red Hat invested a considerable amount of money into Fedora to support our being able to do that.  But what we were in the dark about was what Red Hat expected to get out of this partnership and what they wanted us to do to justify their continued investment.  Although over time we did get our hands dirty maintaining more of the packages that made up the distribution, in a lot of ways we never graduated beyond mricon’s 2004 tongue-in-cheek posting about Red Hat’s relationship to its community (and its own internal divisions at the time).

In the last few years, Red Hat’s portfolio of products and future directions have greatly expanded.  No longer just a producer of a Linux distribution, Red Hat is pursuing revenue sources in application middleware, both IaaS and PaaS pieces of the cloud, and containers.  They also have engineers working on a multitude of open source solutions that enhance these basic products, adding flesh to the framework they set up.  But where does the Fedora Community fit into this expanded roster of technologies?  The Fedora Product has been very focused on “A Linux Distro” for a number of years but the Fedora Community is very broad and multi-talented.  I’m hoping that Denise’s talk will provide an entrypoint for Fedora Contributors to start talking about what new directions they can take the Project in that would align with Red Hat’s needs.  There’s a number of difficulties to work out (for instance, how does Fedora keep its identity while at the same time doing more work on these things that have traditionally been “Upstream Projects”) but we can’t even begin to solve those problems until we understand where our partner in this endeavour wants to go.

Flock Ansible Talk

Posted by Toshio Kuratomi on March 30, 2015 04:41 PM

Hey Fedorans, I’m trying to come up with an Ansible Talk Proposal for FLOCK in Rochester. What would you like to hear about?

Some ideas:

* An intro to using ansible
* An intro to ansible-playbook
* Managing docker containers via ansible
* Using Ansible to do X ( help me choose a value for X 😉
* How to write your own ansible module
* How does ansible transform a playbook task into a python script on the remote system

Let me know what you’re interested in 🙂

Hacky, hacky playbook to upgrade several Fedora machines

Posted by Toshio Kuratomi on December 20, 2014 09:13 PM

Normally I like to polish my code a bit before publishing but seeing as Fedora 21 is relatively new and a vacation is coming up which people might use as an opportunity to upgrade their home networks, I thought I’d throw this extremely *unpolished and kludgey* ansible playbook out there for others to experiment with:


When I recently looked at updating all of my systems to Fedora 21 I decided to try to be a little lighter on network bandwidth than I usually am (I’m on slow DSL and I have three kids all trying to stream video at the same time as I’m downloading packages). So I decided that I’d use a squid caching proxy to cache the packages that I was going to be installing since many of the packages would end up on all of my machines. I found a page on caching packages for use with mock and saw that there were a bunch of steps that I probably wouldn’t remember the next time I wanted to do this. So I opened up vim, translated the steps into an ansible playbook, and tried to run it.

First several times, it failed because there were unsolved dependencies in my packageset (packages I’d built locally with outdated dependencies, packages that were no longer available in Fedora 21, etc). Eventually I set the fedup steps to ignore errors so that the playbook would clean up all the configuration and I could fix the package dependency problems and then re-run the playbook immediately afterwards. I’ve now got it to the point where it will successfully run fedup in my environment and will cache many packages (something’s still using mirrors instead of the baseurl I specified sometimes but I haven’t tracked that down yet. Those packages are getting cached more than once).

Anyhow, feel free to take a look, modify it to suit your needs, and let me know of any “bugs” that you find 🙂

Things I’ll probably do to it for when I update to F22:

Quick question for Fedora Planet

Posted by Toshio Kuratomi on December 20, 2014 06:38 PM

Hey Fedora Planet, quick survey: I’ve been doing some blogging on general python programming and on learning to use Ansible. Are either of these topics that you’d be interested in showing up on planet? Right now the feed I’m sending to planet only includes Fedora-specific posts, linux-specific, or “free software political” but I could easily change the feed to include the ansible or python programming posts if either of those are interesting to people.

Leave me a comment or touch base with me on IRC: abadger1999 on freenode.

A going away present

Posted by Toshio Kuratomi on August 15, 2014 06:17 PM

For those who haven’t heard through Flock or the rumor mill, today is my last day at Red Hat and also the beginning of a hiatus from working on Fedora. Since I’ve been asked this many times in the past few weeks, this is because I’ve become a bit burnt out having worked on Fedora as both my day job and my hobby for the past seven years. It’s time for me to pull back, let fresh faces fill the roles I held, and do something else for a while to add some spice and variety. I may come back to Fedora or to Red Hat in the future but at the moment I’m only looking far enough ahead to see that I need to go forth and have some new experiences.

I do want to say thank you to all the wonderful people who have worked not just to make the Fedora distribution a solid piece of software but also filled Fedora with friendly faces and kind words. Truly, although I’m physically far removed from the rest of you, you are my neighbors, my community, and my friends. Even though I’m stepping away from working on Fedora, I hope to keep in touch with you via IRC for many many years.

I’d also like to announce that I woke up this morning to find that I’d been made the gatekeeper for a new Fedora Badge. As the badge submitter describes it:

Dancing with ToshioI dream of a future where Toshio could fully express his techniques with the complicity and trust of many dance partners, responding to his moves and being pushed forward by him in the arts of dancing; exchanging, learning, growing as a vibrant community.

-Aurelien Bompard

Taking away the specifics of dancing and myself, this is my hope for everyone who participates in Fedora: to be able to grow in sympathy with a larger community.

With that in mind, if we’ve danced together and you would like this badge, please contact me (abadger1999 on IRC, toshio.fedoraproject.org via email). I can’t remember everyone’s FAS usernames but I’m extremely happy to award you the badge if you remind me what of what it is 🙂

Trip report from Flock 2014

Posted by Jared Smith on August 12, 2014 04:43 PM

I recently returned home from Prague, where I attended the Flock conference.  In it’s second year, the Flock conference is a gathering of free software developers, most of whom work in the Fedora community.  Rather than give a blow-by-blow account of every talk I attended and every conversation I had (which would be exhausting), I’ll instead focus on the highlights of the conference.

Location, Venue, and Accommodations

I was very impressed with the location of the conference.  The university was within a five minute walk of the hotel, and close to several convenient tram and metro stops.  The classrooms were well furnished with power connections and comfortable seats, and the larger auditoriums were big enough to handle a big crowd.  The hotel was very nice as well — the lobby was spacious, which made for lots of impromptu meetings and hanging out.  Getting from the airport to the hotel was super-easy as well, as was the return trip.  Also, the cafeteria where we had lunch was was exceptional — the food was delicious, and the location couldn’t have been more perfect.


There were several themes that resonated with me as I attended the conference.  The first was around the changes to the Fedora release products (collectively referred to as Fedora.Next) in Fedora 21 and future releases.  Whereas at last year’s Flock conference there was a lot of apprehension and negativity some of the proposed changes, this year I noticed a remarkably more upbeat attitude toward the changes.  There was a lot of great discussion round how to get the technical work done that’s needed in order to make Fedora 21 (and 22, and so on) a success.

The next theme that resonated with me was documentation.  Maybe it’s because I was giving a talk on documentation, but I felt there was a lot more interest and cohesion around doing a better job of documenting Fedora than I saw at last year’s conference.  Both my talk (on Docbook and Publican) and Jaromir’s talk on Mallard were packed, and the two documentation workshops were very well attended as well.  At one point during Friday’s workshops, I counted 22 people (besides myself) in the room working on Docs.  We also had several new people dive right in and start working on writing documentation, so that was great to see as well.

The third theme that I focused on was ARM processors.  The support in Fedora for ARM has grown tremendously over the past couple of years.  Peter Robinson’s “ARM State of the Union” talk showed just how far support for ARM has come — both in 32-bit ARM as a primary architecture and with 64-bit ARM as a secondary arch.  The ARM workshop on Saturday was great too — I was able to confirm that as of the 3.16 kernel, we now support the Plat’home OpenBlocks AX3 and Mirabox as two more Marvell Armada-based devices that will work great in Fedora 21.  (They both require appending the .dtb to the kernel, but other than that, they seem to be working great.)

Last but not least, it was great to have a lot of hallway discussions with friends and colleagues.  I had too many discussions to be able to remember them all, let alone discuss them here on my blog, but I thoroughly enjoyed catching up with many old friends and making some new ones as well.  I always look forward to opportunities to rub shoulders with so many of the fantastic people that make the Fedora community great.


Thanks to Ruth and Spot and Josh and Miro and all the other folks who worked hard to organize the conference.  Thanks to Red Hat for sponsoring my flight, and thanks to my employer, Bluehost, for sponsoring the conference and allowing me the opportunity to be in Prague for the conference.  Also, thanks to each one of the presenters for making Flock 2014 a great conference.

Hacking a Wifi Kettle

Posted by Mark Cox on February 23, 2014 07:20 PM

Here is a quick writeup of the protocol for the iKettle taken from my Google+ post earlier this month. This protocol allows you to write your own software to control your iKettle or get notifications from it, so you can integrate it into your desktop or existing home automation system.

The iKettle is advertised as the first wifi kettle, available in UK since February 2014. I bought mine on pre-order back in October 2013. When you first turn on the kettle it acts as a wifi hotspot and they supply an app for Android and iPhone that reconfigures the kettle to then connect to your local wifi hotspot instead. The app then communicates with the kettle on your local network enabling you to turn it on, set some temperature options, and get notification when it has boiled.

Once connected to your local network the device responds to ping requests and listens on two tcp ports, 23 and 2000. The wifi connectivity is enabled by a third party serial to wifi interface board and it responds similar to a HLK-WIFI-M03. Port 23 is used to configure the wifi board itself (to tell it what network to connect to and so on). Port 2000 is passed through to the processor in the iKettle to handle the main interface to the kettle.

Port 2000, main kettle interface

The iKettle wifi interface listens on tcp port 2000; all devices that connect to port 2000 share the same interface and therefore receive the same messages. The specification for the wifi serial board state that the device can only handle a few connections to this port at a time. The iKettle app also uses this port to do the initial discovery of the kettle on your network.


Sending the string "HELLOKETTLE\n" to port 2000 will return with "HELLOAPP\n". You can use this to check you are talking to a kettle (and if the kettle has moved addresses due to dhcp you could scan the entire local network looking for devices that respond in this way. You might receive other HELLOAPP commands at later points as other apps on the network connect to the kettle.

Initial Status

Once connected you need to figure out if the kettle is currently doing anything as you will have missed any previous status messages. To do this you send the string "get sys status\n". The kettle will respond with the string "sys status key=\n" or "sys status key=X\n" where X is a single character. bitfields in character X tell you what buttons are currently active:

Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1

So, for example if you receive "sys status key=!" then buttons "100C" and "On" are currently active (and the kettle is therefore turned on and heating up to 100C).

Status messages

As the state of the kettle changes, either by someone pushing the physical button on the unit, using an app, or sending the command directly you will get async status messages. Note that although the status messages start with "0x" they are not really hex. Here are all the messages you could see:

sys status 0x100100C selected
sys status 0x9595C selected
sys status 0x8080C selected
sys status 0x10065C selected
sys status 0x11Warm selected
sys status 0x10Warm has ended
sys status 0x5Turned on
sys status 0x0Turned off
sys status 0x8005Warm length is 5 minutes
sys status 0x8010Warm length is 10 minutes
sys status 0x8020Warm length is 20 minutes
sys status 0x3Reached temperature
sys status 0x2Problem (boiled dry?)
sys status 0x1Kettle was removed (whilst on)

You can receive multiple status messages given one action, for example if you turn the kettle on you should get a "sys status 0x5" and a "sys status 0x100" showing the "on" and "100C" buttons are selected. When the kettle boils and turns off you'd get a "sys status 0x3" to notify you it boiled, followed by a "sys status 0x0" to indicate all the buttons are now off.

Sending an action

To send an action to the kettle you send one or more action messages corresponding to the physical keys on the unit. After sending an action you'll get status messages to confirm them.

set sys output 0x80Select 100C button
set sys output 0x2Select 95C button
set sys output 0x4000Select 80C button
set sys output 0x200Select 65C button
set sys output 0x8Select Warm button
set sys output 0x8005Warm option is 5 mins
set sys output 0x8010Warm option is 10 mins
set sys output 0x8020Warm option is 20 mins
set sys output 0x4Select On button
set sys output 0x0Turn off

Port 23, wifi interface

The user manual for this document is available online, so no need to repeat the document here. The iKettle uses the device with the default password of "000000" and disables the web interface.

If you're interested in looking at the web interface you can enable it by connecting to port 23 using telnet or nc, entering the password, then issuing the commands "AT+WEBS=1\n" then "AT+PMTF\n" then "AT+Z\n" and then you can open up a webserver on port 80 of the kettle and change or review the settings. I would not recommend you mess around with this interface, you could easily break the iKettle in a way that you can't easily fix. The interface gives you the option of uploading new firmware, but if you do this you could get into a state where the kettle processor can't correctly configure the interface and you're left with a broken kettle. Also the firmware is just for the wifi serial interface, not for the kettle control (the port 2000 stuff above), so there probably isn't much point.

Missing functions

The kettle processor knows the temperature but it doesn't expose that in any status message. I did try brute forcing the port 2000 interface using combinations of words in the dictionary, but I found no hidden features (and the folks behind the kettle confirmed there is no temperature read out). This is a shame since you could combine the temperature reading with time and figure out how full the kettle is whilst it is heating up. Hopefully they'll address this in a future revision.

Security Implications

The iKettle is designed to be contacted only through the local network - you don't want to be port forwarding to it through your firewall for example because the wifi serial interface is easily crashed by too many connections or bad packets. If you have access to a local network on which there is an iKettle you can certainly cause mischief by boiling the kettle, resetting it to factory settings, and probably even bricking it forever. However the cleverly designed segmentation between the kettle control and wifi interface means it's pretty unlikely you can do something more serious like overiding safety (i.e. keeping the kettle element on until something physically breaks).

Rest, my friend, the next five years are ours to pass along your wisdom

Posted by Toshio Kuratomi on January 10, 2014 08:34 AM

Just installed a new system and was having ssh connections timeout. Then I remembered talking about this same issue last year on IRC. The anecdote is amusing so I figured I would post the logs:

[Mon April 22 2013] * abadger1999 wishes he knew why his ssh connections to infra keep on hanging.
[Mon April 22 2013] <abadger1999> it’s a timeout of some sort… I just don’t know what.
[Mon April 22 2013] <skvidal> abadger1999: did you reinstall recently?
[Mon April 22 2013] <abadger1999> skvidal: nope
[Mon April 22 2013] <abadger1999> skvidal: would that help?
[Mon April 22 2013] * abadger1999 still on f17
[Mon April 22 2013] <skvidal> I have found I often need to set
[Mon April 22 2013] <skvidal> net.ipv4.tcp_keepalive_time = 300
[Mon April 22 2013] <skvidal> in /etc/sysctl.conf
[Mon April 22 2013] <skvidal> to not get timeouts
[Mon April 22 2013] <abadger1999> Thanks. I’ll try that .


[Wed April 24 2013] <abadger1999> skvidal: btw, your sysctl recipe seems to have fixd my ssh timeout issues. Thanks!
[Wed April 24 2013] <skvidal> abadger1999: 🙂
[Wed April 24 2013] <skvidal> abadger1999: last time it happened to me I had to google for the solution
[Wed April 24 2013] <skvidal> abadger1999: and I found a post from myself from 5yrs earlier
[Wed April 24 2013] <skvidal> abadger1999: _that_ is kinda freaky
[Wed April 24 2013] <pingou> isn’t that what blog are for? 🙂
[Wed April 24 2013] <dwa> nice
[Wed April 24 2013] <abadger1999> Cool 🙂
[Wed April 24 2013] <skvidal> “wow, this dude knew what was going on…. but he sure writes like he’s an ass”
[Wed April 24 2013] <skvidal> “oh….. wait”



Picture of Seth from 2005 looking into the distance

Seth, you were more of a teddy bear than an ass.

حمایت از یک کار فرهنگی ارزشمند در لینوکس ایران

Posted by Mostafa Daneshvar on December 12, 2013 10:22 AM

بهنام توکلی را کسانی که در دنیای گنو-لینوکس ایران به خوبی می شناسند. او مدیر مرکز گنو/لینوکس  سی‌تو است که در تهیه و توزیع انواع گنو-لینوکس ها دستی به کار دارد. او مدتی است با راه انداختن یک کمپین برای تولید مجله‌ای به نام لینوکس‌مگ خیز بلندی برای گسترش فرهنگ گنو برداشته است.

بنده به نوبه خودم از زحمات این عزیز برای کارهایی که تا به حال انجام داده سپاسگزاری می کنم. از همه دوستانی که این نوشته را می خوانند خواهش می کنم با کمک با این مجله شروع خوبی را برای آن رقم بزنند.

لینوکس مگ

لینوکس مگ

شما می توانند با واریز مبلغ حداقل ۲۴هزار تومان به این جریان کمک کنید. اگر هم شرکتی دارید یا وسع مالی بیشتر پس درنگ نکنید.

برای کمک به لینوکس مگ به این لینک مراجعه فرمایید.

اگر هم سوالی در این باره دارید می توانید به لیست سوالات متداول مربوط به آن مراجعه کنید.

با تشکر

مصطفی دانشور – فدورا

git commit doesn’t commit? (GitPython bug)

Posted by Toshio Kuratomi on November 04, 2013 08:30 PM

Mostly posting this to remind myself of the fix the next time I run into this but htis might help some other people as well.

Every once in a while I’ll be working on a git repo in the fedora packages repository and when I git commit -a it, I’ll end up with an empty commit and the files with changes aren’t actually committed. Other intuitive variations of this like git add FILE && git commit have the same buggy behaviour.

The reason this is occurring has something to do with the GitPython library which is used by fedpkg to add some changes to your clone of the git repo when you add new source files. It’s somehow changing the index in a way that causes this behaviour. To get out of this there’s a few simple but non-intuitive things you can try:

git reset FILE && git add FILE

git stash && git stash pop

After running one of those pairs of commands you should once more be able to git commit -a.

Details in this GitPython bug report

rsync unbundles zlib!

Posted by Toshio Kuratomi on August 07, 2013 11:17 PM

Over a year ago I mentioned that the code that rsync needed in order to start using vanilla zlib was finally on its way to being merged.  And today, we’ve finally built an rsync package that completes that saga.

یک خبر بد برای جامعه فدورا

Posted by Mostafa Daneshvar on July 09, 2013 08:26 PM

امروز خبری بسیار بدی به من رسید. لیدر تیم فدورا رابین در لیست فوت یکی از اعضای کلیدی جامعه فدورا و متن باز خبر می داد. سث ویدال توسعه دهنده اصلی یام (yum) برنامه نصاب سیستم‌هایی مانند فدورا و ردهت در یک سانحه از دنیا رفت. خبر را با یکی از دوستان ایرانی در ردهت چک کردم متاسفانه خبر درست بود.



سث ویدال وقتی که سوار بر دوچرخه خود بود در یک برخورد از پشت سر توسط یک ماشین سواری به شدت آسیب می بیند. راننده ماشین بعد از این تصادف از محل حادثه می گریزد. بنابر اخبار تاکنون راننده هنوز دستگیر نشده است.

سث از افراد بسیار فعال در زمینه جامعه کاربری و توسعه دهنده نرم‌افزارهای متن باز و آزاد بود. زمانی که به دلایلی با شرکت ردهت مشکلاتی داشتیم او با تمام توان از ما و دوستان ایرانی فدورا حمایت می کرد. این مقدمه بر دوستی چند ساله‌ی مان بود. در این مدت همیشه از طریق دوست مشترک ایرانی مان در ردهت دورا دورا جویای اخبار وی بودم.

از دست دادن این نیروی ارزشمند را به جامعه فدورا تسلیت می گویم.

Why Fedora Project Contributor Agreement (FPCA) does no harm

Posted by Marcel Ribeiro Dantas on June 27, 2013 03:00 PM
The main reason for this post is to prepare Fedora Ambassadors and Contributors for attempts of others to say FPCA is as bad as Canonical's CLA and that our legal document can do harm as much as theirs. Recently, many posts around the web have spoken of the possible trap Canonical may be setting up. They released Mir, a computer display server for GNU/Linux, under the terms of a copyleft license, the GNU GPLv3, which was supposed to be very well seen by the community. Choosing the GNU GPLv3 as the license of your software makes it clear tha you really care about freedom, since GNU GPLv3 is a very effective license against DRM, software patents and attempts to close the source code of the software...

GNU GPLvX or any later version

Posted by Marcel Ribeiro Dantas on June 27, 2013 03:00 PM
When it comes to releasing your software's source code, it's extremely important to choose very carefully the best license available, in order to make sure your source code will be taken care of, used, distributed and modified in the way you expect it to be. Most free softwares are released under a GNU license, a large number of them licensed under the GNU General Public License (about 68% of the projects listed on SourceForge.net, as of January 2006)...

Free Software is about USERS

Posted by Marcel Ribeiro Dantas on June 27, 2013 03:00 PM
Since the Free Software Movement was created by the hands of software developers, people nowadays tend to think it's a movement from developers to developers, or from technical people to technical people. Unfortunately, it's a common misconception that has spread all over the community and leads people to believe the four essential freedoms are aimed only at software developers...

MirrorManager 1.4 now in production in Fedora Infrastructure

Posted by Matt Domsch on June 20, 2013 01:39 AM

After nearly 3 years in on-again/off-again development, MirrorManager 1.4 is now live in the Fedora Infrastructure, happily serving mirrorlists to yum, and directing Fedora users to their favorite ISOs – just in time for the Fedora 19 freeze.

Kudos go out to Kevin Fenzi, Seth Vidal, Stephen Smoogen, Toshio Kuratomi, Pierre-Yves Chivon, Patrick Uiterwijk, Adrian Reber, and Johan Cwiklinski for their assistance in making this happen.  Special thanks to Seth for moving the mirrorlist-serving processes to their own servers where they can’t harm other FI applications, and to Smooge, Kevin and Patrick, who gave up a lot of their Father’s Day weekend (both days and nights) to help find and fix latent bugs uncovered in production.

What does this bring the average Fedora user?  Not a lot…  More stability – fewer failures with yum retrieving the mirror lists, not that there were many, but it was nonzero.  A list of public mirrors where the versions are sorted in numerical order.

What does this bring to a Fedora mirror administrator?  A few new tricks:

  • Mirror admins have been able to specify their own Autonomous System Number for several years.  Clients on the same AS get directed to that mirror.  MM 1.4 adds the ability for mirror admins to request additional “peer ASNs” – particularly helpful for mirrors located at a peering point (say, Hawaii), where listing lots of netblocks instead is unwieldy.  As this has the potential to be slightly dangerous (no, you can’t request ALL ASNs be sent your way), ask a Fedora sysadmin if you want to use this new feature – we can help you.
  • Multiple mirrors claiming the same netblock, or overlapping netblocks, were returned to clients in random order.  Now they will be returned in ascending netblock size order.  This lets an organization that has a private mirror, and their upstream ISP, both have a mirror, and most requests will be sent to the private mirror first, falling back to the ISP’s mirror.  This should save some bandwidth for the organization.
  • If you provide rsync URLs, You’ll see reduced load from the MM crawler as it will now use rsync to retrieve your content listing, rather than a ton of HTTP or FTP requests.

What does this bring Fedora Infrastructure (or anyone else running MirrorManager)?

  • reduced memory usage in the mirrorlist servers.  Especially with as bad as python is at memory management on x86_64 (e.g. reading in a 12MB pickle file blows out memory usage from 4MB to 120MB), this is critical.  This directly impacts the number of simultaneous users that can be served, the response latency, and the CPU overhead too – it’s a win-win-win-win.
  • An improved admin interface – getting rid of hand-coded pages that looked like they could have been served by BBS software on my Commodore 64 – for something modern, more usable, and less error prone.
  • Code specifically intended for use by Debian/Ubuntu and CentOS communities, should they decide to use MM in the future.
  • A new method to upgrade database schemas – saner than SQLObject’s method.  This should make me less scared to make schema changes in the future to support new features.  (yes, we’re still using SQLObject – if it’s not completely broken, don’t fix it…)
  • Map generation moved to a separate subpackage, to avoid the dependency on 165MB of  python-basemap and python-basemap-data packages on all servers.

MM 1.4 is a good step forward, and hopefully I’ve laid the groundwork to make it easier to improve in the future.  I’m excited that more of the Fedora Infrastructure team has learned (the hard way) the internals of MM, so I’ll have additional help going forward too.

Vienna Calling!

Posted by Christoph Wickert on May 10, 2013 05:11 PM

Last weekend I attended Linuxwochen Wien for the first time. I heard a lot about the event, so I totally wanted to go there. Now that I’m back from Vienna, I am a little disappointed – but nevertheless happy I went there.

The Austrian Linuxwochen (Linux Weeks) is a series of events all over the country. It started in Graz, but there is also Eisenstadt, Krems and Vienna. The event in Salzburg is delayed until further notice, Linz was canceled off this year (only the LUG meeting took place) and Klagenfurt seems dead for years. Overall not very encouraging, but we wouldn’t be Fedora if we were not to change that. So we brought 7 people to Vienna which were supported by two locals, Kevin and Volker. Both did an excellent job, even though they are (officially) no ambassadors. Together we submitted 16 talks and workshops. All were accepted, this is roughly one fourth of the 3 day program. I delivered two talks, one on Kolab and one on postscreen. Both went very well and I’m very happy about the feedback I received. Overall the talks and workshops were very interesting and the speakers very competent.

Fedora booth at Linuxwochen Wien

Fedora booth at Linuxwochen Wien

Fedora delivered a good show. We had by far the biggest and most professional stand and lots of goodies. As a special gimmick Miro had brought his 3D printer and as always it attracted a lot of people. The rest of exhibition however was not impressive. That’s a well know problem for events where the focus is on talks, but this one was worse: It was moved to a new building with more space on the hallways, but the number of exhibitors hadn’t really changed. The booths looked quite lost and there were hardly visitors as most people were attending talks. On Friday we had at least some students from the university showing up and hoped for more people over the weekend, but that was wishful thinking. Maybe it was bad promotion, maybe the weather or a combination of both.

Empty hallway at Linuxwochen Wien

Empty hallway at Linuxwochen Wien

The weather in Vienna was bad compared to Berlin, but on Saturday afternoon it changed and the rest of the weekend turned out to be very sunny. As there were not many visitors and we had more than enough people at the booth, later that afternoon I decided to go for some sightseeing. People told me Vienna is beautiful, but I hadn’t seen anything of that beauty. I have been to Vienna before, but usually it was just for transfer at the airport or on my way to Brno. So I went to the historic city center and I have to admit, it really is impressive. There are a lot of buildings from the imperial times of the Austro-Hungarian monarchy and also from the Art Nouveau (or ‘Jugendstil’ as we call it) era. I love Jugendstil.

Subway station 'Karlsplatz'

The subway station ‘Karlsplatz’ in Vienna – an icon of the ‘Art Nouveau’ era.

On Friday we had a social event. It wasn’t really a social event, instead we just went to a Chinese restaurant down the street for an ‘all you can eat’ buffet. We were around 30 people and I was lucky to sit next to Bernhard. We talked about packaging and he asked me if I could help him with continuous integration of rpm build. It turned out Bernhard is a FreeRDP developer and told him I’m the poor bastard maintainer of remmina in Fedora. Remmina is a GTK-based RDP, SSH, NX and Telepathy client, developed by the FreeRDP project. It’s powerful but in bad shape as FreeRDP is still a young project and constantly moving forward. Unfortunately there haven’t been stable releases for quite a while and backporting fixes is cumbersome. So we agreed that FreeRDP will try to maintain a ‘release’ branch in git, even if there are no actual releases, and we will help them with continuous integration. If Mads, our FreeRDP maintainer, agrees we will build and host nightly versions of Fedora’s freerdp and matching remmina packages. An interesting project and I’m looking forward to it.

My flight back to Berlin left very early on Sunday morning. I had to get up at 5 am, but it allowed me to be in Berlin at half past eight and enjoy a sunny Sunday after which I was very tired – but happy.

Not sure I will attend Linuxwochen Wien next year, we have other awesome people to run the event. Personally, I learned some important lessons:

  • Talks are getting more professional and so is the target audience. When you give a talk, be professional – but don’t forget the fun!
  • Exhibitions on the other hand receive lesser attention. We need to think of new way to attract people and how to interacting with them. We need something more playful like the Fedora photo booth.
  • Renting an apartment is a good idea: Not only that it’s cheaper than a hotel, but more fun, too.
  • The people who told me Vienna is beautiful didn’t lie.

Thanks everybody for making Linuxwochen a successful event. A special thanks goes out to Sirko for being a perfect event owner. He took care of everything, not just the booth and apartment and he was a good tourist guide.

Don’t use a programming language for configuration

Posted by Christoph Wickert on March 10, 2013 01:05 PM

Dear developers,

please don’t use a programming language for configuration files. Seriously. Don’t. Just don’t. You are only making live hard for people.

Here is what my polkit custom desktop policy looked like in Fedora <= 17:


I think this is pretty straight forward, but some people found it confusing and too complex. So David rewrote it.

If you keep complaining about polkit configuration I'll rewrite it in JavascriptNow let’s see how the same looks in Fedora >=18:

polkit.addRule(function(action, subject) {
    if (subject.isInGroup("wheel") && subject.active) {
        polkit.log("action=" + action);
        polkit.log("subject=" + subject);
        if (action.id.indexOf("org.freedesktop.packagekit.package-install") == 0) {
            return polkit.Result.YES;
        if (action.id.indexOf("org.freedesktop.packagekit.package-remove") == 0) {
            return polkit.Result.YES;
        if (action.id.indexOf("org.freedesktop.packagekit.system-rollback") == 0) {
            return polkit.Result.YES;
        if (action.id.indexOf("org.freedesktop.packagekit.system-sources.") == 0) {
            return polkit.Result.YES;
        if (action.id.indexOf("org.opensuse.cupspkhelper.mechanism.") == 0) {
            return polkit.Result.YES;
        if (action.id.indexOf("org.libvirt.unix.") == 0) {
            return polkit.Result.YES;
        if (action.id.indexOf("dk.yumex.backend.pkexec.run") == 0) {
            return polkit.Result.YES;

What do we learn from this?

One doe not simply use JavaScript for config files

Enterprise Linux 6.3 to 6.4 risk report

Posted by Mark Cox on February 27, 2013 01:03 PM
You can read my Enterprise Linux 6.3 to 6.4 risk report on the Red Hat Security Blog.

"for all packages, from release of 6.3 up to and including 6.4, we shipped 108 advisories to address 311 vulnerabilities. 18 advisories were rated critical, 28 were important, and the remaining 62 were moderate and low."

"Updates to correct 77 of the 78 critical vulnerabilities were available via Red Hat Network either the same day or the next calendar day after the issues were public. The other one was in OpenJDK 1.60 where the update took 4 calendar days (over a weekend)."

And if you are interested in how the figures were calculated, here is the working out:

Note that we can't just use a date range because we've pushed some RHSA the weeks before 6.4 that were not included in the 6.4 spin. These issues will get included when we do the 6.4 to 6.5 report (as anyone installing 6.4 will have got them when they first updated).

So just after 6.4 before anything else was pushed that day:

** Product: Red Hat Enterprise Linux 6 server (all packages)
** Dates: 20101110 - 20130221 (835 days)
** 397 advisories (C=55 I=109 L=47 M=186 )
** 1151 vulnerabilities (C=198 I=185 L=279 M=489 )

** Product: Red Hat Enterprise Linux 6 Server (default installation packages)
** Dates: 20101110 - 20130221 (835 days)
** 177 advisories (C=11 I=71 L=19 M=76 )
** 579 vulnerabilities (C=35 I=133 L=159 M=252 )

And we need to exclude errata released before 2013-02-21 but not in 6.4:

RHSA-2013:0273 [critical, default]
RHSA-2013:0275 [important, not default]
RHSA-2013:0272 [critical, not default]
RHSA-2013:0271 [critical, not default]
RHSA-2013:0270 [moderate, not default]
RHSA-2013:0269 [moderate, not default]
RHSA-2013:0250 [moderate, default]
RHSA-2013:0247 [important, not default]
RHSA-2013:0245 [critical, default]
RHSA-2013:0219 [moderate, default]
RHSA-2013:0216 [important, default]

Default vulns from above: critical:12 important:2 moderate:16 low:3
Non-Default vulns from above: critical:4 important:2 moderate:5 low:0

This gives us "Fixed between GA and 6.4 iso":

** Product: Red Hat Enterprise Linux 6 server (all packages)
** Dates: 20101110 - 20130221 (835 days)
** 386 advisories (C=51 I=106 L=47 M=182 )
** 1107 vulnerabilities (C=182 I=181 L=276 M=468 )

** Product: Red Hat Enterprise Linux 6 Server (default installation packages)
** Dates: 20101110 - 20130221 (835 days)
** 172 advisories (C=9 I=70 L=19 M=74 )
** 546 vulnerabilities (C=23 I=131 L=156 M=236 )

And taken from the last report "Fixed between GA and 6.3 iso":

** Product: Red Hat Enterprise Linux 6 server (all packages)
** Dates: 20101110 - 20120620 (589 days)
** 278 advisories (C=33 I=78 L=31 M=136 )
** 796 vulnerabilities (C=104 I=140 L=196 M=356 )

** Product: Red Hat Enterprise Linux 6 Server (default installation packages)
** Dates: 20101110 - 20120620 (589 days)
** 134 advisories (C=6 I=56 L=15 M=57 )
** 438 vulnerabilities (C=16 I=110 L=126 M=186 )

Therefore between 6.3 iso and 6.4 iso:

** Product: Red Hat Enterprise Linux 6 server (all packages)
** Dates: 20120621 - 20130221 (246 days)
** 108 advisories (C=18 I=28 L=16 M=46 )
** 311 vulnerabilities (C=78 I=41 L=80 M=112 )

** Product: Red Hat Enterprise Linux 6 Server (default installation packages)
** Dates: 20120621 - 20130221 (246 days)
** 38 advisories (C=3 I=14 L=4 M=17 )
** 108 vulnerabilities (C=7 I=21 L=30 M=50 )

Note: although we have 3 default criticals, they are in openjdk-1.6.0, but we only call Java issues critical if they can be exploited via a browser, and in RHEL6 the Java browser plugin is in the icedtea-web package, which isn't a default package. So that means on a default install you don't get Java plugins running in your browser, so really these are not default criticals in RHEL6 default at all.

FAD EMEA wrap up

Posted by Christoph Wickert on December 09, 2012 12:06 PM

It turns out we have to leave early. Some people need to travel home and others have family duties – or both. Fortunately we worked hard and managed to complete our agenda.

For now, I just put all the results, todo items and open questions into the wiki. It’s still a rough draft, I will clean it up, format and elaborate it later today. Some of the most important decisions include:

  • We’ll make a Fedora Ambassadors Census. In previous years, we used to do this before this FAD: We ask all the local communities to report their state: How many (active) ambassadors are there, how many events did they attend and what is the overall situation for them.
  • We looked for new ways to bring people into the project. We have communities that are not officially part of the project, like local community websites, IRC channels or groups on social networks. We should actively try to recruit new contributors there.
  • Improve the new contributors experience: Once they joined Fedora, we should make sure new ambassadors can attend at least one major event to get to know other contributors. Mentors should have an eye on how people do within the first year and support them better.
  • Run country-wide ambassadors event: All countries should strive for an event that brings all ambassadors to a table at least once a year.

Still, the real work begins after this FAD. We need to implement what we discussed, whether this is in the wiki, in trac or on various events. But we have gotten a new boost for our community and we are very optimistic that it will have a big impact.

Thanks everybody for coming and especially to Gerold for making this event happen.


Posted by Christoph Wickert on December 08, 2012 11:55 PM

So we are sitting at Beuggen Castle and having some drinks after an awesome social event: A dinner in complete darkness at a restaurant called “Blinde Kuh” (“Blind cow”). If you have not yet had it, give it a try, it’s very interesting experience.

The first day of FAD EMEA turned out to be very productive. We managed to discuss a lot of topics, most importantly:

  • Event planning for 2013. We want to attend 31 events, and for most of them we already have event owners.
  • Budget planning for 2013. Based on the list of events, we’ll spend 11.700 EUR. Sure, this is a lot of money, but we want really to rock at a lot of places and our draft is very conservative.
  • Sponsoring and reimbursements: While FAmSCo has already achieved a lot, we need to do a better job in explaining contributors how to get money easily and how to effectively track all requests.
  • Swag shipping and event box: We think it does not make sense to ship a complete event box within Europe, instead continue shipping what we really need. But this needs improvements: Better tracking of who has what and more ‘bases’ in different countries.
  • Swag production planning: We have a lot of new ideas for awesome swag and need to follow up with getting different quotes and making desisions.

I am going to add all relevant info to the wiki later, because a lot of the topic we discussed needs to be followed up. Tomorrow we’ll have some more discussions, but given that we are already more than half way through the agenda, we should have some time left to document and implement our results. This mainly is wiki gardening an improvements in our trac instance.

Stay tuned for another blog post before I fly home tomorrow.

Fedora elections – don’t forget to vote!

Posted by Christoph Wickert on December 07, 2012 06:53 PM

Fedora Elections are ongoing. Deadline is December 9th at 23:59:59 UTC - vote now!

Fedora Logo



Security FAD

Posted by Toshio Kuratomi on November 26, 2012 07:19 PM

All packed up and waiting for my plane to Raleigh. Going there to work on enabling two-factor authentication for the hosts that give shell access inside of Fedora’s Infrastructure. For the first round, I think we’re planning on going for simple and minimal to show what we can do. Briefly, the simplest and minimalist is:

* Server to verify a one time password (we already have one for yubikeys)
* CGI to take a username, password, and otp to verify in fas and the otp server
* pam module for sudo that verifies the user via the cgi
* database to store the secret keys for the otp generation and associate them with the fas username

We’re hoping to go a little beyond the minimal at the FAD:

* Have a web frontend to configure the secret keys that are stored for an account.
* Presently we’re thinking that this is a FAS frontend but we may end up re-evaluating this depending on what we decide to do for web apps and what to require for changing an auth source.
* Allow both yubikey and google-authenticator as otp

I’m also hoping that since we’ll have most of the sysadmin side of infrastructure present that we’ll get a chance to discuss and write down a few OTP policies for the future:

* Do we want to make two-factor optional for some people and required for others?
* How many auth sources do we require in order to change a separate auth source (email address, password, secret for otp generation, phone number, gpg key, etc)?

If we manage to get through all of that work, there’s a few other things we could work on as well:

* Design and implement OTP for our web apps

When is an SRPM not Architecture-neutral?

Posted by Chris Tyler on November 24, 2012 03:13 AM

Source RPM packages -- SRPMs -- have an architecture of "src". In other words, a source RPM is a source RPM, with no architecture associated with it. There's an assumption that the package is architecture-neutral in source form, and only become architecture-specific when built into a binary RPM (unless it builds into a "noarch" RPM, which is the case with scripts, fonts, graphics, and data files).

An SRPM contains source code (typically a tarball, and sometimes patch files) and a spec file which serves as manifest and build-recipe, plus metadata generated from the spec file when the SRPM is built -- including dependencies (which, unlike binary RPMs, are actually the build dependencies).

However, the build dependencies may vary by platform. If package foo is built against bar and baz, and baz exists on some architectures but not others, then the spec file may be written to build without baz (and the accompanying features that baz enables) on some architectures. The corresponding BuildRequires lines will also be made conditional on the architecture -- and this make total sense. However, querying an SRPM on a given platform may give incorrect build dependency information for that platform if the SRPM was built on another platform -- and only rebuilding the SRPM on the target arch will correct the rpm metadata (and possibly render it incorrect for other platforms). Thus, I've come to realize, SRPMs are not truly architecture-neutral -- and I'm not sure if all our tools take this into consideration.

Edit: I know that not all of our tools take this into consideration.

Continue reading "When is an SRPM not Architecture-neutral?"

Last call for F19 naming proposals

Posted by Christoph Wickert on October 16, 2012 07:07 PM

This is the final reminder that the Fedora 19 naming collection ends today at 23:59 UTC. This means you have 5 hours left to propose a name. Before proposing a name, please make sure to read the guidelines.

OpenShift, perl, YouTube API

Posted by Mark Cox on October 09, 2012 08:25 PM
tracy My wife is part of a competition to be the next face representing her college; with the final number of positive 'likes' on YouTube videos determining the winners. I thought it would be neat to create a scoreboard to track her progress, but also to learn how to use OpenShift all in one. It took me longer to write this blog than to write the code and deploy it live!

After creating an account on Red Hat OpenShift I created a new app based on perl and added a cron container so we can run our script every few minutes (to stop overloading the YouTube API if the site gets popular):

rhc-create-app -a fomc -t perl-5.10
rhc-ctl-app -a fomc -e add-cron-1.4
cd fomc
That was all the configuration needed, the 'fomc' directory is populated with everything you need. OpenShift when you deploy your app, figures out your perl dependencies and grabs and builds them for you, so no messing around needing root or even logging into the host.

By default the file perl/index.pl will get served, but since we're going to cache the output from the script let's make it a html file index. To do this simply add to the existing perl/.htaccess file:

DirectoryIndex index.html
I wrote this quick perl program to query the YouTube API and do a simplistic HTML page of the number of likes for each of the videos in the playlist, and placed it in the main directory as youtube.pl. Now to get it created every ten minutes we use the cron container by creating a file .openshift/cron/minutely/perljob with the contents:
MIN=`date +%M`
if [ $((${MIN#0} % 10)) == 0 ]; then
    perl ${OPENSHIFT_REPO_DIR}/youtube.pl > ${OPENSHIFT_REPO_DIR}/index.html
    mv -f ${OPENSHIFT_REPO_DIR}/index.html ${OPENSHIFT_REPO_DIR}/perl/index.html
The cron job is run every minute, but the "modulus 10" ensures we only run the perl script once every 10 minutes. We use an intermediate file so that anyone visiting the site during the time it takes to create the file doesn't get a blank page. Finally we want to make sure that we don't have to wait ten minutes for the file to be created when we push the app, and give people the ability to see the source, so we create .openshift/action_hooks/post_deploy with the contents:
cp ${OPENSHIFT_REPO_DIR}/youtube.pl ${OPENSHIFT_REPO_DIR}/perl/youtubepl.txt
perl ${OPENSHIFT_REPO_DIR}/youtube.pl > ${OPENSHIFT_REPO_DIR}/perl/index.html
And that's it. Just run
git add .
git commit -a -m 'first app'
git push
And the app is up and running; here it is: http://fomc-esoom.rhcloud.com/. If this blog was useful (blatent plug!) please click on "Tracy Cox", make sure you're logged in, and click "like" ;)

Enterprise Linux 6.2 to 6.3 risk report

Posted by Mark Cox on October 03, 2012 03:16 PM
You can read my Enterprise Linux 6.2 to 6.3 risk report on the Red Hat Security Blog.
"for all packages, from release of 6.2 up to and including 6.3, we shipped 88 advisories to address 233 vulnerabilities. 15 advisories were rated critical, 23 were important, and the remaining 50 were moderate and low."

"Updates to correct 34 of the 36 critical vulnerabilities were available via Red Hat Network either the same day or the next calendar day after the issues were public. The Kerberos telnet flaw was fixed in 2 calendar days as the issue was published on Christmas day. The second PHP flaw took 4 calendar days (over a weekend) as the initial fix released upstream was incomplete."

And if you are interested in how the figures were calculated, as always view the source of this blog entry.

Fedora or Android?

Posted by Mark Cox on September 28, 2012 02:48 PM
20120928_prime For a two day trip I decided to test using my Android tablet instead of also taking a laptop, and it worked out okay for the most part.

I was booked to go to Red Hat HQ in Raleigh, NC at the start of August for a two-day business trip, well more accurately two-days in the office and another two-days of travelling. I'd usually take my trusty ThinkPad x201 on the trip with me, it's small and light, but it's battery life isn't so great anymore. Earlier this year I'd bought an Android tablet, an ASUS Transformer Prime which with a long battery life would be perfect for movies, but could it replace my ThinkPad completely and save me travelling with two devices? I worked through my requirements and it seemed plausible in theory, so here is how it stacked up in practice:

  • Connectivity. In the UK you can only buy the Prime with the keyboard dock, the keyboard dock is great. The in-built wifi was okay for the airport, hotel, and office. I carry a USB network adapter anyway just in case the hotel has a physical connection. The wifi signal on the Prime is terrible compared to other things (like a phone) though, so be prepared to walk around a bit to the best signal. Partial Win.

  • In flight entertainment. I wanted something to watch movies (as US Airways transatlantic don't yet have seat-back video, really!). The large internal memory meant I could store a few films in decent quality to watch and battery life wasn't a problem. I'd used the tablet continously (without wifi) with the keyboard connected for 6 hours and wasn't even down to 50% battery. Although hardware decoding of videos was a bit hit-and-miss, and after trying a dozen apps only "BS Player" seemed to do a reasonable job. A couple of the movies I'd brought had low audio and I couldn't figure out a way to boost it enough to hear over the noise of the plane, even with decent in-ear noise blocking headphones. Having the keyboard dock helped considerably as with the tablet on the tray-table I could set a decent angle to watch a movie. Win.

  • Reading material. I had a few papers and magazines to read which I'd preloaded onto the tablet in PDF format. The Adobe PDF viewer is acceptable, but it seems a little sluggish for something running on a quad-core processor, and the screen resolution isn't really good enough for magazines. The new Transformer Infinity would help here. Partial Win.

  • Keeping in touch with home. The standard Android GMail app and Facebook app are okay, and I was able to use GMail talk to have video chats with my family from both the hotel and office. Win.

  • Working. With just a couple days away I figured all that was needed was the ability to read and send email and browse intranet internal web pages. The standard VPN client on the Prime worked perfectly, and along with the Firefox beta app gave me perfect access to internal sites. For email I prefer command-line text-window clients anyway, so I just needed to be able to connect to a work machine. "Connectbot" on Android works well enough for ssh, and there are a few forked versions you can get that work with the Prime keyboard. The AndChat app works for irc. Win.

  • Presentations. I was giving a presentation at a meeting, but fortunately they had a laptop set up with the projector and I didn't need to worry about taking a HDMI lead and hoping it was a recent projector. Unexpectedly I needed to edit an existing OpenOffice presentation to remove a couple of slides and then convert to PDF to send to another company. I had to ask a colleague to do it for me. There are apps that can view OpenOffice files, but no native OpenOffice suite for android. I'd probably make sure I had access to a VNC server in the future and use a VNC client for anything like this. Fail.

  • Privacy. My thinkpad has full-disk encryption but I didn't bother for Android as I wasn't going to be storing anything sensitive on the machine. My thinkpad has a 3M privacy filter, which is great for airplanes and airports to stop people either side and behind you looking at your screen. The same filters do exist for Android, but are not as straightforward (it of couse only works in one orientation and attaches like a screen protector, so isn't the easiest thing to continuously take on and off, and forces you to use your screen in portrait mode for everything). Fail.

  • Printing a boarding card. When it was time to return home I was able to use Firefox to check in online, and printing my boarding passes gave me a PDF file. I didn't have any printer apps set up, but it was easy enough to email a PDF to a colleague to print for me. Partial Win.

So in summary I think I got away with it; having just the tablet didn't stop me doing anything that had to be done on the trip and I'll definately do the same thing again in the future for very short trips. For anything more than a couple of days or where connectivity might be an issue I'd miss having a full-featured OS.

Red Hat Security Blog

Posted by Mark Cox on September 20, 2012 12:54 PM
We now have an official Red Hat Security Blog, and you'll find all my future reports and discussions about security metrics there. In the meantime here are a few already published articles:

Rilasciata Fedora 18 "Sperical Cow" Alpha

Posted by Fedora Italia on September 19, 2012 07:56 AM

L'alpha release di Fedora 18 “Spherical Cow” è pronta per essere testata! Questo rilascio offre un'anteprima di alcune delle migliori tecnologie open source attualmente sotto sviluppo. Ci sono molte nuove features veramente interessanti, dedicate a un audience molto vasto, in questa nuova release.

Di seguito un piccolo assaggio di quello che ci aspetta nel futuro di Fedora 18.

Per il Desktop

  • NetworkManager Hotspots migliora la capacità di usare la nostra scheda wi-fi e trasformate il nostro computer in un hot spot.
  • Il sistema di installazione riprogettato aggiunge flessibilità al processo di installazione, semplificando l'interfaccia utente.
  • Desktop updates in abbondanza: Gnome 3.6, KDE Plasma Workspace 4.9, Xfce
  • 4.10, Sugar 0.98, e l'introduzione di MATE Desktop in Fedora.

Per i Sysadmin

  • Il database NoSQL Riak, un sistema di database fault-tolerant e scalabile, è incluso per la prima volta in Fedora 18.
  • Samba 4 aggiunge il supporto a SMB3 e ai FreeIPA trusted domains.
  • Aggiunge il supporto per l'installazione dei pacchetti del sistema operativo in avvio agli Aggiornamenti del sistema non in linea . In questo modo gli amministratori di sistema avranno la possibilità di effettuare gli upgrade in modo controllato.

Per gli sviluppatori

  • Lo stack di Python 3 è aggiornato alla versione 3.3
  • Rails è aggiornato dalla versione 3.0 alla 3.2
  • Perl 5.16 aggiunge il supporto ad Unicode 6.1

Problemi noti e Bug

Per chi fosse interessato a testare la nuova Fedora 18 ci sono già una serie di problemi e bug noti. Qui di seguito ne riportiamo alcuni, ma potete trovare la lista completa a questo indirizzo: http://fedoraproject.org/wiki/Common_F18_bugs

  • Utilizzando il partizionamento automatico durante l'installazione verranno formattati tutti i dischi selezionati per l'installazione , senza alcun ulteriore preavviso; TUTTI I DATI ESISTENTI SUI DISCHI ANDRANNO PERSI. In questo momento, non c'è l'opzione per poter utilizzare lo spazio libero sui dischi, o per ridimensionare esistente partizioni. Esiste comunque un workaround per risolvere questo problema.
  • Alcune schede grafiche NVIDIA hanno problemi con l'avvio o la visualizzazione del login manager o il desktop. Questo impedisce di avere un desktop usabile, quando si avvia la live o un sistema installato. In questi casi, il login manager o il desktop può non apparire del tutto, o potrebbe essere, ma con il cursore mancante o con problemi di visualizzazione.

Questo rilascio, come detto prima, presenta una nuova interfaccia utente per anaconda, che rafforzerà in modo significativo l'esperienza dell'utente finale di installazione.Problemi noti relativi alla nuova interfaccia utente di installazione includono:

  • Per le installazione non-grafiche, la pssword di root deve essere settata per abilitare il login; per le installazioni grafiche, il primo utente deve essere settato come amministratore. Questo è attualmente il setup di default durante l'installazione.
  • Non ci sono aggiornamenti anaconda-based o preupgrade a Fedora 18 Alpha, se è necessario aggiornare un sistema installato, si deve usare yum.

Per ulteriori informazioni, comprese le informazioni sui bug più comuni, suggerimenti su come segnalare i bug, e il calendario di rilascio ufficiale, è possibile consultare le note di rilascio nella pagina del wiki di Fedora 18

Per il download delle ISO l'indirizzo è questo: http://fedoraproject.org/get-prerelease

Fonte: Announcing the release of Fedora 18 Alpha!!

Fedora Test Day: 2012-09-18 OpenStack

Posted by Fedora Italia on September 18, 2012 10:02 AM

Oggi si terrà il test day focalizzato su OpenStack IaaS (openstack.org) per Fedora 18.

OpenStack è uno dei progetti cloud di maggior successo e lo si può trovare anche in Fedora.

Potete trovare tutte le informazioni riguardanti questo test day, pre-requisiti per il test ed istruzioni su come effettuare i test nella pagina dedicata del wiki: Test Day:2012-09-18 OpenStack

Tutti sono invitati a contribuire ai test! Potete confermare la vostra presenza nell'evento creato dall'account uffiale di Fedora su Google+: Fedora 18 Test Day - OpenStack

Fedora video contest

Posted by Fedora Italia on September 13, 2012 07:15 AM

Da qualche giorno è partito un video contest che servirà a trovare un template per l'intro/outro dei video del Fedora Videos Project. Il contest è iniziato il 5 settembre 2012 e terminerà il 5 ottobre 2012.

Per inviare il vostro video, è necessario caricarlo in una posizione accessibile al pubblico e inviare una e-mail a videos@fedoraproject.org con oggetto: "Fedora Videos Contest".

Il video dovrebbe essere idealmente tra i cinque e trenta secondi. Ovviamente, il contenuto deve essere appropriato per uso pubblico.

Dal momento che la 'libertà' è uno dei fondamenti del Fedora Project, è consigliato l'utilizzo di strumenti open source per la realizzazione dei video. Tuttavia, non è obbligatorio.

L'email deve contenere:

  • Il link al video
  • La licenza con la quale è stato rilasciato il video, potete trovare maggiori informazioni qui.
  • Il vostro FAS (Fedora Account System ID), è obbligatoria, per registrarsi basta un minuto Smile
  • Se avete una pagina utente sul wiki, inserite anche questo collegamento.

Le specifiche tecniche del video sono queste:

  1. Qualità video (minimo suggerito): SD
  2. Dimensioni Intro (minimo suggerito): 1600x1200
  3. Dimensioni Outro (minimo suggerito): 1600x1200
  4. Frame rate (minimo suggerito): 24fps
  5. Formato video: ogg
  6. Formato audio: ogv
  7. Durata del video: tra i 10 e i 30 secondi

Potete trovare le regole, i criteri di giudizio e tutte le altre informazioni dettagliate del contest a questo indirizzo: https://fedoraproject.org/wiki/Videos/FedoraVideos_Contest_Intro/Outro

Il premio in palio è un t-shirt Fedora.

Rilasciata Fedora 17 per ARM

Posted by Fedora Italia on June 20, 2012 10:53 AM

Dopo poco più di sei mesi di sviluppo su una architettura tutta nuova viene rilasciata oggi Fedora 17 - Beefy Miracle per ARM. Lo sviluppo è stato accelerato dopo la scelta del Team ARM di Fedora di saltare il rilascio della versione 16 per concentrarsi sulla neo nata F17. La Fedora 17 viene rilasciata per la maggior parte delle piattaforme di sviluppo ARM conosciute e vicine all'opensource, molte delle quali hanno richiesto enormi sacrifici per poter supportate dal kernel scelto ovverio il nuovissimo 3.4.
Di seguito il messaggio del Team della pubblicazione delle immagini General Available:

Il team ARM Fedora è lieto di annunciare il rilascio di Fedora 17 GA per ARM, disponibile per il download:


Questa release include immagini GA precompilate per Versatile Express (QEMU), Trimslice, Beagleboard XM, Pandaboard, Plugs Kirkwood, Highbank e piattaforme hardware basate su IMX.

Si prega di visitare la pagina dell' annuncio per ulteriori informazioni e link per specifiche immagini:


Vi invitiamo a scaricare la release di Fedora 17 GA e fornire il proprio prezioso apporto al team ARM Fedora. Unitevi a noi in IRC in # fedora-braccio o su Freenode
inviate feedback e commenti alla mailing list ARM.

A nome del team ARM Fedora,

Fedora Board run-off election

Posted by Jared Smith on June 18, 2012 07:04 PM

If you’ve followed my blog for long, you probably know that I tend to blog a lot about my favorite distribution (and community), Fedora.  And, as you probably well know, in Fedora we have elections for many things such as seats on the leadership committees and release names. In the most recent round of Fedora elections, we had a tie vote in the elections for a seat on the Fedora Board, so we’re now in the middle of a run-off election.  If you have a Fedora account and haven’t yet voted, please do your civic duty and vote in the run-off election.  The voting ends Tuesday at the end of the day UTC time, so you have roughly twenty-four hours to get your votes in.  As always, I encourage you to vote for the candidate that you think will best represent Fedora and its values.

More details on the run-off election can be found at https://lists.fedoraproject.org/pipermail/announce/2012-June/003085.html.  To vote, login to the Fedora Accounts System and place your votes at https://admin.fedoraproject.org/voting.

Let me also add a quick thank you to everyone who has already voted or who has stood up and run for public office.  Leadership in Fedora takes time and effort, and I’m always grateful to those who are willing to put their time and energy and passion into doing a fantastic job.

Fedora Board Runoff Election

Posted by Christoph Wickert on June 12, 2012 06:52 PM

As you might know we had a tie of two candidates (Nick and Robert) in the Fedora Board election. The runoff election between the two of them has now started, please vote now! Voting is open for one week, that is until 2012-06-20 00:00:00 UTC.