UNIX Unleashed, System Administrator's Edition
- 15 -
UNIX Installation Basics
by Syd Weinstein and Lance Cavener
Installing UNIX on a machine requires more thought and planning than installing DOS or Microsoft Windows. You need to decide if this system will be stand-alone, or dependent on a server on your network. You also have to pay careful attention to system resources (such as hard drive space, processor speed, memory, and so on) and which packages are required to tailor this UNIX installation to your needs, and perhaps the needs of users in the future.
Why? DOS is a system that takes less than 10 MB of disk space. Windows takes a bit more, but it's still a rather small amount. UNIX is a large system depending on your configuration. The complete installation of just the operating system and all that comes with it for Sun's Solaris 2.3 release, for example, is about 300 MB. With that much disk space in use, it's often wise to share it across several systems. In addition, there are few options in installing DOS or Windows that can be made by the setup program. UNIX splits the install into many different sections, called packages. Each package consists of files that provide a specific set of features. These features range from networking tools, necessary system utilities, or applications. Many packages can be installed locally, remotely on a server, or not at all, depending on your needs.
You must also take into consideration the various flavors of UNIX that are available, and how much you have to spend. Linux, for example, is free and is publicly available to anyone over the Internet or on CD-ROM. FreeBSD and NetBSD are examples of free BSD-based operating systems; they are generally preferred for larger, more mission critical sites; they are also free. If you have never used any flavor of UNIX before, you should experiment with as many as you can. You have to decide which one best suits your needs and expectations.
On another note, you have commercial operating systems such as BSDI, SCO, Unixware, NeXT, Solaris, and many others. These are generally expensive, although you get over-the-phone technical support and printed documentation. These are things to look for if you run a mission critical site and might need a shoulder to lean on in the future should anything catastrophic happen to your server.
What are the Differences Between the Different Distributions?
While I can't possibly go through every available distribution, I will give a brief description of some of the major UNIX operating systems.
What Do I Need to Know from the Start?
The first thing you need to do is decide what you are going to install on this system. You decide this by looking, not only at this system, but at all the systems on this segment of the network.
You base your decision about what to install on the intended usage of the system, what systems it can be served by, and for which systems it must provide services.
DOS and Windows are not designed to easily share large sections of the installation. UNIX (especially because of its disk needs) almost expects that some sharing will occur. The degree of disk space sharing leads to the definition of stand-alone, server, and diskless machines.
A stand-alone system means that this particular machine can function on its own--it doesn't require any assistance from any other machine on the LAN.
A server is a machine that is connected to the LAN that runs daemons (programs that run like httpd, or smtpd) to give remote clients some functions such as mail or news. Technically, a server can be a stand-alone machine, but because of its tasks, it never is.
If the client system has no disk drive at all, it is considered diskless. It depends on its server for booting, for the entire operating system, and for swap space. Many people use such machines as dumb terminals, or machines that just provide an interface to a remote machine.
Dataless machines contain only the necessary files to boot, although they are not used often because of the high load they put on the network (like diskless machines). To avoid network congestion, many people run stand-alone machines to avoid the added cost of faster network equipment.
In addition to sharing the operating system, UNIX systems can share other disks, such as drives containing databases or user files. Sharing these disks does not make a system a server in the "install" sense. The server name is reserved for serving the operating system or its utilities. A system might be an NFS server (sharing user files via Network File System (NFS)) and still be considered a stand-alone system for the installation of the UNIX operating system.
A diskless system does not require that any of these files be installed, because it uses them from the server. A dataless system requires that the core system files be installed. A stand-alone system could be set up with either end-user packages or with developer packages, whereas a server needs the entire distribution.
You are going to have different storage necessities for different installations. Developer installs usually require more disk space, while a dataless system only requires core files. Depending on the size of these files, you will configure the partition differently. Partitions that will contain Usenet articles should be configured to contain smaller inodes. This, in turn, increases the number of inodes available for storage of the small Usenet articles. Running out of inodes is like running out of disk space, even though you still have disk space left.
So far this chapter just touches on the disk installation. There is still much to be discussed. You must plan for users, the network and its traffic, applications, printers, remote access, backups, security, and much more.
Thus, planning for a UNIX installation requires planning not only for this one system, but for all the systems in this segment of the network.
Who Is Going to Use This System?
Users who typically use their machine for word processing and other general office applications will not require an extremely large amount of disk space or system resources. However, a power user or application developer needs much more to be installed, perhaps including compilers and development libraries. To decide what to install on this segment of the LAN, let alone on this system, you need to determine which types of users are going to be using this system.
Which Type of Users
UNIX users generally fall into one or more of several categories:
For What Purpose? UNIX systems that are being used as shared development machines or are going be placed in a common user area, need a lot of swap space, a large section of the disk for temporary files. They also need more of the packages from the operating system than systems that are just being used on a single user's desk. In addition, if the system is going to be used as a computation or database server, it needs increased swap space and processor power.
What Other Systems Are Located on This Segment of the LAN?
As stated in the "What Do I Need to Know from the Start?" section, you must consider all of the systems on this segment of the LAN. You are looking for systems that provide access to sections of the operating system, provide access to application disk areas, have sufficient disk and memory resources to handle your diskless clients, and make suitable servers for the other systems on the segment.
If you have an office or a lab full of identical machines, all running the same applications with no need for any major customizations, then having a centralized installation is much easier to maintain. But since we now have hardware, such as CD-ROMs, capable of 16x speed, which can do upwards of 700 kbps, and Ethernet which can do anywhere from 10Mbps to 100Mbps (Ethernet and Fast Ethernet respectively) so it is usually easy to install over the network. It's also just as easy to upgrade machines, providing your operating system supports upgrades; it all depends on what the function of the machines on the segment are.
Determining Suitable Servers It's usually easier to determine suitable servers than suitable clients, so start there. To make a good server system, you need the following:
Plenty of RAM-- Servers must have plenty of RAM available for their use. Your server must be capable of handling many clients, each running different processes at the same time. In order for this to be done efficiently, you don't want much swapping happening. Your best bet is to put as much RAM as possible into the server; this will allow room for upgrades (and higher loads). Generally, 64 to 128 MB is sufficient for many installations. There are some exceptions, such as INN where it uses a lot of RAM, and for a full news feed, 64 MB will not last very long.
Fast Disks--The client sees the delay to read a disk block as the time to ask the server for the block, the time the server takes to read the block, and the time to transmit the block over the network back to the client. If the server has a fast disk, this time might be no longer, and is often shorter, than reading the same number of blocks locally.
Since a server is handling multiple clients, including itself, it is more likely that a disk block is already in the server's disk cache. This is especially true for program files and the operating system utilities, because they are used often. Access is then very fast, as the disk read time is not needed at all. This helps make servers as responsive as if they were reading the disk block locally on the client server.
Don't sacrifice quality for price. You pay for what you get; go for the highest possible (and fastest) hard drives and controllers available. Ultra-Wide SCSI controllers with high quality UW-SCSI drives handle the task perfectly.
Sufficient disk space--A server will hold, not only its own files and a copy of the UNIX operating system, but also the swap and temporary space for its diskless clients. A suitable server should have some spare disk space for adding not only the current clients, but some extra to account for growth. Here is a breakdown of some of the more frequently used packages and their sizes for BSDI (http://www.bsdi.com)
0.4 MB--Core (/var)
4.0 MB--Core root (/)
23.6 MB--Core usr (/usr)
9.9 MB--Additional usr (/usr)
12.3 MB--Networking (/usr)
17.0 MB--Development (/usr)
17.3 MB--Manual Pages (/usr/share/man & /usr/contrib/man)
92.7 MB--X11 XFree servers, Development, man Pages (/usr/X11R6)
26.3 MB--Emacs (/usr/contrib)
39.7 MB--TeX & LaTeX
As you can see, BSDI takes up a lot of space. There are still additional packages such as Hylafax, the kernel sources, ghostscript, MH and many other tools that you may or may not want installed.
Spare CPU resources--A server needs to have enough CPU cycles to serve its local users and still provide disk and network access services to its clients. But that does not mean to make the fastest system the server. Often you should do just the opposite.
It does not take much CPU power to be a server. File access in UNIX is very efficient, as is network traffic. A system that is heavily loaded delays the response of disk block requests for its clients. To keep response time up for the clients, leave your power users on the faster systems and use a system with sufficient other resources and a light user load for the server, even if this system has a slower CPU.
Managing Network Traffic Before you can decide how to install the new system, you need to check on the amount of traffic on the network. Sources of this traffic include the following:
The additional traffic generated by the installation of this new system must be compared to the existing traffic on the network. Adding a diskless client on a network segment running at 80 percent utilization is asking for trouble.
You don't need sophisticated tools to monitor network traffic. Just take one of the workstations and use the tools provided by your vendor to count the packets it sees on the network. A simple approach is to use a tool such as etherfind or snoop to place the Ethernet interface into promiscuous mode, where it listens to all the packets on the network, not just those addressed to itself. Then count the number of packets received by the system over a period of time and their respective length. Most UNIX systems can drive an Ethernet segment up to about 800 kbps in bursts and over 500 kbps sustained. If the traffic is anything close to this, consider splitting the segment into two segments to reduce the traffic.
When splitting the network into segments, if you can place a server and its systems into each of the split segments, often you can use a less expensive bridge to reduce the traffic on each segment rather than using a router.
Summarizing What You Need to Know Before Starting
In summary, before starting to plan for the actual installation of the new system, you need to determine who is going to use the system. You need to determine how much disk access they will be performing and how much they will contribute to the overall network traffic; whether this system is going to be a client or a server; and whether the network can tolerate another system on this segment before the segment has to be split because of overloading.
Planning for the Installation
You now must determine on which segment to install this new system, decide what type of user it's for, and decide where to place it. What more do you need to plan for other than where to plug in the power cord and network connection?
This section guides you through a short pre-installation checklist to make the installation process go smoothly. It will have you answer the following questions:
These are some of the questions the system will ask as you install UNIX. Most of the rest have obvious answers, such as what time zone you are in.
From Where Am I Going to Install?
Traditionally, one installed a system by placing the medium in a drive and booting from that medium, such as floppy, tape, or CD-ROM. With the advent of networking, things are no longer so simple, but they can be a lot more convenient.
You have two choices for installing: local or remote. A local installation is the traditional case, where the media is inserted into some drive attached to the computer being installed, and the software is copied onto the system. A remote installation further falls into two types.
You might use the remote systems's CD-ROM or tape drive to read the media because the system you are installing does not have one. But if there is a large number of systems to install you would access an install server, which already has all of the installable files and boot images on its local disks. Because the local disks are faster than CD-ROM or tape, this is faster. It's only worthwhile to set up the install server, however, when you have a lot of systems to install.
Media Distribution Type With upwards of 350 MB of software to install, floppies are no longer practical. UNIX software vendors have switched from floppies to either CD-ROM or tape as the install media. Regarding tapes, different UNIX vendors use different tape formats, some offering more than one. You need to make sure you know which format your vendor is supplying and that you will have access to a drive capable of reading the data.
If you have a choice, choose the CD-ROM media. It has several advantages over tape. CD-ROMs are much faster than tape, and they are also random access. This makes the installation much quicker and efficient.
Another advantage is that the media is read-only. It is impossible to overwrite it by mistake or by hardware malfunction. In addition, a CD-ROM is much less expensive to produce and holds more than the tape or floppies it replaces. With a CD-ROM, there is usually no need to change media partway through the installation.
If your computer is unable to boot off the CD-ROM or tape, the vendor also supplies a boot disk (or in the case of some distributions of Linux, a "root and boot" disk, which essentially contains the information needed to boot with your hardware: the installation program and the software that it requires). This is a minimal RAM-based system that is loaded off the floppy and is used to read the CD-ROM or tape. It basically contains the necessary drivers to access your CD-ROM or tape.
Using a Local Device or a Remote Device for Installation Since most UNIX vendors have decided to switch to CD-ROM as the distribution media of choice, most likely you will have a CD-ROM drive somewhere in the network. At this time you have two choices:
Since the network is usually much faster than the CD-ROM drive, either choice will work. You just have to be sure that the drive remains available to you for the entire installation process. If someone else is going to need the CD-ROM drive, you will not be able to relinquish it to them until the entire install procedure is complete.
Diskless or Stand-Alone Server System?
Now is the time to decide whether this system is going to be a diskless client of some server, a dataless system, or a stand-alone system or server. You need to make this decision to make sure that the system ends up in the same domain as its server and in the same segment of the network if it's diskless.
In addition you need to decide how to partition the disk.
In general, price determines whether a system is totally diskless. If you can afford a disk drive, you should purchase one and make the system a dataless system. Reserve your use of diskless clients' times when it is impractical to place a disk locally with the system because of environmental or power concerns; or where access to the system to upgrade the local disk is going to be difficult or impossible. Then it will be necessary to perform all the administration and upgrades on the server system.
You should see the release notes of your system for specifics, but use the following disk space requirements as a guideline:
Diskless--Because there is no local disk, all disk space resides on the server. Each diskless client must mount its root, swap, temp, and spool partitions from the server. Expect to allocate the following from the server:
root: 10-20 MB
swap: Varies by memory size, but 16-256 MB is the normal range.
spool: 10-20 MB
tmp: 10-40 MB
Dataless--Dataless clients use the local disk for each of the partitions listed above for the diskless client.
Stand-alone--If the system is for an application user, the same sizes as those for the dataless clients are appropriate.
In addition, a /usr partition will be needed with an additional 100 MB to hold the remainder of the operating system. If X window system is also to be stored locally, it can require up to an additional 70 MB, depending on the number of tools and fonts that are installed. A minimal X installation requires about 30 MB.
If the user is a developer, the /usr partition will need to be about 150-200 MB to hold the compilers, libraries, additional tools, and local tools the user will need.
Server--Server systems generally need the entire operating system installed. Here is a guideline for overall sizes:
root: 20 MB
swap: varies by memory size, but 64-512 MB is normal range.
spool: 40-100 MB
tmp: 20-80 MB
usr: 250 MB
X: 75 MB
Per diskless client: 50-200 MB (more if large swap areas are needed for the client)
In addition, a server may have more than one network interface installed. This is so it can serve multiple segments.
Naming the System
Each UNIX system is given a set of names:
This chapter deals with the systems host and domain names. Using a UUCP name that is different from the host name is covered in Chapter 26, "UUCP Administration."
Host Name A host name is typed often, so it should be relatively short. While it can be up to 256 characters long in System V Release 4 systems, no one wants to type a name that long all the time. A short word usually is desired. If this name is to be shared as the UUCP name as well, it should be no longer than 8 characters.
Domain Name (DNS/Mail) If you want to uniquely address every UNIX system by name and you try to use short names for local convenience, you quickly run into the problem bemoaned often on the Internet: "All the good ones are taken." One way around this problem is the same way people resolve it with their own names. You can give systems first, middle, and last names.
One of the results of UNIX and the Internet growing up together is the domain name system. This allows every machine to be uniquely addressed by giving its fully qualified domain name, which is comprised of its host name and its domain name, separated by dots, as in the following:
As an example, the mail gateway at my company, Ascio Communications, uses this fully qualified domain name:
You read this name from right to left as follows:
net: This is the top-level or root domain in the United States and Canada for network providers; com:, for commercial organizations. Other choices include edu, for educational institutions; gov, for governmental bodies; org, for charitable organizations; and us, used mostly for individuals. Outside of the United States and Canada, the International Standards Organization (ISO) country code is the top-level domain.
ascio: This is the chosen domain name for the entire organization. Because the company is connected to the Internet, ascio.net had to be unique before it could be assigned.
mars: This is the actual host name of this system.
The system is then referred to as mars within the local office, and mars.ascio.net from outside the company.
If this is an installation of a system into an existing network, you should already have an existing domain name to use. Then you have to choose only a host name. If this is the first system to install in a local group of systems, consider choosing a local domain name as well.
Only if this is the first system in the organization will you have to choose the remaining levels of the domain name. They should be the same for all systems within the organization.
Choosing Which Packages to Install Locally
When you made the choice of being a server, stand-alone system, dataless client, or diskless client, you made the base choice of what portions of the operating system to install. You can fine-tune this choice if you need to conserve disk space. Linux, BSD/OS, Solaris, and many other operating systems give you a large choice of packages to install. Some of those packages are specific to hardware you may not have installed. You can choose to omit those packages now, and if you change the configuration later, you can always add them to the existing installation.
Once you have chosen the packages you intend to install, sum their sizes as specified in the release notes for that version and you will be ready to lay out the partitions.
Laying Out the Partitions
Rather than use an entire disk drive for one file system, which leads to inefficiencies and other problems, UNIX systems have the ability to split a single drive into sections. These sections are called partitions (FreeBSD calls them slices), because each is a partition of the disk's capacity.
Generally, a disk can be split into eight partitions, each of which the operating system treats independently as a logical disk drive.
Why Multiple File Systems?
Damage control--If the system were to crash due to software error, hardware failure, or power problems, some of the disk blocks might still be in the file system cache and not have been written to disk yet. This causes damage to the file system structure. While the methods used try to reduce this damage, and the fsck UNIX utility can repair most damage, spreading the files across multiple file systems reduces the possibility of damage, especially to critical files needed to boot the system. When you split the files across disk slices, these critical files end up on slices that rarely change or are mounted read-only and never change. Their chances of being damaged and preventing you from recovering the remainder of the system are greatly reduced.
Access control--Only a complete slice can be marked as read-only or read-write. If you desire to mount the shared operating system sections as read-only to prevent changes, they have to be on their own slice.
Space management--Files are allocated from a pool of free space on a per-file system basis. If a user allocated a large amount of space, depleting the free space, and the entire system were a single file system, there would be no free space left for critical system files. The entire system would freeze when it ran out of space.
Using separate file systems, especially for user files, allows only that single user, or group of users, to be delayed when a file system becomes full. The system will continue to operate, allowing you to handle the problem.
Performance--The larger the file system, within limits, the larger its tables that have to be managed. As the disk fragments and space become scarce, the further apart the fragments of a file might be placed on the disk. Using multiple smaller partitions reduces the absolute distance and keeps the sizes of the tables manageable. Although the UFS file system does not suffer from table size and fragmentation problems as much as System V file systems, this is still a concern.
Backups--Many of the backup utilities work on a complete file system basis. If the file system is very big, it could take more time than you want to allocate to back up. Multiple smaller backups are easier to handle and recover from.
The following partitions are required on all UNIX installations: root and swap.
It is recommended that you create partitions to hold usr, var, home, and tmp.
As you read the sections on each partition, make a map of your disk space and allocate each partition on the map. You will use this map when you enter the disk partitioning information as you install the system.
The root Partition
The root partition is mounted at the top of the file system hierarchy. It is mounted automatically as the system boots, and it cannot be unmounted. All other file systems are mounted below the root.
The root needs to be large enough to hold the following:
This partition typically runs on between 10 and 20 MB. It is also usually placed on the first slice of the disk, often called slice 0 or the a slice.
The swap Partition
The note in the "For What Purpose" section describes how UNIX uses the swap partition. The default rule is that there's twice as much swap space as there is RAM installed on the system. If you have 16 MB of RAM, the swap space needs to be a minimum of 32 MB. If you have 256 MB of RAM, the recommended swap is 512 MB.
This is just a starting point. If the users of this system run big applications that use large amounts of data, such as desktop publishing or CAD, this might not be enough swap. If you are unsure as to the swap needs of your users, start with the rule of twice RAM. Monitor the amount of swap space used via the pstat or swap commands. If you did not allocate enough, most UNIX systems support adding additional swap at runtime via the swapon or swap commands.
The usr Partition
The usr slice holds the remainder of the UNIX operating system and utilities. It needs to be large enough to hold all the packages you chose to install when you made the list earlier.
If you intend to install local applications or third-party applications in this partition, it needs to be large enough to hold them as well.
The var Partition
The var partition holds the spool directories used to queue printer files and electronic mail, as well as log files unique to this system. It also holds the /var/tmp directory, which is used for larger temporary files. Every system, even a diskless client, needs its own var file system. It cannot be shared with other systems.
If you do not print very large files, accept the size the release notes suggest for this partition. If you do print a large number of files or large files, or if your site will be performing a large volume of UUCP traffic, consider increasing the size of this partition to accommodate your needs.
The home Partition
This is where the user's login directories are placed. Making home its own slice prevents users from hurting anything else on the system if they run this file system out of space.
A good starting point for this slice is 5 MB per application user plus 10 MB per power user and 20 MB per developer you intend to support on this system.
The tmp Partition
Large temporary files are placed in /var/tmp but sufficient temporary files are placed in /tmp that you don't want it to run your root file system out of space. If your users are mostly application users, 5 to 10 MB is sufficient for this slice. If they are power users or developers, 10 to 20 MB is better. If there are more than 10 users on the system at once, consider doubling the size of this slice.
Assigning Partitions to Disk Drives
If you have more than one disk drive, a second decision you have is on which drive to place the partitions. The goal is to balance the disk accesses between all of the drives. If you have two drives, consider the following partitioning scheme:
The remaining partitions split over the drives as space allows.
Assigning IP (Network) Addresses
If the system has a network connection, it must be assigned an IP address. IP addresses are explained in Chapter 20. An IP address is a set of four numbers separated by dots, called a dotted quad. Each network connection has its own IP address. Within a LAN segment, usually the first three octets of the dotted quad are the same. The fourth must be unique for each interface. The addresses 0 and 255 (all zeros and all ones) are reserved for broadcast addresses. The remaining 254 addresses may be assigned to any system.
If this is your first system, you must decide on the first three octets as well. See Chapter 20 for applying for a network number. The number should be unique within the world and is obtainable at no cost.
If this is not the first system, then any unused value for the fourth octet can be used for this system.
Do You Have the Needed Network Connections? Now is the time to check that you have a network connection for each network interface. Now is the time to check that you have the proper cables, transceivers (if needed), and connectors.
Ethernet comes in three varieties: thick (10Base5), thin (10Base2), and twisted pair (10BaseT). UNIX Systems come with some combination of three types of Ethernet connections: AUI, BNC, or RJ45. If your system has multiple connector types, they are all for the same network interface, unless you purchased an add-on interface that uses a connector type different from that of the main system. Using the matrix below, you can see which parts you need:
Administering a UNIX system requires dealing with many files, such as the password, group, network, and Ethernet address control files. Having to maintain each one of these files on multiple systems can be time consuming. Discrepancies in the files can lead to problems logging in to systems or to security issues.
One solution to this problem is the Network Information Service, or NIS. NIS is a network-wide set of databases for the common administrative files. This allows for centralized administration, even by using multiple servers with a redundant system in case the master server is down.
When installing a system in an NIS environment, you have to answer the install questions with the name of the NIS domain for this system.
The NIS domain does not unnecessarily match the mail domain entered earlier. Generally it is for security reasons or to further subdivide the administrative responsibilities when they do not match.
Performing the Installation
By now, if you've been following along, you should have an installation checklist. It should contain the following:
Now you should be all set.
Booting the Installation Media
The first step in installing a UNIX system is to load the mini-root into RAM (the mini-root is basically a scaled down kernel that will give you the ability to run the UNIX installation programs). UNIX uses the UNIX operating system to perform its installation. It needs a version of UNIX it can run, and to do this the install loader uses RAM to hold a small version of the UNIX file system. When you boot the installation media, it builds a root file system and copies the files it needs to control the installation to this RAM-based file system. This is the reason it takes a while to boot the media.
Booting from Floppies Take the first boot floppy and place it in what DOS would call drive A. Boot the system in the normal manner, by pressing the Ctrl+Alt+Del keys at the same time or by power cycling the machine.
The system will load the boot loader off the first floppy and then use that to create the RAM-based file systems and load the UNIX image into RAM. It will ask for additional floppies as needed and then ask for the install media. Answer CD-ROM or tape, as appropriate, and the system will then load the remainder of the mini-root from the installation media.
Installing the Master System
Once the mini-root is loaded, you are generally presented with the install options. Some systems leave you at a shell prompt. If this happens, enter install to start the installation procedure. Your distribution may be different, or it may be automatic. Follow the installation procedure located in your manual.
UNIX contains a set of install procedures that walk you through the installation. They are almost identical to one another in concept, but they are slightly different in implementation. Given the information on the checklist produced as you followed this chapter, answer the questions as presented by the installation screens.
Expect it to take under an hour to read all the information off the install media to the local disks if you are installing more than just a dataless client. Most systems gives you a progress meter to show you how much it has done and how much further it has to proceed.
Provided you plan ahead and fill out an installation checklist, installing a UNIX system is a simple and automatic process.
Installing Optional or Additional Packages
Once the system is installed and rebooted, you are running UNIX. Congratulations. Of course, you will still need to perform installations from time to time to add packages and applications. All UNIX packages and most standard applications for System V Release 4 use the pkgadd format. Installation of these packages and applications is automatic using the pkgadd utility. RedHat Linux uses rpm, and BSD uses pkgadd via installsw (to make life easier). There are a few different packaging formats uses among distributions of Linux/UNIX and use their own installation format or tar format. Follow the release notes for these applications.
Using pkgadd and pkgrm Packages are added to System V Release 4 systems, such as Solaris 2 and UnixWare, by using the pkgadd command. This command automatically installs the software from the release media and updates a database of what is currently installed on the system. Packages are deleted just as easily with the pkgrm command.
To run pkgadd on the install media, place the media in the drive and enter the command
pkgadd -d path-name-to-device pkg_name
pkgadd will then prompt you for which packages to install and give you progress messages as it installs the package. Different packages may also ask you questions prior to installation. These questions usually relate to where to install the package and any other installation options.
Using swmtool Sun's Solaris system provides an X application to guide you through running pkgadd. It displays the contents of the CD-ROM and provides point-and-click installation and removal of the entire media or selected packages.
To install new packages using swmtool, click on the Properties button to pop up the menu for where the packages are located.
Select the local or remote CD-ROM drive if the installation media is not already mounted. If it is already mounted, select Mounted File System, and then type the pathname of the directory containing the packages.
swmtool then displays the contents of the disk. It can provide details on sizes required and versions on the media. To start the installation, select each of the packages to install and press the Begin Installation button. swmtool runs pkgadd for you. You will still have to answer pkgadd's questions just as if you had run pkgadd by hand.
To remove software with swmtool, just select the Remove button from the top of the screen. Select the packages to remove and press the Begin Removal button. swmtool runs pkgrm for you.
Using rpm RedHat Linux uses a packaging format called rpm. To manipulate these packages you use the rpm program. Its very simple to use, and has a few simple command line arguments. As with other package formats, you cannot install a package if the same package (newer or older) is installed. You can use rpm's uninstall feature to uninstall the old package and then use it to install the newer one. You can also use rpm to query packages (see if they are installed) and verify them. The man page for rpm is very descriptive.
RedHat also comes with an X package tool which lets you select which packages you wish to install (along with the programs contained in them). Installing and uninistalling is very simple and efficient with this program. This program is called glint and is available through RedHat's control panel under package management.
Using installsw Most BSD implementations use the pkgadd format, but come with a simple to use program called installsw. This program provides the administrator with an interface where the different packages can be selected and installed, or uninstalled. It's a much welcomed front end, and avoids the unfriendly command lines of pkgadd.
Adding a Diskless Client to a Server
You take two steps to add a diskless client to a server: Add the common files to support any client. Add the specific files for this client. The first needs to be done only if this is the first client of this type and revision of the operating system to be installed.
Installing the Diskless Client Operating System Support Files Traditionally, diskless client support files are installed in the /export file system on the server. With System V Release 4, the common executable files are placed under the /export/exec directory. Each architecture will have its own subdirectory under /export/exec.
Each UNIX vendor that supports diskless clients has an install procedure for loading support files from the installation media for each supported architecture. In Solaris 2, the swmtool edit menu contains the pull-down item Add client software.... This configures the server to support clients of each of the available architecture types.
Adding the Diskless Client Once client support is available on the server, the client must be added to the server. Since the client has no disk, all installation occurs on the server. A shell script or window command is run to add the /export/root/hostname directory tree and the /export/swap/hostname swap file.
Under Solaris 2, this is performed under admintool's host manager. Select the host manager icon from the admintool and then select Add Host from the Edit pull-down menu. Select diskless from the Client Type pull-down menu, and enter the host name, IP address, and Ethernet address onto the menu and select the time zone from the pull-down menu. The remainder of the parameters should be correct except for the swap size. Adjust that to the proper swap size for this client and click on the Add button.
Other UNIX systems provide shell scripts or administrative pull-down menus for adding diskless clients.
The key to a trouble-free installation of your UNIX system is advance planning, and using the guideline in this chapter and the release notes that came with your software. These are the things you should plan:
With the answers to these questions you can answer the UNIX install procedures questions. From there the installation is automatic.