Linux Blog

Check if SELinux is Enabled

Filed under: Shell Script Sundays — TheLinuxBlog.com at 10:41 am on Monday, December 8, 2008

This weeks (now late) Shell Script Sundays (posted on Monday) article is a short one on a check to see if SELinux is enabled. While SELinux has some great security enhancements it can present a number of problems in applications and shell scripts alike. There is a simple utility that comes with many Linux distributions called “selinuxenabled”

selinuxenabled exits with a status of 1 if it is not enabled and 0 if it is. Zero normally means false but in this case since it is an exit status it is an exception. So, if you need to do a quick check, you may just run selinuxenabled. You will quickly find that it returns nothing. To figure out the exit status for your quick check, put an ampersand (&) at the end, and it will tell you the exit status. eg:

[root@thelinuxblog.com ~]# selinuxenabled &
[1] 28417
[1]+  Exit 1                  selinuxenabled

As we can see from the example above SELinux is disabled.

To use selinuxenabled in your scripts you would use it like any other command. Refer to Shell Scripting 101 for some more information. selinuxenabled can also be used in your scripts to make sure that selinux is enabled, which can be useful if you are trying to do security audits across multiple machines.

Reworking Shell Scripts

Filed under: Shell Script Sundays — TheLinuxBlog.com at 7:02 am on Sunday, August 24, 2008

To me shell Scripts are all about automation, their primary purpose is to get stuff done. If you have a one liner, snippet or other script you use on a regular basis, have you thought about how you could rework it for it to become more in handy?

Lets take last weeks snippet from this column. It was a simple one liner to reconnect to a host. Now, I knew when I posted this article that it was a helpful snippet of code. Now, how can this script be adapted to be a neat utility that we use on a regular basis? Over the next few week’s we’ll find out.

The first thing that I will note on is that this script or shell snippet is a pain to remember. Does a script save you time if you can’t remember how it works? Is it worth the hassle? Not exactly. So, in order to make this snippet a little better the first thing we are going to do is add something that it needs: parameters. Adding parameters to shell scripts is actually easy, much easier than adding parameters to some other languages that we wont mention. although this script does not use it getopts can be used. I’ve covered how to do this with getopts in other posts. Just do a site search (located at the bottom of the right bar for getopts.)

So, here is the modified script that automatically reconnects to a host by using ping and SSH:

#!/bin/bash

# Sleep Time Default: 15 seconds
STIME=15

# Set a default user up
USERNAME=LinuxBlog

#usage function
usage () {
echo -e “Usage: $0 host [user] [Sleep Time]”
}

# display usage if no host is specified
[ -z $1 ] && { usage && exit 1; }

# set the variables
[ $1 ] && { HOST=$1; }
[ $2 ] && { USERNAME=$2; }
[ $3 ] && { STIME=$3; }

# trying:
echo -e “host: $HOST \nuser: $USERNAME \ndelay: $STIME”

while ! ping -W 1 -c 1 $HOST 2>&1 >/dev/null; do true; done && echo “Successful waiting: $STIME secs”; sleep $STIME; ssh $USERNAME@$HOST

Now that you have that done, all you need to do is give the file a name (I called mine ssh_auto) and put it in a folder in your path. Use the filename and parameters defined in the script to connect to the host.

The next shell scripting article I demonstrate how you can further rework shell scripts to better suit your needs.

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

Creating Script Parameters With getopts

Filed under: Shell Script Sundays — TheLinuxBlog.com at 9:06 am on Sunday, October 14, 2007

Many programs for Linux have parameters that can be given at run time. These are also known as switches, arguments or options. These parameters make it easy to tell a program or script what to do and what options to use. In this Shell Script Sundays Blog post I will show you how to implement these in a script by using getopts.

For this example to work the following must be placed in a script:

while getopts “:e:” ARG;
do case “${ARG}” in
e) echo “${OPTARG}”;;
esac;
done

This code basically gets loops around the arguments. All this script does is take the value after the -e and echo’s it out. In the example below I named the script getopts.

owen@the-linux-blog:$ ./getopts -e “Hi There Linux Blog Viewers”
Hi There Linux Blog Viewers

For each extra parameter that is needed a new constant to the getopts and do loop need to be added. For example if the option -e and -q need to be in the script then the following getopts loop would be created:

while getopts “:e:q” ARG;
do case “${ARG}” in
e) echo “${OPTARG}”;;
q) echo “${OPTARG}”;;
esac;
done

Of course the above script for -q also only echo’s out the value for -q as seen below:

owen@the-linux-blog:$ ./getopts -e “Hi There Linux Blog Viewers” -q “Another Option”
Hi There Linux Blog Viewers
Another Option

This is all very well, but documentation is always nice, even if you think you know how to use your script you may forget in the future. Its also nice if you have a script that other people can easily use. That being said its good to have a way to show users how to run the script.

usage () {
echo -e “Usage: $0 -e \”What To Echo\” [ -q \"Output\" ]”
echo -e “\t-e: specifies what to echo (required)”
echo -e “\t-q: Where to write output to. If not specified the output is written to the console”
}

while getopts “:e:q:” ARG;
do case “${ARG}” in
e) ECHO=”${OPTARG}”;;
q) OUTPUT=”${OPTARG}”;;
esac;
done

[ -z "${ECHO}" ] && { usage && exit 1; }

[ "${OUTPUT}" ] && { echo $ECHO > $OUTPUT; } || { echo $ECHO; }

The code above takes the options and assigns a variable to each of the options $ECHO is what to echo and $OUTPUT is where to write the output to. The script calls the usage() function and exits whenever the required option ($ECHO) is not set. If $ECHO is set it checks to see if $OUTPUT is set, if so it echo’s the contents of $ECHO to the $OUTPUT variable (file or device). If $OUTPUT is not set then it just echo’s the $ECHO variable normally. This is the script running with its various different actions:

owen@the-linux-blog:$ ./getopts
Usage: ./getopts -e “What To Echo” [ -q "Output" ]
-e: specifies what to echo (required)
-q: Where to write output to. If not specified the output is written to the console

owen@the-linux-blog:$ ./getopts -e “The Linux Blog getopts Example”
The Linux Blog getopts Example

owen@the-linux-blog:$ ./getopts -e “The Linux Blog getopts Example. Output To Null” -q /dev/null

owen@the-linux-blog:$ ./getopts -e “The Linux Blog getopts Example” -q Write_To_This_File
owen@the-linux-blog:$ ls
Write_To_This_File getopts
owen@the-linux-blog:$ cat Write_To_This_File
The Linux Blog getopts Example

As there are many different variations and each implementation would be different I can not cover each individual getopts scenario but by assigning variables your option arguments you should be able to get switches working in your own shell scripts.