mass deletion of wordpress comments

April 25th, 2013

Suppose you have hundreds or thousands of spam comments on your wordpress blog, and you want to delete them all.  You want to delete them in bulk, so you don’t have to click on them one by one or even page by page.  Fortunately, there is a quick and easy way to do it from the command line.  Here’s the outline:

  1. ssh to the machine that hosts the blog
  2. You need the name of the database user, the password for the database user, and the name of the database itself.  You can get them by reading /etc/wordpress/config-$ServerName.php … then make a note of them in a safe place.
  3. mysql -ublogger -pSesameSwordfish123 blogger
  4. SELECT comment_approved,count(*) FROM wp_comments GROUP BY comment_approved;
    | comment_approved | count(*) |
    | 0                |     1046 |
    | trash            |      140 |
    # where 0 indicates pending comments,
    # and 'trash' indicates comments that have already been moved to the trash
  5. DELETE FROM wp_comments WHERE comment_approved = ’0′;
    Query OK, 1046 rows affected (0.06 sec)
  6. DELETE FROM wp_comments WHERE comment_approved = ‘trash’;
    Query OK, 140 rows affected (0.01 sec)


virtual desktop layout clobbered by Ubuntu upgrade

December 4th, 2012

When I upgraded from one Ubuntu release to another, suddenly the virtual desktop layout changed from one row of four columns to two rows of two columns each.

It is possible to use ccsm to fix this, although it’s a bit of an adventure to find the settings you want.  For details, see workspace switcher preferences.

Note that you may have to apt-get install compizconfig-settings-manager before you can use ccsm.

Note that you can change this “on the fly” i.e. without having to kill / restart your gnome session.

Alt-Tab window switcher broken by Ubuntu upgrade

December 4th, 2012

After upgrading to a new Ubuntu release, I was suddenly unable to use Alt-Tab to switch from one window to another.

It is possible to repair the damage using ccsm.   I mostly agree with the suggestions at launchpad Bug #971051 … except that I recommend turning on the “static application switcher” (rather than the plain “application switcher”).  The static application switcher shows all the available windows at once, in a 2D grid arrangement.  (The other thing shows only a few of them, in a 1D tape arrangement.)

Note that you can change this “on the fly” i.e. without having to kill / restart your gnome session.

graphics acceleration snafu / Ubuntu upgrade

December 4th, 2012

When I upgraded from one Ubuntu release to another, graphics acceleration stopped working.  One symptom was the glxgears would not run.

With a little help from LIBGL_DEBUG=verbose glxgears I was able to figure out what it was looking for.

Workaround part 1: To obtain the necessary driver files I had to do apt-get install –reinstall libgl1-mesa-glx libgl1-mesa-dri

That was necessary but alas not sufficient, because the files got installed in a funny place.

Workaround part 2a: I had to cd /usr/lib64/dri/ and then ln -s ../../lib/x86_64-linux-gnu/dri tls I don’t pretend to understand the purpose of the “tls” directory, so using it in this way might incur some risk, but this is the cleanest workaround I know.

Workaround part 2b: An alternative might be to cd /usr/lib64/dri/ and then ln -s ../../lib/x86_64-linux-gnu/dri/* ./ This is a nasty kludge and is likely to break in the future, e.g. if anything ever gets added to the x86_64-linux-gnu/dri directory.

To summarize what has already been said:

Bug #1:  There is something wrong with the distribution upgrade process.  It should not have been necessary to reinstall those drivers.

Bug #2:  There is something wrong with the distribution itself.  The various graphics packages need to get their act together, so that files are installed in the place where they will be looked for … or so that files are looked for in the place they were installed.

Also: It would be nice if it were possible to set the search path that libGL uses, perhaps by specifying it in the $HOME/.drirc (which libGL already reads).  This would have made it possible to work around the other problems much more cleanly.

Another graphics-related issue is mentioned in the previous note.

fglrx follies / Ubuntu upgrade

December 4th, 2012

After upgrading from one Ubuntu distribution to another, almost all graphics features were broken.  This is on a Lenovo “IBM” Thinkpad W500.

Eventually I figured out that the ATI proprietary fglrx driver was not working.

I tried ./ati-driver-installer-…  –keep but that failed because it saw a previous installation.

I tried ./ati-driver-installer-…  –keep but that failed for obscure reasons.

ATI does not recommend –force, but I tried it anyway:  /ati-driver-installer-…  –keep –force and that succeeded.

Bug #1:  None of this should have been necessary.  It would be better if the fglrx driver were more robust, i.e. not sensitive to changes in userland software.  Note that I did not change operating system versions;  only the userland software got upgraded.

Bug #2: The –uninstall feature should have worked.

Another graphics-related issue is mentioned in the next note.

Ubuntu apt-get dist-upgrade fails

December 4th, 2012

Symptom: The last several times I’ve needed to upgrade from one Ubuntu distribution to another, the procedure has failed miserably.  The command apt-get dist-upgrade installed about half of what it was supposed to, and then stopped, complaining of conflicting dependencies.  This left the system in a nasty half-upgraded state.

Bug #1: Given that it was possible to upgrade these systems, apt-get dist-upgrade should have been able to find the solution automatically.

Bug #2: If it wasn’t smart enough to find the solution apt-get dist-upgrade should have detected the problem in advance, and should have not even started installing stuff.  This would have been vastly preferable to leaving the system half-upgraded.

Bug #3: The suggested solution was to run apt-get install -f which would have been a disaster.  It would have removed hundreds of packages, i.e. most of the software installed on the system.

Here is the workaround that I used.

  1. I did a  cd /var/cache/apt/archives which is where the downloaded .deb files live.
  2. I ran apt-get install (without the -f) and looked at the output.
  3. If two things were conflicting, and it looked safe to proceed, I installed the newer version by brute force:  dpkg -i –force-depends $package.deb
  4. Sometimes it was necessary to use even more brutish force:  dpkg -i –force-depends –force-overwrite $package.deb
  5. Every so often it was helpful to run apt-get upgrade or apt-get dist-upgrade … which would install some of the packages implied by the dependencies of already-installed packages.
  6. Usually that would blow up, in which case it was helpful to do dpkg –configure -a to finish configuring the stuff installed in the previous step.
  7. Every so often it was helpful to run apt-get install -f and see how many packages it was threatening to remove.  Usually it was still in the hundreds, in which case I would ^C out of apt-get and return to installing stuff by brute force.
  8. However, when it got to the point that apt-get install -f only wanted to remove a dozen or so packages, and they were all non-critical, I (a) made a careful note of the removed packages, (b) let the install proceed, and then (c) added the removed packages back in.
  9. After the foregoing hand-work got things back to a consistent state, I did another apt-get dist-upgrade which installed a bunch more stuff.

I am quite unhappy about how much time and effort this took.

How to stop Gnome Keyring from clobbering ssh-agent on Ubuntu Precise (and later)

December 4th, 2012

The desired behavior is as follows.  This is also the observed behavior in earlier versions of Ubuntu:  At the beginning of a gnome session, an ssh agent is automatically started.  It is inherited and shared by all tasks started within that gnome session.  In particular, if you add keys to it via one window in the session, the keys are then available in other windows.  The agent can be propagated to other hosts via ssh in the usual way.

Bug #1: The problem is that in Ubuntu 12.04 Precise and 12.10 Quantal, somebody got the idea of automagically starting the gnome-keyring-daemon.  This is very far from being what I want, for a number of reasons.  This is a problem because the environment variables that are used to implement the inheritance of the ssh agent get clobbered.

The symptom is that after you think you have set keys into your ssh agent, every time you try to use ssh a popup appears, demanding the password to your ssh keys, demanding them over and over again.

For me, the easiest workaround is the following patch:

— /tmp/old/gnome-keyring-ssh.desktop  2012-12-04 11:27:57.576563992 -0700
+++ /etc/xdg/autostart/gnome-keyring-ssh.desktop        2012-12-03 18:48:35.546654870 -0700
@@ -5,6 +5,7 @@
Exec=/usr/bin/gnome-keyring-daemon –start –components=ssh

After applying the patch, it is necessary to kill the current gnome session and start a new one (since the current one has already been clobbered).

For more on this, including a slightly different workaround, see the article by Andy at Dtek

Bug #2:  I would have liked to simply deinstall the gnome-keyring package entirely, but that is not so simple, because ubuntu-desktop depends on it.

A possible workaround is to create a dummy package that purports to “provide” the gnome-keyring feature but in fact provides no code.   It is rather easy to create dummy packages, but I have not tested this approach in this context.

Note: I have seen articles that try to blame this symptom on seahorse, but AFAICT seahorse does not contribute to the observed problems (or solutions).

perl code to convert base26 numerals to/from plain numbers

October 28th, 2012

I wrote some perl code to convert base26 numerals to/from plain numbers .  For example:

  • “A”   <==> 1
  • “Z”   <==> 26
  • “AA”  <==> 27
  • “XFD” <==> 16384

Note that base26 numerals are widely used for the column-name aka column-letter in spreadsheets such as gnumeric and excel.  The code can be found at

The code has been tested.  Self-test methods are included.

snake — probably Sonoran Night Snake

September 15th, 2012

On Friday 14-Sep-2012 I caught a small snake.   No guarantees, but I reckon it might be a Sonoran Night Snake i.e. Hypsiglena torquata.


My writeup, including additional pictures, is at

getting Apache and hostname -f to figure out the desired FQDN

August 12th, 2012

Symptom #1: Sometimes when you start or restart the Apache web server it says:

apache2: Could not reliably determine the server's fully qualified domain name, using for ServerName

Note that the logrotate cronjob restarts the web server, so you will get this message every time the logs get rotated.

Symptom #2: Sometimes the

hostname -f

command returns the bare hostname (e.g. “myhost”) rather than the desired FQDN (e.g. “”)

Analysis: It appears that Apache and the hostname command use the same mechanism to deduce the FQDN.  It appears to depend on the /etc/hosts file, as follows:

  1. Look for the bare hostname in /etc/hosts.
  2. There must be one and only one matching line.
  3. There must be an FQDN as the first entry on that line.

An example can be seen in the second line here:        localhost.localdomain    localhost     myhost

This mechanism has the side effect of assigning an  IP address to both the bare hostname and to the FQDN.  This is effectively a static assignment, since there is no nice way to dynamically update the /etc/hosts file.

Such a static assignment is undesirable in cases where the host has a dynamic IP address.  However, it is not as much of a problem as you might think.  My recommendation is to assign a locally-valid static address, such as in the example above … and then use dynamic DNS to keep track of the dynamic address that you get from your ISP.  If you set up your /etc/host.conf and/or /etc/nsswitch.conf files properly (and maybe even if you don’t), applications will see the DNS address, which is presumably what you want … to the exclusion of the /etc/hosts address.

Remark: The file /etc/hostname must contain only the bare hostname, not the FQDN.   Putting the FQDN in /etc/hostname might seemingly make the result of the “hostname -f” command look better, but only at the cost of making the result of the plain “hostname” command (without the “-f”) look worse.  Don’t do it.  Use the /etc/hosts trick as suggested above.