Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 453 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
453
Dung lượng
2,52 MB
Nội dung
Part VII — System Administration UNIX Installation Basics Starting Up and Shutting Down File System Administration User Administration Networking UNIX Accounting System Performance Monitoring Device Administration Mail Administration News Administration UUCP Administration UNIX System Security 33 o UNIX Installation Basics What Do I Need to Know from the Start? Who Is Going to Use This System? Which Type of Users For What Purpose? What Other Systems Are Located on This Segment of the LAN? Determining Suitable Servers Determining Suitable Clients Managing Network Traffic Summarizing What You Need to Know Before Starting Planning for the Installation From Where Am I Going to Install? Media Distribution Type Using a Local Device or a Remote Device for Installation Diskless, Dataless, or Stand-Alone Server System? Naming the System Host Name Domain Name (DNS/Mail) Choosing Which Packages to Install Locally Laying Out the Disk Slices Why Multiple File Systems? The root Slice The swap Slice The usr Slice The var Slice The opt Slice The home Slice The tmp Slice Assigning Slices to Disk Drives Assigning IP (network) Addresses Do You Have the Needed Network Connections? Using NIS/NIS+ Performing the Installation Booting the Installation Media Booting from Floppies Booting Directly from the CD-ROM Installing the Master System Installing Optional or Additional Packages Using pkgadd and pkgrm Using swmtool Adding a Diskless Client to a Server Installing the Diskless Client Operating System Support Files Adding the Diskless Client Summary 33 UNIX Installation Basics Installing a UNIX system requires a bit more planning than does installing a PC. You need to decide whether the system is autonomous (able to run without any other systems being present on a network) or how dependent it would be on the other systems on its network. You also have to decide which parts of the UNIX system and its various utilities and application programs each user of this system will need. Why? MS-DOS is a system that takes less than 10 MB of disk space. MS-Windows takes a bit more, but it's still a rather small amount. UNIX is a large system. The complete installation of just the operating system and all that comes with it for Sun's Solaris 2.3 release, as an 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 installer. UNIX splits the install into many different sections, called packages. Each package consists of files that provide a specific set of features. Many packages can be installed locally, remotely on a server, or not at all, depending on your needs. Whereas 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, dataless, and diskless systems. A stand-alone system is one that is capable of operating without a connection to a local area network (LAN) and other UNIX systems. It's not that it cannot be connected; it's capable of booting and operating without any connection. This means that it does not need to access any other UNIX system's disk for boot or operating system files and for swap space. A server is also a stand-alone system. It is capable of operating without a connection to other systems. But it also generally contains some extra files, which are used by its clients. The clients may only have part of the operating system installed—just enough to boot the system—and depend on the server for the remainder of the commands, utilities, and library files. Such a client is called a dataless system. It has a boot disk and local swap space, and it is missing the remainder of the utilities and operating system. 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. 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 via Network File System user files) and still be considered a stand-alone system for the installation of the UNIX operating system. As an example, Sun's Solaris 2.3 requires either 27 MB, 101 MB, 158 MB, or 213 MB just to install the operating system and its utilities and documentation. A diskless system does not require that any of these files be installed, as it uses them from the server. A dataless system requires that the core system support files be installed. A stand-alone system could be set up with either end-user packages or with developer packages, whereas a server traditionally needs the entire distribution. So far this chapter just touches on the disk installation. There is much more to it: planning for users, the network and its traffic, applications, printers, remote access, 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. What Do I Need to Know from the Start? The first think 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 will have to provide services. Who Is Going to Use This System? Just as a PC for a user to run a spreadsheet and a word processor needs a much smaller disk and less of UNIX and its applications installed, such a UNIX system will also require less to be installed. 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 type 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, server capacity (sizing), 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 does the normal application user. Developers Developers not only run applications, they also run compilers, access different applications than do 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 these developers. 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. For What Purpose? UNIX systems that are being used as shared development machines, or are going be placed in a common user area, will need a lot of swap space, a large section of the disk for temporary files, and 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 will need increased swap space. What Other Systems Are Located on This Segment of the LAN? As stated in the section "What Do I Need to Know from the Start?," you have to 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. In UNIX it is a good idea to remotely serve systems with most of the operating system packages. Dataless systems are a good idea. Sharing the operating system not only saves disk space, it also makes the future task of upgrading the operating system easier. You only have to upgrade the server system with the full distribution, a process that can take an hour or more. For the Dataless clients, a small, few-minute procedure will update the small amount of the system that is located on their private disks. If a little disk sharing is good, isn't a lot better? If you are running diskless clients, they need no upgrade at all. All of the upgrade is done on the server. However, there is a downside to diskless systems: excessive network traffic. A diskless system depends on its server not only for the operating system, but also for its swap and temporary disk space. The network is not as fast as a local disk, especially if it is getting overloaded by too many diskless clients. A reasonable trade-off is to use diskless clients for small systems that are used by application users, and dataless clients for the rest. When you make a system a diskless or dataless client, you reduce redundancy in the segment. These systems are totally dependent on their servers to function. If the server is down for any reason, these systems are also down. This causes many systems to go down if a server is down. (This includes while upgrading the server with a new revision of the operating system.) You should not place mission-critical applications on systems that are clients of other systems. Having a mission-critical system freeze due to NFS Server Unreachable is not good. 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—A server must not only cache files for its own use, but also for the demands of its clients. Having plenty of RAM so the in-memory disk cache managed by UNIX can be large really helps on servers. With the rapid drop in memory prices, what used to be a good-sized buffer might not be any more, but as a minimum, consider 32 MB of RAM in the system. 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, as 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. 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. Dataless clients do not use space on the server for swap and temporary files. 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 will delay 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-model CPU. Determining Suitable Clients Once the server is determined, choosing suitable clients is a balancing act. You need to mix performance, ease of administration, network traffic, and available resources. Diskless clients—These are the easiest to determine. If the system does not have a disk, it must have a diskless client. Choose a server for this system that is going to be relatively lightly loaded. Diskless clients make larger demands on their servers than do dataless clients. Make sure the server for diskless clients is on the same segment of the network as the client. Although NFS requests for disk blocks will cross out of a segment and across a router to a different LAN segment, the boot request will not. It is a local broadcast packet. The diskless client needs its bootp server, the system that holds its boot files and responds to its diskless request, to be local to the segment on which it resides. Even if the system that holds its boot files responds to its diskless boot request, the segments are not connected by routers today. Follow this rule: when the segments are converted to using routers to reduce backbone traffic, the system will be unbootable without a local bootp server. Dataless clients—Since a dataless client accesses the utility portions of the UNIX operating system only from its server, it makes relatively small demand on its server. Almost any system that is not critical that it operates if the server is down makes a good choice for use as a dataless client. If a system will have a large number of disk accesses to user files, such as for a local database, it still can be a dataless client. It can keep on its local disk a file system for those heavily used files, and still access the server for the portions of the system that are not on its local disk. This will free more of the space on its local disk for the local file system. For those systems that support a newer type of NFS remote mount, called a Cached File System, consider its use for the read-only mounting of the shared portions of the UNIX installation. It provides the remote access desired and can greatly reduce the amount of network traffic. It is ideal for these partitions because they are read-only anyway. If you have a very reliable server, such as a redundant system, consider placing the UNIX OS server on the backbone with multiple LAN connections on it, servicing each of the local LANs. This can greatly reduce the overhead in maintaining the server and keeping it up to the latest release. This is only practical if the server can provide sufficient I/O band width to support all its clients. 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% 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 KB/second in bursts and over 500 KB/second sustained. If the traffic is anything close to this, consider splitting the segment into two segments to reduce the traffic. There is a mistake in the silicon of many EtherNet chips, causing them not to be able to reach the numbers described before having excessive collisions. If the netstat -i command is consistently showing a significant number of collisions, say over 1 percent, even though the traffic levels are well below those numbers, you should consider the segment overloaded. You might have several systems on your network with chips with that problem. 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 have to 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 diskless, dataless, stand-alone, or server system? What is its name? What is its address? Which packages should be installed? How should the disk be partitioned? Should you use a network database? 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 are you 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 actually can be a lot more convenient. [...]... 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 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... start up and shut down your UNIX system It also describes how you can change your system to different system states while it is running Examples in this chapter are based on the UnixWare version of UNIX, as implemented on an IBM PC or compatible (that is, Intel 386 technology) Turning On the Computer When you turn on a computer that has the UNIX system installed, starting up UNIX is managed by a process... System V—based UNIX systems the recommended size from the vendor is probably sufficient for this slice In BSD-based UNIX systems, consider increasing the size of this slice to allow for a few extra kernels BSD uses prelinked kernels instead of runtime driver loading, and you will need to keep more UNIX kernels around The swap Slice The note in the section "For What Purpose" describes how UNIX uses the... letter S These include the following: S01MOUNTFSYS S02mse S18setuname S50merge S75rpc S01tzsetclk S05RMTMPFILES S21perf S55merge S02PRESERVE S11uname S27nuc S69inet S15mkdtab S73snmp S42els You can list these files to see what they do On the whole, however, the scripts start networking and other addon features For example, S27nuc starts NetWare connectivity, S69inet starts TCP/IP, and S50merge starts... 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... applications, and services on your computer are available to be used Because UNIX is a powerful multitasking and multiuser operating system, many processes are set in motion when you start it up First, UNIX runs system initialization processes to do things such as set the system clock from hardware, configure devices, and build a new UNIX kernel (if necessary) Then the system begins running processes associated... Then the system begins running processes associated with the particular initialization state (or init state) assigned to your system When the UnixWare version of the UNIX system is delivered, the default run state for your system is state 3 This state makes your UNIX system available for multiuser use in a networked environment (including file sharing) What this means is that all file systems are connected... 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, as UNIX clears the /tmp directory on each reboot anyway The disk label that contains the disk layout is held in block 0 of the disk UNIX does not use this block in file systems, so there is no... operating systems installed The description in this system assumes that UNIX is the active operating system configured on your computer See the description of fdisk for information on assigning different operating systems to boot on your computer This section describes what happens when you start up the UnixWare 1.1 version of the UNIX system on your personal computer, as it is delivered from Novell,... 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 . Part VII — System Administration UNIX Installation Basics Starting Up and Shutting Down File System Administration User Administration Networking UNIX Accounting System Performance Monitoring. Administration Mail Administration News Administration UUCP Administration UNIX System Security 33 o UNIX Installation Basics What Do I Need to Know from the Start? Who Is Going. Operating System Support Files Adding the Diskless Client Summary 33 UNIX Installation Basics Installing a UNIX system requires a bit more planning than does installing a PC. You need