Unix Linux Administration II

Download Report

Transcript Unix Linux Administration II

Bash Scripting
Basic Shell Script Structure
Agenda
 Script
component overview
 Psuedo-Psuedo Code
 Group Labs
Script Components:
Sha-Bang
 Initial comments
 Initialize runtime environment.
 Functions
 User input validation; “Sanitize”
 Functional execution
 Execution validation
 User Message/Exit Codes.

Sha-Bang:
At the head of a script tells your system that this
file is a set of commands to be fed to the
command interpreter indicated. The #! is actually a
two-byte magic number, a special marker that
designates a file type, or in this case an
executable shell script (type man magic for more
details on this fascinating topic). Immediately
following the sha-bang is a path name. This is the
path to the program that interprets the commands
in the script, whether it be a shell, a programming
language, or a utility. This command interpreter
then executes the commands in the script, starting
at the top (the line following the sha-bang line),
and ignoring comments.
Sha-Bang examples:
#!/bin/sh
#!/bin/bash
#!/usr/bin/perl
#!/usr/bin/tcl
#!/bin/sed -f
#!/bin/awk -f
Initial Comment Block:
Title: Name of original file
 Date: When originally written/see version
 Author: Who originally wrote it/see version
 Purpose: Short declaration of what the script
is used for/does. Should include comments
about expected user provided information,
require run conditions.
 Version: Last revision, date, author, revision
summary.

Initialize runtime environment
Setup the basic requirements for execution.
 Script PID
 Initialize logging if any
 Validate user permissions
 Command aliases
 Declare any defaults to be used
Functions:
“A function is a subroutine, a code block that
implements a set of operations, a "black box" that
performs a specified task. Wherever there is
repetitive code, when a task repeats with only slight
variations in procedure, then consider using a
function.”
Examples:
 Usage instructions
 Command validation
 User feedback
 Temporary file cleanup
User input validation; “Sanitize”
The level of sanitizing required depend on
level of risk.
Confirm input matches required data type:
 Alpha
 Numeric
 File name
 Directory
 Supported action
Functional execution:
This is were it all comes together.
 You have a runtime environment setup the way
you need.
 You know what you are supposed to be doing.
 Now you actually do it, copy the file, read the
log, restart the service, take over the world..
Execution validation:
Ok, now you’ve done something, see if it worked.
 Exit status of attempted commands
 Check for new/removed files
 Confirm the service is stopped/started/running
 Enjoying supreme authority
User Message/Exit Codes:
Now we know what we have done or failed
to do, lets tell our user how we did.
 echo “Success, we have done that cool
thing for you, have a great day”
 echo “Failed, sorry the flux capacitor
wasn’t fully charged, so we only were able
to move 3 years into the future.”
 exit 0/1/57
Psuedocode:
Pseudocode is an informal high-level
description of the operating principle of a
computer program or other algorithm. It uses
the structural conventions of a programming
language, but is intended for human reading
rather than machine reading.
User Story:
In software development and product management, a user
story is one or more sentences in the everyday or business
language of the end user or user of a system that captures
what a user does or needs to do as part of his or her job
function. User stories are used with agile software
development methodologies as the basis for defining the
functions a business system must provide, and to facilitate
requirements management. It captures the 'who', 'what' and
'why' of a requirement in a simple, concise way, often
limited in detail by what can be hand-written on a small
paper notecard.
Psuedo-Psuedocode:




Specific to the individual author.
Should account for the various user stories the
script is designed to accommodate.
The more comprehensive the easier it is to write
the functional “code”.
Becomes the basis for comments contained
within.
Psuedo-Psuedocode Example:
#BANG
##Based on user input:
# Check for the number of unsuccessful root connection attempts, number of unique sources for those
attempts, date/time of most recent attempt.
# Or display currently open ports and a human readable application using that port. E.G. 22 Secure
Shell (SSH)—used for secure logins, file transfers (scp, sftp) and port forwarding, 25 Simple Mail
Transfer Protocol (SMTP)
#Setup message color codes
##Confirm desired user story
# Commandline switches, should support all three log attempt options on a single run, or port listing,
but no need for both.
#Confirm adequate permissions to read /var/log/secure
#Get/build a table of humanreable port descriptions
### Fork execution to either parse log or report port usage
## Read logs for desired information
## Check port information
# Tell user what we now know, and call it a day.
Group Lab 1:
Pick a partner or two and collaborate on creating
an example pseudo-pseudocode for a script to
support the following user stories:
 Check for the number of unsuccessful root
connection attempts, number of unique sources
for those attempts, date/time of most recent
attempt.
 Display currently open ports with a human
readable application description.
Smoke 'em if You Got 'em
Be back in 15 minutes
In class lab 2

Take the framework you just wrote, and
make it a functional script.
Why are you still here?
Questions?
If not, go home, we are done here.