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. TIP: Linux and FreeBSD are both available on CD-ROM from Walnut Creek. Their Internet address is ref HYPERLINK http://www.cdrom.com. FreeBSD has a web page at ref HYPERLINK http://www.freebsd.com. NetBSD is at ref HYPERLINK http://www.netbsd.org. Linux has a web page ref HYPERLINK http://www.linux.org. 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. Unixware is based on Svr4, and was originally developed by AT&T. Novell had control of it for a while, and now SCO is developing for it. Unixware runs primarily on x86 (Intel or 100 percent compatible) based machines. BSDI's BSDI Internet Server is a commercial distribution of BSD/OS originally designed and programmed by Berkeley University. BSDI took BSD/OS and added many new utilities, programs, and features that make this distribution a very stable and productive addition to any corporate Intranet or Internet gateway. Its main focus is at Internet Service Providers (ISP) because of its prefect networking capabilities. BSDI runs on all x86 (Intel or 100 percent compatible) machines. FreeBSD and NetBSD are free alternatives to BSDI Internet Server. They contain many of the great features that make BSD/OS very popular, but lack the professional technical support of any commercial distribution. If you don't need the over-the-phone technical support and want the stability and reliability you look for in a Internet/Intranet focused OS, these are for you. Did I mention they are both free? FreeBSD will run on the x86 platform, while NetBSD will run on the following: Dec Alpha, Amiga, Acorn RiscPC, Atari, HP 9000/300 series, x86, m86k Macintosh, PowerPC, Sun SPARC series, Sun 3, Dec VAX and many others. NetBSD is by far the most portable operating system available, although FreeBSD seems to be a more popular choice among x86 users. SCO's SCO OpenServer is another variation of UNIX that is based on XENIX, an OS developed by Microsoft. It is very popular among corporate Internets/Intranets and has been for many years. It earns a respectable place on corporate servers, although it lacks the versatility of BSD. Its technical support cannot be matched, which is why many corporations choose this commercial OS as their server OS of choice. SCO also has a whole host of applications available--even Microsoft products such as Word and Excel. Linux (RedHat, Slackware, Debian, and so on) was originally developed from the Minix source. It began as a hobby and grew to a frequently updated, used, and supported operating system. Linux is largely based on the POSIX standards, and SysV. Linux has a very wide range of applications available (more so than SCO) and is also free. There are commercial distributions available that usually contain commercial software (for instance, Applixware for RedHat). Linux is very popular among first-time UNIX users, and is easily installed. Linux is very frequently updated with new kernels and is not always as stable as some would like. While Linux is very popular for workstations, it is usually not given the task of a mission critical server as it lacks the technical support, stability and functionality of a high-quality professionally developed operating system such as BSDI Internet Server. 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. NOTE: A network segment is a group of machines all plugged into the same Ethernet, a type of LAN which uses a bus topology. Because the Ethernet uses a bus topology, each of the machines sees all the traffic on the network. Each is local to each other and is immediately accessible via the network. Since the Ethernet LAN is only able to handle a finite amount of traffic, the network is broken into segments connected by routers or bridges. Traffic to systems within the segment is not repeated, or retransmitted, into the other segments. Only traffic that is for systems outside the segment is repeated. With proper planning, almost all of the traffic will be internal to the segment, and more systems can be placed on the overall network before everyone bogs down from trying to put more bytes out over the LAN than it can handle. 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. Space Requirements 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. TIP: An inode is basically a unit where data is stored. If you have ten 512-byte inodes, and ten 3-byte files, you fill up those ten inodes even though you have not used up the space contained in them. As you can see, this is why decreasing the size of the inodes will produce more available inodes for storage of these small files. 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. TIP: Not only will the type of user dictate what gets installed, it will also dictate how many systems can be put on this segment of the LAN, the server capacity, and swap space requirements. Which Type of Users UNIX users generally fall into one or more of several categories: Application users. These users run commercial or locally developed applications. They rarely interact with the shell directly and do not write their own applications. These users might be running a database application, a word processor or desktop publishing system, a spreadsheet, or some in-house-developed set of applications. They spend most of their time in think mode, where they are deciding what to do with the results the application has presented them, or in data entry mode, typing responses or data into the system. Their need for large amounts of local disk access is minimal, and they do not change applications frequently, nor are they running many applications simultaneously. (They might have them open, but they are generally interacting with only a couple of them at a time--the rest are waiting for the user to provide input.) Although application users might put a large load on their database servers, they do not normally put large disk loads on their own systems. Power users. These users run applications, just like the application users, but they also run shell scripts and interact more closely with the system. They are likely to be running multiple applications at once, with all these applications processing in parallel. These users keep several applications busy and access the disk more frequently and use more CPU resources than do the normal application users. Developers. Developers not only run applications, they also run compilers, access different applications than users, require access to the development libraries, and generally use more components of the operating system than do users. Furthermore, they tend to use debugging tools that require more swap space and access to more disk resources than the application user generally needs. The UNIX operating system has packages that are only needed by developers, and if a developer is on this segment of the LAN, these files must be installed and accessible to the systems used by the developers. Compiling takes up a great amount of processor power; therefore, you must plan to accommodate this need with the right type of system. Ten programmers compiling 10,000 lines of code in parallel can easily bog down a Pentium Pro 200 Mhz. TIP: You must, not only consider who will use the system right away, but because you only install UNIX once, consider who might use the system over the next six months to a year. Remember, depending on what type of system you are going to set up, you will be adding users to your machine. If the programs these users need are not available, you will be forced to reinstall the whole system, or install the appropriate packages, depending on the OS. Because of the low cost of hardware these days, you are better off to invest in the added hardware and install all the packages that might be of use to you or anyone else in the future. 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: Traffic from the systems in Department A to its local server for the following: Remote file systems, including accessing shared UNIX OS partitions and user files. Access to client/server applications hosted on the Department A server. Diskless client access to swap, temporary, and spool partitions. Traffic between the systems in Department A, including the following: Client/server application traffic. Remote display updates (a window on one system showing output from a process on a different system). Sharing of local file systems that are not on the server. Traffic between the systems in Department A and the backbone server, including the following: Remote file access to company-wide files. Access to client/server applications running on the backbone, such as a master database. Traffic between the systems in Department A and those in Department B, including the following: Access to files located locally at Department B. Access to client/server applications running on the systems in Department B. Remote file access to local disks on Department B systems. 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: From where am I going to install? Is this to be a stand-alone, server, or diskless system? What is its hostname? What is its IP address? Which packages should be installed? How should the disk be partitioned? 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. CAUTION: If you need boot floppies, be sure you order the proper boot floppies for your system. Many vendors of System V Releases 3 and 4 provide different boot floppies for systems that use SCSI-based tape drives than for those that use dedicated controllers for the tape drive. Also some provide different floppies for CD-ROM than for tape and for different versions of disk controllers. Some Linux distributions have many different boot disks to choose from, while some commercial UNIXes such as BSD/OS have only one generic boot disk. CAUTION: Read the release notes carefully. Most PC-based UNIX systems support only a limited set of hardware. Be sure your display adapter card, network card, and disk controller are supported. Check to see if any special device drivers are required and that you have those drivers for your version of the operating system. If not, before you start the installation, be sure to acquire current drivers for those cards from the manufacturer of the cards or from your UNIX vendor. Be sure the driver is specific to the version of UNIX you will be installing. If the installation procedure does not ask you to install these drivers, be sure to install them before rebooting from the mini-root used to install the system to the operating system just installed. Otherwise, the system will not boot. 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: Unplug the drive from where it is currently and add it to the new system to perform the install. Then you have a local CD-ROM drive and can follow the instructions in the installation notes for using a local CD-ROM drive. If your version of UNIX has remote installation abilities, access the drive remotely from the system on which it currently resides. 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. CAUTION: If the system must boot off the CD-ROM drive, it is not always possible to plug any CD-ROM drive into the system. Many UNIX workstation vendors have placed special roms in their CD-ROM drives to modify their behavior to look more like a disk drive during the boot process. When in doubt, it is best to have available a model of that workstation vendor's CD-ROM drive for the installation. 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: Host name--a short name it is known by locally. UUCP name--usually the same as the host name. Used for modem-based communications between UNIX systems. Domain name--a name that identifies which set of systems this system is a part of for electronic mail and routing. NIS domain--a name that identifies which set of systems this system is grouped with for systems administration purposes. The set of systems shares a common password and other systems administration files. 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. TIP: At any organization, people generally come and go, and when they go, the system they were using gets reassigned. Hardware also gets replaced. It's not a good idea to name a system for its current user or for its current hardware. These are some poor name choices: sun1051--Today it might be a Sun Sparc 10/51. Tomorrow it might be a Dec Alpha or something else. Choose a name that will retain its meaning regardless of the changes in hardware. jerry--It was Jerry's system, but who has it now? The name should help identify the system for the user and the administrators. You will be referring to the system by this name in many contexts. mis1--Systems migrate, even from department to department. When this system ends up in engineering, calling it mis anything could be confusing. Instead, consider using some name that allows for a selection of one of a group of names. These are some popular choices: The names of the seven dwarves--This gives the systems some personality, and at least allows for seven. You could expand to use the names of other characters in stories besides Snow White when more names are needed. Street names--Be careful, though. If you name the aisles of your cubicle system for streets, don't use the same street names for your systems. Moving them around could get confusing. Don't take this tip too literally. If functional names, such as mis1 or database make sense, use them. It isn't that difficult to retire the old name and change the system's name to a new one in the future. 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: hostname.localdomain.masterdomain.topdomain As an example, the mail gateway at my company, Ascio Communications, uses this fully qualified domain name: mars.ascio.net 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. TIP: Why use a local domain name? In networked systems, a central administration group is responsible for assigning and maintaining all host names and their corresponding addresses. When the number of systems gets large, there is too much burden on this one group. It can cause delays while you wait for the administration group to get around to adding your new information to their master files. If they delegate this responsibility for a set of systems to a local group, they only need to add the local domain to their files and then you can add systems and make changes as needed. 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. NOTE: Just because you are doing multiple backups does not necessarily mean you need multiple tapes. UNIX can place more than one backup on a single tape, provided there is space on the tape to hold them. 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: The boot information and the bootable UNIX kernel, and a backup copy of the kernel in case the main one gets damaged Any local system configuration files, which are typically in the /etc directory Any stand-alone programs, such as diagnostics, that might be run instead of the OS 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. NOTE: Although the var file system cannot be shared, subdirectories under it can (for example, /var/news). These would be mounted on top of the var file system after it is already mounted. 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. TIP: For print files, a good starting point is adding 10 times the size of the largest print file to the size recommended. Add more if there are a large number of users or multiple printers attached to this system. For UUCP files, have enough space to hold at least a day's worth of traffic for every site. 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. TIP: Don't worry too much about getting it exactly right. If you need more space for a particular user, just move that user's directory to a different file system that does have room and create a symbolic link in /home to point to its new location. The user may never know you moved the directory. 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. TIP: The files in the /tmp directory are very short-lived. Use the file system type TMPFS (Tmp file system, a RAM-based file system) for /tmp if your version of UNIX offers it. It can improve performance by placing this file system in RAM instead of on the disk. Losing the files on each reboot is not a concern, because UNIX clears the /tmp directory on each reboot anyway. 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: Drive 1 Drive 2 root usr swap home var 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. NOTE: The IP address is not the Ethernet address. An Ethernet address is a hardware-level address assigned by the manufacturer. It is six octets long (48 bits). The first three represent the manufacturer of the network interface board. The remaining three octets are unique to the system. This is commonly called the MAC address. An IP address is a software level address. Part of the IP protocol, also called ARP or Address Resolution Protocol, is used to match the software IP address with the physical Ethernet address. 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: Connector Type Network Type 10Base5 10Base2 10BaseT AUI AUI cable transceiver AUI to BNC transceiver AUI to RJ45 transceiver BNC 10Base2 Hub BNC Tee 10Base2 Hub RJ45 10BaseT Hub with AUI port and RJ45 Cable 10BaseT Hub with BNC port and RJ45 Cable RJ45 Cable and free slot on BaseT Hub Using NIS/NIS+ 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: The name of the system holding the drive for the installation, and its device name TIP: Check your release notes--you might have to enter the name of the new system into the root user's .rhost file temporarily during the installation, or load the CD-ROM and mount the partition prior to running the remote installation. Diskless, dataless, stand-alone, or server system The name of the server for the new client, if it's a dataless or diskless system, should be on your sheet along with its IP address. The name of the host and domain The IP address The packages to install How to partition the disk (This is the map of the disk drive or drives you made earlier.) Whether to use a network database (This is the name of the NIS domain, if you intend to run NIS.) Now you should be all set. CAUTION: You are about to do things that will change the information on the disks. If this is not a brand new system, be sure you have readable backups in case something goes wrong. 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. TIP: On Sun systems, to install a system with custom disk layouts, or to install any server, requires selecting the Custom Install menu option on the opening installation screen. This will walk you through all the questions, setting everything up for you automatically. 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. CAUTION: If you are installing from a nonstandard disk controller, be sure to select the option to add the custom driver for this controller and provide the floppy with the driver when requested. If you exit install and attempt to reboot without providing this driver, you will be unable to boot the system, and you will have to start the installation from the beginning. 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. CAUTION: Many packages must be deleted before being reinstalled. If pkgadd is asked to install a package that is already installed, it will attempt to overwrite the existing package. Some packages work with this overwrite and some do not. If the installation is an upgrade to a newer version of a package, it is safer to first remove the old copy with the pkgrm program and then install the new one. TIP: To determine which packages are currently installed UNIX provides the pkginfo command. This command has two forms. The first form, when run with no pathname as an argument, lists which packages are currently installed. When run as pkginfo -l, it will also list when the package was installed, the version currently installed, if any patches installed affect this version, and how much disk space it is currently consuming. When run with a pathname, pkginfo tells you which packages reside on the installation media. Note that the -l argument also works in this mode and can tell you how much space each package will take to install. 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. NOTE: pkgadd also checks to make sure that other packages this new package requires are already installed. It will warn you or not let you install a package if the prerequisites are not already installed. 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. Summary 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: The type of system you are installing: server, stand-alone, dataless, or diskless Who will act as server for this system, if necessary What size and on what disk each slice will be located root, usr, var, home, and tmp file systems swap partition The name and address for this system: host name, domain name, IP address, and NIS domain name, if applicable Which packages you are going to install From where you are going to install With the answers to these questions you can answer the UNIX install procedures questions. From there the installation is automatic.

©Copyright, Macmillan Computer Publishing. All rights reserved.