The Official Ubuntu Server Book provides everything you need to know about the Ubuntu Server. Whether you are an experienced user or new to the system, co-authors Kyle Rankin and Benjamin Mako Hill teach you all about the ins and outs of the Ubuntu operating system. Readers of the The Official Ubuntu Server Book will learn about installation, navigation, package management, security, virtualization, troubleshooting and more! Rankin...
and Hill provide step-by-step instructions and in-depth analysis to ensure readers fully understand what the Ubuntu Server provides. The publisher has made a free download of Chapter 3: Package Management available for preview.
I asked Kyle Rankin a few questions to learn more about the ideas and expert experiences behind The Official Ubuntu Server Book.
With all of the other Ubuntu server books on the market, what inspired you to write The Official Ubuntu Server Book? What sets your book apart from the others?
One of the big differences with The Official Ubuntu Server Book is that it continues in the tradition of The Official Ubuntu Book and Ubuntu itself by being very accessible while still being comprehensive. Ubuntu has added many great tools to make server administration easy, and we wanted the book to both guide new system administrator into how to use Ubuntu as well as show veterans more effective ways to use the system. Another big difference with this book is that we worked very closely with the Ubuntu server team. That really helped since we wanted to cover both the LTS as well as any new exciting features in the latest release.
How did you and co-author Benjamin Mako Hill collaborate to decide who would write what? Do you each have an area of expertise or was it a joint effort all the way through?
We basically divided up sections of the book according to expertise and what worked best with our schedules, but of course we both reviewed what each other wrote and collaborated on the overall focus and audience for the book.
A few book reviews have claimed this book is extremely helpful and easy to use however it is aimed towards beginners and doesn't really give a lot of information for the more advanced Ubuntu user. Was the target audience a beginner Ubuntu user? Do you have any plans to write more advanced Ubuntu books in the future?
We really had two main audiences in mind for the book. The first, the beginning systems administrator you already mentioned, and we wanted to make sure that even when we talked about advanced topics, we did so with language that was accessible even to beginners. The second group we aimed for was the experienced system administrator, particularly one that has used Linux for some time but might be new to Ubuntu. If you are used to, for instance, Red Hat as a server and try out Ubuntu Server, you'll find that everything seems to be in a different place. We wanted to give those admins a straightforward guide to how Ubuntu organizes files as well as perhaps convince them that the "Ubuntu way" of server administration is something that will save them time. I've seen too many administrators who are set in their ways and, for instance, insist on compiling everything themselves or doing every task by hand. I hope this book will convince some of them to learn a few new tricks.
In a book with a scope like this one - covering an entire server distribution - you have to make some hard choices about how deep to go in each area. I personally have never liked books that fluff up their page count by essentially pasting in manual pages. If you take the chapter on basic Ubuntu services, for instance, we talk about how to set up some common Linux servers in Ubuntu and introduce how Ubuntu organizes Apache, MySQL, Postgres, BIND, Samba, and a number of other services. You'll find entire books on any one of these services that goes in depth so obviously it wasn't feasible to cover all the features and options for each server. That beeing said, I could see adding a few more advanced examples in a future revision.
In chapter three, "Package Management," you mention that packaging is usually done by distributions such as Ubuntu. However, users of distributions and software vendors can also create packages. Can you explain why a user or vendor would create a package instead of letting distributions do the work?
Generally speaking I advocate that users stick with distribution packages whenever possible. When you manage any significant amount of servers one of the most valuable things you can have is consistency and stability. The moment you build your own package, you lose many of the advantages you get when hundreds or thousands of people are hammering away on the same exact package. But, sometimes a system administrator might want either a cutting edge version of a program that hasn't been packaged yet or wants to add custom features that don't exist in the standard package. While that can be risky, it is one reason why people build their own packages. A less risky reason is if you have your own set of custom scripts or programs that you want to deploy. While many administrators might just copy scripts to servers by hand, if you build them into a package you can take advantage of the packaging infrastructure you already have in place which makes revision tracking, automated deployment, and a number of other things easier.
You mention in chapter three that upgrades and new versions of packages can be found in the /etc/apt/sources.list on the Ubuntu server. Are there any risks involved in upgrading such as losing packages that were built from scratch? Also, will Ubuntu continue to support older versions of packages or will a user be forced to upgrade?
I would say that the safest upgrade path is from one release to the immediate next release, as that's the distribution upgrade that gets the most testing. If, for instance, you run 8.04 and want to move to 9.04, probably the safest way to do so is to make 8.04 completely up to date first, then move to 8.10, then 9.04.
Whether or not upgrades will clobber your custom packages really has to do with how well you set up your custom package dependencies and versioning. After all, if you built your own Apache package and the next version of Ubuntu has a newer version, the package manager might install it over the top of yours if you named it the same and didn't manage the versions well. This is yet another reason I advocate that people try to stick to distribution packages whenever they can - why duplicate the headaches the package maintainer has to deal with?
In your opinion, what is the future of package management? Do you see packaging software as a young breakthrough where people should really jump onboard or do you believe that package management, although still useful now, is just waiting to be replaced by the next best thing?
I think even with all of the advocacy for programs like cfengine and Puppet to deploy software, that traditional package management is still the most mature approach. Dpkg has been around for a long time and a lot of the kinks such as automatic dependency management has been handled long ago with systems such as APT. It's funny when you notice all of these "app stores" out there these days and realize you've had the same thing on Linux for many years.
Kyle Rankin is co-author, with Benjamin Mako Hill, of The Official Ubuntu Server Book, published by Prentice Hall Professional, ISBN 0137021186, June 2009, Copyright 2009 Canonical, Ltd. For a free sample chapter please visit the publisher site at informit.com.
Greg Smith is an editorial coop at Tech Target. Greg attends Northeastern University studying for his bachelor's degree in Journalism.