SysAdmin to SysAdmin: Five flags you completely forgot about

Administrators are creatures of habit. So much so that we often read
things and think, “hey, that’s really cool,” and then we completely
forget about them, even though they might, in some instances, be useful
on a regular basis. Old habits are hard to break. I know this, because I
fall victim to it myself. I try to correct this by occasionally using
downtime to read man pages for commands I use all the time, like
cp and ls. So I’ve done the geeky work for you,
and now I present “Five flags you completely forgot about.”

Scrap your scripts: cp -u

A perfect piece of evidence that admins myself included) are prone to habit lies in a script I was writing in Perl. It, along with some
config files for the systems, sat in a directory called /lab/adm, and it was mounted by about 30 machines. The machines were configured with a cron job that would run the script from
the mounted directory every 20 minutes. The script was called etcupdate, and it worked flawlessly. When run on the client, it checked the contents of the directory (minus the script itself) against
its local /etc directory. If it found any that weren’t in the local /etc, or any that were newer than what was in the local /etc, it would copy them over.

Problem is, I had now written about 30 lines of Perl to perform the exact same functionality as cp -u. The -u
means “update.” From the man page:

-u, –update
copy only when the SOURCE file is newer than the
destination file or when the destination file is
missing

Miscreant tarball detection

You’ve heard me talk about miscreant tarballs — they’re the ones that
fail to create their own directory to put files in. Instead, they
randomly spew files all over whatever directory you happen to untar them
in. This doesn’t happen all that often, but when it does, it’s a pain in the neck, and I always wind up finding some
oddball file six months later that I have to remove by hand. To
detect these, just replace the x flag to tar
with t, as in tar tvzf filename. This
will not extract the tarball, but will list the files that live in the
archive, full paths included. This means that you’ll see if it creates
its own subdirectory or not. This is nice.

What the heck is that user doing?

Ahhh, users. At once the reason and bane of a system administrator’s
existence. Many times, an administrator simply wants to know what a user
is running. There are various legitimate reasons for this. Maybe they’re
hogging resources, and you’re trying to detect whether it could’ve been
prevented or if it’s an out-of-control, endlessly forking, buggy script
that’s taken over. You may not always be privy to how the programs
work, either. On a development server, you may not even recognize the name of
the application, or know where it lives or what it does. There are
a number of utilities that can help you figure out where all of your CPU cycles are going, but why not use the same old command you’ve used for decades?

Turns out, the old ps command has a couple of flags
that, when used together, can help you understand what’s going on. The
-F flag (not available on all distros) provides an even
fuller listing than the -f flag, and the -H
flag shows the processes hierarchically, showing the parent and child
relationships among the processes. Put these together with -u
user, and you have a pretty complete picture of what a user is running. Try running ps -FHu username next
time you’re in this position.

The case of the missing scanner

I’ve made a habit of using nmap to double-check my work
after a new installation, to make sure I haven’t left any ports open,
and to check that I know what any open ports are being used for.
However, many distros don’t install nmap by default. You
still have a few quick options, though. For one,
netstat has three flags I often use together to list TCP
ports (specified with -t) that are in a listening state
(specified with a -l. To keep the ports from being
translated into a service name, I usually use -n. Note
here that while using netstat -lnt will list all listening
ports, dropping the -l will list all established
connections (as well as those in other states like CLOSE_WAIT or
TIME_WAIT). Play with these on a busy machine!

Another option you can use is lsof‘s -i
flag (NOTE: on some systems, this flag requires you to be root). By
itself, lsof -i will show you established connections as
well as listening ports. However, this flag has some less obvious
functionality that’s also pretty handy. For example, to see all outbound
established TCP connections, try running lsof
-iTCP@hostname. Similarly, replacing hostname with
the name of a remote host shows you the connections from the local
machine to that host.

The flag that isn’t a flag

The last flag, which I constantly forget about, is the
shutdown command’s time argument. I forget it a lot
because the shutdown command in general is different on the various Unix
flavors I administer. Hopefully writing it will help me remember and
give everyone a reminder at the same time. Running shutdown -h
15 on a Linux system will halt the machine 15 minutes from the
time the command is run, and issue a warning every minute until then.
This is not to be confused with the -t flag, whose meaning
is slightly ambiguous to me and others I’ve asked (input hereby
solicited!).

In closing

This week I hope I’ve given you at least one new command flag that you
find useful. Share your own little morsels with the rest of us by posting your favorite “power flags” as comments to this article. I hope I’ve also shown how sifting through manpages on your
lunch hour can be of great benefit to your career!