TIP All shells configured identically
Users often want to configure their login and interactive shells in the same way. To do this, they choose to interpreter (or “source”) the content from ~/.bashrc in the ~/.bash_profile file. It is possible to do the same with files common to all users (by calling /etc/bash.bashrc from /etc/profile).
8.7. Printer Configuration
Printer configuration used to cause a great many headaches for administrators and users alike. These headaches are now mostly a thing of the past, thanks to the creation of cups, the free print server using the IPP protocol (Internet Printing Protocol).
This program is divided over several Debian packages: cups is the central print server; cups-bsd is a compatibility layer allowing use of commands from the traditional BSD printing system (lpd daemon, lpr and lpq commands, etc.); cups-client contains a group of programs to interact with the server (block or unblock a printer, view or delete print jobs in progress, etc.); and finally, cups-driver-gutenprint contains a collection of additional printer drivers for cups.
COMMUNITY CUPS
CUPS (Common Unix Printing System) is a trademark filed by the Easy Software Products company, when cups was created.
→ http://www.easysw.com/
NOTE CUPS and CUPSYS
The packages containing cups are currently called cups, cups-client, cups-bsd, etc. In the Debian versions before Lenny, the packages had names built on the basis of cupsys. You may still find transition packages installed on some relatively old machines that have been updated over time.
After installation of these different packages, cups is administered easily through a web interface accessible at the local address: http://localhost:631/. There you can add printers (including network printers), remove, and administer them. You can also administer cups with the system-config-printer graphical interface (from the Debian package of the same name), which is installed by default if the “Desktop environment” task is chosen.
NOTE Obsolescence of /etc/printcap
cups no longer uses the /etc/printcap file, which is now obsolete. Programs that rely upon this file to get a list of available printers will, thus, fail. To avoid this problem, delete this file and make it a symbolic link (see sidebar BACK TO BASICS Symbolic links) to /var/run/cups/printcap, which is maintained by cups to ensure compatibility.
8.8. Configuring the Bootloader
It is probably already functional, but it is always good to know how to configure and install the bootloader in case it disappears from the Master Boot Record. This can occur after installation of another operating system, such as Windows. The following information can also help you to modify the bootloader configuration if needed.
BACK TO BASICS Master boot record
The Master Boot Record (MBR) occupies the first 512 bytes of the first hard disk, and is the first thing loaded by the BIOS to hand over control to a program capable of booting the desired operating system. In general, a bootloader is installed in the MBR, removing its previous content.
8.8.1. Identifying the Disks
CULTURE udev, devfs and /dev/
The /dev/ directory traditionally houses so-called “special” files, intended to represent system peripherals (see sidebar BACK TO BASICS Device access permissions). /dev/hda1 thus always corresponds to the first partition of the the first IDE hard drive. This static structure does not allow dynamic setting of “major” and “minor” numbers for these files, which forces kernel developers to limit their number, since a priori assignment of the identifiers prohibits adding more once these conventions are established.
To take into account the characteristics of more and more dynamic, modern computers, the kernel has, at some time, offered an implementation of /dev/ by a virtual filesystem called defvs. In some cases, this makes it easier to find files, since the naming convention uses a hierarchal structure: the first partition of the master hard drive on the first IDE bus was then represented by the file, /dev/ide/host0/bus0/target0/lun0/part1. Not only were these naming conventions not very intuitive, but they were also hard-coded into the kernel which presented problems for hot-pluggable drives because the corresponding special file name would vary.
The current solution is the second incarnation of the process, udev, with which the kernel delegates the choice of the device file names to be created to a program in user space. This program (udevd) can then have all of the flexibility of user space to decide what actions to take, naming of peripherals, etc.
With udev (user-space /dev/), a filesystem is stored in RAM and generated automatically by udevd (and it hides the content of any /dev/ that may be stored on-disk). udevd collaborates with the kernel's hotplug sub-system (see Section 9.11, “Hot Plugging: hotplug”) to detect the appearance (hotplugging) of devices, then dynamically creates the corresponding special files in /dev/. The content of /dev/ is, thus, lost on each reboot, but udev recreates it systematically.
This mechanism allows the machine to dynamically choose the file name. You can thus keep the same name for a given device, regardless of the connector used or the connection order, which is especially useful when you use various USB peripherals. The partition system on the first IDE hard drive can then be called /dev/hda1 for backwards compatibility, or /dev/root-partition if you prefer, or even both at the same time since udevd can be configured to automatically create a symbolic link. Furthermore, /dev/ no longer contains useful files at this time. Previously, some kernel modules did not automatically load when you tried to access the corresponding peripheral; henceforth, the peripheral's special file no longer exists prior to loading the module, which is no big deal, since most modules are loaded on boot thanks to automatic hardware detection. But for undetectable peripherals (such as older disk drives or PS/2 mice), this doesn't work. Consider adding the modules, floppy, psmouse and mousedev to /etc/modules in order to force loading them on boot.
Configuration of the bootloader must identify the different hard drives and their partitions. Linux uses a special filesystem (in “block” mode) stored in the /dev/ directory, for this purpose. Historically, /dev/hda was the master disk on the first IDE controller, and /dev/hdb its first slave, /dev/hdc and /dev/hdd being, respectively, the master and slave disks on the second IDE controller, and so on down for any others. /dev/sda corresponded to the first SCSI drive, /dev/sdb being the second, etc. This naming scheme has been unified with the Linux kernel present in Squeeze, and all hard drives (IDE/PATA, SATA, SCSI, USB, IEEE 1394) are now represented by /dev/sd*.
Each partition is represented by its number on the disk on which it resides: for instance, /dev/sda1 is the first partition on the first disk, and /dev/sdb3 is the third partition on the second disk.
The PC architecture (or “i386”) is limited to four “primary” partitions per disk. To go beyond this limitation, one of them must be created as an “extended” partition, and it can then contain additional “secondary” partitions. These secondary partitions must be numbered from 5. Thus the first secondary partition could be /dev/sda5, followed by /dev/sda6, etc.