Linux Blog

Asterisk AGI IP Address lookup

Filed under: General Linux — TheLinuxBlog.com at 12:01 am on Sunday, September 19, 2010

While not exactly a shell script, I figured it would be worthy to post something rather than nothing and technically it is a script none-the-less.
I was experimenting with Asterisk AGI scripts and needed a project. I decided that an IP address lookup would be a good one. Sometimes my dynamic IP changes but my dynamic DNS doesn’t update. With this script, I should be able to dial into my Asterisk machine and get it to tell me the IP address. At least, that’s the plan.

(Read on …)

A Manpage Template for your Scripts

Filed under: Shell Script Sundays — TheLinuxBlog.com at 11:44 am on Sunday, June 21, 2009

So, you just finished that killer script and the first thing you want to do is write that man page for it right? Not exactly? What do you mean?
Writing a man page isn’t that hard and will give your users an idea of how to use a script.

Here is a basic template for creating your own man pages:

.\" This is a comment
.\" Contact Owen@thelinuxblog.com
.TH man 1 "21 June 2009" ".1" "Man Page Example"
.SH NAME
Man \- Example Man Page
.SH SYNOPSIS
Example Man Page
.SH DESCRIPTION
This is an example of a man page.
.SH OPTIONS
No options for this man page
.SH SEE ALSO
man(1), groff(1), man.config(5)
.SH BUGS
No known bugs for this template, except you might want to replace the quotes if you copy from my blog.
.SH AUTHOR
Owen (owen@thelinuxblog.com)

When you’re done with the gruelling task of writing documentation (which your users won’t read or thank you for) just plop it the correct man section in /usr/share/man
That’s all there is to it!

Using a custom Tomcat on Fedora

Filed under: Quick Linux Tutorials — TheLinuxBlog.com at 10:22 am on Wednesday, November 12, 2008

So, I hear you need to use Tomcat on Fedora eh? Not happy with the available Tomcat version from the repository? Well my friends you can add a custom Tomcat to Fedora and have it run as a service.

This post is somewhat related to: my Adding a service on Fedora post except this one is more specific to Tomcat. If you’d like more information on adding services to Fedora that is the place to look.

Here is the script that I have been using: (Read on …)

Adding a service in Fedora

Filed under: Shell Script Sundays — TheLinuxBlog.com at 2:08 pm on Sunday, July 6, 2008

This week on Shell Script Sundays I’ll show you how to add a service to Fedora. This is very useful if you don’t happen to use yum for every service you want to run, and xinetd doesn’t really work for you.

Firstly there are three main parts to a Fedora service script. Start, Stop and Restart. They are pretty much self explanatory, but you don’t have to worry about the restart action since all it does is stop’s and then starts the service.

Without further ado here is the script:

#!/bin/bash
#
# Fedora-Service Update notification daemon
#
# Author:       TheLinuxBlog.com
#
# chkconfig:    1000 50 50
#
# description:  This is a test Fedora Service \
#               Second line of the fedora service template.
# processname:  FedoraTemplate
#
RETVAL=0;
 
start() {
echo "Starting Fedora-Service"
}
 
stop() {
echo "Stopping Fedora-Service"
}
 
restart() {
stop
start
}
 
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo $"Usage: $0 {start|stop|restart}"
exit 1
esac
 
exit $RETVAL

Now that you have a template for the script, you will want to modify it for your service. You need to keep the header at the top. This is how the Fedora Knows about your service. The three numbers indicate what order the scripts should start up and shut down in. The first seems to be a identification number and the other two are the startup and shutdown order. These can be adjusted depending on when you want the service to start up.Once you are done modifying the script put the script in /etc/init.d/

To make sure it works you can call it with service using the following actions:

service start
service stop
service restart

If all of the actions work, you are ready to add the service to the system. If you use the setup command as root it seems to do this step for you, but if you just want to add the service quickly without bothering to scramble through configuration menu’s you can do the following:

chkconfig --add [script name]

If you want the service to start automatically at boot up you can use ntsysv. For more information read my post on Managing Services on Fedora

Suspend Scripts for the Toshiba Tecra M2

Filed under: Quick Linux Tutorials,Shell Script Sundays — TheLinuxBlog.com at 12:15 am on Sunday, March 30, 2008

As you may know if you are a regular reader I own a Toshiba Tecra M2. One of the things that annoyed me was I had to turn the brightness up every time my computer came out of standby mode. A fix for this is to adjust the brightness every time the computer comes out of standby mode.

The script is intended to be run under cron. I have mine set up to suspend after 5 minutes of the lid being closed.

if [ $(cat /proc/acpi/button/lid/LID/state | sed 's/state:      //') == "closed" ]; then
VAR=$(cat /proc/acpi/toshiba/lcd | sed 's/brightness:              //' grep -v levels);
sudo su -c "echo mem > /sys/power/state";
if [ $VAR -eq 1 ]; then
ACTION=ADD;
elif [ $VAR -eq 7 ]; then
ACTION=SUB;
else
ACTION=ADD;
fi;
if [ $ACTION == "ADD" ]; then
VAR=$(($VAR + 1));
else
VAR=$(($VAR - 1));
fi;
sudo su -c "echo brightness:$(echo $VAR) > /proc/acpi/toshiba/lcd";
fi;

I run this with the following cron entry:

*/5 * * * * sh hibernate.sh

The script first checks the current brightness. If the brightness is currently 1 or 7 it adjusts the mathematic operation so that when the laptop is opened the brightness is adjusted. Basically if the brightness is one, it adds one. If the brightness is 7 or any other value it subtracts one. This is currently working out quite well for me. I don’t know how useful this is to any body else, unless you happen to have a Toshiba that is doing the same thing but it should give you a good overall idea of how to perform basic mathematic operations in bash.

PHP Script To Log Into cPanel

Filed under: Shell Script Sundays — TheLinuxBlog.com at 3:47 am on Sunday, February 24, 2008

Earlier this week I made a script that logs into cPanel to check statistics. Basically if you have a webhost that runs cPanel and you wish to log into cPanel for some reason then this script is for you. Once you are logged in you can basically do anything you would want to do. For example my specific use was to log into my cPanel nightly and parse some data provided by AWStats. But with some modification this script could automate anything you can do by hand.

Since this is more of a web project for me I decided to write my cPanel login script in PHP. I found a PHP class to login here. curl is used to fetch the URL’s and I parse the data using PCRE regular expressions. The statistics code is still very basic but I thought I would post it for those interested and what better place then The Linux Blog’s Shell Script Sundays column?

Onto the script.

It consists of three scripts each with their own purpose in run time. They are as follows:

cPanel.php – This script does all of the dirty work in connecting to cPanel and fetching the pages. I modified this from the original a little
class.mysql.php – Just a generic data base handler. MySQL configuration information is stored in here.
login.php – This is the script that starts off the process. I named it login.php instead of index.php so that I do not have it run as the default page in my web browser. login.php also does all of the parsing of the data and is where the data gets inserted into the database.

To run the script edit login.php and then you can either put it in your PHP powered web server directory or run it from the command line by doing:

php login.php

The output should be as follows:

Num: 0 Date: 2454521 uniques: X visits: X visits per visitor: (Xvisits/visitor) pages: X pages per visitor: (XPages/Visit) hits: X hits per visitor: (XHits/Visit) bandwidth: X GB bandwidth per visitor: (XMB/Visit)

Feel free to modify this as you wish. If any questions can be answered I’d be happy to do so. I’d like to hear what people are using this for too, so drop a comment!

Download the PHP cPanel Login Script

Bash, PHP or Perl?

Filed under: Shell Script Sundays — TheLinuxBlog.com at 12:23 pm on Sunday, January 6, 2008

One thing that is for certain is that some people like performance. Running an operating system like Linux gives you choices right out of the box for scripting. This blog post will show the differences in times between Bash, PHP and Perl.

Basically what I have done is created three scripts, one in each language. Then I run them with the time tool to test out the execution time.

Here are the results of echoing 1-100000 out to /dev/null for each script:

BASH:
 
real    0m1.966s
user    0m1.664s
sys     0m0.072s
 
PHP:
 
real    0m0.309s
user    0m0.220s
sys     0m0.048s
 
Perl:
 
real    0m0.126s
user    0m0.096s
sys     0m0.000s

You can clearly see out of this the order of performance by this test is Perl, PHP and then BASH. Now, what is interesting is when I run the script to stdout these are the results:

BASH:
 
real    0m8.689s
user    0m2.408s
sys     0m0.416s
 
PHP:
 
real    0m4.381s
user    0m0.544s
sys     0m0.372s
 
Perl:
 
real    0m3.938s
user    0m0.244s
sys     0m0.324s

Bash takes about twice as long as Perl / PHP to complete the exact same task. The winner of this test is Perl but I’ll be doing more tests over time when I become more familiar with Perl

Package management on Slackware

Filed under: General Linux,Linux Software — TheLinuxBlog.com at 6:38 am on Friday, December 21, 2007

People complain that Slackware is hard to use. I don’t believe that thats true. I don’t think that its any harder to use than any other Linux distribution. I also believe that there is perfection in simplicity. Believe me that it isn’t the easiest to set up but once its up it is actually easy to update and maintain once you learn how.

Despite popular believe Slackware does have good package management software. The main ones that come to mind are slapt-get, slackbuilds, pkgtools, swaret and slackpkg. Below is a small amount of information about each of them.

I’ve never myself used swaret so I don’t know too much about it other than its a package manager that manages dependencies. I also know that a new version will be released soon. If your interested in finding the best package management for Slackware you might want to check swaret out.

slapt is a mashup of the two words slack & apt. Those familiar with Debian or Ubuntu will know apt-get is at the heart of these systems, slapt-get is a clone of this system. Its been in Beta since its creation but works perfectly. There are graphical front ends for this software. I personally don’t use it because I can not find a fast repository in my area.

slackbuilds are kind of like the Gentoo package management. They are distributed with the source code on the Slackware DVD. They are basically scripts that help compile the source code. Its pretty easy to use, for more information visit: slackbuilds.org

pkgtools are the base of Slackware package management. Basically it is a suite of utilities that you can use to install, remove and upgrade software. The best source I’ve found for finding extra packages is linuxpackages.net.

My favorite for updating Slackware is slackpkg. It uses pkgtools to install and remove packages. It comes on the Slackware CD’s / DVD’s in the extras folder and is pretty easy to use. Basically you install it, select a mirror from the config file and then run:

slackpkg update

Once its finished doing its thing you can then do:

slackpkg upgrade-all

This will start a fairly lengthy process of downloading and installing all of the new packages. Other options are available such as options to install new packages, remove packages revert to vanilla system and many more. One thing I have to caution on is updating to current. Its not as easy as upgrading from release X to slackware-current all the time. This is due to the different versions of GCC, glib, solibs and various other types of libraries. Always read the UPGRADE.TXT or at least have a back up of all of your critical data before attempting to upgrade.

There are a lot of options, if your interested in running Slackware I suggest you try them all and then use the one you like. If you don’t want to run Slackware because another distribution suits you better try not to use the “I don’t use Slackware because its hard to maintain” card.

Making your scripts user and sysadmin friendly

Filed under: Shell Script Sundays — TheLinuxBlog.com at 11:08 pm on Sunday, November 18, 2007

When designing a shell script it is important to make them easy to use but also to make it easily automated for deployment. One example of this that comes to mind is the NVIDIA installer. It has command line options to allow for deployment but also gives a nice interface for the end user.

To implement this “dialog” can be used for the user interface and “getopts” can be used for the command line options. The script may look something like:

#help function
help () {
echo "Linux Blog - getopts and dialog example";
echo "Usage:";
echo -e "\t -h shows this help";
echo -e "\t -a [y/n][other] ANSWER (Yes, No or Other)";
}
 
#show dialog to get the answers
showDialog () {
dialog --yesno "Do you want to enter y?" 5 50 && \
ANS="Yes was entered using dialog" ||\
ANS="No was entered using dialog"
showAnswer;
}
 
#actually show the answer
showAnswer() {
echo $ANS;
}
 
#check answer for command line processing
checkAns() {
if [ "${OPT1}" == "y" ]
then
ANS="Yes sent by getopts";
elif [ "${OPT1}" == "n" ]
then
ANS="No was sent getopts";
else
ANS="This: $OPT1 was sent by getopts";
fi
#call showAnswer
showAnswer;
}
 
#get the options
while getopts "a:h" ARG;
do case "${ARG}" in
a) OPT1="${OPTARG}";;
h) HELP="TRUE";;
esac;
done
 
#see if help was entered
if [ "${HELP}" ]
then
#display help and quit
help;
exit;
fi
#if the options are empty
if [ -z "${OPT1}" ]
then
showDialog;
else
checkAns;
fi

Keep this getopts and dialog post in mind next time your shell scripting. It will take a little extra time to implement but the result will be a user and sysadmin friendly script.