Linux Installation and Getting Started ------------------------------------------------------------------------ Copyright 1993 Matt Welsh, Version 1.0, 5 August 1993. This book is an introduction to the Linux system, including infor- mation on how and where to get Linux, installation of the software, a beginning UNIX tutorial, and an introduction to system adminis- tration. This is the first book anyone with interest in Linux should read. Note: This is the ASCII version of Linux Installation and Getting Started, which is a quick hack made possible by a combination of a LaTeX style format, dvi2tty, and a couple of hours of manual editing. It is only made available to give those with no PostScript or .dvi viewing/printing capabilities a chance to use the book. However, if you have access to a PostScript printer, xdvi, or GhostView, I suggest that you use one of these to view or print the .dvi or PostScript version of the book, which includes such features as: * Fonts * Page numbers * Table of contents * Nicely-formatted page layout * A complete vi tutorial * Linux BBS list * And more! This ASCII version is slightly ugly, and in the future I hope that LameTeX will provide enough functionality to format the LDP manuals for ASCII. However, it's readable. Enjoy. --mdw Preface It's unfortunate that the Intel 80386 and 80486 line of processors has been subjected to the growing popularity of so-called operating systems such as MS-DOS, an aging system which doesn't exploit the power of these machines. It's also unfortunate that better operating systems, commercial UNIXes and OS/2 included, are so large and expensive_not the enthusiast's forte. The question everyone's been asking is, "Who's going to save the IBM PC?" Who is going to save the PC world from the death grip of commercial operating systems? Where's Richard Stallman when you need him? Things were looking extremely bleak, as the dark cloud of Mi- crosoft and IBM loomed menacingly on the horizon. But, at long last, a messiah emerged unexpectedly from the fjords of Helsinki. Kernel in hand, with a growing band of programmers, beta testers, and other such brigands in tow_Linus Torvalds. And his system was known as Linux: the free UNIX clone for the 386. The author hopes that this book will bring the masses the god- foot of that most miraculous of systems. Until recently only those with a true aptitude for UNIX and, indeed, computers in gen- eral have been able to take the plunge and run Linux on their machines. We have braved the jungle of conflicting and obsolete Linux documentation, and have fought with ardor to clear the path for newcomers, those without the alleged software machete. But trailblazing can only go so far. Sometimes it's best to burn down the entire jungle and start anew. This manual is the result of this destruction and rebirth. Finally, the cowering bourgeois can install and run Linux on almost any 386 or 486 based machine. Even those who have never seen or touched the likes of UNIX before can immerse themselves in the beauty of true multitasking, X Windows, TEX, and a myriad of GNU software. And it doesn't cost a shilling_it is the free soft- ware buff's dream. It is the chance for all of us UNIX-developer wannabe's to get our hands dirty with kernel programming, port- ing software, writing documentation, and fixing bugs. It is the frustrated programmer's recluse from segmented memory and false 32-bit environments. It is the neophyte's escape from MS-DOS to the Elysian Fields of UNIX, the future. Audience This book is for any personal computer user who wants to install and use Linux on their system. We assume that you have basic knowledge about personal computers and operating systems such as MS-DOS. No previous knowledge about Linux or UNIX is as- sumed. Organization This book contains the following chapters. Chapter 1, Introduction, gives a general introduction to what Linux is, what it can do for you, and what is required to run it on your system. Chapter 2, Getting Linux, explains how to obtain the Linux software, either via U.S. Mail or from the Internet, via FTP. This discussion focuses on the SLS distribution of Linux. Chapter 3, Installing Linux, explains how to install the Linux software, from repartitioning your drive, creating filesystems, and loading the software on the system. Again, this discussion focuses on the SLS distribution. Chapter 4, Linux Tutorial, is a complete introduction to using the Linux system for UNIX novices. If you have previous UNIX experience, most of this material should be familiar. Chapter 5, System Administration, introduces many of the im- portant concepts of system administration under Linux. This will also be of interest to UNIX system administrators who want to know about the Linux-specific issues of running a system. Chapter 6, Advanced Features, introduces the reader to a num- ber of advanced features supported by Linux, such as the X Win- dow System and TCP/IP networking. Appendix A, Tips, Tricks, and Common Problems, contains other information of interest to those setting up a new Linux sys- tem, such as how to install Linux from the hard drive, and how to set up Linux for use with multiple filesystems. Appendix B, Bibliography and Sources of Information, is a list- ing of other sources of information about Linux, including news- groups, mailing lists, online documents, and books. Appendix C, Quick FTP Tutorial, is a tutorial for downloading files from the Internet with FTP. This appendix also includes a listing of FTP archive sites which carry Linux software. Appendix D, Linux BBS List, is a listing of bulletin board sys- tems worldwide which carry Linux software. Because most Linux users are do not have access to the Internet, it is important that information on BBS systems becomes available. Appendix E, The GNU General Public License, contains a copy of the GNU GPL, the license agreement under which Linux is dis- tributed. It is very important that Linux users understand the GPL; many disagreements over the terms of the GPL have been raised in recent months. Acknowledgments This book has been long in the making, and many people are re- sponsible for the outcome. In particular, I would like to thank Larry Greenfield and Karl Fogel for their work on the first version of Chapter 4, and to Lars Wirzenius for his work on Chapter 5. Thanks to Michael K. Johnson for his assistance with the LDP and the LaTEX conventions used in this manual. I would also like to thank Andy Oram, Lar Kaufman, and Bill Hahn at O'Reilly and Associates for their assistance and interest in the Linux Doc- umentation Project. And, of course, a special thanks to the many activists, especially Linus Torvalds and Peter MacDonald, without whom this would not have been possible. In the last two years, we've seen Linux grow from a single hack- er's operating systems programming project into a fully-functional UNIX clone, with an expanding support base of software, users, and programmers. Linux, as it stands now, is one of the greatest accomplishments of free software in existence, and I can only antic- ipate its further growth. I'd like to call it a revolution. I guess we'll see. So, gentle reader, I give you Linux_soon to be your faithful companion in the war against the wrath of proprietary operating systems. Take no prisoners. Matt Welsh 5 August 1993 Credits and Legalese The Linux Documentation Project is a loose team of writers, proof- readers, and editors who are working on a set of definitive Linux manuals. The overall coordinator of the project is Matt Welsh, aided by Lars Wirzenius and Michael K. Johnson. This manual is but one in a set of several being distributed by the Linux Documentation Project, including a Linux User's Guide, System Administrator's Guide, and Kernel Hacker's Guide. These manuals are all available in LaTEX source format and Postscript output for anonymous FTP from tsx-11.mit.edu, in the directory /pub/linux/ALPHA/LDP. We encourage anyone with a penchant for writing or editing to join us in improving Linux documentation. If you have Internet e- mail access, you can join the DOC channel of the Linux-Activists mailing list by sending mail to linux-activists-request@niksula.hut.fi with the line X-Mn-Admin: join DOC as the first line of the message body. Feel free to get in touch with the author and coordinator of this manual if you have questions, postcards, money, or ideas. Matt Welsh can be reached via Internet e-mail at mdw@tc.cornell.edu, and in real life at 205 Gray Street Wilson, N.C. 27893 U.S.A. UNIX is a trademark of Unix System Laboratories Linux is not a trademark, and has no connection to UNIX[TM] or Unix System Laboratories. Copyright (c) 1993 Matt Welsh 205 Gray Street NE, Wilson NC, 27893 USA mdw@tc.cornell.edu Linux Installation and Getting Started may be reproduced and dis- tributed in whole or in part, subject to the following conditions: 0. The copyright notice above and this permission notice must be preserved complete on all complete or partial copies. 1. Any translation or derivative work of Linux Installation, Set- up, and Getting Started must be approved by the author in writing before distribution. 2. If you distribute Linux Installation and Getting Started in part, instructions for obtaining the complete version of this manual must be included, and a means for obtaining a com- plete version provided. 3. Small portions may be reproduced as illustrations for reviews or quotes in other works without this permission notice if proper citation is given. 4. The GNU General Public License referenced below may be reproduced under the conditions given within it. 5. Several sections of this document are held under separate copyright. When these sections are covered by a different copyright, the separate copyright is noted. If you distribute Linux Installation and Getting Started in part, and that part is, in whole, covered under a separate, not- ed copyright, the conditions of that copyright apply. Exceptions to these rules may be granted for academic purpos- es: Write to Matt Welsh, at the above address, or email mdw@tc.cornell.edu, and ask. These restrictions are here to protect us as authors, not to restrict you as educators and learners. All source code in Linux Installation and Getting Started is placed under the GNU General Public License. See appendix E for a copy of the GNU "GPL." Documentation Conventions These conventions should be obvious, but we'll include them here for the pedantic. Bold Used to mark new concepts, WARNINGS, and keywords in a language. italics Used for emphasis in text, and occasionally for quotes or introductions at the beginning of a sec- tion. Also used to indicate commands for the user to type when showing screen interaction (see be- low). Used to mark meta-variables in the text, espe- cially in representations of the command line. For example, ls -l where would "stand for" a filename, such as /bin/cp. Typewriter Used to represent screen interaction, as in $ ls -l /bin/cp -rwxr-xr-x 1 root wheel 12104 Sep 25 15:53 /bin/cp Also used for code examples, whether it is C code, a shell script, or something else, and to display general files, such as configuration files. When nec- essary for clarity's sake, these examples or figures will be enclosed in thin boxes. [Key] Represents a key to press. You will often see it in this form: Press [return] to continue. Chapter 1 Introduction This book is about Linux, the free clone of the UNIX operating system for 80386 and 80486 machines. The rationale for writing this manual is clear: as Linux has grown and gained popularity, the old approach of searching a myriad of old documentation and software, downloading megabytes of files, and hoping that every- thing works is no longer adequate. Surprisingly, the number of MS-DOS and OS/2 users who are moving to Linux is large, and many of these users are new to UNIX. Here, rolled into one book, is a complete guide to installing Linux, with enough introductory material on using UNIX to get new users on their feet. Linux is a clone of the UNIX operating system that runs on Intel 80386 and 80486 based machines. It supports a wide range of software, from TEX to X Windows to the GNU C/C++ compiler to TCP/IP. It's a versatile, bona fide implementation of UNIX, freely distributed by the terms of the GNU General Public License (see Appendix E). Before we delve any further, a few words about this book. 1.1 About This Book In this manual, we'll cover: o What Linux is; o How to obtain and install Linux on your system; o Getting started with Linux, even if you've never UNIX before; o The basics of Linux system administration; o An introduction to upgrading and installing new software. This manual assumes no previous knowledge of Linux or UNIX. Some experience with Intel-based personal computers is assumed, and familiarity with MS-DOS or Microsoft Windows is helpful. If you have previous UNIX experience, you may wish to skip ahead to Chapter 2, "Getting Linux," and then read through Chap- ter 3, "Installing Linux," and from there you're set. You may also wish to read Chapter 6, discussing some of the more advanced and interesting features of Linux. The rest of the manual covers issues of concern to those new to UNIX. 1.2 Introduction to Linux and UNIX UNIX is one of the most popular operating systems worldwide be- cause of its large support base and distribution. It was originally developed as a multitasking system for minicomputers and main- frames in the mid-1970's, but has since grown to become one of the most widely used operating systems anywhere, despite its some- times confusing interface and lack of central standardization. The real reason for UNIX's popularity? Many hackers feel that UNIX is the Right Thing_the One True Operating System. Hence, the development of Linux by an expanding group of UNIX hackers who want to get their hands dirty with their own system. Doug Gwyn said, "UNIX was never designed to keep people from doing stupid things, because that policy would also keep them from doing clever things." Most UNIX hackers would agree. Versions of UNIX exist for many systems_ranging from person- al computers to to supercomputers such as the Cray Y-MP. Most versions of UNIX for personal computers are quite expensive and cumbersome. At the time of this writing, a one-machine version of AT&T's System V for the 386 runs at about US$1500. 1.2.1 Where Linux comes in Linux is a freely distributable version of UNIX developed primarily by Linus Torvalds (*Note: torvalds@kruuna.helsinki.fi.) at the University of Helsinki in Finland. Linux was developed with the help of many UNIX programmers and wizards across the In- ternet, allowing anyone with enough know-how and gumption to hack a custom UNIX kernel the ability to develop and change the system. The Linux kernel uses no code from AT&T or any other proprietary source, and much of the software available for Linux is developed by the GNU project at the Free Software Foundation in Cambridge, Massachusetts. However, programmers all over the world have contributed to the growing pool of Linux software. Linux supports almost all of the features of commercial ver- sions of UNIX, as well as many not found on proprietary UNIX systems. Furthermore, Linux is closely compatible with the IEEE POSIX.1 standard, and has been developed with software porta- bility in mind, thus supporting many important features of other UNIX standards. Linux also utilizes all of your system's memory_ without memory limits or segmentation. The Linux system runs exclusively in 80386's protected mode, which allows it to operate as a true 32-bit operating system. A little-known fact about the 80386 and 80486 chips is that, internally, these processors were designed to support multitasking systems such as UNIX. Unfortu- nately, even MS-DOS 6.0 has yet to exploit these features. There is a rumor abound that UNIX is a large, unwieldy system, unapproachably hungry for resources such as disk space and mem- ory. In Linux, the proof to dispell those myths was implemented. Linux is small, fast, and flexible. It requires fewer resources than IBM's OS/2, and uses less space than many MS-DOS or Microsoft Windows systems including large applications (such as Microsoft Word or Lotus 1-2-3). Linux has built-in support for networking, multitasking, and other features which you'll see touted as "New Technology" in systems such as in Windows NT. In fact, UNIX (and now, Linux) has implemented this "New Technology" for well over 15 years. The proprietary PC software industry is still catch- ing up. When using Linux, keep in mind that it is truly "a hacker's operating system"_developed by and for UNIX hackers. This is a strong distinction between commercial versions of UNIX, which are designed for customers, not for hackers. Commercial versions of UNIX are expected to work "out of the box". This is not the case with Linux. Because of this distinction, many newcomers get easily frustrat- ed with Linux. The only problem is a lack of basic UNIX know-how. Setting up and running your own UNIX system is something which most UNIX users never get to do, even after years of experience. Linux has provided UNIX newcomers the unique opportunity to "do it yourself"_but nobody said it was going to be easy. It takes a lot of time and effort to run your own UNIX system (and a certain knack for fixing problems). Even with standard Linux distributions, such as SLS, there are sometimes little quirks which need to be fixed by hand in order for everything to work correctly. If you have previous UNIX experience, it should be easy to find these problems. However, if you're new to UNIX, it would serve you well to read up on using and running a UNIX system before you dive in. Put simply, Linux isn't for everyone. Many users get in "over their heads" when getting started with Linux. To keep your head above water, we strongly encourage you to find a good book on using UNIX, as well as a book on UNIX system administration. In this manual, we include an introductory UNIX and system admin- istration tutorial, but this is the bare minimum that is needed to get started. The Linux Documentation Project is working to solve this dilem- ma. In the future, the LDP's Linux User's Guide and Linux System Administration Guide will be available. Until then, you'll need to rely on other sources. See Appendix B for a list of relevant UNIX books and other sources of information. 1.3 About Linux's Copyright Linux is copyrighted under the GNU General Public License, some- times called the GPL or copyleft. This license was developed by the Free Software Foundation to allow programmers to write "free software", where "free" refers to freedom, not just cost. The GPL provides for the protection of such free software in a number of ways. First of all, it allows the original author to retain the soft- ware's copyright. Secondly, it allows others to take the software and modify it, or base other programs on it. Thirdly, it allows others to redistribute or resell the software, or modified versions of the software. You can even resell the software for profit. However, in reselling or redistributing the software, you cannot restrict any of these rights from the party you're selling it to. Also, if you sell the software, you have to provide at no cost the full source code so that others can modify the software and resell it if they wish. This might sound a bit silly at first. Why sell software for prof- it, if someone else can give it away for free? Essentially, that's the point. However, let's say someone bundles a large amount of free software together on a CD-ROM and wishes to distribute it world- wide. They'll probably need to charge for this service to cover their cost and risk in distributing the software. Right now, several or- ganizations are distributing Linux on CD-ROM, and making profit from it. The original authors of the Linux software may never see a penny of these revenues. This is allowed by the GNU GPL_ the point of free software isn't to make money; nobody's getting ripped off. That's simply an understanding between the authors of the software and those who are using it or selling it. One other thing: Free software, as covered by the GNU G- PL (which includes Linux), comes with absolutely no warranty. However, individual vendors may provide support for the software, which usually includes a warranty. However, unless you purchased such support, the assumption is that the software comes with no such warranty, and if you use a piece of free software which goes haywire and wipes everything on your system, neither the authors nor those that distributed the software to you are liable (*Note: Hopefully, this won't happen.). Free software as covered by the GPL is not shareware, nor is it in the public domain. Neither of these terms correctly describe what free software really is. The complete GNU GPL is printed in Appendix E. To sum it all up, you can freely distribute Linux as much as you like, and you can even modify it and distribute your own version of Linux. But in doing so, you can't take away those rights from others. Furthermore, you must attribute the original authors of the work. 1.4 Features of Linux Here are some of the benefits and features that Linux provides over single-user operating systems (such as MS-DOS) and other versions of UNIX for the PC. o Full multitasking and 32-bit support. Linux, like all oth- er versions of UNIX, is a real multitasking system, allowing multiple users to run many programs on the same system at once. The performance of a 50 MHz 486 system running Lin- ux is comparable to many low- to medium-end workstations, such as those from Sun Microsystems and DEC, running pro- prietary versions of UNIX. Linux is also a full 32-bit operating system, utilizing the special protected-mode features of the Intel 80386 and 80486 processors. o GNU software support. Linux supports a wide range of free software written by the GNU Project, including utilities such as the GNU C and C++ compiler, gawk, groff, and so on. Many of the essential system utilities used by Linux are GNU software. o The X Window System. The X Window System is the de facto industry standard graphics system for UNIX ma- chines. A free version of The X Window System (known as "Xfree86") is available for Linux. The X Window System is a very powerful graphics interface, supporting many applica- tions. For example, you can have multiple login sessions in different windows on the screen at once. Other examples of X Windows applications are Seyon, a powerful telecommuni- cations program; Ghostscript, a PostScript language proces- sor; and XTetris, an X Windows version of the popular game. See Section 6.1 for an introduction to the X Window System. o TCP/IP networking support. TCP/IP ("Transmission Control Protocol/Internet Protocol") is the set of protocol- s which links millions of university and business computers into a worldwide network known as the Internet. With an Ethernet connection, you can have access to the Internet or to a local area network from your Linux system. Or, using SLIP ("Serial Line Internet Protocol"), you can access the Internet over the phone lines with a modem. Section 6.2 has an introduction to configuring the Linux TCP/IP software. o Virtual memory and shared libraries. Linux can use a portion of your hard drive as virtual memory, expanding your total amount of available RAM. Linux also implements shared libraries, allowing programs which use standard sub- routines to find the code for these subroutines in the libraries at runtime. This saves a large amount of space on your sys- tem, as each application doesn't store its own copy of these common routines. 1.5 Hardware Requirements Unlike some other versions of UNIX for the PC, Linux is very small. You can run an entire system from a single high-density 5.25" floppy. However, to run a complete Linux system, there are other hardware requirements, listed below. Linux, by its very nature, is continuously expanding, and more features are added every day. However, hardware compatibility is limited to that hardware which the developers themselves have access to. For instance, if none of the Linux developers has access to the Foobaz Net-O-Driver 3000 card, then chances are it isn't supported. On the other hand, there are many "generic" drivers_ for example, the IDE disk driver for Linux should work with all IDE hard drives and adapters. If your favorite peripheral isn't supported by Linux, all that's required is to write a kernel driver for it. This may be easy or dif- ficult, depending on the hardware and the technical specifications that are available. For example, some hardware developers prefer to write their own drivers for MS-DOS and Windows, and not re- lease specifications for third parties to write their own. Therefore, writing drivers for Linux will be difficult, if not impossible. (We call this practice "bad business" for the hardware vendors involved.) 1.5.1 Suggested setup Below, the suggested hardware configuration for Linux is listed. If you're in the market for a new system, you should follow the recom- mendations given below. In the next section, we'll talk about some of the hardware drivers which are currently under development for Linux, and other hardware which is known not to work. o An Intel 80386 or 80486 based system. You don't need a math coprocessor, although it's strongly recommended that you have one. (If you have an 80386 chip, 80387 math copro- cessors are available separately, and are installed in a socket on your motherboard. If you have an 80486 processor, the math coprocessor is on the 486 chip itself. The exception is the 80486SX, which is a 486 chip without the coprocessor components.) If you don't have a math coprocessor, the Lin- ux kernel will emulate floating-point math for you. If you do have one, however, floating point math will be handled by the hardware, which for some applications is a real plus. The 386SX, 486SX, and the accelerated 486DX and 486DX2 chips are all reported to work. It is suggested that you have a genuine Intel processor, instead of a clone (such as a CTX processor). Look for the "Intel Inside" logo on the machine. The forthcoming Intel Pentium chip should work with Linux without any changes. o Your system must be either an ISA, EISA, or local bus ar- chitecture machine. These terms specify how the CPU com- municates with hardware, and are a characteristic of your motherboard. Most existing systems use the ISA bus archi- tecture. The EISA bus is a newer form of the ISA bus, which is reportedly faster on some machines. Local bus architec- ture is often the fastest of the three, as it allows the CPU to communicate directly to video and drive adapters. If your machine uses local bus, it is strongly recommended that it comply with the VESA Local Bus standard (most local bus systems do). MicroChannel architecture (MCA) machines, such as the IBM PS/2 line, are not currently supported. o At least four megabytes of RAM. Technically, Linux is capa- ble of running on a system with only two megabytes, however, some distributions of Linux require four megabytes for instal- lation. Memory is speed, so if you have more physical RAM you'll thank yourself for it later. If you're a "power user," 8 megabytes should be more than enough for most applications. o An AT-standard compatible hard drive controller. This in- cludes MFM, RLL, ESDI, and IDE controllers. Many SCSI controllers are also supported. These terms specify the means used to communicate with the hard drive through the con- troller card; most controllers are either IDE or SCSI. Drivers for XT-standard driver controllers are under devel- opment; see the next section. o A hard drive (compatible with your controller card, of course), with free space available for installing Linux. The amount of space required depends on the amount of software you're installing and how much free space you wish to leave your- self. If you only install a small amount of software, less than 10 megabytes is required. However, if you install a number of optional software packages, including the X Window Sys- tem, perhaps 80 megabytes or more, including space for users, would be required. In addition, you will probably want to set aside some amount of space on your drive as a swap partition, used for virtual memory. This is covered in Chapter 3. o A Hercules, CGA, EGA, VGA, or Super VGA video card and monitor. In general, if your video card and monitor work under MS-DOS or Microsoft Windows, then Linux should be able to use them without any problem. However, if you're go- ing to use the X Window System, there are certain hardware configurations which are not yet supported. See Section 6.1 for more. 1.5.2 Other hardware There are other hardware drivers currently under development for Linux. However, to use these drivers, you usually have to patch them into your kernel code, which assumes that you already have a running Linux system. The Linux FAQ has information on patching in hardware driver- s with Linux. See Appendix B for more information. Linux will also run on a number of laptop machines (some lap- tops use certain software interrupts to power the memory, and Lin- ux doesn't cooperate with these systems, yet). The best way to find out if Linux will run on your hardware is just to try it out. 1.6 Before You Get Started Assuming that you have hardware compatible with Linux, obtain- ing and installing the system is not difficult. However, there are a number of burning questions which most users want answers to before they dive in. 1.6.1 Running other operating systems with Linux You can install other operating systems, such as MS-DOS or OS/2, along with Linux on the same machine. Each operating system uses its own partitions on the hard drive, and they do not interfere with each other. For example, if you want to install both MS-DOS and Linux on the same drive, fine. However, MS-DOS will use one partition on the drive, and Linux will use another. Partitioning your drive for use with Linux is covered in Section 3.2.3. To select which operating system to run at boot time, you can install LILO, a program which replaces the standard MS-DOS boot loader on your hard drive. With LILO installed, at boot time you select the operating system to run from a simple menu. Or, you can set a default operating system to boot, and override the default by holding down the [shift] key as the system is booting. LILO is covered in detail in Section 5.2.2. Alternately, if you use OS/2, you can boot Linux from the OS/2 Boot Manager. See Section 5.2.2 for more information. 1.6.2 Accessing files from MS-DOS Linux supports several features which will allow you to access y- our MS-DOS files from Linux. The mtools package, included with most distributions of Linux, allows you to use commands such as mcopy and mdir to access your MS-DOS files. Or, you can mount an MS-DOS partition or floppy directly under Linux, giving you direct access to your files using the MS-DOS filesystem. (See Sec- tion 6.1.6.) There is also an MS-DOS Emulator available for Linux, and work is beginning on a Microsoft Windows emulator to run under the X Window System. The MS-DOS Emulator isn't perfect; don't expect to play Wing Commander from Linux. However, it will enable you to run many standard MS-DOS applications, such as Wordperfect or Lotus 1-2-3. Watch out, Microsoft! 1.6.3 How to pronounce Linux Pronouncing the word "Linux" is one of the great mysteries of the Linux world. Americans pronounce the name Linus with a long i sound, as in pie. However, because Linux was originally based on a small, PC-based implementation of UNIX called "Minix" (pro- nounced with a short i ), the actual pronunciation of Linux pre- serves this characteristic_it's LIH-nucks. Think Finnish. 1.7 Finding Help There are many people out there who enjoy helping new users get started with Linux. If you have any problems with installing or us- ing the system, the first thing you should do is consult this manual (and the other Linux manuals) to see if your problem is covered there. Another good source of information is the Linux Frequently Asked Questions list, which covers many disparate topics not in this manual. Appendix B for information on the Linux FAQ and other sources of information. If you have access to USENET news, you can post questions to the newsgroup comp.os.linux. The moderated newsgroup comp.os.linux.announce is also available for announcements and important information. However, it's strongly suggested that you read all of the available documentation before posting questions; most problems are covered in this manual and the Linux FAQ list. You can also direct questions about this manual, or Linux in general, to the authors of this book. We're very open to any questions, comments, or suggestions. Matt Welsh can be reached on the Internet at mdw@tc.cornell.edu and Lars Wirzenius at wirzeniu@cc.helsinki.fi. Chapter 2 Getting Linux This chapter covers how to obtain the Linux software. If you re- ceived this manual with a set of Linux software, on disk or CD- ROM, then you can go ahead and skip to Chapter 3 on installing the system. 2.1 Distributions of Linux There is no single, "official" release of the Linux software. In fact, there are many releases, each independently coordinated by various companies and individuals. While these releases differ somewhat in their goals and specifications, each release has a number of elements in common with the rest: o The Linux kernel_the lowest level program of the Linux system, the operating system itself. The kernel is constantly running, handling the low-level details of memory manage- ment, process scheduling, device access, and so on. In any UNIX system, the kernel is the software which controls ac- cess to system resources (such as memory and processor time) from user programs (such as a text editor). This is in sharp contrast to operating systems such as MS-DOS, which allow only a single program to run at a time. o A set of utilities which handle basic system tasks such as manipulating files, creating users, reporting system activity, and so on. These programs are essentially the same on any UNIX system, and provide a standard interface for users. For example, the command to copy a file on all UNIX systems is known as cp. Therefore, using Linux will be very similar, if not identical, to using other versions of UNIX. o The system libraries, which contain common subroutines used by software to handle everything from file I/O to dis- playing graphics. Linux implements shared libraries, which allow programs to share the code in these subroutines, reduc- ing the size of program binaries significantly. o A set of system configuration files, containing information about the users on the system, available devices, network interface configuration, and so on. Many individual applica- tions also have their own set of configuration files. o Online documentation, in the form of manual pages (often abbreviated as "man pages"). Man pages document the com- mands, library routines, kernel system calls, file formats, and device driver interfaces available on the system. They are an excellent source of online help and are easy to use. The man pages available for Linux are incomplete, but most of the im- portant system commands and library calls are documented. o And, of course, application software. There are many appli- cations available for Linux, such as TEX (a document pro- cessing system), Emacs (a powerful yet baroque text editor), the X Window System (a graphics interface), and more. The application software is what really composes the Linux system from the user's point of view. However, it is all of these elements combined which form the entire system. As mentioned before, there isn't a single official distribution for all of this soft- ware. There are many distributions available_each of which differ somewhat in their installation methods and supported software, but all of which contain the essential elements listed above. In this book, we focus on the Softlanding Linux System (SLS) distribution of Linux. SLS has become the de facto standard for Linux installations worldwide. Because of its completeness and ease of use, we will only cover how to get and install the SLS distribution here. We don't mean to be biased towards a particular release; how- ever, it takes a lot of time and effort to keep up with all of the Linux distributions available. However, all of the concepts discussed in this book apply to Linux distributions other than SLS. 2.2 The SLS Distribution The Linux distribution that many people have installed is known as the Softlanding Linux System ("SLS") distribution. SLS is coordi- nated by Peter MacDonald (*Note: pmacdona@sanjuan.uvic.ca.), and has become the most widely-used release of Linux, because of its completeness and ease of installation. The SLS distribution is broken into various sets of disks, each of which is denoted by a letter followed by a disk number. For example, the a series disks are numbered a1, a2, a3, and a4. The disk series in the current SLS distribution are shown below. o a1-a4: The minimal base system, required. Contains the Linux kernel, libraries, basic binaries, and tools used to set up and install the system. o b1-b7: Base system extras, such as man pages, Emacs, and so on. o c1-c3: Compilers, such as gcc, p2c, f2c, and others. o x1-x10: The X Window System and related software. o t1-t3: TEX, a document formatting system. o s1: Source code for several of the packages. Currently under development. o d1-d2: Documentation for various things. As more packages are added to SLS, new series are added, or extra disks are added to the existing series. The only set of disks which you must install are the a set. However, you should probably install at least the b and c disk sets as well, which contain the full base system and compilers. For X Windows (see Section 6.1) you should install the x series in addition to a, b, and c. It is easy to upgrade your software with the SLS distribution. For example, you could install only the a and b series, and install the c and x series at another time. Therefore, you may wish to only install the SLS a series at first, to try out a minimal system, and install the rest later. The amount of disk space required for installing the SLS release depends on how many of the series you install. Table 2.1 summa- rizes the disk space requirements for installing each SLS package. Package Disk series Approximate space requirements ------------ -------------------- ------------------------------------ Tiny a 15 megabytes Base a, b, c 45 megabytes Main a, b, c, x 70 megabytes Full a, b, c, x, d, s, t 90 megabytes Table 2.1: SLS Disk Space Requirements Also keep in mind that in addition to the space requirements listed in Table 2.1, you'll need to set aside extra space for swap (see Section 3.2.3) and for user accounts, free space to install new software, and so on. 2.2.1 Getting SLS from the Internet If you have access to the Internet, you can download the SLS distri- bution via FTP from a number of sites. If you've never used FTP before, see Appendix C for a quick tutorial. If you don't have In- ternet access, you can get SLS either via mail or from a number of BBS's worldwide; see sections 2.2.2 and 2.3 for more information. 2.2.1.1 Downloading the files The two primary FTP sites from which to obtain the SLS distri- bution are tsx-11.mit.edu and sunsite.unc.edu. In addition, a large number of FTP sites around the world mirror these two_see Appendix C for a listing of Linux FTP sites. The SLS release is kept in the directory /pub/linux/SLS on tsx-11.mit.edu, and in /pub/Linux/SLS on sunsite.unc.edu (note that the filenames are case-sensitive). You should download the following files. Be sure to use binary mode when downloading them. o If you boot from a 3.5" floppy, download the file a1.3. If you boot from a 5.25" floppy, download a1.5 instead. These files are images of the SLS a1 disk which is used for booting the system (*Note: Some FTP sites have the files a1.3.Z and a1.5.Z instead. These are compressed images of the a1 disk; you'll need to use the UNIX uncompress command to uncom- press it. We've requested that FTP sites leave the files a1.3 and a1.5 uncompressed for this step to be unnecessary for those downloading to a non-UNIX machine; both tsx-11 and sunsite should have them both in uncompressed format.). Hereafter, we'll be referring to the files a1.3 and a1.5 simply as "a1"_because you'll only be downloading one or the other. o rawrite.exe: A DOS program to "raw write" a given file, block by block, to an MS-DOS formatted floppy. You will use rawrite to create the a1 disk. Note that rawrite.exe may not be in the SLS directory, but it should be somewhere nearby on the FTP site. On sunsite.unc.edu, rawrite is found in: /pub/Linux/SLS/DOSUTILS/rawrite2.exe On tsx-11.mit.edu, rawrite is found in: /pub/Linux/INSTALL/dos_utils/rawrite.exe o The files in the a2, a3 and a4 directories. Be sure to keep these files in separate directories when you download them. Later, you'll simply copy these files to MS-DOS floppies, but you don't want to get the a2, a3 and a4 files mixed up. o If you plan to get any of the other series, you need to down- load the files in their corresponding directories. For example, if you're downloading the b disk series, grab the files in the directories b1 through b7. As with a2 through a4, keep the files in each directory separate as you download them. o The files SLS.FAQ and SLS.README, which are text files giving important information about the current release of SLS. 2.2.1.2 Transferring the files to MS-DOS Once you have these files, transfer all of them to an MS-DOS sys- tem, in order to create the installation disks (*Note: If you have access to a UNIX machine with a floppy drive, you can create the installation disks from there. See Section A.4.). If you did not FTP the files directly to an MS-DOS system, you may need to ask your local computer guru for information on transfering the files to MS-DOS. The methods used to do this vary from site to site. 2.2.1.3 Making the installation disks To create the installation disks, you'll be using rawrite.exe as well as the MS-DOS COPY command. First, be sure that you have one MS-DOS formatted, blank floppy for each disk in the SLS series that you downloaded (*Note: It is possible to install SLS directly from your hard drive, instead of from floppies. See Section A.1 for more information.). All of the floppies must be formatted high density (either 1.2Mb 5.25" or 1.44Mb 3.5"). The floppy used for the a1 disk must be the type of floppy that you boot from on your system. To create the a1 disk, run the command C:\> rawrite from MS-DOS. You should see something like RaWrite 1.2 - Write disk file to raw floppy diskette Enter source file name: Specify the filename that you wish to rawrite (such as a1.3 or a1.5), followed by the drive that you wish to write it to (either A: or B:). Enter source file name: a1.5 Enter destination drive: A: Please insert a formatted diskette into drive A: and press -ENTER- : Press [return] and rawrite will copy the file to the disk in the specified drive. Number of sectors per track for this disk is 15 Writing image to drive A:. Press ^C to abort. Track: 00 Head: 0 Sector: 1 ... Done. Once rawrite is done, the floppy will no longer be accessible by MS-DOS. The floppy has been completely overwritten with the a1 image, and is now a "Linux-format" floppy. If you have problems with rawrite, make sure that the floppy is MS-DOS formatted, high density. If the floppy has any bad sectors you may just need to use another disk. The rest of the disks are created using the MS-DOS copy com- mand. All of these disks must be of the same type (either 3.5" or 5.25") and must be high-density MS-DOS formatted as well. Copy all of the files from the a2 directory to a floppy labeled a2. For example, For example, C:\A2> copy *.* A: will copy all of the files in the directory C:\A2 to the disk in A:. Repeat the procedure for the rest of the disks in the SLS dis- tribution. Remember that you must have at least a1 through a4. After you are finished creating the disks, you can install the soft- ware. This is covered in Chapter 3. 2.2.2 Getting SLS via U.S. Mail The SLS distribution is also available on floppy via U.S. Air or Land mail. A small fee is charged on a per-disk basis, but this fee is nominal and more than worth the service. This is a reliable way to get the SLS distribution, even if you do have network access_it saves you a lot of time downloading and creating the disks yourself. To order, send a check or money order to: Softlanding Software 910 Lodge Ave. Victoria, B.C., Canada V8X-3A8 By the beginning of 1993, they hope to take Visa and/or Mas- tercard orders by telephone. Their number is +1 604 360 0188. They do take international orders, so if you're not in the States or Canada you can still get the SLS distribution by mail from this address. The charge is on a per disk basis. The complete distribution (that is, all of the a, b, c, x, and t series) is currently 29 disks, but more disks are added to the distribution on occasion. The copying charge is $3.25/disk US ($4.00/disk Canadian). For 3.5" disks, add $1.00/disk. There is also a $10.00 shipping and handling charge. Table 2.2 summarizes the various packages and prices. Package #Disks Series 5.25" Disks 3.5" Disks -------- ------- --------- ------------------------ ------------------------ Tiny 4 a US $23.00 (CDN $26.00) US $27.00 (CDN $30.00) Base 16 a,b,c US $62.25 (CDN $74.00) US $78.00 (CDN $90.00) Main 24 a,b,c,x US $88.00 (CDN $106.00) US $112.00 (CDN $130.00) Full 29 a,b,c,x,t US $104.25 (CDN $126.00) US $133.25 (CDN $155.00) Table 2.2: SLS by-mail disk prices 2.3 Getting Linux from BBSs Using a modem and standard communications software, you can also download Linux from a number of bulliten board systems (BB- Ss) worldwide. You'll likely find a version of the SLS distribution on these BBS sites, with each disk image packed into a PKZIP .zip archive file. The PKUNZIP utility, used to unpack these files before you transfer the files to floppies, should be easy to locate (perhaps on the BBS itself). For the most part, you can follow the directions for creating the SLS floppies in Section 2.2.1.3 once you have downloaded the files. Just be sure that the files on the a2, a3, etc. disks are expanded_ in other words, the SLS a2 contains a number of .tgz files. If you download a single a2.zip from the BBS, you may need to use PKUNZIP to get those .tgz files before you place them on the floppy. In any case, there should be a README describing how to load and install the release of Linux found on the BBS. What version and distribution of Linux you find on these BBS's is really up in the air_we can make no guarantees that you'll find a particular release in a particular format, or that the files on the BBS are up-to-date. Every BBS is different. If you're unfamiliar with downloading files from BBS's, it's real- ly quite simple. You need a modem and communications software, to begin with. The communications software should come with complete instructions on how to dialup a BBS and how to down- load software_the mechanism differs greatly depending on your modem and your software. If all else fails, have a computer guru near you show you how it's done. Printed in Appendix D is a list of BBS sites which carry Linux software. You should be able to find a BBS within reasonable calling distance. If not, and if you don't have Internet access of some kind, you may want to consider ordering the SLS distribution of Linux via mail. See Section 2.2.2 for details. Chapter 3 Installing Linux In this chapter, we'll go through the steps of installing Linux, from repartitioning your drive, to setting up the Linux filesystems, to actually installing the software. As you're partitioning your drive and installing Linux, it's al- ways a good idea to take notes of every command you type and what goes on during the process, just so you have something to refer to when you run into those inevitable problems. Trust me; it's worth the time it takes just to jot down notes while installing, especially if you're a newcomer to Linux. If you have problems lat- er and have to ask for help, having a list of exactly what commands you typed and what the results were will be invaluable. 3.1 SLS installation overview This is an overview of installing the SLS release of Linux. As mentioned before, the basic ideas are applicable to distributions other than SLS as well. To install the SLS release, you're doing to do the following: o Backup any software (for MS-DOS, OS/2, etc.) on your sys- tem. (Section 3.2.3.) o Repartition your drive to allocate space for Linux. (Sec- tion 3.2.3.) o Reinstall the original software on your system. (Section 3.2.3.) o Boot the SLS a1 disk, and create partitions for Linux. (Sec- tion 3.3.4.) o Create filesystems on those partitions. (Section 3.3.7.) o Finally, install the software. (Section 3.4.) 3.2 Repartitioning your Drive As we have mentioned, in order to allocate space for Linux on your hard drive(s), you'll need to repartition the drive(s), resizing any existing partitions. Until now, most users of 386 and 486 systems haven't had to worry about partitioning their hard drive, or even running more than one operating system on the same drive (unless you're an OS/2 user). Thus, some explanation of hard drives and partitions is probably in order. 3.2.1 Hard drive geometry A typical hard drive consists physically of one or more circular platters which rotate about a central axis. The read/write heads move to specified place on the disk surface to access information. There is typically one head on each side of every platter, which all move in unison back and forth across the platter (that is, either closer to the center of the disk, or closer to the outer edge). The drive platters are divided into cylinders, which is the area of each platter which can be accessed without moving the heads. A cylinder is a barrel-shaped cross section of a disk, consisting of a circular strip from each side of each platter. The part of a cylinder which is the circular strip on a single platter is called a track. Thus, if there are 3 platters in a given drive (stacked on each other, like a sandwich), then you have a read/write head on each side of each platter, to make up 6 heads. (In actuality, the outer surface of the outermost platters don't usually have heads accessing them, so in this case you'll have only 4 heads.) Thus if you position the heads at a single radius from the center of the disk, the area which they can access by rotating the platters is one cylinder. A track is the area which one head can access. Thus, for our drive with 4 heads, there are 4 tracks per cylinder. Each track is divided into a number of pie-shaped sliced called sectors, which are the smallest parts of the disk which can be read or written at one time. Therefore, the geometry of the disk is specified as o The number of cylinders that the disk contains; o The number of tracks per cylinder (same as the number of heads); o The number of sectors per track; and, o The size of each sector (in bytes). Some of these numbers will vary, but a typical disk might have about 1000 cylinders, 6 heads, 15 or 20 sectors per track, and each sector containing 512 bytes. The size of the disk is (1000 cylinders) * (6 tracks per cylinder) * (15 sectors per track) * (512 bytes per sector) or 46,080,000 bytes (about 46 megs). 3.2.2 Partitions Hard drives are divided into one or more partitions which are sections of the hard drive set aside for some operating system to use. The concept of a partition allows you to have, for instance, MS-DOS running on one partition on your hard drive, and Linux on another. Many MS-DOS systems have only a single partition taking up the entire drive. To MS-DOS, this partition is known as C:. If you have more than one partition on your drive, MS-DOS names them D:, E:, and so on. In a way, each partition acts like a separate hard drive. On the the first cylinder, first head, and first sector of the disk is a 1-sector master boot record along with a partition table. The boot record (as the name implies) is used to boot the system. The partition table contains information about the locations and sizes of your partitions. There are three kinds of partitions: primary, extended, and logical. Of these primary partitions are by far used most often. However, because of a limit in the size of the partition table, you can only have 4 primary partitions on any given drive. The way around this 4 partition limit is to use an extended partition. An extended partition doesn't hold any data by itself; instead, it acts as a "container" for logical partitions. Therefore, you could create one extended partition, covering the entire drive, and within it create several logical partitions. However, you may have only one extended partition per drive. 3.2.3 Resizing your current partitions If your hard drive is currently taken up by partitions for other operating systems, you'll need to delete and resize those partitions to allocate space for Linux. If you don't have any other operating systems installed (you're installing Linux on a clean system), you can skip to Section 3.3. There isn't any safe or reliable way to resize an existing partition without deleting it. Therefore, before repartitioning your drive, backup your system. After you have repartitioned the drive, you can reinstall your original software from the backups. Also keep in mind that because you'll be shrinking your original partitions, you may not have space to reinstall everything. How much space should you leave free for Linux? This depends greatly on how much software you're installing, and how much free space you want to leave yourself. In Section 3.3.2 we'll cover this in detail. Under MS-DOS, the program used to modify partitions is FDISK (*Note: Instructions for modifying partitions for operating systems other than MS-DOS are similar to those presented here. Refer to the documentation for those systems, if applicable.) In order to repartition, you should create an MS-DOS bootable "system disk" which contains all of the necessary DOS utilities, including FDISK.EXE and FORMAT.COM (*Note: You can format an MS-DOS system disk with the command format /s A:.). Boot from this disk, and run FDISK. Use of FDISK should be self-explanatory, but consult your MS- DOS documentation for details. When you start FDISK, use the menu option to display the partition table, and write down the information displayed there. It is important to keep a record of your original setup in case you want to back out of the Linux installation. To delete an existing partition, choose the fdisk menu option to Delete an MS-DOS Partition or Logical DOS Drive. Specify the type of partition that you wish to delete (primary, extended, or logical) and the number of the partition. Verify all of the warnings. Poof! To create a new (smaller) partition for MS-DOS, just choose the fdisk option Create an MS-DOS Partition or Logical DOS Drive. Specify the type of partition (primary, extended, or logical), and the size of the partition to create (specified in megabytes). fdisk should create the partition and you're ready to roll. After you're done using fdisk, you should exit the program and reformat the new partition(s). For example, if you resized the first DOS partition on your drive (C:) you should run the command format /s C: You may now reinstall your original software from backup. A warning: When repartitioning, you should only use the ver- sion of fdisk for the operating system that you are manipulating partitions for. That is, you should not use MS-DOS's fdisk to make partitions for Linux, and vice versa. In some cases, doing so won't cause any damage, but will cause MS-DOS not to boot correctly. For manipulating MS-DOS partitions, use MS-DOS's version of fdisk, and for Linux partitions use Linux's version of fdisk. 3.3 Creating your Linux Partitions and Filesystems Setting up partitions for Linux is very similar to setting them up for other operating systems such as MS-DOS. To create your Linux partitions, you use the Linux version of the fdisk program. After you create the partitions, you create filesystems on them, which allows them to be used by the Linux system. Making a filesystem is analogous to "formatting" a partition under MS-DOS. Because your swap partition doesn't hold files, we call preparing it "making the swap space". 3.3.1 Drives and partitions under Linux Drives and partitions under Linux are given different names than their MS-DOS counterparts. Under MS-DOS, floppy drives are referred to as A: and B:, while hard drive partitions are named C:, D:, and so on. Under Linux, the naming convention is quite different, but easier to comprehend. Device drivers, found in the directory /dev, are used to com- municate with devices on your system (such as hard drives, mice, and so on). For example, if you have a mouse on your system, access to it is through the driver /dev/mouse. Floppy drives, hard drives, and individual partitions are all given device drivers through which you access them. Table 3.1 lists the names of these various device drivers. Device Name --------------------------------------------------- -------------- First floppy (A:) /dev/fd0 Second floppy (B:) /dev/fd1 First hard drive (entire drive) /dev/hda First hard drive, primary partition 1 /dev/hda1 First hard drive, primary partition 2 /dev/hda2 First hard drive, primary partition 3 /dev/hda3 First hard drive, primary partition 4 /dev/hda4 First hard drive, logical partition 1 /dev/hda5 First hard drive, logical partition 2 /dev/hda6 . . . Second hard drive (entire drive) /dev/hdb Second hard drive, primary partition 1 /dev/hdb1 . . . First SCSI hard drive (entire drive) /dev/sda First SCSI hard drive, primary partition 1 /dev/sda1 . . . Second SCSI hard drive (entire drive) /dev/sdb Second SCSI hard drive, primary partition 1 /dev/sdb1 (and so on...) Table 3.1: Linux partition names A few notes about this table. Note that /dev/fd0 corresponds to the first floppy drive (A: under MS-DOS) and /dev/fd1 corre- sponds to the second floppy (B:). Also, SCSI hard drives are handled differently than other drives. IDE, MFM, and RLL drives are accessed through the devices /dev/hda, /dev/hdb, and so on. The individual partitions on the drive /dev/hda are /dev/hda1, /dev/hda2, and so on. However, SCSI drives are named /dev/sda, /dev/sdb, etc., with partition names such as /dev/sda1 and /dev/sda2. Here's an example. Let's say that you have a single IDE hard drive, with 3 primary partitions. The first two are set aside for MS-DOS, and the third is an extended partition which has two logical partitions, both for use by Linux. The devices referring to these partitions would be: First MS-DOS partition (C:) /dev/hda1 Second MS-DOS partition (D:) /dev/hda2 Extended partition /dev/hda3 First Linux logical partition /dev/hda5 Second Linux logical partition /dev/hda6 Note that /dev/hda4 is skipped; it corresponds to the fourth primary partition, which we don't have. Logical partitions start with /dev/hda5 and go on up. 3.3.2 Partition sizes for Linux For Linux, you will need to create at least two partitions. One will be used as the root partition, which contains the Linux software (*Note: You may choose to create separate partitions for each part of your Linux directory tree, using multiple filesystems. If you have UNIX system administration experience, you may be able to par- tition you drive more creatively. See Section A.3 for information.). The second will be used as the swap partition, which acts as virtual memory on your system (*Note: Instead of using a swap partition, you may use a swap file. See Section A.5 for more infor- mation.). Swap space is very important for Linux: it allows you to run many more programs at once than you would be able to other- wise. This is especially important if you're low on physical RAM, or if you're running X Windows. Even if you have 16 megabytes or more of physical RAM, using swap space on your hard drive is a good idea. The size of your root partition depends greatly on how much software you're installing. Section 2.2 should give you an idea of the diskspace requirements for the SLS distribution of Linux. For ex- ample, a minimal SLS installation (only the a series disks) requires about 15 megabytes for the root partition, while a full installation requires 90 megabytes. You should also leave yourself room for expansion_space to install new software, space for users, and so on. The size of your swap partition depends on the amount of phys- ical RAM you have, and how much swap space you want. Swap space is used as virtual memory by Linux. Remember that Linux is a multitasking operating system; this allows you to run many programs at once. Because the number of simultaneously running programs may require more memory than you have, use of swap space is vital. Also, the more swap space you have, the less Linux will need to swap programs back and forth between real memory and virtual memory. It is generally suggested that you have twice the amount of swap space than you have physical RAM. For example, if you have 4 megabytes of physical RAM, an 8-megabyte swap partition should suffice. However, the decision is really up to you. If you have 16 megabytes or more of physical memory, an 8- or 16-megabyte swap partition should be more than enough. However, your swap partition cannot be larger than 16 megabytes. You can use multiple swap partitions (up to 8) if you wish_if you'd like to have 32 megabytes of swap, simply create two 16-megabyte swap partitions. 3.3.3 Booting SLS You are now ready to boot the SLS release on your system to start the installation. To boot SLS, simply boot the a1 disk on your system. While booting, hold down the [ctrl] or [alt] key. You should see the prompt LILO Followed by a boot menu. At this point, you have two options: to boot the floppy with the ramdisk enabled, or to boot without the ramdisk. If you have at least 4 megs of RAM in your machine, then you can just press [return] or type ramdisk to boot with the ramdisk enabled. This will speed up operations while you're using the a1 disk. However, if you have only 2 megs of RAM in your machine, you'll need to type floppy to boot without the ramdisk. The other options on the menu are for installing the Mitsumi CD-ROM release of SLS (see Section A.2) or for booting Linux from the hard drive (after you've installed it). As the system boots, you'll be asked to Press to see SVGA-modes available or to continue Press [space] to use the standard 80x25 mode (not all SVGA modes work on all displays). There will be a short pause wile the system uncompresses the kernel (you should see "Uncompressing Linux" at the top of your screen. Also, there may be a 5-10 second pause after the lp_init... line at bootup, while the system checks for SCSI devices. Don't panic! Finally, you should see the message Welcome to the SLS install/bootdisk. and be given the login prompt softland login: Here, login as root (no password, of course). softland login: root softland:/# To look at the installation information on the disk, use the com- mand softland:/# install.info Instead, if you login as install, you will be presented with an installation menu. In the following sections, we cover how to install the system by hand, instead of using the SLS menus. This is because manual installation is applicable to Linux distributions other than SLS, and also because it's a good idea to know how to use the commands directly (without the menu). However, the con- cepts behind using the SLS install menu and using the commands directly are the same. 3.3.4 Running fdisk After booting Linux, run fdisk by typing fdisk where is the Linux device name of the drive you plan to add partitions to (see Table 3.1 on page 26). For instance, if you want to run fdisk on the first SCSI disk in your system, use the command fdisk /dev/sda. /dev/hda (the first IDE drive) is the default if you don't specify one. If you are creating Linux partitions on two separate drives, run fdisk once for each drive. # fdisk /dev/hda Command (m for help): Here fdisk is waiting for a command; you can type m to get a list of options. Command (m for help): m Command action a toggle a bootable flag d delete a partition l list known partition types m print this menu n add a new partition p print the partition table q quit without saving changes t change a partition's system id u change display/entry units v verify the partition table w write table to disk and exit x extra functionality (experts only) Command (m for help): The n command is used to create a new partition. Most of the other options you won't need to worry about. To quit fdisk without saving any changes, use the q command. To quit fdisk and write the changes to the partition table to disk, use the w command. The first thing you should do is display your current partition table and write the information down, for later reference. Use the p command. Command (m for help): p Disk /dev/hda: 16 heads, 38 sectors, 683 cylinders Units = cylinders of 608 * 512 bytes Device Boot Begin Start End Blocks Id System /dev/hda1 * 1 1 203 61693 6 DOS 16-bit >=32M Command (m for help): In this example, we have a single DOS partition on /dev/hda1, which is 61693 blocks (about 60 megs). This partition starts at cylinder number 1, and goes to cylinder 203. We have a total of 683 cylinders in this disk; so there are 480 cylinders left to make Linux partitions on. To create a new partition, use the n command. In this example, we'll create two primary partitions (/dev/hda2 and /dev/hda3, respectively) for Linux. Command (m for help): n Command action e extended p primary partition (1-4) Here, fdisk is asking the type of the partition to create: extended or primary. In our example, we're creating only primary partitions, so we choose p. Partition number (1-4): Fdisk will then ask for the partition to create; since partition 1 is already used, our first Linux partition will be number 2. Partition number (1-4): 2 First cylinder (204-683): Now enter the starting cylinder number of the partition. Since cylinders 204 through 683 are unused, we'll use the first available one (number 204). There's no reason to leave empty space in be- tween your partitions. First cylinder (204-683): 204 Last cylinder or +size or +sizeM or +sizeK (204-683): Fdisk is asking for the size of the partition to create. We can either specify an ending cylinder number, or a size in bytes, kilobytes, or megabytes. Since we want our partition to be 80 megs in size, we specify +80M. Last cylinder or +size or +sizeM or +sizeK (204-683): +80M Warning: Linux cannot currently use 33090 sectors of this partition This warning can be ignored. Fdisk prints the warning because it's an older program, and dates before the time that Linux partitions were able to be larger than 64 megabytes. Now we're ready to create our second Linux partition. For sake of demonstration, we'll create it with a size of 10 megabytes. Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 3 First cylinder (474-683): 474 Last cylinder or +size or +sizeM or +sizeK (474-683): +10M Lastly, we'll display the partition table. Again, write down all of this information_especially the block sizes of your new parti- tions. You'll need to know the sizes of the partitions when creating filesystems, later. Command (m for help): p Disk /dev/hda: 16 heads, 38 sectors, 683 cylinders Units = cylinders of 608 * 512 bytes Device Boot Begin Start End Blocks Id System /dev/hda1 * 1 1 203 61693 6 DOS 16-bit >=32M /dev/hda2 204 204 473 82080 81 Linux/MINIX /dev/hda3 474 474 507 10336 81 Linux/MINIX As you can see, /dev/hda2 is now a partition of size 82080 block- s (which corresponds to about 80 megabytes), and /dev/hda3 is 10336 blocks (about 10 megs). Finally, we use the w command to write the changes to disk and exit fdisk. Command (m for help): w # Keep in mind that none of the changes you make while running fdisk will take effect until you give the w command, so you can toy with different configurations and only save them when you're done. Also, if you want to quit fdisk at any time without saving the changes, use the q command. Also remember that you shouldn't modify partitions for any operating systems other than Linux with the Linux fdisk program. 3.3.5 Rebooting the system Before you create your filesystems, you need to reboot the system in order for the changes to the partition table to take effect. You should boot the system from the diskette or CD-ROM for your distribution of Linux, as before. (You can't boot from the hard drive, yet, because you haven't installed the Linux software). Under Linux, you should never reboot the system with [ctrl- alt-del] (the "Vulcan Nerve Pinch") or by pressing the reset button on your system. This is because Linux, like other versions of UNIX, buffers disk I/O in memory. The system only writes the memory buffers to disk every 30 seconds or so. If you were to reset the system before it was able to "sync" and write the information to disk, you would corrupt the data on your hard drive. To reboot your system, use the command shutdown -r now This will sync and reboot the system safely. If you only want to shutdown the system (that is, so you can turn it off), give the command shutdown now (without the -r). 3.3.6 Making the swap space After you have created your Linux partitions, you are ready to "format" them by creating a filesystem on the root partition, and preparing the swap space on the swap partition. First, let's create the swap space. Reboot the system, as de- scribed above, and login as root. The command used to prepare swap space is mkswap, and it takes the form mkswap -c where is the name of the swap partition you have cre- ated, and is the size of the partition, in blocks (*Note: This is the size as reported by fdisk, using the p menu option.). For example, if your swap partition is on /dev/hda2 and is 8208 blocks in size, use the command # mkswap -c /dev/hda2 8208 The -c option tells mkswap to check for bad blocks on the partition when creating the swap space. 3.3.7 Creating the filesystems As mentioned previously, before you may use your Linux root par- tition to store files, you must create a filesystem on it. There are several types of filesystems available for Linux. The most common- ly used filesystem type is the Linux Second Extended Filesys- tem, or ext2fs_it is used by the majority of Linux users worldwide. Because of the ext2fs's popularity, speed, and robustness, we'll on- ly cover the creation of an ext2fs-type filesystem here (*Note: If you're interested in using a filesystem type other than the ext2fs, see the Linux FAQ. Information on obtaining the FAQ is found in Appendix B.). To create a filesystem on the Linux root partition, use the com- mand mke2fs -c where is the name of the Linux root partition, and is the size of the partition in blocks. For example, to create a 60400-block filesystem on /dev/hda3, use the command mke2fs -c /dev/hda3 60400 If you're creating more than one filesystem for Linux (see Sec- tion A.3), you'll need to use the appropriate mke2fs command for those partitions as well. 3.4 Installing SLS The doinstall command is used to install SLS. It is relatively straightforward, and prompts you for a number of options before installing. 3.4.1 The SLS bootdisk Before you begin, make sure you have in hand an MS-DOS for- matted floppy, which will be used during the installation process to create a Linux boot disk: essentially, a copy of the Linux kernel used to boot your system (*Note: In Section 5.2.2, we'll cover how to install LILO to boot your system from the hard drive. Booting Linux from floppy is no big deal; once it's finished booting con- trol is transferred to the hard drive, and the floppy isn't accessed again.). 3.4.2 Using doinstall The syntax of the doinstall command is doinstall [ ...] The first is required: it is the partition which the root filesystem is mounted on (such as /dev/hda2). The other argu- ments are used to tell doinstall where to mount any additional filesystems if you're using them. See Section A.3 for details on this procedure. For example, if your Linux root filesystem is on /dev/hda2, use the command softland:/# doinstall /dev/hda2 The doinstall command will step you through the installation process. It will ask you what media to install from (e.g., floppy, hard drive, CD-ROM, or network). Choose the appropriate option (which is probably "floppy", unless you're installing from CD-ROM or the hard drive. See Sections A.1 and A.2.) doinstall will also ask you how much of the software to install, depending on which disk sets you're installing. Tiny base system a disk series only (15 megs) Main base system a, b, and c series (45 megs) Main base system + X11 a, b, c, and x series (70 megs) Full system a, b, c, x, d, s, and t series (90 megs) You can selectively install packages from the disk series during the installation process_you need not install all of the software on each disk series. Just answer "yes" to the question "Prompt for each package?" when you run doinstall. During the installation, if you receive numerous error mes- sages such as "No space left on device", then you didn't create filesystems large enough to hold the software. You should go back and either repartition your drive to allocate more space, or being the installation again (this time not installing as much of the soft- ware). In any case, if you choose to reinstall SLS for some reason, it is important that you redo the mke2fs command (i.e., re-create your filesystems). This will delete any existing software on your Linux partitions before you attempt to reinstall. If everything goes well, then congratulations! You've just in- stalled Linux on your system. Go have a Diet Coke or something_ you deserve it. 3.4.3 Rebooting the system To boot Linux, simply boot the Linux boot disk that was created during the installation procedure (not the a1 disk). Also, it's a good idea to keep your SLS installation disks around_if you acci- dentally trash your system, for example, you can use the SLS a1 disk to recover your files (with a little luck). 3.5 Now That You Have Linux Installed You've probably run into a few problems along the way while trying to install Linux. The most common problem is having corrupt files on your installation disks, caused by either a mistake while downloading or a mistake by the folks who put together the release you're trying to install. Hopefully, however, all has gone well and you now have a running Linux system. The next few chapters will help you get aquainted with the Linux system. Chapter 4 Linux Tutorial 4.1 Introduction New users of UNIX and Linux may be a bit intimidated by the size and apparent complexity of the system before them. There are many good books on using UNIX out there, for all levels of expertise from novice to expert. However, none of these books covers, specifically, an introduction to using Linux. While 95% of using Linux is exactly like using other UNIX systems, the most straightforward way to get going on your new system is with a tutorial tailored for Linux. Herein is such a tutorial. This chapter does not go into a large amount of detail or cover many advanced topics. Instead, it is intended to get the new Linux user running, on both feet, so that he or she may then read a more general book about UNIX and understand the basic differences between other UNIX systems and Linux. Very little is assumed here, except perhaps some familiarity with personal computer systems, and MS-DOS. However, even if you're not an MS-DOS user, you should be able to understand everything here. At first glance, UNIX looks a lot like MS-DOS (after all, MS-DOS was modeled on the CP/M operating system, which in turn was modeled on UNIX). However, only the very superficial features of UNIX resemble MS-DOS in any way. Even if you're completely new to the PC world, this tutorial should be of help. And, before we begin: Don't be afraid to experiment. The sys- tem won't bite you. You can't destroy anything by working on the system. UNIX has some amount of security built in, to prevent "normal" users (the role which you will now assume) from damag- ing files which are essential to the system. Even so, the absolute worst thing that can happen is that you'll delete all of your files_ and you'll have to go back and re-install the system. So, at this point, you have nothing to lose. 4.2 Basic UNIX Concepts UNIX is a multitasking, multiuser operating system. This means that there can be many people using one computer at the same time, running many different applications. (This differs from MS- DOS, where only one person can use the system at any one time.) Under UNIX, for users to identify themselves to the system, they must log in, which entails two steps: Entering your login name (the name which the system identifies you as), and entering your password, which is your personal secret key to logging into your account. Because only you know your password, no one else can login to the system under your username. On traditional UNIX systems, the system administrator will assign you a username and an initial password when you are given an account on the system. However, because you are the system administrator, you must set up your own account before you can login_see Section 4.2.1, below. For the following discussions, we'll use the imaginary username "larry". In addition, each UNIX system has a hostname assigned to it. It is this hostname that gives your machine a name, gives it character and charm. The hostname is used to identify individual machines on a network, but even if your machine isn't networked, it should have a hostname. In Section 5.9.2 we'll cover setting your system's hostname. For our examples, below, the system's hostname is "mousehouse". 4.2.1 Creating an account Before you can use the system, you must set up a user account for yourself. This is because it's usually not a good idea to use the root account for normal use. The root account should be reserved for running priveleged commands and for maintaining the system, as discussed in Section 5.1. In order to create an account for yourself, you need to login as root and use the useradd or adduser command. See Section 5.4 for information on this procedure. 4.2.2 Logging in At login time, you'll see the a prompt resembling the following on your screen: mousehouse login: Here, enter your username, and press the [Return] key. Our hero, larry, would type the following: mousehouse login: larry Password: Now, enter your password. It won't be echoed to the screen when you login, so type carefully. If you mistype your password, you'll see the message Login incorrect and you'll have to try again. Once you have correctly entered the username and password, you are officially logged into the system, and are free to roam. 4.2.3 Virtual consoles The system's console is the monitor and keyboard connected di- rectly to the system. (Because UNIX is a multiuser operating sys- tem, you may have other terminals connected to serial ports on your system, but these would not be the console.) Linux, like some other versions of UNIX, provides access to virtual consoles (or VC's), which allow you to have more than one login session from your console at a time. To demonstrate this, login to your system (as demonstrated above). Now, press [alt-F2]. You should see the login: prompt again. You're looking at the second virtual console_you logged into the first. To switch back to the first VC, press [alt-F1]. Voila! You're back to your first login session. A newly-installed Linux system probably allows you to access the first four VC's, using [alt-F1] through [alt-F4]. However, it is possible to enable up to 12 VC's_one for each function key on your keyboard. As you can see, use of VC's can be very powerful_you can be working on several different VC's at once. While the use of VC's is somewhat limiting (after all, you can only be looking at one VC at a time), it should give you a feel for UNIX's multiuser capabilities. While you're working on VC #1, you can switch over to VC #2 and start working on something else. 4.2.4 Shells and commands For most of your explorations in the world of UNIX, you'll be talk- ing to the system through the use of a shell. A shell is just a program which takes user input (e.g., commands which you type) and translates them into instructions. This can be compared to the COMMAND.COM program under MS-DOS, which does essentially the same thing. The shell is just one interface to UNIX. There are many possible interfaces_such as the X Window System, which lets you run commands by using the mouse and keyboard in con- junction. As soon as you login, the system starts the shell, and you can type commands to it. Here's a quick example. Here, Larry logs in, and is left sitting at the shell prompt. mousehouse login: larry Password: larry's password Welcome to Mousehouse! /home/larry# "/home/larry#" is the shell's prompt, indicating that it's ready to take commands. (More on what the prompt itself means later.) Let's try telling the system to do something interesting: /home/larry# make love make: *** No way to make target `love'. Stop. /home/larry# Well, as it turns out make was the name of an actual program on the system, and the shell executed this program when given the command. (Unfortunately, the system was being unfriendly.) This brings us to one burning question: What are commands? What happens when you type "make love"? The first word on the command line, "make", is the name of the command to be executed. Everything else on the command line is taken as arguments to this command. Examples: /home/larry# cp foo bar Here, the name of the command is "cp", and the arguments are "foo" and "bar". When you type a command, the shell does several things. First of all, it looks at the command name, and checks to see if it is a command which is internal to the shell. (That is, a command which the shell knows how to execute itself. There are a number of these commands, and we'll go into them later.) The shell also checks to see if the command is an alias, or substitute name, for another command. If neither of these conditions apply, the shell looks for a program, on the disk, with the command's name. If it finds such a program, the shell runs it, giving the program the arguments specified on the command line. In our example, the shell looks for the program called make, and runs it with the argument love. Make is a program often used to compile large programs, and it takes as arguments the name of a "target" to compile. In the case of "make love", we instructed make to compile the target love. Because make can't find a target by this name, it fails with a humorous error message, and we are returned to the shell prompt. What happens if we type a command to a shell, and the shell can't find a program with the command name to run? Well, we can try it: /home/larry# eat dirt eat: command not found /home/larry# Quite simply, if the shell can't find a program with the name given on the command line (here, "eat"), it prints an error message which should be self-explanatory. You'll often see this error message if you mistype a command (for example, if you had typed "mkae love" instead of "make love"). 4.2.5 Logging out Before we delve much further, we should tell you how to log out of the system. At the shell prompt, use the command /home/larry# exit to logout. There are other ways of logging out as well, but this is the most foolproof one. 4.2.6 Changing your password You should also be aware of how to change your password. The command passwd will prompt you for your old password, and your new password. It will ask you to reenter the new password for validation. Be careful not to forget your password_if you do, you will have to ask the system administrator to reset it for you. (If you're the system administrator, see Section 5.4.) 4.2.7 Files and directories Under most operating systems (UNIX included), there is the con- cept of a file, which is just a bundle of information which is given a name (called a filename). Examples of files would be your history term paper, an e-mail message, or an actual program which can be executed. Essentially, anything which is saved on disk is saved in an individual file. Files are identified by their filenames. For example, the file containing your history paper might be saved with the filename history.txt. These names usually identify the file and its contents in some form which is meaningful to you. With the concept of files comes the concept of directories. A directory is just a collection of files. It can be thought of as a "folder" which contains many different files. Directories themselves are given names, with which you can identify them. Furthermore, directories are maintained in a tree-like structure; that is, directo- ries may contain other directories. A file may be referred to by its pathname, which is made up of the filename, preceded by the name of the directory which contains the file. For example, let's say that Larry has a directory called papers, which contains three files: history-final, english-lit, and masters-thesis. (Each of these three files contains informa- tion for three of Larry's ongoing projects.) To refer to the file english-lit, Larry can specify the file's pathname: papers/english-lit As you can see, the directory and file names are separated by a single slash (/). MS-DOS users will find this convention familiar, although in the MS-DOS world, the backslash (") is used instead. As mentioned, directories can be nested within each other as well. For example, let's say that Larry has another directory, within papers, called notes. This directory contains the files math-notes and cheat-sheet. The pathname of the file cheat-sheet would be papers/notes/cheat-sheet Therefore, the pathname really is a "path" which you take to locate a certain file. The directory above a given subdirectory is known as the parent directory. Here, the directory papers is the parent of the notes directory. 4.2.8 The directory tree Most UNIX systems have a standard layout for files, so that system resources and programs can be easily located. This layout forms a directory tree, which starts at the "/" directory, also known as "the root directory". Directly underneath / are some important subdirectories: /bin, /etc, /dev, and /usr, among others. These directories in turn contain other directories which contain system configuration files, programs, and so on. In particular, each user has a home directory, which is the directory set aside for that user to store his or her files. In the examples above, all of Larry's files (such as cheat-sheet and history-final) were contained in Larry's home directory. Usual- ly, user home directories are contained under /home, and are named for the user who owns that directory. Therefore, Larry's home di- rectory is /home/larry. 4.2.9 The current working directory At any given time, commands that you type to the shell are given in terms of your current working directory. You can think of your working directory as the directory in which you are currently "located". When you first login, your working directory is set to your home directory_/home/larry in our case. Whenever you reference a file, you may refer to it in relationship to your current working directory, instead of specifying the full pathname of the file. Here's an example. Larry has the directory papers, and papers contains the file history-final. If Larry wants to look at this file, he can use the command /home/larry# more /home/larry/papers/history-final The more command simply displays a file, one screen at a time. However, because Larry's current working directory is /home/larry, he can instead refer to the file relative to his current location. The command would be /home/larry# more papers/history-final Therefore, if you begin a filename (such as papers/final) with a character other than "/", the system assumes that you're referring to the file in terms relative to your current working directory. This is known as a relative pathname. On the other hand, if you begin a filename with a "/", the system interprets this as a full pathname_that is, a pathname including the entire path to the file, starting from the root directory, /. This is known as an absolute pathname. 4.2.10 Referring to home directories Under both Tcsh and Bash on Linux, your home directory can be referred to using the tilde character ("~"). For example, the command /home/larry# more ~/papers/history-final is equivalent to /home/larry# more /home/larry/papers/history-final The "~" character is simply replaced with the name of your home directory by the shell. In addition, you can specify other user's home directories with the tilde as well. The pathname "~karl/letters" translates to "/home/karl/letters" by the shell (if /home/karl is karl's home directory). The use of the tilde is simply a shortcut; there is no di- rectory named "~", it's just syntactic sugar provided by the shell. 4.3 First Steps into UNIX 4.3.1 Moving around Now that we can login, and know how to refer to files using path- names, how can we change our current working directory, to make life easier? The command for moving around in the directory structure is cd, short for "change directory". You'll notice that many often- used Unix commands are two or three letters. The usage of the cd command is: cd where is the name of the directory which you wish to change to. As we said, when you login, you begin in your home directory. If Larry wanted to move down into the papers subdirectory, he'd use the command /home/larry# cd papers /home/larry/papers# As you can see, Larry's prompt changes to reflect his current work- ing directory (so he knows where he is). Now that he's in the papers directory, he can look at his history final with the com- mand /home/larry/papers# more history-final Now, Larry is stuck in the papers subdirectory. To move back up to the parent directory, use the command /home/larry/papers# cd .. /home/larry# (Note the space between the "cd" and the "..".) Every directory has a subdirectory named ".." which refers to the parent directory. Similarly, every directory has a subdirectory named "." which refers to itself. Therefore, the command /home/larry/papers# cd . gets us nowhere. You can also use absolute pathnames in the cd command. To cd into Karl's home directory, we can use the command /home/larry/papers# cd /home/karl /home/karl# Also, using cd with no argument will return you to your own home directory. /home/karl# cd /home/larry# 4.3.2 Looking at the contents of directories Now that you know how to move around directories you probably think, "So what?" The basic skill of moving around directories is fairly useless, so let's introduce a new command, ls. ls prints a listing of files and directories, by default from your current direc- tory. For example: /home/larry# ls Mail letters papers /home/larry# Here we can see that Larry has three entries in his current directory: Mail, letters, and papers. This doesn't tell us much_ are these directories or files? We can use the -F option on the ls command to tell us more. /home/larry# ls -F Mail/ letters/ papers/ /home/larry# From the / appended to each filename, we know that these three entries are in fact subdirectories. Using ls -F may also append "*" to the end of a filename. This indicates that the file is an executable, or a program which can be run. If nothing is appended to the filename using ls -F, the file is a "plain old file", that is, it's neither a directory, or an executable. In general, each UNIX command may take a number of options in addition to other arguments. These options usually begin with a "-", as demonstrated above with ls -F. The -F option tells ls to give more information about the type of the files involved_in this case, printing a / after each directory name. If you give ls a directory name, it will print the contents of that directory. /home/larry# ls -F papers english-lit history-final masters-thesis notes/ /home/larry# Or, for a more interesting listing, let's see what's in the system's /etc directory. /home/larry# ls /etc Images ftpusers lpc rc.new shells adm getty magic rc0.d startcons bcheckrc gettydefs motd rc1.d swapoff brc group mount rc2.d swapon brc~ inet mtab rc3.d syslog.conf csh.cshrc init mtools rc4.d syslog.pid csh.login init.d pac rc5.d syslogd.reload default initrunlvl passwd rmt termcap disktab inittab printcap rpc umount fdprm inittab.old profile rpcinfo update fstab issue psdatabase securetty utmp ftpaccess lilo rc services wtmp /home/larry# (For those MS-DOS users out there, notice how the filenames can be longer than 8 characters, and can contain periods in any position. It is even possible to have more than one period in a filename.) Let's cd up to the top of the directory tree, using "cd ..", and then down to another directory: /usr/bin. /home/larry# cd .. /home# cd .. /# cd usr /usr# cd bin /usr/bin# You can also move into directories in multiple steps, as in cd /usr/bin. Try moving around various directories, using ls and cd. In some cases, you may run into a foreboding "Permission denied" error message. This is simply the concept of UNIX security kick- ing in: in order to ls or to cd into a directory, you must have permission to do so. We'll talk more about this in Section 4.9. 4.3.3 Creating new directories It's time to learn how to create directories. This involves the use of the mkdir command. Try the following: /home/larry# mkdir foo /home/larry# ls -F Mail/ foo/ letters/ papers/ /home/larry# cd foo /home/larry/foo# ls /home/larry/foo# Congrats! You've just made a new directory and moved into it. Since there aren't any files in this new directory, let's learn how to copy files from one place to another. 4.3.4 Copying files Copying files is done with the command cp: /home/larry/foo# cp /etc/termcap . /home/larry/foo# cp /etc/shells . /home/larry/foo# ls -F shells termcap /home/larry/foo# cp shells bells /home/larry/foo# ls -F bells shells termcap /home/larry/foo# The cp command copies the files listed on the command line to the file or directory given as the last argument. Notice how we use the directory "." to refer to the current directory. 4.3.5 Moving files A new command named mv moves files, instead of copying them. The syntax is very straightforward. /home/larry/foo# mv termcap sells /home/larry/foo# ls -F bells sells shells /home/larry/foo# Notice how termcap no longer exists, but in its place is the file sells. This can be used to rename files, as we have just done, but also to move a file to a completely new directory. Note: mv and cp will overwrite the destination file (if it already exists) without asking you. Be careful when you move a file into another directory: there may already be a file with the same name in that directory, which you'll overwrite! 4.3.6 Deleting files and directories You now have an ugly rhyme developing with the use of the ls command. To delete a file, use the rm command. ("rm" stands for "remove"). /home/larry/foo# rm bells sells /home/larry/foo# ls -F shells /home/larry/foo# We're left with nothing but shells, but we won't complain. Note that rm by default won't prompt you before deleting a file_so be careful. A related command to rm is rmdir. This command deletes a directory, but only if the directory is empty. If the directory contains any files or subdirectories, rmdir will complain. 4.3.7 Looking at files The commands more and cat are used for viewing the contents of files. more displays a file, one screenful at a time, while cat displays the whole file at once. To look at the file shells, we can use the command /home/larry/foo# more shells In case you're interested what shells contains, it's a list of valid shell programs on your system. On most systems, this in- cludes /bin/sh, /bin/bash, and /bin/csh. We'll talk about these different types of shells later. While using more, press [Space] to display the next page of text, and [b] to display the previous page. There are other com- mands available in more as well, these are just the basics. Pressing [q] will quit more. Quit more and try cat /etc/termcap. The text will probably fly by much too quickly for you to read it. The name "cat" actually stands for "concatenate", which is the real use of the program. The cat command can be used to concatenate the contents of several files and save the result to another file. This will be discussed later. 4.3.8 Getting online help Almost every UNIX system, Linux included, provides a facility known as "manual pages", or "man pages" for short. These man pages contain online documentation for all of the various system commands, resources, configuration files, and so on. The command used to access man pages is man. For example, if you're interested in finding out about the other options of the ls command, you can type /home/larry# man ls and the man page for ls will be displayed. Unfortunately, most of the man pages out there are written for those who already have some idea of what the command or resource does. For this reason, man pages usually only contain the hardcore technical details of the command, without a lot of tutorial. However, man pages can be an invaluable resource for jogging your memory if you forget the syntax of a command. Man pages will also tell you a lot about the commands which we won't tell you in this book. I suggest that you try man for the commands we've already gone over, and whenever I introduce a new command. You'll notice some of these commands won't have man pages. This could be for several reasons. For one, the man pages haven't been written yet (the Linux Documentation Project is responsible for man pages under Linux as well. We are gradually accumulating most of the man pages available for the system). Secondly, the the command might be an internal shell command, or an alias (as discussed in Section 4.2.4), in which case it would not have a man page of its own. One example is cd, which is a shell internal command. The shell actually processes the cd_there is no separate program which contains this command. 4.4 Summary of Basic Commands This section introduces some of the most useful basic commands on a UNIX system, including those covered in the last section. Note that options usually begin with a "-", and in most cases multiple one-letter options may be combined using a single "-". For example, instead of using the command ls -l -F, it is adequate to use ls -lF. Instead of listing all of the options available for each of these commands, we'll only talk about those which are useful or impor- tant at this time. In fact, most of these commands have a large number of options (most of which you'll never use). You can use man to see the manual pages for each command, which list all of the available options. Also note that many of these commands take a list of files or directories as arguments, denoted by " ...". For example, the cp command takes as arguments a list of files to copy, followed by the destination file or directory. When copying more than one file, the destination must be a directory. cd Change the current working directory. Syntax: cd is the directory to change to. ("." refers to the current directory, ".." the parent directory.) Example: cd ../foo sets the current directory to ../foo. ls Displays information about the named files and directories. Syntax: ls ... Where through are the filenames or directories to list. Options: There are more options than you want to think about. The most commonly used are -F (used to display some infor- mation about the type of the file), and -l (gives a "long" listing including file size, owner, permis- sions, and so on. This will be covered in detail later.) Example: ls -lF /home/larry will display the contents of the directory /home/larry. cp Copies file(s) to another file or directory. Syntax: cp ... Where through are the files to copy, and is the destination file or direc- tory. Example: cp ../frog joe copies the file ../frog to the file or directory joe. mv Moves file(s) to another file or directory. This command does the equivalent of a copy followed by the deletion of the original. This can be used to rename files, as in the MS-DOS command RENAME. Syntax: mv ... Where through are the files to move, and is the destination file or direc- tory. Example: mv ../frog joe moves the file ../frog to the file or directory joe. rm Deletes files. Note that when files are deleted under UNIX, they are unrecoverable (unlike MS- DOS, where you can usually "undelete" the file). Syntax: rm ... Where through are the filenames to delete. Options: -i will prompt for confirmation before deleting the file. Example: rm -i /home/larry/joe /home/larry/frog deletes the files joe and frog in /home/larry. mkdir Creates new directories. Syntax: mkdir ... Where through are the directories to create. Example: mkdir /home/larry/test creates the directory test under /home/larry. rmdir This command deletes empty directories. When using rmdir, your current working directory must not be within the directory to be deleted. Syntax: rmdir ... Where through are the directories to delete. Example: rmdir /home/larry/papers deletes the directory /home/larry/papers, if it is empty. man Displays the manual page for the given command or resource (that is, any system utility which isn't a command, such as a library function.) Syntax: man Where is the name of the command or resource to get help on. Example: man ls gives help on the ls command. more Displays the contents of the named files, one screen- ful at a time. Syntax: more ... Where through are the files to dis- play. Example: more papers/history-final displays the file papers/history-final. cat Officially used to concatenate files, cat is also used to display the entire contents of a file at once. Syntax: cat ... Where through are the files to dis- play. Example: cat letters/from-mdw displays the file letters/from-mdw. echo Simply echoes the given arguments. Syntax: echo ... Where through are the arguments to echo. Example: echo "Hello world" displays the string "Hello world". grep Display all of the lines in the named file(s) match- ing the given pattern. Syntax: grep ... Where is a regular expression pattern, and through are the files to search. Example: grep loomer /etc/hosts will display all lines in the file /etc/hosts which contain the pattern "loomer". 4.5 Exploring the File System The file system is the collection of files and the hierarchy of di- rectories on your system. I promised before to escort you around the filesystem and the time has come. First, change to the root directory (cd /), and do an ls -F. You'll probably see these directories (*Note: You may see others, and you might not see all of them. Don't worry. Every release of Linux differs in some respects.): bin, dev, etc, home, install, lib, mnt, proc, root, tmp, user, usr, and var. Let's take a look at each of these directories. bin /bin is short for "binaries", or executables. This is where many essential system programs reside. Use the command "ls -F /bin" to list the files here. If you look down the list you may see a few commands that you recognize, such as cp, ls, and mv. These are the actual programs for these com- mands. When you use the cp command, you're running the program /bin/cp. Using ls -F, you'll see that most (if not all) of the files in /bin have an asterisk ("*") appended to their filenames. This indicates that the files are executables, as described in Section 4.3.2. /dev Next on our stop is /dev. Take a look, again with ls -F. The "files" in /dev are known as device drivers_ they are used to access system devices and re- sources, such as disk drives, modems, memory, and so on. For example, just as you can read data from a file, you can read input from the mouse by accessing /dev/mouse. The filenames beginning with fd are floppy disk devices. fd0 is the first floppy disk drive, fd1 the second. Now, the astute among you will notice that there are more floppy disk devices then just the two I've listed above: they represent specific types of floppy disks. For example, fd1H1440 will access high-density, 3.5" diskettes in drive 1. Here is a list of some of the most commonly used device files. Note that even though you may not have some of the devices listed below, the chances are that you'll have entries in /dev for them any- way. o /dev/console refers to the system's console_ that is, the monitor connected directly to y- our system. o The various /dev/ttyS and /dev/cua devices are used for accessing serial ports. For exam- ple, /dev/ttyS0 refers to "COM1" under MS- DOS. The /dev/cua devices are "callout" de- vices, which are used in conjunction with a modem. o The device names beginning with hd access hard drives. /dev/hda refers to the whole first hard disk, while hda1 refers to the first partition on /dev/hda. o The device names beginning with sd are SC- SI devices, such as SCSI hard drives, tape drives, and so on. If you have a SCSI hard drive, instead of accessing it through /dev/hda, you would access /dev/sda. o The device names beginning with lp access parallel ports. /dev/lp0 refers to "LPT1" in the MS-DOS world. o /dev/null is used as a "black hole"_any da- ta sent to this device is gone forever. Why is this useful? Well, if you wanted to sup- press the output of a command appearing on your screen, you could send that output to /dev/null. We'll talk more about this later. o The device names beginning with /dev/tty refer to the "virtual consoles" on your system (accessed via by pressing [alt-F1], [alt-F2], and so on). /dev/tty1 refers to the first VC, /dev/tty2 refers to the second, and so on. o The device names beginning with /dev/pty are "pseudo-terminals". They are used to provide a "terminal" to remote login sessions. For example, if your machine is on a network, incoming telnet logins would use one of the /dev/pty devices. /etc /etc contains just about everything which can be labeled "et cetera"_many system configuration files, programs, and utilities. Most of the pro- grams found in /etc are for use by the system administrator only. We'll cover these in depth in Chapter 5. /home /home contains user's home directories. For ex- ample, /home/larry is the home directory for the user "larry". On a newly-installed system, there may not be any users in this directory. /lib /lib contains shared library images. These files contain code which many programs share in common. Instead of each program containing its own copy of these shared routines, they are all stored in one common place, in /lib. This makes executable files smaller, and saves space on your system. /proc /proc is a "virtual filesystem", the files in which are stored in memory, not on the drive. They refer to the various processes running on the system, and allow you to get information about what pro- grams and processes are running at any given time. We'll go into more detail in Section 4.10.1. /tmp Many programs have a need to generate some in- formation and store it in a temporary file. The canonical location for these files is in /tmp. /usr /usr is a very important directory. It contains a number of subdirectories which in turn contain some of the most important and useful programs and configuration files used on the system. The various directories described above are essen- tial for the system to operate, but most of the things found in /usr are optional for the system. However, it is those optional things which make the system useful and interesting. Without /usr, you'd more or less have a boring system, only with programs like cp and ls. /usr contains most of the larger software packages and the configuration files which accompany them. /usr/X386 /usr/X386 contains The X Window System, if y- ou installed it. The X Window System is a large, powerful graphical environment which provides a large number of graphical utilities and program- s, displayed in "windows" on your screen. If y- ou're at all familiar with the Microsoft Windows or Macintosh environments, X Windows will look very familiar. The /usr/X386 directory contains all of the X Windows executables, configuration files, and support files. This will be covered in more detail in Section 6.1. /usr/adm /usr/adm contains various files of interest to the system administrator, specifically system logs, which record any errors or problems with the system. Other files record logins to the system, as well as failed login attempts. This will be covered in Chapter 5. /usr/bin /usr/bin is the real warehouse for software on any UNIX system. It contains most of the executables for programs not found in other places, such as /bin. /usr/etc Just as /etc contained miscellaneous system pro- grams and configuration files, /usr/etc contains even more of these utilities and files. In general, the files found in /usr/etc are not essential to the system, unlike those found in /etc, which are. /usr/include /usr/include contains include files for the C compiler. These files (most of which end in .h, for "header") declare data structure names, subrou- tines, and constants used when writing programs in C. Those files found in /usr/include/sys are generally used when programming on the UNIX system level. If you are familiar with the C pro- gramming language, here you'll find header files such as stdio.h, which declares functions such as printf(). /usr/g++-include /usr/g++-include contains include files for the C++ compiler (much like /usr/include). /usr/lib /usr/lib contains the "stub" and "static" library equivalents to the files found in /lib. When com- piling a program, the program is "linked" with the libraries found in /usr/lib, which then directs the program to look in /lib when it needs the actu- al code in the library. In addition, various other programs store configuration files in /usr/lib. /usr/local /usr/local is a lot like /usr_it contains vari- ous programs and files not essential to the system, but which make the system fun and exciting. In general, those programs found in /usr/local are specialized for your system specifically_that is, /usr/local differs greatly between UNIX system- s. Here, you'll find large software packages such as TEX (a document formatting system) and Emacs (a large and powerful editor), if you installed them. /usr/man This directory contains the actual man pages. There are two subdirectories for every man page "sec- tion" (use the command man man for details). For example, /usr/man/man1 contains the source (that is, the unformatted original) for man pages in sec- tion 1, and /usr/man/cat1 contains the formatted man pages for section 1. /usr/spool /usr/spool contains files which are to be "spooled" to another program. For example, if your machine is connected to a network, incoming mail will be stored in /usr/spool/mail, until you read it or delete it. Outgoing or incoming news articles may be found in /usr/spool/news, and so on. /usr/src /usr/src contains the source code (the uncom- piled program) for various programs on your sys- tem. The most important thing here is /usr/src/linux, which contains the source code for the Linux ker- nel. /usr/tmp Another directory used for temporary files, like /tmp. 4.6 Types of shells As I have mentioned too many times before, UNIX is a multitask- ing, multiuser operating system. Multitasking is very useful, and once you get used to it, you'll use it all of the time. Before long, you'll be able to run programs in the "background", switch be- tween multiple tasks, and "pipeline" programs together to achieve complicated results with a single command. Many of the features we'll be covering in this section are fea- tures provided by the shell itself. Be careful not to confuse UNIX (the actual operating system) with the shell_the shell is just an interface to the underlying system. The shell provides a great deal of functionality on top of UNIX itself. The shell is not only an interpreter for your interactive com- mands, which you type at the prompt. It is also a powerful pro- gramming language, which allows you to write shell scripts, to "batch" several shell commands together in a file. MS-DOS users will recognize the similarity to "batch files". Use of shell scripts is a very powerful tool, which will allow you to automate and expand you usage of UNIX. See Section 4.11.1 for more information. There are several types of shells in the UNIX world. The two major types are the "Bourne shell" and the "C shell". The Bourne shell uses a command syntax like the original shell on early UNIX systems, such as System III. The name of the Bourne shell on most UNIX systems is /bin/sh (where sh stands for "shell"). The C shell (not to be confused with sea shell) uses a different syntax, somewhat like the programming language C, and on most UNIX systems is named /bin/csh. Under Linux, there are several variations of these shells avail- able. The two most commonly used are the Bourne Again Shell, or "Bash" (/bin/bash), and Tcsh (/bin/tcsh). Bash is a form of the Bourne shell with many of the advanced features found in the C shell. Because Bash supports a superset of the Bourne shell syn- tax, any shell scripts written in the standard Bourne shell should work with Bash. For those who prefer to use the C shell syntax, Linux supports Tcsh, which is an expanded version of the original C shell. The type of shell that you decide to use is mostly a religious issue. Some folks prefer the Bourne shell syntax with the advanced features of Bash, and some prefer the more structured C shell syn- tax. As far as normal commands, such as cp and ls, are concerned, the type of shell you're using doesn't matter_the syntax is the same. Only when you start to write shell scripts or use some of the advanced features of the shell do the differences between shell types begin to matter. As we're discussing some of the features of the shell, below, we'll note those differences between Bourne and C shells. However, for the purposes of this manual, most of those differences are minimal. (If you're really curious at this point, read the man pages for bash and tcsh). 4.7 Wildcards A key feature of most Unix shells is the ability to reference more than one filename using special characters. These so-called wild- cards allow you to refer to, say, all filenames which contain the character "n". The wildcard "*" refers to any character or string of characters in a filename. For example, when you use the character "*" in a filename, the shell replaces it with all possible substitutions from filenames in the directory which you're referencing. Here's a quick example. Let's suppose that Larry has the files frog, joe, and stuff in his current directory. /home/larry# ls frog joe stuff /home/larry# To access all files with the letter "o" in the filename, we can use the command /home/larry# ls *o* frog joe /home/larry# As you can see, the use of the "*" wildcard was replaced with all substitutions which matched the wildcard from filenames in the current directory. The use of "*" by itself simply matches all filenames, because all characters match the wildcard. /home/larry# ls * frog joe stuff /home/larry# Here are a few more examples. /home/larry# ls f* frog /home/larry# ls *ff stuff /home/larry# ls *f* frog stuff /home/larry# ls s*f stuff /home/larry# The process of changing a "*" into filenames is called wild- card expansion and is done by the shell. This is important: the individual commands, such as ls, never see the "*" in their list of parameters. The shell expands the wildcard to include all of the filenames which match. So, the command /home/larry# ls *o* is expanded by the shell to actually be /home/larry# ls frog joe One important note about the "*" wildcard. Using this wild- card will not match filenames which begin with a single period ("."). These files are treated as "hidden" files_while they are not really hidden, they don't show up on normal ls listings, and aren't touched by the use of the "*" wildcard. Here's an example. We already mentioned that each directory has two special entries in it: "." refers to the current directory, and ".." refers to the parent directory. However, when you use ls, these two entries don't show up. /home/larry# ls frog joe stuff /home/larry# If you use the -a switch with ls, however, you can display filenames which begin with ".". Observe: /home/larry# ls -a . .. .bash_profile .bashrc frog joe stuff /home/larry# Now we can see the two special entries, "." and "..", as well as two other "hidden" files_.bash_profile and .bashrc. These two files are startup files used by bash when larry logs in. More on them in Section 4.11.3. Note that when we use the "*" wildcard, none of the filenames beginning with "." are displayed. /home/larry# ls * frog joe stuff /home/larry# This is a safety feature: if the "*" wildcard matched filenames beginning with ".", it would also match the directory names "." and "..". This can be dangerous when using certain commands. Another wildcard is "?". The "?" wildcard will only expand a single character. Thus, "ls ?" will display all one character filenames, and "ls termca?" would display "termcap" but not "termcap.backup". Here's another example: /home/larry# ls j?e joe /home/larry# ls f ??g frog /home/larry# ls ????f stuff /home/larry# As you can see, wildcards allow you to specify many files at one time. In the simple command summary, in Section 4.4, we said that the cp and mv commands actually can copy or move multiple files at one time. For example, /home/larry# cp /etc/s* /home/larry will copy all filenames in /etc beginning with "s" to the directory /home/larry. Therefore, the format of the cp command is really cp ... where through is a list of filenames to copy, and is the destination file or directory to copy them to. mv has an identical syntax. Note that if you are copying or moving more than one file, the must be a directory. You can only copy or move a single file to another file. 4.8 UNIX Plumbing 4.8.1 Standard input and output Many UNIX commands get input from what is known as stan- dard input and send their output to standard output (often abbreviated as "stdin" and "stdout"). Your shell sets things up so that standard input is your keyboard, and standard output is the screen. Here's an example using the command cat. Normally, cat reads data from all of the filenames given on the command line and sends this data directly to stdout. Therefore, using the command /home/larry/papers# cat history-final masters-thesis will display the contents of the file history-final followed by masters-thesis. However, if no filenames are given to cat as parameters, it instead reads data from stdin, and sends it back to stdout. Here's an example. /home/larry/papers# cat Hello there. Hello there. Bye. Bye. [ctrl-D] /home/larry/papers# As you can see, each line that the user types (displayed in italics) is immediately echoed back by the cat command. When reading from standard input, commands know that the input is "finished" when they receive an EOT (end-of-text) signal. In general, this is generated by pressing [ctrl-D]. Here's another example. The command sort reads in lines of text (again, from stdin, unless files are given on the command line), and sends the sorted output to stdout. Try the following. /home/larry/papers# sort bananas carrots apples [ctrl-D] apples bananas carrots /home/larry/papers# Now we can alphabetize our shopping list... isn't UNIX useful? 4.8.2 Redirecting input and output Now, let's say that we wanted to send the output of sort to a file, to save our shopping list elsewhere. The shell allows us to redirect standard output to a filename, using the ">" symbol. Here's how it works. /home/larry/papers# sort > shopping-list bananas carrots apples [ctrl-D] /home/larry/papers# As you can see, the result of the sort command isn't displayed, instead it's saved to the file shopping-list. Let's look at this file. /home/larry/papers# cat shopping-list apples bananas carrots /home/larry/papers# Now we can sort our shopping list, and save it, too! But let's suppose that we were storing our unsorted, original shopping list in the file items. One way of sorting the information and saving it to a file would be to give sort the name of the file to read, in lieu of standard input, and redirect standard output as we did above. As so: /home/larry/papers# sort items > shopping-list /home/larry/papers# cat shopping-list apples bananas carrots /home/larry/papers# However, there's another way of doing this. Not only can we redi- rect standard output, but we can redirect standard input as well, using the "<" symbol. /home/larry/papers# sort < items apples bananas carrots /home/larry/papers# Technically, sort < items is equivalent to sort items, but the former allows us to demonstrate the point: sort < items behaves as if the data in the file items was typed to standard input. The shell handles the redirection. sort wasn't given the name of the file (items) to read; as far as sort is concerned, it was still read- ing from standard input as if you had typed the data from your keyboard. This introduces the concept of a filter. A filter is a program which reads data from standard input, processes it in some way, and sends the processed data to standard output. Using redirection, standard input and/or standard output can be referenced from files. sort is a simple filter: it sorts the incoming data and sends the result to standard output. cat is even simpler: it doesn't do anything with the incoming data, it simply outputs whatever was given to it. 4.8.3 Using pipes We've already demonstrated how to use sort as a filter. However, these examples assumed that you had data in a file somewhere, or were willing to type the data to standard input yourself. What if the data you wanted to sort came from the output of another command, such as ls? For example, using the -r option with sort sorts the data in reverse-alphabetical order. If you wanted to list the files in your current directory in reverse order, one way to do it would be: /home/larry/papers# ls english-list history-final masters-thesis notes /home/larry/papers# ls > file-list /home/larry/papers# sort -r file-list notes masters-thesis history-final english-list /home/larry/papers# Here, we saved the output of ls in a file, and then ran sort -r on that file. But this is unwieldy and causes us to use a temporary file to save the data from ls. The solution is to use pipelining. Pipelining is another feature of the shell which allows you to connect a string of commands in a "pipe", where the stdout of the first command is sent directly to the stdin of the second command, and so on. Here, we wish to send the stdout of ls to the stdin of sort. The "|" symbol is used to create a pipe: /home/larry/papers# ls | sort -r notes masters-thesis history-final english-list /home/larry/papers# This command is much shorter, and obviously easier to type. Another useful example---using the command /home/larry/papers# ls /usr/bin is going to display a long list a files, most of which will fly past the screen too quickly for you to read them. Instead, let's use more to display the list of files in /usr/bin. /home/larry/papers# ls /usr/bin | more Now you can page down the list of files at your own leisure. But the fun doesn't stop here! We can pipe more than two commands together. The command head is a filter which displays the first lines from an input stream (here, input from a pipe). If we wanted to display the last filename in alphabetical order in the current directory, we can use: /home/larry/papers# ls | sort -r | head -1 notes /home/larry/papers# where head -1 simply displays the first line of input that it receives (in this case, the stream of reverse-sorted data from ls). 4.8.4 Non-destructive redirection Using ">" to redirect output to a file is destructive: in other words, the command /home/larry/papers# ls > file-list overwrites the contents of the file file-list. If, instead, you redi- rect with the symbol ">>", the output will be appended to the named file, instead of overwriting it. /home/larry/papers# ls >> file-list will append the output of the ls command to file-list. Just keep in mind that redirection and using pipes are features provided by the shell_the shell provides this handy syntax using ">" and ">>" and "_". It has nothing to do with the commands used themselves, but the shell. 4.9 File Permissions 4.9.1 Concepts of file permissions Because there are multiple users on a UNIX system, in order to protect individual user's files from tampering by other users, UNIX provides a mechanism known as file permissions. This mechanis- m allows files and directories to be "owned" by a particular user. As an example, because Larry created the files in his home direc- tory, Larry owns those files, and has access to them. UNIX also allows files to be shared between users and groups of users. If Larry so desired, he could cut off access to his files, such that no other user could access them. However, on most systems the default is to allow other users to read your files, but not modify or delete them in any way. As explained above, every file is owned by a particular user. However, files are also owned by a particular group, which is a system-defined group of users. Every user is placed into at least one group when that user is created. However, the system admin- istrator may also grant the user access to more than one group. Groups are usually defined by the type of users which access the machine. For example, on a university UNIX system, users may be placed into the groups student, staff, faculty or guest. There are also a few system-defined groups (such as bin and admin) which are used by the system itself to control access to resources_very rarely do actual users belong to these system groups. Permissions fall into three main divisions: read, write, and ex- ecute. These permissions may be granted to three classes of users: the owner of the file, the group to which the file belongs, and to all users, regardless of group. Read permission allows a user to read the contents of the file, or in the case of directories, to list the contents of the directory (using ls). Write permission allows the user to write to and modify the file. For directories, write permission allows the user to create new files or delete files within that directory. Finally, execute permission allows the user to run the file as a program or shell script (if the file happens to be a program or shell script, that is). For directories, having execute permission allows the user to cd into the directory in question. 4.9.2 Interpreting file permissions Let's look at an example to demonstrate file permissions. Using the ls command with the -l option will display a "long" listing of the file, including file permissions. /home/larry/foo# /home/larry/foo# ls -l stuff -rw-r--r-- 1 larry users 505 Mar 13 19:05 stuff /home/larry/foo# The first field printed in the listing represents the file permis- sions. The third field is the owner of the file (larry), and the fourth field is the group to which the file belongs (users). Obviously, the last field is the name of the file (stuff), and we'll cover the other fields later. This file is owned by larry, and belongs to the group users. Let's look at the file permissions. The string -rw-r--r-- lists, in order, the permissions granted to the file's owner, the file's group, and everybody else. The first character of the permissions string ("-") represents the type of file. A "-" just means that this is a regular file (as opposed to a directory or device driver). The next three letters ("rw-") represent the permissions granted to the file's owner, larry. The "r" stands for "read" and the "w" stands for "write". Thus, larry has read and write permission to the file stuff. As we mentioned, besides read and write permission, there is also "execute" permission_represented by an "x". However, there is a "-" here in place of the "x", so Larry doesn't have execute permission on this file. This is fine, the file stuff isn't a program of any kind. Of course, because Larry owns the file, he may grant himself execute permission for the file if he so desires. This will be covered shortly. The next three characters, r--, represent the group's permis- sions on the file. The group which owns this file is users. Because only an "r" appears here, any user which belongs to the group users may read this file. The last three characters, also r--, represent the permissions granted to every other user on the system (other than the owner of the file and those in the group users). Again, because only an "r" is present, other users may read the file, but not write to it or execute it. Here are some other examples of group permissions. -rwxr-xr-x The owner of the file may read, write, and execute the file. Users in the file's group, and all other users, may read and execute the file. -rw------- The owner of the file may read and write the file. No other user can access the file. -rwxrwxrwx All users may read, write, and execute the file. 4.9.3 Dependencies It is important to note that the permissions granted to a file also depend on the permissions of the directory in which the file is located. For example, even if a file is set to -rwxrwxrwx, other users cannot access the file unless they have read and execute access to the directory in which the file is located. For example, if Larry wanted to restrict access to all of his files, he could simply set the permissions on his home directory /home/larry to -rwx------. In this way, no other user has access to his directory, and all files and directories within it. Larry doesn't need to worry about the individual permissions on each of his files. In other words, to access a file at all, you must have read and execute access to all directories along the file's pathname. Usually, users on a UNIX system are very open with their files. The usual set of permissions given to files is -rw-r--r--, which will allow other users to read the file, but not change it in any way. The usual set of permissions given to directories is -rwxr-xr-x, which will allow other users to look through your directories, but not create or delete files within them. However, many users wish to keep other users out of their files. Setting the permissions of a file to -rw------- will not allow any other user to access the file. Likewise, setting the permissions of a directory to -rwx------ will keep other users out of the directory in question. 4.9.4 Changing permissions The command chmod is used to set the permissions on a file. Only the owner of a file may change the permissions on that file. The syntax of chmod is: chmod {a,u,g,o}{+,-}{r,w,x} Briefly, you supply one or more of all, user, group, or other. Then you specify whether you are adding rights (+) or taking them away (-). Finally, you specify one or more of read, write, and execute. Some examples of legal commands are: chmod a+r stuff Gives all users read access to the file. chmod +r stuff Same as above_if none of a, u, g, or o is specified, a is assumed. chmod og-x stuff Remove execute permission from users other than the owner. chmod u+rwx stuff Allow the owner of the file to read, write, and execute the file. chmod o-rwx stuff Remove read, write, and execute permission from users other than the owner and users in the file's group. 4.10 Job Control 4.10.1 Jobs and processes Job control is a feature provided by many shells (Bash and Tcsh included) which allows you to control multiple running commands, or jobs, at once. Before we can delve much further, we need to talk about processes. Every time you run a program, you start what is known as a process_which is just a fancy name for a running program. The command ps displays a list of currently running processes. Here's an example: /home/larry# ps PID TT STAT TIME COMMAND 24 3 S 0:03 (bash) 161 3 R 0:00 ps /home/larry# The PID listed in the first column is the process ID, a unique num- ber given to every running process. The last column, COMMAND, is the name of the running command. Here, we're only looking at the processes which Larry is currently running (*Note: There are many other processes running on the system as well_"ps -aux" lists them all.). These are bash (Larry's shell), and the ps com- mand itself. As you can see, bash is running concurrently with the ps command. bash executed ps when Larry typed the com- mand. After ps is finished running (after the table of processes is displayed), control is returned to the bash process, which displays the prompt, ready for another command. A running process is known as a job to the shell. The terms process and job are interchangeable. However, a process is usually referred to as a "job" when used in conjunction with job control_ a feature of the shell which allows you to switch between several independent jobs. In most cases users are only running a single job at a time_that being whatever command they last typed to the shell. However, using job control, you can run several jobs at once, switching be- tween them as needed. How might this be useful? Let's say that you're editing a text file and need to suddenly interrupt your edit- ing and do something else. With job control, you can temporarily suspend the editor, and back at the shell prompt start to work on something else. When you're done, you can start the editor back up, and be back where you started, as if you never left the editor. This is just one example. There are many practical uses for job control. 4.10.2 Foreground and background Jobs can either be in the foreground or in the background. There can only be one job in the foreground at any one time. The foreground job is the job which you interact with_it receives in- put from the keyboard and sends output to your screen. (Unless, of course, you have redirected input or output, as described in Section 4.8). On the other hand, jobs in the background do not receive input from the terminal_in general, they run along quietly without need for interaction. Some jobs take a long time to finish, and don't do anything interesting while they are running. Compiling programs is one such job, as is compressing a large file. There's no reason why you should sit around being bored while these jobs complete their tasks; you can just run them in the background. While the jobs are running in the background, you are free to run other programs. Jobs may also be suspended. A suspended job is a job that is not currently running, but is temporarily stopped. After you suspend a job, you can tell the job to continue, in the foreground or the background as needed. Resuming a suspended job will not change the state of the job in any way_the job will continue to run where it left off. Note that suspending a job is not equal to interrupting a job. When you interrupt a running process (by hitting your interrupt key, which is usually [ctrl-C]) (*Note: The interrupt key can be set using the stty command. The default on most systems is [ctrl-C], but we can't guarantee the same for your system.), it kills the process, for good. Once the job is killed, there's no hope of resuming it; you'll have to re-run the command. Also note that some programs trap the interrupt, so that hitting [ctrl-C] won't immediately kill the job. This is to allow the program to perform any necessary cleanup operations before exiting. In fact, some programs simply don't allow you to kill them with an interrupt at all. 4.10.3 Backgrounding and killing jobs Let's begin with a simple example. The command yes is a seem- ingly useless command which sends an endless stream of y's to standard output. (This is actually useful. If you piped the output of yes to another command which asked a series of yes and no questions, the stream of y's would confirm all of the questions.) Try it out. /home/larry# yes y y y y y The y's will continue ad infinitum. You can kill the process by hitting your interrupt key, which is usually [ctrl-C]. So that we don't have to put up with the annoying stream of y's, let's redirect the standard output of yes to /dev/null. As you may remember, /dev/null acts as a "black hole" for data. Any data sent to it will disappear. This is a very effective method of quieting an otherwise verbose program. /home/larry# yes > /dev/null Ah, much better. Nothing is printed, but the shell prompt doesn't come back. This is because yes is still running, and is sending those inane y's to /dev/null. Again, to kill the job, hit the interrupt key. Let's suppose that we wanted the yes command to continue to run, but wanted to get our shell prompt back to work on other things. We can put yes into the background, which will allow it to run, but without need for interaction. One way to put a process in the background is to append an "&" character to the end of the command. /home/larry# yes > /dev/null & [1] 164 /home/larry# As you can see, we have our shell prompt back. But what is this "[1] 164"? And is the yes command really running? The "[1]" represents the job number for the yes process. The shell assigns a job number to every running job. Because yes is the one and only job that we're currently running, it is assigned job number 1. The "164" is the process ID, or PID, number given by the system to the job. Either number may be used to refer to the job, as we'll see later. You now have the yes process running in the background, con- tinuously sending a stream of y's to /dev/null. To check on the status of this process, use the shell internal command jobs. /home/larry# jobs [1]+ Running yes >/dev/null & /home/larry# Sure enough, there it is. You could also use the ps command as demonstrated above to check on the status of the job. To terminate the job, use the command kill. This command takes either a job number or a process ID number as an argument. This was job number 1, so using the command /home/larry# kill %1 will kill the job. When identifying the job with the job number, you must prefix the number with a percent ("%") character. Now that we've killed the job, we can use jobs again to check on it: /home/larry# jobs [1]+ Terminated yes >/dev/null /home/larry# The job is in fact dead, and if we use the jobs command again nothing should be printed. You can also kill the job using the process ID (PID) number, which is printed along with the job ID when you start the job. In our example, the process ID is 164, so the command /home/larry# kill 164 is equivalent to /home/larry# kill %1 You don't need to use the "%" when referring to a job by its process ID. 4.10.4 Stopping and restarting jobs There is another way to put a job into the background. You can start the job normally (in the foreground), stop the job, and then restart it in the background. We'll demonstrate this below. First, start the yes process in the foreground, as you normally would: /home/larry# yes > /dev/null Again, because yes is running in the foreground, you shouldn't get your shell prompt back. Now, instead of interrupting the job with [ctrl-C], we'll suspend the job. Suspending a job doesn't kill it: it only temporarily stops the job until you restart it. To do this, you hit the suspend key, which is usually [ctrl-Z]. /home/larry# yes > /dev/null [ctrl-Z] [1]+ Stopped yes >/dev/null /home/larry# While the job is suspended, it's simply not running. No CPU time or memory is used for the job. However, you can restart the job, which will cause the job to run again as if nothing ever happened. It will continue to run where it left off. To restart the job in the foreground, use the command fg (for "foreground"). /home/larry# fg yes >/dev/null The shell prints the name of the command again so you're aware of which job you just put into the foreground. Stop the job again, with [ctrl-Z]. This time, use the command bg to put the job into the background. This will cause the command to run just as if you started the command with "&" as in the last section. /home/larry# bg [1]+ yes >/dev/null & /home/larry# And we have our prompt back. jobs should report that yes is indeed running, and we can kill the job with kill as we did before. How can we stop the job again? Using [ctrl-Z] won't work, because the job is in the background. The answer is to put the job in the foreground, with fg, and then stop it. As it turns out you can use fg on either stopped jobs or jobs in the background. There is a big difference between a job in the background and a job which is stopped. A stopped job is not running_it's not taking up CPU time or memory, and it's not doing any work. A job in the background is running, and using memory, as well as completing some task while you do other work. However, a job in the background may try to display text on to your terminal, which can be annoying if you're trying to work on something else. For example, if you used the command /home/larry# yes & without redirecting stdout to /dev/null, a stream of y's would be printed to your screen, without any way of interrupting it (you can't use [ctrl-C] to interrupt jobs in the background). In order to stop the endless y's, you'd have to use the kill command (without being able to see what you're typing). Another note. The fg and bg commands normally foreground or background the job which was last stopped (indicated by a "+" next to the job number when you use the command jobs). If you are running multiple jobs at once, you can foreground or back- ground a specific job by giving the job ID as an argument to fg or bg, as in /home/larry# fg %2 (to foreground job number 2), or /home/larry# bg %3 (to background job number 3). You can't use process ID numbers with fg or bg. Furthermore, using the job number alone, as in /home/larry# %2 is equivalent to /home/larry# fg %2 Just remember that using job control is a feature of the shell. The commands fg, bg and jobs are internal to the shell. If for some reason you use a shell which does not support job control, don't expect to find these commands available. In addition, there are some aspects of job control which differ between Bash and Tcsh. In fact, some shells don't provide job control at all_however, most shells available for Linux support job control. 4.11 Customizing your Environment The shell provides many mechanisms to customize your work en- vironment. As we've mentioned before, the shell is more than a command interpreter_it is also a powerful programming language. While writing shell scripts is an extensive subject, we'd like to in- troduce you to some of the ways that you can simplify your work on a UNIX system by using these advanced features of the shell. As we have mentioned before, different shells use different syn- taxes when executing shell scripts. For example, Tcsh uses a C-like syntax, while Bourne shells use another type of syntax. In this sec- tion, we won't be running into many of the differences between the two, but we will assume that shell scripts are executed using the Bourne shell syntax. 4.11.1 Shell scripts Let's say that you use a series of commands often, and would like to shorten the amount of required typing by grouping all of them together into a single "command". For example, the commands /home/larry# cat chapter1 chapter2 chapter3 > book /home/larry# wc -l book /home/larry# lp book would concatenate the files chapter1, chapter2, and chapter3 and place the result in the file book. Then, a count of the number of lines in book would be displayed, and finally book would be printed with the lp command. Instead of typing all of these commands, you could group them into a shell script. We described shell scripts briefly in Sec- tion 4.11.1. The shell script used to run all of these commands would look like #!/bin/sh # A shell script to create and print the book cat chapter1 chapter2 chapter3 > book wc -l book lp book If this script was saved in the file makebook, you could simply use the command /home/larry# makebook to run all of the commands in the script. Shell scripts are just plain text files; you can create them with an editor such as emacs or vi. Let's look at this shell script. The first line, "#!/bin/sh", identifies the file as a shell script, and tells the shell how to execute the script. It instructs the shell to pass the script to /bin/sh for execution, where /bin/sh is the shell program itself. Why is this important? On most UNIX systems, /bin/sh is a Bourne- type shell, such as Bash. By forcing the shell script to run using /bin/sh, we are ensuring that the script will run under a Bourne- syntax shell (instead of, say, a C shell). This will cause your script to run using the Bourne syntax even if you use Tcsh (or another C shell) as your login shell. The second line is a comment. Comments begin with the char- acter "#" and continue to the end of the line. Comments are ignored by the shell_they are commonly used to identify the shell script to the programmer. The rest of the lines in the script are just commands, as you would type them to the shell directly. In effect, the shell reads each line of the script and runs that line as if you had typed it at the shell prompt. Permissions are important for shell scripts. If you create a shell script, you must make sure that you have execute permission on the script in order to run it (*Note: When you create text files, the default permissions usually don't include execute permission.). The command /home/larry# chmod u+x makebook can be used to give yourself execute permission on the shell script makebook. 4.11.2 Shell variables and the environment The shell allows you to define variables, as most programming languages do. A variable is just a piece of data which is given the name. Note that Tcsh, as well as other C-type shells, use a different mechanism for setting variables than is described here. This dis- cussion assumes the use of a Bourne shell, such as Bash (which you're probably using). See the Tcsh man page for details. When you assign a value to a variable (using the "=" operator), you can access the variable by prepending a "$" to the variable name, as demonstrated below. /home/larry# foo="hello there" The variable foo is given the value "hello there". You can now refer to this value by the variable name, prefixed with a "$" char- acter. The command /home/larry# echo $foo hello there /home/larry# produces the same results as /home/larry# echo "hello there" hello there /home/larry# These variables are internal to the shell. This means that only the shell can access these variables. This can be useful in shell scripts; if you need to keep track of a filename, for example, you can store it in a variable, as above. Using the command set will display a list of all defined shell variables. However, the shell allows you to export variables to the en- vironment. The environment is the set of variables which all commands that you execute have access to. Once you define a variable inside the shell, exporting it makes that variable part of the environment as well. The export command is used to export a variable to the environment. Again, here we differ between Bash and Tcsh. If you're us- ing Tcsh, another syntax is used for setting environment variables (the setenv command is used). See the Tcsh man page for more information. The environment is very important to the UNIX system. It allows you to configure certain commands just by setting variables which the commands know about. Here's a quick example. The environment variable PAGER is used by the man command. It specifies the command to use to display man pages one screenful at a time. If you set PAGER to be the name of a command, it will use that command to display the man pages, instead of more (which is the default). Set PAGER to "cat". This will cause output from man to be displayed to the screen all at once, without breaking it up into pages. /home/larry# PAGER="cat" Now, export PAGER to the environment. /home/larry# export PAGER Try the command man ls. The man page should fly past your screen without pausing for you. Now, if we set PAGER to "more", the more command will be used to display the man page. /home/larry# PAGER="more" Note that we don't have to use the export command after we change the value of PAGER. We only need to export a variable once; any changes made to it thereafter will automatically be propagated to the environment. The man pages for a particular command will tell you if the command uses any environment variables; for example, the man man page explains that PAGER is used to specify the pager com- mand. Some commands share environment variables; for example, many commands use the EDITOR environment variable to specify the default editor to use when one is needed. The environment is also used to keep track of important infor- mation about your login session. An example is the HOME environ- ment variable, which contains the name of your home directory. /home/larry/papers# echo $HOME /home/larry Another interesting environment variable is PS1, which defines the main shell prompt. For example, /home/larry# PS1="Your command, please: " Your command, please: To set the prompt back to our usual (which contains the current working directory followed by a "#" symbol), Your command, please: PS1="\w# " /home/larry# The bash man page describes the syntax used for setting the prompt. 4.11.2.1 The PATH environment variable When you use the ls command, how does the shell know where to find the ls executable itself? In fact, ls is found in /bin/ls on most systems. The shell uses the environment variable PATH to locate executable files for commands which you type. For example, your PATH variable may be set to: /bin:/usr/bin:/usr/local/bin:. This is a list of directories for the shell to search, each directory separated by a ":". When you use the command ls, the shell first looks for /bin/ls, then /usr/bin/ls, and so on. Note that the PATH has nothing to do with finding regular files. For example, if you use the command /home/larry# cp foo bar The shell does not use PATH to locate the files foo and bar_those filenames are assumed to be complete. The shell only uses PATH to locate the cp executable. This saves you a lot of time; it means that you don't have to remember where all of the command executables are stored. On many systems, executables are scattered about in many places, such as /usr/bin, /bin, or /usr/local/bin. Instead of giving the command's full pathname (such as /usr/bin/cp), you can sim- ply set PATH to the list of directories that you want the shell to automatically search. Notice that PATH contains ".", which is the current working directory. This allows you to create a shell script or program and run it as a command from your current directory, without having to specify it directly (as in ./makebook). If a directory isn't on your PATH, then the shell will not search it for commands to run_this includes the current directory. 4.11.3 Shell initialization scripts In addition to shell scripts that you create, there are a number of scripts that the shell itself uses for certain purposes. The most important of these are your initialization scripts, scripts auto- matically executed by the shell when you login. The initialization scripts themselves are simply shell scripts, as described above. However, they are very useful in setting up your environment by executing commands automatically when you lo- gin. For example, if you always use the mail command to check your mail when you login, you place the command in your initial- ization script so it will be executed automatically. Both Bash and Tcsh distinguish between a login shell and other invocations of the shell. A login shell is a shell invoked at login time; usually, it's the only shell which you'll use. However, if you "shell out" of another program, such as vi, you start another instance of the shell, which isn't your login shell. In addition, whenever you run a shell script, you automatically start another instance of the shell to execute the script. The initialization files used by Bash are: /etc/profile (set up by the system administrator, executed by all Bash users at login time), $HOME/.bash_profile (executed by a login Bash session), and $HOME/.bashrc (executed by all non-login instances of Bash). Tcsh uses the following initialization scripts: /etc/login.csh (executed by all Tcsh users at login time), $HOME/.tcshrc (execut- ed a login time and by all new instances of Tcsh), and $HOME/.login (executed at login time, following .tcshrc). To fully understand the function of these files, you'll need to learn more about the shell itself. Shell programming is a compli- cated subject, far beyond the scope of this book. See the man pages for bash and/or tcsh to learn more about customizing your shell environment. 4.12 So You Want to Strike Out on Your Own? Hopefully we have provided enough information to give you a ba- sic idea of how to use the system. Keep in mind that most of the interesting and important aspects of Linux aren't covered here_ these are the very basics. With this foundation, before long you'll be up and running complicated applications and fulfilling the po- tential of your system. If things don't seem exciting at first, don't despair_there is much to be learned. One indispensable tool for learning about the system is to read the man pages. While many of the man pages may appear con- fusing at first, if you dig beneath the surface there is a wealth of information contained therein. We also suggest reading a complete book on using a UNIX sys- tem. There is much more to UNIX than meets the eye_unfortunately, most of it is beyond the scope of this book. Some good UNIX books to look at are listed in Appendix B. Chapter 5 System Administration This chapter is an overview to Linux system administration, in- cluding a number of advanced features which aren't necessarily for system administrators only. Just as every dog has its day, every system has its administrator, and running the system is a very im- portant and sometimes time-consuming job, even if you're the only user on your system. We have tried to cover here the most important things about system administration you need to know when you use Linux, in sufficient detail to get you comfortably started. In order to keep it short and sweet, we have only covered the very basics, and have skipped many an important detail. You should read the Linux Sys- tem Administrator's Guide if you are serious about running Linux. It will help you understand better how things work, and how they hang together. At least skim through it so that you know what it contains and know what kind of help you can expect from it. 5.1 About Root, Hats, and the Feeling of Power As you know, UNIX differentiates between different users, so that what they do to each other and to the system can be regulated (one wouldn't want anybody to be able to read one's love letters, for instance). Each user is given an account, which includes a username, home directory, and so on. In addition to accounts giv- en to real people, there are special system-defined accounts which have special privileges. The most important of these is the root account, for the username root. 5.1.1 The root account Ordinary users are generally restricted so that they can't do harm to anybody else on the system, just to themselves. File permissions on the system are arranged such that normal users aren't allowed to delete or modify files in directories shared by all users (such as /bin and /usr/bin. Most users also protect their own files with the appropriate file permissions so that other users can't access or modify those files. There are no such restrictions on root. The user root can read, modify, or delete any file on the system, change permissions and ownerships on any file, and run special programs, such as those which partition the drive or create filesystems. The basic idea is that the person or persons who run and take care of the system logs in as root whenever it is necessary to perform tasks that cannot be executed as a normal user. Because root can do anything, it is easy to make mistakes that have catastrophic consequences when logged in using this account. For example, as a normal user, if you inadvertently attempt to delete all of the files in /etc, the system will not permit you to do so. However, when logged in as root, the system won't complain at all. It is very easy to trash your system when using root. The best way to prevent accidents is to: o Sit on your hands before you press [return] on a command which may cause damage. For example, if you're about to clean out a directory, before hitting [return], re-read the entire command and make sure that it is correct. o Don't get accustomed to using root. The more comfortable you are in the role of the root user, the more likely you are to confuse your privileges with those of a normal user. For example, you might think that you're logged in as larry, when you're really logged in as root. o Use a different prompt for the root account. You should change root's .bashrc or .login file to set the shell promp- t to something other than your regular user prompt. For example, many people use the character "$" in prompts for regular users, and reserve the character "#" for the root user prompt. o Only login as root when absolutely necessary. And, as soon as you're finished with your work as root, log out. The less you use the root account, the less likely you'll be to do dam- age on your system. Of course, there is a breed of UNIX hackers out there who use root for virtually everything. But every one of them has, at some point, made a silly mistake as root and trashed the system. The general rule is, until you're familiar with the lack of restrictions on root, and are comfortable using the system without such restrictions, login as root sparingly. Of course, everyone makes mistakes. Linus Torvalds himself once accidentally deleted the entire kernel directory tree on his system. Hours of work were lost forever. Fortunately, however, because of his knowledge of the filesystem code, he was able to reboot the system and reconstruct the directory tree by hand on disk. Put another way, if you picture using the root account as wear- ing a special magic hat that gives you lots of power, so that you can, by waving your hand, destroy entire cities, it is a good idea to be a bit careful about what you do with your hands. Since it is easy to move your hand in a destructive way by accident, it is not a good idea to wear the magic hat when it is not needed, despite the wonderful feeling. 5.1.2 Abusing the system Along with the feeling of power comes the tendency to do har- m. This is one of the grey areas of UNIX system administration, but everyone goes through it at some point in time. Most users of UNIX systems never have the ability to wield this power_on university and business UNIX systems, only the highly-paid and highly-qualified system administrators ever login is root. In fact, at many such institutions, the root password is a highly guarded secret: it is treated as the Holy Grail of the institution. A large amount of hubbub is made about logging in as root; it is portrayed as a wise and fearsome power, given only to an exclusive cabal. This kind of attitude towards the root account is, quite sim- ply, the kind of thing which breeds malice and contempt. Because root is so fluffed-up, when some users have their first opportu- nity to login as root (either on a Linux system or elsewhere), the tendency is to use root's privileges in a harmful manner. I have known so-called "system administrators" who read other us- er's mail, delete user's files without warning, and generally behave like children when given such a powerful "toy". Because root has such privilege on the system, it takes a great deal of maturity and self-control to use the account as it was intended_to run the system. There is an unspoken code of honor which exists between the system administrator and the users on the system. How would you feel if your system administrator was reading your e-mail or looking over your files? There is still no strong legal precedent for electronic privacy on time-sharing com- puter systems. On UNIX systems, the root user has the ability to forego all security and privacy mechanisms on the system. It is important that the system administrator develop a trusting rela- tionship with the users on the system. I can't stress that enough. 5.1.3 Dealing with users UNIX security is rather lax by design. Security on the system was an afterthought_the system was originally developed in an environment where users intruding upon other users was simply unheard of. Because of this, even with security measures, there is still the ability for normal users to do harm. System administrators can take two stances when dealing with abusive users: they can be either paranoid or trusting. The para- noid system administrator usually causes more harm than he or she prevents. One of my favorite sayings is, "Never attribute to malice anything which can be attributed to stupidity." Put another way, most users don't have the ability or knowledge to do real harm on the system. 90% of the time, when a user is causing trouble on the system (by, for instance, filling up the user partition with large files, or running multiple instances of a large program), the user is simply unaware that what he or she is doing is a problem. I have come down on users who were causing a great deal of trouble, but they were simply acting out of ignorance_not malice. When you deal with users who are causing potential trouble, don't be accusative. The old rule of "innocent until proven guilty" still holds. It is best to simply talk to the user, and question about the trouble, instead of causing a confrontation. The last thing you want to do is be on the user's bad side. This will raise a lot of suspicion about you_the system administrator_running the system correctly. If a user believes that you distrust or dislike them, they might accuse you of deleting files or breaching privacy on the system. This is certainly not the kind of position that you want to be in. If you do find that a user has been attempting to "crack" the system, or was intentionally doing harm to the system, don't return the malicious behavior with malice of your own. Instead, simply provide a warning_but be flexible. In many cases, you may catch a user "in the act" of doing harm to the system_give them a warning. Tell them not to let it happen again. However, if you do catch them causing harm again, be absolutely sure that it is intentional. I can't even begin to describe the number of cases where it appeared as though a user was causing trouble, when in fact it was either an accident or a fault of my own. 5.1.4 Setting the rules The best way to run a system is not with an iron fist. That may be how you run the military, but UNIX was not designed for such discipline. It makes sense to lay down a simple and flexible set of guidelines for users_but remember, the fewer rules you have, the less chance there is of breaking them. Even if your rules for using the system are perfectly reasonable and clear, users will always at times break these rules without intending to. This is especially true in the case of new UNIX users, who are just learning the ropes of the system. It's not patently obvious, for example, that you shouldn't download a gigabyte of files and mail them to everyone on the system. Users need help understanding the rules, and why they are there. If you do specify usage guidelines for your system, make sure that the reason behind a particular guideline is made clear. If you don't, then users will find all sorts of creative ways to get around the rule, and not know that they are in fact breaking it. 5.1.5 What it all means We can't tell you how to run your system to the last detail. Most of the philosophy depends on how you're using the system. If you have many users, things are much different than if you only have a few users, or if you're the only user on the system. However, it's always a good idea_in any situation_to understand what being the system administrator really means. Being the system administrator doesn't make you a UNIX wiz- ard. There are many system admins out there who know very little about UNIX. Likewise, there are many "normal" users out there who know more about UNIX than any system administrator could. Also, being the system administrator does not allow you to use malice against your users. Just because the system gives you the privilege to mess with user files does not mean that you have any right to do so. Lastly, being the system administrator is really not a big deal. It doesn't matter if your system is a little 386 or a Cray supercom- puter. Running the system is the same, regardless. Knowing the root password isn't going to get you money, fame, or girls. It will allow you to maintain the system, and keep it running. That's it. 5.2 Booting the System There are several ways to boot the system, either from floppy or from the hard drive. 5.2.1 Using a boot floppy Many people boot Linux using a "boot floppy" which contains a copy of the Linux kernel. This kernel has the Linux root partition coded into it, so it will know where to look on the hard drive for the root filesystem. (The rdev command can be used to set the root partition in the kernel image; see below.) This is the type of floppy created by SLS during installation, for example. To create your own boot floppy, first locate the kernel image on your hard disk. It should be in the file /Image or /etc/Image. Some installations use the file /vmlinux for the kernel. You may instead have a compressed kernel. A compressed k- ernel uncompresses itself into memory at boot time, and takes up much less space on the hard drive. If you have a compressed kernel, it may be found in the file /zImage or /etc/zImage. Once you know where the kernel is, set the root device in the kernel image to the name of your Linux root partition with the rdev command. The format of the command is rdev where is the name of the kernel image, and is the name of the Linux root partition. For example, to set the root device in the kernel /etc/Image to /dev/hda2, use the command # rdev /etc/Image /dev/hda2 rdev can set other options in the kernel as well, such as the default SVGA mode to use at boot time. Just use "rdev" with no arguments to get a help message. After setting the root device, you can simply copy the kernel image to the floppy. Whenever copying data a floppy, it's a good idea to MS-DOS format the floppy first. This lays down the sector and track information on the floppy, so it can be detected as either high or low density. For example, to copy the kernel in the file /etc/Image to the floppy in /etc/fd0, use the command # cp /etc/Image /dev/fd0 This floppy should now boot Linux. 5.2.2 Using LILO Another method of booting is to use LILO, a program which resides in the boot sector of your hard disk. This program is executed when the system is booted from the hard disk, and can automatically boot up Linux from a kernel image stored on the hard drive itself. LILO can also be used as a first-stage boot loader for several operating systems, allowing you to select at boot time which operating system (such as Linux or MS-DOS) to boot. When you boot using LILO, the default operating system is booted unless you press [ctrl], [alt], or [shift] during the bootup sequence. If you press any of these keys, you will be provided with a boot prompt, at which you type the name of the operating system to boot (such as "linux" or "msdos"). If you press [tab] at the boot prompt, a listing of available operating systems will be provided. LILO is located in the directory /etc/lilo (if you have it). The easy way to install LILO is to edit the configuration file, /etc/lilo/config, and then run the command # /etc/lilo/lilo The LILO configuration file contains a "stanza" for each oper- ating system that you want to boot. The best way to demonstrate this is with an example LILO config file. The below setup is for a system which has a Linux root partition on /dev/hda1, and an MS-DOS partition on /dev/hda2. # Tell LILO to modify the boot record on /dev/hda (the first # non-SCSI hard drive). If you boot from a drive other than /dev/hda, # change the following line. boot = /dev/hda # Name of the boot loader. No reason to modify this unless you're doing # some serious hacking on LILO. install = /etc/lilo/boot.b # Have LILO perform some optimization. compact # Stanza for Linux root partition on /dev/hda1. image = /etc/Image # Location of kernel label = linux # Name of OS (for the LILO boot menu) root = /dev/hda1 # Location of root partition vga = ask # Tell kernel to ask for SVGA modes at boot time # Stanza for MSDOS partition on /dev/hda2. other = /dev/hda2 # Location of partition table = /dev/hda # Location of partition table for /dev/hda2 label = msdos # Name of OS (for boot menu) The first operating system stanza in the config file will be the default OS for LILO to boot. You can select another OS to boot at the LILO boot prompt, as discussed above. The program /etc/lilo/QuickInst will ask you questions about your setup and generate a LILO config file for you. Remember that every time you update the kernel image on disk, you should rerun /etc/lilo/lilo in order for the changes to be reflected on the boot sector of your drive. Also note that if you use the "root =" line, above, there's no reason to use rdev to set the root partition in the kernel image. LILO sets it for you at boot time. The Linux FAQ (see Appendix B) provides more information on LILO, including how to use LILO to boot with OS/2's Boot Manager. 5.3 Shutting Down Shutting down a Linux system is a bit tricky. Remember that you should never just turn off the power or hit the reset switch while the system is running. The kernel keeps track of disk I/O in memory buffers. If you reboot the system without giving the kernel the chance to write its buffers to disk, you can corrupt your filesystems. Other precautions are taken at shutdown time as well. All pro- cesses are sent a signal, which allows them to die gracefully (writ- ing and closing all files, and so on). Filesystems are unmounted for safety. If you wish, the system can also alert users that the system is going down and give them a change to log off. The easiest way to shutdown is with the shutdown command. The format of the command is shutdown