Five Flags You Completely Forgot About
ls. So I've done the geeky work for you, and now I present "Five flags you completely forgot about."
Scrap your scripts:
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:
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
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
-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!).
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!