scripts

LAMP stack story overlooks impact of cloud, reader says

My recent story on the dimming of the LAMP stack sparked a thoughtful reader response from John Locke, the manager of Seattle-based Freelock Computing. The story concluded that while an all-open source stack is still a valid concept, there are many more open source options that LAMP (Linux, Apache, MySQL and Perl, Python, PHP) is largely irrelevant.  I made a single exception for Apache, the popular Web server.

Locke argued, however, that even Apache has a growing array of alternatives such as the Lighttpd Web server, the Apache FastCGI Web interface,  the Nginx proxy server and others.

But what undercuts the LAMP stack more than the advent of additional open source options is the emergence of cloud frameworks, Locke said.

Initially, cloud computing meant renting compute power on demand from the likes of Amazon Elastic Compute Cloud (EC2). This meant renting a host virtual machine, programming the top layer, adding libraries and then when it was all done, managing the host and the virtual application, Locke said.

The problem with this model is that data centers are responsible for scaling the application up or down in response to changing volume requirements, he said. To solve this problem, Google, as well as Microsoft’s recently announced Azure platform, go beyond computing-on demand and manage the entire process with frameworks. All you do is write the application code (yes, you still need the P in LAMP), put it atop an application framework, and the framework will scale the application up and down as needed. No further involvement required. No LAMP stack required either.

Two successful examples of cloud frameworks are Salesforce.com and Facebook, he said.

The downside of frameworks, however, are loss of control and potential vendor lock-in, Locke said. The risk is less with Amazon EC2 since its controls are far more limited, he said. When writing an application for a specific vendor’s framework, however, a customer can lose portability because the provisioning and scaling mechanisms are behind-the-scenes and the source code and licensing are not necessarily readily available, he said.

The biggest challenge to LAMP as well as the Java and .NET stacks, therefore, is not the growth of additional choices but the cloud frameworks which may make all the stacks irrelevant. While handing over management and control is convenient, it also has its downside: you have to live by someone else’s rules, Locke said. Just  like a condo or regulated housing community, you’ve delegated the work, but you’ve also lost your freedom. Time will tell if you’ve made a good bet.

More Linux commands for your scripting pleasure

One of our users, James Lowden, emailed us to say that our recent 77 useful Linux commands and utilities guide missed a couple of his favorites:

I’m a NetBSD guy, but I have RHEL at work.

As for commands, I like:

1. pax better than tar

2. hexdump better than od

3. tnfpt better than wget

Pax has a much better command-line interface than tar, especially for copying trees. Consider:

$ pax -rw -pe src dest # to copy a tree

$ pax -wzf file.pax.gz src # to create and archive

hexdump -C is what you almost always want.

Tnftp (a port of the NetBSD FTP client to other systems) is a much saner way to fetch stuff. Why the GNU world focuses on wget instead is a mystery to me. It doesn’t do anything tnftp doesn’t do, and it doesn’t do anything better, either.

If you would like to share your opinions of our essential Linux command guide, feel free to drop us line and share some of your favorite commands with the Enterprise Linux Log.

Script tracks Perl modules for you

Michael Hurley shares a script that he wrote called modlister. I’ll let him explain:

It’s a script to tell you what Perl modules you have installed and where, to query whether you have a particular module installed, to see associated files, etc. For example:

1. 1. List all installed modules:

modlister.pl

Only show filenames (strip directories):

modlister.pl -f

See if Compress::Zlib is installed:

modlister.pl -m Zlib

See all the files associated with Zlib:

modlister.pl -m Zlib -a

Thanks for the script, Michael.

Try this one out yourself. Tell us what you think or submit one of your own. If we use your script, you will receive a gift a Starbucks gift certificate. More scripting goodness after the jump… Continued »

Handy script protects Linux against traffic spikes

We received another user-submitted Linux script for our “Share scripts… win Starbucks” series. This one comes from David Witham, who writes:

I administer a consumer VoIP switch for a VSP. The switch acts as a SIP registrar and proxy. Many thousands of devices register and re-register with the registrar every few minutes so there’s a pretty constant stream of traffic hitting it. Some SIP devices have flakey firmware and misbehave in such a way that they flood the registrar with registration requests to the point that performance is compromised, so I needed a way to protect the registrar from those devices.

I wrote a script that takes a sample of network traffic using Ethereal, checks for IP addresses transmitting excessive packets and blocks them by adding them to a list of addresses to drop in the INPUT chain of iptables.

David suggests running the script every 15 minutes to allow new IP addresses to be added to the list, then flushing the addresses and re-adding them so IP addresses that have stopped flooding can re-register.

Give it a try. This script was optimized for RHEL4 but should run on other Linux and Unix systems that have Ethereal or iptables. Feel free to modify it any way you like, or maybe you have one of your own to share? Share a script with us and, if we use it, we’ll treat you to Starbucks.

Keep the scripts coming!

#!/bin/bash
#
# Run from cron on a frequent basis, including on the hour, to block IP addresses flooding with SIP requests
# Use -f to force a flush of the INPUT chain
#
# First 3 octets of destination IP address of the flooding packets

BASE=xxx.xxx.xxx

# Whole destination IP address of the flooding packets

HOSTIP=xxx.xxx.xxx.xxx

# Interface on which the flooding is occurring

INTERFACE=eth3

# Flush iptables INPUT filter chain each hour in case some IPs have stopped flooding and are genuinely trying to use the service
if [ $(date +%M) = "00" -o "$1" = "-f" ]; then
        /sbin/iptables -F INPUT
        # Wait 5 seconds for IPs to start flooding again (most flooding IPs send REGISTER every 4 seconds if not getting a response)
        sleep 5
        # Add IP address to drop to iptables INPUT filter chain. Repeat a couple of times to catch all IPs
        /usr/sbin/tethereal -i $INTERFACE-a duration:10 2>/dev/null | awk ‘{print $2;print $4}’ | grep -v $BASE | sort | uniq -c | sort -rn | awk ‘$1 > 30 {print $2}’ | while read ip; do /sbin/iptables -A INPUT -s $ip -d $HOSTIP -j DROP ; done
        sleep 5
        /usr/sbin/tethereal -i $INTERFACE-a duration:10 2>/dev/null | awk ‘{print $2;print $4}’ | grep -v $BASE | sort | uniq -c | sort -rn | awk ‘$1 > 30 {print $2}’ | while read ip; do /sbin/iptables -A INPUT -s $ip -d $HOSTIP -j DROP ; done
        sleep 5
        /usr/sbin/tethereal -i $INTERFACE-a duration:10 2>/dev/null | awk ‘{print $2;print $4}’ | grep -v $BASE | sort | uniq -c | sort -rn | awk ‘$1 > 30 {print $2}’ | while read ip; do /sbin/iptables -A INPUT -s $ip -d $HOSTIP -j DROP ; done
else
        # Add more IP addresses to drop to iptables INPUT filter chain
        /usr/sbin/tethereal -i $INTERFACE-a duration:10 2>/dev/null | awk ‘{print $2;print $4}’ | grep -v $BASE | sort | uniq -c | sort -rn | awk ‘$1 > 30 {print $2}’ | while read ip; do /sbin/iptables -A INPUT -s $ip -d $HOSTIP -j DROP ; done

fi 

Does this script work for you?

Recently, we asked our readers to share some of their Linux scripts with us. Our first script comes to us from Diethard Ohrt, who sent us a script named “survf”. He writes:

The script “survf” monitors a file so you can check whether this file is growing (e.g. during ftp transfer). If you link it to the name “survp,” it monitors a running process… when the process terminates it sounds a bell and terminates.

Take a look at survf and give it a try. Diethard adds that he originally wrote it for the Korn shell on a Unix box a few years ago (so you might want to tweak it with “proper, real bash syntax.”)

Thank you, Diethard! To show our appreciation, we are sending you a gift certificate for some Starbucks coffee. Enjoy.

Let us know what you think of the script or send us one of your own. If we use it, you can earn yourself a Starbucks gift certificate plus you’ll be helping out other users.

If you would like some more scripts, check out our tips section. Whether it is help with Linux migrations or managing high-volume CPU processes, our SearchEnterpriseLinux experts help you navigate through the Linux world.

Hope you like the script. Keep them coming.


!/bin/bash