Blog of Leonid Mamchenkov

Last time I wrote about KDE 4, I said that it wasn’t very usable for me.  Recenlty, the much praised upgrade to KDE 4.2 became available via Fedora updates.  So I got it and switched to KDE for a couple of days.

What can I say?  Quite an improvement indeed.  Mostly stable, with only a few issues, which are nicely balanced out by nice desktop effects, overall graphics, and plasmoids.  A few things moved around and I had to look for them (such as keyboard shortcuts for switching between desktops), but overall it was a pleasant experience.

Why am I back to Gnome for now?  Because of the following:

• couldn’t manage to make KDE 4.2 work properly with two monitors (major issue)
• got a bit annoyed by KDE 4.2 not waking up properly from suspend  (not always, but often enough)
• also got annoyed by it not always coming back properly from screensaver mode
• couldn’t find graphical configuration for power managment (my laptop kept suspending when idle for 5 minutes with no power plugged in)
• a few other minor things here and there

I’m sure I’ll be back to KDE very soon.  The progress between KDE 4 and KDE 4.2 is huge and if it goes like this, then I won’t have to wait long.

It’s been bugging me for a while now that advanced search is extremely slow in our RT3.  I thought it was something related to the famous Perl bug, but apparently it wasn’t.  Then I was I waiting for Fedora 10 to come out, so that we’d upgrade our RT3 installation to version 3.8.  And that didn’t solve the problem either.  Finally, we got bored and annoyed enough by this problem to actually do soemthing about it.  The solution was, as often, just a Google search away.  Here is the quote from this discussion:

Faulty rights on a specific queue caused the owner list to be quite long, which RT didn’t like. (By mistake someone had given the own ticket right on the queue to all unprivileged users)

I went through all the queues to check the rights, and there it was - a test queue had “Own Ticket” assigned to “Everyone”.  Immediately, after remove this access levels things got back to normal.

If it so happens that your Fedora install suddenly fails to boot, giving some error messages or a simple “GRUB ” string, then I advise you to boot into rescue mode, install all updates, regenerate initrd image and reboot.  All should be nice and sweet now.

Those of you who need more info, scroll through Common Fedora 10 Bugs wiki page.

We upgraded our development server to Fedora 10 over the weekend.  Among other things, it runs RT3 - excellent support, issue management, and bug tracking tool.  Once the upgrade was over, we ended up with a semi-working setup of RT3.  The emails were going through just fine, but the web interface was giving out a blank screen with no content or errors or warnings.

Googled a bit, but that didn’t help a lot.   Went through server logs and found an out of memory shout from Storable.pm:

2325:Callback called exit at
../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/thaw.al)
line 415.

Googled for that, but it turned out that quite a few people have the problem with this module running out of memory.  And not only in RT3.

So I left it where it was and had some good night sleep.  And it helped.  In the morning, englightment came in, and I tried reloading the page with cookies and cache cleaned.  It worked.  And then it didn’t work again.  Cleaning cookies was helping for a couple of page views.  So I dived back into the RT_Config.pm file to see my options.  There it was.

=item C<$WebSessionClass>
C<$WebSessionClass> is the class you wish to use for managing Sessions.
It defaults to use your SQL database, but if you are using MySQL 3.x and
plans to use non-ascii Queue names, uncomment and add this line to
F<RT_SiteConfig.pm> will prevent session corruption.
=cut
# Set($WebSessionClass , 'Apache::Session::File');

Once I enabled Apache::Session::File, the problem went away.  We are now back to work, enjoying the new web 2.0 round corners interface, pastel colors, and more.

We’ve been doing some interesting things at work, as always, with yet more people and Linux boxes.  And of the side effects of mixing people, Linux boxes, and several locations is this need for some sort of centralized logging.  Luckily we have either syslog-ng or rsyslog daemons installed on each machine, so the only two issues seemed to be reconfiguration of syslog services for remote logging and setup of some log reading/searching tool for everyone to enjoy.

As for log reading and searching, there seems to be no end of tools.  We picked php-syslog-ng, which has web interface, MySQL back-end, access control, and more.  There were a few minor issues during setup and configuration, but overall it seemed to be OK.  I also patched the source code a bit in a few places, just to make it work nicer with our setup and our needs  (both numerical and symbolic priorities, preference for include masks over excludes, and full functionality with disabled caching).  In case you are interested, here is a patch against php-syslog-ng 2.9.8f tarball.

Once everything was up and running and we started looking through logs from all our hosts in the same place, there was one thing that surprised me a lot.  Either I don’t understand the syslog facilities and priorites fully (and I don’t claim that I do), or there is just too many software authors who don’t care much.  Most of our logs are coming in at priority critical.  Even if there isn’t much critical about them.  Emergency is also used way too much.  And there is hardly anything at debug or info or notice levels.  (RT, SpamAssassin, and many other applications seem to be using critical as their default log level).  Luckily, that  almost always is trivial to fix using either the configuration files or applications’ source code directly.