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 [...]... uncomplicated shutdown of the system Listing 16. 6 shows a sample shutdown from an IRIX system Listing 16. 6 Sample shutdown from an IRIX system Shutdown started Wed Apr 16 01: 46: 29 EDT 1997 Broadcast Message from root (ttyq0) on indy Wed Apr 16 01: 46: 29 1997 THE SYSTEM IS BEING SHUT DOWN! Log off now On the system console, once shutdown began, the following appeared: The system is shutting down Please... 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... down the system Most other variants allow only the superuser to bring the system down -h: Halt the system -r: Reboot the system neither -h nor -r: Place system in single-user mode q q q -y: Default answers to any interactive question grace: Integer seconds defining how long users have to log off The default value for grace is 60 seconds IRIX q q q q q q q q q q q q q q q q q To reboot an IRIX system. .. procedures questions From there the installation is automatic ©Copyright, Macmillan Computer Publishing All rights reserved UNIX Unleashed, System Administrator's Edition - 16 Startup and Shutdown by David Gumkowski and John Semencar Starting up and shutting down UNIX are unlike most system administration tasks in that after deciding when either occurs, the administrator is more a passive observer than... unexported /usr2 Removing swap areas Unmounting file systems: As with starting up the system, shutting down the system will reflect parts of what is happening to the system console and system log file Summary To recap, during system startup and shutdown, as the console spews information out, be an educated observer; unless problems occur, keep the rest of your system administration skills ready but in the... Release 10.x machine is found in Listing 16. 1 Note that most startup messages are written to the system console device as well as the system log file Please refer to your system' s manual page for syslogd to find where your syslog configuration file is located The configuration file will indicate to you in the last column where the system log files are located Listing 16. 1 Sample startup from a Hewlett Packard... 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... 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. .. 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... ©Copyright, Macmillan Computer Publishing All rights reserved UNIX Unleashed, System Administrator's Edition - 17 User Administration by David Gumkowski and John Semencar While performing user administration you will call upon all of your skills in virtually every area of system management Whether it is keeping disks as empty as possible, finding system bottlenecks, answering questions, or adding new users, . 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. 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. the UNIX install procedures questions. From there the installation is automatic. ©Copyright, Macmillan Computer Publishing. All rights reserved. UNIX Unleashed, System Administrator's Edition -