I encountered this today when trying to query a package on a Red Hat server:

rpmdb: Lock table is out of available locker entries
error: db4 error(22) from db->close: Invalid argument
error: cannot open Name index using db3 – Cannot allocate memory  (12)

This happens when an operation involving the rpm db gets interrupted and the locks not cleared.  The solution is rather simple:

1.   Make a backup of /var/lib/rpm   (because you never know)

2.   rm /var/lib/rpm/__db.00*

3.   rpm --rebuilddb

You should have a working rpm databse now.

ServerSignature and ServerTokens are two variables that determine how the Apache server describes itself, which makes it useful to keep some secrets.   While obscurity is not security, it’s nevertheless a good idea not to save a potential attacker time by giving them the exact versions of everything you run on your server.

ServerTokens

ServerTokens describe how much information about itself Apache divulges, both in the HTTP headers, and in the signature on server-generated pages, such as errors and directory indexes.  Here are the possible settings and example values:

Full:  Apache/2.2.3 (Red Hat) mod_ssl/2.2.4 OpenSSL/0.9.7l DAV/2 mod_fastcgi/2.4.2 PHP/5.1.5 mod_jk/1.2.15
OS: Apache/2.2.3 (Red Hat)
Minimal: Apache/2.2.3
Minor: Apache/2.2
Major: Apache/2
ProductOnly:  Apache

ServerSignature

This describes how Apache refers to itself in server-generated pages.  Possible values are On, Off or EMail.  On will give a message like:

Apache Server at www.somerandomstuff.com Port 80

Where “Apache Server” is the result of the ServerTokens value.  Setting ServerSignature to EMail, will give something like (note the mailto link):

Apache Server at www.somerandomstuff.com Port 80

And finally, setting it to Off, will show nothing.

Today I got tasked with removing duplicate mails from a mail folder with over 100,000 mails in it.  Doing this from a mail client is so impractical, it’s not even worth giving any thought at all.  Fortunately, the mailbox is on a mail server using Maildir style mailboxes, so I knew this could be done with minimum effort.

I discovered the ‘reformail’ utility, part of courier-imap, and after a few trial runs, I settled on the following:

# cd /path/to/mailbox/Maildir/cur

# for i in `find . -type f`; do reformail -D 10000000 /tmp/duplicates <$i && rm $i; done


-D looks for, and deletes duplicates.

10000000 is the length of the temporary file where a list of message IDs will be written

/tmp/duplicates is the aforementioned temporary file.

The temporary file needs to be big enough to accommodate the message ID of each mail.  In this particular case, I have found the average length to be 54 characters, but I would suggest using around double that to be safe.  So adjust to your needs.

In a big mail folder, and especially on ext3, this will take a long time to complete.

I recently decided to move my enormous mail archive from my trusty Courier-imap/Maildir setup to DBmail. The reason is simple.  I have several mail folders with 100,000+ mails in.  That means several directories with upwards of 100,000 files in.   And that means bad performance.    There is another reason:  I can execute far more powerful searches with an SQL query, than any mail client can allow me to do.

DBmail is a POP3/IMAP server that uses a regular database server (currently MySQL, PostgreSQL or SQLite) for its mail store.  Given the obvious advantages, I’m surprised this isn’t more popular.

There is one gotcha to the setup.  MySQL, being Swedish, has a default collation setting of ‘latin1_swedish_ci’ while DBmail assumes ‘utf8_general_ci’ will be set.  But the DBmail docs, and even the MySQL notes page, does not mention this* at all, and the included create_tables.mysql script does not set the correct collation either.   This results in the following error showing up in the logs:

Sep 14 03:00:01 hermes dbmail/maintenance[16708]: Error:[sql] dbmysql.c,db_mysql_check_collations(+138): collation mismatch, your MySQL configuration specifies a different charset than the data currently in your DBMail database.

This is easily fixed.  Assuming your database is called ‘dbmail’ do:

mysql> use information_schema;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed

mysql> select * from SCHEMATA where SCHEMA_NAME = ‘dbmail’;

The ‘DEFAULT_COLLATION_NAME’ column will most likely show ‘latin1_swedish_ci’ – this is the problem.  Run the following:
mysql> alter database `dbmail` collate `utf8_general_ci`;
Query OK, 1 row affected (0.02 sec)

Run the select query again and check if the right collation is showing.  After doing this, dbmail should connect to MySQL without any problems.

After doing some updates on my Debian Lenny workstation, I noticed that KDE’s Konsole is no longer able to find the “Console” font, and upon trying to install it, I’m greeted with an error saying:

Could not install console8x16.pcf.gz into fonts:/Personal/
Fortunately, this is easily fixable. As root, run the following:

# dpkg-reconfigure fontconfig-config

Choose the default option to all but the question about bitmap fonts – choose YES here. This will enable support for bitmap fonts. Then do:

# dpkg-reconfigure fontconfig

This will update the font cache. Now restart your Konsole, and your fonts should be back to normal.

Update 2009/03/07:   I had this happen to me again today (did a dist-upgrade to Squeeze) and after running the above fix, only one of the two missing fonts returned.   I found that removing the contents of ~/.fontconfig/ does the trick.

Update 2009/07/25:   I got a new PC at work, and this time did a clean install of Squeeze, which meant getting dumped into KDE4.  Again, the font was missing, and the font installer wouldn’t see the pcf file.  I had to do the above, and then, using the font installer, had to type *.pcf  in the filter field – this installed the font.  I also had to set font anti-aliasing to “enabled” instead of “system settings” in the System Settings panel –> Appearance –> Fonts.

I use an AMOD AGL3080 GPS logger in my photography. For a few days now, I cannot get it to do anything. The storage light stays on, but nothing happens. I thought that I’m out of disc space, maybe the trash is taking up all the free space? But that seemed not to be the case – I had 112MB free.

Today I got to look at this more closely for the first time. In the .Trashes directory, there is a ’501′ directory, and under that, I get the following:

# ls -lha
ls: QžÇØ\026gYø.œ?\036: No such file or directory
ls: ýdßÞæer˜.^ín: No such file or directory

# rm *
rm: cannot remove `QžÇØ\026gYø.œ?\036′: No such file or directory
rm: cannot remove `ýdßÞæer˜.^ín’: No such file or directory

Eventually, I gave up and plugged it into a linux box. Now the ’501′ didn’t show up as a directory any more, but as a file. rm -rf, unmount it, switch it on, and what do you know, it’s working! I’m not sure if just deleting the 501 from the terminal in OSX would have worked, it probably would have. I just find it strange that it showed up as a directory and not a regular file.

I get this kind of problem every day: “We’ve run out of disc space on our Plesk server – what’s taking up all the space?” The answer, almost every time, is “logs.” Plesk doesn’t enable log rotation by default, so logs can end up taking a lot of space.

Continue reading »

Geo Visitors Map © 2010 Some Random Stuff Suffusion WordPress theme by Sayontan Sinha