Using OpenLMI to join a machine to a FreeIPA domain

People who have been following this (admittedly intermittent) blog for a while are probably aware that in the past I was heavily-involved in the SSSD and FreeIPA projects.

Recently, I’ve been thinking a lot about two topics involving FreeIPA. The first is how to deploy a FreeIPA server using OpenLMI. This is the subject of my efforts in the Fedora Server Role project and will be covered in greater detail in another blog post, hopefully next week.

Today’s topic involves enrollment of FreeIPA clients into the domain from a central location, possibly the FreeIPA server itself. Traditionally, enrolling a system has been a “pull” operation, where an admin signs into the system and then requests that it be added to the domain. However, there are many environments where this is difficult, particularly in the case of large-scale datacenter or cloud deployments. In these cases, it would be much better if one could script the enrollment process.

Additionally, it would be excellent if the FreeIPA Web UI (or CLI) could display a list of systems on the network that are not currently joined to a domain and trigger them to join.

There are multiple problems to solve here. The first of course is whether OpenLMI can control the joining. As it turns out, OpenLMI can! OpenLMI 1.0 includes the “realmd” provider, which acts as a remote interface to the ‘realmd’ service on Fedora 20 (or later) and Red Hat Enterprise Linux 7.0 (or later).

Now, there are some pre-requisites that have to be met before using realmd to join a domain. The first is that the system must have DNS configured properly such that realmd will be able to query it for the domain controller properties. For both FreeIPA and Active Directory, this means that the system must be able to query for the _ldap SRV entry that matches the domain the client wishes to join.

In most deployment environments, it’s reasonable to expect that the DNS servers provided by the DHCP lease (or static assignment) will be correctly configured with this information. However, in a development or testing environment (with a non-production FreeIPA server), it may be necessary to first reconfigure the client’s DNS setup.

Since we’re already using OpenLMI, let’s see if we can modify the DNS configuration that way, using the networking provider. As it turns out, we can! Additionally, we can use the lmi metacommand to make this very easy. All we need to do is run the following command:

lmi -h <client> net dns replace x.x.x.x

With that done, we need to do one more thing before we join the domain. Right now, the realmd provider doesn’t support automatically installing the FreeIPA client packages when joining a domain (that’s on the roadmap). So for the moment, you’re going to want to run

lmi -h <client> sw install freeipa-client

(Replacing ‘freeipa-client’ with ‘ipa-client’ if you’re talking to a RHEL 7 machine).

With that done, now it’s time to use realmd to join the machine to the FreeIPA domain. Unfortunately, in OpenLMI 1.0 we do not yet have an lmi metacommand for this. Instead, we will use the lmishell python scripting environment to perform the join (don’t worry, it’s short and easy to follow!)

c = connect('server', 'username', 'password')
realm_obj = c.root.cimv2.LMI_RealmdService.first_instance()
realm_obj.JoinDomain(Domain='domainname.test', User='admin', Password='password')

In these three lines, we are connecting to the client machine using OpenLMI, getting access to the realm object (there’s only one on a system, so that’s why we use first_instance()) and then calling the JoinDomain() method, passing it the credentials of a FreeIPA administrator with privileges to add a machine, or else passing None for the User and a pre-created one-time password for domain join as the Password.

And there you have it, barring an error we have successfully joined a client to a domain!

Final thoughts: I mentioned above that it would be nice to be able to discover unenrolled systems on the network and display them. For this, we need to look into extending the set of attributes we have available in our SLP implementation so that we can query on this. It shouldn’t be too much work, but it’s not ready today.

The Forgotten “F”: A Tale of Fedora’s Foundations

Lately, I’ve been thinking a lot about Fedora’s Foundations: “Freedom, Friends, Features, First”, particularly in relation to some very sticky questions about where certain things fit (such as third-party repositories, free and non-free web services, etc.)

Many of these discussions get hung up on wildly different interpretations of what the “Freedom” Foundation means. First, I’ll reproduce the exact text of the “Freedom” Foundation:

“Freedom represents dedication to free software and content. We believe that advancing software and content freedom is a central goal for the Fedora Project, and that we should accomplish that goal through the use of the software and content we promote. By including free alternatives to proprietary code and content, we can improve the overall state of free and open source software and content, and limit the effects of proprietary or patent encumbered code on the Project. Sometimes this goal prevents us from taking the easy way out by including proprietary or patent encumbered software in Fedora, or using those kinds of products in our other project work. But by concentrating on the free software and content we provide and promote, the end result is that we are able to provide: releases that are predictable and 100% legally redistributable for everyone; innovation in free and open source software that can equal or exceed closed source or proprietary solutions; and, a completely free project that anyone can emulate or copy in whole or in part for their own purposes.”

The language in this Foundation is sometimes dangerously unclear. For example, it pretty much explicitly forbids the use of non-free components in the creation of Fedora (sorry, folks: you can’t use Photoshop to create your package icon!). At the same time, we regularly allow the packaging of software that can interoperate with non-free software; we allow Pidgin and other IM clients to talk to Google and AOL, we allow email clients to connect to Microsoft Exchange, etc. The real problem is that every time a question comes up against the Freedom Foundation, Fedora contributors diverge into two armed camps: the hard-liners who believe that Fedora should never under any circumstances work (interoperate) with proprietary services and the the folks who believe that such a hard-line approach is a path to irrelevance.

To make things clear: I’m personally closer to the second camp than the first. In fact, in keeping with the subject of this post, I’d like to suggest a fifth Foundation, one to ultimately supersede all the rest: “Functional”. Here’s a straw-man phrasing of this proposal:

Functional means that the Fedora community recognizes this to be the ultimate truth: the purpose of an operating system is to enable its users to accomplish the set of tasks they need to perform.

With this in place, it would admittedly water down the Freedom Foundation slightly. “Freedom” would essentially be reduced to: the tools to reproduce the Fedora Build Environment and all packages (source and binary) shipped from this build system must use a compatible open-source license and not be patent-encumbered. Fedora would strive to always provide and promote open-source alternatives to existing (or emerging) proprietary technologies, but accepts that attracting users means not telling them that they must change all of their tools to do so).

The “Functional” Foundation should be placed above the other four and be the goal-post that we measure decisions against: “If we make this change, are we reducing our users’ ability to work with the software they want/need to?”. Any time the answer to that question would be “yes”, we have to recognize that this translates into lost users (or at the very least, users that are working around our intentions).

Now, let me be further clear on this: I am not in any way advocating the use of closed-source software or services. I am not suggesting that we start carrying patent-encumbered software. I think it is absolutely the mission of Fedora to show people that FOSS is the better long-term solution. However, in my experience a person who is exposed to open source and allowed to migrate in their own time is one who is more likely to become a lifelong supporter. A person who is told “if you switch to Fedora, you must stop using Application X” is a person who is not running Fedora.

Fedora.NEXT at FOSDEM and DevConf

I just want to throw out a quick update on the progress of Fedora.NEXT work.

First of all, the deadline for the submission of the Workstation, Server and Cloud PRDs was extended one week, so they will now need to be delivered by Monday, January 20th. Assuming that the PRDs are ratified by the Fedora Board and FESCo, that means that the next phase will be execution planning.

Execution planning means that we will need to put together a list of resource needs of all varieties (for packaging QA, doc-writers, release-engineering, Ambassadors, etc.). This will also include scoping efforts to determine the delivery schedule.

This is a big task and one that will need help from throughout our community. I’ve reserved time at two of the larger upcoming European FOSS conferences to get people together and brainstorming these needs.

The first such conference is FOSDEM, the Free, Open-Source Developers European Meeting in Brussels, Belgium. I have reserved an hour meeting in the “distributions” devroom on Saturday, February 1 at 1600 local time for this purpose. If you are attending FOSDEM and have any interest in seeing Fedora succeed, I urge you to join us there and help turn these goals into actionable efforts.

The second conference is, running a week after FOSDEM in Brno, the Czech Republic. Devconf is a very Fedora-friendly conference and will be dedicating an entire day to the Fedora Project: Sunday, February 9th. Matthew Miller, Fedora’s Cloud Architect, will be kicking off the Fedora Day with his keynote entitled “ Future of Fedora Big Picture, plus Working Group report“.

Following Matthew’s keynote, I will be leading a workshop/brainstorming session in the same room entitled “We are Fedora (and so can you!)“. The goal of this session will be similar to that of the FOSDEM devroom session: to get as many people with an interest in Fedora into the same room to help us plan how to meet the visions set forth in the Fedora product PRDs.

If you are going to either of these conferences, I very much hope you will join us!

Proposal: FreeIPA Role for Fedora Servers Using Cockpit

At last week’s Fedora Server Working Group meeting, we encountered some confusion as to what exactly a role should look like. We seemed to be of differing opinions, technologically, on how to implement the roles. I recommended that we take a step back and try to design the user experience that a role should accomplish first. I recommended that we probably wanted to take one example and provide a user story for it and use that as a straw-man to work out the more general cases of server roles.

Continue reading

IETF, MTI codecs and Fedora


Cisco announced that they will be releasing an implementation of H.264 under a BSD license along with distributing binaries to encode and decode this video format. Their purpose for doing so is to push it as a WebRTC standard with the IETF. The problem faced by Fedora is that the patent licensed granted by Cisco covers only the binaries that they themselves build and distribute. If the IETF approves the use of H.264 in addition to (or instead of) the VP8 codec as part of mandatory compliance in the WebRTC standard, Fedora would have to ship (or provide access to) a pre-compiled binary codec over which we have no control. We cannot ship a version that we ourselves build because it would not be covered under the patent license grant.

Fedora’s Response

The issue was escalated to FESCo, the Fedora Engineering Steering Committee, today with the question of how we should respond. We elected to make the following statement[1]:

Fedora is a distribution that cares about software freedom and our users
freedom. Firstly, we cannot ship binary-only prebuilt software within Fedora.
This rules out inclusion of OpenH264 binaries direct from Cisco, or other
providers. Secondly, we cannot ship software built from source which is not free
for any use, freely distributable, and free from patent restrictions.
Therefore, Fedora is similarly unable to ship rebuilt OpenH264 code.

Fedora would be much happier with a non-patent encumbered codec in the standard
as it would relieve us of the burden of caring for a codec implementation that
we cannot fix if it is buggy on our platform, let us ship improved or more
efficient versions of the codec if that is asked for, and relieve us of the
burden of making sure all implementors of the standard were using a proper
technique to retrieve the patent-encumbered portion from the internet so that
we weren't shipping non-free code.

Acceptance of an insufficiently-free license of the OpenH264 codec would mean
that open-source vendors are not able to implement it on their own terms. They
must rely on the implementation provided by a third party (Cisco) and create
workarounds to have the user download that implementation after installation,
increasing the burden on open-source users. This creates an unequal environment
for open-source vendors.

As members of the Open Source community, we feel that it is necessary to take a principled stand here. Allowing the WebRTC standard to mandate a patent-encumbered codec ensures an uneven playing field for open source distributions. I would like to encourage anyone reading this to write to the IETF at and express concern at how much damage it would do to force an insufficiently open codec to be required for compliance with the future of the World Wide Web. Please make it clear to the IETF that to select H.264 as a mandatory codec would be to reduce the availability of competitive and alternative implementations.


Why not change the world?

I have always been interested in science, technology and (most of all) computers. These are things that I always loved, even though they were sometimes difficult. I loved math and science class in school; I read science-fiction and fantasy novels in all of my spare time. I was the nerdy kid at school that was bullied and mocked. It would have been so easy to just give in and be “like everyone else”. I could have stopped reading. I could have played more sports.

But I didn’t. I knew what it was that I loved. I knew that what I wanted was more important than what they wanted. Most of all, I wanted to change the world.

No one in history has ever changed the world by being what others wanted them to be. They have changed the world by daring to laugh at conventional wisdom and try something new. They have changed the world by standing up and defying that “might makes right” or that “going along to get along” is the right course of action.

This is the sentiment that drove me into my open source career. I chose this path in my life because I see it as a way to effect real change in the world. This is a change really has happened in my lifetime and continues to do so. It flies in the face of the history of business.

At its heart, the open source movement is an extension of science. Sir Isaac Newton wrote “If I have seen further it is by standing on the shoulders of giants.”. One of the greatest minds in history acknowledged that his contributions to our greater understanding came not from his sole vision but from the fact that thousands of great and lesser minds had worked together to create a world into which his particular spark could ignite change.

The philosophy of open source is the same. It is a mechanism for enabling thousands of people to work together for a common goal. Classic software development has always occurred in closed environments that jealously protect their secrets. Essentially, it has operated on the same philosophies as invention and manufacturing has over the years. It is a difficult habit to break, especially when it seems like you’re giving something up.

That is the core piece that most people have trouble grasping, in my experience. While you are giving up exclusive control, you are gaining something much more valuable: you’re expanding the base level. You are feeding those giants so that you and others can see further and strive higher still. Where once you were an inventor standing on one giant’s shoulders, now you look down and can see the truth for what it is: that giant is standing on other, bigger giants. And on it goes, all the way (“It’s giants all the way down”, to borrow from a popular joke).

Once that realization is made, things become more clear. When you stand taller and can see further, you realize that your efforts can have greater impact than you once believed. Instead of the miserly hoarding of knowledge, you can share it with the world and see what they will do with it too. It won’t always be pretty and it won’t always match your original intentions, but it will always be greater than the sum of its parts. And in a small way, you will have changed the world.

One thing that gets forgotten a lot of the time when folks talk about changing the world is that they talk about massive shifts in direction. They talk about those moments in history where you can look back and say, “There! That’s the moment when everything changed!”. There will always be a few such moments every few centuries, but the truth is that most change happens glacially.

Open source is one of those glacial changes. I don’t use that term to suggest that it moves too slowly. Rather, I chose it to evoke the immensity, inevitability, and incredible moving inertia that drives it. A glacier may take decades, centuries or millenia to move across the land, but nothing can truly stand against that oncoming tide. This is the legacy of open source: the tide of progress.

Over the last twenty-two years of Linux, we’ve seen a great many strides made in the march of progress. When people ask what I work on and I say “Linux” or “open source”, they often give me a blank look. I usually follow up with the following sentence: “Do you have a device with an on-switch that doesn’t start with the letter I? Chances are, it’s running Linux or at least some open source code”. Every time I say this, I boggle at the magnanimity of it. All those years of hard work from so many talented individuals has paid off to such a degree that open source technologies are now the default, rather than the challenger or also-ran. Moreover, it has become so ubiquitous that the public at large is using it without ever caring or needing to know about it.

In a very real way, the open source community has changed the world. It continues to do so every day. I get to be a part of that, and I won’t pretend that the idea doesn’t make me a little heady and giddy.

I started this blog entry up with the question “Why not change the world?”, but that was a little bit misleading. We’ve already succeeded. The real question has to be “How will you change it next?“.

Flock 2013 Con Report

My god, it’s full of stars!

So as most of you probably know, this past weekend was Flock, the first of a new breed of Fedora conference that replaces FUDCon. It was reasonably well-attended (the count I heard was about two hundred). Among those that attended were nearly all of the well-known members of the Fedora community. I’m sure some (many?) of them will also be summarizing their experiences, but I want to get my notes out there while it’s still fresh. This is not a comprehensive overview of Flock. If that’s what you’re looking for, Máirín Duffy has provided an excellent set of blog posts including the recordings and transcripts[1].

The first three days followed a pattern of talks/lectures before lunch and workshops or hackfests in the afternoon. There were a great many sessions (usually eight or nine running concurrently at any time) and this made it somewhat difficult to see all of the useful content.

There were a great many interesting talks, but I’m going to focus this report on the three that I think will have the most lasting (and widely-felt) impact on the Fedora project as a whole.

Updates Model

The first here was Tom Callaway’s proposal of changing the default updates delivery method. As he put it, currently Fedora users are “drinking from the firehose”. All updates are delivered as soon as they hit the stable updates repository and it feels to users like they are in constant flux. Tom’s proposal is that instead of a constant updates stream, we should shift to delivering important[2] updates as part of a monthly update set. Security issues should still be released in the current model, so that users get those as quickly as possible. There was some debate over whether security updates should be installed automatically or just notified, but that was left unresolved. The set of “important” updates should be rolled up as a bundled collection of updates that is prepared a week before the monthly deliverable and offered for testing as a complete set. Package updates outside this set should be made available similar to the way Microsoft does its “optional” updates. They can be selected manually (or in bulk) in an updates tool if the user wants them. We believe that, by having the ability to tests updates as a set we will be able to reduce some of the instability the arises throughout the Fedora supported lifetime as well.

Tom’s proposal dovetails closely with the next two proposals, one from Matthew Miller and one from myself. Matthew’s proposal is fairly well-known at this point. It involves redefining Fedora into a set of policy rings wherein we can tighten or relax the packaging rules in order to make it easier to run applications and SDKs in or on Fedora. I won’t go into great detail on this proposal, as it’s been discussed at great length on other lists. I will say that the Fedora community as represented by Flock attendees was receptive and very much liked the idea of relaxed packaging requirements at the higher levels of the stack, as well as being able to layer projects atop other foundational pieces (such as OpenShift Gears or Software Collections).

Fedora as Products

The final proposal was one that I came up with and discussed with Robyn Bergeron and the RHEL architects shortly before Flock. The general idea behind this proposal was to stop trying to treat Fedora as “everything for everyone”. Instead of our classic approach of building all projects in Fedora as a single collection of packages, we should instead focus on a set of specific constituencies and serve those needs directly and completely. To that end, I proposed that we should build three products from the Fedora family with very specific target audiences and then work with Matthew’s proposal to layer other software atop these products in a sensible way.

Fedora Server

Target: People for whom RHEL and CentOS don’t move fast enough, and people who want to see and influence the future of RHEL
Purpose: Build a better RHEL, and engage customers in development of RHEL, OpenStack, and other emerging technologies.

One of the key points here is that we would start making it clear that Fedora Server is the development path for RHEL 8. Disruptive changes made to the Fedora Server would be carefully scoped out ahead of time. We want this to be the place that we can engage application developers and tell them “if you want something from RHEL to enable functionality for your application, this is where you build it”.

Fedora Cloud

Target: Development; DevOps in production; OpenShift
Purpose: We do not become entirely irrelevant.
This should be mainly a proper subset of the Fedora Server, with some few additional packages for acting as a virtualization client. The goal here is to provide the definitive operating system for running in a PaaS environment like OpenShift. This is the fast-moving DevOps platform that people who are doing rapid develop-and-deploy with high resiliency would want to use in production.

Fedora Workstation[3]

Target: Creatives, Developers, Sysadmins, and other IT professionals
Purpose: Keep Linux users on Fedora (This is a niche market; we recognize that. But let’s make it our niche.)
This is the platform upon which we would want people to be doing useful work in the Fedora/RHEL ecosystem. It’s where the “makers” and IT professionals should be able to get their work done. This is also the product that would have the most leniency in making disruptive changes (the most obvious forthcoming one being Wayland). That is not to say that this should be “Rawhide in disguise”. The goal here (as with the other products) is that this should be a stable and useful workstation that enables the user. It is not a playground, nor is it a general-purpose desktop.

Tying it together

The responsibility for defining the specific requirements placed upon each of these products would be placed upon a working team (chaired by a FESCo member) for each product. The proposals presented therein would require approval and then would become essentially a constitution for that team. The specific details of how this process would work are still being worked out. All of this is contingent upon acceptance of the overall plan by the Fedora Advisory Board, who will be receiving a formal proposal in the next week or so.

Last Day

The fourth day was dedicated to hackfests. I spent the morning working on Kerberos-related hacking on the fixes for the new kernel keyring support and then the afternoon in Matthew Miller’s “Hack the Future” session discussing his and my proposals for a new, more targeted Fedora design. In this latter discussion, we came up with most of the above plans.

It is worth noting that while the overall reception of these plans was positive and encouraging, there were individuals from Fedora Release Engineering and Fedora Quality Assurance teams that fear these changes will strain their already-limited resources. This is a valid concern and will be addressed. We’re looking at ways to reduce the impact on these two teams (such as by increasing automation and re-using existing capabilities wherever possible) as well as possibilities for providing increased resourcing. No plan will go forward without consulting these two groups.

If you have read this far, I thank you. I know it’s a bit wordy.


[2] “Important” should be left intentionally vague at this time.
[3] There is debate over whether to call it “Workstation” or “Client”, but we all agree that “Desktop” is not the right name. I’m in favor of Workstation, so that’s what I’ll use here.