Home » Monthly archive

February 2010

Experimenting with Drupal

I'm heavily experimenting with Drupal. I have 95 or so modules I want to experiment with, which is just too cool! The more modules, the more obvious it is that this thing might actually turn out to do exactly what you wish ;-)

For now, I'm looking for a good case tracker, issue tracker or you-name-it. Preferably one that integrates with organic groups, and/or user roles. It seems "Project" and "Project Issues" module are unsuitable after some initial testing -I'm not quite done with them yet, though. "Project" seems to be very specifically aimed at software projects with releases, whereas I just need a ticketing system for tasks, basically. I've done this before with "Support", so maybe that's what I'll end up using.

repo tag required

Just for fun, I started building ruby-1.8.6 and ruby-1.9.1 packages for Enterprise Linux 5. These would be opt-in repositories, "channels" if you will, fast-tracking an Enterprise Linux 5 box to newer versions of Ruby, and many of the packages that depend on Ruby one way or the other (such as Ruby on Rails packages, and many Ruby Gems).

I started out with the Fedora packages, obviously, and after getting a bunch of packages in said repositories, and testing and patching and rebuilding a bunch of times, it became obvious;

For the type of situation where you want two of these "fast-track" repositories, or even just multiple versions of the same packages built under different conditions, it turns out to be mandatory that a Koji build of a certain package contains a globally unique package NEVRA (Name, Epoch, Version, Release, Architecture), so they can be distinguished between the two (very much different) versions of the package. That is to say, one package NEVRA can only be built once, and can only be duplicated to other destination tags.

Example: The ruby-shadow package (a requirement for Puppet, which makes it very important to me) is binary compiled, either against ruby-1.8.6 or ruby-1.9.1. For one version (e.g. upstream's 0.9.7) to be available through both repositories, one builds ruby-shadow-0.9.7-1.el5.src.rpm.

I build the package against two Koji build targets, each one using a build tag that causes a buildroot to be created with either ruby-1.8.6 or ruby-1.9.1; in my case these build targets are feature-el5-ruby-1.8.6 and feature-el5-ruby-1.9.1.

Koji however will only allow one specific package NEVRA to be built just once. But, ruby-shadow-0.9.7-1.el5.src.rpm has to be built twice; once for ruby-1.8.6, and once for ruby-1.9.1. Since one build with the same NEVRA already exists, another cannot be built.

Ergo, you need some kind of indication of the build-root/build-tag/destionation-tag in the package NEVRA...

And we go off rebuilding everything again... ;-)

Koji lessons learned

Note to self: when using external repositories and building on those, please remember that priorities in tag inheritance does matter.

Thank you.

Novell gives away Certified Linux Administrator certification to LPIC-1

If you have level 1 Linux Professional Institute certification, you can get Certified Linux Administrator from Novell for free:

  1. Go to the LPI login-page and login with your LPI ID or email address.
  2. Click on "Verify Certification" and then "certifications" near the bottom of the page.
  3. Copy your LPI ID and the Verification Code for LPIC-1
  4. Go to Novell Certified Linux Administrator Certification Registration Form
  5. Fill out the form and press "Continue".
  6. Congratulations!
  7. Ask your employer for that raise he promised you in case you would obtain (yet another) certification.

Have fun!

Zarafa in Fedora 11, 12, rawhide and Extra Packages for Enterprise Linux

I'm very much pleased to be able to announce that Zarafa, one of the best Linux groupware suites, is now available through the standard Fedora and EPEL repositories.

After Zarafa itself had already announced inclusion to the repositories, news that was dented through major news sites such as heise.de, Robert Scheck and myself sat together at FOSDEM and worked on the packaging until we were both sufficiently satisfied.

It's currently set up to allow the maximum amount of flexibility one could ever wish for. Normally, the packages provided by Zarafa consist of the backend server, gateway (IMAP/POP), the PHP libraries needed for the Webmail interface, and too many other things to really build up a scalable infrastructure without installing all capabilities on all servers in such infrastructure -which introduces it's own world of pain.

Now, apparently, we still need to figure out some things. For one, I get a SIGPIPE / Broken pipe when I run zarafa-server with UNIX passwd authentication. The availability of a platform like Fedora (fast-pace moving forward) allows us however to solve this kind of issues way before Enterprise Linux 6 hits public beta.

You gotta love it!

Re-Blog: ATTENTION

On February 9th, Mike McGrath wrote:

Toshio Kuratomi is awesome.

That is all.

+1 Mike, and so are you!

Today: sysadmin-main for ogd.nl

Today is the day we come together with a bunch of Linux experts, and start knocking down some of the items on our TODO list, as well as -hopefully- share more information and responsibility on the overall Linux infrastructure inside our company, and the Linux infrastructure at a lot of out customers both!

Zarafa and undefined symbol

I've always been a huge fan of Zarafa, one of merely two serious competitors in the Open Source groupware market.

The other competitor is Zimbra, but I have somewhat less of an incentive to sink my teeth into that Java mess, which installs in /opt/zimbra/, and uses it's own vendored libraries rather then those available in the system stack. This, in my opinion, is just wrong, raises cost and gives you less overall options and control. But enough about Zimbra, because obviously the suite *just works* (and a lot of people are very much happy with it).

I have (and still am) running Zarafa at my company for about a thousand users, and Zarafa's headquarters are pretty close to my company's. I get to speak to Zarafa's people regularly, and most of it is while I'm wearing my Fedora hat ;-)

Either way, now that Robert Scheck and myself are attempting to package Zarafa for our dear distribution, Robert and I run into the following when using Fedora 12:

[jmeeuwen@ghandalf SPECS.mine]$ sudo zarafa-spooler -F
zarafa-spooler: symbol lookup error: /usr/lib64/libmapi.so.1: undefined symbol: _ZN10ECMemTable6CreateEP14_SPropTagArrayjPPS_

Robert has created a topic on Zarafa's forum about this some time ago.

Let me first emphasize that Zarafa is upstream for three libraries:

  1. inetmapi
  2. perlmapi
  3. libmapi

This symbol is undefined in libmapi only, as you can see in Robert's comment.

I once succeeded (I don't know how) to make the command result in a stack trace:

[jmeeuwen@ghandalf spooler]$ gdb /usr/bin/zarafa-spooler
GNU gdb (GDB) Fedora (7.0.1-30.fc12)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/zarafa-spooler...(no debugging symbols found)...done.
(gdb) run -F
Starting program: /usr/bin/zarafa-spooler -F
[Thread debugging using libthread_db enabled]
Unable to open configuration file /etc/zarafa/spooler.cfg
Continuing with defaults
Wed 03 Feb 2010 03:53:54 AM CET: Unable to open pidfile '/var/run/zarafa-spooler.pid'
Wed 03 Feb 2010 03:53:54 AM CET: Starting zarafa-spooler version 6,30,9,18385 (18385), pid 7285
Wed 03 Feb 2010 03:53:54 AM CET: using SMTP server: localhost

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) thread apply all bt

Thread 1 (Thread 0x7ffff7fcb820 (LWP 7285)):
#0  0x0000000000000000 in ?? ()
#1  0x0000003d0da20ca9 in M4LMsgServiceAdmin::GetMsgServiceTable(unsigned int, IMAPITable**) () from /usr/lib64/libmapi.so.0
#2  0x0000003d0e259782 in CreateProfileTemp(char*, char*, char*, char*, unsigned int, char*, char*) () from /usr/lib64/libinetmapi.so.1
#3  0x0000003d0e259a3b in HrOpenECSession(IMAPISession**, char*, char*, char*, unsigned int, char*, char*, char*) () from /usr/lib64/libinetmapi.so.1
#4  0x0000003d0e259b29 in HrOpenECAdminSession(IMAPISession**, char*, unsigned int, char*, char*) () from /usr/lib64/libinetmapi.so.1
#5  0x00000000004069a1 in InitThreadData(thread_data*) ()
#6  0x00000000004075bd in ProcessQueue(char*, char*) ()
#7  0x00000000004078ff in running_server(char*, char*) ()
#8  0x000000000040d04e in main ()
(gdb)

I'm not at all too familiar with C/C++ code, and/or libtool (a more recent version of libtool in Fedora is rumored to have caused this?), and so my first step is to Google. Googling for "undefined symbol" doesn't really give you anything else then forum topics with questions and often not even solutions to very particular problems though :/

So, I turn to you, dear Lazyweb, and I'm asking you to help me wrap my head around it and put the finger on the sour spot.

SPEC: http://www.kanarip.com/custom/SPECS/zarafa.spec

SRPM: http://www.kanarip.com/custom/f12/SRPMS/zarafa-6.30.10-1.fc12.src.rpm

Thanks in advance!