LAC Logo Order online or call 866-865-9498
Contact | FAQ | Privacy | Home
Sat May 24 21:51:04 MDT 2008

Every LAC desktop, laptop, or server system comes with 30 days of free e-mail Linux technical support to assist with system integration. Contact us with questions or comments related to this page or to your LAC computer. We provide the following information "as-is", without warranty or guarantee, as a service to the community and to our customers.

Distribution Specific Tips

General Administrative Tips

General User Tips

Dual Boot Tips


Starting and Stopping Network Services in Red Hat and Fedora

In a Red Hat-based system, one can find start/stop scripts for services in /etc/rc.d/init.d (a directory, which is typically symlinked as /etc/init.d). Common examples include crond, sshd, and gpm. One can make a service start or stop at boot using chkconfig. The syntax for chkconfig is

# chkconfig <service name> <on|off>
(<service name> must correspond to a script in /etc/rc.d/init.d) For example, to make sshd not start at boot, do

# chkconfig sshd off

chkconfig does not start and stop services -- it merely sets whether or not a service will start or not at boot. Services can be started and stopped (and more) with service. The general syntax is:

# service <service name> <start|stop|status|restart|reload>
For example, to stop sshd, do

# service sshd stop
To cause a running sshd to reread its configuration file, do

# service sshd reload

back to top

Starting and Stopping Network Services in Debian and Ubuntu

In a Debian-based system, one can find start/stop scripts for services in /etc/init.d. Common examples include crond, ssh, and gpm. One can configure a service to start or not at boot using update-rc.d, or by manipulating symlinks found in /etc/rcN.d (N = run level). See the file README in /etc/init.d in your Debian system, and read update-rc.d(8).

For example, to keep Exim from starting in run level 2, do

# rm /etc/rc2.d/S??exim
To make sshd start at boot in run levels 2, 3, 4, and 5 (sequence 30) and stop in run levels 0, 1, and 6 (sequence 20), do

# update-rc.d ssh start 30 2 3 4 5 . stop 20 0 1 6 .
Note that for the update-rc.d example to work, no start/stop links for ssh can be present; i.e. first do

# rm /etc/rc?.d/???ssh

back to top

Configuring a Network Card in Red Hat and Fedora

In a GNU/Linux system, a NIC (ethernet card, typically) is generally referred to as ethN, starting at N = 0. There are usually GUI or menu-driven tools for NIC configuration, and there are always text files one can edit to configure NICs.

Starting and Stopping Networking

In a Red Hat-based system, the text file /etc/sysconfig/network-scripts/ifcfg-ethN is used to configure interface ethN. Before making changes to ifcfg-ethN, one should bring down ethN by doing
# ifdown ethN
                

When done editing ifcfg-ethN, bring ethN back up by doing
# ifup ethN
                

The command

# service network restart
is used to restart networking; in a Red Hat system, this is equivalent to

# /etc/init.d/network restart
This will bring down all network interfaces and then bring up those configured to start at boot. If one desires to have ethN start at boot, put the line

ONBOOT=yes
in ifcfg-ethN.

Configuring for DHCP

To use DHCP (for a dynamic IP address) for ethN, use the following ifcfg-ethN:

DEVICE=ethN
BOOTPROTO=dhcp
ONBOOT=yes
USERCTL=no
The USERCTL line is optional. USERCTL=yes allows non-root users to start and stop ethN.

Configuring a Static IP Address

To use a static IP address, one must know the following:

  • IP address,

  • netmask (frequently 255.255.255.0), and

  • IP address of at least one name server.

If the desired IP address for ethN is 1.2.3.4, the netmask is 255.255.255.0, and ones assigned name servers are 2.3.4.5 and 3.4.5.6, one should make ifcfg-ethN look like:

DEVICE=ethN
BOOTPROTO=static
IPADDR=1.2.3.4
NETMASK=255.255.255.0
ONBOOT=yes
USERCTL=no
and one should make /etc/resolv.conf look like:

nameserver 2.3.4.5
nameserver 3.4.5.6
If, in addition, one has network, broadcast, and gateway values, one can add these to ifcfg-ethN. For example, a complete ifcfg-ethN entry for ethN might look like:

DEVICE=ethN
BOOTPROTO=static
IPADDR=1.2.3.4
NETMASK=255.255.255.0
BROADCAST=1.2.3.255
NETWORK=1.2.3.0
GATEWAY=1.2.3.1
ONBOOT=yes
USERCTL=no

None of the changes to ifcfg-ethN will take effect until the affected network interfaces are restarted.

back to top

Configuring a Network Card in Debian and Ubuntu

In a GNU/Linux system, a NIC (ethernet card, typically) is generally referred to as ethN, starting at N = 0. There are usually GUI or menu-driven tools for NIC configuration, and there are always text files one can edit to configure NICs.

Starting and Stopping Networking

In a Debian-based system, the text file /etc/network/interfaces is used to configure NICs. Before making changes to interfaces that will affect ethN, one should bring down ethN by doing
# ifdown ethN
                

When done editing interfaces, bring ethN back up by doing
# ifup ethN
                

The command

# /etc/init.d/network restart
is used to restart networking. This will bring down all network interfaces and then bring up those configured to start at boot. If one desires to have ethN start at boot, put the line

auto ethN
in interfaces. It is possible to specify more than one interface in an auto line; e.g.

auto lo eth0 eth1

Configuring for DHCP

To use DHCP (for a dynamic IP address) for ethN, put the following entry in interfaces:

iface ethN inet dhcp

Configuring a Static IP Address

To use a static IP address, one must know the following:

  • IP address,

  • netmask (frequently 255.255.255.0), and

  • IP address of at least one name server.

If the desired IP address for ethN is 1.2.3.4, the netmask is 255.255.255.0, and ones assigned name servers are 2.3.4.5 and 3.4.5.6, one should make an entry in interfaces like:

iface ethN inet static
    address 1.2.3.4
    netmask 255.255.255.0
and one should make /etc/resolv.conf look like:

nameserver 2.3.4.5
nameserver 3.4.5.6
If, in addition, one has network, broadcast, and gateway values, one can add these to interfaces. For example, a complete interfaces entry for ethN might look like:

iface ethN inet static
    address 1.2.3.4
    netmask 255.255.255.0
    network 1.2.3.0
    broadcast 1.2.3.255
    gateway 1.2.3.1

None of the changes to interfaces will take effect until the affected network interfaces are restarted.

back to top

Installing and Removing Software with RPM

The most common way to manage software in a Red Hat, SuSE, or Mandrake system is to install binary RPM packages, using rpm at a command line, or using one of the GUIs for RPM.

Package Naming Conventions

File names for binary RPM packages typicall follow the convention

[package name]-[version].[architecture].rpm

For example,

kernel-2.4.18-3.i386.rpm

is the binary RPM file for package "kernel", version "2.4.18-3", architecture "i386" (or better).

Installing and Upgrading RPM Packages

One can install the RPM file /tmp/samplepackage-1.0.i386.rpm by doing

# rpm -ivh /tmp/samplepackage-1.0.i386.rpm
or

# rpm -Uvh /tmp/package-1.0.i386.rpm
If /tmp/updates/ is a directory containing binary RPM files (of package updates, say), update all packages that are currently installed by doing

# rpm -Fvh /tmp/updates/*.rpm
Consult rpm(8) for detailed info.

Uninstalling RPM Packages

To uninstall package samplepackage and delete its configuration files, do

# rpm -e samplepackage
If one had modified any of samplepackage's configuration files post-installation, the modified files are frequently left behind with an .rpmsave appended to the name of the modified config file.

RPM Query Examples

View information about and files contained in RPM package samplepackage that is already installed in ones system by doing

$ rpm -qil samplepackage
View information and file list for the binary RPM file /tmp/samplepackage-1.0.i386.rpm by doing

$ rpm -qilp /tmp/samplepackage-1.0.i386.rpm
Display package and version for the installed RPM from which came the file /bin/ls by doing

$ rpm -qf /bin/ls

back to top

Installing and Removing Software with APT

The typical way to manage software in a Debian-based system is to use binary Debian packages (ending in .deb), using apt-get or dpkg at the command line, or using GUIs such as synaptic, dselect, or aptitude. (Use care when running dselect for the first time; read documentation on keybindings, etc. available from within dselect first!) APT for RPM is maturing, and LAC installs and configures APT for RPM in Fedora systems, so one can use APT for software management in ones LAC system running Fedora.

Installing Software with apt-get

Tell APT where to get binary or source packages in the file /etc/apt/sources.list, typically using a mirror from the list at

http://www.debian.org/mirror/list

or at

http://www.debian.org/mirror/mirrors_full

(These are Debian mirror lists.) For example, if a mirror ftp.m.com has the Debian archive available at /debian by anonymous FTP. To use this location to download and install (free) testing packages, put the line

deb ftp://ftp.m.com/debian testing main contrib

in sources.list. After changing sources.list, activate the changes by doing

# apt-get update
One can install a package, Mozilla, say, by doing

# apt-get install mozilla
Many more details are available in apt-get(8).

Uninstalling Software with apt-get

One can uninstall software at the command line with apt-get. The output of

$ dpkg -l
shows currently installed packages; in column two, one can see the names of installed packages. Assuming package samplepackage is installed, uninstall it and its dependencies and purge its configuration files by doing

# apt-get remove --purge samplepackage
Uninstalling samplepackage and its dependencies can also be done with

# apt-get remove samplepackage
(no --purge) which leaves the configation files in place. In many cases, this will allow one to reinstall samplepackage without having to restore custom configurations.

Querying with dpkg

One can use dpkg at the command line to do a variety of useful package queries. For example, to see the files belonging to the binary Debian package file /tmp/samplepackage_1.0_i386.deb, do

$ dpkg -c /tmp/samplepackage_1.0_i386.deb
To see the list of files belonging to the installed package samplepackage, do

$ dpkg -L samplepackage
To determine from which installed package came the file /bin/ls, do

$ dpkg -S /bin/ls

Searching for Packages with apt-cache

apt-cache is a useful command line program for searching the list of available software, and for displaying information about available packages. For searching, basic usage is

$ apt-cache search [expression]
                

For example, to show packages with names or descriptions containing ``apache2'':

$ apt-cache search apache2
apache2-dev - Development headers for apache2
libapache2-mod-auth-pam - Module for Apache2 which authenticate using PAM
libapache2-mod-auth-plain - Module for Apache2 which provides plaintext authentication
libapache2-mod-auth-sys-group - Module for Apache2 which checks user against system group
libapache2-mod-macro - Create macros inside apache2 config files
libapache2-mod-xslt - An apache2 module that does on-the-fly XSLT processing
apache2-common - Next generation, scalable, extendable web server
apache2-doc - Documentation for apache2
apache2-mpm-perchild - Experimental High speed perchild threaded model for Apache2
apache2-mpm-prefork - Traditional model for Apache2
apache2-mpm-threadpool - Experimental High speed thread pool model for Apache2
apache2-mpm-worker - High speed threaded model for Apache2
apache2-prefork-dev - Development headers for apache2
apache2-threaded-dev - Development headers for apache2
libapache-mod-dav - A DAV module for Apache
libapache2-mod-perl2 - Integration of perl with the Apache2 web server
libapache2-mod-python - An Apache module that embeds Python within the server
libapache2-mod-python-doc - An Apache module that embeds Python within the server
libapache2-mod-python2.2 - An Apache 2 module that embeds Python 2.2 within the server
libapache2-mod-python2.3 - An Apache 2 module that embeds Python 2.3 within the server
libapache2-mod-security - Tighten the Web application security for Apache 2.x
libapache2-svn - Apache modules for Subversion - in development, alpha
libapr0 - The Apache Portable Runtime
                

And to show information about package apache2-common:

$ apt-cache show apache2-common
Package: apache2-common
Priority: optional
Section: net
Installed-Size: 3164
Maintainer: Debian Apache Maintainers 
Architecture: i386
Source: apache2
Version: 2.0.48-4
Depends: libapr0 (>= 2.0.48), libc6 (>= 2.3.2.ds1-4), libdb4.1,
         libexpat1 (>= 1.95.6), libldap2 (>= 2.1.17-1), libssl0.9.7,
	 zlib1g (>= 1:1.1.4), debconf, debianutils (>= 1.6), mime-support,
	 openssl, net-tools, ssl-cert
Suggests: apache2-doc
Filename: pool/main/a/apache2/apache2-common_2.0.48-4_i386.deb
Size: 808280
MD5sum: 596426e6dd733776c02e2c2b367a6776
Description: Next generation, scalable, extendable web server
 Apache v2 is the next generation of the omnipresent Apache web server. This
 version - a total rewrite - introduces many new improvements, such as
 threading, a new API, IPv6 support, request/response filtering, and more.
 .
 It is also considerably faster, and can be easily extended to provide services
 other than http.
 .
 This package contains all the standard apache2 modules, including SSL support.
 However, it does *not* include the server itself; for this you need to
 install one of the apache2-mpm-* packages; such as worker or prefork.
                

See apt-cache(8) for details about this useful program.

Further Resources

The official Debian APT HOWTO is available at

http://www.debian.org/doc/manuals/apt-howto/

A popular, up and coming resource for unofficial APT sources:

http://www.apt-get.org/

back to top

Introduction to Text Editors

One can usually find a GUI tool in each distribution to assist with system configuration; the GUI tools tend to vary per distribution, however. What is common in each Linux distribution is that configuration options are usually specified in text files, and one can tweak system settings by editing appropriate text files with a text editor. Popular text editors available in nearly every Linux distribution include Emacs, Pico (or GNU nano, a free Pico clone), and Vi (say "vee eye").

For beginners, we recommend Emacs or nano (or Pico), and we focus on the (extreme) basic functionality of these editors in this document. In the examples, we work on a file named sample.txt that exists in (or that is to be created in) ones home directory ~/. One should substitute pico for nano (and Pico for nano) below if one is using Pico and not nano.

Opening and Closing Files

One opens ~/sample.txt at the command line with Emacs by doing

$ emacs ~/file.txt
If one is in an X session, append an & to run Emacs in the background, thereby retaining usage of the command line from which the command was executed. Open ~/test.txt with nano by doing

$ nano ~/file.txt
Do not append an & in this case, for nano will run in the terminal window in which the command was executed. If one does accidently invoke nano in the background by appending an &, get back the the stopped nano session by doing

$ fg

In either of these editors, move the cursor with the arrow keys, and make desired changes with the keyboard. To save changes and exit, in Emacs do

Ctrl-x Ctrl-s Ctrl-x Ctrl-c

where, e.g. "Ctrl-x" means hold down a Control key and press the x key. To save and exit in nano, do

Ctrl-o (edit the file name if desired) Enter Ctrl-x

Further Resources

The Emacs home page is at

http://www.gnu.org/software/emacs/emacs.html

The nano home page is at

http://www.nano-editor.org/

Info about Pico is available at

http://www.washington.edu/pine/man/#pico

which, assuming Pine (the e-mail client) is installed in your system, is available at pico(1).

For those interested in Vi (it's really worth giving it a try, but read some documentation first!!), we suggest starting at

http://www.thomer.com/vi/vi.html

back to top

Managing Software RAID Arrays with mdadm

In this section, we present the bare essentials of the command mdadm, with which one can control every aspect (e.g. create, delete, inspect, maintain, monitor) of a software RAID array. mdadm software RAID arrays are highly preferred over proprietary software RAID arrays (e.g. using a Promise or Highpoint RAID card), because for one thing, software RAID disks can be used in any computer on any standard IDE or SATA controller. Software or hardware RAID can serve as a useful component in an overall data protection, backup, and recovery plan. RAID is not a data protection plan in itself.

mdadm has several modes of operation:

$ mdadm --help
mdadm is used for building, managing, and monitoring
Linux md devices (aka RAID arrays)
Usage: mdadm --create device options...
            Create a new array from unused devices.
       mdadm --assemble device options...
            Assemble a previously created array.
       mdadm --build device options...
            Create or assemble an array without metadata.
       mdadm --manage device options...
            make changes to an existing array.
       mdadm --misc options... devices
            report on or modify various md related devices.
       mdadm --monitor options...
            Monitor one or more array for significant changes.
       mdadm device options...
            Shorthand for --manage.

Creating Software RAID Arrays

mdadm can create arrays of RAID level 0 (striping, no redundancy, fast but dangerous for your data), 1 (mirroring, full redundancy), 4, 5, 6, and 10 (they latter four RAID levels offer redundancy). RAID levels are detailed in this Wikipedia article.

The --create argument (or -C) is used to create a RAID array. The devices in the array can be unpartitioned disks (e.g. /dev/sda, /dev/hda, whatever) or partitions (e.g. /dev/sda1, /dev/hda1), or other block devices (we focus on disks). We advise creating and using type fd RAID partitions to make it easier to look at a disk later and know that the disk was used in a RAID array (by looking at the partition table).

For example, these disks will be used for software RAID 1 arrays. They have identical partition tables, each with two software RAID partitions (type fd) and a swap partition:

# fdisk -l /dev/hda /dev/hdc

Disk /dev/hda: 251.0 GB, 251000193024 bytes
255 heads, 63 sectors/track, 30515 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1         262     2104483+  fd  Linux raid autodetect
/dev/hda2             263         328      530145   82  Linux swap / Solaris
/dev/hda3             329       30401   241561372+  fd  Linux raid autodetect

Disk /dev/hdc: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdc1               1         262     2104483+  fd  Linux raid autodetect
/dev/hdc2             263         328      530145   82  Linux swap / Solaris
/dev/hdc3             329       30401   241561372+  fd  Linux raid autodetect

Create a software RAID 1 array using /dev/hda1 and /dev/hdc1 like this:

# mdadm -C /dev/md0 --raid-level=1 --raid-devices=2 --spare-devices=0 /dev/hda1 /dev/hdc1

Upon successful creation, ``cat /proc/mdstat'' will show the mirroring in progress for block device /dev/mdN (N will be a number 0 or larger), and the array can be immediately formatted (with mke2fs, mkfs.ext3, etc.), mounted, and used. Generally, performance will be impacted until the mirroring is complete.

Inspecting and Activating Software RAID Arrays

How can one tell if a running system is using software RAID, or if a standalone disk was part of a software RAID array? If one is logged in to a system, the easiest way to tell if a system is using software RAID is to examine /proc/mdstat:

$ cat /proc/mdstat
Personalities : [raid1] 
md2 : active raid1 hdc3[1] hda3[0]
      241561280 blocks [2/2] [UU]
      
md0 : active raid1 hdc1[1] hda1[0]
      2104384 blocks [2/2] [UU]
      
unused devices: 
If there are entries for mdN devices (md0 and md1 exist in the output above), then the system is using software RAID. One can then use the df command to determine where the RAID volumes are mounted:

$ df -h | grep \/dev\/md
/dev/md0              2.0G  816M  1.2G  41% /
/dev/md1              230G   86G  144G  37% /home
The output above shows that /dev/md0 is mounted at / and /dev/md1 is mounted at /home.

mdadm in miscellaneous mode (i.e. mdadm --misc) can be used to aquire information directly from the RAID array:

# mdadm --query /dev/md0 
/dev/md0: 2.01GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail.

# mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90.03
  Creation Time : Sat Aug 13 15:25:41 2005
     Raid Level : raid1
     Array Size : 2104384 (2.01 GiB 2.15 GB)
    Device Size : 2104384 (2.01 GiB 2.15 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sat Mar  3 07:58:00 2007
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : 46f6c11f:129424d6:0b27e611:7c4e2011
         Events : 0.9017957

    Number   Major   Minor   RaidDevice State
       0       3        1        0      active sync   /dev/hda1
       1      22        1        1      active sync   /dev/hdc1

Use mdadm --misc --help to see all mdadm miscellaneous mode options.

Due to the availability of /proc/mdstat in a running system, it is generally easier to determine the presence of software RAID in a running system. If one has a standalone disk and wishes to determine if it was a part of a software RAID array, one can use fdisk and mdadm together for this purpose. First, to use fdisk to examine the partition table of the device of interest (/dev/hda in this example):

# fdisk -l /dev/hda

Disk /dev/hda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1         262     2104483+  82  Linux swap / Solaris
/dev/hda2             263       30401   242091517+  fd  Linux raid autodetect
This disk has one partition, hda2, that might be a part of a software RAID array. Examine any RAID details using mdadm:

# mdadm --examine /dev/hda2
dev/hda2:
          Magic : a92b4efc
        Version : 00.90.03
           UUID : a5f01882:efa40048:a9010604:3404e02c
  Creation Time : Sat Mar  3 22:10:01 2007
     Raid Level : raid1
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 0

    Update Time : Sat Mar  3 22:11:57 2007
          State : clean
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0
       Checksum : b60738f9 - correct
         Events : 0.10


      Number   Major   Minor   RaidDevice State
this     1       3        2        1      active sync   /dev/hda2

   0     0       0        0        0      removed
   1     1       3        2        1      active sync   /dev/hda2

The output indicates that this disk was the second component of a two disc software RAID 1 array. mdadm can be used to activate a single component of a RAID 1 (mirroring) array in order to mount it and recover data. More on that later.

Another possibility in the above example is that the disk has no partitions, but the block device /dev/hda itself is a part of a software RAID array. In that case, the partition table output will look like this:

# fdisk -l /dev/hda 

Disk /dev/hda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/hda doesn't contain a valid partition table

If we use mdadm to examine /dev/hda, we see this if it is not a component of a software RAID array:

# mdadm --examine /dev/hda
mdadm: No super block found on /dev/hda (Expected magic a92b4efc, got 00000000)
and we see this if it is a component of a software RAID array:

# mdadm --examine /dev/hda
/dev/hda:
          Magic : a92b4efc
        Version : 00.90.03
           UUID : db77843a:89811870:b4eb7c6a:64ee629e
  Creation Time : Sat Mar  3 22:17:22 2007
     Raid Level : raid1
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 0

    Update Time : Sat Mar  3 22:17:47 2007
          State : clean
 Active Devices : 1
Working Devices : 1
 Failed Devices : 1
  Spare Devices : 0
       Checksum : c25fdf8a - correct
         Events : 0.13


      Number   Major   Minor   RaidDevice State
this     0       3        0        0      active sync   /dev/hda

   0     0       3        0        0      active sync   /dev/hda
   1     1       0        0        1      faulty removed

Indeed, /dev/hda was the first component in a software RAID 1 array.

As mentioned above, mdadm can be used to activate an array discovered in this manner (so it can be mounted for data recovery, for example). Using the RAID 1 component /dev/hda above, one can activate an array containing that device with mdadm like this:

# mdadm /dev/md0 --assemble /dev/hda
mdadm: /dev/md0 has been started with 1 drive (out of 2).

# cat /proc/mdstat 
Personalities : [raid1] 
md0 : active raid1 hda[0]
      244198464 blocks [2/1] [U_]
      
unused devices: 

Maintaining Software RAID Arrays

In this section, we will use mdadm to hot add a partition to a degraded RAID 1 device and to remove a failing partition from a RAID 1 device. All array components (partitions) are in the same disk /dev/hda and this is for example purposes only. In a real environment, we advise building RAID arrays using components from different disks.

Here is a degraded RAID 1 array, to which we will add a partition:

# cat /proc/mdstat 
Personalities : [raid1] 
md0 : active raid1 hda2[0]
      87899520 blocks [2/1] [U_]
      
unused devices: 

In a RAID 1 array, the component (partition) to add must be at least as big as the active component, which is 87899520 blocks in this case. We will use /dev/hda3 from a disk with this partition table:

# fdisk -l /dev/hda

Disk /dev/hda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1         262     2104483+  82  Linux swap / Solaris
/dev/hda2             263       11205    87899647+  fd  Linux raid autodetect
/dev/hda3           11206       22148    87899647+  fd  Linux raid autodetect

Use mdadm to add /dev/hda3 like this. After successfully adding hda3, look at /proc/mdstat to see the device resyncing:

# mdadm /dev/md0 --add /dev/hda3
mdadm: hot added /dev/hda3

# cat /proc/mdstat 
Personalities : [raid1] 
md0 : active raid1 hda3[2] hda2[0]
      87899520 blocks [2/1] [U_]
      [>....................]  recovery =  0.0% (31744/87899520) finish=46.0min speed=31744K/sec
      
unused devices: 

We now use mdadm to remove component /dev/hda3 from the software RAID device constructed above. First fail the device (if it is not already failed), then remove it from the array. In the sequence of commands, we periodically examine /proc/mdstat to display the effects of our commands:

# mdadm /dev/md0 --fail /dev/hda3
mdadm: set /dev/hda3 faulty in /dev/md0

# cat /proc/mdstat 
Personalities : [raid1] 
md0 : active raid1 hda3[2](F) hda2[0]
      87899520 blocks [2/1] [U_]
      
unused devices: 

# mdadm /dev/md0 --remove /dev/hda3
mdadm: hot removed /dev/hda3

# cat /proc/mdstat 
Personalities : [raid1] 
md0 : active raid1 hda2[0]
      87899520 blocks [2/1] [U_]
      
unused devices: 

All of the RAID management maneuvers in this section can be done on an active, mounted RAID array.

Monitoring Software RAID arrays

When using software RAID arrays, it is very important to monitor the array status in order to know when a device failure has occured, putting ones RAID array in a degraded state. It must be known immediately when a disk failure above so that an administrator can take quick action using the techniques we demonstrated above.

mdadm can be run in --monitor mode and will send an e-mail notification when a software RAID array status changes. The notification e-mail address is generally set in the text file /etc/mdadm/mdadm.conf (this can vary per distribution).

First of all, the system must be able to send an e-mail to the notification address you choose. Assuming the address is sysop@domain.com, you should test the ability to send an e-mail to that address at the command line. If this works, then mdadm will be able to send a message to the same address:

$ echo "test message" | mail -s "test e-mail" sysop@domain.com

Next, configure mdadm to use that address. Edit the plain text file /etc/mdadm/mdadm.conf in your system, including this line:

MAILADDR sysop@domain.com

Upon changing this file, restart mdadm and then make sure it's running:

# /etc/init.d/mdadm restart
Stopping MD monitoring service: mdadm --monitor.
Starting MD monitoring service: mdadm --monitor.

# ps ax | grep mdadm
 8302 ?        Ss     0:00 /sbin/mdadm --monitor --pid-file /var/run/mdadm/monitor.pid --daemonise --scan --syslog

If one successfully completes the above steps, one should be notified by e-mail immediately in the event of a RAID status change.

Further Resources

The Linux Documentation Project Software-RAID HOWTO is online at

http://tldp.org/HOWTO/Software-RAID-HOWTO.html

back to top

Adding and Deleting User Accounts

User root

The root account is analogous to Administrator in Windows XP and should be used with care. Using the root account is not recommended other than when performing system maintenance. The root account has full read/write privileges on the file system; with one mistake, it is possible to render ones Linux side unbootable (by deleting an essential boot file, for example). One is unable to make such a mistake as a regular user, since one will have, at most, read-only access to critical boot files. It is a reasonable policy to always login as a regular user, and become root by doing

$ su -
for administrative purposes only (the "-" causes root's login files to be read, which typically causes system commands in /usr/sbin and /sbin to be in ones path).

Changing Passwords

User root can change the password for any user by doing

# passwd [username]
where one substitutes for [username] the name of the user whose password one intends to change. By executing passwd without arguments, a user can change ones own password. Only root can specify a user name with the passwd command.

Creating User Accounts

One can make user accounts with a GUI tool (which vary per GNU/Linux distribution), or at the command line with useradd. For example, if one does

# useradd -c "Jane User" -m -g users janeuser
followed by

# echo "change.me" | passwd --stdin janeuser
one will have created a user with login name janeuser, full name "Jane User" (by the -c), janeuser's home directory will be created (typically at /home/janeuser) and populated with default config files from /etc/skel (by the -m), and janeuser's password will be initialized to change.me. See useradd(8) for full details.

Deleting User Accounts

One can delete account janeuser and the associated home directory and mail spool (an mbox file named janeuser, typically in /var/spool/mail/ or /var/mail/) by doing

# userdel -r janeuser
The -r is the cause for ~/janeuser and for the janeuser mbox file to be purged from the system. Consult userdel(8) for full details.

back to top

Basic Masquerading/Firewalling with iptables

netfilter/iptables provides sophisticated packet filtering functionality in GNU/Linux systems running 2.4 or later kernels. This section is intended to demonstrate how to enable masquerading (to share an Internet connection with an internal network) using iptables.

Requirements

One must have two NICs in ones system running Linux 2.4 or 2.5, and netfilter/iptables must be enabled in the kernel (compiled in or modules). We refer to the NIC connected to the Internet as ext, and the NIC connected to the internal network as int.

Sample Script

If one sets variables int, ext, and ipaddr in the following script and executes it in ones system, ones Internet connection will be available to an internal network. This script is available by anonymous FTP at

ftp://ftp.laclinux.com/lac/scripts/firewall

One must be root, and iptables must be in ones path for the script to work (i.e. become root by doing "su -").

#!/bin/sh

# int belongs to the internal network.
# ext is connected to the Internet (e.g. eth0, ppp0).
int=eth1
ext=eth0

# If you use a static IP address for eth0 (connected to the Internet),
# put it in the quotes.  For DHCP, leave blank.
extip=""

# Enable IP forwarding.
echo "1" > /proc/sys/net/ipv4/ip_forward

# Flush all rules.
iptables -P INPUT ACCEPT
iptables -F INPUT
iptables -P OUTPUT ACCEPT
iptables -F OUTPUT
iptables -P FORWARD DROP
iptables -F FORWARD
iptables -t nat -F

#####
# Masquerade for internal network at int via ext.
iptables -A INPUT -i $ext -m state \
 --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $ext -o $int -m state \
 --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $int -o $ext -j ACCEPT

# Use SNAT for static ext interface, MASQUERADE for DHCP ext interface.
if [ -n "$extip" ]; then
        iptables -t nat -A POSTROUTING -o $ext -j SNAT --to-source $extip
else
        iptables -t nat -A POSTROUTING -o $ext -j MASQUERADE
fi

# Let anything in through int.
iptables -A INPUT -i $int -j ACCEPT
#####

# e.g. Uncomment this line allow incoming SSH.
#iptables -A INPUT -i $ext --protocol tcp --dport ssh -j ACCEPT

# Uncomment this line to respond to ping requests.
#iptables -A INPUT --protocol icmp --icmp-type echo-request -j ACCEPT

# REJECT (rather than DROP) remaining INPUTs
iptables -A INPUT -i $ext -p tcp -j REJECT
iptables -A INPUT -i $ext -p udp -j REJECT
          

Comments About the Script

As presented, port scans of a machine using the above script will reveal no open ports. By uncommenting the line

# iptables -A INPUT -i $ext --protocol tcp --dport ssh -j ACCEPT
          
and reexecuting the script, a port scan will show that the machine is listening on TCP port 22 (assuming sshd is running). One can use the command line program telnet to connect to TCP port 22 like this:

# telnet somehost.domain.com ssh
Connected to somehost.domain.com.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3p2 Debian-8
We can use "ssh" to specify the port rather than the port number 22 because there is an entry for ssh in /etc/services. Have a look at this file to see the port(s) associated with other services.

back to top

Manually Burning CDs and DVDs in a GNU/Linux System

Sub-topics:
CD-R[W]
DVD+R[W]/-R[W]

Our examples use cdrecord without dev (device) and speed (speed) options, which might not work in a general GNU/Linux system without a properly tuned cdrecord configuration file. The config file for cdrecord is either /etc/cdrecord.conf or /etc/default/cdrecord (it varies per release and/or per compile time options, and sometimes is not needed at all). If applicable, the proper file will be in place with proper entries for the recordable optical device in your new LAC system, so the examples below will work as-is. For complete details, see cdrecord(1).

CD-R[W]

CD writing is done with cdrecord (or wodim, both used at the command line) and with GUIs for cdrecord (k3b is a popular example). CD-RW discs are required for rewriting, and CD-R discs for one time writing.

Here is an example of how one can use cdrecord with mkisofs to burn files in a directory, e.g /tmp/burn, to a CD. First, use mkisofs to create an ISO image named, say, /tmp/image.iso with label MY_CD:

$ mkisofs -J -R -V MY_CD -o /tmp/image.iso /tmp/burn
(See mkisofs(8) for info on the command line options.)

If one is using a previously used CD-RW disc, first blank the CD-RW:

# cdrecord blank=fast
Finally, burn the ISO image to disc:

# cdrecord -dao -v -data /tmp/image.iso

A final, sometimes useful tip: One can mount an ISO image on the hard drive for inspection prior to burning it to a CD. The general syntax is

# mount -o loop /path/to/image.iso /mount/point
For example, to mount the ISO image /tmp/image.iso at the directory /mnt, one can do

# mount -o loop /tmp/images.iso /mnt
Then

$ ls /mnt
will display the contents of the image file. Make sure to remember and unmount the image when done. In the above example, unmount by doing

# umount /mnt
or

# umount /tmp/image.iso

DVD+R[W]/-R[W]

One must use dvd+rw-tools for using DVD+ or DVD- devices, which provides the commands dvd+rw-format, growisofs, dvd+rw-booktype, and dvd+rw-mediainfo. We provide source and binaries for the latest version of these tools by anonymous ftp at

ftp://ftp.laclinux.com/linux/utils/dvd+rw-tools/

One can obtain the source code for dvd+rw-tools and usage instructions at

http://fy.chalmers.se/~appro/linux/DVD+RW/

DVD media can be rewritten using growisofs or can be mounted and used like a 4.7 gig hard drive by applying a kernel patch available at the dvd+rw-tools home page linked above.

back to top

Remapping Keyboard Keys (Use the ``Windows'' Keys)

Why Bother?

Two common reasons are to switch functions between keys (many users like to swap the Caps Lock and the left Ctrl key), and to use otherwise inactive keys (e.g. the ``Windows'' key on a standard PC-104 keyboard).

Gather Data on Target Keys

We assume you are running X.org -- this info applies for a keyboard used with X.org. We will implement the keyboard changes with xmodmap.

We are interested in the keycode number and in the keysym value, which one can get from xev. One can launch xev from an xterm, put the mouse pointer in the resulting box, and press the target key. The keycode number and the keysym value will appear in the xterm from which xev was launched. For example, the PC-104 keyboard I am using has left and right ``Windows'' keys and a ``menu'' key. Pressing these keys in sequence (plus the A key and the left Shift key for comparison) gives the following xev output.

Left ``Windows'':

KeyPress event, serial 25, synthetic NO, window 0x2200001,
    root 0x8d, subw 0x0, time 197960873, (2,133), root:(1085,257),
    state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:  ""
 
KeyRelease event, serial 25, synthetic NO, window 0x2200001,
    root 0x8d, subw 0x0, time 197960952, (2,133), root:(1085,257),
    state 0x40, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:  ""
                

Right ``Windows'':

KeyPress event, serial 25, synthetic NO, window 0x2200001,
    root 0x8d, subw 0x0, time 197961027, (2,133), root:(1085,257),
    state 0x0, keycode 116 (keysym 0xffec, Super_R), same_screen YES,
    XLookupString gives 0 bytes:  ""
 
KeyRelease event, serial 25, synthetic NO, window 0x2200001,
    root 0x8d, subw 0x0, time 197961148, (2,133), root:(1085,257),
    state 0x40, keycode 116 (keysym 0xffec, Super_R), same_screen YES,
    XLookupString gives 0 bytes:  ""
                

``menu'':
 

KeyPress event, serial 25, synthetic NO, window 0x2200001,
    root 0x8d, subw 0x0, time 197961334, (2,133), root:(1085,257),
    state 0x0, keycode 117 (keysym 0xff67, Menu), same_screen YES,
    XLookupString gives 0 bytes:  ""
 
KeyRelease event, serial 25, synthetic NO, window 0x2200001,
    root 0x8d, subw 0x0, time 197961431, (2,133), root:(1085,257),
    state 0x0, keycode 117 (keysym 0xff67, Menu), same_screen YES,
    XLookupString gives 0 bytes:  ""
                

A key (not Shift-modified):
 

KeyPress event, serial 25, synthetic NO, window 0x2200001,
    root 0x3f, subw 0x0, time 8726828, (160,114), root:(166,141),
    state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes:  "a"
 
KeyRelease event, serial 25, synthetic NO, window 0x2200001,
    root 0x3f, subw 0x0, time 8726913, (160,114), root:(166,141),
    state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes:  "a"
                

Left Shift:

KeyPress event, serial 25, synthetic NO, window 0x2200001,
    root 0x3f, subw 0x0, time 8727368, (160,114), root:(166,141),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:  ""
 
KeyRelease event, serial 25, synthetic NO, window 0x2200001,
    root 0x3f, subw 0x0, time 8727453, (160,114), root:(166,141),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:  ""
                

The keycode/keysym pairs (in order) are 115/Super_L, 116/Super_R, 117/Menu, 38/a, and 50/Shift_L. Note that the state values in the KeyRelease event are non-zero for the ``Windows'' keys and left Shift keys (0x40 and 0x1) and are zero for the ``menu'' and A keys.

Manually Remap Target Keys

We will use xmodmap to remap the left and right ``Windows'' keys to be left and right Meta keys, and we will remap the ``menu'' key to be a right Ctrl key. There is more than one way to effect the desired change -- see xmodmap(1).

Left ``Windows'' key (115/Super_L):

$ xmodmap -e "clear Mod1"
$ xmodmap -e "keycode 115 = Meta_L"
$ xmodmap -e "add Mod1 = Meta_L"
                

Right ``Windows'' key (116/Super_R):

$ xmodmap -e "clear Mod2"
$ xmodmap -e "keycode 116 = Meta_R"
$ xmodmap -e "add Mod2 = Meta_R"
                

``menu'' key (117/Menu):

$ xmodmap -e "keycode 117 = Control_R"
$ xmodmap -e "add Control = Control_R"
                

Changes occur immediately upon executing the xmodmap command -- there is no need to restart X.

Automatically Remap Target Keys

The effect of the above xmodmap commands can happen automatically when X is started (using GDM/XDM or via startx) by making (or modifying) the file /etc/X11/Xmodmap. If the file does not exist in your system, create it with the following lines. If it does, add the following lines. Compare to the sequence of xmodmap commands above. Lines beginning with ! are comments.

! left windows key to left meta key
clear Mod1
keycode 115 = Meta_L
add Mod1 = Meta_L

! right windows key to right meta key
clear Mod2
keycode 116 - Meta_R
add Mod2 = Meta_R

! menu key to right control key
keycode 117 = Control_R
add Control = Control_R
                

After changing or creating the Xmodmap file, restart X and enjoy your new keymap. Alternately, one can do

$ xmodmap /etc/X11/Xmodmap
                

back to top

Multi-head X Configuration

Sub-topics:
How to use this Tutorial
Traditional Mode (Independent Desktops)
Xinerama Mode (Single Desktop)

Complete information (beyond that given in these specific examples) is available in xorg.conf(5). At the bottom of the man page are references to pages specific to various X.org video card drivers which are worth a read if you have such a card in your system. Some drivers offer dual head functionality beyond the standard traditional and Xinerama modes described below (e.g. radeon(4)).

NVIDIA's proprietary nvidia driver and ATI's proprietary fglrx driver offer dual head extensions that provide Xinerama-type dual head functionality. These drivers are not addressed in this document. The methods here for both traditional and Xinerama multi-head configurations will work in a system using these drivers.

How to use this Tutorial

We assume you already have functioning single head X windows in your GNU/Linux system.

We will use a single video chip with two heads for our examples here (one AGP card, or a laptop with a VGA out port). The procedure is similar for two or more single or multi-head cards. First, gather the decimal PCI bus ID of your card. To get this value, execute lspci and look for your graphics card(s):

$ /sbin/lspci
...
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000] (rev 01)
...
                
We will refer to this card as 1:0:0 in our final xorg.conf files (XX:YY:Z becomes XX:YY:Z -- it's OK to drop leading zeroes).

For each multi-head mode, changes must be made to ones X configuration file (typically /etc/X11/xorg.conf), which we refer to as xorg.conf.

There are various Sections in this file, and one must either modify existing or create new ServerLayout, Device, and/or Screen sections. We will show our beginning single head xorg.conf file, and for each mode, we will show what changes to make and a final xorg.conf file.

Here is our beginning xorg.conf file:

#/etc/X11/xorg.conf -- single AGP

Section "ServerLayout"
        Identifier     "single AGP"
        Screen         "Screen0"
        InputDevice    "USB mouse" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
EndSection
 
Section "ServerFlags"
        Option "AllowMouseOpenFail" "true"
EndSection
 
Section "Files"
        FontPath     "unix/:7110"
        FontPath     "unix/:7100"
        # Fall back in case font server is not available
        FontPath     "/usr/X11R6/lib/X11/fonts/75dpi/"
        FontPath     "/usr/X11R6/lib/X11/fonts/100dpi/"
        FontPath     "/usr/X11R6/lib/X11/fonts/misc/"
        FontPath     "/usr/X11R6/lib/X11/fonts/Speedo/"
        FontPath     "/usr/X11R6/lib/X11/fonts/Type1/"
        FontPath     "/usr/X11R6/lib/X11/fonts/CID/"
EndSection
 
Section "Module"
        Load  "dbe"
        Load  "dri"
        Load  "extmod"
        Load  "glx"
        Load  "record"
        Load  "xtrap"
EndSection
 
Section "InputDevice"
        Identifier "Keyboard0"
        Driver     "keyboard"
EndSection
 
Section "InputDevice"
        Identifier "USB mouse"
        Driver     "mouse"
        Option     "Protocol" "ImPS/2"
        Option     "Device" "/dev/input/mice"
        Option     "Emulate3Buttons" "false"
        Option     "ZAxismapping" "4 5"
EndSection
 
Section "Device"
        Identifier "Card0"
        Driver     "ati"
EndSection
 
Section "Monitor"
        Identifier "Monitor0"
	#HorizSync 31-80
        #VertRefresh 50-75
	Option     "dpms"
EndSection
 
Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        DefaultDepth 16
        SubSection "Display"
                Depth 16
                Modes "1280x1024"
        EndSubSection
EndSection

Section "DRI"
        Group      0
        Mode       0666
EndSection
                

Again, the Sections of interest are ServerLayout

Section "ServerLayout"
        Identifier     "single AGP"
        Screen         "Screen0"
        InputDevice    "USB mouse" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
EndSection
                

Device

Section "Device"
        Identifier "Card0"
        Driver     "ati"
EndSection
                

Monitor

Section "Monitor"
        Identifier "Monitor0"
	#HorizSync 31-80
        #VertRefresh 50-75
	Option     "dpms"
EndSection
                

and Screen

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        DefaultDepth 16
        SubSection "Display"
                Depth 16
                Modes "1280x1024"
        EndSubSection
EndSection
                

Traditional Mode (Independent Desktops)

We will now convert our original xorg.conf file in order to run two heads in ``traditional mode''. This allows for independent desktops (addressed as displays 0.0 and 0.1) -- one can run a different window manager on each display.

First, using the PCI bus ID of 1:0:0 found with lspci, modify the existing Device section and make a new Device section, like this:

Section "Device"
        Identifier "Card0"
        Driver     "ati"
	BusID "PCI:1:0:0"
	Screen 0
EndSection

Section "Device"
        Identifier "Card1"
        Driver     "ati"
	BusID "PCI:1:0:0"
	Screen 1
EndSection
                

Next, make another Monitor section, so there are now two:

Section "Monitor"
        Identifier "Monitor0"
	#HorizSync 31-80
        #VertRefresh 50-75
	Option     "dpms"
EndSection

Section "Monitor"
        Identifier "Monitor1"
	HorizSync 30-70
        VertRefresh 50-120
	Option     "dpms"
EndSection
                
We uncommented the HorizSync and VertRefresh lines for Monitor1 because the monitor we are using is old and does not support auto-detection.

Make another Screen section using the new Device and Monitor sections. Our Screen sections are now:

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        DefaultDepth 16
        SubSection "Display"
                Depth 16
                Modes "1280x1024"
        EndSubSection
EndSection

Section "Screen"
        Identifier "Screen1"
        Device     "Card1"
        Monitor    "Monitor1"
        DefaultDepth 16
        SubSection "Display"
                Depth 16
                Modes "1400x1050"
        EndSubSection
EndSection
                
We will use a different resolution in Screen1.

Finally, modify ServerLayout:

Section "ServerLayout"
        Identifier     "dual traditional"
        Screen         "Screen0"
	# We use RightOf -- you can use LeftOf, Above, Below
	Screen	       "Screen1" RightOf "Screen0"
	Option	       "Xinerama" "off"
        InputDevice    "USB mouse" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
EndSection
                

Our final xorg.conf file for traditional dual head:

#/etc/X11/xorg.conf -- dual AGP traditional

Section "ServerLayout"
        Identifier     "dual traditional"
        Screen         "Screen0"
	# We use RightOf -- you can use LeftOf, Above, Below
	Screen	       "Screen1" RightOf "Screen0"
	Option	       "Xinerama" "off"
        InputDevice    "USB mouse" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
EndSection
 
Section "ServerFlags"
        Option "AllowMouseOpenFail" "true"
EndSection
 
Section "Files"
        RgbPath      "/usr/X11R6/lib/X11/rgb"
        ModulePath   "/usr/X11R6/lib/modules"
        FontPath     "unix/:7110"
        # Fall back in case font server dies
        FontPath     "/usr/X11R6/lib/X11/fonts/misc/"
        FontPath     "/usr/X11R6/lib/X11/fonts/Speedo/"
        FontPath     "/usr/X11R6/lib/X11/fonts/Type1/"
        FontPath     "/usr/X11R6/lib/X11/fonts/CID/"
        FontPath     "/usr/X11R6/lib/X11/fonts/75dpi/"
        FontPath     "/usr/X11R6/lib/X11/fonts/100dpi/"
EndSection
 
Section "Module"
        Load  "dbe"
        Load  "dri"
        Load  "extmod"
        Load  "glx"
        Load  "record"
        Load  "xtrap"
EndSection
 
Section "InputDevice"
        Identifier "Keyboard0"
        Driver     "keyboard"
EndSection
 
Section "InputDevice"
        Identifier "USB mouse"
        Driver     "mouse"
        Option     "Protocol" "ImPS/2"
        Option     "Device" "/dev/input/mice"
        Option     "Emulate3Buttons" "false"
        Option     "ZAxismapping" "4 5"
EndSection
 
Section "Device"
        Identifier "Card0"
        Driver     "ati"
	BusID "PCI:1:0:0"
	Screen 0
EndSection

Section "Device"
        Identifier "Card1"
        Driver     "ati"
	BusID "PCI:1:0:0"
	Screen 1
EndSection
 
Section "Monitor"
        Identifier "Monitor0"
	#HorizSync 31-80
        #VertRefresh 50-75
	Option     "dpms"
EndSection

Section "Monitor"
        Identifier "Monitor1"
	HorizSync 30-70
        VertRefresh 50-120
	Option     "dpms"
EndSection
 
Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        DefaultDepth 16
        SubSection "Display"
                Depth 16
                Modes "1280x1024"
        EndSubSection
EndSection

Section "Screen"
        Identifier "Screen1"
        Device     "Card1"
        Monitor    "Monitor1"
        DefaultDepth 16
        SubSection "Display"
                Depth 16
                Modes "1400x1050"
        EndSubSection
EndSection

Section "DRI"
        Group      0
        Mode       0666
EndSection
                

Xinerama Mode (Single Desktop)

Next, we convert our original xorg.conf file to run two heads in ``Xinerama mode''. This gives a single desktop spanning all heads, addressable as display 0.0 in this example.

As with traditional mode, we use the PCI bus ID of 1:0:0 found with lspci and make two Device sections:

Section "Device"
        Identifier "Card0"
        Driver     "ati"
	BusID "PCI:1:0:0"
	Screen 0
EndSection

Section "Device"
        Identifier "Card1"
        Driver     "ati"
	BusID "PCI:1:0:0"
	Screen 1
EndSection
                

We also make another Monitor section for our second monitor, resulting in two Monitor sections:

Section "Monitor"
        Identifier "Monitor0"
	#HorizSync 31-80
        #VertRefresh 50-75
	Option     "dpms"
EndSection

Section "Monitor"
        Identifier "Monitor1"
	HorizSync 30-70
        VertRefresh 50-120
	Option     "dpms"
EndSection
                
The HorizSync and VertRefresh lines are uncommented for Monitor1 because ours is old and does not support auto-detection.

Make another Screen section using the new Device and Monitor, resulting in two Screen sections:

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        DefaultDepth 16
        SubSection "Display"
                Depth 16
                Modes "1280x1024"
        EndSubSection
EndSection

Section "Screen"
        Identifier "Screen1"
        Device     "Card1"
        Monitor    "Monitor1"
        DefaultDepth 16
        SubSection "Display"
                Depth 16
                Modes "1280x1024"
        EndSubSection
EndSection
                
It is not necessary to run the same resolution on both monitors.

Here is the ServerLayout section modifed for Xinerama. This differs from that used with traditional mode:

Section "ServerLayout"
        Identifier     "dual xinerama"
        Screen         "Screen0"
	# We use RightOf -- you can use LeftOf, Above, Below
	Screen	       "Screen1" RightOf "Screen0"
	Option	       "Xinerama" "on"
        InputDevice    "USB mouse" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
EndSection
                

Here is our final xorg.conf file for Xinerama type dual head video:

#/etc/X11/xorg.conf -- dual AGP Xinerama

Section "ServerLayout"
        Identifier     "dual xinerama"
        Screen         "Screen0"
	# We use RightOf -- you can use LeftOf, Above, Below
	Screen	       "Screen1" RightOf "Screen0"
	Option	       "Xinerama" "on"
        InputDevice    "USB mouse" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
EndSection
 
Section "ServerFlags"
        Option "AllowMouseOpenFail" "true"
EndSection
 
Section "Files"
        RgbPath      "/usr/X11R6/lib/X11/rgb"
        ModulePath   "/usr/X11R6/lib/modules"
        FontPath     "unix/:7110"
        # Fall back in case font server dies
        FontPath     "/usr/X11R6/lib/X11/fonts/misc/"
        FontPath     "/usr/X11R6/lib/X11/fonts/Speedo/"
        FontPath     "/usr/X11R6/lib/X11/fonts/Type1/"
        FontPath     "/usr/X11R6/lib/X11/fonts/CID/"
        FontPath     "/usr/X11R6/lib/X11/fonts/75dpi/"
        FontPath     "/usr/X11R6/lib/X11/fonts/100dpi/"
EndSection
 
Section "Module"
        Load  "dbe"
        Load  "dri"
        Load  "extmod"
        Load  "glx"
        Load  "record"
        Load  "xtrap"
EndSection
 
Section "InputDevice"
        Identifier "Keyboard0"
        Driver     "keyboard"
EndSection
 
Section "InputDevice"
        Identifier "USB mouse"
        Driver     "mouse"
        Option     "Protocol" "ImPS/2"
        Option     "Device" "/dev/input/mice"
        Option     "Emulate3Buttons" "false"
        Option     "ZAxismapping" "4 5"
EndSection
 
Section "Device"
        Identifier "Card0"
        Driver     "ati"
	BusID "PCI:1:0:0"
	Screen 0
EndSection

Section "Device"
        Identifier "Card1"
        Driver     "ati"
	BusID "PCI:1:0:0"
	Screen 1
EndSection
 
Section "Monitor"
        Identifier "Monitor0"
	#HorizSync 31-80
        #VertRefresh 50-75
	Option     "dpms"
EndSection

Section "Monitor"
        Identifier "Monitor1"
	HorizSync 30-70
        VertRefresh 50-120
	Option     "dpms"
EndSection
 
Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        DefaultDepth 16
        SubSection "Display"
                Depth 16
                Modes "1280x1024"
        EndSubSection
EndSection

Section "Screen"
        Identifier "Screen1"
        Device     "Card1"
        Monitor    "Monitor1"
        DefaultDepth 16
        SubSection "Display"
                Depth 16
                Modes "1280x1024"
        EndSubSection
EndSection

Section "DRI"
        Group      0
        Mode       0666
EndSection
                

back to top

Planning for Dual Boot -- Partitioning Requirements

Common Problems

We have heard reports of users installing an MS OS first, allowing an analog of MS fdisk to partition ones disk, ending up with a drive that is not usable in the way that the user intended. It is a good idea to partition the disk(s) ahead of time using a Linux partitioning utility (e.g. Linux fdisk), which offers one the ability to specify how ones hard drive(s) will be used without being limited by drive naming schemes ("C: drive"). Nearly every GNU/Linux distribution provides the means to partition hard drives early in the installation procedure, so an easy way to partition drives in a new system is to boot an installation CD, and follow the installer until one has accomplished disk partitioning.

MS Win Partition Requirements

A main cause of problems is lack of knowledge that every MS Win OS requires a primary partition on the first hard drive in the system to use as its "C: drive". For example, if one has a single IDE drive and creates two partitions in the MS Win installer, the first a placeholder for GNU/Linux and the second for MS Win, the installer will make the first partition primary and the second logical (as far as we have seen, MS fdisk has always only allowed one to create a single primary partition, forcing the rest to be logical). If one then installs in the second partition, it will be the "D: drive" in the new system, and the first partition will be the "C: drive", holding a small amount of MS Win boot data. At that point, MS Win has consumed the whole hard drive, and one must resort to trickery (e.g. fips partition resizing) in order to install GNU/Linux without blowing away the MS Win installation.

In IDE systems, the first drive in the system is whichever first appears in the list primary master, primary slave, secondary master, and secondary slave. In SCSI systems, the first drive in the system is the drive with the lowest device ID in the SCSI channel that is probed first when the system POSTs. In mixed IDE/SCSI systems, which is the first hard drive in the system varies, typically dependent on the motherboard BIOS. Whether setting SCSI to appear in the boot order before IDE affects whether one can make a primary partition on a SCSI drive be MS Win's "C: drive" is BIOS-dependent. A hack to get around an ill-behaved BIOS in this case is to install with IDE hard drives disconnected, to be reconnected after the MS Win installation is done. To avoid problems in this scenario, we suggest making MS Win partitions in IDE devices logical and not primary partitions.

One can tell one is facing a BIOS problem in a mixed SCSI/IDE system if the MS Win installer labels the first primary partition in a SCSI drive with a letter other than C. If one attempts to install in the SCSI drive, the installer will inform that it will write some data to a partition in an IDE drive. If one chooses to not let this occur, the installation will terminate.

Modern GNU/Linux distributions have no such limitations or restrictions, so one must merely plan ahead for satisfying MS Win's requirements to arrive at a functioning dual boot system. If one has installed Linux first, we suggest making and testing a boot disk to have on hand for getting back to ones Linux side in order to configure the boot loader for dual boot.

back to top

Reclaiming the Master Boot Record

If one installs an MS OS into empty disk space in a GNU/Linux system, it is likely that the master boot record (MBR) will be overwritten, and the system will boot immediately into the MS OS post-installation. To correct this and configure for dual boot, one must use an alternate method to access ones Linux side, one must configure the boot loader (typically LILO or GRUB) to boot the MS OS, and one must reinstall the boot loader. We address how to access ones Linux side and reinstalling the boot loader next; configuring LILO or GRUB to boot an MS OS is addressed here.

Obtain a Rescue CD

We recommend using using the Red Hat installation CD or the Red Hat / Fedora Core rescue CD (boot with linux rescue), and let the rescue environment auto-detect and auto-mount the existing installation as described in the next section. For example, use the 32 bit Fedora Core 6 rescue CD.

Mounting the Linux Side Using a Red Hat CD

If one has planned ahead and has a boot floppy, one should use it. If not, the easiest method for getting access to ones Linux side is to use the small shell environments provided by most modern GNU/Linux distributions' bootable installation CDs.

One of the most straightforward applications of this method can be done using a recent Red Hat (Fedora) installation CD. This usually works whether or not the GNU/Linux side is Red Hat (it can fail if one is using kernel functionality not provided by the Red Hat installation kernel -- e.g. XFS file system). At the boot prompt, enter "linux rescue", and follow the installer through a few pages. Let it attempt to locate and mount ones Linux installation. If it succeeds, one will drop to a shell, with ones Linux side available at /mnt/sysimage. One can now use chroot to make / correspond to the root file system of the target GNU/Linux installation:

# chroot /mnt/sysimage
If the Red Hat auto-detection was successful, skip the next section on mounting manually in a shell.

Mounting the Linux Side Manually in a Shell

If the Red Hat auto-detection fails or if one uses an installer other than Red Hat's, one must mount ones Linux side manually.

To accomplish this, choose a mount point (we will create /mnt/target for this purpose), and mount ones root file system (mount point for /) at the selected mount point. Assuming ones root file system is at /dev/hda6 (this will vary per system), do

# mkdir /mnt/target
# mount /dev/hda6 /mnt/target
Assuming mount is in /bin, as it usually is, next use chroot to make / correspond to the root directory in the system one is reclaiming:

# chroot /mnt/target
As it is sometimes required to have access to /proc, next do

# mount -t proc proc /proc
Next, edit /etc/mtab to eliminate references to mounts that are not valid in the chroot environment. Following along in our example, /etc/mtab should look like:

/dev/hda6 / ext3 rw 0 0
none /proc proc rw 0 0
Delete all references to mount points corresponding to the installation environment, and remove the /mnt preceding / and /proc.

Finally, mount the rest of the target system in the chroot environment:

# mount -a

Reinstalling GRUB

In the chroot environment (following our example, the boot device is /dev/hda; this will vary per system), do

# grub-install /dev/hda
If grub-install fails (e.g. due to an error when editing mtab), success can often be obtained by doing

# grub-install --recheck /dev/hda
Assuming the target GNU/Linux installation was booting fine with GRUB prior to the MS OS installation, one should now be able to boot ones Linux side normally.

Reinstalling LILO

In the chroot environment, do

# lilo
Assuming the target GNU/Linux installation was booting fine with LILO prior to the MS OS installation, one should now be able to boot ones Linux side normally.

back to top

Configuring GRUB or LILO to Boot an MS OS

In the examples below, we assume the MS OS's "C: drive" is at /dev/hda1 (this varies per system).

Configuring GRUB to Boot an MS OS

To boot an MS OS with its "C: drive" at /dev/hda1, make the following entry in /boot/grub/menu.lst:

title MS Win
    rootnoverify (hd0,0)
    chainloader +1
Note that one might have to use a device entry different from hd0; have a look at /boot/grub/device.map, e.g. do

# cat /boot/grub/device.map
to see how GRUB has sequenced /dev/hda. Unlike LILO, it is not necessary to reinstall GRUB after modifying its target OS configuration file menu.lst.

Configuring LILO to Boot an MS OS

To boot an MS OS with its "C: drive" at /dev/hda1, make the following entry in /etc/lilo.conf:

other=/dev/hda1
    label="MS Win"
After modifying lilo.conf, one must reinstall LILO by doing

# lilo

back to top