I understand that many of you don’t want to use the command line in Linux (or in any operating system, for that matter). But the truth is, to be a good administrator, you have to know the command line. Why? Well, with Windows there are times when the command line is the only thing that can save your skin. With Linux, the command line is vast, reliable, flexible, fast… I could go on and on.
And of the 2,119 possible commands from the /usr/bin directory (in Mandriva Spring 2008) and the 388 possible commands from /usr/sbin/, a few are indispensable. Here are 10 of them that might make your Linux admin life — or your introduction to Linux — a whole lot simpler.
I could make this easy and go with the most used commands (cd, ls, rm, etc — okay, etc isn’t a command, but you get the point). But instead, I am going to go with the most useful commands, and I’ll keep it as distribution-neutral as I can.
#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 auxgrep 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 auxgrep 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).
Can’t live without ‘em
These 10 Linux commands make Linux administration possible. There are other helpful commands, as well as commands that are used a lot more often than these. But the commands outlined here fall into the necessity category. I don’t know about you, but I don’t go a day without using at least half of them.
No comments:
Post a Comment