blog.arithm

If you find yourself upgrading a wicked old Fedora distro, you may run across an error like this:

Error: Package initscripts needs kernel < 2.6.12, this is not available.

Try upgrading your kernel. To upgrade your kernel, make sure that only the latest version is hanging around. Because of a bug in legacy versions of yum, any older versions of the kernel must be removed.

To check your installed kernels, run:

$ rpm -qa | grep kernel

Note that if you simply run “rpm -q kernel”, you may miss smp kernels or other. The above will give you a complete picture. Remove all except the very latest version, then run yum update.

As it only transfers deltas between source and destination files, rsync is a great backup tool when working with uncompressed data. The structure of compressed data, however, can change drastically between backups, defeating the benefits of rsync. I’d read somewhere recently, however, that bzip2’s “blocking” design might make it a viable compression to use with rsync. Ran an ad hoc experiment this morning to check this out.

Uncompressed Data

Here are the results from rsync’ing an uncompressed MySQL database with a few minor record changes.

total: matches=1634 hash_hits=2136 false_alarms=0 data=21227
sent 6.73K bytes received 9.92K bytes 6.66K bytes/sec
total size is 2.69M speedup is 161.44


Nice. Only about 7K transferred. Roughly the size of the change.

bzip2 Compressed Data

And here are the results from rsync’ing the same MySQL database, compressed in advance with bzip2.

total: matches=596 hash_hits=17533 false_alarms=1 data=876602
sent 876.99K bytes received 7.73K bytes 353.89K bytes/sec
total size is 1.64M speedup is 1.85


Woah! What amounts to about a 7K change is resulting 10x the data transfer.

Which makes sense, as — digging into the details of bzip2 — I see that the bzip2 algorithm chunks data in 100K - 900k blocks.  So I suppose that using bzip2 might make sense if you have an incrementally growing data store that adds about 100K of data between backups; and where the older data rarely, if ever, changes.  Barring that, to achieve the benefits of rsync, uncompressed data is probably the way to go.

That said, there seems to be a version of gzip with an --rsyncable switch for Debian.  The BeezNest has a great article on this here.

I ain’t never going to remember this, so into the blog it goes:

$ chsh -s /path/to/fish

Masochists should substitute “fish” for whatever less friendly shell they prefer.

Thanks to the little Cygwin setup/upgrade app, I periodically come across useful new utilities.  For example, even though I’ve only been playing with these two for a couple of days, I’m already wondering how I ever did without them.

multitail

multitail renders multiple tail logs in an ncurses-formatted window. Perfect for monitoring access and error logs at the same time.  Much better than interleaving multiple logs with tail.  Now I don’t have to squint through output in an attempt to figure out which data is from which log.

since

since is tail with a memory. Whereas tail displays the last 10 lines (or whatever value you define with -n/--lines) of a file, since starts from where you left off the last time you ran it. This is an excellent tool for when you you’re toggling between watching a log, tweaking configuration parameters, and then returning to log monitoring.

Going to have to upgrade Cygwin more often.

You login to a mysterious new box. There is no login message. You poke around and before long you start to wonder “So what the heck distro is this anyway?”

$ uname -a
just tells you all about the kernel. Hmmm.  A mystery.

To pull up details on the distribution, take a peak in /etc/issue. This text file is often what is presented to users after they login, and typically contains distribution specific details. Likewise, look for /etc/*release or /etc/*version, which various distributions use to tag the release version.

Elementary!

After doing an emerge world on an older box I get:

* Messages for package sys-libs/com_err-1.40.4:

* PLEASE PLEASE take note of this
* Please make *sure* to run revdep-rebuild now
* Certain things on your system may have linked against a
* different version of com_err -- those things need to be
* recompiled.  Sorry for the inconvenience

In other words, “This update is going to break your system. We kind of screwed up. Something changed. Here’s how to fix it.”

So now I don’t have to google around frantically trying to figure out why randomserviced is suddenly failing. And the Gentoo guys even apologize.

Honesty, transparency, and humility in software. Go figure.

Easier to configure than I thought it would be. The defacto document on this lists a series of convoluted steps to get UTF-8 working.  All you really need to do is as follows:

1. Launch the local configurator via # dpkg-reconfigure locales
2. Select the locales you would like to support. I need Japanese support so I selected ja_JP.EUC, ja_JP.UTF-8, and en_US.UTF-8 in addition to already available locales. Click “Ok”.
3. Choose the default locale from the list; make sure it is a UTF-8 locale. Click “Ok”.
4. Login to another shell.

That’s it!

# locale charmap should now return “UTF-8″.

I have a new favorite shell: fish.

Fish is awesome for variety of reasons, but primarily because Fish:

1. Emphasizes command and parameter discovery, as well as overall usage transparency with truly useful default settings, over tweakability.  (After all, who really has time to trick out the shell on every damn box you log into?)
2. Has extremely powerful default tab completion and history search.
3. Highlights syntax with pretty colors.
4. Has multiline editing that actually works.
5. Simplifies directory navigation.  (Aspects of which remind me of the old AmigaDOS CLI.)

Be sure to check out the fish change log for insight into recent-ish enhancements.  Some very cool though obscure features in fish.

Looks like mktemp is now provided by coreutils.  No wonder.  This block has been bugging me (read: I’ve been ignoring it) for months.

To fix just unmerge mktemp and update coreutils.

Update: Same for the setarch / util-linux block should you come across it.  Unmerge setarch.

This post comes via notes taken from another blog… seemingly gone awol.   Here for posterity.

Etch naturally has an older version of WordPress.  To upgrade to a more recent, possibly though unlikely more secure version,  the easiest way is to change your tracking to testing, install WordPress and then change back.  How to do it:

1.  Edit your /etc/apt/sources.list to track testing. If your sources.list says etch or stable, change that to testing.  For example if your source.list has:

deb http://debian.lcs.mit.edu/debian etch main contrib non-free
deb-src http://debian.lcs.mit.edu/debian etch main contrib non-free

change those to:

deb http://debian.lcs.mit.edu/debian testing main contrib non-free
deb-src http://debian.lcs.mit.edu/debian testing main contrib non-free

2.  After you change your tracking to testing do an apt-get update.

apt-get update

3.  Install WordPress

apt-get install wordpress

this may pull in a few new php libraries, such as libphp-phpmailer.  Let it.

4.  Change your tracking back to Etch. just reverse what you did in step 1. that is change testing back to etch.

5.  Clean everything up.

apt-get clean && apt-get update

After all this is done, login back in as admin to wordpress, and it will tell you that you have to update your WordPress database tables.  Do that and you’re done.