Migrating to FreeBSD
| At the time of this writing, and as accurately as these things can be measured (which is to say, not very), FreeBSD has approximately 10 percent of the open-source UNIX Internet server market. The rest of that market is almost all Linux, with the remainder comprised of NetBSD, OpenBSD, and a few other little-known variants. In the wider server market, Windows 2000/XP/Server 20003 claims about a 30-percent share (and remaining steady), with UNIX/Linuxboth commercial and open-sourceestimated at about 60 percent. By any measure, this means FreeBSD is not an especially large player. However, market share alone does not dictate the quality of a piece of software, as anyone reading this book likely knows. FreeBSD usage, while perhaps not growing as rapidly as in the past, is at least holding firm. A steady stream of Linux-based and commercial UNIX-based businesses are moving to support FreeBSD for its stability and its performance, desiring an open-source solution that's free of the distribution politics of Linux (which is true because of its natureFreeBSD is a complete operating system, whereas Linux is simply a kernel). Stories also abound of high-profile, web-based services running on FreeBSD simply because it is the only solution that can handle the load (the services' parent companies' own operating systems notwithstanding). The end result is a healthy and long-lived respect for FreeBSD in the server community, and a general desire to move toward its tempting mixture of stability, standards compliance, openness, and power. Migration away from Windows or Linux means a trade-off of two features: software availability and established practices. These two factors are the largest stumbling blocks typically faced by seasoned server veterans eyeing FreeBSD for the first timethe former applying more significantly to Windows (because more and more Linux programs are being ported to FreeBSD); the latter applying to both. The following sections look at both these migration paths in turn and address the barriers. Migrating from WindowsIf you're switching to FreeBSD from a Windows server platform, the problems you are most likely to face involve not just what software is available, but a number of fundamental differences in how the computer is used. The topological role a Windows server plays in a network is quite different from that of a FreeBSD server. Windows is almost exclusively GUI-based, without a mature or widely used remote administration method comparable to the tried-and-true command-line shell of UNIX. Even the built-in Terminal Services in recent versions of Windows have their practical limitations and technical quirks that don't affect the minimalist command line. This means that to use a Windows server effectively, you usually need to be physically sitting at the machine. Getting used to a command-line interface to do your work can be a daunting task, but it's crucial to UNIX systems' great advantage of remote accessibility. In this section of the chapter, you learn that setting up a FreeBSD server to provide certain common services involves much less commercial software, licensing, and client/server installation than is required to set up other servers. You learn about migrating client/server applications to the FreeBSD system, and you learn information about some of the important differences between maintaining security in FreeBSD and in Windows. An important part of ensuring a secure server is keeping your operating system up to date; later in this section, you learn how to keep your FreeBSD system current with the latest developments. Of course, one big difference you'll notice when you migrate from Windows to FreeBSD is the change in software availability, licensing, and registration. When you move to FreeBSD, you deal with free and open-source software packages that you compile yourself, with support coming from grassroots Internet sources or third-party support services rather than from large software vendors. Note Built-in and third-party components of Windows are gradually increasing the remote accessibility of the platform. These days, you can manage services remotely that are controlled through the Services control panel, and various methods exist to acquire a DOS command line on the server machine. However, these are both subsets of the complete functionality of a systemthey're limited to the functionality explicitly built in to the control mechanism you're using. Complete configurability of installed server software often relies on administrative client programs, as we'll discuss next. Client/Server ApplicationsMost enterprise software for Windows servers is developed on a model in which you install the server portion physically (generally from CD). In this model, you then install an administrative portiona clienton your desktop machine as well as on the machine of anyone else who will be administering the server. Terminal services are available in modern versions of Windows, which allow you to directly control the server machine itself from a remote location; but due to the intensely graphical Windows GUI and a variety of technical quirks in the available software, these tools are not simple or elegant to use. You must accept a major philosophical shift when moving to UNIX. There are virtually no specialized client/server applications for FreeBSD that are comparable to the groupware, calendaring, or network management utilities on Windows. Their number, however, is growingmostly due to the increase in popularity of web-based administration interfaces, such as the configuration utilities for third-party applications like the CUPS printing system and the Mailman mailing list server. These utilities are usually intended only to be run at a local console because of security concerns (configuration utilities generally have to be run as root, and you don't want any web utility running as root to be accessible from just anywhere on the network). In any case, these web-based administration systems are usually just convenient add-ons; there's always a command-line version of every administration utility, because by far the favored mechanism for administering any part of UNIX is the command line accessed from a remote terminal. SSH (or the unencrypted Telnet, as a recourse) is the dominant all-purpose tool for doing anything in the UNIX world. Technologically, using Telnet is one of the most efficient and streamlined methods imaginable for working with the serverall you're sending and receiving is text. It's also the most versatile method, giving you much wider access to the server's operations than any graphical tool could because you're free to type any command you want at the command line, rather than being limited to the specific controls written into a GUI tool. Naturally, though, this also means you have more power to break things. It's a trade-off: the ease of use, safety, and directed functionality of Windows client/server software for the versatility, risk, and esoterica of terminal-based administration. SecurityWhole books have been written on the Windows 2000/XP/Server 2003 security model, and the topic is well beyond the scope of this chapter. However, if you're used to the Windows style of users, domains, and permissions and you're moving to FreeBSD, there are a few things you'll want to know that will help you keep your security model roughly intact. The "root" account is the equivalent of "Administrator." That is hardly a secret. However, beyond that there are a few things you can do to keep your services running with their accustomed privileges and to give your trusted administrators exactly as much power as they needand no more. The first step is to know what some of the fundamental differences are between the Windows and FreeBSD security models:
Windows bills itself as being easier to use and to make secure than UNIX. The number of necessary security certification courses for Windows administrators and engineers suggests that this is not universally true. Windows is potentially easier to make insecure through misconfigurations that are done with the best of intentions. Although this is also possible in FreeBSD, historical data shows that it is less common. FreeBSD may suffer fewer security flaws resulting from misconfiguration because UNIX is structured to encourage tighter security by default as a result of actions a new user might take. The large amount of concise and useful information available online for securing UNIX systems certainly contributes to stronger security, as well. An excellent resource for such information is the SANS (System Administration, Networking, and Security) Institute, found at http://www.sans.org. Software EquivalencyTable 21.1 lists some of the commonly used software on Windows servers and what the equivalents would be under FreeBSD.
It's worth pointing out that in the Windows world, unwanted interactions between different pieces of server software are often such a risk that enterprises typically will not run more than one critical service on the same machine. These networks have a dedicated mail server, a dedicated web server, a dedicated name serverall different machines. The open-source UNIX community doesn't subscribe as commonly to that philosophy for two reasons:
You may or may not choose to follow the UNIX method, and you might not want to risk running all your network's critical services on a single machine. If you do, however, you can generally feel more at ease and operate more efficiently running multiple critical services on the same server than you could if it were a Windows machine. Note A practice rapidly rising in popularity is virtualization, or multiple concurrent operating system instances running on the same hardware and shielded from interfering with each other. VMWare is a popular commercial virtualization package; and Xen (http://www.xen.com) is a virtualization monitor package built into FreeBSD as of the 6.1 release. Keeping Up to DateMicrosoft provides system updates through service packs. These large collections of software revisions and binary patches appear every six months or so. Quicker responses (for instance, in response to security bulletins) come in the form of binary hotfixesupdates and patches that can be downloaded from Microsoft's website through the Windows Update mechanism. FreeBSD's method of keeping current can be a lot more complex than Microsoft's, but once it's understood, this method also can be easier and more effective. FreeBSD places a lot of emphasis on being available in source form for you to track if you like, keeping a local copy of the entire source tree synchronized at whatever frequency you choose. The CVSup tool makes this process both automatable and easy on bandwidth resources. The recommended practice on FreeBSD is to keep a local copy of the source code for the release version of FreeBSD that you have installed, as a substrate for source patches, and to synchronize it regularly to the errata fix branch for that release, which keeps it in line with every new change checked in for a security vulnerability or a bug fix. Refer to Chapter 19, "Keeping Up to Date with FreeBSD," for more about using CVSup and how the errata fix branches are structured. Any security bulletin that is sent out by the FreeBSD Security Officer contains a source patch or similar way to fix a particular problem. Line-by-line instructions are provided; all you really have to do is copy them verbatim to the command line, and often you don't even need to reboot after you're done. You can, if you choose, keep your system completely cutting-edge by rebuilding the entire thing from scratch, from your synchronized sources, however often you like. This process is known as make world and is covered in detail in Chapter 19. This is probably not something you need to do as a newcomer to the FreeBSD world. Rebuilding the system might prove useful later, however, as you build up experience and want to work with the very latest state of the system. For now, though, use Chapter 19 as a reference for synchronizing your sources to the proper errata fix branch for your FreeBSD release so you can apply security patches and keep your system fresh. Caution It's always a good idea to keep a "backup" machine as a mirrored copy of your "live" machine. If you must do cutting-edge synchronization and use the newest code, do it on the backup machine first before applying the same changes to the live machine. Migrating from LinuxFreeBSD is much more similar to Linux than to Windows, and in many ways is functionally identical, even though Linux shares no actual code with FreeBSD. FreeBSD and Linux are both derived from the same UNIX tradition, they're both open-source, and their security models follow the same rules. The same third-party software (for the most part, especially if you take into account FreeBSD's Linux binary compatibility) is available for both platforms. The same kinds of system administration problems occur on both platforms, and the same kinds of solutions tend to work as well. Migration difficulties from Linux to FreeBSD are much more technological than philosophical, and so this section will go into more administrative detail than the section on migrating from Windows. Functional differences between Linux and FreeBSD can be boiled down to a few basic areas:
Where Everything in the System Can Be FoundThe most important thing to remember about FreeBSD should be a mantra by now: Everything that you install goes into the /usr/local subtree. FreeBSD maintains this model very carefully to prevent pollution of core system areas (/usr/bin, /var/lib, and so on). Table 21.2 lists a few common locations for the resources you'll need, but bear in mind that the Linux locations might vary from distribution to distribution.
Caution Some ports aren't as well behaved as others. Beware of ports that install components into areas outside /usr/local, as some such ports do exist. Some of these resource locations differ because of the differences between the RPM method (the widely used Linux package manager) and the FreeBSD ports/packages method of software installation. Other location differences exist because of differences in the core system layout. Linux typically has more of a "System V" structure, whereas FreeBSD is more, well, BSD-like. Refer to Chapter 16 for a fuller discussion of how ports and packages work under FreeBSD. Partitions and Filesystem TypesThe Linux bootloader architecture takes a very DOS-like approach to disk partitioning: There are four primary BIOS partitions, one of which can be made into an "extended partition" with multiple "logical" partitions inside it. These partitions all appear on the same "level" to the user, even though the structure is, in fact, hierarchical. The system can be booted only from a nonextended partition, thus leading to a lot of potential confusion. FreeBSD's hierarchical partition structure is much more overt. BIOS partitions are called slices, subpartitions are called partitions or BSD partitions, and the boot process handles the different levels explicitly (each with its own boot block code) in order to remove the mystery associated with extended and primary partitions. Setting up a disk involves first slicing the disk and then partitioning each slice. This process is described in detail in Chapter 20, "Adding Hard Disk Storage." FreeBSD's native filesystem is UFS/FFS. You can use your Linux disks under FreeBSD without modification, but FreeBSD needs to load a kernel module to support Ext2FS; if you need to use Linux disks regularly, you will want to recompile the FreeBSD kernel to add Ext2FS support and remove the need to load that kernel module dynamically every time. See Chapter 18, "Kernel Configuration," for instructions on how to enable this option and build yourself a new kernel. Ports and PackagesComing from a Linux background, you may be used to installing software through the RPM utility. This is not widely used or recommended in FreeBSD. In fact, you can seriously damage your system by installing incompatible libraries into places such as /usr/lib, although it is possible to do if you really need to. The preferred method of installing and maintaining software in FreeBSD is through the package tools (pkg_*) or the ports. Chapter 16 offers a full explanation of ports and packages, but some aspects of how they work in FreeBSD are especially important to users migrating from Linux. Packages and ports provide a centralized filtering mechanism to tweak the build and installation options of software written for Linux so that it will compile properly under FreeBSD and install into the prescribed locations for user-installed materials. Ports and packages travel through the FreeBSD committers and the central download sites, rather than being available directly from the software developers themselves. This helps keep a FreeBSD system neat and tidy. Keeping in SyncFreeBSD is more "source centric" than Linux; because there is effectively only one "distribution" of the operating system, the entire installation is directly available in source form. The Linux world doesn't do this as effectively. Each distribution has its own structure and its own software selections. The Linux kernel itself is the only source subtree that you can be sure is the same as another Linux user'sand even the kernel can be patched differently depending on the distribution. Different distributions have different philosophies toward making the rest of their source trees available for automatic download, synchronization, and building. FreeBSD provides tools and infrastructure to accomplish these tasks across the board. This means that to keep synchronized with the latest development code, all you have to do in FreeBSD is to track the sources using CVSup, as described in Chapter 19. Security patches and hotfixes (available in Linux variously as RPMs, source patches, or binary patches) are distributed in FreeBSD both in source patch form and by checking in fixes to the central source tree. You can update your system in response to a security bulletin either by following the line-by-line patch instructions in the bulletin or by simply making sure your source tree is synchronized to your appropriate errata fix branch at a point after the fix has been made and then rebuilding that part of the system. Caution Patching system components without rebuilding the entire operating system is a method that usually works (especially for small, noncritical elements of the system), but not always. The more fundamental to the system's operation a component is, the more likely it is that you will need to do a complete make world in order to upgrade properly. Such fundamental areas of the system usually include the central libraries (items in /usr/lib) or headers (in /usr/include). Less-risky areas are the supporting binaries, in /usr/bin and /usr/sbin. Working with Master Password FilesLinux and FreeBSD both use shadow passwords, a method of storing encrypted password strings in a file readable only by root (see "The /etc/passwd and /etc/master.passwd Files" in Chapter 13). However, whereas FreeBSD maintains an /etc/master.passwd file that contains all user data, with /etc/passwd being simply a subset (without the actual password strings), Linux does it a bit differently. Linux's /etc/shadow file doesn't contain any useful information other than the username and the hashed password. Both /etc/passwd and /etc/shadow are necessary to develop an entire user database on a Linux system, whereas on FreeBSD all you need is /etc/master.passwd. With the combined /etc/passwd and /etc/shadow files from a Linux system, it's possible to put together a master.passwd that you can install into your FreeBSD machine and thus preserve all your users' login data. This can be done with a Perl script shown in Listing 21.1. Listing 21.1. Sample Perl Script to Convert a Linux User Database for Use in FreeBSD
Make sure this script is set executable; then, log in to the Linux machine, use su to gain super-user access, and run the script sending the output into a file: % ./mkpasswd.pl > new.master.passwdTransfer this new.master.passwd file to your FreeBSD machine and put it into /etc (pwd_mkdb doesn't like working on input files and destinations that are on different filesystems). Open up the file in a text editor and then open FreeBSD's /etc/master.passwd in another window. You will need to modify the first block of about 15 usernames (such as daemon, bin, news, and other system pseudo-users whose UIDs are different in Linux and FreeBSD). Simply copy this block of users from FreeBSD's /etc/master.passwd into the new.master.passwd file, replacing the corresponding block in the new file. Back up your existing /etc/master.passwd by making a copy of it. Finally, run pwd_mkdb to generate the new password files and hash databases: # pwd_mkdb -p /etc/new.master.passwdIf this command completes without errors, don't log out yetyou need to test this while you still have super-user (root) privileges so that you can fix any problems that might exist. Do this by opening another terminal window and attempting to log in as a regular user and to obtain root access using the su command. If you can't, run pwd_mkdb again on the backup file you created, and the databases will revert to their former state, so you can determine safely what went wrong. Technical EsotericaA lot of extra little odds and ends are different between Linux and FreeBSD. Here is a list of some of the most visible:
Aside from adjusting to these minor differences, though, the transition from Linux to FreeBSD ought to be quite smooth. |
