Debian

Webmin may be installed by adding the following lines to your apt sources file:

deb http://download.webmin.com/download/repository sarge contrib deb http://webmin.mirror.sornersettechsolutions.co.uk/repository sarge contrib

Usually, this is added to a separate webmin.list file in /ete/apt/sourees .list.d.

The use of 'sarge' for the release name in the configuration is not a

mistake. Since Webmin was dropped after the Sarge release (Debian \: 3.1), the developers update the repository as itis and haven't bothered changing it to keep up with the Debian code names. However, the

versions available in the repository are compatible with any Debian release since 3.1.

After updating your cache file, Webmin can be installed and maintained using apt-get, aptitude, or Synaptic. Also, ifyou request a Webmin upgrade from within Webmin itself on a Debian system, it will use the proper Debian package to upgrade.

This is the simplest and fastest method to install one or a few packages and their dependencies, but it requires that you know what packages you want to install. There are several utilities that can be used to search package names and descriptions, which will provide you with the means to find the proper package names. The most common of these is apt-cache. Once you know what package or packages you want to install, you can use apt-get or the command line format of aptitude or dselect to quickly download and install the packages.

System security is one of the most important duties of an administrator. Ensure that your system is protected by setting up proper policies for users and groups, and hardening your systems (especially servers) when exposed to attack from the Internet. Firewall tools are useful in blocking attacks, and intrusion detection should be used to discover any system anomalies as early as possible.

We've now been through pretty much all of the major administrative areas of Debian Linux, not counting individual software suites. Next, we will cover some advanced administration techniques.

Disk encryption comes in several flavors. Full disk encryption, where the entire contents of the storage device are encrypted, is handled by hardware in the disk drive itself, or on the system's motherboard. This is because the code necessary to decrypt the disk can't really reside on the disk, since it will be in encrypted form and thus can't be loaded until decrypted. Since this method depends on the motherboard or disk software, which varies with manufacturer, it won't be covered here.

A non-hardware method does exist, using an unencrypted USB stick or other media to provide the boot code, but requires special steps for creating the boot media that won't be covered here either.

Partial disk encryption, where individual partitions are encrypted, can be handled by Linux directly. There must be some unencrypted area from which the decryption software and keys can be loaded. This usually means an unencrypted boot partition, or booting from an unencrypted USB stick, thus getting the initial decryption software loaded and then chain loading from the encrypted disk. The keys themselves are encrypted by a password or pass phrase that is required at boot time to keep the keys secure.

A special case would be encrypting the swap partition. Ifthere is any page swapping, or ifhibernation (suspend to disk) is used, information in memory can be exposed to anyone who can read the partition. For this reason, many administrators encrypt the swap partition.

Disk encryption is appropriate for laptops, or for separate partitions on servers that contain sensitive data.

One of the first things to consider is how to set up user groups and how to manage the root account. Although this can be changed any time, it should be done just after installation when changes will have less impact. The two basic issues are how to set up default user group assigrunent, and whether the root account should be disabled.

XFS is another alternative, developed by Silicon Graphics in 1993. It is a high-speed JFS, with emphasis on parallel input/output (I/O). The NASA Advanced Supercomputing Division uses this format on their 300+ terabyte Altix storage servers. Metadata operations are somewhat slower than other formats, although this was improved somewhat with the changes made by Red Hat. This is a good choice where metadata changes very little (such as few file or directory creation, move, or delete operations) and I/O performance is of utmost importance.

Maintenance involves running the Filesystem Check program (FSCK). Ifthe system is rebooted frequently, as is the case with laptops or workstations, or the partition is unmounted and mounted frequently, this will normally happen automatically. EXT3 and EXT4 filesystems default to every 39 mounts when originally created unless otherwise requested. This may be changed using the tune2fs utility which can also set a time-dependent check interval instead of mount count dependent.

Although it is possible, periodic checking should not be disabled. Joumaling filesystems in general are always marked clean and so Linux will not recognize when such a system may have problems.

Ifyour system is always up and the partition in question is never unmounted, you may want to arrange for a periodic reboot of the system, either via the shutdown -rF command that forces a filesystem check, or by using tune2fs to set a time-dependent check interval that is less than the reboot interval. Of course, ifproblems are found, you must have access to the physical console in order to answer the questions about how to fix them.

An alternative is to never check the filesystem except when problems are obvious or likely. Normally, after a failure that could potentially cause filesystem infrastructure errors, the system will need to be rebooted anyway, if it isn't forced. This is the time to run the FSCK manually in maintenance (single user) mode, or to force the check by having a short, time-dependent check interval set. Again, ifproblems arise, someone will need access to the physical console in order to answer questions.

To speed up periodic filesystem checks, use EXT4 instead of EXT3. Inmost circumstances, checks are anywhere from 2 to 20 times faster for EXT4.

One of the best examples of how careful Debian is about licensing issues involves the Mozilla suite of software, which includes the Thunderbird mail reader and the popular Firefox browser. A whole chapter could be written on the history of the dispute and the issues involved. However, the basic problem is that the Mozilla artwork is not under a free license as defined by the Debian guidelines. For a while, Debian was allowed to use other artwork, but eventualy the Mozilla Corporation withdrew that permission. Some of the reasons this changed included the way the Debian developers compiled the software to comply with their policies and the social contract.

After a long argument, the Debian project determined that the best approach was to rename the software, as allowed by the Mozilla license, so it would remain compatible with the DFSG. Thunderbird in Debian is now called Iceowl, and Firefox is called Iceweasel.

The names evolved from early discussions when Iceweasel was used to describe a hypothetical re-branded version. The name stuck. Other Mozilla software was renamed in a similar fashion.

The advantages for administrators include the following:

• The Debian version is unencumbered by non-free licensing.
• Bugs are frequently fixed by the Debian maintainers more quickly. These patches are passed on to the Mozilla maintainers. This is actually required for all patches to any software by Debian developers by policy.
• Updates are managed via the Debian packaging framework rather than requiring a separate, proprietary update procedure.
• The software uses standard Debian system libraries rather than installing Mozilla's separate libraries.
• The software will run on the various Debian supported, non-Intel architectures. For example, do you have an old IBM z Series server? Debian Iceweasel will run on it. How about an old SG or Sparc workstation? Same story, Debian Iceweasel will run just fine.

Nevertheless, Debian Iceweasel is, for all practical purposes, Firefox. It offers the same look and feel, uses the same plugins, and identifies itself to servers as compatible with Firefox. The same is true for the rest of the re-branded Mozilla software.

The Plugin Search feature is modified in Debian to seek only free plugins, but I've never found this to be a problem. Non-free plugins can still be installed at the user's own discretion, and will work.

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.