Debian GNULinux Idiosyncrasies
|
| < Free Open Study > |
|
Debian GNU/Linux Idiosyncrasies
This section will describe some aspects or features that are unique to Debian GNU/Linux. So far, you've seen that Debian GNU/Linux is quite similar to Red Hat Linux and Slackware Linux, but that a few minor differences exist in some areas. This section outlines a few more significant differences that you need to be aware of when using a Debian GNU/Linux system.
Touring the /etc Directory
Generally, you'll find everything in /etc that you would expect to find. There are a few things worth paying special attention to, though. Table 6-7 lists some noteworthy subdirectories of /etc that you should know about. The list does not include the common subdirectories defined by the Filesystem Hierarchy Standard (such as /etc/X11 and /etc/init.d), only Debian-specific directories. Each entry in Table 6-7 is discussed in the text that follows, except for /etc/alternatives, which has a whole section devoted to it later.
 |
| DIRECTORY | CONTENTS |
|---|---|
| /etc/default | Files containing configuration information for various programs |
| /etc/network | Files related to configuring the network interfaces |
| /etc/dpkg | Configuration information for the dpkg tool |
| /etc/alternatives | Symbolic links that choose defaults between certain programs |
|
The /etc/default Directory
This directory contains files that set values to variables used by other scripts. Typically, any time a program or script needs to have values assigned to it that are specific to the installation, the variables are placed in a file in /etc/default and the script or program reads this file to determine its settings. This way, administrators don't have to edit the script itself to tweak the settings. (Actually, this is a different solution to the same problem that inspired Red Hat to use the "drop-in config directory" approach discussed throughout Chapter 4.)
For example, Linux 2.4 kernels support the iptables functionality, which allows administrators to create firewalls, among other things. (See Chapter 16 for an example of a Linux-based firewall using iptables.) Using iptables requires that some variables be set. So, the script provided by Debian that sets up iptables reads these values from /etc/default/iptables rather than requiring the administrator to modify the /etc/init.d/iptables script directly.
Since the only files in this directory will be placed there by individual packages, the contents of this directory will obviously vary by which packages are installed. Whenever you install a new Debian package, be sure to check /etc/default to see if is contains a file to modify. Of course, you should always read all the documentation for the software as well.
The /etc/network Directory
This directory is similar to /etc/default in that it contains configuration information for the networking system. However, the network-related files were placed here to keep them all in one place and to prevent them from getting mixed in with other files in a confusing bundle. This directory is analogous to /etc/sysconfig/network on Red Hat Linux systems, though its contents are different.
The /etc/network directory is installed by the ifupdown and netbase packages. Table 6-8 lists the typical contents of /etc/network.
|
| FILE OR DIRECTORY | PURPOSE |
|---|---|
| if-down.d | Holds scripts to run when a network interface is brought down |
| if-post-down.d | Holds scripts to run after an interface has been brought down |
| if-up.d | Holds scripts to run when an interface is brought online |
| if-pre-up.d | Holds scripts to be run before an interface is brought online |
| ifstate | Contains information on whether each network device is up or down |
| interfaces | Contains network configuration information for all interfaces |
| options | Enables or disables various optional networking features |
| spoof-protect | Enables or disables protection from network spoofing attacks |
|
Generally, the files you're most likely to interact with will be interfaces and options. The interfaces file contains detailed network information (such as IP address, netmask, and gateway, or whether to use Dynamic Host Configuration Protocol [DHCP]) for each interface that the system is to use. By editing the contents of this file, you can control most aspects of your system's network configuration. The only other file you're likely to need to interact with is options, which enables or disables additional general networking options, such as whether to configure the kernel to act as a network router by forwarding IP packets. An excellent manual page for the /etc/network/interfaces file is provided; simply type man interfaces and you'll have all the information you need to configure your system's network interfaces.
The other files in /etc/network are for cases where administrators need more advanced capabilities. For example, the if-down.d, if-up.d, if-pre-up.d, and if-post-down.d directories provide administrators with a way to hook scripts into the process of activating and deactivating network interfaces, in order to log such events, for example. (These directories implement the common config.d configuration directory approach discussed throughout Chapter 4.) Similarly, the /etc/network/spoof-protect file allows administrators to set parameters that are used to detect network spoof attacks. (This file may actually no longer be needed by recent kernels.) Finally, the /etc/network/ifstate file is internal to the ifup and ifdown scripts and is used to indicate which interfaces are active and which are not. Again, generally you won't need to work with these files, but it's good to know they're there if you do need them someday.
The /etc/dpkg Directory
This directory contains files that configure the dpkg and dselect programs. The dpkg.cfg and dselect.cfg files can be used to set default options for dpkg and dselect, so that they don't have to be entered on the command line each time the programs are run. The origins directory contains files that describe where the particular distribution originated. (This is typically used by the various organizations that provide variants of the base Debian distribution.) The shlibs.default and shlibs.override files can be used to tweak the shared libraries used by dpkg (such as when upgrading core system libraries like glibc). This is a rather arcane area, and you shouldn't mess with it unless you know what you're doing!
Understanding the /etc/alternatives Directory
The /etc/alternatives directory, listed in Table 6-7, establishes default programs in cases where more than one program may be installed that fulfills a certain purpose.
For example, probably the most ubiquitous Unix text editor is the vi program. However, there are a number of free implementations of vi, such as Vi Improved (vim), nvi, and elvis. Typically, whenever one of these programs is installed, a symbolic link is created to run the vi clone every time a user types the command vi. (That is, /bin/vi is usually a symbolic link to one of those programs.) However, a given Debian installation could have several or all of these installed at the same time. When that's the case, how do you choose which vi clone gets to masquerade as the "real" vi? Obviously, you simply must choose one and make it the default.
This scenario happens fairly frequently. In addition to the vi example just mentioned, there are multiple implementations of the awk program (including gawk), the yacc program (including bison and byacc), and so on. In fact, this happens so frequently that the Debian Project created the /etc/alternatives and the "update-alternatives" system around it.
The purpose of the /etc/alternatives directory is simply to indicate which clone of a particular program is to be the "real thing" on the system. The real program in the filesystem is actually a symbolic link to the /etc/alternatives directory, and the file there is in turn a symbolic link to the clone. Going back to the vi example, suppose nvi and vim are installed, and that vim is to be configured as the real vi on the system. To implement this configuration, /etc/alternatives/vi is linked to point at /usr/bin/vim. The actual /usr/bin/vi file, meanwhile, is symbolically linked to point at /etc/alternatives/vi. The /usr/bin/vi file never changes; to switch to a different clone, you only change the /etc/alternatives/vi file.
The /etc/alternatives directory actually handles more than just the program itself; it also handles man pages. (After all, it doesn't do you any good to have vim as your vi clone but get nvi's manual page when you type man vi!) The mechanism for the manual pages is very similar to that of the programs; the "real" man pages in the /man and /usr/man directories are symbolically linked to point to /etc/alternatives, where they are in turn symbolically linked to the man page for a clone.
As you can probably tell, it would quickly get annoying to manage all these symbolic links. To address this, Debian GNU/Linux also includes the update-alternatives program, which manages the symbolic links in /etc/alternatives for you in much the same way that update-rc.d (and chkconfig on Red Hat Linux) manage the SysV init symbolic links. The update-alternatives program is easy to use, so check its manual page (man update-alternatives) for full details.
Configuring the X Display Manager
The X display manager is the program that allows users to log in directly to X via a graphical user interface. Several programs are available that act as X desktop managers; notably, KDE and GNOME each have one, named kdm and gdm. This section discusses how to configure Debian GNU/Linux to use kdm or gdm as the X display manager.
Red Hat Linux and Slackware Linux both start the X display manager from /etc/inittab. Specifically, Red Hat has a program known as prefdm that is invoked directly from /etc/inittab and is responsible for choosing the default desktop manager (usually gdm or kdm) to use; similarly, Slackware starts a very simple shell script (/etc/rc.d/rc.4) from /etc/inittab that selects the display manager dynamically and runs it. Debian does things a little differently, however.
| Cross-Reference | See Chapters 4 and 5 for details on Red Hat's and Slackware's techniques. |
Debian starts the display manager as a normal SysV service. Each package containing a display manager installs its own SysV script in /etc/init.d. For example, gdm and kdm install /etc/init.d/gdm and /etc/init.d/kdm, respectively. Debian is then able to treat these scripts as standard SysV init services, and doesn't need to have an entry in /etc/inittab for them.
A potential problem with this approach can arise if both gdm and kdm are installed; the system has to choose between them since they both can't run at the same time. To avoid such conflicts, both init scripts are written to check the file /etc/X11/default-display-manager, which contains the path of the official default display manager for the system. The gdm and kdm init scripts check this file to determine whether they should run; as a result, only one will run at a time.
So, to change the default display manager on Debian GNU/Linux, you must edit the /etc/X11/default-display-manager file. This file contains a single line, which is the path to a desktop manager program—for example, /usr/bin/gdm. Simply change this program name to something like /usr/bin/kdm.
Now that you know how to do this by hand, you should know about the tool that automates it. When you actually install two display managers on the system, Debian's package manager will prompt you to select which one you want. In order to change display managers, then, you can simply have dpkg reconfigure one of the packages; the command shown shortly demonstrates how to do this. When you run it, you'll be prompted to select your display manager again. Of course, all this program is doing is modifying the contents of /etc/X11/default-display-manager, so it's really a question of which method is faster. The command to have dpkg reconfigure the display manager is as follows:
$ dpkg-reconfigure gdm
Securing the System
As with Slackware Linux, Debian GNU/Linux leaves many services running in a default installation. It's very important to remove unneeded services, or else you risk letting your system be compromised by an attacker, especially if your system is connected to the open Internet. This section will discuss how to lock down your system.
Shutting Down Unneeded SysV Services
Typically, if you install a Debian package that is started by the SysV init system, it will be configured to start by default. As a result, depending on how carefully you selected your packages when you installed the system, you may have a number of services running that you don't need. Some of these, such as the portmap and NFS statd program, have a history of security vulnerabilities, so it makes sense to shut them off.
On Red Hat Linux, the chkconfig program can be used to easily view which SysV services are configured to run and which are not for each runlevel. Unfortunately, it doesn't seem to be quite that easy on Debian GNU/Linux. In order to tell if a service is configured for a given runlevel, you actually have to check the symbolic links in the appropriate runlevel directory. For example, to see what's configured to run in runlevel 2, you would have to issue the command ls/etc/rc2.d; any files that start with a "K" are configured to be stopped in that runlevel, and any that start with an "S" are configured to be started.
| Cross-Reference | For full details on how the SysV init system works, see the section "System Startup Scripts" in Chapter 4. |
Once you've seen what's running, you have to decide what needs to be running and what doesn't. Generally, if you don't need a service, you should shut it off, to prevent exposing yourself to a potential future vulnerability in a program you don't even need. To actually configure a service to not run, you can either modify the symbolic links by hand (as discussed in Chapter 4), or you can use the update-rc.d program as discussed earlier in this chapter.
Removing inetd Services
Debian uses a traditional implementation of inetd. (It's the same implementation used by Slackware Linux; contrast this with Red Hat Linux, which uses the alternative xinetd program instead.) Like Slackware, Debian's default inetd configuration comes with a number of services enabled by default. As always, it's a good idea to disable services you don't need.
Using the update-inetd Program
To disable services, you can use the exact same techniques discussed in the section "Configuring Inetd" in Chapter 5. However, Debian also provides an additional tool called update-inetd. This program is similar to Red Hat's chkconfig and Debian's update-rc.d, except that it works strictly on inetd services configured in the /etc/inetd.conf file. This program makes it fairly easy to add new entries to /etc/inetd.conf (such as when you install a new inetd service on the system; see Chapter 12 for an example of this) as well as enabling and disabling existing services. (For example, you may wish to disable the CVS service from running while you perform maintenance, but you don't want to remove the entry entirely.) The update-inetd program also allows you to delete entries from /etc/inetd.conf outright.
When update-inetd is run, it's simply taking the actions discussed in Chapter 5, so you don't have to do them manually. The update-inetd program will actually be discussed more in Chapter 12, so I won't discuss it here in much detail. However, to use it to disable inetd services for security purposes, follow this example, which disables the finger service:
$ update-inetd --disable finger
Just repeat this command for each service you wish to disable! If you find that you don't need any inetd services running at all, then you should disable the inetd SysV service entirely by using the technique mentioned in the previous section. (Note: To see which services are currently enabled, you will have to look at the contents of /etc/inetd.conf and find the lines defining services. See Chapter 5 for details.)
|
| < Free Open Study > |
|
EAN: 2147483647
Pages: 159