Resources

There are a couple of other things administrators should know about how Debian differs from other distributions before we get into details.

One thing to note is that the home of distribution if you will, can affect the character of distribution. For example, Red Hat was originally developed in the United States and, as such, reflects the common usage and preferences of American administrators. SuSE, on the other hand, originated in Germany, and reflects European practices. A concrete example of this is that, for Red Hat, GNOME is the preferred window manager, while SuSE is more geared towards the KDE desktop manager, although both window managers, as well as others, are available in both distributions. The primary issue is that a distribution that matches your preferences will require fewer configuration changes or software package installations to match your administrative style. Information on a distribution's history and intended purpose can be found on the distribution's home page, and frequently in Wikipedia entries as well.

The Debian project originated in the United States but recruited developers worldwide right from the beginning. Thus, defaults and settings reflect the most common best practices worldwide as much as possible, with individual packages reflecting the interpretation of their developer's particular experience.

The best practice is to select a distribution that best matches your preferences. That way, the default configuration will be closest to what you want and will require less tweaking to match your administrative style.

Next, distributions fall into two main categories: those with corporate sponsorship, and those without it. Corporate sponsorship usually implies that paid support is available, as well as a paid version of the distribution with extra features. This does not mean that it is not available for distributions without such sponsorship, only that one must find third-parties that provide it rather than finding it in one place.

Debian does not have or accept corporate sponsorship, although it does accept and receive a great deal of corporate support in the form of hardware, developer support, and donations. The idea is that Debian is guided by their social contract and their developers, rather than a particular corporate sponsor. Paid support is available from a number of sources (many who have also contributed), and free support from the developers and user community is available via many support pages and forums, as well as an official bug reporting and tracking site.

Another thing that the lack of corporate sponsorship might imply is a lack of structure or direction. This is not the case for Debian. In fact, there is a very strong structure, with supporting processes and administrative responsibilities, guiding Debian development and release. The main impact is more subtle-Debian is guided by a social contract, and a community of developers committed to the idea of quality, free software, widely available, that runs as trouble-free as possible in as many environments as possible.

With that, let's take a look at the Debian Project itself.

Many software packages are moving to a multiple file configuration system. Debian developers are using this feature to protect local changes by instructing administrators to place their modifications in a file with a . local extension. In other cases, such as the Apache configuration directories, files are placed in specified subdirectories (conf.d and sites-available in this case), and may be named freely, as long as they don't conflict with file names used by standard Debian or upstream configurations. In these cases, the Debian developers have modified the configuration files so they contain commands to include local configuration files, overriding the standard files as necessary. In any case, a savvy administrator will use such separate files for local configuration changes when possible, so that they are unaffected by package updates.

One of the side effects of this separation of local configuration files is that the update procedure will no longer ask you whether to install the developers' configuration, leave the local configuration, or reconcile the two. Generally, this is what you want, as your local changes will remain in place, and any new features will have reasonable defaults that shouldn't cause problems. However, in cases where there are possible major changes to the configuration defaults, a pop-up description of the changes occurs during the upgrade (requiring acknowledgement), and is also emailedtotherootaccount.Evenwithoutthis.though.itis good practice to browse the package documentation for configuration advice and the configuration files for any obvious changes, after the upgrade is complete.

Itis also possible to build Debian packages yourself, either from a partial alien conversion (as previously discussed), or from scratch using the original software. The procedure can vary from simple to complex, depending on what the package is to provide, and is well covered in the Debian maintainer's guide and the Debian policy manual, both available online or as installable packages in Debian, and in many other online resources. A good online starting place is the Debian packaging Wiki page at https://wiki. debian. org/HowToPackageForDebian.

Manual builds, either from scratch or from a partial alien conversion, are the recommended way to handle software that cannot be obtained instandard Debian format.

Details vary greatly, depending on the actual software involved. Generally, a package is built from source code, but itis also possible to build a package from a binary only software release as well. The general procedure for this is as follows:

1. Obtain the source (or binary files) and place in an appropriate package building directory.
2. Create the necessary Debian packaging files, which include additional documentation as necessary, optional script files specific to Debian packages, files to control the package building process, and files required by Debian package managers.
3. Test the build. Ifnecessary, add patches to correct any problems in packaging, or that are required for the software to compile or run properly in a Debian environment.
4. Repeat steps 2 and 3 until the final product installs and runs on your distribution.

The packages available to Debian developers are included in the distribution for anyone to use. The primary ones used in building your own packages are:

• build-essential (packages essential for building Debian packages)
• dpkg-dev (package development tools)
• fakeroot (allows users to build as if they were the root user)
• dh-make (tools to create files in the debian package build directory)
• debhelper (helper programs for the debian/rules file)
• cdbs (optional, additional helper programs for the debian/rules file)
• quilt (debian package patch management)

It is all but impossible to give any general example, as every package will differ in all but the first step. However, there are many good examples and tutorials available online, and the full package source of all Debian packages included in the distribution is available for anyone to examine and learn from.

Probably the best known application for distributed management is Puppet, developed by Puppet Labs. Unlike FAI, only the Open Source edition is free, the Enterprise edition, which has many additional features, is not. Puppet does include support for environments other than Linux. The desired configuration is described in a custom, high-level definition language, and distributed to systems with installed clients. Unlike FAI, Puppet does not provide its own bare metal remote installation method, but does use existing methods (such as kickstart) to provide this function. A number of companies that make heavy use of distributed and clustered systems use Puppet to manage their environments. More information is available at http://puppetlabs.com/.

aptitude is a frontend for the APT suite of tools, with added functions that make it a little more like dselect, where it offers finer-grained dependency checking, and resolves dependencies with user assistance rather than autonomously. As such, itis sometimes more successful than dselect or apt-get in resolving dependencies in ways that require fewer major software changes. Uke dselect, it is menu-driven (using the curses interface), with command line functions as well. Due to the user assistance sometimes required for dependency resolution, it is less suited to unattended or automatic software updating. However, itwill frequently find simpler solutions, involving fewer changes, when compared to APT.

In general, outbound traffic is legitimate, and many administrators do not restrict traffic originating on the local system going to remote systems. Unfortunately, there are cases where this is not advisable. A common example is when a company wishes to restrict the outside services its employees can use (such as preventing the use of YouTube because it is inappropriate for them to be using it during working hours). Another example, though, is the case where a system has been compromised and starts contacting a remote command and control system for orders and additional malicious software to install.

Both cases may be handled by at least logging, and in many cases restricting outbound traffic. In most cases it is sufficient to limit outbound opens (requests for a new connection).

On a personal system, outbound opens need not be restricted unless company policy requires such restrictions. On a server, outbound opens should be restricted to those services that the server requires for proper operation. Outbound traffic should be allowed only if it is on or related to an established connection.

Some administrators used partitions to limit the space available for certain directories. A good example is a mail spool directory. A massive spam attack can quickly consume large amounts of disk space. Using a separate partition for the spool directories will limit the total space that can be used by spool files, and the errors generated when no space remains alerts the administrator to the condition.

The availability of account quota systems for Linux can handle this situation without using partitions, but some administrators still prefer the hard limit of partitions.

Even production system logs will eventually grow to the point where they take up a significant amount of disk space, and this is even more of a problem with development systems that follow the preceding guidelines. One of the administrator's duties is to determine how much log data should be kept, and manage the mes appropriately.

All distributions, and Debian is no exception, provide by default a job or jobs that run periodically to close the current log mes, mark them with a cycle number, and open new, clean mes for logging. In Debian, this is provided by the logrotate package. While this package is primarily concerned with log files, itcan be used for any other mes that grow constantly and need to be cycled. Detailed documentation is provided with the package, but the basic idea is that each log file is checked and if itis over a certain size, it is closed. Then all cycles of the log me are renamed, and if necessary, those over a certain age or cycle number are deleted. A new log me is then created to continue logging.

You can configure how many cycles are kept, or even how old the cycles can be before they are deleted. The primary choice here is how long you wish to keep log entries. The defaults installed with each package reflect the experience of many administrators and are usually appropriate in most circumstances.

One of the first choices to be made when installing any Linux distribution is whether the system will be single or multiboot. In general, many developers run both Windows and Linux on the same machine. In some cases, due to licensing restrictions or just personal preference, they wish to use the Windows installation that came with their computer and boot into one or the other as needed. This is perfectly fine, and most bootloaders will recognize both operating systems and provide menu items to boot the desired one. Another option is to use Xen or similar virtualization software to boot both simultaneously. A third choice is to run Windows under a Linux virtual machine (VM) using QEMU or KVM software. Creating VMs under QEMU, KVM, Xen, or any other virtualization software (such as VMware), would be a complete book in itself. For our purpose, we will consider a VM as essentially equivalent to an actual hardware system, since the issues outside VM creation are identical.

Best practice, if this is a single operating system server environment, will be a single-boot system. If this is a developer system that may require booting into an alternative operating system, use dual boot.

VM generally does not require dual boot.

Basic to any system is network access, either to allow others to use its services, or to allow users to access services on other systems. There are two main ways of setting up and controlling networking, the static /ete/network/interfaees file, and the more dynamic Network Manager.

The Debian Packaging System (DPKG/DEB) was developed about the same time as the RPM, and has the same features, although they are implemented differently. DPKG refers to the original software packaging utility. This has been superseded by more flexible and user-friendly utilities, so this branch is often referred to by the extension used by the package files: DEB ( . deb). Some distributions in this branch have corporate sponsorship (Ubuntu is the most notable) and thus, have a unified administrative utility, similar to SuSE's YaST for example. Others, such as Debian, depend upon third-party software to fulfill this function.

The most common distributions in this branch are Debian and Ubuntu. Most of the others in the branch, such as Mint and BackTrack, are derived from one of these.

Because Debian upgrades often affect configuration files, the developers have crafted techniques to lower the impact of upgrades on locally modified configurations. In particular, they are moving to provide separate local configuration files and special directories that help maintain local changes during upgrades.

If the package exists in some other Unux distribution, it can often be converted to a Debian package. This is done using a package called alien. Alien provides commands to convert between a number of package formats (including Red Hat RPM, Stampede SLP, Slackware TGZ, Solaris PKG, and Debian DEB).

In general, the conversion itself is fairly straightforward. Although the results cannot be guaranteed, the converted package often will install okay under Debian. Any problems that do occur are most likely to be caused by different library dependency names, or even differences in software level identification.

All is not lost when this happens, however. Alien can perform a partial conversion, essentially stopping at the point where it has created the temporary directory from which itnormally builds the Debian package. You can then go into the directory and make the necessary modifications, and then complete the build manually.

Fully Automated Installation (FAI) focuses on managing Linux installations, and is developed using Debian, although it works with many different distributions, not just Debian. FAI uses a class concept for categorizing similar systems, and provides a good deal of flexibility and customization via hooks. F AI provides for unattended, automatic installation as well as tools for monitoring and updating groups of systems. FAI is frequently used for creating and maintaining clusters. More information is available at http://fai-project . org/.

The Advanced Package Tool (APT) was developed to provide a better command line tool, that provides the download and dependency resolution of dselect without requiring a separate utility for installation. Think of it as an all-in-one command line tool that can select and install or remove packages, and automatically resolve dependencies.

APT is actually a set of utilities that include apt-get, the basic package installation tool, plus several other command line tools with an apt prefix that provide additional functions, such as reporting on available software, and other basic local repository maintenance functions.

The man apt command is a good starting point, as it references other man pages for the additional commands. The Debian reference manual also has a lot of information on these and other package management commands

This tool is fast and, except in unusual circumstances, handles dependencies without requiring user intervention. Itis the basic tool used for automatic, unattended software installation and updating.

Any time someone can open a connection to a system, that system can be attacked via that connection. This doesn't refer to inbound traffic in general, especially since much of this will be related to connections the local system established. It refers to the request from a remote system for a new connection to a local service. This is usually called an inbound open as it involves an initial request by a remote system to open a connection on a specific IP port.

Of course, if your system is a server that provides services to remote users, you must allow requests for services your server provides. Just don't allow any other inbound requests, and if you can, limit the source address of the requests unless the service is to be provided to anyone and everyone.

Limit inbound requests (opens) to only those absolutely required to provide particular services to remote clients. Do not allow any other inbound traffic unless it is on or related to an established connection.

In the past, backups were performed on full partitions. Large partitions could take a long time to back up, and the system could not write to the partition during the process. With the advent of incremental and live backups, this is no longer a primary consideration. Another problem was that when a disk got corrupted, recovery usually was limited to a single partition. There are partition repair utilities now that can fix most problems (though not all), and only those files that can't be fixed need to be recovered.

Still, limiting the damage and the focus of recovery can be useful and remains a valid consideration.

The rsys1og system logging facility in Unux provides for various options, facilities, and log levels. The options control what happens when a message is logged, such as whether itis sent to the console ifitcan't be logged in a file, whether the process ID (PID) is included in the message. The facilities provide a means to divide messages into various areas according to what subsystem is involved, such as AUTH for authorization messages, CRON for scheduled jobs, KERN for kernel messages. Most software that uses the system log provides configuration items to control the options, files, and facilities it uses for its messages. Inaddition, and most important, are the levels of log messages, which determine how important a message is.

Log levels detail which messages, of the many that might be sent to the system log, actually get logged. This varies from the EMERG level, which only involves messages that essentially mean the system is unusable, down through ALERT (immediate action required), CRIT (critical), and ERR (errors) to WARN (warning conditions), NOTICE (normal but significant), INFO, and DEBUG. Setting the log level to any of the latter three can generate a significant number of entries and use a lot of disk space as well as requiring significant system overhead.

For that reason, there are some guidelines as to what should be logged:

• Production systems should only log EMERG, CRIT, ALERT, ERR, and WARN levels. NOTICE, INFO, and DEBUG should never be logged on a production system unless absolutely necessary.
• Development systems should log those levels mentioned in the previous point, along with NOTICE and perhaps INFO levels to provide information necessary to the software developers. DEBUG may also be used when necessary.

The idea is to provide the necessary infonnation without unduly burdening a system. In particular, NOTICE, INFO and especially DEBUG levels can produce massive amounts of data that are generally unnecessary in a stable production system.

Log data is frequently used to analyze how the system is being used, who accesses it, what activities are being perfonned, as well as to notify the administrator of things that need attention.

Each architecture has its own characteristic method of partitioning disk drives and placing boot code in the appropriate place. For most, this is very straightforward. However, the Intel architecture is undergoing changes that require some understanding of the boot process and disk layout.

Non-Debian third-party packages often do not provide SysV scripts to start and stop their software's background processes, and you may need to write your own. Even if such scripts are provided, they may need to be modified to follow the Debian standards, particularly ifthey use prepackaged functions available in other distributions that differ from those in Debian.

Writing init scripts is a whole subject in itself. However, the Debian initseripts package includes a /ete/init. d/skeleton script that can be copied and modified according to your needs. The Operating System of the Debian Policy Manual (available as a Debian package and at http://www. debian. org/doe/debian-poliey/) and Olapter 20, System Initialization of the Core Linux System Base standard (available at http://refspees . linuxfoundation. org/lsb. shtml). The latter also provides for some standard functions in /lib/lsb/init-funetions to assist in script coding.