Resources

Once all modifications have been made, and the appropriate sites or modules enabled, it is best to test the configuration for obvious errors. While it is possible to use the init script in /etc/init .d/apache2 for this, the apache2ctl utility is specifically intended for, and better suited for this purpose. There is a configtest command option (detailed in the apache2ctl manual page) which will perform basic checking on all of the included files. It won't catch all errors, but it will catch the majority of them. After you are confident the configuration is correct, it is necessary to reload or restart Apache in order for the changes to become effective. Again, while the init script can handle this, using apache2ctl is the preferred method.

There are two ways to get Apache to reload its configuration files, a regular restart, or a graceful restart (which doesn't actually restart, it just reloads the configuration). The graceful restart is the preferred method because if there is some issue with the configuration, especially something the configtest was unable to catch, the web service continues running with the old configuration, avoiding server downtime while you fix the problem. A graceful restart may take some time if there are long-running threads, since it waits until all threads are idle before reloading the configuration. A full restart forcibly terminates all threads and reloads the configuration, and won't restart the server after it is fully stopped, if there are configuration errors.

Most configuration files reside in the / ete directory hierarchy. In general, most packages place their configuration files in a subdirectory named after the software. In cases where the upstream developers do not do this, the Debian package usually modifies the behavior. A good example is the BIND DNS server software. Traditionally, the base configuration is placed in /ete/named. eonf, with any other configuration files placed in the /var/lib/named directory. The Debian BIND package places all configuration files in /ete/bind9 and its subdirectory.

In addition, there is a fete/default directory, in which commonly modified options are placed in a file matching the package name. Again, using BIND, the file is /ete/ default/bind9, and contains two simple options: whether the resolveonf dynamic resolver is being used, and what options the server should be run with. We'll cover this directory first.

Many administrators will never have to administer a cluster, and many won't be responsible for a large number of systems requiring central backup solutions. However, even administering a single system using command line tools and text editors can be a chore. Even clusters sometimes require administrative tasks on individual systems. Fortunately, there is an application that can ease many administrative tasks, is easy to use, and can handle many aspects of Unux administration. Itis called Webmin.

Up until Debian Sarge, Webmin was a part of Debian distributions. However, the Debian developer in charge of packaging it had difficulty keeping up with the frequent releases, and it was eventually dropped from Debian. However, the upstream Webmin developers maintain current packages that install cleanly. Some users have reported issues because Webmin does not always handle configuration files exactly as Debian intends, but it most certainly attempts to handle them in a compatible manner, and while some users have experienced problems with upgrades, many administrators are quite happy with Webmin.

As long as you are willing to deal with conflicts during upgrades, or restrict use of modules that have major configuration impacts, you will find Webmin quite useful.

The package information is updated simply by the refresh menu entry in Synaptic, or the aptitude or apt-get update command to update the package information cache. This should be done regularly to ensure that the information you have on available packages is current. Once you have the repositories configured and have updated the package information cache, you can select and install software from any or all of them as desired. There are two basic methods for selecting packages. command line and selection lists.

System scanners include packages that scan for possible rootkits that may be installed or active on your system, and virus scanners. The packages rkhunter and chkrootkit are two of the most used rootkit detection packages. The Tiger package is a somewhat more comprehensive scanner that uses chkrootkit and Tripwire or AIDE as well as its own scripts to perform a full audit of your system's security. After the first audit of your clean system, Tiger will alert you to changes in your system's vulnerabilities.

The only major function absent from Tiger is virus scanning, which can be handled by the clamav package, which also provides live scanning of email.

A final word on remote logging

One of the first things an accomplished hacker will do once he penetrates a system is attempt to erase all signs of system compromise. TIris includes removing entries from log files, hiding files, and network connections so they can't be shown using normal utilities, and so on. They may even go so far as to install their own compromised versions of your intrusion detection software, and your file and system scanners that won't report any sign of their illicit activities. One of the best countermeasures for this is to set your system up to write your system logs and NIDS and scan results to a remote system. Many scanners also provide ways to encrypt and verify configuration files and scan databases to protect them from compromise as well.

If your system is subject to frequent attacks, set up remote logging, reporting, and alerting, and secure the configuration files and databases of your system and file scanners and your intrusion Detection System.

One of the main reasons for encryption is to keep private and sensitive data secure from unauthorized access. Laptops, for example, are frequently stolen and their contents have, in some well-publicized cases, been made public or put to harmful or illegal uses. Servers, on the other hand, aren't usually stolen, but they do have multiple users, and while the Linux permissions system can prevent unauthorized access, there are ways for hackers to bypass it, and they are constantly trying. For example, ifone can gain root access, either legally as a system administrator, or illicitly by exploiting unpatched software security vulnerabilities, read/write access to everything on the system is allowed. Or, ifa user is not careful with setting permissions, access via other users may be allowed unintentionally. Inall cases, access by anyone who does not have the proper keys can be prevented by encryption.

One of the most critical tasks performed by system administrators is setting up and monitoring system security. Debian provides some assistance here, with special packages that help in hardening your systems, but this is only the beginning. In particular, you must pay attention to how you set up the root account, how to block improper access to your systems, and how to monitor your system for security problems.

Developed by IBM for its Unix-like AIX operating system, and offered as an alternative to the ext and ext2 filesystems via release under the GPL, Joumaled File System OFS) is one of the alternatives to the current ext4. It uses fewer resources, while remaining quite stable and resilient. It includes many features of Btrfs, and is a good choice when CPU power is limited, or with database systems that require synchronous writes to survive hardware failures.

Although modern journaling filesystems are quite resilient, they will, on occasion, suffer an error in the underlying infrastructure. The reasons are many and include power fluctuations, hardware failures, and certain types of kernel failures. While the last is extremely rare in Debian stable releases, it does happen, especially ifthirdparty kernel modules that are not part of Debian are installed or ifthe kernel has been modified locally for some reason.

As mentioned in The social contract section, licensing is one of the central issues in Debian. All of the software in the official Debian distribution is released under any one of several free software licenses, usually some version of the GNU General Public License (GPL), a Berkeley BSD-style license, or some form of the artistic license used by some Perl developers.

What this means for administrators is that they can run Debian on as many different systems as they wish, without licensing fees, and provide as many copies as they wish to others, without restrictions (well, technically, there are restrictions, but mostly they are requirements that will keep the software free, in the spirit of the Free Software Foundation's definition).

This freedom does not prevent an administrator from running proprietary software in Debian. In fact, such freedom is a part of the social contract. The only restrictions are whatever that software's license states.

As mentioned previously, site and module configurations and options are placed in the sites-available and mods -available directories. They are not included unless there is a link to them in the sites-enabled or mods-enabled directory. Instead of making the links manually, use the a2enmod and a2dismod commands to enable or disable modules, and the a2ensite and a2dissite commands to enable or disable specific site configurations.

Debian depends heavily on the configuration methods used by the upstream developers of each package, supplemented by the Debian developers' modifications and additions to standardize package configuration, and make the administrator's life easier. In this chapter, we will cover the standard location of configuration files, utilities available to assist in configuration, trends in configuration file management, and some examples.

Some common components of clusters have already been mentioned, such as the OpenMPI libraries. Aside from the meta-packages already mentioned, the redhat-cluster suite of tools is available in Debian, as well as many useful libraries, scheduling tools, and failover tools such as booth. All of these can be found using apt-cache or Synaptic by searching for "cluster".

Once you have the repositories that you want configured, you need to retrieve information about what is in the repositories. This includes not only package lists, but package descriptions, contents, and dependencies. This is done by updating your package cache, after which you can browse, select, install, upgrade, and delete packages.

The second level of intrusion detection involves monitoring the files on the system. There are several good monitors that will alert you to new, deleted, or modified files, usually filtering the reports so they include only changes that indicate a potential compromise. The most commonly used File Monitor is Tripwire and that is what is installed by the harden-environment package. However, Tripwire is now owned by a commercial enterprise that sells proprietary versions. While open source tripwire is still available, many administrators are switching to AIDE (Advanced Intrusion Detection Environment) or Samhain as alternatives.

Configure your file monitors carefully to catch important changes and filter out as many false positives as possible without filtering out the true positives.

The importance of filtering your results can't be overemphasized. An alert or report with too many false positives will frequently be skimmed at best or ignored at worst, and can result in missing a true positive indication of compromised files.

The final choice to be made prior to installation is whether to encrypt the disk contents. There are two main options, disk encryption and directory encryption.

In some countries, encryption is subject to legal restrictions. Know the laws in your jurisdiction!

The tasks of an administrator are many and include the responsibility for what services the system provides (especially how they are started and shut down), network configuration, system backup, filesystem space management, system operation (system logs), and providing the face the system shows to the world. We've covered some of the issues in each of these areas, although comprehensive coverage of any of the subjects could take several books. One subject not covered here that must be covered in depth is basic system security. We will cover this in the next chapter.

The ext filesystem was originally developed to overcome the limitations of the MINIX filesystem..

MINIX was linus Torvalds' inspiration for linux.

The second extended filesystem (ext2) improved upon it, while the third extended filesystem (ext3) added joumaling, as well as performance improvements. The fourth extended filesystem (exl4) added additional features and performance improvements.

• The ability to disable joumaling is one reason ext2 was sometimes used over ext3 for flash drives in order to reduce the write cycles.

There are two types of filesystem maintenance: partition and content maintenance. The former includes periodic checking of the filesystem's underlying structure and metadata, modifying the partition layout, and low-level backups. The latter involves monitoring and controlling the space used by files as well as file backup and recovery.

In addition to the organization, there are very comprehensive policy manuals that guide everything about development and release, including the structure of the repositories and archives, as well as a number of related standards documents. Information on all of this is available at http://www.debian.org/devel/.

One of the most important effects of these policies and the organization behind them is the stability of the Debian distribution. At any one time, there are three main versions of Debian available: stable, testing, and unstable. There are also experimental and backports versions, but they are not complete distributions. The experimental version contains packages that are incomplete and not ready to be included in the unstable release. Backports contain newer packages compiled especially for the current Debian stable release.

The unstable version is where active development takes place. Once a package has no "release critical" bugs and works on all supported architectures, it is moved to testing, where it gets additional testing. At some point, the testing contents are frozen in preparation for a new stable release. After stability is verified and all packages satisfy Debian requirements for release, testing becomes the new stable release, and the cycle continues.

Requirements for the stable release are quite stringent. In fact, requirements for testing are strict enough as some have commented that the testing version is more stable than many companies' stable releases. Thus, in DeWan, stable means just that. A stable release of Debian is extremely dependable, with a system for releasing security and emergency updates that keep it so. It provides mission-critical, production quality software for servers and development systems. This is one of the main reasons Debian is used on more production web servers than any other Linux distribution (according to W3Tech, as of January 2012).

As with any advantage, there is a corresponding disadvantage. Debian stable does not always contain the latest, leading-edge software. This is done to ensure the distribution is as mature and crash-free as possible. Of course, it is possible to install newer software under Debian with its required dependencies. In fact, the backports set of repositories contains just such software, pre-compiled especially for use on the Debian stable release. Such packages, however, are not guaranteed to be as stable as those that comprise the official stable release.