SysAdmin Adventures

It’s been a while since I posted anything useful, but hopefully this will make up for it.

A friend came to me asking for help configuring the backup of his remote LAMP server and I duly obliged, but ended up getting a little carried away. Some hours later I emerged with this bash script to do the job properly.

Called from cron, each time the script runs:

• It creates/updates a local rsync-copy of a remote directory.
• It runs a mysqldump to a file, named by date-stamp.
• Any archives or log files older than the user-specified expiry time (days) are deleted.
• All three operations are carefully logged to appropriate “.log” and “.err” files.
• The mysqldump, the rsync-copy and all the logs are run through tar.
• The tarball is run through a user-specified compression program (default: xz).
• The final archive is named by date-stamp.
• A summary file is created including highlighted errors and execution times for each step.
• The summary.log is (optionally) e-mailed to the backup administrator.
• The script cleans up after itself, deleting any superfluous log and mysqldump files.

In the end you have a configurable period of snapshotted-history for your LAMP server, all in small archive files, named by their date and with logs for every step of every backup and permanently-deleted file.

I recommend the script is called by cron like this (assuming midnight backup):

Which will also give you activity and error logs for the script itself.

If you wish to run the script manually from the command line to test it, you can set the output to verbose like this:

Ensure that lamp-backup.conf lives in the same directory as lamp-backup.sh and is readable and carefully configured.

DO NOT RUN THIS SCRIPT AS ROOT UNLESS YOU REALLY NEED TO AND HAVE TESTED YOUR CONFIGURATION AS A NORMAL USER.



You can get a copy of v1.0 (stable) of this script and associated config file from my subversion repository:

I will be working on it more soon, abstracting further, adding command line parameters and adding additional features that seem useful.

You can track the current version via the repository trunk.

Stumbled across the Rosetta Code site this morning. I can’t remember when I last discovered a site so unbelievably useful; especially for people like me who occasionally dip into languages and then don’t use them again for a long time.

http://rosettacode.org/

Rosetta Code is a programming chrestomathy site. The idea is to present solutions to the same task in as many different languages as possible, to demonstrate how languages are similar and different, and to aid a person with a grounding in one approach to a problem in learning another. Rosetta Code currently has 504 tasks, and is aware of 384 languages, though we do not (and cannot) have solutions to every task in every language.

A very good example from the site:

http://rosettacode.org/wiki/Reverse_a_string

Slackware-13.37 (and Slackware64-13.37) has been released today and I must say I’m extremely happy with it. I previously posted that I thought 13.1 was rushed, and it was, but this release is the polar opposite. Slackware-13.37 has been in beta for nearly two months and has been getting bugfixes, small updates and tweaks that whole time. I’m confident that this is quite simply the best version of Slackware ever to get through the stable door.

I want to personally extend my thanks to the whole Slackware team for their constant efforts to make the core of my infrastructure (and yours too) as good as it can be.

Want a copy now? Right now? Ok. Here’s the official torrents

Torrents for Slackware 13.37, 32-bit x86

• Install ISO disc 1 (A/AP/D/E/L/N, bootable installer, kernels, testing/, Slackbook)
• Install ISO disc 2 (F/K/T/TCL/X/XAP/Y, L source, /testing kernel source)
• Install ISO disc 3 (KDE, A/AP/E/F/installer source)
• Install ISO disc 4 (KDEI, /extra packages, source for D)
• Source ISO disc 5 (KDE/XAP source)
• Source ISO disc 6 (/pasture packages, K/N/T/TCL/X/Y source, USB and PXE installers)

• Slackware 13.37 x86 DVD ISO (everything)

Torrent for Slackware 13.37, 64-bit x86_64

• Slackware 13.37 x86_64 DVD ISO (everything)

The divorce was a long time coming. The papers are finally signed. Xorg has dumped hal and eloped with udev.

Keyboard layout modifications are back to (almost) normal – but instead of using /etc/X11/xorg.conf, we’re now using /etc/X11/xorg.conf.d/90-keyboard-layout.conf.

To change your keyboard layout from US to GB (for example):

Modify the file to replace:

Option “XkbLayout” “us”

With:

Option “XkbLayout” “gb”

.. just as you would have done a few years ago with xorg.conf.

In order to upgrade your multilib Slackware64-current box to a more recent -current (or perhaps 13.37):

1. Make sure you have a copy of the version you want to upgrade to available.
2. Make sure your slackpkg config points to it

Bear in mind that you need to know what modifications you’ve made to your system in the “clean-system” stage. slackpkg will offer to remove any package that’s not part of the version you’re upgrading to. If you need to keep any extra packages that you’ve installed you need to make sure you don’t uninstall them at this stage. For this reason I heavily recommend that you blacklist SlackBuilds.Org packages in the slackpkg blacklist file.

Sorry for the downtime over the last couple of days, people. My server decided to barf up its kernel while I was away camping and driving an M3 and a DB9 for my birthday. Typically, the server was only 5 days from its first uptime anniversary.

Normal service has now been resumed.

My company has been bought. While this means a lot of good and bad all over the place, it means one thing that’s very sad; I am about to commence work on tearing down the network I have so lovingly crafted over the last four years. Within a year I don’t expect there to be more than one or two Slackware boxes still running, if any. Black armbands please.

I was trying to build partclone to read an image created with clonezilla, and discovered it won’t build with XFS support on Slackware because Slackware lacks libxfs.h. I think this is somewhat intentional in that the XFS Makefile only installs the header if you explicitly target “install-qa”. It seems libxfs.h is only supposed to be used by XFS devs and 3rd party software should not require it, and I’m happy with that.

Just in case there is a reason you should need libxfs.h on Slackware:

You now have libxfs.h installed at /usr/include/xfs/libxfs.h

If you are building your own packages from SlackBuild scripts, then you need to make sure your umask is 022 before you start!

Because of the nature of the shared environment in which I work, I changed my default umask to 002 in /etc/profile. I’ve just discovered a big problem as a result. When directories such as $PKG/etc aknd $PKG/usr are created as part of the SlackBuild, they are created with file permission 775 as per the umask. Then when it comes to installing those directories from the package, the installer overwrites the permissions on the directories in your system with the permissions set in the package.

So, if $PKG/etc was created with 775, your /etc directory will be modified from 755 to 775 and this can do harm. This especially the case with directories such as /etc/mail which are checked by daemons for security before they run. If the permissions are too loose, the daemons don’t run.

Before you run a SlackBuild script, check that your umask is 022!!

I have a right pain of a problem in this network in that individual machines are slow to get network access at boot. I haven’t had the opportunity to properly find out why, but my instinct says the blame lies with the Allied Telesyn switches.

The big problem this causes is that any machines with a remote filesystem, such as an NFS share, in their fstab fail to mount the shares at boot; which means I have to manually ssh in and issue a mount command as root.

The solution is to ask rc.inet2 if it would kindly consider waiting just a little longer for the network to come up and not mount remote filesystems if it doesn’t.

The following patch attempts to ping an always-on host, preferably the host that serves the filesystem(s) you are going to mount.

• If a response is received, the boot process continues as normal.
• If there’s no response to the first ping:
  • A further 5 pings are attempted.
  • A countdown is displayed.
  • After 6 failed attempts boot continues, but with no attempt to mount remote filesystems.

rc.inet2.diff (download rc.inet2.diff.gz):

In order to apply the above patch, do the following as root:

Do not forget to manually edit your newly patched file to replace “<known up host, or remote filesystem server>” with a valid hostname or IP address.