rootninja

The food and restaurant industry might be down across the board, but some areas seem to be doing quite fine. Amazon is reporting record sales this year. http://usnews.rankingsandreviews.com/cars-trucks/daily-news/081230-Amazon-Reports-Record-Holiday-Sales/

I was in a mall today and saw a line 20 deep in the food court for Taco Bell. People gotta eat, and they need their latest and greatest software too. I’m sure the net is lagging behind the economy, but in some regards I guess it might not turn out to be a bad year for Linux. I’m sure the usual suspects will be feeling a nasty bite soon and although they might not really have their hearts behind anything that has to do with free, according to Bruce Byfield, “when the talk turns to free and open source software (FOSS), suddenly the mood brightens. Whether their concern is the business opportunities in open source or the promotion of free software idealism, experts see FOSS as starting from a strong base and actually benefiting from the hard times expected next year.” http://itmanagement.earthweb.com/osrc/article.php/3793286/Linux+in+2009:+Recession+vs.+GNU.htm

Economy, Linux 2009, Economy, foss, free, gloomy, GNU, Linux, recession

Cron is so simple yet so useful I think it’s often unappreciated! Being able to toss a command into a cron, or execute a script at specific times of the day, days of the week, etc. That’s good stuff!

You could call a script that checks your mail once an hour, cleans out a temporary directory, or archives a special directory where you dump files to get saved without ever having to visit the server manually and tar/gzip the files yourself.

My latest use for cron is a nightly build script for building code checked out of subversion.  I’m doing this on my system for personal use, but also at work along with a python script i’m writing that also runs from a cron a few hours later.  It parses the build log looking for errors.  If it sees errors, it sends them out in email.  Python is wonderful… /off topic.

# +———— minute (0 - 59)
# | +———- hour (0 - 23)
# | | +——– day of month (1 - 31)
# | | | +—— month (1 - 12)
# | | | | +—- day of week (0 - 6) (Sunday=0 or 7)
# | | | | |
* * * * * command to be executed

If you want to run a script called check-for-rootkits.sh every 10 minutes, its as easy as:

*/10 * * * * /root/check-for-rootkits.sh

You could also get fancy and use “run as” to run crons as specific users.  Users can do this on their own (”crontab -e”), but you could force things to happen for them with your root crons if you wanted.  Fedora makes use of this for running hourly and nightly cron directories.  If you want anything to run along with the standard Fedora cron jobs, you just drop your script into those directories and they fire off alongside the defaults.

Linux cron, fedora, Linux, subversion

FSVS is the abbreviation for “Fast System Versioning” and is pronounced [fisvis].

It is a complete backup/restore/versioning tool for all files in a directory tree or whole filesystems, with a subversion repository as the backend. 

Using this application, all files(almost) in /etc/ are maintained in a subversion repository. As files get created in /etc/ they are added to the repository automatically. commit’s to the repository are executed on a daily basis with a cron job in /etc/cron.daily.  Configuration creation, updates, and deletions are easy to see and track down long after the fact, eliminating questions like, “When did this get changed?? and what the heck did it look like before!?”

• fsvs does not pollute directories with .svn folders.
• It keeps track of everything with file lists and hashes in /etc/fsvs/ and /var/spool/fsvs/
• All fsvs repositories can be stored in one place to make it easy to back up.

I think of it as a safety parachute, incase the regular one doesn’t work. (my regular method of backing up a config is to copy the original file with the extension “.old”, “.bak”, or “.orig”)

How to install it

Commands to run from the subversion server, “TheServer”

# yum install fsvs
# mkdir /RAID/fsvs_repos
# svnadmin create /RAID/fsvs_repos/TargetHost

Commands run from the client machine, “TargetHost”

# yum install fsvs
# cd /etc   ($pwd must be the base directory you want to use to populate the repository)
# fsvs urls svn://theserver/fsvs_repos/TargetHostName  (this points to the berkley db you just created on “theserver”)
# fsvs ignore ./fsvs
# fsvs ignore ./ld.so.cache
# fsvs ignore ./prelink.cache
# fsvs ignore ./lvm
# fsvs ignore ./localtime
# fsvs ignore ./.pwd.lock
# fsvs ignore ./selinux
# fsvs commit -m “Initial fsvs commit”

Daily cron commit setup

A one liner cron in /etc/cron.weekly/fsvs.cron should be all you need.

/usr/bin/fsvs commit -m “cron commit at `date +%R_%d-%m-%Y`”

Linux backups, cron, etc, fsvs, Linux, subversion, svn

In a shell script you’re probably testing a variable against some constant or another variable, but why not run a command in a subshell and compare the output?  You could even compare the output of two subshell commands!  I guess most of the time i’m doing something like this i’m using perl or python.  But I needed a way to double check which disk had a powerpc boot partition on it before copying it over to a blank disk and I didn’t have much to work with on those old boards, so I whipped this up right quick:

#!/bin/sh

#check to see if sda has a PPC boot partition

if [ "`/sbin/fdisk -l /dev/sda | grep PPC`" == "" ]; then

if [ "`/sbin/fdisk -l /dev/sdb | grep PPC`" == "" ]; then

echo “both disks have PPC boot partitions”

exit 1;

else

echo “run this: dd if=/dev/sdb of=/dev/sda”

fi

else

if [ "`/sbin/fdisk -l /dev/sdb | grep PPC`" == "" ]; then

echo “run this: dd if=/dev/sda of=/dev/sdb”

else

echo “both disks have PPC boot partitions”

exit 1;

fi

fi

Shell scripting if-then-else tests with commands embedded in backticks.  Why?  Because i’m messing with some old power pc blades running 2.4 kernels with no modern day apps like ssh, rsync, or python.  I don’t know why I didn’t think of this before now?

Linux 2.4, if-then-else, kernel, Linux, ppc, shell scripts

I don’t understand why some people think this is a complicated thing to set up, so here goes my approach which I think is the easiest method.  Perhaps you’re behind a very restrictive corporate firewall or you want to conserve bandwidth when you’re setting up several machines.  You can set up your own repositories on one machine in your network and have it download the packages and updates in the off-hours.  Whenever a client machine on your network wants updates, they’ll get them much faster and you’ll save bandwidth too.

Step-by-step:

Install createrepo on the machine you want to be your update server.

[user@hostname ~]$ sudo yum install createrepo

Now you’ll create a few crons to create and maintain your mirror.  Let’s start with the one that does the grunt work of downloading the packages.  I’ll go ahead and set a bandwidth limit and log my mirroring.  I don’t care about debug stuff so i’ll exclude that and any iso’s that may get dumped in there too.

#!/bin/sh
# GET THE LATEST PACKAGES
/usr/bin/rsync -aq –bwlimit=500 –stats –log-file=/var/log/rsync/i386.rsync.1.log rsync://your-favorite-linux-mirror/linux/updates/9/i386.newkey/ –exclude=debug/ –exclude=*.iso /opt/yum/updates/8/i386/
/usr/bin/rsync -aq –bwlimit=500 –stats –log-file=/var/log/rsync/x86_64.rsync.1.log rsync://your-favorite-linux-mirror/linux/updates/9/x86_64.newkey/ –exclude=debug/ –exclude=*.iso /opt/yum/updates/8/x86_64/

Create a cron to update your repo as new rpms get mirrored.

#!/bin/sh
# CREATE/MAINTAIN MY LOCAL REPOSITORY
/usr/bin/createrepo –update /opt/yum/base/8/i386
/usr/bin/createrepo –update /opt/yum/base/8/x86_64

Create another cron to rotate your logs, saving the last week’s worth.

#!/bin/sh
# ROTATE THE LOGS
rm -f /var/log/rsync/yum-rsync-log7.tar.gz
mv -f /var/log/rsync/yum-rsync-log6.tar.gz /var/log/rsync/yum-rsync-log7.tar.gz
mv -f /var/log/rsync/yum-rsync-log5.tar.gz /var/log/rsync/yum-rsync-log6.tar.gz
mv -f /var/log/rsync/yum-rsync-log4.tar.gz /var/log/rsync/yum-rsync-log5.tar.gz
mv -f /var/log/rsync/yum-rsync-log3.tar.gz /var/log/rsync/yum-rsync-log4.tar.gz
mv -f /var/log/rsync/yum-rsync-log2.tar.gz /var/log/rsync/yum-rsync-log3.tar.gz
mv -f /var/log/rsync/yum-rsync-log1.tar.gz /var/log/rsync/yum-rsync-log2.tar.gz
mv -f /var/log/rsync/yum-rsync-log.tar.gz /var/log/rsync/yum-rsync-log1.tar.gz
tar -czf /tmp/yum-rsync-log.tar.gz /var/log/rsync/*.log
rm -rf /var/log/rsync/*.log
mv -f /tmp/yum-rsync-log.tar.gz /var/log/rsync/

On your client machines, move or delete the existing repo definitions and create a new one that points to your local repositories.  Assuming your server machine’s IP address is 192.168.1.2 and you’re using Fedora your new repo definitions would look something like this:

[fairfield-base]
name=My_Local_Repo - base - Fedora $releasever - $basearch
failovermethod=priority
baseurl=http://192.168.1.2/yum/base/$releasever/$basearch
enabled=1
gpgcheck=1

[fairfield-updates]
name=My_Local_Repo - updates - Fedora $releasever - $basearch
failovermethod=priority
baseurl=http://192.168.1.2/yum/updates/$releasever/$basearch
enabled=1
gpgcheck=1

Wait until your cron fills your repositories or download a few packages and run your createrepo.  From now on your updates will execute much faster.  And if you want to build new machines, you can point your kickstart to get packages from your local mirror instead of just your cdrom so you can build machines that are fully up to date right out of the box.  Try updating on your clients.  You should notice it takes ten times longer to install the updates than it does to download them.

[user@hostname ~]$ sudo yum update

Linux Linux, packages, repo, rpm, rsync, server, updates, yum