Why are you: rm $1?
Ok. I'm a little bit paranoid, make sure that any errors or failures that you can think of will return some sort of message either to a log, standard out, or as a generated e-mail to the administrator (you). The last is much preferred.
You initialize a tempfile then >> (redirect+concatenate-which is to add the next item on a new line at the end of the file.) Even though it adds to the size of the script, always interpret error messages in an easy-to-understand way.
You can, in fact, by using "escape characters" echo human-readable COMMENTS to your log-file and still leave it parse-able by scripts.
Then, add a script function to e-mail all pertinent information back to you. And, don't forget to clean-up and remove the tempfile after all is done, success or failure.
(It is best to use a random number generator to make sure the tempfile_name is unique so you don't clobber some other script function you may have or may write in the future. Don't trust that every environment of every machine will do this for you.)
You can set up a special e-mail account for this, with a script which parses the generated message for the: host, group, region, location, user, the success/error messages; use this to create an administrative log for each specific machine. Then discard the e-mail itself after processing it.
Set it up to create a file if one doesn't exist--or--concatenate messages to an existing file with a generated solid line or some sort of easily identified break between entries and some sort of identification for each of the installations. Most likely this is not going to be a one time deal, always try to create a tool which can be used again with no editing for each use. **
Having a broken line or other easily identified break means that you can use variables as part of the script to keep track and speed up automated searches of each log-file. Then, one file within the directory you set up will have unique entries for all of the types of breaks: policies, software-updates, patches, software, settings, private-public keys, vpn-IDs, changed-Admin-passwords, changed-user-passwords, anything you want to keep track of; using line numbers, generated IDs, and "friendly" human readable names; this you can use to quickly check any identified machine which you are responsible for--for any problems or installation information. Each machine can be sorted by group or any other information you choose to use in the header of the logfiles, and each machine will have its own log-file.***
These "breaks" can be made unique pretty easily for each kind of task. All you need is a unique pattern which can be matched using Regular Expressions. (You embed the DATE/time in the breaking line after enough characters to ensure that identity is unique for your intended use. I'll tell you this, the use of Regular Expressions is explained by "Rute User" better than any programming manual I have ever read. I have read many.
The tasks to which I refer can be: scripts for generating private keys--which then can be uploaded to you using your public key for encryption so they will remain secure (along with the specific machine public-key), which then enables you to securely change administrative passwords, vpn keys, secure-shell keys, new encryptions/logins/passwords for wire-less networking, MAC address assignments, and other stuff you need to do.
Automated searching of the machine_specific_log-files you create can enable you to create scripts to change: every machine and user-specific network login, encryption, services, settings, software, group-memberships, priveleges, users, available server and network resources, anything you can do physically to the machine with the exception of adding and removing hardware; remotely from your workstation, and as securely as if you were doing it at the keyboard on the machine itself.
Why? because each machine has it's own encryption, which is imported by the script you write, and no unencrypted communication goes over any internal or external network.
You literally can change the whole network--including windows machines--with one command from your administrative console, without having to look up anything. That is the power of a bash script.
And, of course, all of the new machine-specific encryptions and information would be appended to the specific log for each machine/programmable device.
Planning the layout of the log-file is important, any information you choose to include in the header can be used to generate reports and sorted information by whatever entries you choose to include in the header.****
NOTE: Size alone is not sufficient to verify a file transfer. I know this from bitter experience. If a file is tar-ed/compressed/packed/zipped/bzipped/whatever then there is a check-sum value in the header to verify the file integrity. That is why .iso files always have an MD-5 check-sum available on the server to check integrity. It is always good policy to distribute files with some means of verification. You can automate the unpacking and/or verification as part of the script.
The way you can do this is: create another tempfile-with a corresponding variable_name; download the bzipped file to the tempfile; attempt to unzip it to the location you wish for the final location; process the returned success or failure/error value of the utility within your bash-script. It would be a Very Good Idea (tm) to include in your bash-script a test for which type of compression is used on the object you want to download from the server and to call the specific program to de-compress it; this avoids the kind of errors I make which drive me up the wall. (Sometimes I wish I could fire myself.)
/** Take it one step at a time; keep each task simple, with a means of processing failure, and include enough comments/documentation to be able to maintain each segment of your script separately. Complexity is built by following one task with another. A script IS a program--whether it is in Windows or Linux. **/
/*** I wouldn't use tabs or special characters--they can cause un-intended results. It also makes it useful no matter what operating system you may be running--always make things portable if possible. ***/
/**** Remember, if you import a set of files from windows, you have to strip extra characters that windows puts on the end of every line. Linux/Unix just uses a "new-line" character, windows adds a carriage return and sometimes even more characters. They will not show up in anything but a hex-editor--but stuff will go dramatically wrong. On the other hand, the windows version of diff (and the script-engine) may consider the lack of a carriage return as a continuation of the same line, which can give you bizarre results which are difficult to track. Always check syntax. It never hurts to open a file in a hex-editor first, when trying to track down a problem.
If you are calling a windows machine with a script from a Unix/Linux environment, pipe the returned text-file through the text filter "To-Unix". Do a search on
http://www.google.com/linux for import text from windows.
(If you know of a program which shows the un-printable characters without the hassle let me know. The To-Unix and To-Windows translator scripts don't show the characters--they just change them--and they aren't infallible.)
I still will screw up and wonder why the "quick edit" I did in notepad results in catastrophic failure of a web-page on a Unix/Linux server. (I have replaced notepad with a "proper" editor with a switch to enable Unix type of editing, but will forget from time to time and wonder why stuff doesn't work. D'oh! ****/
BTW: Using returned information from a machine can call an alternate set of scripts to use for a Windows machine--which means you can do it all from one work-station in an auto-mated fashon--which in the long-run will save you time, effort and sanity. This way every machine which you have any responsibility for will have a full set of logs which track every patch, every update (anything you choose to include) in one easily backed-up and maintained location. It will simplify all of the administration tasks, the generation of reports, disaster-planning, and security which you may be resposible for.
BTW-the sequel: Windows and Linux both have tools which will report all of the patches and other information from the machines. (Like a software inventory for all of the windows machines for the BSA, and a hardware inventory and chipset information for you.) Neither will report--or should report--any sensitive information: like passwords, private keys, administrative passwords, or any sensitive information which can be used to gain entry to your network, your servers, your wireless vpn keys, encryption keys, etc. Much of that information, aside from their personal password, should be un-available to the USERS of the individual machines.
Yes, it is a real pain in the ass to set up, (and can be done from your workstation if you are cunning/diabolical enough) but security is a must anymore. The laws are getting strict, and no one knows exactly how much legal exposure a company--or the administrator--has until every possibility is decided in court. It is best to be paranoid.
