summarize:
This book are grouped together into the following five categories: Boot Time, Command Line, Automation, Resource Management,
and Kernel Tuning.
1.Boot Time:
Removing Unnecessary Services
Forgoing the Console Login
Common Boot Parameters
Creating a Persistent Daemon with init
2.Command Line:
n>&m: Swap Standard Output and Standard Error
Building Complex Command Lines
Working with Tricky Files in xargs
Immutable Files in ext2/ext3
Speeding Up Compiles
3.Automation:
At home in your shell environments
Finding and eliminating setuid/setgid binaries
Make sudo work harder for you
Using a Makefile to automate admin tasks
Brute forcing your new domain name
4.Resource Management:
Playing Hunt the Disk Hog
Fun with /proc
Manipulating processes symbolically with procps
Managing system resources per process
Cleaning up after ex-users
5.Kernel Tuning:
Eliminating unnecessary drivers from the kernel
Using large amounts of RAM
hdparm: fine tune IDE drive parameters
chapter 1 Removing Unnecessary Services
When building a server, you should continually ask yourself: what do I really need this machine to do? Do I really need FTP
services on my web server? Should NFS be running on my DNS server, even if no shares are exported? Do I need the automounter
to run if I mount all of my volumes statically?
test step:
1.ps ax
2.grep -v ^# /etc/inetd.conf and netstat -lp
Here are some notorious(臭名昭著的) (and typically unnecessary) services that are enabled by default in many distributions:
1.portmap, rpc.mountd, rpc.nfsd
These are all part of the NFS subsystem. Unless you need to mount remote NFS shares, you don't need these daemons running.
2.smbd and nmbd
These are the Samba daemons. Do you need to export SMB shares to Windows boxes (or other machines)? If not, then these
processes can be safely killed.
3.automount
The automounter can be handy to bring up network (or local) filesystems on demand, eliminating the need for root
privileges when accessing them.But on a dedicated server, the automounter is probably unnecessary.
4.named
Are you running a name server? You don't need named running if you only need to resolve network names; that's what
/etc/resolv.conf and the bind libraries are for.
5.lpd
Do you ever print to this machine?
6.inetd
Do you really need to run any services from inetd? If you have ssh running in standalone mode, and are only running
standalone daemons (such as Apache, BIND, MySQL, or ProFTPD) then inetd may be superfluous. In the very least, review which
services are being accepted with the grep command grep -v ^# /etc/inetd.conf. If you find that every service can be safely
commented out, then why run the daemon? Remove it from the boot process (either by removing it from the system rc's or with a
simple chmod -x /usr/sbin/inetd).
7.telnet, rlogin, rexec, ftp
The remote login, execution, and file transfer functionality of these venerable daemons has largely been supplanted by ssh
and scp, their cryptographically secure and tremendously flexible counterparts.
8.finger, comsat, chargen, echo, identd
The finger and comsat services made sense in the days of an open Internet, where users were curious but generally well-
intentioned. In these days of stealth portscans and remote buffer overflow exploits, running extraneous services that give
away information about your server is generally considered a bad idea. The chargen and echo ports were once good for testing
network connectivity, but are now too inviting for a random miscreant to fiddle with (and perhaps connect to each other to
drive up server load quickly and inexpensively). Finally, the identd service was once a meaningful and important source of
information, providing remote servers with an idea of which users were connecting to their machines. Unfortunately, in these
days of local root exploits and desktop Linux machines, installing an identd that (perish the thought!) actually lies about
who is connected has become so common that most sites ignore the author information anyway. Since identd is a notoriously
shaky source of information, why leave it enabled at all?
If you absolutely need to run insecure services on your machine, then you should use tcp wrappers or local firewalling to
limit access to only the machines that absolutely need it.
chapter 2 Forgoing the Console Login
All of the access, none of the passwords :
It will happen to you one day. You'll need to work on a machine for a friend or client who has "misplaced" the root password
on which you don't have an account.
If you have console access and don't mind rebooting, traditional wisdom beckons you to boot up in single user mode.
Naturally, after hitting Control-Alt-Delete, you simply wait for it to POST and then pass the parameter single to the booting
kernel. For example, from the LILO prompt:
LILO: linux single
On many systems, this will happily present you with a root shell. But on some systems (notably RedHat), you'll run into the
dreaded emergency prompt:
Give root password for maintenance
(or type Control-D for normal startup)
If you knew the root password, you wouldn't be here! If you're lucky, the init script will actually let you hit ^C at this
stage and will drop you to a root prompt. But most init processes are "smarter" than that, and trap ^C. What to do? Of
course, you could always boot from a rescue disk and reset the password, but suppose you don't have one handy (or that the
machine doesn't have a CD-ROM drive).
All is not lost! Rather than risk running into the above mess, let's modify the system with extreme prejudice, right from the
start. Again, from the LILO prompt:
LILO: linux init=/bin/bash
# mount -o remount,rw /
change password
# mount -o remount,ro /
reboot
chapter 3 Common Boot Parameters
Manipulate kernel parameters at boot time :
As we saw in [Hack #2], it is possible to pass parameters to the kernel at the LILO prompt allowing you to change the program
that is first called when the system boots. Changing init (with the init=/bin/bash line) is just one of many useful options
that can be set at boot time. Here are more common boot parameters:
1.single ##Boots up in single user mode.
2.root= ##Changes the device that is mounted as /. For example: root=/dev/sdc4
3.hdX=
Adjusts IDE drive geometry. This is useful if your BIOS reports incorrect information:
hda=3649,255,63 hdd=cdrom
This defines the master/primary IDE drive as a 30GB hard drive in LBA mode, and the slave/secondary IDE drive as a CD-ROM
4.console=
Defines a serial port console on kernels with serial console support. For example:
console=ttyS0,19200n81
Here we're directing the kernel to log boot messages to ttyS0 (the first serial port), at 19200 baud, no parity, 8 data bits,
1 stop bit. Note that to get an actual serial console (that you can log in on), you'll need to add a line to /etc/inittab
that looks something like this:
s1:12345:respawn:/sbin/agetty 19200 ttyS0 vt100
5.nosmp
Disables SMP on a kernel so enabled. This can help if you suspect kernel trouble on a multiprocessor system.
6.mem=
Defines the total amount of available system memory. See [Hack #21].
7.ro
Mounts the / partition read-only (this is typically the default, and is remounted read-write after fsck runs).
8.rw
Mounts the / partition read-write. This is generally a bad idea, unless you're also running the init hack. Pass your init
line along with rw, like this:
init=/bin/bash rw
to eliminate the need for all of that silly mount -o remount,rw /
chapter 4 Creating a Persistent Daemon with init
------------待续----------
