I now have that tool in NetworkManager. In this article I will explain what NetworkManager is, what capabilities exist in the tool (in both Fedora and Red Hat Enterprise Linux), and what you can do to extend it to give you more control over your system than before.

What is NetworkManager?

NetworkManager is a software utility that allows a desktop user to manage wired, wireless, modem, WWAN/3G, and VPN network connectivity from a single source. It does not require root access or manual editing of configuration files.

NetworkManager started as a Gnome project and initially appeared in Fedora. It is now supported on multiple desktop environments (Gnome, KDE, Xfce, etc.) and in multiple distributions (Fedora, SuSE, Ubuntu, Gentoo, Debian, etc.). NetworkManager uses dbus and hal to provide network status updates to other desktop applications, allowing them to alter their operation based on this information. For instance, if NetworkManager shows the network is offline, then apps like Evolution and Pidgin will put themselves into offline mode andwait for the network to come online.

How is the NetworkManager software deployed on the system?

NetworkManager is deployed in two parts. The first part is the NetworkManager daemon, which is found in the package NetworkManager. This daemon should be set to start while the system is booting. This can be accomplished by entering the following command as root:

    # /sbin/chkconfig NetworkManager on

You can also start NetworkManager manually by entering the following command as root:

    # /sbin/service NetworkManager start

The second part is the user client, which normally takes the form of an applet. This applet (nm-applet) can be found in the NetworkManager-gnome package, and should be part of the basic Gnome desktop installation. You will not need to add this applet to your desktop. Gnome will add the nm-applet control to the Notification Area applet when the NetworkManager daemon is active.

How does NetworkManager work?

For the user, most everything will be done via the NetworkManager applet. Exactly what needs to be done depends on the type of networking the user needs to activate.

Wired network

If the system the user is logged into is on a wired network (Ethernet), the user does not need to do anything. NetworkManager will look for the link on the network port. When the link is active, it will bring up the interface and then ask for network information via DHCP.

Wireless Network

If the user is trying to connect via wireless, NetworkManager is especially helpful. As long as the wireless device is active, NetworkManager will scan for available networks and will attempt to connect to the last network you connected to that it can see. If the network it is trying to connect to is a secure network (using WEP, WPA, WPA2, or LEAP) it will request the appropriate security information. Once the information is entered, NetworkManager will try to store this information into the GNOME keyring manager.

To connect to a different network than the one that NetworkManager chooses, simply click on the applet and choose a different wireless network.

WWAN network (3G/EVDO/HSDPA/RTTx1/EDGE)

With the release of NetworkManager 0.70, users can now choose WWAN networking. Most of these cards require activation in Windows, but NetworkManager can handle the auto-configuration some cards need for use under Linux. Other cards may still require some minimal account information to activate and use.

If the card is plugged in when NetworkManager starts, it will be autodetected and an attempt to auto-configure the card will be made when you request a connection to the network. If auto-configuration is successful, the user can then just select the card in the applet menu and connect.

VPN connectivity

Once a successful network connection has been made, the user can also use NetworkManager to activate a VPN connection. Currently, there are modules providing support for OpenVPN and Cisco (via vpnc) VPN connectivity.

The VPN connection will be configured, activated, and deactivated via the applet. Username, password, group passwords, and other information can be stored in the GNOME keyring manager, or the user can choose to be prompted to enter some—or all—of the information at each login.

What else can NetworkManager do?

Beside managing your network connectivity, NetworkManager has another key feature. NetworkManager can run scripts when there is a network state change on any interface, using the network interface and the up/down state as variables. In prior releases, this functionality was provided by a separate daemon called NetworkManagerDispatcher. As of NetworkManager 0.70 in Fedora 9, this functionality is now integrated into NetworkManager itself.

In Bash scripts written for NetworkManager, the variable $1 equals the interface whose state has changed and triggered the script. Variable $2 equals the state of the interface (up or down). No other variables are needed.

Let’s take a look at one of the scripts that is included with Fedora 9:

# cat /etc/NetworkManager/dispatcher.d/05-netfs

#!/bin/sh

export LC_ALL=C

if [ "$2" = "down" ]; then
        /sbin/ip route ls | grep -q ^default || {
                [ -f /var/lock/subsys/netfs ] && /etc/rc.d/init.d/netfs stop
        }
fi

if [ "$2" = "up" ]; then
        /sbin/ip -o route show dev "$1" | grep -q '^default' && {
                /sbin/chkconfig netfs && /etc/rc.d/init.d/netfs start
        }
fi

When an interface comes up and adds itself as the default route, the script starts the netfs service. This script also stops the netfs service when an interface goes down and no default route remains. Effectively, this will mount your NFS and CIFS shares when you have access to the network, and will unmount those same shares when the network goes down. Using this script as an example, you can easily write your own scripts to run various commands as the network state changes.

How can I best use NetworkManager in the field?

Now that you have a good idea of how NetworkManager works and what it can do, let’s talk about how to best use NetworkManager in the field. Now that you have NetworkManager managing your network connectivity, make sure your network interfaces are not trying to start on boot. Nothing is more annoying than having your laptop tell you that your wired network is not available when you are sitting on a plane. If you are using NetworkManager 0.70 (currently in Fedora 9), you should also disable the network service itself, as it may conflict with NetworkManager.

You can go further, writing NetworkManager scripts to activate various services only when they are needed. Many of the init scripts in Linux make the assumption that your system is a server or a workstation with continuous access to the network. Things like ntp, cups, sshd, even rhnsd do not need to be running while you have no network connectivity. These services can be disabled, set to run only when NetworkManager starts them via a custom script on a network state change.

Using the previously posted script as a guide, a script to manage sshd might look like this:

# cat /etc/NetworkManager/dispatcher.d/10-sshd

#!/bin/sh
#
# Start and stop sshd based on network availability using NetworkManager
#

export LC_ALL=C

if [ "$2" = "down" ]; then
        /sbin/ip route ls | grep -q ^default || {
                [ -f /var/lock/subsys/sshd ] && /etc/rc.d/init.d/sshd stop
        }
fi

if [ "$2" = "up" ]; then
        /sbin/ip -o route show dev "$1" | grep -q '^default' && {
                /sbin/chkconfig sshd && /etc/rc.d/init.d/sshd start
        }
fi

You could substitute “rhnsd” or “cups” for “sshd”, and the script should work equally well for those tasks..

If you are a administrator tasked with managing Red Hat or Fedora systems of remote employees, the scripting functionality can be even more handy. You can write a script that looks for the activation of the VPN interface then sends an email letting you know the system is online. You could have the system check in with a Satellite server located within your firewall, installing updates you previously scheduled for it. The possible uses here are many.

The student is now the master

No longer do I envy my Windows-based peers and their easy mobile connectivity. NetworkManager is constantly impressing me, adding functionality and allowing me to be more efficient on the road. This Swiss Army knife of Linux networking gives me the control I need over my connectivity whether at home, coffee house, or airport. Now that you know what NetworkManager is, how it works, and how best to use it, try it out of your own system. I trust you will find NetworkManager works as well for you as it did for me.

More information

1. NetworkManager main project page
2. NetworkManager in Fedora
3. dbus and hal
4. KNetworkManager

The first talk I had a part in was Func, which I co-presented with Adrian Likins. Func, as mentioned before in Red Hat Magazine, is an API for controlling lots of nodes for arbitrary systems management tasks. It is ideally suited for replacing legacy SSH infrastructure as well as building new network applications that require secure network communications infrastructure.

We gave an overview for folks that hadn’t heard of Func before, and showed off several examples of things you can do with the Python API. Interest in Func is growing, and lots of folks are using it in ways we hadn’t originally intended (which is, of course, the idea).

One such application that surprised us was Open Symbolic, which aims to be a user-friendly systems management application written on Func. Additionally, some of our own IT folks have written a very lightweight “cloud” type management application using Func, which you should hear more about shortly. At the conclusion of that talk there were some very good questions about how things work, and also some interest in future expansions (with hopefully some patches coming down the pipe).

My second talk was about Cobbler, our next-generation installation server. I was very pleased to see Cobbler’s talk was standing-room only, showing that there is a lot of need for good tools to help streamline Linux installations and low-level datacenter setup tasks. Again, there were a tremendously good set of questions asked, and the community is already getting a lot larger with people trying out Cobbler after hearing about it at Summit. I’m happy to see that.

The current idea behind Cobbler is to build a common installation service that various applications can use to deploy Linux (more on this below)rather than having to keep creating these components. I’ll also be extending it to deal with image-based deployments in addition to traditional kickstart deployments.

As always, we’ll continue to gather a large community of sysadmins to work together and build common tooling we can all share. The basic premise is that by working together, we can build tools that are more powerful than the tools we could build alone. By following an open development model with shared tools, the need to reinvent the same wheels to do the same tasks goes away.

We’re also building a large set of community documentation based on deployment best practices and tricks, and I hope to roll this into a nice openly licensed manual and deployment guide later this year. Open community, open code, open docs — neat!

And while all of this is nice, the most exciting part of Summit was the announcement about Spacewalk. Spacewalk is the project name for the open-sourcing of Red Hat Satellite Server. This is not a “community edition”, it’s everything. The upstream for all code in the project is going to the website, and we’re already seeing a lot of interest from existing Satellite customers and prospective users. We had a lot of great discussion at FudCON about places the project might go, and there have already been several non-Red Hat patches made against the codebase.

We also announced that Satellite will be using Cobbler to provide advanced deployment support next year, so we can already see the advantages of getting these tools to work together. Planned work includes adding open source database alternatives and improving our support for Fedora and derivative distributions.

In the future, Func may have a place in Spacewalk as well. We can also look at incorporating other proven open source management applications, tools, and libraries. Everyone is encouraged to join the Spacewalk mailing lists or IRC channels (#spacewalk on irc.freenode.net) if they are interested in learning more or have ideas/questions.

These three applications, in general, constitute a new way of thinking. Namely, how can we apply the Fedora Development model towards enterprise management applications and sysadmin-level tools and processes?

Rather than buy tooling from a vendor or inventing internal frameworks that disappear when one changes jobs or departments, what can we share and openly build together and re-use? While we use the Fedora model to produce a community-driven distribution, we’re now also using it to produce better ways to manage Enterprise Linux. This development model applies just as equally to Enterprise Linux as it does Fedora. It just works.

As Paul Frields (the Fedora Project Leader) indicated at FudCON, the future of Fedora (and in turn, Fedora Hosted Projects and Extras Packages for Enterprise Linux (EPEL)) is about lowering barriers to entry and encouraging collaboration–we are already doing well on technical grounds. How do we encourage more collaboration around management software? For starters, we work at making it easier to install. And we must make sure the communities remain active and integral, and continue to grow.

A lot of management software is hard to find and install because it’s not yet part of the distribution. I would encourage all ISVs out there that write open source software to look at getting their content into EPEL, where it can be easily found via search and is yum-installable. I’d also like them to take a look at how we are building strong communities around our projects using Fedora Hosted Infrastructure–and to take those examples to their own projects and communities.

Regardless of who we work for, open communication and collaboration are how we get ahead–and Fedora (and EPEL) are providing an outstanding breeding ground for open source software now–even in what was previously thought of as an “Enterprise” type cathedral environment. I should also mention that the Fedora community is full of packaging experts and smart folks who can help you. Join #fedora-devel on irc.freenode.net and say hi.

If you’re not interested in development, but adminster systems and want to know how you can help out, take a look at Mike McGrath’s new CSI venture.

Good ideas come from where we least expect them. The Fedora development model and infrastructure are really powerful ways to create software, documentation, and tools that solve problems for people who need to manage their Linux infrastructure. Whether you are interested in Cobbler, Func, or Spacewalk–or even if you’re interested in Linux systems management in general–let’s get together, find better ways to collaborate, and invest in the operating systems that we all love.

So, that’s my summary of the Red Hat Summit and FUDCon. Boston’s a beautiful city and I will give it a pass for not having sweet tea at all available restaurants. I look forward to Summit and FUDCon next year–we’re growing fast in Fedora and Red Hat Enterprise Linux land, and there’s still many more places to go.

• guest_t – Terminal login, nosetuid, nonetwork, noxwindows, noexec in homedir
• xguest_t – X Windows Login and terminal login, nosetuid, nonetwork, noexec in homedir
• user_t - X Windows Login and terminal login, nosetuid, noexec in homedir
• staff_t - X Windows Login and terminal login, nosetuid except sudo
• unconfined_t – Full login, able to run with almost all privs as with SELinux disabled.

These confined users are a great starting point, but what if you want to create a confined user with different privileges?

I want to create a limited privilege terminal login user with the ability to send mail and read/write files in the /maildir directory.

My son Timothy uses his confined xguest account, but is not happy because he wants to communicate with his friends using AOL.

Fedora 9 has the solution. The SELinux management environment (system-config-selinux) has been updated and includes the ability to build customized SELinux policy modules for the confinement of users.

Remember, this tool is just a wizard–it helps create a framework for building policy. You can then use tools like audit2allow or the package eclipse-slide for further editing of the policy. Thiswill give you a good head start.

In the toolbar panel select:

System->Administration->SELinux Management

This starts system-config-selinux.

Select Policy Module and then Select the New button.

This will start the policy template generator (polgengui).

Click Forward.

As you can see, this screen has been enhanced to allow the creation of policy for confined users as well as confined applications. Writing policy for confined applications was described in a previous article.

The second column, Login Users, allows you to build policy modules that either customize existing user roles or create brand new roles. Selecting Existing User Roles allows you to build policy to change one of the default user types defined above. (guest, xguest, user, staff). Select one of the other radio buttons to define a new user role, based off of the 4 default user roles.

• Minimal Terminal User Role == guest_t
• Minimal X Windows User Role == xguest_t
• User Role == user_t
• Admin Role == staff_t

The final column, Root Users, allows you to define a user type that other user types can transition to when they are running as root. For example you could define a root role, dbadm, to administer the mysql database. You could set up the staff role to transition to this role using sudo.

I want to create a limited privilege terminal login user with the ability to send mail and read/write files in the /maildir directory?

In order to answer this question, we want to create a new Minimal Terminal User Role called mailuser.

Select Minimal Terminal User Role, and press Forward.

This screen displays a list of confined domains to which this role might transition. For example, if you wanted the mailuser to transition to the ethereal domain you would select this now. Since we do not want any transitions we will just hit forward.

This screen allows you to select other roles to which the current role can transition. This is where you would define the transition to dbadm from staff role described above. We will just hit Forward.

This screen allows you to select ports that the user can listen to. If the confined user was going to run a network server you could select the ports here. We will just select Forward.

Finally, we get to a screen which defines the ports the confined user can connect to. We will select the smtp port #25 and then go forward again.

This screen allows you to define a boolean. If you wanted to allow our confined user to connect to the mail port, only if the “allow_mailuser_sendmail” boolean is set, we could create the boolean here. We are not going to do this so select forward.

This screen allows us to select the directory to write the policy framework into. The directory must already exist.

This final screen tells you which files you are about to create. Press Apply.

The tool will create the following policy:

#vi /root/mailuser/mailuser.te
     policy_module(mailuser,1.0.0)
     ########################################
     #
     # Declarations
     #
     userdom_restricted_user_template(mailuser)

This one interface defines all the interaction of a guest user.

     #######################################
     #
     # mailuser local policy
     #
     sysnet_dns_name_resolve(mailuser_t)
     corenet_all_recvfrom_unlabeled(mailuser_t)
     allow mailuser_t self:tcp_socket create_stream_socket_perms;
     corenet_tcp_sendrecv_all_if(mailuser_t)
     corenet_tcp_sendrecv_all_nodes(mailuser_t)
     corenet_tcp_sendrecv_all_ports(mailuser_t)
     corenet_tcp_connect_smtp_port(mailuser_t)

These interfaces allow the mailuser_t to communicate with the smtp ports. Also, the policy generation tool added an interface to resolve host names. We now have enough policy to allow a mailuser_t to login to a machine and connect to a mail server, but not to read/write files to /maildir. This tool is just a framework-generating tool, not a policy editor. We will need to write policy for handing the /maildir directory ourselves. Since we want a directory that the mailuser can read/write to, we need to define a new type, mailuser_rw_t, then we need to tell the system that this is a type that affects files.

type mailuser_rw_t;
file_type(mailuser_rw_t)

We also need to allow mailuser_t to manage files and directories of this type:

manage_dirs_pattern(mailuser_t, mailuser_rw_t, mailuser_rw_t)
manage_files_pattern(mailuser_t, mailuser_rw_t, mailuser_rw_t)

We are done with the mailuser.te file.

Now, we want to define the file context in the mailuser.fc file:

# vi /root/mailuser/mailuser.fc

/var/maildir(/.*)?                  gen_context(system_u:object_r:mailuser_rw_t,s0)

We use regular expressions to define the path.

Now we can run the shell script to compile the policy and install it to the test system.

#  sh mailuser.sh
Building and Loading Policy
+ make -f /usr/share/selinux/devel/Makefile
Compiling targeted mailuser module
/usr/bin/checkmodule:  loading policy configuration from tmp/mailuser.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 8) to tmp/mailuser.mod
Creating targeted mailuser.pp policy package
rm tmp/mailuser.mod.fc tmp/mailuser.mod
+ /usr/sbin/semodule -i mailuser.pp
+ /usr/sbin/semanage user -a -R mailuser_r mailuser_u

At this point we have a new SELinx user mailuser_u installed on the machine. We want to assign a linux user to this type:

# semanage login -a -s mailuser_u dwalsh

We also want to create the directories /var/maildir:

# mkdir /var/maildir
# restorecon /var/maildir
# chown dwalsh:dwalsh /maildir

Now dwalsh can log in and use the /var/maildir directories.

But what about my son and his friends on AOL?

My son Timothy uses his confined xguest account, but is not happy because he wants to communicate with his friends using AOL.

I want to confine my son’s account so that only Firefox can talk to internet ports–but I want to allow his account to communicate with AIM/AOL. I can customize the xguest account and add this access.

Back at system-config-selinux I select New to create a new policy module.

I click forward through the intro screen to get to the policy module selection screen.

I want to modify an existing user role, so I click on Existing User Roles and then click forward.

The next box shows me the list of all exising user roles. Select xguest. The tool will add “my” to the policy name and create policy files named myxguest.

Click forward through the next couple of screens, until you reach the network connect screen.

Add the AOL Ports as a comma separated list, then click forward until the end.

Now take a look at the myxguest.te file that was created:

policy_module(myxguest,1.0.0) 

gen_require(`
      type xguest_t, xguest_devpts_t, xguest_tty_device_t;
      role xguest_r;
') 

########################################
#
# xguest customized policy
# 

sysnet_dns_name_resolve(xguest_t)
corenet_all_recvfrom_unlabeled(xguest_t) 

allow xguest_t self:tcp_socket create_stream_socket_perms;
corenet_tcp_sendrecv_all_if(xguest_t)
corenet_tcp_sendrecv_all_nodes(xguest_t)
corenet_tcp_sendrecv_all_ports(xguest_t)
corenet_tcp_connect_aol_port(xguest_t) 

allow xguest_t self:udp_socket { create_socket_perms listen };
corenet_udp_sendrecv_all_if(xguest_t)
corenet_udp_sendrecv_all_nodes(xguest_t)
corenet_udp_sendrecv_all_ports(xguest_t)

The tool added the AOL ports and the ability to resolve their hosts.

Compile to install the new policy like so:

sh myxguest.sh

Since I had previously set my son up to log in as xguest_u, no user management would need to be done. He can now use AOL Instant Messages in a secure environment.

If I had not set up his account I would need to execute:

# semodule login -a -s xguest_u twalsh

or

usermod -Z xguest_u twalsh

These examples show that it is fairly simple to extend SELinux confined users. If you need more advanced features, you can use system-config-selinux to build the framework and then use audit2allow or eclipse-slide to do further policy generation.

Next time, we will cover confinement of the root user.

From FUDCon Boston, June 20, 2008:

The Fedora Users and Developers Conference (FUDCon) is in full swing on its second day. We have another full day of exceptional hacking taking place on the third floor of the Hynes Convention Center in Boston. Just as the Red Hat Summit is drawing to a close downstairs–winding up with a half-day of sessions and panels–we’re just now kicking into high gear. This has been an exceptional way to introduce open source customers to the larger ecosystem behind the products they love, and the community that powers Fedora, the upstream for Red Hat Enterprise Linux.

Last night at the close of FUDCon Day 1, we had two huge events–the first came courtesy of Fedora’s Infrastructure team. Over the last couple of years, the team has built a world-class infrastructure for hosting and communication throughout the entire Fedora community. Last night, Infrastructure team leader Mike McGrath announced a one-two punch of free software goodness for Fedora. First, our Fedora Account System is now an OpenID provider. This means that the identity you create in the Fedora Project can be used across thousands of web sites. The other big announcement was the new Fedora telephony system, “Fedora Talk,” based on the juggernaut free software VoIP project Asterisk.

That’s right, Fedora contributors will be able to use VoIP to set up voice meetings that facilitate better and more efficient collaboration. There will also be features to ensure that those conversations don’t damage the openness and transparency on which Fedora thrives. As Mike announced in this recent blog post, the hardware and bandwidth have been provided courtesy of our friends at ServerBeach, and the dial-in numbers by Arrival Telecom and DiDDiscount.

Red Hat CEO Jim Whitehurst arrived in the FUDCon space just in time for Mike’s big announcement. I saw a smile spread across his face as he saw the incredible work done by our Infrastructure team–just a recent example of the constant, continuous improvements in Fedora. If you’re interested in what Jim had to say, Fedora engineer Jeremy Katz posted an excellent summary of the speech and subsequent Q&A.

This morning things kicked into high gear again. Some of today’s highlights:

• Our QA and Triage teams continued some very intense work on Fedora’s testing processes, and discussing the current and future use of Rawhide and how it can be used most effectively to improve the distribution.
• A brainstorming session was held by Max Spevack and Mairin Duffy on the future of the Spins website, and how to generate a user-friendly experience for people who want to create and consume customized versions of Fedora (“spins”). Max and Mairin make a great team for keeping the talk on-track and focused on the user experience (or “story”) before lunch, and afterward narrowing in on guidelines and goals for the spin process itself.
• The Extra Packages for Enterprise Linux (EPEL) group members here at FUDCon also formed a hackfest session. The EPEL special interest group is all about helping enterprise Linux users use more of the thousands of software packages available in Fedora.
• The Community Architecture group had a long strategy meeting to talk about its funding for the rest of 2008–making sure it’s spent in a way that maximizes the benefits to Fedora and our community building goals. One of the most interesting things about our CA team–and frankly, one of the reasons many others want to emulate the way they build Fedora’s community–is that they conduct all this work openly and transparently. Anyone is free to see how we allocate our funds, set our priorities, and produce results from our community work.
• Thanks to our friends at Digium, the company behind Asterisk, many of our Infrastructure team, some folks who operate in remote areas of the globe, and a handful of other Fedora team leaders and engineers were able to receive SIP handsets. We’ll use those with the new Fedora Talk to test and implement new communications solutions for all our contributors.
• Around all this activity, there were a constant stream of visitors from the Red Hat Summit–people interested in the ways in which our community brings innovative new ideas and software to the world of free and open source software. Educators, engineers, system administrators, editors, students, journalists, C-level executives, and enthusiasts all were well represented.

It’s been an exhausting but incredibly fulfilling couple of days thus far–and the BarCamp day on Saturday is sure to be just as solid. Just another few days in the whirlwind of community-powered goodness that we call the Fedora Project.

Today I am presenting at the Red Hat Summit in Boston on the topic of “Fedora Packages for Red Hat Enterprise Linux”. This article is derived from that talk.

There are two aspects of EPEL that are important to note. EPEL packages first provide system administrators with a proven, trusted set of packages that are dependency complete. This means that every piece of software needed to let that package build and install is already within the repository or part of Red Hat Enterprise Linux (RHEL). Because of this, EPEL packages do not replace or duplicate RPMs that ship in RHEL or any add-on RHEL solutions, such as Red Hat Cluster Suite or Red Hat Application Stack.

The other aspect of EPEL is the way it can help software vendors and open source projects improve the quality of their applications, while lowering costs, and making it easier to get certified to run on the next version of RHEL. Fedora EPEL is a major reason to participate in the open source process, with all the subsequent benefit.

ISVs and projects benefit through packaging their applications as part of Fedora, gaining the thousands and millions of testers and users, learning and using Fedora best practices for software production and maintenance. Since all this work occurs six, twelve, or more months in advance of the next RHEL alpha cycle, it is a significant jump on the certification process for an ISV. The more the ISVs participate in the open source process, the lower their certification costs can be, as they improve the software incrementally toward a ready-for-RHEL state through the Fedora community.

The benefit is not limited to ISVs. Anyone who has extra software they want available for their RHEL subscription can use or contribute to EPEL. This could be an IT or applications group in an enterprise, academic, or other institution. It could be a small coding boutique or a start-up, looking to ride the social connection toward a larger audience and a stronger code base.

One of the best practices that EPEL teaches is to create a job description for your Fedora package maintainers, and have this job description baked in to a role in your organization. This separates the individual who may have championed the original package creation from the ongoing role of package maintainer. Individuals change jobs and duties, and an integrated job description allows them to pass on the tasks. This overall improves longevity across EPEL.

If you are interested in learning more about EPEL, there is a useful FAQ, and you want to be sure to join and learn more about packaging in Fedora.

Authors: James Bessen and Michael J. Meurer
Publisher: Princeton University Press
Publication Date: March 2008

Patent Failure examines the current state of the American patent system based on the way it has traditionally been treated–as a type of property system. Using the yardstick of property rights and the economics they influence, Bessen and Meurer analyze the costs and benefits of patents to innovators. Their qualification: “If the estimated costs of the patent system to an innovator exceed the estimated benefits, then patents fail as property.”

The authors rightly point out that many of the criticisms of the patent system are anecdotal. We’ve all heard about the peanut-butter-and-jelly patent. So what are we to base reforms on then? Patent Failure answers that with empirical evidence, largely economic, but also from history, international comparison, and legal precedent. The book focuses quite a bit (some might say a bit too much) on the claims brought by E-Data, now a decade-old case.

For quite a few years, patents have been lumped in with the completely different systems of trademark and copyright under the title “intellectual property.” And, as the authors point out, the quotation marks have fallen away. Many, if not most, people now assume patents are property. But for certain industries, namely software, patents fail as a property system.

So what should we do?

That “for certain industries” part is a sticky point. I have to admit, it’s easy for me, and I suspect others, to forget that patents can work quite well outside of software. But because that’s where the controversy is, that’s where the media is, and so it’s the failures we hear about. Bessen and Meurer do plenty to build a separation, often making exceptions for chemical and pharmaceutical patents. Those types of patents come much closer to passing the patent-as-property test than software.

The authors then devote chapter 9 to “Abstract Patents and Software,” the entirety of which you can download as a book preview. They point out that “no other technology has experienced anything like the broad industry opposition to software patents that arose during the 1960s.” That is to say, this unprecedented opposition is coming from within the industry the patents ideally help protect. Software developers oppose patents on their own work. You simply cannot draw the same fence around the property lines of software patents the way you would around the property boundaries of the land you own. The authors conclude:

[Software patents] play a central role in the failure of the patent system as a whole. Any serious effort at patent reform must address these problems and the failure to deal with the problems of software patents–either with software-specific measures or general reforms–will likely doom any reform effort.

Like not giving away the end of the movie, I’ll leave it to you to read and form your own opinion of their recommendations that follow that chapter. You can also read excerpts and some interesting discussion about the book on PatentlyO, a patent law blog.

And if you’re interested in hearing more about the authors’ ideas firsthand, Michael Meurer will be presenting a session about Patent Failure at the Red Hat Summit on Thursday, June 19 at 11:30.

“You want to know the run-levels for Red Hat® Enterprise Linux® or Fedora®?” You pause, thinking. “Well, I use Linux every day, and I know single user mode is level 1…”. You stammer a bit, and say you’re drawing a blank for the rest. The recruiter thanks you in that “sorry” tone-of-voice, and hangs up the phone.

Let’s cross that question off the recruiter’s list forever. (Sorry, recruiters.) In this article, we cover how to create, use, modify, and ultimately master run-levels. Bookmark this page with your favorite bookmarking service, and rest easy about ever missing that interview question again.

Of course, there are more reasons to know about run-levels than just to pass an interview. Interacting with run-levels is quite useful once you get used to it. In this article we are going to cover the basics, and then go beyond that to create our own run-level that we write a script against.

What’s a run-level?

A run-level is a system state that is defined by the services listed in /etc/rc.d. Typically, advanced administration of a machine is done by switching run-levels (or state) to perform tasks such as minimal resource usage, run-level 3, shutdown run-level 0, or maintenance. Maintenance is run-level 1–or single user mode, as it is commonly known.

Unix/Linux run-level comparison chart

If you happen to work with AIX, Solaris, HP-UX, Ubuntu, Fedora, Free BSD and/or Red Hat Enterprise Linux, then it can get a bit confusing figuring out which run-level does what. Please refer to the Wikipedia reference at the bottom of this article to get more information on cross platform run-level comparisons.

Red Hat run-level chart

Here is a chart of Red Hat-specific run-levels:

What run-level am I?

Just like life, with an operating system you need to know where you are now, in order to get to where you want to go next. If you are planning on modifying your run-level, you need to first know what your current run-level is. In order to do this, you can use one of two commands, like so:

[root@localhost ~]# who -r
         run-level 3  2008-04-29 08:17                   last=5
[root@localhost ~]# runlevel
5 3

If we look at the output of who -r, we can tell that we are currently running at run-level 3–which is multi-user, but console only.We can also tell that we were previously running at run-level 5, which is multi-user with console and X11 login.

Changing run-levels

Once you know what run-level you are at, it is very simple to change to a different one. All you need to do is type: “init” followed by number of the runlevel you would like to switch to. Here is an example of switching to single user mode, or runlevel 1:

init 1

This command will change your system to single user mode, and it will ask you for the root password. When you arrive in single user mode, there are no services running, as this level it is most often used for maintenance, backup, or recovery. Once you are in single user mode it is quite common to enable, for example, network and NFS to backup your operating system, like so:

service network start; service nfs start

When you are done with your work, type in the run-level you would like to go to–perhaps run-level 5 which brings up the X11 login window:

init 5

Later in this article, we will write our own run-level and then use it to script a maintenance operation.

Permanently changing the default run-level

While changing the runlevel manually is most common, sometimes it is useful to change the default run-level from level 5 to level 3 permanently. This can help conserve resources inside of, for example, a virtual machine. You may also choose to define your own custom run-level, and wish to make that the default.

You will need to edit /etc/inittab and change this line with your favorite text editor:

id:5:initdefault:

Change ‘5′ to the run-level you wish your machine to be at when it boots. To change the run-level so that it never loads the GUI on boot would look like this:

id:3:initdefault:

Note:

A word of caution on editing /etc/inittab. It is very important to keep /etc/inittab in version control, and/or keep a backup of it when you are editing the file. If you make a change incorrectly you can render your operating system unbootable.

Tip:

If you happen to get yourself in this pickle, there is a way out. You can interrupt the Grub boot loader and press “A”, and then append the word “emergency” to the end of the kernel arguments. This will boot the operating system without using init. Then, you can fix what you altered by copying back the original version of /etc/inittab.

Creating your own run-level HACK

First, a word of caution. Do not do this on a production machine, period! This section is a VERY dirty hack that you should only use on a virtual machine you can experiment with, or a machine you don’t mind rebuilding.. It is always a good idea to do testing inside of a virtual machine before doing something that could potentially render a box unbootable. This is a very quick and dirty way to alter a run-level for the purposes of learning, but perhaps you can get some ideas from it that can be used in a more production-oriented way. Ideally, some of the readers of this article will post some production quality hacks to creating custom run levels.

1. cd to /etc/rc.d/rc4.d/
2. do a sanity check to make sure you are running Red Hat: cat /etc/redhat-release
3. backup existing run-level directory:

   mkdir /tmp/rc4.d.original/
   cp /etc/rc.d/rc4.d/* /tmp/rc4.d.original/
   

4. rm -f /etc/rc.d/rc4.d/*

At this point

 cp /etc/rc.d/rc1.d/* /etc/rc.d/rc4.d/

We have now copied the run-level scripts for single user mode into our own custom run-level 4. We can hijack the the S99single script and tell it to do something different. In this example, we are going to write a custom Python script that gets forked to the background and backs up the machine over rsync. Let’s edit that file we copied:

vim /etc/rc.d/rc4.d/S99single

Change the last part of it to look like this:

# Now go to the single user level.
echo $"Telling INIT to go to single user mode."
echo "This is a custom code. Forking custom script"
/custom.py &
exec init -t1 S

We’ve inserted two lines. One echoes that we are forking off a custom script. The second line forks a python script, shown below, that backs up the machine via rsync. Note that this assumes you have set up ssh keys on the remote backup server.

custom.py script:

#!/usr/bin/env python
import time
import subprocess

rsync = "rsync -av / 10.0.1.3:/Volumes/Backup/server_backup/"
network = "service network start"
init = "init 3"

cmds = [rsync, network]

def single_user_backup():
    """Starts network service, creates backup and returns to init 3"""
    try:
        subprocess.call(network, shell=True)
        subprocess.call(rsync, shell=True)
    finally:
        subprocess.call(init, shell=True)

def main():
    """Runs program"""
    print "sleeping for 60 seconds"
    #time.sleep(60)  #Gives machine time to quiesce
    single_user_backup()

main()

The main function runs a sleep command for 60 seconds, just to give the single user mode scripts time to quiesce the box. Remember, this script is forked to the background. Next, function single_user_backup attempts to start network services and run rsync to remotely back up the whole / volume to another server. This is obviously crude and there will be lots of errors trying to back up /proc, for example, but it give you an idea of how an automated backup could work with a custom run-level. Finally, the machine gets called back to init 3, which is console only multi-user mode.

Tip:

Again, this is just an idea for a backup script, but not one I would actually run in production in my wildest dreams. One problem with this technique is that because of symbolic links in run level 1, we actually, changed run level 1 and our run level 4. This is not acceptable, obviously, for any sane user, but it is acceptable as a way to have fun with a disposable virtual machine!

If you can think of a more realistic backup script that would work from a custom run-level, I would love to see it. Create a how to on your blog, and then post a response to this article. Also, it would interesting to see other things such as database backups and migration done with custom run-levels as well. Leave a comment and let me know what you’d do.

Running your own run-level

To run the newly created run-level, you only need to type:

init 4

You will then see the custom print statements we inserted. The machine
will sleep for 60 seconds, and then run the rsync backup.

Summary

This article covered quite a bit of ground in a short while. We went over what a run-level was, how to tell what run-level you are at, how to change run-levels, and, finally, how to make your own run-level with custom, frankenstein quality, code. Hopefully, this showed you some new tricks and spurs some ideas for further innovation with run-levels.

References

• Section 19.1. Runlevels (Red Hat Enterprise Linux 4 manual)
• Wikipedia: Runlevel
• Wikipedia: Init
• Python for bash scripters: A well-kept secret (RHM, Feb 2008)

About the author

Noah Gift is the co-author of Python For Unix and Linux by O’Reilly Publishers. He is an author, speaker, consultant, and community leader, writing for publications such as IBM Developerworks, Red Hat Magazine, O’Reilly, and MacTech. His has both a consulting company and a personal website. Noah is also the current organizer for the www.pyatl.org”>Python User Group for Atlanta, GA. He has given presentations at PyCon and PyAtl. In his free time, he enjoys spending time with his wife Leah, and their son Liam, playing the piano, and exercising religiously.

Linux.com, like many of the reviews, not only picked up on the technical innovation that Fedora leads, but the community that is at the center of everything the project does.

http://www.linux.com/feature/135102

“The Fedora distribution has a reputation for innovation, and the new Fedora 9, released today, is no exception. With features that range from easy filesystem encryption to support for the ext4 format, it includes a wide range of features that are likely to become standard in other distributions in the next six months. But for Paul W. Frields, who became Fedora project leader in February, what distinguishes the release is less the technology than the community that supports it, and how the technology contributes to the larger free software world.”

PC Pro, on the other hand, focused largely on the other two features that have been widely regarded as resounding sucesses for Fedora:

http://www.pcpro.co.uk/news/196605/red-hat-dons-stylish-new-fedora.html

“Fedora 9 will be put up for download today, and continues the trend of making Linux a more inviting proposition for newcomers…

Fedora 9 also allows you to carry a persistent version of the operating system around on a 1GB or greater USB stick, which maintains all your updates and saved files, meaning you need never leave home without your operating system again.”

And bit-tech.net won the award for the most accurate and succinct report of all:

http://www.bit-tech.net/news/2008/05/12/fedora-9-leaked/1

“With the official release due tomorrow, it’s clear that there’s plenty for fans of the Fedora distribution to look forward to.”

If you’re interested in reading more reviews about Fedora 9, the project is keeping a regularly updated list of all the reviews they come across, and you can find it at the Fedora Project wiki.

At the 2006 JavaOne conference, Sun announced plans to open source Java. This wasn’t exactly a surprise to those of us working on Java at Red Hat, given that there had been rumblings before. But this was a real announcement. We were immediately interested in learning exactly which license Sun would choose. Even if it was a legitimate open source license, it still might not allow us to combine our code with Sun’s.

We have been working on free Java for many years–most particularly through gcj, a project started at Cygnus in 1998 by a developer named Per Bothner. Gcj has been steadily improving over the years, but still wasn’t fully Java-compatible, partly because we couldn’t get permission to run the official Java compatibility test suite. We had also been working on GNU Classpath, which is GNU’s free replacement for the core Java class libraries from Sun. We were very curious to see the “official version.”

We were thrilled to hear Sun announce in November 2006 that it had selected the exact same license as GNU Classpath.

When the complete Java source code–now called OpenJDK–was released on May 9, 2007, there were a few challenges. Most notably, some of the code was missing. Over the years, Sun had licensed Java libraries from a variety of sources, some of which would not allow their code to be open sourced. In order to work with this encumbered code, Sun provided some “binary plugs” that were copied into the build. This presented a problem as Fedora’s rules don’t allow the inclusion of anything that isn’t open source. It’s hard for us to maintain confidence in code we can’t see.

We were 95 percent of the way to a truly free Java. The way to fill that last five percent became clear: use the code from GNU Classpath. We later discovered that one of the reasons Sun selected the Classpath license was so that they could work with the Classpath developers and the Linux distributions that already used GNU Classpath. This was a great vote of confidence.

We needed to start a project to combine OpenJDK with the GNU Classpath code. This project could have been hosted within Red Hat, but we didn’t want this to be seen as Red Hat only. Classpath came to the rescue and Mark Wielaard, GNU Classpath maintainer, set up the IcedTea project. This is the repository for the totally free version of OpenJDK.

Bootstrapping was another not-so-obvious problem. Much of OpenJDK is written in Java. Sun built the first release of OpenJDK with its unfree Java. Fedora, however, doesn’t allow packages to depend on any unfree software. This time, it was gcj that came to the rescue. Since gcj is completely free software, we could use it to build OpenJDK. This also ensured that unfree code couldn’t “leak” into our OpenJDK package during the build process.

Over the next few weeks, a team within Red Hat worked vigilantly to create the OpenJDK and GNU Classpath hybrid that was to become IcedTea. Less than a month after we received the OpenJDK source code, we were able to release IcedTea 1.0. In a few cases, we had to create non-functional stubs for code we didn’t have, but the result was good enough to run many of the Java applications in Fedora. Since then, Sun has created replacements for many of the binary plugs and we have gradually been able to remove much of the GNU Classpath code.

The OpenJDK that Sun released only ran on i386 and AMD-64 machines. Fedora runs on other systems, in particular those based on the PowerPC. To solve this problem, we started an IcedTea porting project. That project produced an interpreter-only OpenJDK port for the PowerPC, based on Sun’s C++ interpreter. This later became Zero, a truly portable “zero assembler” version. As you might expect, a pure interpreter is not as fast as the high-performance JIT (Just In Time) compilers often used in Java implementations, but we’re working on that.

The OpenJDK code that Sun released was a preview of Java SE Version 7 rather than an implementation of Version 6. Java SE Version 7 has not yet been released and neither has its specification, so IcedTea cannot officially be certified as compatible with anything. Despite this, it works so well that we shipped it with Fedora 8.

Though it is not officially part of the Java platform, for many Fedora users the Java web browser plugin is essential to a complete desktop experience. Sun did not open source its Java plugin with OpenJDK, presenting another opportunity to utilize IcedTea. GNU Classpath includes a Java plugin named, for historical reasons, gcjwebplugin. By adapting Sun’s applet viewer code slightly, we were able to integrate gcjwebplugin into IcedTea to provide a working Java plugin. This plugin was released as part of Fedora 8, and is installed by default on both x86 and x86-64. This was the first time a 64-bit Java plugin had been available to Fedora users; unfree Java plugins are 32-bit only.

The plugin is closely related to the other Java deployment technology, Java Web Start, which also currently lacks an open source replacement. We’re working on IcedTea to complete the support for both the plugin and Java Web Start. We’ve integrated and extended NetX, an open source web start implementation; it is now nearing release-readiness for Fedora. We’re making good progress on gcjwebplugin’s two missing features: a LiveConnect Java/JavaScript bridge and signed applet verification. Future Fedora releases will boast increasingly better integration of these Java deployment technologies.

After the release of Fedora 8, the lack of an open source version of Java SE Version 6 became more of a problem. Developers were using IcedTea on Fedora, but as it was a preview of Version 7, there was a risk that people might rely on libraries and interfaces that would change when Version 7 was released. Sun started an OpenJDK 6 project, which took the OpenJDK 7 code base and made the changes necessary for it to be compatible with Version 6. We immediately realized that this would be far more useful to Fedora users and developers.. After some discussion, we decided to base the next Fedora’s OpenJDK on the Java 6 code.

At the same time, Sun decided to allow Fedora to use its OpenJDK trademark for IcedTea. This makes perfect sense as there are now so few binary plugs needed to build OpenJDK that it’s a distinction without a real difference from a user’s point of view. Fedora 9’s package is now called OpenJDK, not IcedTea, and it is based on OpenJDK 6.

We have also been permitted to run the official Java SE Compatibility test suite on OpenJDK. This test suite has a crucial role in Java: to be called Java-compatible, an implementation must pass every one of tens of thousands of tests. Simply running this test suite is a huge effort. We still fail some tests, so our OpenJDK package cannot yet claim to be Java compatible, but we are working on it. Watch this space. When we pass the last few tests, we will finally be able to say “Java is free!”