DOCSLIB.ORG

Diskless Debian Etch

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Diskless Debian Etch Diskless Debian Etch W. Trevor King∗ November 18, 2010 Contents 1 Overview 1 1.1 Physical setup.............................................1 1.2 Notation................................................1 2 Basic server setup 2 2.1 Installing the OS...........................................2 2.2 Configuring networking.......................................2 3 Remote booting 3 3.1 Server services............................................3 3.1.1 pxelinux............................................3 3.1.2 DHCP.............................................4 3.1.3 TFTP.............................................5 3.1.4 NFS..............................................6 3.2 Client setup..............................................6 3.2.1 Root file system.......................................6 3.2.2 Configuring etc........................................7 3.2.3 Kernel and initial ramdisk..................................7 3.3 Synthesis...............................................8 4 Adding clients 9 Appendix 9 A Compiling a kernel 10 B Troubleshooting 11 B.1 Waiting for /usr/........................................... 12 Bibliography 12 1 Overview This HOWTO details the procedure I used to set up the abax cluster for NFS-rooted network booting. The system is useful in this case because it centralizes the installation in the head node (server), which makes maintaining, upgrading, or altering the computational nodes (clients) easier. ∗Drexel University 1 This procedure follows mainly Tim Brom's Microwulf configuration notes[1] with two major differences. • Microwulf uses Ubuntu (gutsy?), and I'm using Debian etch. • Microwulf has a seperate partition for each client's root, populated with an independent installation from CD. I'm using a single partition for all of my clients, with the base system created using deboot- strap (no CD). For guidance in my deviations, I'm indebted to Bart Trojanowski's pxeboot and nfsroot notes[2] and Falko Timme's notes on kernel compilation in Debian Etch[3]. 1.1 Physical setup Our cluster has one server with eight clients. The server has two network cards, eth0 and eth1. eth1 is connected to the outsize world (WAN). All of the clients have one network card, eth0. All of the eth0s are connected together through a gigabit switch (LAN). 1.2 Notation Throughout this HOWTO, I will use # as the prompt for root, $ as the prompt for an unpriveledged user, and chroot# as the prompt for a root in a chrooted environment. File contents will be framed with the full path listed labeling the frame /path/to/file Contents of file All files are complete with the exception of lines containing ..., in which case the meaning of the example should be clear from the context. 2 Basic server setup 2.1 Installing the OS Boot the server with the Debian installation kernel following one of the options in the Debian installation guide[4]. I netbooted my server from one of the client nodes following this procedure to set up the DHCP and TFTP servers on the client and untarring http://http.us.debian.org/debian/dists/etch/main/ installer-i386/current/images/netboot/netboot.tar.gz in my tftpboot directory. After netbooting from a client, don't forget to take that client down so you woln't have DHCP conflicts once you set up a DHCP server on your server. Install Debian in whatever manner seems most appropriate to you. I partitioned my 160 GB drive manually according to Mount point Type Size / ext3 280 MB /usr ext3 20 GB /var ext3 20 GB /swap swap 1 GB /tmp ext3 5 GB /diskless ext3 20 GB /home ext3 93.7 GB I went with a highly partitioned drive to ease mounting, since I will be sharing some partitions with my clients. To understand why partitioning is useful, see the Partition HOWTO[5]. You can install whichever packages you like, but I went with just the standard set (no Desktop, Server, etc.). You can adjust your installation later with any of (not an exhaustive list) 2 • tasksel : command line, coarse-grained package control[6]. • apt-get : command line, fine-grained package control. • aptitude : curses frontend for apt-get. • synaptic : gtk+ frontend for apt-get. • dpkg : command line, package-management without dependency checking. The base install is pretty bare, but I don't need a full blown desktop, so I flesh out my system with # apt-get install xserver-xorg fluxbox fluxconf iceweasel xterm xpdf # apt-get install build-essentials emacs21-nox which gives me a bare-bones graphical system (fire it up with startx), and a bunch of critical build tools (make, gcc, etc.). 2.2 Configuring networking We need to set up our server so that eth1 assumes it's appropriate static IP on the WAN, and eth0 assumes it's appropriate static IP on the LAN. We achieve this by changing the default /etc/network/interfaces to /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback allow-hotplug eth0 # start on boot & when plugged in iface eth0 inet static # static LAN interface address 192.168.2.100 netmask 255.255.255.0 broadcast 192.168.2.255 allow-hotplug eth1 # start on boot & when plugged in #iface eth1 inet dhcp # WAN DHCP interface (not used) iface eth1 inet static # WAN static interface address XXX.XXX.YYY.YYY netmask 255.255.128.0 broadcast XXX.XXX.127.255 gateway XXX.XXX.ZZZ.ZZZ where I've censored our external IPs for privacy. The netmask selects which addresses belong to which networks. The way we've set it up, all 192.168.2.xxx messages will be routed out eth0, and everything else will go through eth1 to it's gateway. See the Net-HOWTO[7] for more details. 3 Remote booting 3.1 Server services The clients will boot remotely using the Pre eXecution Environment (PXE). The boot procedure is 3 1. Client powers on. 2. Client BIOS comes up, detects attached devices, and looks for a DHCP server for advice on network booting. 3. DHCP server gives client an IP address, domain name, host name, the IP address of the TFTP server, and the location of the bootloader on the TFTP server. 4. Client gets bootloader from TFTP server. 5. BIOS hands over control to bootloader. 6. Bootloader gets kernel and initial ramdisk from TFTP server. 7. Bootloader hands over control to kernel 8. Kernel starts up the system, mounting root via NFS. 9. after this point, it's just like a normal boot process. We can see that we need to set up DHCP, TFTP, and NFS servers (not necessarily on the same server, but they are in our case). 3.1.1 pxelinux The bootloader can be obtained with # apt-get install syslinux which installs it to /usr/lib/syslinux/pxelinux.0 along with a manual[8] and some other syslinux tools. 3.1.2 DHCP Install a server with # apt-get install dhcp Configure the server with /etc/dhcpd.conf allow bootp; # maybe? allow booting;# maybe? option domain-name "your.domain.com"; option domain-name-servers XXX.XXX.XXX.XXX,YYY.YYY.YYY.YYY; subnet 192.168.2.0 netmask 255.255.255.0 { range 192.168.2.150 192.168.2.200; # non-static IP range option broadcast-address 192.168.2.255; option routers 192.168.2.100; # Gateway server next-server 192.168.2.100; # TFTP server filename "pxelinux.0"; # bootloader host n1 { hardware ethernet ZZ:ZZ:ZZ:ZZ:ZZ:ZZ; fixed-address 192.168.2.101; option root-path "192.168.2.100:/diskless/n1"; option host-name "n1"; } ... more hosts for other client nodes ... } 4 This assigns the client a static hostname, domain name, and IP address according to it's ethernet address (aka MAC address). It also tells all the clients to ask the TFTP server on 192.168.2.100 for the bootloader pxelinux.0. For extra fun, it tells the clients to send packets to the router at 192.168.2.100 if they can't figure out where they should go, and to use particular DNS servers to resolve domain names to IP addresses. This gives them access to the outside WAN. I don't know yet if the booting options are necessary, since I don't know what they do. We also need to ensure that the DHCP server only binds to eth0, since starting a DHCP server on your WAN will make you unpopular with your ISP. /etc/default/dhcp INTERFACES="eth0" Once the DHCP server is configured, you can start it with # /etc/init.d/dhcp restart Check that the server is actually up with # ps -e | grep dhcp and if it is not, look for error messages in # grep -i dhcp /var/log/syslog 3.1.3 TFTP There are several TFTP server packages. We use atftpd here, but tftp-hpa is also popular. Install atftpd with # apt-get install atftpd xinetd where xinetd is a super-server (replacing inetd, see man xinetd for details). Configure atftpd with /etc/xinetd.d/atftpd service tftp { disable = no socket_type = dgram protocol = udp wait = yes user = nobody server = /usr/sbin/in.tftpd server_args = --tftpd-timeout 300 --retry-timeout 5 --bind-address 192.168.2.100 --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --logfile /var/log/atftpd.log --verbose=10 /diskless/tftpboot } Note that the server_args should all be on a single, long line, since I haven't been able to discover if xinetd recognizes escaped endlines yet. This configuration tells xinetd to provide TFTP services by running in.tftpd (the daemon form of atftpd) as user nobody. Most of the options we pass to in.tftpd involve multicasting, which I believe is only used for MTFTP (which pxelinux.0 doesn't use). --logfile /var/log/atftpd.log --verbose=10 logs lots of detail to /var/log/atftpd.log if it exists.
Load more

Recommended publications
  • Chrooting All Services in Linux
    LinuxFocus article number 225 http://linuxfocus.org Chrooting All Services in Linux by Mark Nielsen (homepage) About the author: Abstract: Mark works as an independent consultant Chrooted system services improve security by limiting damage that donating time to causes like someone who broke into the system can possibly do. GNUJobs.com, writing _________________ _________________ _________________ articles, writing free software, and working as a volunteer at eastmont.net. Introduction What is chroot? Chroot basically redefines the universe for a program. More accurately, it redefines the "ROOT" directory or "/" for a program or login session. Basically, everything outside of the directory you use chroot on doesn't exist as far a program or shell is concerned. Why is this useful? If someone breaks into your computer, they won't be able to see all the files on your system. Not being able to see your files limits the commands they can do and also doesn't give them the ability to exploit other files that are insecure. The only drawback is, I believe it doesn't stop them from looking at network connections and other stuff. Thus, you want to do a few more things which we won't get into in this article too much: Secure your networking ports. Have all services run as a service under a non-root account. In addition, have all services chrooted. Forward syslogs to another computer. Analyze logs files Analyze people trying to detect random ports on your computer Limit cpu and memory resources for a service. Activate account quotas. The reason why I consider chroot (with a non-root service) to be a line of defense is, if someone breaks in under a non-root account, and there are no files which they can use to break into root, then they can only limit damage to the area they break in.
    [Show full text]
  • Operating System Boot from Fully Encrypted Device
    Masaryk University Faculty of Informatics Operating system boot from fully encrypted device Bachelor’s Thesis Daniel Chromik Brno, Fall 2016 Replace this page with a copy of the official signed thesis assignment and the copy of the Statement of an Author. Declaration Hereby I declare that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Daniel Chromik Advisor: ing. Milan Brož i Acknowledgement I would like to thank my advisor, Ing. Milan Brož, for his guidance and his patience of a saint. Another round of thanks I would like to send towards my family and friends for their support. ii Abstract The goal of this work is description of existing solutions for boot- ing Linux and Windows from fully encrypted devices with Secure Boot. Before that, though, early boot process and bootloaders are de- scribed. A simple Linux distribution is then set up to boot from a fully encrypted device. And lastly, existing Windows encryption solutions are described. iii Keywords boot process, Linux, Windows, disk encryption, GRUB 2, LUKS iv Contents 1 Introduction ............................1 1.1 Thesis goals ..........................1 1.2 Thesis structure ........................2 2 Boot Process Description ....................3 2.1 Early Boot Process ......................3 2.2 Firmware interfaces ......................4 2.2.1 BIOS – Basic Input/Output System . .4 2.2.2 UEFI – Unified Extended Firmware Interface .5 2.3 Partitioning tables ......................5 2.3.1 MBR – Master Boot Record .
    [Show full text]
  • The Linux Kernel Module Programming Guide
    The Linux Kernel Module Programming Guide Peter Jay Salzman Michael Burian Ori Pomerantz Copyright © 2001 Peter Jay Salzman 2007−05−18 ver 2.6.4 The Linux Kernel Module Programming Guide is a free book; you may reproduce and/or modify it under the terms of the Open Software License, version 1.1. You can obtain a copy of this license at http://opensource.org/licenses/osl.php. This book is distributed in the hope it will be useful, but without any warranty, without even the implied warranty of merchantability or fitness for a particular purpose. The author encourages wide distribution of this book for personal or commercial use, provided the above copyright notice remains intact and the method adheres to the provisions of the Open Software License. In summary, you may copy and distribute this book free of charge or for a profit. No explicit permission is required from the author for reproduction of this book in any medium, physical or electronic. Derivative works and translations of this document must be placed under the Open Software License, and the original copyright notice must remain intact. If you have contributed new material to this book, you must make the material and source code available for your revisions. Please make revisions and updates available directly to the document maintainer, Peter Jay Salzman <[email protected]>. This will allow for the merging of updates and provide consistent revisions to the Linux community. If you publish or distribute this book commercially, donations, royalties, and/or printed copies are greatly appreciated by the author and the Linux Documentation Project (LDP).
    [Show full text]
  • LM1881 Video Sync Separator Datasheet
    Product Sample & Technical Tools & Support & Folder Buy Documents Software Community LM1881 SNLS384G –FEBRUARY 1995–REVISED JUNE 2015 LM1881 Video Sync Separator 1 Features 3 Description The LM1881 Video sync separator extracts timing 1• AC Coupled Composite Input Signal information including composite and vertical sync, • >10-kΩ Input Resistance burst or back porch timing, and odd and even field • <10-mA Power Supply Drain Current information from standard negative going sync NTSC, • Composite Sync and Vertical Outputs PAL (1) and SECAM video signals with amplitude from • Odd and Even Field Output 0.5-V to 2-V p-p. The integrated circuit is also capable of providing sync separation for non- • Burst Gate or Back Porch Output standard, faster horizontal rate video signals. The • Horizontal Scan Rates to 150 kHz vertical output is produced on the rising edge of the • Edge Triggered Vertical Output first serration in the vertical sync period. A default vertical output is produced after a time delay if the • Default Triggered Vertical Output for Non- rising edge mentioned above does not occur within Standard Video Signal (Video Games-Home the externally set delay period, such as might be the Computers) case for a non-standard video signal. 2 Applications Device Information(1) • Video Cameras and Recorders PART NUMBER PACKAGE BODY SIZE (NOM) SOIC (8) 4.90 mm × 3.91 mm • Broadcasting Systems LM1881 • Set-Top Boxes PDIP (8) 9.81 mm × 6.35 mm • Home Entertainment (1) For all available packages, see the orderable addendum at the end of the data sheet. • Computing and Gaming Applications (1) PAL in this datasheet refers to European broadcast TV standard “Phase Alternating Line”, and not to Programmable Array Logic.
    [Show full text]
  • White Paper: Indestructible Firewall in a Box V1.0 Nick Mccubbins
    White Paper: Indestructible Firewall In A Box v1.0 Nick McCubbins 1.1 Credits • Nathan Yawn ([email protected]) 1.2 Acknowledgements • Firewall-HOWTO • Linux Router Project • LEM 1.3 Revision History • Version 1.0 First public release 1.4 Feedback • Send all information and/or criticisms to [email protected] 1.5 Distribution Policy 2 Abstract In this document, the procedure for creating an embedded firewall whose root filesystem is loaded from a flash disk and then executed from a RAMdisk will be illustrated. A machine such as this has uses in many environments, from corporate internet access to sharing of a cable modem or xDSL connection among many computers. It has the advantages of being very light and fast, being impervious to filesystem corruption due to power loss, and being largely impervious to malicious crackers. The type of firewall illustrated herein is a simple packet-filtering, masquerading setup. Facilities for this already exist in the Linux kernel, keeping the system's memory footprint small. As such the device lends itself to embedding very well. For a more detailed description of firewall particulars, see the Linux Firewall-HOWTO. 3 Equipment This project has minimal hardware requirements. An excellent configuration consists of: For a 100-baseT network: • SBC-554 Pentium SBC with PISA bus and on-board PCI NIC (http://www.emacinc.com/pc.htm#pentiumsbc), approx. $373 • PISA backplane, chassis, power supply (http://www.emacinc.com/sbcpc_addons/mbpc641.htm), approx. $305 • Second PCI NIC • 32 MB RAM • 4 MB M-Systems Flash Disk (minimum), approx. $45 For a 10-baseT network: • EMAC's Standard Server-in-a-Box product (http://www.emacinc.com/server_in_a_box.htm), approx.
    [Show full text]
  • Making Linux Protection Mechanisms Egalitarian with Userfs
    Making Linux Protection Mechanisms Egalitarian with UserFS Taesoo Kim and Nickolai Zeldovich MIT CSAIL ABSTRACT firewall rules, forcing applications to invent their own UserFS provides egalitarian OS protection mechanisms protection techniques like system call interposition [15], in Linux. UserFS allows any user—not just the system binary rewriting [30] or analysis [13, 45], or interposing administrator—to allocate Unix user IDs, to use chroot, on system accesses in a language runtime like Javascript. and to set up firewall rules in order to confine untrusted This paper presents the design of UserFS, a kernel code. One key idea in UserFS is representing user IDs as framework that allows any application to use traditional files in a /proc-like file system, thus allowing applica- OS protection mechanisms on a Unix system, and a proto- tions to manage user IDs like any other files, by setting type implementation of UserFS for Linux. UserFS makes permissions and passing file descriptors over Unix do- protection mechanisms egalitarian, so that any user—not main sockets. UserFS addresses several challenges in just the system administrator—can allocate new user IDs, making user IDs egalitarian, including accountability, re- set up firewall rules, and isolate processes using chroot. source allocation, persistence, and UID reuse. We have By using the operating system’s own protection mecha- ported several applications to take advantage of UserFS; nisms, applications can avoid race conditions and ambi- by changing just tens to hundreds of lines of code, we guities associated with system call interposition [14, 43], prevented attackers from exploiting application-level vul- can confine existing code without having to recompile or nerabilities, such as code injection or missing ACL checks rewrite it in a new language, and can enforce a coherent in a PHP-based wiki application.
    [Show full text]
  • Sandboxing 2 Change Root: Chroot()
    Sandboxing 2 Change Root: chroot() Oldest Unix isolation mechanism Make a process believe that some subtree is the entire file system File outside of this subtree simply don’t exist Sounds good, but. Sandboxing 2 2 / 47 Chroot Sandboxing 2 3 / 47 Limitations of Chroot Only root can invoke it. (Why?) Setting up minimum necessary environment can be painful The program to execute generally needs to live within the subtree, where it’s exposed Still vulnerable to root compromise Doesn’t protect network identity Sandboxing 2 4 / 47 Root versus Chroot Suppose an ordinary user could use chroot() Create a link to the sudo command Create /etc and /etc/passwd with a known root password Create links to any files you want to read or write Besides, root can escape from chroot() Sandboxing 2 5 / 47 Escaping Chroot What is the current directory? If it’s not under the chroot() tree, try chdir("../../..") Better escape: create device files On Unix, all (non-network) devices have filenames Even physical memory has a filename Create a physical memory device, open it, and change the kernel data structures to remove the restriction Create a disk device, and mount a file system on it. Then chroot() to the real root (On Unix systems, disks other than the root file system are “mounted” as a subtree somewhere) Sandboxing 2 6 / 47 Trying Chroot # mkdir /usr/sandbox /usr/sandbox/bin # cp /bin/sh /usr/sandbox/bin/sh # chroot /usr/sandbox /bin/sh chroot: /bin/sh: Exec format error # mkdir /usr/sandbox/libexec # cp /libexec/ld.elf_so /usr/sandbox/libexec # chroot /usr/sandbox
    [Show full text]
  • Chapter 3. Booting Operating Systems
    Chapter 3. Booting Operating Systems Abstract: Chapter 3 provides a complete coverage on operating systems booting. It explains the booting principle and the booting sequence of various kinds of bootable devices. These include booting from floppy disk, hard disk, CDROM and USB drives. Instead of writing a customized booter to boot up only MTX, it shows how to develop booter programs to boot up real operating systems, such as Linux, from a variety of bootable devices. In particular, it shows how to boot up generic Linux bzImage kernels with initial ramdisk support. It is shown that the hard disk and CDROM booters developed in this book are comparable to GRUB and isolinux in performance. In addition, it demonstrates the booter programs by sample systems. 3.1. Booting Booting, which is short for bootstrap, refers to the process of loading an operating system image into computer memory and starting up the operating system. As such, it is the first step to run an operating system. Despite its importance and widespread interests among computer users, the subject of booting is rarely discussed in operating system books. Information on booting are usually scattered and, in most cases, incomplete. A systematic treatment of the booting process has been lacking. The purpose of this chapter is to try to fill this void. In this chapter, we shall discuss the booting principle and show how to write booter programs to boot up real operating systems. As one might expect, the booting process is highly machine dependent. To be more specific, we shall only consider the booting process of Intel x86 based PCs.
    [Show full text]
  • Linux Boot Loaders Compared
    Linux Boot Loaders Compared L.C. Benschop May 29, 2003 Copyright c 2002, 2003, L.C. Benschop, Eindhoven, The Netherlands. Per- mission is granted to make verbatim copies of this document. This is version 1.1 which has some minor corrections. Contents 1 introduction 2 2 How Boot Loaders Work 3 2.1 What BIOS does for us . 3 2.2 Parts of a boot loader . 6 2.2.1 boot sector program . 6 2.2.2 second stage of boot loader . 7 2.2.3 Boot loader installer . 8 2.3 Loading the operating system . 8 2.3.1 Loading the Linux kernel . 8 2.3.2 Chain loading . 10 2.4 Configuring the boot loader . 10 3 Example Installations 11 3.1 Example root file system and kernel . 11 3.2 Linux Boot Sector . 11 3.3 LILO . 14 3.4 GNU GRUB . 15 3.5 SYSLINUX . 18 3.6 LOADLIN . 19 3.7 Where Can Boot Loaders Live . 21 1 4 RAM Disks 22 4.1 Living without a RAM disk . 22 4.2 RAM disk devices . 23 4.3 Loading a RAM disk at boot time . 24 4.4 The initial RAM disk . 24 5 Making Diskette Images without Diskettes 25 6 Hard Disk Installation 26 7 CD-ROM Installation 29 8 Conclusions 31 1 introduction If you use Linux on a production system, you will only see it a few times a year. If you are a hobbyist who compiles many kernels or who uses many operating systems, you may see it several times per day.
    [Show full text]
  • The Linux Command Line
    The Linux Command Line Fifth Internet Edition William Shotts A LinuxCommand.org Book Copyright ©2008-2019, William E. Shotts, Jr. This work is licensed under the Creative Commons Attribution-Noncommercial-No De- rivative Works 3.0 United States License. To view a copy of this license, visit the link above or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042. A version of this book is also available in printed form, published by No Starch Press. Copies may be purchased wherever fine books are sold. No Starch Press also offers elec- tronic formats for popular e-readers. They can be reached at: https://www.nostarch.com. Linux® is the registered trademark of Linus Torvalds. All other trademarks belong to their respective owners. This book is part of the LinuxCommand.org project, a site for Linux education and advo- cacy devoted to helping users of legacy operating systems migrate into the future. You may contact the LinuxCommand.org project at http://linuxcommand.org. Release History Version Date Description 19.01A January 28, 2019 Fifth Internet Edition (Corrected TOC) 19.01 January 17, 2019 Fifth Internet Edition. 17.10 October 19, 2017 Fourth Internet Edition. 16.07 July 28, 2016 Third Internet Edition. 13.07 July 6, 2013 Second Internet Edition. 09.12 December 14, 2009 First Internet Edition. Table of Contents Introduction....................................................................................................xvi Why Use the Command Line?......................................................................................xvi
    [Show full text]
  • Dell EMC Poweredge Systems Running Red Hat Enterprise Linux 7 Release Notes Notes, Cautions, and Warnings
    Dell EMC PowerEdge Systems Running Red Hat Enterprise Linux 7 Release Notes Notes, cautions, and warnings NOTE: A NOTE indicates important information that helps you make better use of your product. CAUTION: A CAUTION indicates either potential damage to hardware or loss of data and tells you how to avoid the problem. WARNING: A WARNING indicates a potential for property damage, personal injury, or death. © 2014 - 2019 Dell Inc. or its subsidiaries. All rights reserved. Dell, EMC, and other trademarks are trademarks of Dell Inc. or its subsidiaries. Other trademarks may be trademarks of their respective owners. 2019 - 03 Rev. A15 Contents 1 Overview........................................................................................................................................................6 System configuration requirements................................................................................................................................. 6 Memory......................................................................................................................................................................... 6 Installation and upgrade instructions............................................................................................................................... 6 2 Known issues—To be fixed in future releases.................................................................................................7 Unable to create or modify namespace for NVDIMM..................................................................................................
    [Show full text]
  • 26 Disk Space Management
    26 Disk Space Management 26.1 INTRODUCTION It has been said that the only thing all UNIX systems have in common is the login message asking users to clean up their files and use less disk space. No matter how much space you have, it isn’t enough; as soon as a disk is added, files magically appear to fill it up. Both users and the system itself are potential sources of disk bloat. Chapter 12, Syslog and Log Files, discusses various sources of logging information and the techniques used to manage them. This chapter focuses on space problems caused by users and the technical and psy- chological weapons you can deploy against them. If you do decide to Even if you have the option of adding more disk storage to your system, add a disk, refer to it’s a good idea to follow this chapter’s suggestions. Disks are cheap, but Chapter 9 for help. administrative effort is not. Disks have to be dumped, maintained, cross-mounted, and monitored; the fewer you need, the better. 26.2 DEALING WITH DISK HOGS In the absence of external pressure, there is essentially no reason for a user to ever delete anything. It takes time and effort to clean up unwanted files, and there’s always the risk that something thrown away might be wanted again in the future. Even when users have good intentions, it often takes a nudge from the system administrator to goad them into action. 618 Chapter 26 Disk Space Management 619 On a PC, disk space eventually runs out and the machine’s primary user must clean up to get the system working again.
    [Show full text]