Mistakes A Noob Makes In Vim

From codeulate.com

A noob uses the arrow keys.
The First Commandment of vim is “Thou shalt not use the arrow keys, for they be too far from thy holy home row. Use instead the blessed h, j, k and l.”

A noob does not know his motions.
When a noob deletes a word, he holds ‘x’.

When a master deletes a word, he taps ‘dw’.

A noob should learn the motions granted him by w, i, t, f, and a. His practice would be guided well by the writings in ‘:help motion.txt’

A noob does not know the ‘.’ command.
And great is his needless suffering.

A noob does not record macros.
A master’s q key is well-worn.

A noob writes Rails code with vim, unaware of this screencast.
A master does not hesitate to share his awesome content.

Change username or UserID/uid on Linux

From linuxers.org

Usermod is a useful command to manage user settings. It modifies the system account files to reflect the changes that are specified on the command line. It is capable of doing a lot of things, but here we will see how to change username and UserID or uid on Linux using usermod.

Change the username using Usermod

The command syntax is simple:

[root]# usermod -l new_username old_username

The above command only changes the username, nothing else is done. So, its a good practice to manually change the user home directory to reflect the change.

[root]# mv /home/old_username /home/new_username

Change the UID/UserID using Usermod

Here’s the syntax.

[root]# usermod -u UID username

Please note that, UID 0-999 are reserved for system accounts and should not be used. The above command will change the ownership of all the content owned by the user in his home directory; stuff outside the home directory needs to be manually fixed.

For more information, take a look at usermod’s manpage.

New apache tomcat server 7.0

The Apache Software Foundation (ASF) has announced Version 7.0 release of Apache Tomcat, the popular open-source Java web server. Tomcat 7.0 is the first major release of the software since 2006.

Apache Tomcat 7 is the project’s first major release since 2006, fully implementing the Java Servlet 3.0, JavaServer Pages (JSP) 2.2, and Expression Language (EL) 2.2 specifications for easier Web framework integration. One of the ASF’s earliest projects, the Tomcat code base was first donated to the ASF in 1999; the first Apache release, v.3.0, was made later that year.

Tomcat 7 makes it simpler to write and deploy complex Web applications, providing out-of-the-box support for development features that would otherwise be coded manually.

Developers using Tomcat 7 also will benefit from improved memory leak detection and prevention and support for ‘aliasing’ directories into an application’s URL space. All known bugs reported in previous versions of Tomcat have been fixed in v.7.0.

Apache is an all-volunteer group that serves as developers, stewards, and incubators of 143 open source projects and initiatives. Apache Tomcat is shepherded by dozens of volunteers who contribute updates to its code base; its day-to-day operations, including community development and product releases, are overseen by a project management committee.

“Developers can rely on Tomcat 7 for faster, more reliable application development and integration, providing both a better user experience and better use of server resources,” said Mark Thomas, a member of the Apache Tomcat Project Management Committee.

With more than 10 million downloads to date, Apache Tomcat powers a broad range of websites.

“MuleSoft applauds the Apache Tomcat team on the release of Tomcat 7,” said Ross Mason, founder and CTO of MuleSoft, in a statement. “The improvements in this new release leverage advances in Java, including the Servlet 3 specification, significantly improving the lives of the world’s Web application developers. This release includes more than 10 years of active community development effort, continuing Tomcat’s lead as the best Java web application server to power the enterprise.”

“I am delighted to see this first release of Apache Tomcat 7,” said Rod Johnson, general manager of the SpringSource division of VMware. “Tomcat has always been the most popular deployment platform for Spring-based applications and this new release adds some great production technology. Tomcat’s small footprint and reliable execution make it the ideal choice for the runtime component of SpringSource’s tc Server. These features are also proving particularly important as organizations move their workloads to the cloud.”

Tomcat versions 5.x and 6.x will continue to be supported; however, bug fixes or updates to possible security vulnerabilities in earlier versions may be slightly delayed.

Tomcat 7 is released under the Apache Software License v2.0. Downloads, documentation, and related resources are available at http://tomcat.apache.org/.

Changelog is here…

How linux start up scripts work

From wiki.clug.org.za


If you are coming from a Windows environment, the way that GNU/Linux starts up may seem very confusing. Just like Windows, Linux has several places where start-up scripts and actions can be stored. The methods used in Linux though, are more structured and organised, and once you get the hang of it, it’s real easy to understand as well.


Chances are, you’re using an external bootloader such as LILO or GRUB to boot your Linux distribution. Settings such as your default runlevel, and other boot options, are sometimes specified in your boot loader. The default runlevel is specified in /etc/inittab.

The bootloader can be installed to the master boot record of a disk, or to a specific partition on your disk. This means that you can use one boot loader as your main boot loader, and link to other boot loaders to your disk. Dual booting is achived this way, since most operating systems are capable of writing their bootloaders to the partition it is installed on.

The bootloader will load your kernel (and an initial ramdisk, if needed), and specify to the kernel which partition to use as the root partition. The kernel will then initiate a program called “Init”, which will continue the boot process.

Init, the mother of all processes

In GNU/Linux, every program you run acts as a process. Each process may have sub-processes, and parent processes. Each process has a unique I.D. by which it can be identified. Init is usually the first process started by the Linux kernel, and will have a process ID of “1”. Each process started by Init, will be a child process of init. Killing Init will kill all child processes, and will result in a kernel panic.

Init will then take a peek at /etc/inittab, to find out how it should boot your system. If you specified your own options at boot time, it will override the settings in inittab.

If you remember the MS-DOS days, you’ll remember that DOS started up with one script, called AUTOEXEC.BAT. In GNU/Linux, there are several different paths that you can choose when booting up. These are called runlevels, which also control the shut-down and reboot sequences.


You may have up to 9 runlevels on your system. Most distribution has 6 runlevels configured in the inittab file.

    Runlevel 0 is used to shut down the system.

    Runlevel 1 boots up in single user mode, with no networking

    Runlevel 2 is the default for Debian based systems, and gives full multi-user-system and the X-window system (if configured). On some systems, runlevel 2 is configured to be single user mode with networking

    Runlevel 3 is often used on many distributions for booting to a multi-user console without the X-window system

    Runlevel 4 is usually reserved for custom user runlevels

    Runlevel 5 is often used on many distributions for full multi-user-system with the X-window system.

You can assess the current runlevel by typing “runlevel” inside a terminal window or from a console:

me@clug ~ $ runlevel
N 2

The first character shows your previous runlevel. The second character shows your current runlevel. The N suggests that you weren’t previously in another runlevel. The “2” means that you are in runlevel 2.

You can change runleve by using the “init” command. You need to be root or run with sudo to change runlevel.

root@clug ~ # init 0
System is going down for reboot NOW!

Runlevel 0 is used for shutting down your system. Changing to this runlevel will have the same effect as running “halt”. Similarly, typing “init 6” will have the same effect as “reboot”.

The default runlevel your system boots in is specified in the /etc/inittab file:

# The default runlevel.

In this example, the default runlevel is runlevel 2.

On most GNU/Linux systems, the startup scripts are stored in “/etc/init.d”. On some systems, this might be at “/etc/rc.d/init.d”, or just “/etc/rc.d”.

Many scripts need to run regardless of the runlevel you choose. These scripts will all be run from “/etc/rcS.d”, and is specified in the inittab by:

Some files from /etc/rcS.d:

You may notice that these aren’t physical scripts stored in this directory. Instead, they are symbolic links (shortcuts) to the real files stored in “/etc/init.d”. The “S” at the beginning of the filename is short for “start”, and means that this service should be running in this runlevel. In the shutdown runlevel, most of the filenames will start with a “K”, which is short for kill, which means that services should be stopped in this runlevel. The numbers next to the “S” is the order in which the scripts should run. ntpdate, for instance, is a program that syncs your computers system date over the Internet. It won’t work unless your networking is up, so it needs to run after your networking is activated. You can also run several scripts in parrallel, by making the scripts start at the same time by giving them the same numbers.

If you’d like to add a script to a runlevel, for instance, let’s say I want my webserver to start when I boot into runlevel 2, I can use “ln -s” to create a symbolic link to “/etc/rc2.d”.

ln -s /etc/init.d/apache2 /etc/rc2.d/S91apache2
In the example above, apache will start after all other processes in runlevel 2.

If I would want apache2 to stop when switching to runlevel 3, I can also do it by creating a symbolic link:

ln -s /etc/init.d/apache2 /etc/rc3.d/K05apache2
When the symlink starts with an “S”, the script is called with the parameter “start”, and if it starts with a “K”, the parameter is “stop”. The K05apache2 above will have the same effect in runlevel 3 as:

/etc/init.d/apache2 stop

Runlevel Editors

For those who do not want to do it by hand:

    YaST (on SUSE Linux)
    sysv-rc-conf (text based tick-box editor)
    chkconfig (Red Had based systems)
    ksysv (Graphical editor)

Other start-up scripts


Most shells also have scripts that start up when you log in. These scripts will typically set some shell settings, such as they way your prompt looks, start programs, and other useful tools, such as programmable bash auto-completion.

In Bash, the most commonly used shells in Linux distributions, this file is called “.bashrc”, and can be found in your home directory. Edit this file to manipulate what happens when you start Bash.

You can also edit “/etc/bash.bashrc” to edit the Bash startup settings for all users. “/etc/profile” can be used for initial settings for all Bourne-like shells (bash, ksh, ash, etc)


Just like Bash, there are certain scripts that are run each time you log into an X session. These scripts are stored in “/etc/X11/Xsession.d/”. Scripts are executed in numerical order from 1st to last.

Pam sessions

PAM is an acronym for Pluggable Authentication Module. Pam manages four types of verification: authentication, account, session and password. A pam aware application will have a small stub configuration in /etc/pam.d. This configuration can specify session modules which may perform certain functions whenever you start a new session.

Logging in usually starts a new session. Common tasks performed at login time is to check if you have mail and print a message informing you if you do (pam_mail.so).

Further Reading

Init manual page: man 8 init
inittab maual page: man 5 inittab

Getting the most from your bash history

From serverwatch.com

Type history at the Bash command prompt, and you’ll get a list of your previous commands. You can navigate through these with the up and down arrows, but there are other ways of interacting with them that I’ve been investigating this week. One straightforward option is to use the number at the start of the line to refer to the command. So,

> !15268

will execute the line numbered 15268.
executes the last command, and
will execute the last-but-two command.

You can edit previous commands quickly using :s///. For example, if you typed ‘temp’ when you meant ‘tmp’ in command 15200, use this to correct it:
To do this, edit with the previous command, use
or the shortcut

Using the g global modifier changes every occurrence of the word, not just the first one:


You can also edit a block of commands. Let’s say you executed a series of commands, between numbers 1478 and 1482, with a particular value, and want to edit them all. (Maybe you did a series of things to a file or a directory, and now want to repeat the sequence with another file.) Use this command:

fc 1478 1482

The lines will be opened up in your preferred editor, where you can edit them, save and exit, and they’ll be run (as edited) immediately. (And then added, in their edited form, to your history!)

Check out the bash manual for more things you can do with the history.

Automatically recover Tomcat from crashes

From vineetmanohar.com

Tomcat occasionally crashes if you do frequent hot-deploys or if you are running it on a machine with low memory. Every time tomcat crashes someone has to manually restart it, so I wrote a script which automatically detects that tomcat has crashed and restarts it.

Here’s the pseudo logic:

every few minutes

check tomcat status;

if (status is "not running") {
start tomcat;

Here’s a shell script to implement the above logic. It assumes that you are running on a unix/linux system and have /etc/init.d/tomcat* script setup to manage tomcat.

Adjust the path to “/etc/init.d/tomcat” in the script below to reflect the correct path on your computer. Sometimes it is called /etc/init.d/tomcat5 or /etc/init.d/tomcat6 depending on your tomcat version. Also make sure that the message “Tomcat Servlet Container is not running.” matches with the message that you get when you run the script when tomcat is stopped.

#! /bin/sh
STOPPED_MESSAGE="Tomcat Servlet Container is not running."

if [ "`$SERVICE status`" == "$STOPPED_MESSAGE"];
$SERVICE start

To run the script every 10 minutes:

  • 1. Save the above script to “/root/bin/recover-tomcat.sh”.

    2. Add execute permission:

  • chmod +x /root/bin/recover-tomcat.sh

    3. Add this to root’s crontab, type the following as root:

    crontab -e

    4. Add the following lines to the crontab:

    # monitor tomcat every 10 minutes
    */10 * * * * /root/bin/recover-tomcat.sh

    What if I don’t have /etc/init.d/tomcat* script on my computer?

    Tomcat creates a pid file, typically in the TOMCAT_HOME/bin directory. This file contains the process id of the tomcat process running on the machine. The pseudo logic in that case would be:

    if (the PID file does not exist)

    // conclude that tomcat is not running
    start tomcat
    else {
    read the process id from the PID file
    if (no process that id is running) {
    // conclude that tomcat has crashed
    start tomcat

    You can implement the above logic as follows. The following is experimental and is merely a suggested way, test it on your computer before using it.

    # adjust this to reflect tomcat home on your computer

    if [ -f $TOMCAT_HOME/bin/tomcat.pid ] then
    echo "PID file exists"
    pid="`cat $TOMCAT_HOME/bin/tomcat.pid`"
    if [ "X`ps -p $pid | awk '{print $1}' | tail -1`" = "X"] then
    echo "Tomcat is running"
    echo "Tomcat had crashed"
    echo "PID file does not exist. Restarting..."

    Why would tomcat crash?

    The most common reason is low memory. For example, if you have allocated 1024MB of max memory to tomcat and enough memory is not available on that machine. Other reasons may involve repeated hot-deploys causing memory leaks, rare JVM bugs causing the JVM to crash.


    boomerang always comes back, except when it hits something.


    This piece of javascript measures a whole bunch of performance characteristics of your user’s web browsing experience. All you have to do is stick it into the bottom of your web pages and call the init() method.

    We’ll make it more complicated later.

    Documentation is in the docs/ directory, it’s all HTML, so your best bet is to check it out and view it locally, though it works best through a web server (you’ll need cookies). I periodically check out a copy of the docs here

    Removing ASSP X

    If you want to uninstall ASSP X, run the following in order from the command line on the server:
    /bin/rm -fv /usr/local/cpanel/whostmgr/docroot/cgi/addon_asspx.cgi
    /bin/rm -fv /usr/local/cpanel/whostmgr/docroot/cgi/asspxversion.txt
    /bin/rm -Rfv /usr/local/cpanel/whostmgr/docroot/cgi/asspx/
    /bin/rm -fv /usr/local/cpanel/3rdparty/asspx
    /bin/rm -fv /etc/cron.d/assp
    /etc/init.d/crond reload
    /etc/init.d/assp stop
    /bin/rm -fv /etc/init.d/assp
    /bin/rm -Rfv /usr/local/assp
    /bin/rm -Rfv /usr/local/asspx
    /bin/rm -Rfv /etc/chkserv.d/assp*

    For cPanel 11 unregister ASSP X plugin:
    /usr/local/cpanel/bin/unregister_cpanelplugin /usr/local/cpanel/bin/asspx.cpanelplugin;
    /bin/rm -fv /usr/local/cpanel/bin/asspx.cpanelplugin;

    Also make sure ‘local_interfaces’ & daemon_smtp_ports variables at exim.conf removed and SpamAssassin/Boxtrapper installed if needed.
    When you have Exim ports changed back, execute (ignore not found errors if any):
    replace '[exim]=125' '[exim]=25' -- /etc/chkserv.d/exim
    /etc/init.d/chkservd restart
    replace 'socket_port=125' 'socket_port=25' -- /usr/local/sim/modules/init/exim.mod
    replace 'SMTPPORT = 125' '' -- /usr/local/cpanel/3rdparty/mailman/Mailman/mm_cfg.py

    Remove line “/usr/local/assp/scripts/assppostupcp” from /scripts/postupcp
    vim /scripts/postupcp
    Finally execute cPanel update to clean up all ASSP changes:
    /scripts/upcp --force

    Storm On Demand Declared Best Cloud Computing Service

    Storm On Demand Declared Best Cloud Computing Service by Independent Analyst
    Storm On Demand more powerful and less expensive than Amazon EC2!

    LANSING, Mich., June 23, 2010 /PRNewswire via COMTEX/ — On Monday Cloud Computing analyst, www.CloudHarmony.com, completed their fourth round of benchmark testing of Cloud Computing platforms. This round of testing was focused on Memory IO. Five Storm On Demand Servers topped the list and outperformed Amazon EC2 and Rackspace Cloud.

    On June 1st, Cloud Harmony conducted a round of benchmarking that was specifically focused on raw CPU Power. Cloud Harmony determined that Storm On Demand 48GB Cloud Server was the top performing server and when compared to Amazon EC2, Storm On Demand was 57% faster at nearly half of the cost! Cloud Harmony benchmarked more than 150 different cloud server configurations and more than 20 cloud computing companies. http://StormOnDemand.com

    Cloud Harmony results:

    Storm On Demand “by far the most diverse heterogeneous infrastructure.”

    “Storm’s 48GB cloud server was the top performer out of all of our benchmarked servers with 42.5 CCUs and a Geekbench score of 13020! This is most likely due to the very new and extremely fast Xeon X5650 ‘Westmere’ hardware it runs on.”

    The top performers in the Memory IO benchmark category were Storm on Demand (6 servers with scores 116 and above), and EC2.

    Benchmark Methodology Used by Cloud Harmony:

    All benchmarked cloud servers were configured almost identically using CentOS 64-bit. To compute the score, the results from each of the 7 benchmarks on the baseline server are compared to the same benchmark results for a cloud server. The baseline server benchmark score represents 100% for each benchmark. If a cloud server scores higher than the baseline it receives a score higher than 100% (based on how much higher the score is) and vise-versa for a lower score.


    Media (http://StormOnDemand.com/cloud-hosting/about/media.html)

    About Storm On Demand – Cloud Computing (http://www.StormOnDemand.com)

    Storm On Demand is a proprietary cloud computing platform and server hosting infrastructure developed by Liquid Web Inc’s software development staff. Storm On Demand makes it quick and easy to deploy and manage cloud servers from within a web browser. Storm features include instant server setup, utility style hourly billing, ability to clone server images, easy server scaling and complete backup/restoration capabilities. Storm On Demand is a wholly owned subsidiary of the managed hosting company Liquid Web Incorporated that was founded in 1997. Storm servers are deployed within Liquid Web’s 90,000 square foot state-of-the-art Cloud Data Center in the mid-western United States. Storm servers are backed by the engineering and support services of the Liquid Web Heroic Support team which is on site and available 24x7x365.

    Force inactive user logout

    From linuxers.org

    When you work on different servers from your system, the sessions are scattered over various terminals across different workspaces. Its a common mistake people usually make by leaving one or more of those server sessions open. Such sessions can lead to bad things if they get in hands of someone else. So, instead of blaming the user its always a good practice for sysadmins to automatically logout a user who is inactive for quite sometime.

    So, its a good idea to add a TimeOut after which a user will be automatically logged out of the system.

    You can add it to your .bash_profile or .profile (for a specific user) OR you can add it to /etc/profile or /etc/bashrc for all system users.

    [root]# vim /etc/profile


    This will logout a user if he/she is inactive for 10 min.

    NOTE: This won’t work in case of GUI, its a level 2, 3 setting. For a GUI environment, you can use any auto-lock system. Also it wont work if you have any application running, for example – an open document.