Day 20 - Scripting
Today is the final session for the course. Pat yourself on the back if you worked your way through all lessons!
You’ve seen that a continual emphasis for a sysadmin is to automate as much as possible, and also how in Linux the system is very “transparent” - once you know where to look!
Today, on this final session for the course, we’ll cover how to write small programs or “shell scripts” to help manage your system.
When typing at the Linux command-line you’re directly communicating with “the command interpreter”, also known as “the shell”. Normally this shell is bash, so when you string commands together to make a script the result can be called either a ‘“shell script”, or a “bash script”.
Why make a script rather than just typing commands in manually?
- It saves typing. Remember when we searched through the logs with a long string of
sortcommands? If you need to do something like that more than a few times then turning it into a script saves typing - and typos!
- Parameters. One script can be used to do several things depending on what parameters you provide
- Automation. Pop your script in /etc/cron.daily and it will run each day, or install a symlink to it in the appropriate /etc/rc.d folder and you can have it run each time the system is shut down or booted up.
START WITH A SHEBANG!
Scripts are just simple text files, but if you set the “execute” permissions on them then the system will look for a special line starting with the two characters “#” and “!” - referred to as the “shebang” (or “crunchbang”) at the top of the file.
This line typically looks like this:
Normally anything starting with a “#” character would be treated as a comment, but in the first line and followed by a “!”, it’s interpreted as: “please feed the rest of this to the /bin/bash program, which will interpret it as a script”. All of our scripts will be written in the bash language - the same as you’ve been typing at the command line throughout this course - but scripts can also be written in many other “scripting languages”, so a script in the Perl language might start with
#!/usr/bin/perl and one in Python
YOUR FIRST SCRIPT
You’ll write a small script to list out who’s been most recently unsuccessfully trying to login to your server, using the entries in /var/log/auth.log.
vim to create a file,
attacker, in your home directory with this content:
#!/bin/bash # # attacker - prints out the last failed login attempt # echo "The last failed login attempt came from IP address:" grep -i "disconnected from" /var/log/auth.log|tail -1| cut -d: -f4| cut -f7 -d" "
Putting comments at the top of the script like this isn’t strictly necessary (the computer ignores them), but it’s a good professional habit to get into.
To make it executable type:
chmod +x attacker
Now to run this script, you just need to refer to it by name - but the current directory is (deliberately) not in your $PATH, so you need to do this either of two ways:
Once you’re happy with a script, and want to have it easily available, you’ll probably want to move it somewhere on your $PATH - and /usr/local/bin is a normally the appropriate place, so try this:
sudo mv attacker /usr/local/bin/attacker
…and now it will Just Work whenever you type
EXTENDING THE SCRIPT
You can expand this script so that it requires a parameter and prints out some syntax help when you don’t give one. There are a few new tricks in this, so it’s worth studying:
# ## topattack - list the most persistent attackers # if [ -z "$1" ]; then echo -e "\nUsage: `basename $0` <num> - Lists the top <num> attackers by IP" exit 0 fi echo " " echo "Persistant recent attackers" echo " " echo "Attempts IP " echo "-----------------------" grep "Disconnected from authenticating user root" /var/log/auth.log|cut -d: -f 4 | cut -d" " -f7|sort |uniq -c |sort -nr |head -$1
Again, use vim to create
chmod to make it executable and
mv to move it into /usr/local/bin once you have it working correctly.
(BTW, you can use
whois to find details on any of these IPs - just be aware that the system that is “attacking” you may be an innocent party that’s been hacked into).
A collection of simple scripts like this is something that you can easily create to make your sysadmin tasks simpler, quicker and less error prone.
If automating and scripting many of your daily tasks sounds like something you really like doing, you might also want to script the setup of your machines and services. Even though you can do this using bash scripting like shown in this lesson, there are some benefits in choosing an orchestration framework like ansible, cloudinit or terraform. Those frameworks are outside of the scope of this course, but might be worth reading about.
And yes, this is the last lesson - so please, feel free to write a review on how the course went for you and what you plan to do with your new knowledge and skills!
- Learn Bash Scripts - Tutorial (video)
- Bash scripting tutorial
- BASH Programming - Introduction HOW-TO
- How to be a good (and lazy) System Administrator
Some rights reserved. Check the license terms here