Resources

The Red Hat Package Manager (RPM) was developed by Red Hat in order to provide some structure for software management. It provides all of the customary software management features which are as follows:

• Software installation, including resolution of software dependencies during the process
• Various reports on the installed software
• Software verification and control
• The ability for users to package their own software so that it can also be managed

Most RPM-based distributions are sponsored by a company that also sells an enhanced version of the distribution and provide extensively, paid support. This also means that unified administrative utilities are available, at least in the paid version, and often in the free version with somewhat reduced features. Many administrators prefer this approach, which makes the most common administrative tasks available through a single starting place.

The most common distributions using this format are Red Hat (and the paid version, Red Hat Enterprise Linux or RHEL) and SuSE (the free version is known as OpenSuSE and the paid version is often referred to as SuSE Linux Enterprise Server or SLES).

Finally, there are a number of packages that were created for the express purpose of configuring individual services. There are software packages that provide graphic or command line configuration tools for any number of other software packages. The packages vary in complexity and usage, as they are usually provided by third parties. They can be found by using any of the search capable Debian package managers. Synaptic is probably the easiest as it allows one to easily browse descriptions after searching.

Many of the third-party utilities are not aware of modifications Debian makes to the configuration file layout in order to ease administration, upgrades, and stability. Often, they use the upstream configuration file layout, or sometimes even the author's idea of a better layout. Although the Debian package upgrade procedure will handle this as a local configuration file modification, it does make extra work for the administrator during upgrades. Keep this in mind when deciding whether to use third-party configuration utilities.

The next section will cover the preferred methods for local configuration in Debian.

What do you do when a package doesn't exist in Debian? There are several options. One mentioned previously is to add non-Debian repositories to the repository configuration. After a Synaptic refresh, apt-get, or aptitude update, all of the package information in the repository will be available to the Debian package managers.

If, however, the software isn't included in any repository, there are a couple of options available.

There is actually one additional option: just install such software from its original source. This technique is not recommended because it places the software completely outside of the package management system. Future system upgrades that involve required libraries can cause the software to behave strangely or even break completely, and finding the reason can be quite frustrating. This technique should be used as a last resort only.

One of the issues frequently faced by administrators is that of having multiple, remote systems all with similar software for the most part, but with minor differences in what is installed or running. Debian provides several packages that can help manage such an environment in a unified manner. Two of the more popular packages, both available in Debian, are FAI and Puppet. While we don't have the space to go into details, both applications are described briefly here.

These were the first package management tools for Debian. The dpkg command still does all of the work, since all the newer tools use it as a backend. As such, ithas all the functions required to install, remove, configure, and report on packages. Itis a command line tool.

One of the limitations of dpkg is that it does very little in the way of dependency checking, other than to offer an error message when there is a dependency problem. Itrequires the user to examine the dependency report and include the necessary packages during installation. Another limitation is that dpkg only works on packages that have already been downloaded. However, both of these limitations are addressed by the dselect utility.

The dselect command is a menu-driven utility that provides access to information on packages in the Debian repositories, and also checks and helps resolve software dependencies. This greatly simplifies package selection and installation. Once packages are selected and all dependencies satisfied, either automatically or with user assistance, dpkg is run automatically to perform the actual installation.

There are many books and reams of Internet advice on building firewalls. The classic work on the subject is Building Internet Firewalls by Elizabeth D. Zwicky, Simon Cooper, and D. Brent Chapman, O'Reilly Media. However, for our present purposes, we'll cover some basic design principles.

The next decision to be made is how to partition the available storage space. There are the following three main considerations when deciding how to partition storage for a Debian system:

• Efficient backup and recovery
• limiting space
• Disk management

Another one of the system administrator's responsibilities is to manage the system logs. Debian systems by default log information that can tell an administrator how the system is being used, provide warnings and error messages that can indicate problems with software or hardware, and even provide early signs the system is being attacked or misused.

System logs are handled by the rsyslog package, and normally reside in /var/ log and its subdirectories. Various software packages and especially those that provide important services, such as DNS, FTP, E-Mail, and H1TP (Apache), often do extensive logging that may include entries that allow activity to be tracked and warn of potential problems or misconfiguration. The package documentation includes information on how to configure what is logged and where.

Some of the first decisions that must be made, even before installing Debian, involve deciding the best way to format the storage space for the installation. This includes what type of filesystem to use, how to partition it for the best effect, and whether and what to encrypt for security. The actual work of partitioning and boot code placement is handled by the Debian installer and can be altered later using standard Linux bootloader and partitioning utilities. The installation process and the utilities are covered well by the Debian installation guide mentioned in the previous chapter, and the documentations for the GRUB2, fdisk, and GNU Parted included with the appropriate software packages.

TItis chapter serves as a basic introduction to the concepts of boot loading and disk partitioning, along with some guidelines to keep in mind when installing Debian or updating your boot or partitioning schemes. Do not worry if you are still uncertain what is best for your situation when first installing Debian. As we shall see, the defaults will work just fine for most cases, and the beginner can't really go wrong while using them when in doubt.

The update-rc. d utility has already been mentioned, and is one of the primary command line interfaces for managing init scripts. However, there are several other utilities that are essentially a frontend for update -rc . d that make the administrator's job a little easier. The primary ones are bum and sysv-rc-conf.

The Boot Up Manager, or bum, is a graphical application for managing init scripts. It requires a window manager to run, and provides a nice interface showing what services are running and what scripts are enabled. Inadvanced mode, itwill also allow you to adjust individual run levels and run order.

As mentioned for the update -rc . d start and stop commands, adjusting script ordering is not recommended.

There is also a utility called sys-rc-conf. It uses the curses library to provide a full-screen text interface. Inits default mode, itwill not modify script order, although special options on the command line will allow this ifyou really need this functionality.

Both utilities are pretty much self-explanatory. Check the services you want, uncheck those you don't, and you can set or unset check marks for different run levels on the same script.

Frequently, you will need to execute a SysV script manually, either to check the status, or to restart a service that requires it. Although the script in /etc/init. d maybe executed manually, the recommended

method is to use the invoke-rc. d command, which ensures that system policy and run level constraints are satisfied.

The Softlanding Linux System (SLS) distribution, which evolved into the Slackware distribution, is one of the oldest. Distributions in this branch generally made minimal or no changes to the original software packages before including them. Distributions using this format generally provided no native software management and depended on third-party utilities for package management and administration. These utilities were readily available and often included, so this was not necessarily a disadvantage.

These distributions are also known as Sorcerer/Lunar-Linux/Source Mage (SIS) distributions for the most common distributions using the format. These distributions are mostly obsolete and not often seen. However, the package format is still used by many software projects.

So far, we have been discussing server configuration. User configuration of a desktop environment is actually a little easier, as both GNOME (GNU Object Model Environment) and KDE (K Desktop Environment), as well as other desktop managers, provide a full suite of utilities gathered in one menu area that allows the user to easily configure things such as desktop appearance, behavior, window themes, login behavior, and system and session services relevant to their environment.

Itis possible to perform automatic, unattended updates to a system, but there are some potential problems. Setting it up is quite simple. Just install the unattendedupgrades package. Ifyou aren't asked during installation ifyou want to enable automatic security upgrades, run the command dpkg-reconfigure -plow

unattended-upgrades.

Generally, only security upgrades will be automatically installed, which will minimize potential problems, which include modified dependencies and changes that modify how the software is configured or how it operates. Itis possible to allow other upgrades by modifying the configuration file in /ete/apt/apt. eonf .d/SOunattendedupgrades. The file is commented to help identify the modifications desired, generally just removing the / / in front of the lines you want to enable. Note that enabling anything other than security updates can result in errors (when dependency issues are encountered) or system disruption (when the upgrade modifies software behavior or configuration). This is especially true ifthe stable release name is used, which can result in very major changes when a new stable version is released.

Best practice is to allow automatic installation of security upgrades only (use the default configuration). The package information cache for all packages will be updated in any case, so you can manually upgrade

the rest of the packages periodically, allowing you to address any unusual upgrade issues as they arise.

Of course, backups are not the only issue with managing multiple, remote systems. In particular, managing such multiple configurations using a centralized application is often desirable.

The Debian package manager started out as a simple, command line utility, dpkg, with an additional utility called dselect that allowed more complex package selection and dependency resolution via a menu-based, curses interface. Eventually, additional utilities were developed to provide a better interface, better automatic dependency resolution, or both. The current standard package manager is Synaptic, a full-blown GUI application that runs in a graphical window manager, and provides extensive selection and reporting features.

IPTABLES, which supersedes the old IPCHAINS code, is the generic name for what is actually a group of kernel modules and applications used to define and control Linux kernel firewaIling. It actually includes moduIes and applications to provide IPv4, IPv6, ARP, and Ethernet Frame packet filtering as well as some statefuI inspection of packets. There are many options for filtering, depending not only on the packet characteristics (such as protocol, source and destination addresses), but on how the packet is being handled, such as whether it is just entering the system, being forwarded, exiting to the network, needs address translation (such as Network Address Translation or NAT), related to an established connection. There are several good books available on IPTABLES, or you can start with the documentation on the www .netfilter.org website, which is the home of IPT ABLES code as well as many related projects.

There is a project, NFl" ABLES, which is slated to replace IPfABLES in the kernel. It is still under development and at the time of writing, there is no official Debian support (either in Debian 7 or the testing release for Debian 8). However, there are compatibility packages in the works, and once the code becomes part of the official Linux kernel, official Debian packages are expected to follow.

Since most firewall packages provide their own ways to define your firewalls and output the appropriate iptables configuration commands, it is not necessary to understand all of the gritty details of IPIABLES, but a good administrator will want to understand the basics for a couple of reasons. First, it will help in understanding the capabilities of the firewall configuration software, since the features will be based on what can be done with IPTABLES, and second, it will be needed if you use something such as fireflier or mason, which propose rules and expect you to modify or delete them as required for your specific environment.

Of course, beyond understanding what is possible, it is necessary to figure out what is required for your firewall.

Generally, the default ext4 format is the best choice. In specific cases, IFS or XFS may provide some advantages, and if the ability to resize dynamically is more important than performance or scalability, and you don't want to use logical volumes, ReiserFS (especially version 4) might be appropriate. Btrfs should not be used for critical data yet, but at some point soon it will become the preferred format. Non-Linux formats should not be used for the basic system.

Which backup software you choose is somewhat a matter of taste, but there are some guidelines. For quick and dirty backups of individual files, the standard rsyne, tar, and epio utilities are usually sufficient. For more routine backup of individual systems, one of the software packages that provide for configuring and scheduling automatic backups, both full and incremental, is your best bet. Ifyou have multiple systems to back up, one of the major backup suites that provide central control, scheduling, and storage is best. We will discuss this further in Chapter 7, Advanced System Management.

In all cases, ifyour backup solution doesn't automatically take care of it, be sure to include a rescue or live CD that includes the software necessary to format and partition the disk drive, restore the files, and recreate the boot information. Some backup packages, such as Mondo, include the creation of such bootable media as part of their software.

Don't neglect backups. Even the most resilient VM environment with multipath Network Addressable Storage (NAS) can fail in unexpected ways that will corrupt your data. I am aware of one such environment where the UPS was disconnected in a way that removed power from both the NAS system and the VM host. Although the Debian system used a non-cached journal for its fiIesystem, the NAS was buffering the journal writes. When power was lost, the journal was incomplete, and the disk ended up quite corrupted. Lesson learned.

Debian is an extremely stable Linux distribution that includes a great variety of software that runs in many different environments and on many different CPU architectures. It is free, in the spirit of the Free Software Foundation's definition, and thus may be run freely on as many systems as an administrator desire, without limit or licensing fees. It may be freely copied, modified, and re-distributed. Debian is available from many official Debian servers and mirrors, and it is well supported by an official and well-defined, albeit all-volunteer organization, which provides support via many channels. Paid installation media and support are also available from many third parties.

Debian installations tend to install the minimum services necessary, requiring the administrator to add any additional services necessary after the initial installation. This results in systems that are secure, run faster without unnecessary services and allows Debian to work satisfactorily on older, less capable systems.

Now that we've covered the basics of Debian, it's time to cover the basics of disk layouts, including the structures used for booting and how to determine the partition layouts.

As mentioned previously, this is now the default as of Debian 7 Wheezy. Itwas introduced in Debian 6 Squeeze, although it could be turned off. It is now always enabled, although provisions are made for legacy ordering (assigning specific numbers to start and stop scripts). Because of this, the administrator no longer needs to determine the order in which the init scripts are run. This is now handled by the insserv utility.

The insservutility should not be called clirectly. The update-reo d

utility provided by Debian, which calls the low-level insserv command,

is the recommended interface to manage init scripts.

The init scripts must now have dependencies and defaults listed in a special set of headers, along with a description of the script, what service or services itprovides, and what run levels the service should be active in. A good example is the beginning of the script for starting Apache:

lIl/bin/sb lIlili BBGIN INIT INFO

i Provides: apacha.2

i Required-Start: $local_fa $remota_fa $network $Byslog $named II Required-Stop: $local_fB $remote_fa $network $Byslog $named i Default-Start: 2 3 4 5 II Default-Stop: o 1 6

i X-Interactive: true i Short-Description: Start/stop apache2 web server

lIliji BND INIT INFO

The fields are fairly self-explanatory. 1ms script provides the apache2 service. Other scripts can name this service as a pre-requisite. 1his script requires that local and remote filesystems be mounted, and that the network be up, and that syslog and named services be available prior to starting. likewise, these services must not be stopped after this script has shut down the apache2 service. The default runlevels where apache2 should be active are 2 through 5, and of course, 0, 1, and 6 is where it is stopped. The X-Interactive field means that the script can require user input if it is run in such a way that a terminal is available to communicate with the script. There are other fields available as well, which are documented in the insserv manual page.

• These headers are called LSB headers, since they are defined in the

Linux Standard Base document, developed jointly by a number of Linux distributions under the organizational structure of the Linux Foundation

While dependencies generally do not change, the administrator can modify what run levels a script is active in. 1ms should not be done by editing the headers. Rather, update-re. d should be used to modify the run levels. For example, suppose you want apache to run only in run levels 4 and 5, and not 2 or 3, the command updatere. d apaehe2 disable 2 3 will do this.

Many scripts provide a switch in their fete/default configfile that

defines whether the service should run at all. When you want to disable a

service completely, this switch should be used in preference to disabling

the script in all run levels via update-re. d.

The manual page for update-re. d also documents the options start and stop, as well as a means of specifying the start or stop order of a script (using the legacy method of assigning numbers to the start and stop links). However, these are deprecated and it appears they will be removed in Jessie (Debian 8).

H you have locally developed or third-party init scripts that do not .ct include the necessary headers, Debian 7 will still boot using the old method of script ordering, but will notify you of the reasons it can't

migrate to a dependency-based boot sequence.