Distribution Specific
General
* Starting and Stopping Services [Red Hat][Debian]
* Configuring Network Interfaces [Red Hat][Debian]
* Installing and Removing Software [Red Hat][Debian]
Starting and Stopping Services in Red Hat
In Red Hat, 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 Services in Debian
In Debian GNU/Linux, 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 SSH from starting on boot, do
# update-rc.d -f sshd remove
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 .
back to top
Configuring an Ethernet Card in Red Hat
Sub-topics:
* Starting and Stopping Networking
* Configuring for DHCP
* Configuring a Static IP Address
In a GNU/Linux system, a NIC (ethernet card, typically) is 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 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 /etc/sysconfig/network-scripts/ifcfg-ethN
Configuring for DHCP
To use DHCP (for a dynamic IP address) for ethN, use the following /etc/sysconfig/network-scripts/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 an Ethernet Card in Debian
Sub-topics:
* Starting and Stopping Networking
* Configuring for DHCP
* Configuring a Static IP Address
In a GNU/Linux system, a NIC (ethernet card, typically) is 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 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 Software in Red Hat
Sub-topics:
* Package Naming Conventions
* Installing and Upgrading RPM Packages
* Uninstalling RPM Packages
* RPM Query Examples
The most common way to install software in a Red Hat 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 in Debian
Sub-topics:
* Installing Software with apt-get
* Uninstalling Software with dpkg
* Querying with dpkg
Further Resources
The typical way to manage software in a Debian system is to use binary Debian packages (ending in .deb), using apt-get or dpkg at the command line, or using GUIs such as dselect or aptitude. (Use care when running dselect for the first time; read documentation on keybindings, etc. available from within dselect first!)
Installing Software with apt-get
Tell APT where to get Debian 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
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) Woody packages, put the line
deb ftp://ftp.m.com/debian woody 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 dpkg
One can uninstall software at the command line with dpkg. The output of
$ dpkg -l
shows currently installed binary Debian packages; in column two, one can see the names of installed packages. Assuming package samplepackage is installed, uninstall it and purge its configuration files by doing
# dpkg -P samplepackage
Uninstalling can also be done with
# dpkg -r samplepackage
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
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
Dual Booting
* Planning Ahead -- Partitioning Requirements
* Reinstalling GRUB or LILO to the Master Boot Record
* Configuring GRUB or LILO for Dual Boot an MS OS
Planning for Dual Boot -- Partitioning Requirements
Sub-topics:
Common Problems
MS Win Partition 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
Reinstalling the Master Boot Record
Sub-topic
* Mounting the Linux Side Using a Red Hat CD
* Mounting the Linux Side Manually in a Shell
* Reinstalling GRUB
* Reinstalling LILO
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.
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 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 use /mnt which is typically available in this scenario), 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
# mount /dev/hda6 /mnt
As it is sometimes useful to have access to /proc, next do
# mount -o bind /proc /mnt/proc
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
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 / ext2 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
Sub-topics:
* Configuring GRUB to Boot an MS OS
* Configuring 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
|
|
