Monthly Archives: November 2010

Top Five Linux Deployment Mistakes

The days when Linux is an unknown quantity in a business are largely over — but that doesn’t mean that every organization has tons of experience deploying Linux. Even if your organization has deployed Linux before, there are some common mistakes to be aware of. Here’s five things you need to watch for when planning a new Linux deployment.

Too Much, Too Fast

Any deployment should start with a small test deployment if at all possible. Whether you’re using Linux as a server or desktop/workstation system, or both, trying to roll out Linux to the entire organization (unless it’s a very small shop) can be a recipe for trouble.

For mission critical server systems, you need to make sure that you can handle peak loads and ensure uptime. This means doing extensive load testing before you deploy Linux servers to see whether you need heftier hardware, configuration changes, etc.

For user systems, you need to make sure that there are no unpleasant surprises when the systems are put in front of real users who aren’t already Linux experts. A Linux desktop may seem simple as pie for the IT department, but even a minor interface change can befuddle less experienced users.

Start small, and find out what (if anything) needs to be changed before going for a full deployment.

Interoperability Hazards

As much as some might prefer otherwise, it’s a Windows-friendly world out there. The good news is that Linux plays well with others. The bad news is that Windows doesn’t.

Part of any test deployment should not only focus on the new systems, but the interaction between the new and old. Can your Windows users access the Linux systems seamlessly? If you’re deploying Linux desktops, can you get to Windows file shares or make appropriate use of other user-facing services that have traditionally been accessed via Windows?

Any situation that calls for two or more operating systems to be in the same environment means you need to worry about interoperability. That leads to the next common mistake…

Authentication Silos

The new Linux systems are running great, users love them, management is thrilled — except for the part about having to maintain one set of user credentials for Windows systems under Active Directory, and another set of credentials for Linux.

This goes along with interoperability — make sure that your organization can deliver Single Sign-On (SSO). Whether that means setting up LDAP for the entire organization, or configuring your Linux systems to work with Microsoft’s Active Directory, don’t burden your users with two (or more) sets of credentials to do their job.

Out with the Old, In with the New

You’ve heard the phrase “if it’s not broken, don’t fix it”? That really applies when it comes to IT projects. One of the biggest mistakes that IT can make when it comes to Linux (or, honestly, any solution) is to let enthusiasm for a new platform or solution lead to unnecessary disruption.

In this case, that means replacing existing infrastructure that works with something new. Many organizations suffer with Microsoft Exchange, for example. If users and management want to kick Exchange to the curb, then do so — but if the users in the organization are by and large happy with Exchange, then leave it in place unless there’s a compelling reason to move to something new.

This doesn’t mean that your organization should be trapped on a legacy platform forever, of course. At some point, support for Windows XP ends. At some point, you have to replace the legacy UNIX systems that go out of support. That’s typically the best time to make a break, but rip and replace just to deploy a Linux/FOSS solution — when there’s a well-functioning system in place — is a bad idea.

Document, Document, Document

It’s not enough to deploy a solid solution that you, or the existing team, understand. You have to plan for vacations, career changes, and other contingencies that mean someone else will have to administer the systems you’ve tended.

This means that when systems are set up, you need to document what you’ve done, how you’ve done it, etc. If you’ve had the experience of trying to maintain legacy systems that will be replaced with Linux, you’ve no doubt faced installations that are baffling because the previous admin or admin team set up a custom system — with absolutely no or very minimal documentation.

Make sure that part of any Linux deployment (or any deployment, really) is adequate documentation of the system from top to bottom. Anything that a replacement admin would need to know to update the system, add users, configure services, etc. should be well-documented. If this is documented elsewhere (e.g. online documentation from the vendor) make sure that you have pointers to the external docs. Better yet, make a local copy in case the online docs change, are moved, or disappear altogether.


Most of the above should be common sense — yet many organizations make some, if not all, of these mistakes when deploying Linux. With a bit of careful planning, though, you can avoid all of these.

Have other deployment mistakes we should be aware of? Let us know in the comments!


Announcing the release of Fedora 14

It’s here!  It’s here!  It’s really here!  Fedora 14 has been officially released! Fedora is a leading edge, free and open source operating system that continues to deliver innovative features to many users, with a new release approximately every six months.

Fedora 14, codename Laughlin, is now available for download.  Join us and share the joy of free software and the community with friends and family.

We know you can’t wait to get started with Fedora 14, so simply follow this link to download it today:

If you want a quick tour of highlights in this release, check out:

For more information including common and known bugs, and tips on how to report bugs, please refer to the release notes:

You can also find this announcement text at:

=== What’s New in Fedora 14? ===

==== For desktop users ====
A universe of new features for end users:

  • libjpeg-turbo:  Users can load and save images faster in Fedora 14 than in previous releases.
  • Spice: Spice (Simple Protocol for Independent Computing Environments) provides users with an enhanced remote desktop experience. Currently, it provides the rudimentary foundation to take advantage of things like Accelerated 2D graphics, encryption, and hardware cursor support.

==== For developers ====
For developers there are all sorts of additional goodies:

  • D: Fedora 14 introduces support for D, a systems programming language combining the power and high performance of C and C++ with the programmer productivity of modern languages such as Ruby and Python.
  • Python 2 upgrade: The system python 2 stack has been upgraded to 2.7.
  • GNUStep: A GUI framework based of the Objective-C programming language which is part of the gcc.
  • Memory Debugging Tools: The new “gdb-heap” package adds a new “heap” command to /usr/bin/gdb which allows you to get a breakdown of how a process is using dynamic memory.
  • Rakudo Star: An implementation of Perl version 6, based on the Parrot VM.
  • Support for Milkymist: Developers can enjoy developing for Milkymist, an open hardware embedded board, on Fedora 14. Thanks to the Fedora Electronic Lab for their work in this regard.

==== For system administrators ====
And don’t think we forgot about the system administrators:

  • Fedora is now available for users of the Amazon Elastic Computing Cloud service, released concurrently with the traditional release.
  • virt-v2v assists in the easy migration of Xen virtual machines to KVM virtual machines.
  • A Virtualization Technology Preview Repo allows users to test the very latest developments in virtualization related packages.
  • Varnish has been updated and includes improved scalability and a new log function.
  • Apache has been updated and includes a number of module and security fixes.

And that’s only the beginning. Updated versions of many packages, as usual, will be available in Fedora 14. A more complete list with more details of the new features on board Fedora 14 is available at:

OK, so what are you waiting for?  Go download it!  You know you can’t wait.

If you are upgrading from a previous release of Fedora, refer to

In particular, Fedora has made preupgrade a more robust solution and pushed several bug fixes to older releases of Fedora to enable an easy upgrade to Fedora 14.

Fedora 14 full release notes and guides for several languages are available at:

Fedora 14 common bugs are documented at:

=== Fedora Spins ===

Fedora spins are alternate version of Fedora, tailored for various types of users via hand-picked application set or customizations. They can be found at:

== Contributing Back to Fedora ==

There are many ways to contribute beyond bug reporting.  You can help translate software and content, test and give feedback on software updates, write and edit documentation, design and do artwork, help with all sorts of promotional activities, and package free software for use by millions of Fedora users worldwide.  To get started, visit today!

== Fedora 15 ==

Even as we continue to provide updates with enhancements and bug fixes to improve the Fedora 14 experience, our next release, Fedora 15, is already being developed in parallel, and has been open for active development for several months already. We have an early schedule for an end of April 2011 release:

== Contact information ==

If you are a journalist or reporter, you can find additional information at:

Jared Smith
Fedora Project Leader