Linux News Today features the latest news from the global Linux community. This site is updated daily. Click here to return to our homepage. Get the lowest cost and the best tech support on any Linux web hosting plan. Click here for details.
                                          home   |   news archives   |   linux forum   |   advertise on our site   |   contact




Install your server in Sun Hosting's modern colocation center in Montreal. Get all the details by clicking here.



Plans begin at $24.95 a month. Get more details, click here.



Promote your company. Reach over 450,000 Linux software developers, Linux users, Web hosting companies, etc. Boost your sales and promote your brand. Read more, click here.



The industry's best and most accurate tool to find out EXACTLY what your CORRECT keywords are. Click here to learn more.

Good advice and tips for Linux administrators, page 3

Add to del.icio.us     Digg this story Digg this

July 24, 2008

(Continued from the previous page)

Tip No. 8: Command-line scripting and similar useful utilities

Any Linux systems administrator becomes a lot more effective by using command-line scripting, but with some authority in it. This includes designing some loops and knowing how to parse data using utilities like AWK, Grep, and even SED. There are many cases where doing so takes fewer keystrokes and lessens the likelihood of user errors, but you get the point.

For instance, let's just suppose that you need to generate a new /etc/hosts file for a Linux cluster that you are about to install on a network. The long (and harder) way would be to add IP addresses in vi or in nano. But it can be done faster by taking the already existing /etc/hosts file and appending the following to it by simply running this on the command line:

# P=1; for i in $(seq -w 200); do echo "192.168.99.$P n$i"; P=$(expr $P + 1);
done >>/etc/hosts

Wow, 200 host names, n001 through n200, will then be created with IP addresses 192.168.99.1 through 192.168.99.200. Populating a file like this by hand runs the risk of inadvertently creating duplicate IP addresses or host names, so this is a good example of using the built-in command line to eliminate user errors. This is a rare case where a computer or server can sometimes be more accurate than a human... Anyway. Please note that this is done in the bash shell, the default in most Linux distributions.

As another example, let's say you want to check that the memory size is the same in each of the computer nodes in the Linux cluster. In most cases similar to this, having a distributed or parallel shell would be the best and most practical method, but for the sake of this illustration, here's a way to do this using SSH:

Assume the SSH is set up to authenticate without a password (rare, but possible). Simply run:

# for num in $(seq -w 200); do ssh n$num free -tm | grep Mem | awk '{print $2}';
done | sort | uniq

A command line such as this looks pretty borring, right? But it can be worse if you put regular expressions in it. Let's take it apart and uncover the mystery here. First you're doing a loop through 001-200. This padding with 0s in the front is done with the -w option to the SEQ command. Then you substitute the num variable to create the host you're going to SSH to.

Once you have the target host, give the command to it. In this case, it's:

free -m | grep Mem | awk '{print $2}'

That command says to: Use the free command to get the memory size in megabytes. Take the output of that command and use grep to get the line that has the string Mem in it. Now take that line and use awk to print the second field, which is the total memory in the node. Then this operation is performed on every node in the network.

Once you have performed the command on every node and in the way depicted above, the entire output of all 200 nodes is piped (|d) to the sort command so that all the memory values are sorted out.

Finally, you can eliminate duplicates with the uniq command. This command will result in one of the following cases:

If all the nodes, n001-n200, have the same memory size, then only one number will be displayed. This is the size of memory as seen by each operating system. If node memory size is different, you will see several memory size values. And if the SSH failed on a certain node, then you may see some error messages.

However, please note that this command isn't perfect. If you find that a value of memory is different than what you expected, you won't know on which node it was or how many nodes there were. Another command may need to be issued for that.

But what this tip does give you is a rapid method to check for something and quickly learn if something is wrong in the system. This is it's real value: Speed to do a quick-and-dirty job of checking.


Tip No. 9: Spying on the console

In Linux, there are times when some specific programs print some strange or unusual error messages to the console that may or may not necessarily show up on your SSH session. Using the vcs devices can let you examine some of these, but it ain't always the best way. From within an SSH session, run the following command on a remote server:

# cat /dev/vcs1

This will show you what is on the first console. You can also look at the other virtual terminals using 2, 3, etc. If a user is typing on the remote system, you'll be able to see what he typed, right then and there.

In most data centers, using a remote terminal server, KVM or even Serial Over LAN (SOL) is the best way to view this information. It also provides the additional benefit of out-of-band viewing capabilities. Using the vcs device provides a fast in-band method that may be able to save you some time from going to the DC and looking directly at the console.


Tip No. 10: Vital system information collection done at random

In one of the tips depicted above, we showed you an example of using the SSH command line interface to get information about the total memory in the system. In this tip, we will offer a few additional methods to collect important and vital information from the server you may need to verify, troubleshoot or offer remote support.

Before we begin, let's gather some basic information about the CPU. This is easily done as follows:

# cat /proc/cpuinfo

That command will give you exact information on the processor manufacturer (Intel or AMD), speed, quantity and specific model and version number. Also, using grep in many cases can give you the desired value as well.

A check that some admins do sometimes is to ascertain the exact quantity of CPUs on the server. If a company has purchased a dual processor quad-core server, you can run:

# cat /proc/cpuinfo | grep processor | wc -l

You would then expect to see 8 as the value, since a dual CPU stands for a quantity of 2, and the quad designation is viewed by the above test as a multiplier of 4, hence the correct answer back has to be 8. In the above test, if you don't get 8 as the final answer, then call up the server vendor and tell them to send you another processor, or better still, a whole new motherboard!

Another piece of vital information that system admins often require is disk capacity information. As many of you probably are already aware, this can be had with the df command. It's a good idea to add the -h flag so that you can see the output in gigabytes or megabytes. The # df -h command also will show you how the disk was partitioned when the server was originally setup in the first place.

Also, if ever you need to check the BIOS version of your server, you can simply run the dmidecode command. However, you won't be able to easily grep for the information, so piping it is a less efficient way to do this. Here's the command:

#dmidecode | less
...
BIOS Information
Vendor: DELL
Version: D7A66KF23 (1.02 )
Release Date: 03/16/2006
...

This method is better than rebooting your server and looking at the POST output. To look at the driver and firmware versions of your Ethernet adapter, just run the ethtool command:

# ethtool -i eth0
driver: e1000
version: 7.3.20-k2-NAPI
firmware-version: 0.3-0

So there you have it folks! There are literally tons of good tips you can learn from someone's who's a pro at the SSH command line interface. It's also a good idea to read the man pages. Reading man pages, even on commands you already know can provide additional insights into the Linux kernel.

(Continued from the previous page)

Source: The Web Hosting Forum.

Add to del.icio.us     Digg this story Digg this

Article featured on Tech Blog and on Business 5.0

This article was featured on Tech Blog and Business 5.0.











ADVERTISERS:
Linux News Today.org is read by over 450,000 people involved in the field of Linux application development, professional Web hosting services, Linux security, Linux Web development, etc. Inquire about our reasonable advertising rates on our news website. One of our advertising representatives will be in touch with you. Simply email us to learn about our ad rates and how we can help drive relevant traffic to your website. Advertising space is limited.



                      Site powered by Linux Hosting            Sponsored by DMZ eMail, by Sun Hosting and by MWD            Linux news while they are still fresh.    © Linux News Today.org