Linux Czar

Its possible my earlier post was…a bit much. Probably being frustrated all day means I shouldn’t post at 1:00 AM.

I still believe that these INs are a terrible idea. They serve to make my life more complicated and its a very “corporate” way to control your products compared to the Open Source methodology of choice.

I’m drawing comments. I’ll take that as a good sign. To correct myself and respond to a few comments, is this IN thing a form of DRM? Wikipedia defines DRM as

an umbrella term that refers to any of several technologies used by publishers or copyright owners to control access to and usage of digital data or hardware, and to restrictions associated with a specific instance of a digital work or device.

Assuming that Wikipedia is fairly accurate here is there a case we could compare this to DRM? INs definitely don’t qualify as copy protection or technical protection measures. There is really nothing to prevent you copying the work in question. However, I think there is a point that INs control access to the software. Can you install it later via Yum (provided you have the proper contracts) or use RPM to install the packages from the CDs? Yes. Would every single person installing RHEL 5 understand that you have to go back and install more stuff? I have folks that I can’t get to understand that you must register your system with RHN to even get any updates. What about the software on the CDs that are not covered by my contracts? I can just make my own Yum repository of those too.

Does this potentially violate the GPLv3? I am not a lawyer so insert grain of salt here. In a more lucid state I would definitely say no. The distribution can be completely reproduced via the source without loss of functionality.

Another commenter had the audacity to say “installation numbers are a convenience.” I laughed. I laughed a lot. Thanks, ’cause I needed that. I do more than install a few RHEL 5 clients and servers. I maintain well over 1,000 RHEL based machines. So my environment is highly automated. The admins I work with understand well the existing system of choosing package sets. Now I need to somehow figure out from their package set choices what IN I should use. Or do I distribute INs to the admins and let them combine yet another code on top of the RHN activation key and our internal configuration management keys and make the same package choices twice? There are also the folks that want to install their own version of RHEL without our local modifications. I see the next 6 months are going to be putting out a lot of fires of “I can’t install RHEL 5″ rather than doing useful things. No matter which way ends up the best to solve using INs there has been more complexity introduced.

The same comment’s corollary seems to indicate that based on your contracts you are not permitted to install some “binary bits” found on the installation media. That seems like “technologies used by publishers or copyright owners to control access to and usage of digital data” to me.

Perhaps what really set me off last week is that we use the academic contracts to purchase our RHEL subscriptions. So on Red Hat’s website I see my line items that look like “RHEL WS/AS Site Subscription” or “RHN Academic Site Subscription.” None of my line items are specific to Server or Client much less the virtualization, workstation, or cluster options. The web site gives me several INs. All of which are the same Server, 2 sockets, and 4 VMs. I’ve seen lots of noise on mailing lists about academic customers not having the INs that cover what they purchased. I’ve spoke with various folks in and outside of Red Hat and I know they are honestly working to correct the situation.

The solution here is choice. If I’m doing onesy-twosy installs let me chose what options I want to install. This is one reason we have installclasses. During firstboot and RHN registration I could be presented with a well designed dialog explaining that I have installed software options not covered by my entitlement if that were the case. This would warn about security issues and give me options for what I should do. In my automated environment I have control over what can be installed and can configure my local configuration management tools to not install options that we do not have access to right beside the code that knows how to register the machine with RHN. I do that already, that adds minimal complexity.

The solution is choice.

I’m normally a big fan of Red Hat. Both for the ideals and progress in the Fedora community and for the advantages of using RHEL in the enterprise world. RHEL as a distribution tends to Not Suck(tm).

With the introduction of RHEL 5 Red Hat now wants you to use an activation code to install. Called Installation Numbers. (How long did it take someone to figure up that name?) You can install without a code but you only get the core Client or Server installed. In most cases this is somewhat less than useful. But, being clear, to have the installer install much of the Open Source software on the CD sets you must enter a 16 diget hexadecimal code that configures the installer to install the options you purchased.

I’m very insulted. The ideals that Red Hat holds so highly are flushed down the toilet at the sight of something green. How is this not DRM? How would this be legal with the GPL v3? Its really a horrid, evil idea. The least of which makes me as a sysadmin have to do much more work to deploy RHEL 5. I remember when (back in the day) new distributions were easier to maintain and deploy than older.

This is Open Source software. Its all about choice. Why did Red Hat chose to not give the user a choice what flavor of Server/Client they want to install? At RHN registration time the admin could be alerted that he or she has installed features not covered under the contract and give them options for what to do. Possibly, buy the missing support? No…that would be too hard. Instead, we must give them the complete set of software and then restrict how it can be used. Bad Red Hat.

This is Open Source software. The installer needs to know how to parse these installation numbers. The RHN tools on the system need that knowledge as well to communicate with RHN. This is Open Source software Red Hat. You cannot hide the details of these codes. In fact, I have already learned all I need to generate Installation Numbers myself with any feature set I so desire.

You can find some quick code to generate these numbers in genkey.py. I have also written a more in depth article about creating installation numbers and a few examples.