LWN.net Weekly Edition for November 18, 2004

Fedora: an example of community involvement

The Fedora Project, after more than one year, has not become a "community" project by any means. It is centrally controlled, and many crucial decisions seem to come from some sort of smoke-filled room in Raleigh. The long-promised publicly-available source code repository ("intended to be available by the release of Fedora Core 2") is nowhere to be seen, the governing councils have not been created, and the project's technical leader is rarely seen on the mailing lists. In many ways, Fedora looks more like an open beta testing program run by Red Hat than a true community project.

That said, a couple of things are worth pointing out. One is that the Fedora Project has clearly succeeded in creating, evolving, and supporting a top-quality distribution with bleeding-edge software and predictable release cycles. The other is that, in some ways at least, Fedora's interaction with its user community is yielding clear benefits. Simple testing and filing of bugs is probably the biggest part of it. Beyond that, however, the project does seem to listen to its users and be influenced by what they say, even if Red Hat does have the final word on important decisions. And, at times, members of the community can truly help to make the distribution better.

As an example, consider this challenge recently posted by Owen Taylor. He noted that a Linux system still takes a couple of minutes to boot, which is too much:

Owen asked for help from the community in figuring out what was slowing down the boot process. That help was all of two days in coming, when Ziga Mahkovec posted some results. He had modified the kernel boot process to instrument what was going on, and produced a pretty chart showing where the time was being spent. One immediate culprit stands out from the chart: the rhgb process. That is the "Red Hat Graphical Boot" utility, which does no actual work; it simply watches over the initialization process and shows its progress on the console. It's not something which should be occupying a large part of the time required to boot. But it was responsible for over 1/3 of the time required to boot a Fedora system.

As it turns out, rhgb gets into a loop where it simply spins in the CPU, slowing down everything else. A bugzilla entry was created, the bug was fixed, and life improved. Ziga made a new chart showing an improved situation - and a boot time of 46 seconds.

Fedora users may have even more to cheer soon. Ziga made yet another chart which follows the process through a GNOME graphical login. One of the big culprits there is the obnoxious, throbbing Red Hat Network update applet. It turns out that Red Hat developers detest that applet too and tend to kill it on their systems. Now that it has been shown to be a major factor in making users wait to be able to do anything with their systems, it may just get some needed attention.

Meanwhile, the bottom line is this: Fedora may not be a community project like, for example, Debian. But neither is it a sealed product from a corporate cathedral. Fedora is clearly a better distribution as a result of its interactions with its users. Hopefully, someday, Red Hat will follow through on its promises (source code management server, community governing council) and bring the community further into the process. Fedora is blessed with a community of users who want to help; it shouldn't let the desire for corporate control keep them from being part of the project.

Comments (17 posted)

Book review: SELinux

The NSA's Security Enhanced Linux project is controversial. To some, it is the future of Linux computing; with SELinux, many of our current security nightmares will cease to trouble us. To others, SELinux is a morass of complexity which is difficult, if not impossible, to understand well enough to get any sense of whether it is configured in a secure way or not. This whole situation is not helped by the current state of SELinux documentation. There are few resources out there for people wanting to know how SELinux works, how to manage it, or even whether to try to adopt it.

There is, however, a new book on the shelves: SELinux: NSA's Open Source Security Enhanced Linux, by Bill McCarty. At 254 pages, this book is relatively thin by contemporary technical book standards. It offers a finicky editor a fair number of things to grumble about, but those grumbles should not overshadow the important point: this book is an important step in the process of bringing SELinux to a level where software developers and system administrators can make some sense of it.

Let's get the grumbles out of the way first. The book shows some signs of having been written and produced in a hurry; as a result, it has more than the desirable number of typos and contradictions. It talks alternately about the runcon and run_con command, for example. It claims that "domain" and "type" are interchangeable terms for the same concept, then says "Recall that a general type is one not related to a specific domain." Readers are directed to the kernel source (said to be found in the deprecated /usr/src/linux directory) to associate a device name with a major number when a quick look at /proc/devices would do the job. We are told "SELinux is generally stable and free of trouble," which would, by itself, strain many readers' ability to suspend disbelief, but then the author suggests avoiding using X on SELinux systems, or, if that is impractical, learning to love GNOME to avoid problems with KDE. And so on. The reader finds these things often enough that they become a significant distraction from the real content of the book.

The book starts with a general overview of SELinux, including the obligatory set of scary statistics on the frequency of attacks. A number of approaches to security are looked at, including, of course, mandatory access control schemes. The second chapter is a quick overview of SELinux, where the important concepts (roles, types) are introduced. The two mechanisms which can cause type/domain transitions (file creation and exec() calls) are introduced. Everything is fairly vague at this point, but the discussion is enough to let some of the important ideas sink in.

The author then takes a diversion into how to install SELinux on several distributions, with special attention paid to Debian, Fedora, and Gentoo. This information will certainly be useful to some readers, but (especially in the future) most readers are likely to find SELinux on their systems already. If you are trying to figure out how to make your Fedora system work, Chapter 3 will just be a distraction. (Incidentally, the book covers Fedora Core 2).

Chapter 4 gets into high-level SELinux administration: turning enforcement on and off, installing new policies, dealing with file labels, etc. There is useful stuff here, but the presentation leaves a little to be desired. For example, loading policies requires the use of the newrole command (which will remind old-time Unix users of the obnoxious newgrp command made necessary by certain vendors' kernels which could only handle membership in one group at a time). Policy loading is covered before newrole, however, leading to a fair number of forward references in the text. Reordering the discussion would have made things easier to follow. That said, this chapter provides a reasonable start for administrators trying to find their way around their SELinux systems.

The next three chapters form the technical core of the book, with detailed descriptions of the language used to define role-based access control and type enforcement rules. There's lots of cute railroad diagrams for those who want pictures, and a detailed examination of how the policy for the ping utility is put together. If you are trying to make sense of the policy files that come with your SELinux distribution, these chapters provide the information that you will need. The book then winds down with a chapter on ancillary policy statements and one giving some pointers on how to carry out simple policy changes.

A topic which is missing entirely is how one might design a security policy from the beginning. The implicit assumption is that few, if any, readers will have such ambitious goals; they will, instead, be trying to make things work with the policy shipped by their distributor. That is probably a good assumption; designing an SELinux security policy from the beginning is not for the faint of heart. Still, as we'll explore in a companion article, there may be reasons for wanting to take on such a project.

Meanwhile, if SELinux takes off the way many people clearly expect it to, there will be a strong need for developers and administrators who truly understand how it works. For that reason, your editor predicts that this book will become required reading for a lot of people. For all of our quibbles, we must say that Mr. McCarty has succeeded in shedding some much-needed light into a dark and difficult corner of Linux systems administration.

Comments (4 posted)

Solaris 10

As the release date for Solaris 10 nears, Sun Microsystems has been powering up the hype machine accordingly, and trying to convince the world that Solaris 10 is the best OS ever. According to Sun, Solaris 10 will offer more than 600 new, "breakthrough" features. That's a few too many for this article, but we'll take a look at some of the most notable features that are slated for inclusion in Solaris 10.

One interesting feature is Solaris Dynamic Tracing (DTrace). DTrace is a system for troubleshooting problems in real time, by allowing admins and developers to observe and tune system behavior.

Another feature that Sun is touting is Solaris Containers. Containers are essentially virtual machines, which allow an admin to create "private execution environments" on a machine, to isolate applications from one another and essentially create multiple hosts on a single server. This is, of course, nothing new to Linux users who have already discovered User-Mode Linux or any of the other virtualization solutions available for Linux.

Solaris 10 also comes with a new file system, ZFS. This is a 128-bit file system that offers far greater capacity than the current UFS, and 64-bit checksums for data stored on the filesystem. ZFS works with "virtual storage pools," and is supposed to greatly reduce the difficulty of administering file systems. According to Sun's website:

The TCP/IP stack gets special attention in Solaris 10. Sun has rewritten its networking stack, and claims that delivers a 50-percent or better speed boost for "many networked applications." Solaris 10 also includes built-in kernel support for the Stream Control Transmission Protocol (SCTP) and Session Initiation Protocol (SIP) in an effort to make Solaris 10 attractive for VoIP deployments.

Despite the slew of new features, Sun has fallen into an unenviable position with Solaris: Having to go to customers with a emulation technology to run their existing programs. When Linux was the underdog, much was made of the ability to run Solaris and other *nix binaries on Linux, as a way to allow companies to move their existing applications to Linux. With Solaris 10, Sun is promising a Linux Application Environment (LAE) to run Linux binaries on Solaris 10 on x86 systems.

Pricing for Solaris 10 has changed as well. Sun is, literally, giving it away. Sun is giving a "right-to-use" (RTU) license and security updates for Solaris 10 at no charge. Customers who want to utilize support or have access to all Solaris 10 updates and fixes start at $120 per year for a 1-4 CPU machine.

The company is also making much of binary compatibility with Solaris 10 -- promising customers that older Solaris applications will be able to run unchanged on Solaris 10.

Perhaps the most interesting feature for Solaris 10 is the licensing, if we ever find out what it is. According to Sun's executives, Solaris 10 will be open source. However, the company has not yet announced a license, whether the license will be OSI-compliant or exactly how much of Solaris 10 will be under this open source license. Further, assuming that the license is open enough to encourage contribution, Sun hasn't set out any information about accepting contributions from the community.

A more ominous possibility exists: Sun could release its code under a license which is not only non-free, but which creates problems for any free software developers who look at that code. If Sun's fortunes continue to decline, there is a definite possibility that the company could look to litigation for its salvation. This possibility should be kept in mind by anybody who contemplates going anywhere near the Solaris code.

Obviously, Sun is trying to regain some of the ground that it has lost with Linux. It seems unlikely, at least to this writer, that Sun will make much headway in regaining lost customers with Solaris 10. While Solaris 10 offers some undeniably useful and interesting features, it's fairly obvious that most organizations do not choose operating systems on features alone.

Sun lacks the momentum that Linux has gained over the past few years. Companies that have already invested time and money into migrating to Linux are less likely to spend additional time and money evaluating Solaris 10 if Linux is meeting their needs. Companies that are already utilizing Linux are unlikely to even bother evaluating Solaris 10 unless Linux does not meet their needs.

Also, Sun's LAE won't be available in the first release of Solaris 10, meaning that organizations that are willing to consider migrating from Linux to Solaris will have to hold off until Sun releases LAE in an update to Solaris 10. This puts Sun even farther in the hole with regards to losing customers to Linux.

If the Solaris 10 license is GPL-compatible, many of Solaris 10's interesting features will no doubt find their way into Linux. It seems unlikely that Sun would choose that path. On the other hand, if Sun chooses a less friendly open source license, it will have a tough time creating a community that will drive Solaris development or adoption in the same way that the GPL has driven Linux. Either way, Sun seems set to lose with its open source ploy.

Solaris 10 looks to be a fine operating system, but it may very well be too little and too late to help Sun regain its market share.

Comments (36 posted)

Poland gets cold feet on Europatents

A press release has gone out stating that the Polish government has officially decided that it is unable to support software patents in Europe.

Needless to say, this is an important development. Software patents will probably not be defeated quite this easily, but this is an important step in that direction.

Comments (none posted)

LWN comes early next week

Next week's LWN Weekly Edition will be published on November 24 - one day earlier than usual - so that the LWN staff can prepare themselves for the annual Thanksgiving feast. We'll return to the usual schedule on December 2.

Comments (none posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: Civilizing SELinux; New vulnerabilities in bogofilter, ez-ipupdate, OpenSSL, SquirrelMail, sudo, ...
• Kernel: Not getting burned by kunmap_atomic(); Trustees Linux; Avoiding unwanted OOM killer experiences.
• Distributions: SUSE Linux Enterprise Server 9; Gentoo Linux 2004.3; Novell Desktop reviewed
• Development: Wired: a music production and creation system, new versions of ALSA, GLib, DSPAM, spamprobe, Analog, abcde, Ecasound, Grace, SQL-Ledger, PythonCAD, JGraphpad, JUNG, GARNOME, Xfce, Passepartout, Grisbi, Gaim, Epiphany, Coaster, SableVM, MLton, Pyro, Ali, Wing IDE.
• Press: A patent marketplace, Firefox adoption, Open Solaris, Norway saves money with Linux, Senate Copyright Bill, MS and Indemnification, FC3 review.
• Announcements: The Linux Core Consortium, VC firm joins OSDL, lots of new books, VA survey on open-source resistance, GNOME love day, JavaPolis, PHP Quebec, Mozparty2.
• Letters: How to improve IE

Next page: Security>>