Debian

As mentioned previously, itis simple to update your system. The commands (or menu items) for upgrading your system to the next official release are different from the standard updating commands. The apt-get command dist-upgrade or the aptitude full-upgrade will perform the necessary special calculations to upgrade to the next major distribution release after the package information cache has been updated (either using the normal update command if you have configured the release name as stable, or after changing to the new release name and executing the update command). The reason for the special commands is that there are major changes in package dependencies between official releases, and the way some software is configured, as well as the removal of obsolete packages, all of which require special calculations not involved in a normal package upgrade.

Synaptic can also handle a full distribution upgrade, but instead of a different command, it handles such upgrades when 'smart upgrade' is set in Preferences instead of 'default upgrade'.

There are other packages that can be used to manage a distributed environment, such as Chef and BCFG2. While simpler than Puppet or FAI, they support similar functions and have been used in some distributed and clustered environments.

The use of FAI, Puppet, and others in cluster management warrants a brief look at clustering next, and what packages in Debian support clustering.

Synaptic is a package manager with a complete GUI interface and no command line capability. Itoffers most of the capabilities of aptitude along with many of the repository handling features of dseleet. Uke the menu-based dselect and aptitude utilities, it provides a software list divided into sections of interest, such as databases, development, editors, and many more, which allow an administrator to browse available software more effectively. It also has search functions which allow easy discovery of packages for specific purposes.

Best practices are as follows:

• For general use -Synaptic
• For automated installation -APr
• For dependency resolution in difficult cases -aptitude

Most administrators are not concerned with traffic on the local loopback interface. This is because such traffic is often necessary for proper operation of the local system. It is also rather difficult to analyze in order to determine what is necessary and what may be safely blocked without affecting normal operation. The major reason to firewall loopback traffic is that if rogue software is installed on the system by a virus or worm, then that software has more avenues to further attack the local system over the unprotected loopback interface. It may allow a minor compromise to exploit the opening to become a major system takeover.

The major trade-off here is whether the likelihood of compromise and the resulting potential for damage justify the additional time and effort required to analyze and create a proper firewall for the loopback interface.

Aside from backup, recovery, and damage limitation, there are administrative functions that may differ depending on how a disk is partitioned. In particular, using a single partition for an entire disk relieves an administrator from having to modify partition sizes if one partition fills up and more space is necessary. TIlls is frequently why a single disk partition (plus swap space) is the recommendation for new users who are uncertain how they want to partition their drives.

Early BIOS systems could not boot from locations beyond the first 1024 cylinders of the disk. Thus, at one time, it was necessary to create a small/boot partition below that limit so that the system code (which could access larger areas) could be booted.

So, does an administrator need to wade through all of the log entries daily? That would be an extremely tedious task, and is really not necessary. A number of packages exist in Debian that will scan the logs for certain conditions and email the results to the administrator for further checking and action. The most common is logcheck, which checks the latest log cycles against a database of entries that an administrator might be interested in. It then emails the important ones to the administrator for further checking. There are also packages that perfonn various analysis tasks, such as email statistics or lITTP access statistics, using the system logs often combined with other information sources. They may be found using the Debian package management search facilities.

What package you use to check the logs, or even whether you use your own scripts based on string searches, is not important. The critical thing is to check the logs regularly. They can give you timely warning of impending hardware issues, software instabilities, programming problems, and attacks on your system.

Up until the late 1990s, the Basic Input/Output System, or BIOS, was the way all Intel-based systems were booted. Its disk partitioning information was held in a Master Boot Record (MBR) with additional code in the first sector of each bootable partition. With the advent of the Microsoft-sponsored Secure Boot feature, and its associated boot mechanism known as the Universal Extensible Firmware Interface (UEFI), there is a new partitioning layout and additional considerations.

This is the traditional method for setting up networking on a Debian system. It involves a series of files in fete/network. RPM-based systems such as RedHat Fedora and SuSE Linux use a different layout in /ete/syseonfig/network that is managed by their own utilities.

The /ete/network/interfaees file is probably the simplest way to get a network up and running. While it must be edited manually, it is easy to understand and a minimum number of configuration lines are needed to handle most situations. In fact, the Debian installation process will set up this file for you. lf you use the same networking configuration as you used for installation, the network will work immediately and require minimal tweaking. In fact, a minimal interfaces file is usually sufficient for most servers that aren't part of a cluster. Even if you do use an alternate method for network configuration, such as Network Manager, the local loopback interface is usually left configured in the interfaces file to keep the alternate configuration uncluttered, since it requires only basic configuration and doesn't normally need to be modified.

The interfaces file, while it can be very simple, also offers many options for more complex setups. You can configure wired, wireless, VLAN (Virtual Local Area Network) and Bridge interfaces, IP tunnels, and Point to Point (PPP) interfaces. Each interface can be configured to use DHCP or a static IP address, with both IPv4 and IPv6 supported as well as Novell's IPX protocol. A simple interfaces file is shown as follows:

# This file describes the network interfaces available on your # system and how to activate them. For more infor.mation, see # interfaces(S).

# The loopback network interface auto 10 ifaae 10 inet loopback

# The primary network interface

a11ow-hotp1ug athO

ifacs ethO iust static address 192.168.3.52

natmask 255.255.255.0 gateway 192.168.3.1

Lines beginning with # are comments, of course. The purpose of other lines is as follows:

• auto 10: The 10 interface is brought up whenever ifup is run with the -a option, as itis during system initialization
• iface 10 inet 100pback: This defines the basic loopback interface; the address is always 127 . 0 . 0 . 1 or : : 1 for IPv6
• allow-hotplug ethO: This brings up Ethernet a ifit is available and plugged in
• iface ethO inet static: This defines Ethernet a as an interface with a static IP address
• address, netmask, and gateway: These define Ethernet a's address, net mask, and the default IP gateway, respectively.

Simple and to the point. This file was actually set up during Debian installation and works as is. Ofcourse, there are many other options available which are documented in the interfaces manual page that allow you to handle much more complex configurations. The details on setting up the interfaces file may be found in the interfaces manual page. Itincludes information on setting up IPv6 and many other protocols.

In addition to the interfaces file, there are a number of scripts in the fete/network hierarchy that are related. In particular, the subdirectories if-pre-up. d, if-up. d, if-down. d, and if-post -down. d contain scripts that are run automatically when interfaces are brought up or down. Inaddition, specific scripts can be identified in the interfaces file to be executed when a particular interface is brought up or down (this is especially useful in configuring Bridges). The major disadvantage to using the fete/network/interfaces file is that there is no provision to configure Virtual Private Networks (VPN). However, in general, these can be configured using command line tools.

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.