RSync and SSH Keys - A Presentation on backups

Recently I did a presentation on RSync and RSnapshot focusing on using it for backups. You can down load the presentation from http://www.theonealandassociates.com/files/rsyncPortable.zip or if you do not have Open Office yet (a free and powerful Office suite comparable and compatible with MS Office and Word Perfect) or another application that can handle the ultra efficient open document formats, you can get the power point version (at twice the total download size) at http://www.theonealandassociates.com/files/rsyncPortable1_with_ppt.zip
The presentation is narrated and is easy to follow, but for you looking for the cliff's note version

1. You do not need to set up an rsync server to use rsync. The server function handles file browsing and other functions and set up is not required for transfers.
2. If your going to automate your backups going from one computer to another, you should implement some basic security. Moving your files over SSH for example is easy, but you need to set up a pair of ssh keys so that you don't have to enter a password to shh from one server to another. Simply perform the flowing commands from the production server (now known as Server A) and just use remote execution to perform your work on the backup server (hence forth know as Server B)
2.i) backupuser@ServerA:~> ssh-keygen -t rsa

a) Do not enter a passphrase (just hit enter)

2.ii) backupuser@ServerA:~> ssh backupuser@ServerB mkdir -p .ssh

a) This creates an ssh directory for the backup user on server B

2.iii) backupuser@ServerA:~> cat .ssh/id_rsa.pub | ssh b@B 'cat >> .ssh/authorized_keys'

a) This moves the contents of your public key to the remote servers authorized keys file
b) You can just as esaly open a second terminal window, log into server B, vi the .ssh/authorized keys file, and cut and past from the vi window of your .ssh/id_rsa.pub file on server A

2.iv) backupuser@ServerA:~> ssh b@B chmod 0700 .ssh/
2.v) backupuser@ServerA:~> ssh b@B chmod 0600 .ssh/authorized_keys

a)If you don't restrict the permission SSH will ignore the file by default and the whole thing will fail to function.

3. Set up an automates script containing a command like
3.i) rsync -a -r -v -t -z --stats --progress -e ssh /dir/for/destination/files/ backupuser@ServerB.MyDomain.com:/dir/for/source/files/
3.ii) there are more detailed instructions for windows and Linux inside the presentation.

You can verify the whole thing is working, and trouble shoot problems, by ssh'ing witht he verbose option -vvv and looking at the recipiants logs /var/log/secure

backupuser@ServerA:~> ssh -vvv b@B

b@B sudo -tail -f /var/log/secure

Your basically done. Though the presentation fills a nice half hour time slot and provides more detail; as such I highly recommend downloading it from the links at the top of the post ;)

Please show your work and label your units

A small rant on units. I have run into meaningless use of units so often lately that I thought I post a small rant here. “Please show your work and label your units” is something every instructor I had since grade school has been reiterating, so why do we have a problem with people failing to do just that? Units are important as they provide understanding to numerical measurements. To do so the units used in quantitative measurements should be appropriate for what is measured, consistent with comparable measurements, and above all well labeled. To begin with I would like to address the disturbingly prevalent absence of units. For example I was recently looking at a simple matrix chart in a magazine comparing baby monitors. One of column was labeled distance and had units such as 700, 300, 500, but no where in the article or the chart did it tell you 500 what; inches, meters, feet, miles, what? The second frustrating error is the inconsistent use of units. To use the prior example I would have only slightly less disdain if the article indicated 700 In., 300 M, 500 Ft. Yes, one now has the information required to understand the measurement and to do the comparison, with conversion, however the inconstant units do not allow us to use the chart in a useful way to make quick comparisons. The third issue I have is the use of units that either don't make sense for the measurement or don't convey accurate information. Simple said units need to make sense for what the measure. For example, the axiom that one should always leave two car lengths between your car and the car ahead of you, suffers from this bad choice of units. The units, car lengths, are first non standard (i.e ranging 2.7 M for a Smart to 5.7M for a Lincoln Town Car) and second, meaningless. I say meaningless because stopping distance is a function of the speed the vehicle is traveling. For example if I am travailing at 10 kph I can easily stop in less then 3 meeter's. However if I am travailing at 150 kph I would not be able to register the need to stop and have my foot hit the break, let alone stop, inside 5 times that distance. Let us look at it this way, we want a fixed unit to govern distance with regard to a variable distance/time function; thus we need a constant time unit. Simply said, if you stay two seconds behind the car ahead of you the distance will become greater at higher speeds, thus accommodating for the greater stopping distance required.
Now I understand when what you are looking to measure quantitatively is intrinsically tied to a qualitative value it gets harder. For example a recruiter asked me how many years of experience I have writing disaster recovery plans. My first thought was, who does nothing but write disaster recovery plans for their career, that must be a rather specialized market. I was tempted to say 10 years since my first disaster recovery project was in 1998, when I took over a flawed DR project, and the last one I wrote was in 2008 when I wrote one as part of developing standard operational documentation. However the first plan was for an environment I understood with a budget I understood and was limited in scope (servers and licenses for the IT department which served a greater college at the local university) and the last one was integrally tied to the development of a brand new .com operational procedures manual which I was helping start from scratch. And while I had written several in between, (~5 in total) they had all been part of normal operations for the company and not separately measured. In addition many of those had the assistance of an establish continuity plan to borrow from. I would argue hours, not years, would have been a more accurate reflection of my experience. For example if you have two candidates, one of which has 10 years experience, and one who has 2 years, which one should you higher for a managerial position? What if the one who has 10 years managed one worker who clocked only 8 hours a week for 10 years while the second one managed a department of 50 full time employees and a dozen contractors for two years? One has more “years” but at the same time far fewer hours of managerial experience. However, this is nearly an impossible paradigm shift for most people. In the above example if I had replied to the recruiters experience query with “I have over 2,500 hours of disaster recovery experience” it is likely I would have received a blank stare.
In conclusion, please use appropriate, consistent, and well labeled units in all quantitative measurements. Doing so will make your work measurably more useful.

How to hack your head

This post is taken from a conversation occurring on the Phoenix Lunix Users Group, and giving that the information is both obvious and important, but never followed, I felt that it was important to present it here for all of you in hope it will help change the way you work.

Hack your Head
or
How to maintain optimal thought processing abilities.

When working on systems, we often get into the zone, don't eat, don't stretch and don't maintain optimal glucose for thought processes. We therefore get REALLY STUPID and don't notice it. This can happen late at night, or at noon, but when it happens, we must acknowledge our own limitations.

If you have attacked a problem for 30 minutes using caution, and addressing resources, and cannot fix it, get up and walk around, go outside look at the sun. Be assured that some part of your higher functioning is still working on it in a creative way. Poking a problem for 30 hours with the same information you were unable to think with initially, is not productive, it's stupid. You might need to attempt to explain the problem to another (like we do on the PLUG list) in order to get clarity for instance. We learn to package and organize abstractions to develop if/then/therefore logic via PLUG list discussions, and or questioning our initial assumptions. There are a great many people who never learned systems analysis using documentation, Linux veterans did not have the luxury of Google (RHCE does not allow you to use anything but the system itself). Others essentially do not think in language, but use higher functioning to solve problems. All of us develop a higher functional way to solve problems, but sometimes that process fails and we must therefore use language or logical dissection to find our way out. We all LOVE doing this, it's incredibly addicting, but it also has some mental health risks, that must be mitigated with lifestyle changes.

Be sure to follow these daily cautionary steps to remain healthy:
1) Eat a good mix or protein, polyunsaturated fats and carbs on a regular schedule.
2) Sports drinks are just going to make you crash badly, however, adding B and C vitamins with a good breakfast, lunch and dinner will go a long way toward allowing you think effectively. Caffiene does assist with some times of tunnel attention, but can also cause health issues. The best and brightest don't drink coffee all day - that's for marketing people.
3) When you are too tired or ill to work, you must acknowledge it. Too many systems administrators just work and work and work, over and beyond what is healthy and make grave mistakes when tired.
4) Build a healthy life away from computing to provide for emotional balance. We get so far into the abstract analytical virtual realm and develop functional stunting, especially under the pressures of 24X7 Uptime.
5) Talk to others in a deep personal level; if you have noone to talk to, call your own voice mail or record yourself. Einstein and thinkers of the last century all kept uber personal journals. The mere act of talking about things or examining issues through grief and anger to laughter will assist development of free flowing heathy emotional states and that all important core of individuality and muscled critical thought.
6) Do various balanced emotional and physical things that restore your individualism, such as walk/bike, laugh, and play games, hug, chase the opposite sex and dream or create, and listen to music. Allowing children to swing and listen to music is known to stimulate intelligence.
The sheer number of IT professionals and college students taking SSRI neurotransmitter uptake inhibiters is astounding, and certainly not necessary. Exercise has been shown to be more statistically effective over time than SSRIs. Tobacco has been long used as an anti-anxiety medication, however, smoking does kill. Anxiety from balancing unrealistic, unevolved demands from people who cannot understand you when you talk is best mitigated with laughter and zen detachment.

I am sure you all can relate to Number 10 on the top ways to Hack your Brain http://brainz.org/brain-hacks/
O'Reilly has some good books that are an amusing way to wait for your greater intelligence to find the best solution to another problem.
1. Mind Performance Hacks: Tips & Tools for Overclocking Your Brain (Hacks) by Ron Hale-Evans
2. Google Hacks: 100 Industrial-Strength Tips & Tools by Tara Calishain
3. On Intelligence by Jeff Hawkins
4. Mind Wide Open: Your Brain and the Neuroscience of Everyday Lifeby Steven Johnson
5. Getting Things Done: The Art of Stress-Free Productivity by David Allen
6. Firefox Hacks: Tips & Tools for Next-Generation Web Browsing (Hacks) by Nigel McFarlane
7. Knoppix Hacks: 100 Industrial-Strength Tips and Tools by Kyle Rankin
8. How the Mind Works by Steven Pinker
9. This Is Your Brain on Music: The Science of a Human Obsession byDaniel J. Levitin

Derived from HackFest Series PLUG ,
Written by Lisa Kachold:
Edited by Bryan O'Neal