Linux

I've done a lot of different things over the years to back up my systems, and until very recently used an optical disk backup system called BackBurner (long, long abandoned project).

Now I've simplified things for myself, as well as fully automated my backups.  I use a script which creates snapshots and uses rsync to copy down data.  Because it does a smart method of making hard links for the snapshots, the resulting backup set is as compact as it can be, yet it is not compressed at all.  It is directly accessible on the filesystem.  If a file doesn't change, it simply has a hard link made.  If it has changed, multiple copies will exist, one per snapshot.  This lets you go back in time and recapture a file as it was at that time.  Comes in every handy for restoring files quickly and easily.

I have my server set up with a 200G disk dedicated for backups and it backs up itself, my second server, my workstation, and my new V100 laptop.  All the other machines have NFS mounts and generally run once a week.  The local copy runs every 6 hours, creating 4 snapshots per day.  Then there are 4 daily snapshots, allowing me to retrieve data from 6, 12, 18, 24, 48, 72, 96, and 120 hours ago.  As mentioned above, it would seem this would require a lot of disk space, but I find that this full hourly+daily snapshot requires around 2x filesystem size.  So if you're currently backing up 4G of data, this system will use about 8G of disk space.  If you have a lot of big files which frequently change the disk requirements will go up.

Please note that this script should protect you from single disk failures, also give you access to files from another system if that particular system has gone down, etc.  It will obviously not protect you from fires or catastrophic failures.   It would be well advised to also do offsite backups of critical data.  At least the data is all in place to make a copy of.  I have my backup drive on a removable tray and could remove the disk in about 15s if the need arose and I was there to be able to do it.  This also lets me pop in another disk to make a snapshot to and then remove and store in another location.

Here is the script, inside it are some basic instructions on how to set it up.  There's an hourly script and a daily script.  You don't have to use the daily script, all it does it make snapshots of the oldest hourly snapshot.   But it comes in handy to go back multiple days to retrieve a file.

• make_snapshot.sh - Main file, 4 rotations.  Excellent for 6 hour crons
• daily_snapshot_rotate.sh - If you want an additional 5 days of backups
• make_snapshot-remotemachine.sh - Example of using rsync/nfs for remote backup

Example:  My server runs make_snapshot.sh every 6 hours, then daily it runs daily_snapeshot_rotate.sh.  What this gives me is a snapshot for 6, 12, 18, and 24 hours ago, as well as 2, 3, 4, 5, and 6 days ago.

Example:  I backup my workstation weekly, so I only run make_snapshot_remotemachine.sh on it.  Since it's weekly, this means I have 4 weeks of snapshots.   This is basically the same as make_snapshot.sh but it's geared for remote machines.

I can't take the credit for these scripts, I've only made some updates to them for myself and documented the process a bit.  The original website for the scripts are here.

TrueCrypt is an excellent open source encryption software that can do a variety of things, most notably it can make encrypted/secure volumes out of entire devices or within files on the filesystem which can be mounted and used like a normal filesystem.

There's no Fedora-specific RPM available, but there is a very easy method for getting it working in Fedora 8.

1. Go to the TrueCrypt download page and download the Unewbtoo package.
2. Use file-roller on the tar.gz that downloads, and enter the download
3. Click to enter the .deb file that you'll see.
4. Enter the data.tar.gz file
5. Click the directory (might just show '.' but click on it)
6. Enter usr/bin
7. Copy the fiile called "truecrypt" to your home directory or directly into /usr/local/bin
8. Try to run truecrypt.  If you get a GUI, you're good to go, now read the instructions at their website!
   

If you don't get a GUI and it won't launch, you might need a dependancy, so run the following from the command line or equivilent GUI tool:

# yum install wxPython

Someone please contact me through the link in the menus if you have any corrections for the above, I mucked around a little bit with some stuff and not 100% sure if the above is all that is necessary.

Some useful CLI type information can be found here and here.  How to mount a volume from the terminal, etc, but I'd still like to figure out how to be able to 'automount' a volume (with password, of course).

I was recently asked to help out someone who was having problems with a server being hit by ssh scripts, the basic brute-force password cracking attempts that's been going on for a few years now.  While the chance of being hacked with this sort of script is very low unless you use really bad passwords, this sort of thing is pretty annoying and makes a lot of noise in the logs and can potentially cause a lot of cpu time.  My P2 400Mhz server/router uses 100% cpu for several minutes when being hit with one of these scripts.

So I wrote up a fairly simple HOWTO on the subject and was pretty successful first try on getting it to work for this person who was reading it and doing it on his system, and he was a self-claimed Linux newb.  Hopefully it's useful for someone else too.  Please read the installation instructions for blocksshd before starting here so that you understand what is going on.

Lines which are prefixed with # are commands to run, otherwise the line is informative or instructions.

Get the blocksshd program from here: http://sourceforge.net/project/showfiles.php?group_id=163753
Download blocksshd-X.X-src.rpm (download the latest, 1.1 at this moment)
# rpmbuild --rebuild blocksshd-1.1-src.rpm
# cd /usr/src/redhat/RPMS/noarch
# rpm -Uvh blocksshd-1.1-1.noarch.rpm

Now it's installed, time to set up the system.  FYI, you don't have to edit the blocksshd config file, but I suggest you read the instructions that come with blocksshd and make sure it's ideal for your network.

You'll need a perl module or two most likely..
# yum install perl-File-Tail perl-Net-DNS

Unfortunately gotta install one module manually...
# wget http://search.cpan.org/CPAN/authors/id/S/SR/SRI/Net-Subnets-0.21.tar.gz
Download the latest version of the Net::Subnets module from here: http://search.cpan.org/~sri/Net-Subnets-0.21/lib/Net/Subnets.pm
# tar zxf Net-Subnets-0.21.tar.gz
# cd Net-Subnets-0.21
# perl Makefile.PL
# make install

Now, must edit the iptables script to add a single but necessary rule, so edit /etc/sysconfig/iptables ABOVE the line with --dport 22 ACCEPT, add this:

-N blocksshd
-I INPUT -p tcp -m tcp --dport 22 -j blocksshd

Or might be this if it matches your firewall:

-N blocksshd
-I RH-Firewall-1-INPUT -p tcp -m tcp --dport 22 -j blocksshd

I want to make specific mention here to be very careful with your firewall, especially if you're working on a remote machine.  And it would be ideal to add these lines in some way other than directly editing the iptables script, but I don't know of another way.  If you later edit your iptables with the system-config-security tool, you'll have to make sure these lines weren't lost as blocksshd does not function without it.  See the blocksshd readme or install documentation for more information.

Now we can restart iptables and start blocksshd! 

# service iptables restart
# service blocksshd start
# chkconfig --level 345 blocksshd on

(FYI I see a small error with the init script when it runs, but I think it's harmless as everything seems to work..)

One suggestion I might make is that you make sure you remain ssh'ed into the machine while testing the script.  I would set the block timeout to a low value in the config file temporarily so that you can test to make sure that blocksshd is working.

Once things are working, you'll want to tweak the config file, especially add networks into the whitelist so that you're less likely to get locked out of your own machine.

I've recently started putting my laptop to sleep after being idle 45m, and then I get curious how long it's been asleep, etc.  So I wrote a perl script to keep record for fun.

This is called in my suspend script before suspend with the suspend argument, after the script with the resume argument, then with the sleeptime argument.  So basically what it does is record a suspend record before the laptop suspends, then after the laptop resumes it writes a resume record, then prints the last suspend time (difference between the two events) in a friendly format.  How this will be configured for your particular installation I can't say, as I have my own custom suspend script.  But figure out where the laptop goes to sleep and when it wakes up and you should be able to insert the lines appropriately, it's pretty simple really.  You can see my suspend script on this page as an example.

The script is available here, and is fairly well self-documented.  It is written in Perl and is licensed under GPL v3.

Tip!  If you use KDE, you can even pop up the suspended time on the screen after restore.  See my suspend script on this page to see how I do that. 

Example output:

# ./sleeptime sleephistory
(00:01:07:23) Asleep 1 hours 7 minutes 23 seconds
(00:01:05:41) Asleep 1 hours 5 minutes 41 seconds

Seems a lot of laptops don't support ACPI battery alarms, you can cat /proc/acpi/battery/BAT0/alarm to see if yours is supported.  If so, handle it in an ACPI script.  However, if your laptop is like both of mine, read further.

This script checks to see if the battery is discharging (off AC), then compares the critical battery level with the current level.  If the level is critical, begin a shutdown in 5m.  If AC is restored, the shutdown is aborted.  The script also creates a flag so it won't run itself multiple times, so you can have this script in a cron file without worries of it running multiple times.

You very likely will need to adjust the  LOGGER, BAT_INFO, and BAT_STATE variables at the top of the script to match your particular laptop.  If you have multiple batteries this script will need work I expect.  It's suggested you test the script by changing the $LOGGER entries to echo's and comment out the shutdown command.  Probably change the sleep time, inject a fake $REMAINING value, etc.  Hopefully it will work without changing anything besides the variables listed above.

I suggest you put this script in cron on a five minute check, that should be enough time to safely shut the laptop down.  This suggested configuration would mean at least 10m of critical battery run before shutting down, and possibly as much as just under 15 minutes if the critical level is reached right after the last run of the script.  If your laptop drains faster or needs a faster response time, you might consider having this script run every minute on a cron and/or shortening the shutdown time from 5m to 1m.  One minute may or may not give you time to get to the AC adapter to get the laptop plugged back in, so consider time necessary unless you want the laptop to shut down.  You might also want to add some sort of alert to the script where noted in the script, such as sending an email or an SMS. 

You can grab the script here, let me know if there are any suggested changes, bugs, etc.   I've updated the script to include a reference to my suspend script noted in the V100 section for suspend to disk instead of system shutdown.

Version 1.0 

Here's a script I recently wrote to warn me when disk space is getting low.  There are probably others out there, including some large things like Nagios, but this is small and simple and does what I need.  I put this in an hourly cron.

The script is here, it works for me on Red Hat and CentOS Linux, your mileage may vary.