Here’s the final installment of Bill Nottingham’s series based on the talk he gave at this year’s Red Hat Summit. Find out about the latest and greatest Fedora™ developments… and the future of Red Hat® Enterprise Linux® from this experienced engineer. Missed the first part? Catch up in the archives.
Network handling
Another area that’s shown a lot of improvement since Enterprise Linux 5 is networking, especially for desktop and laptop computers. In Fedora 9, we’ve greatly enhanced NetworkManager, and as a result, have switched to NetworkManager by default for all installs. Some of the features we’ve added to NetworkManager include:
- MobileBroadband support - NetworkManager now supports configuring access via GSM and CDMA cards for even greater connectivity options.
- System configuration support - NetworkManager now reads my system configuration , as configured via anaconda or system-config-network. This allows support for things such as static IPs.
- Multiple device support - NetworkManager will automatically connect to both wireless and wired devices simultaneously. This means that if I disconnect the wired device, I’ll have seamless access through my wireless device, instead of having to wait for it to associate and get an IP address.
- Connection editing - NetworkManager also includes a connection editor. With this, I can easily configure my wireless network, my mobile broadband connection, or even 802.1x for my wired connection.
From the application side, we’re working on getting more and more apps tied into the NetworkManager infrastructure so they will automatically adapt to changing networks. For example, Firefox in Fedora 9 will now automatically go into offline mode if the network goes away, and go back online as soon as it returns.
In the future, we’re looking at extending NetworkManager to support Ipv6, as well as more device types (such as bridging and bonding devices).
Encrypted devices
One of the most requested features since the release of Enterprise Linux 5 is encrypted device support. We support encrypted devices via a technology called LUKS. LUKS, implemented on top of the existing device-mapper cryptography code, standardizes the partition header for the automatic detection of encrypted devices. It also allows for multiple passphrases to decrypt the device. For example, if I insert an encrypted USB stick, the encrypted device is detected via HAL, the GNOME file manager prompts me for the passphrase, and LUKS unlocks the device–which is then mounted and ready to use.
Fedora 9 goes even further: We support encrypting the entire system in the installer if the user desires. Anaconda will prompt for a password for physical devices, and then on boot, you’ll be prompted for that password before proceeding.
Audio handling
The addition of PulseAudio has greatly improved the audio subsystem in Fedora 9. PulseAudio is a networked sound server, used for mixing and playing audio streams on the system. Now, some of you might remember ESD, and wonder why we need another sound server. Simply put, the power and flexibility provided by PulseAudio is far beyond what ESD ever did.
For example, with PulseAudio I can easily adjust the volume of the audio streams individually. If I’m listening to music and I get a SIP call via ekiga, I can mute the music.
PulseAudio abstracts away your hardware devices as well. Say I decide to plug in a USB headset. I can then move any (or all) of my audio streams to that headset, while they’re playing. If I remove the headset, the audio streams are automatically moved back to the remaining device.
We’re working to use PulseAudio natively by all the applications shipped in Fedora and Enterprise Linux, and also use PulseAudio’s network support as a potential means for doing virtualized audio.
User switching and constrained users
Say I’m using my computer. My daughter comes up and says she wants to check her mail. In Fedora, we’ve made it easy for you to switch between users. When I log in, I see my user name on the panel. If I click there, my session is locked and a new login window will launch. From that window, I can select a different user. When this user logs out, I’ll automatically be switched back to my session.
If you notice, there’s a ‘Guest’ entry in the user list. The simple listing belies what’s available–this account is more than just an login named ‘guest’. Through cooperation between the Desktop and the SELinux teams, we’ve introduced a technology called ‘xguest.’
XGuest is a restricted kiosk-type user. I can log in as the guest user with no password. The guest user is specially confined via SELinux and only certain actions are allowed. For example, the only way to get out on the network is via the browser. Furthermore, on logout, any changes, customizations, or data saved by the guest user is thrown away so the next user will start with a clean slate (and guests can do little permanent damage). For example, I can change the background of the desktop. The next time I log in as the guest user, it will be reset to normal.
Virtual file systems
Another feature that was added in Fedora 9 is something called GVFS. GVFS is a userspace-based virtual filesystem. It replaces gnome-vfs in GNOME, adding many new features.
Let’s look at an example. One of the backends for GVFS is an archive mounter. I can enter and examine an archive–such as an ISO image or a tarball of source code– via the file manager by simply right-clicking and choosing ‘Open with Archive mounter.’ Once it’s open, I can navigate and open items with standard GNOME tools. Anything mounted with gvfs will also show up both in the GNOME ‘Places’ menu, and in the file chooser.
GVFS adds a new feature that makes it even more useful. Leveraging the power of FUSE userspace filesystems, anything mounted by GVFS is also exposed to your ’standard’ Linux tools under ~/.gvfs. I can navigate into it with a shell, and read/write files to these locations without actually porting your apps to GVFS.
GVFS has back-ends for archive mounting, Samba/CIFS shares, DAV shares, sftp network mounts, OBEX (for talking to your bluetooth phone), and more. In future releases, we plan on extending the backends available for GVFS, and porting more of the desktop stack to use it natively.
Virtualization
If you’ve been around any sort of technical presentation in the past two years, you’ve certainly heard about virtualization. That’s another area we’re working on improving in Fedora, although a lot of that improvement is done under the covers. For example, if I start virt-manager now, it looks much the same as it does under Red Hat Enterprise Linux 5.
However, the virtualization hypervisor has changed from Xen to KVM. KVM offers many benefits over Xen:
- KVM uses the standard kernel
Xen runs as a hypervisor that requires a modified kernel underneath. Since it runs a (somewhat) non-standard kernel, it can lead to compatibility problems, especially for anything that has to call into, or use, the BIOS. For example, power management has had problems working under Xen, and console redirection and handling was often an interesting exercise., as anyone who’s used a serial console will tell you. By using the standard kernel, KVM allows full hardware compatibility–whatever works in the standard kernel, works in your virtualized host.
- KVM is in the upstream kernel
KVM has been accepted into the upstream Linux kernel. This is a great step for virtualization, in that it will now always be available, and won’t need continual porting to newer kernels. As anyone who has followed Fedora knows, attempting to maintain the Xen kernel patchset against the upstream kernel is a large amount of work. Working in the upstream obviates the need for that effort, allowing work to be done on improving the virtualization experience rather than chasing the kernel of the day.
But wait, you say… what about my paravirtualized guests? We’ve got you covered. Fedora 9 introduces new technology called Xenner. Xenner emulates the Xen hypervisor interface as a thin layer on top of KVM.
This shows the power of our virtualization strategy–by abstracting the interfaces away via tools like libvirt and virt-manager, we can change out the virtualization hypervisor, yet still present the same interface to the user and administrator, and run the same guests.
And more…
There’s even more where this comes from–new versions of Firefox, new firewire stacks, and more. If you want to know what’s down the road for Red Hat Enterprise Linux, check out Fedora 9– that’s where the innovation happens.
About the author
Bill Nottingham is an engineer at Red Hat, where he’s worked on Red Hat Linux, Red Hat Enterprise Linux, and Fedora for the past ten years. (yipes!) He currently serves on the Fedora Project Board and the Fedora Engineering Steering Committee, and maintains a variety of packages in Fedora.













0 Responses to “What?s next in Red Hat Enterprise Linux (part 2)”
Leave a Reply
You must login to post a comment.