Automatically Deploy Debian Load Balancers with bash scripting

In yet another post in our automation series, we will share a bash script that automates the deployment of debian based load balancers (specifically with LVS / Linux Virtual Server project).

Even though the environments and systems you deploy may start to get more complicated such as with load balancers, there will always be a baseline level with which these systems can be brought to before further configuration and customization needs to be done.

There are many things that can be automated with this process, as you will see in the script below. In most round-robin load balancing scenarios, there wouldn’t be much more that needs to be done as far as configuration beyond what this script can do.

Obviously you will likely need to modify the script to suit your needs and requirements for the organization and standards therein.

Hopefully this will help you roll out many debian load balancers! May the load be split evenly between all your systems šŸ˜‰

[cc lang=”bash”]

#!/bin/sh
# Debian LVS deployer script
# Version 1.0

PROGNAME=”$0″
VERSION=”1.0″

# working directory for deployer process.
WORKDIR=”/root”

# tasks left (this is updated every step to accommodate recovery during
# the deployer process)
TASKS=”./deploy-lvs.tasks”

init_tasks() {
# This function will write a new tasks file.
# it’s called from the main body of the script if a tasks file does not exist.
cat > $TASKS<hostname > /etc/hostname
echo hostname > /etc/mailname
return 0
}

usage() {
echo “[+] Usage: $PROGNAME”
echo
return 0
}

###############################
### MAIN SCRIPT STARTS HERE ###
###############################

# installer_splash
installer_splash

# fix working dir.
cd $WORKDIR

# does our installer file exist? if not, initalize it.
if [ ! -f $TASKS ]
then
echo “[+] No task file found, installation will start from beginning.”
init_tasks
if (($? != 0))
then
echo “[!] ERROR: Cannot create tasks file. Installation will not continue.”
exit 1
fi
else
echo “[+] Tasks file located – starting where you left off.”
fi

# start popping off tasks from the task list and running them.
# pop first step off of the list
STEP=head -n 1 $TASKS
while [ ! -z $STEP ]
do
# execute the function.
echo -e “nn###################################”
echo “[+] Running step: $STEP”
echo -e “###################################nn”
$STEP
if (($? != 0))
then
# command failed.
echo “[!] ERROR: Step $STEP failed!”
echo ” Installation will now abort – you can pick it up after fixing the problem”
echo
exit 1
fi
# throw up a newline just so things don’t look so crowded
echo
# remove function from function list.
perl -pi -e “s/$STEPn?//” $TASKS || exit 1
STEP=head -n 1 $TASKS
done

# clean_up_and_reboot
echo “[+] Installation finished – cleaning up.”
clean_up_and_reboot

# script is done now – termination should happen with clean_up_and_reboot.
echo “[!] Should not be here!”
exit 1
[/cc]

Automatically Deploy Debian Firewalls with bash scripting

Automation is as necessary as any other aspect of systems administration in any critical or production environment where growth and scalability are moving at a significant pace.

Growth in any organization is obviously a good thing. In the systems administrator’s perspective, however, growth can mean more time spent deploying systems and less time spent focusing on other duties.

Automating the server deployment process is the natural next step when your organization has grown to a point where time efficiency becomes more relevant and noticeable to your business owners.

This is the first in a series of posts here where we will explain and share shell scripts that automate the deployment process of several key debian linux based systems. These scripts automate the patching, configuration and implementation of said systems.

They will certainly have to be modified to fit your organization’s needs and standards obviously, but hopefully it will give you a starting point to base your automation / roll-out policies.

Making your life easier and more automated is always a good thing! šŸ˜‰

Relay Exim mail to google mail in Debian Linux

Sometimes its necessary to relay your mail through a third party provider. If your server environment has a dedicated sendmail server (most do), then this scenario is applicable to you. It is ideal to centralize your outgoing mail to one server so that changes, policies and configuration is located in a single place.

In this scenario, outgoing mail is relayed to google’s domain mail in an Exim mail environment. These steps are fairly straightforward and will hopefully help you to utilize google’s free mail service to send your mail.

Note that google has queuing and mass mail restrictions so if you plan on sending alot of mail this way, you will just get blocked.

    Step 1

Run dpkg-reconfigure exim4-config

1. Choose mail sent by smarthost; received via SMTP or fetchmail

2. Type System Mail Name: e.g. company.com

3. Type IP Adresses to listen on for incoming SMTP connections: 127.0.0.1

4. Leave Other destinations for which mail is accepted blank

5. Leave Machines to relay mail for: blank

6. Type Machine handling outgoing mail for this host (smarthost): smtp.gmail.com::587

7. Choose NO, donā€™t hide local mail name in outgoing mail.

8. Chose NO, donā€™t keep number of DNS-queries minimal (Dial-on-Demand).

9. Choose mbox

10. Choose NO, split configuration into small files

11. Mail for postmaster. Leaving blank will not cause any problems though it is not recommended

    Step 2

1. Open the file /etc/exim4/exim4.conf.template
2. Find the line .ifdef DCconfig_smarthost DCconfig_satellite and add the following in that section

If you have any other smarthost defined with ā€œdomains = ! +local_domainsā€ remove that smarthost.

3. Find the ā€œbegin authenticatorsā€. In that section add the following

Make sure you have no other authenticators with the same public_name (LOGIN). Comment them out if needed (Thanks Jakub for reminding me)

4. Find the comment ā€œtransport/30_exim4-config_remote_smtp_smarthostā€. In that section add

    Step 3

1. Run update-exim4.conf

2. Do /etc/init.d/exim4 restart

That should be it. You can test by using the command line mail client.

Test :