ERROR 1045 (28000): Access denied for user ‘debian-sys-maint’@’localhost’ (using password: YES)

Another error message from the attempt to move an existing MySQL installation to a new server, this time caused by the import of all the old users from the old server. debian (and Ubuntu) adds their own user to the server to be able to perform upgrades and other maintenance through automagical scripts. The password that debian (or Ubuntu) uses to connect to this user is stored in a file on the local file system: /etc/mysql/debian.cnf.

This file contains the current password for the debian-sys-maint user, and if you’re moving all your users to a new server, be sure to also get this password from the file on the old server and copy it into the file on the new server. I strongly suggest copying just the password and not the whole file, as there may be new settings added to the file since you last upgraded the old server.

ERROR 1577 (HY000) at line 1: Cannot proceed because system tables used by Event Scheduler were found damaged at server start

After moving a complete SQL dump from a MySQL 5.0 server to a MySQL 5.1 server I forgot about any issues stemming from the different versions of MySQL. Importing the old information_schema tables and any possible changes for the mysql table itself made it barf out the error message “ERROR 1577 (HY000) at line 1: Cannot proceed because system tables used by Event Scheduler were found damaged at server start” when trying to connect to the server.

The connection were still made, but obviously something were afoot. A few pages hinted in the direction of using mysql_upgrade to upgrade the now 5.0-compatible tables to the 5.1 format, but mysql_upgrade didn’t seem to want to run (maybe because of a new root password / debian-sys-maint password). The solution was to tell mysql_upgrade to ask for a password, which user it should connect as and which server it should connect to. You should run this command as root (preferrably through sudo) so that it can run mysql_fix_privilege_tables with the correct permissions:

sudo mysql_upgrade -u root -h localhost -p --verbose --force

The --force parameter will make the command run even if it thinks your server already has been upgraded to 5.1 (or the current version if you’re reading this at a later time). It may think this if you’ve already performed parts of the upgrade, but failed when trying to do the mysql_fix_privilege_tables-bit.
And away we went!

Varnish: No ESI processing, first char not ‘<‘

I’ve spent some time setting up varnish for a service at work where we deliver JSON-fragments from different resources as a unified document. We build the resulting JSON document by including the different JSON fragments through an ESI (Edge Side Includes) statement in the response. Varnish then fetches these fragments from the different services, allowing for independent caching duration for each of the services, combining then into a complete document.

The main “problem” is that of Varnish 2.0.4, varnish does a check to see if the content returned from the server actually is HTML-based content. It does this by check if the first character of the returned document is ‘<'. The goal is to avoid including binary data directly into a text document. Since we’re working with JSON instead of regular HTML/XML, the first character in our responses is not a ‘<', and the ESI statement did not get evaluated. You can however disable this check in varnishd by changing the esi_syntax configuration setting - just add the preferred value to the arguments when starting varnish. To disable the content check, add:

varnishd … -p esi_syntax=0x1

I’m not sure if you can set this for just one handler / match in varnish as this solved our issue, but feel free to leave a comment if you have any experience with this.

Unbreak My Hea.. Firefox Ctrl Click Please!

When we launched Gamer.no over a year ago, we had to come up with a wallpaper advertising solution in a rush (everything were a rush back then as we built and launched a site from scratch (after disagreements between the previous owner and Gamer) in just under four days (or 96 hours)). While this solution has worked .. good enough .. it has always had a few irky bugs that I’ve never really had the right inspiration to uncover the cause of. Usually I’ve spent an hour and decided that the time wasn’t worth it at the moment and then moved onto something else, but today! Today is a glorious day!

The bug has been fixed!

The wallpaper element is placed around the main content div, which sadly also makes the wallpaper element receive any click elements that the main content div receives. This leads to the wallpaper getting clicked and the wallpaper ad window opening regardless of where people click – which will get very, very annoying very quick. So to battle this issue the original solution was to call .stopPropagation() on the evt object in a click handler for the main content div. This solved the issue and everyone rejoiced! However, all was not perfect in paradise.

Some time later we discovered that the .stopPropagation() fix borked ctrl-click a link in Firefox. Other browsers handled it just fine, but Firefox were obviously not happy. Not happy at all. Mad and going on a killing spree it shot down the proposed fixes from both myself and other people who had a brief look at the code. It wasn’t a big issue as we only run the wallpaper code for small intervals of time and people didn’t complain (maybe we were some of the few who had the issue).

Today I decided to have a look at the issue again, and finally I realized that we had been way to focused on our call to .stopPropagation(). Everyone had been planning how we could get .stopPropagation to do what we wanted it to do – after all – the issue was that stopPropagation didn’t behave when we ctrl-clicked in Firefox. But wait.

If you instead think of the original problem; the window.open gets triggered when people click the inner element instead of the outer, there may be alternative solutions to using stopPropagation. And yes, THAT was quite a simple fix. Instead of trying to stop the event from bubling up through the cloud.. let’s just set a status variable that tells the code handling the wallpaper click that THIS CLICK IS NOT FOR YOU BAD HANDLER GO AWAY LET OTHER GROWNUPS HANDLE THIS. So that I did.

$(document).ready(function () {
    innerClick = false;
    $('#wallpaper').click(function() {
        if (innerClick)
        {
            innerClick = false;
            return true;
        }
        
        window.open("..");
    });
    $('#content').click(function(evt) {
        innerClick = true;
    });
});

As soon as I actually spent some time on what we were trying to solve instead of what seemed like the cause of the issue .. everything went better than expected.

Blogging Each Day For A Month – The Results Show Redux

After I spent January posting an article each day I summed up my experiences in a post about how this had affected the traffic. As I noted back then the traffic to my blog is driven by search engines as I usually provide solutions to issues I encounter during my daily work. This means that the increase in traffic will be a bit delayed until the posts gets indexed and ranked accordingly.

I’ve added data points for february in the table below, originally seen in the previous post.

October January February
Visits 3 643 4 352 (+19%) 5 678 (+56%)
Pageviews 4 529 5 636 (+24%) 7 327 (+62%)

The average time spent on the site has adjusted itself to 58 seconds (one second down from the time in January) – which is within the bias. Nothing new here.

Obvious conclusion: more content that solves problems people have gives an increase in traffic. Not sure if anyone didn’t see that one coming.

svn: Can’t convert string from native encoding to ‘UTF-8’

The error “svn: Can’t convert string from native encoding to ‘UTF-8′” suddenly made it impossible to update one of the projects on our staging servers. The project contains loads of file under SVN control, and several data directories which up to this time wasn’t svn:ignore’d. One of the files in one of these directories had norwegian letters in ISO-8859-1 in its filename (which didn’t work in the project anyhow, as it was something left around from earlier).

This single file borked svn from actually being able to update or do anything useful with the actual files under SVN control. When Subversion analyzed the directory structure to check which files it should attempt to update, it would just barf before seeing any files with the error message about the file name not being in UTF-8. You’d think it would be better to ignore errors for filenames that aren’t a part of svn and that you’re not trying to add, but there’s probably a good reason for this behaviour.

Anyways: The solution: delete the file. We didn’t use it anyway. There’s also a good chapter in the SVN Book about localization issues which contain information about how you can solve the issue by changing your active character set.

gnome-web-photo segfaults (segment fault)! OH NOES!

We capture images from beautiful web pages all over the world by exposing the gnome-web-photo package through a simple web service. After moving the service to a new server today gnome-web-photo suddenly started segfaulting (aka segment fault).

Running the application as the same user as the web server worked (after fixing the home directory so that gconf etc was able to create its files), but when running in the web server process itself things segfaulted.

The next attempt was to run both the working and non-working version through strace and see what the difference were, and apparently things segfaulted when the working process accessed <home directory>.mozilla/. This was the first access to anything inside the home directory of the user, which provided the solution:

When the process was running under the web server, the HOME environment variable was not set, but while running under the user from the shell (through su -), it was present. gnome-web-photo (or Firefox?) apparently does not feature any sort of fallback if the HOME environment variable is missing and segfaults instead.

Maybe that could be a patch for the weekend, but hey, the Olympic Games are on!

Fixing dpkg / apt-get Problem With Python2.6

While trying to upgrade to Python 2.6 on one of my development machines tonight I was faced by an error message after running apt-get install python2.6:

After unpacking 0B of additional disk space will be used.
Setting up python2.6-minimal (2.6.4-4) ...
Linking and byte-compiling packages for runtime python2.6...
pycentral: pycentral rtinstall: installed runtime python2.6 not found
pycentral rtinstall: installed runtime python2.6 not found
dpkg: error processing python2.6-minimal (--configure):
 subprocess post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of python2.6:
 python2.6 depends on python2.6-minimal (= 2.6.4-4); however:
  Package python2.6-minimal is not configured yet.
dpkg: error processing python2.6 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 python2.6-minimal
 python2.6
E: Sub-process /usr/bin/dpkg returned an error code (1)

Attempting to install python2.6-minimal wouldn’t work, attempting to install python2.6 proved to have the same problem.

Luckily the Launchpad thread for python-central provided the answer: Upgrade python-central first!

:~# apt-get install python-central
[snip]
Setting up python2.6 (2.6.4-4) ...
Setting up python-central (0.6.14+nmu2) ...
:~#

Fixing Issue With PHPs SoapClient Overwriting Duplicate Attribute and Tag Names

The setting:

An SOAP request contains an Id attribute – and an element with the exact name in the response (directly beneath the element containing the attribute – an immediate child):


  foobar

The problem is that the generated result object from the SoapClient (at least of PHP 5.2.12) contains the attribute value, and not the element value. In our case we could ignore the z:Id attribute, as it was simply an Id to identify the element in the response (this might be something that ASP.NET or some other .NET component does).

Our solution is to subclass the internal SoapClient and handle the __doRequest method, stripping out the part of the request that gives the wrong value for the Id field:

class Provider_SoapClient extends SoapClient
{
    public function __doRequest($request, $location, $action, $version)
    {
        $result = parent::__doRequest($request, $location, $action, $version);
        $result = preg_replace('/ z:Id="i[0-9]+"/', '', $result);
        return $result;
    }
}

This removes the attribute from all the values (there is no danger that the string will be present in any other of the elements. If there is – be sure to adjust the regular expression). And voilá, it works!

Blogging Each Day For A Month – The Results Show

January has come to an end and in total I managed to blog each day except the 2nd and the 31st. I do not have a plan of continuing on that level, so I’ll probably slide back to the regular frequency of updates (1-2 a month) in the coming weeks. This spur of updates occured as I suddenly had inspiration to do five or six posts in an evening, actually making it possible to keep up the tempo for a couple of weeks. After a while things got a lot harder and I started to slide away from my regular posting time of 11am, but I got the posts out! Now it’s time to look at the stats for the previous month!

My blog is mainly search driven – I cover lots of one-off problems, attempting to include and descriptive error messages and other hints that people may use when they’re using Google to try to find an answer to a task they’re having problems with. This means that people don’t stay around to read other articles than the one they came here for, and so far this has meant that writing a new article usually has given me a small increment in traffic.

As December had the holidays – and searches for the terms I cover drop in large number during those days – I’m using the numbers from October 2009 for comparison. November is a day short.

October January
Visits 3 643 4 352 (+19%)
Pageviews 4 529 5 636 (+24%)

Time spent on the site increased with 7 seconds to 59 seconds – still nothing to write home about.