#1: top
I figured it was fitting to put the top command at the top.
Although top is actually responsible for listing currently running
tasks, it is also the first command Linux users turn to when they need
to know what is using their memory (or even how much memory a system
has). I often leave the top tool running on my desktop so I can keep
track of what is going on at all times. Sometimes, I will even open up a
terminal (usually aterm), place the window where I want it, and then
hide the border of the window. Without a border, the terminal can't be
moved, so I always have quick access to the information I need.
Top is a real-time reporting system, so as a process changes, it will
immediately be reflected in the terminal window. Top does have some
helpful arguments (such as the -p argument, which will have top monitor
only user-specified PIDs), but running default, top will give you all
the information you need on running tasks.
#2: ln
To many administrators, links are an invaluable tool that not only
make users lives simpler but also drastically reduce disk space usage.
If you are unaware of how links can help you, let me pose this simple
scenario: You have a number of users who have to access a large
directory (filled with large files) on a drive throughout the day. The
users are all on the same system, and you don't want to have to copy the
entire directory to each user's ~/ directory. Instead, just create a
link in each user's ~/ directory to the target. You won't consume space,
and the users will have quick access. Of course when spanning drives,
you will have to use symlinks. Another outstanding use for links is
linking various directories to the Apache doc root directory. Not only
can this save space, it's often advantageous from a security standpoint.
#3: tar/zip/gzip
Tar, zip, and gzip are archival/compression tools that make your
administrator life far easier. I bundle these together because the tools
can handle similar tasks yet do so with distinct differences (just not
different enough to warrant their own entry in this article). Without
these tools, installing from source would be less than easy. Without
tar/zip/gzip, creating backups would require more space than you might
often have.
One of the least used (but often most handy) features of these tools
is the ability to extract single files from an archive. Now zip and gzip
handle this more easily than tar. With tar, to extract a single file,
you have to know the exact size of the file to be extracted. One area
where tar/zip/gzip make administration simple is in creating shells
scripts that automate a backup process. All three tools can be used with
shell scripts and are, hands down, the best, most reliable backup tools
you will find.
#4: nano, vi, emacs
I wasn't about to place just one text editor here, for fear of
stoking the fires of the "vi vs. emacs" war. To top that off, I figured
it was best to throw my favorite editor -- nano -- into the mix. Many
people would argue that these aren't so much commands as they are
full-blown applications. But all these tools are used within the command
line, so I call them "commands." Without a good text editor,
administering a Linux machine can become problematic.
Imagine having to attempt to edit /etc/fstab or /etc/samba/smb.conf
with OpenOffice. Some might say this shouldn't be a problem, but
OpenOffice tends to add hidden end-of-line characters to text files,
which can really fubar a configuration file. For the editing of
configuration or bash files, the only way to go is with an editor such
as nano, vi, or emacs.
#5: grep
Many people overlook this amazingly useful tool. Grep prints lines
that match a user-specified pattern. Say, for instance, that you are
looking at an httpd.conf file that's more than 1,000 lines long, and you
are searching for the "AccessFileName .htaccess" entry. You could comb
through that file only to come across the entry at line 429, or you can
issue the command grep -n "AccessFileName .htaccess" /etc/httpd/conf/http.conf. Upon
issuing this command you will be returned "439:AccessFileName
.htaccess" which tells you the entry you are looking for is on, surprise
of all surprises, line 439.
The grep command is also useful for piping other commands to. An example of this is using grep with the ps
command (which takes a snapshot of current running processes.) Suppose
you want to know the PID of the currently crashed Firefox browser. You
could issue ps aux and search through the entire output for the Firefox entry. Or you could issue the command ps aux|grep firefox, at which point you might see something like this:
jlwallen 17475 0.0 0.1 3604 1180 ? Ss 10:54 0:00 /bin/sh /home/jwallen/firefox/firefoxjlwallen 17478 0.0 0.1 3660 1276 ? S 10:54 0:00 /bin/sh /home/jlwallen/firefox/run-mozilla.sh /home/jlwallen/firefox/firefox-bin jlwallen 17484 11.0 10.7 227504 97104 ? Sl 10:54 11:50 /home/jlwallenfirefox/firefox-bin jlwallen 17987 0.0 0.0 3112 736 pts/0 R+ 12:42 0:00 grep --color firefox
Now you know the PIDs of every Firefox command running.
#6: chmod
Permissions anyone? Linux administration and security would be a
tough job without the help of chmod. Imagine not being able to make a
shell script executable with chmod u+x filename. Of course it's
not just about making a file executable. Many Web tools require certain
permissions before they will even install. To this end, the command chmod -R 666 DIRECTORY/
is one very misused command. Many new users, when faced with
permissions issues trying to install an application, will jump
immediately to 666 instead of figuring out exactly what permissions a
directory or folder should have.
Even though this tool is critical for administration, it should be
studied before jumping in blindly. Make sure you understand the ins and
outs of chmod before using it at will. Remember w=write, r=read, and
x=execute. Also remember UGO or User, Group, and Other. UGO is a simple
way to remember which permissions belong to whom. So permission rw- rw-
rw- means User, Group, and Other all have read and write permissions. It
is always best to keep Other highly restricted in their permissions.
#7: dmesg
Call me old-school if you want, but any time I plug a device into a
Linux machine, the first thing I do is run the dmesg command. This
command displays the messages from the kernel buffer. So, yeah, this is
an important one. There is a lot of information to be garnered from the
dmesg command. You can find out system architecture, gpu, network
device, kernel boot options used, RAM totals, etc.
A nice trick is to pipe dmesg to tail to watch any message that comes to dmesg. To do this, issue the command dmesg | tail -f
and the last few lines of dmesg will remain in your terminal. Every
time a new entry arrives it will be at the bottom of the "tail." Keep
this window open when doing heavy duty system administration or
debugging a system.
#8: kill/killall
One of the greatest benefits of Linux is its stability. But that
stability doesn't always apply to applications outside the kernel. Some
applications can actually lock up. And when they do, you want to be able
to get rid of them. The quickest way to get rid of locked up
applications is with the kill/killall command. The difference between
the two commands is that kill requires the PID (process ID number) and
killall requires only the executable name.
Let's say Firefox has locked up. To kill it with the kill command you would first need to locate the PID using the command ps aux|grep firefox command. Once you got the PID, you would issue kill PID (Where PID is the actual PID number). If you didn't want to go through finding out the PID, you could issue the command killall firefox (although in some instances it will require killall firefox-bin). Of course, kill/killall do not apply (nor should apply) to daemons like Apache, Samba, etc.
#9: man
How many times have you seen "RTFM"? Many would say that acronym
stands for "Read the Fine* Manual" (*This word is open for variation not
suitable for publication.) In my opinion, it stands for "Read the Fine
Manpage." Manpages are there for a reason -- to help you understand how
to use a command. Manpages are generally written with the same format,
so once you gain an understanding of the format, you will be able to
read (and understand) them all. And don't underestimate the value of the
manpage. Even if you can't completely grasp the information given, you
can always scroll down to find out what each command argument does. And
the best part of using manpages is that when someone says "RTFM" you can
say I have "RTFMd."
#10: mount/umount
Without these two commands, using removable media or adding external
drives wouldn't happen. The mount/umount command is used to mount a
drive (often labeled like /dev/sda) to a directory in the Linux file structure. Both mount and umount take advantage of the /etc/fstab file, which makes using mount/umount much easier. For instance, if there is an entry in the /etc/fstab file for /dev/sda1 that maps it to /data, that drive can be mounted with the command mount /data. Typically mount/umount must have root privileges (unless fstab has an entry allowing standard users to mount and unmount the device). You can also issue the mount command
without arguments and you will see all drives that are currently
mounted and where they're mapped to (as well as the type of file system
and the permissions).
No comments:
Post a Comment