Planet Ergo blogs

Your Passenger is Finally Ready for Boarding

jmeeuwen — Sat, 14 Apr 2012 13:55:17 +0000

After more than 3 years, the review request for package rubygem-passenger can finally move forward.

A bundling exception was finally granted, because someone is putting in the work to make the bundled, forked and patched version of Boost ultimately dissappear - by bringing the required changes upstream.

While I proposed doing so early on in the saga, though I could not do it myself and would have needed to find someone else to do so, that wasn't acceptable - as is tradition in the Fedora Project by now, the "discussion" on my plan of attack went absolutely nowhere, with people arguing in circles, simply for the sake of arguing, and without ever having been, being or feeling endangered of being involved in any way, shape or form.

Patience is golden, the cost of running Passenger in my own build systems can now be avoided. Time for 3.0.12 to be packaged for Rawhide, built against Ruby 1.9, and the review to move along!

Release Early, Release Often - Kolab 3.0 Web Administration Panel

jmeeuwen — Thu, 29 Mar 2012 15:03:20 +0000

One part we're doing some significant work on for Kolab 3.0 is the Kolab Web Administration Panel (or WAP, for short).

Again, you ask? You may remember the look-and-feel revamp Kolab Systems performed in Kolab 2.3 - this one is different though.

I hear you think, "Don't they all say that all the time?", and you're probably right. Pictures or it didn't happen, is what I would say. I'll do you one better; Want to click around yourself, perhaps?

Check out admin.klab.cc/~vanmeeuwen/kolab-wap/public_html/. Login with your full email address (not an alias, see bug #594), such as 'jeroen.vanmeeuwen@klab.cc', but not 'vanmeeuwen@klab.cc', and the same password you are using for our http://webmail.klab.cc demo environment.

Don't have an account yet? Don't worry. Send your givenname and surname to sysadmin-main+kolab@klab.cc and one of our admins will create an account for you.

Please note it is a work under construction, and this is a "Release Early" under the "Release Often" mantra. We have a list of known issues. Feel free to add one or two, the more the merrier.

Should you want to try yourself, perhaps against your own Kolab Groupware (test?) installation, please clone the GIT repository like so:

$ git clone git://git.kolab.org/git/kolab-wap

and follow the instructions in the INSTALL file. Note that you will need a MySQL server, and a system that allows you to have an /etc/kolab/kolab.conf file in .INI format (that means, no installing this on existing OpenPKG Kolab 2.3 servers) - work is undergoing to document the full extent of the configuration options available. An example is available here.

Kolab Groupware 2.4 Documentation

jmeeuwen — Fri, 16 Mar 2012 12:32:10 +0000

Many people have been wondering why the documentation for Kolab Groupware currently refers to version 2.4, and what that version 2.4 is all about. We have to take a couple of steps back in order to address the question, and review what has happened, and why.

Documentation... regrettably, it's one of those things that tends to lag behind the actual development and release of a software project. Perhaps it's because many people contributing to the software development have little interest in writing up how their software should or could be used. Perhaps some of the people that would write it all up do not have confidence in their documentation skills - perhaps a language barrier is a part of that. In any case, so far, the majority of documentation for Kolab Groupware version 2.4 has therefore been written by yours sincerely, though admittedly parts of it are attributable to others who've created wiki articles on a particular subject, such as the chapter on Combatting Spam.

Kolab Systems, the vendor of Kolab Groupware, and the company that enables me to pay my bills, has a vested interest in the adaptability and continued development of the Kolab Groupware solution. We have found that, using the traditional deployment model for Kolab 2.3, and with the Kolab 2.3 code-base, integration into existing environments, scalability and redundancy had proven to be... suboptimal.

Suboptimal not in that it was impossible to do, but the code-base would have needed customizations that in turn would prove to be mutually exclusive with deployment in other environments, again spawning the need for customizations. This is a virtuous circle, but would have taken a very long time to increment in value and move forward. Long story short, for integration and adaptability purposes, the code-base needed some serious re-factoring.

The Kolab components we are speaking of mainly in this context would include the Kolab daemon, it's Kolab perl library, which is used by kolabconf, and the web administration panel. Inherently, the changes would also impact client software, such as Horde and Roundcube.

On August 26th, 2010, work on PyKolab began. Its goals were set out to be broad yet very clear; allow for sufficient option value to integrate with existing environments sustainably.

PyKolab, today, includes the following components;

Kolab daemon
Kolab SASL Authentication daemon
Kolab SMTP Access Policy
Kolab Content Filter
Kolab Command-line utilities
Format interpreters

All of this was, and still is, somewhat mutually exclusive with Kolab 2.3. It could therefore not be released as part of Kolab 2.3. Furthermore, Kolab 2.3 is product series for which the reference implementation continues to be OpenPKG, and that does not ship Python.

So, we're looking at something that is not Kolab 2.3 to ship PyKolab with. After some deliberations, it was decided that it could also not be called Kolab 3.0 as we were looking to make many other changes, many of which are outlined in the agenda for our last meeting on February 27th, that would, for most of them, each by themselves justify a major release (see KEP #5, "Server Product Versioning").

Because its availability had become urgent, it was decided to dupe the product series "Kolab 2.4". Perhaps, in hindsight, it was not the wisest of decisions, but it happened nonetheless.

So why were most of you not involved in this decision?

First, urgency - a specific customer needed the changes that were in PyKolab right-away.

Second, we had not yet defined any sort of process around development cycles, let alone agreed upon a set of processes with you, the community.

Third, the changes involved are significant. No, let me rephrase - the changes involved are extra-ordinarily humongous. An attempt to outline what was going on with the Kolab SMTP Access Policy implementation outlines the amount of confusion surrounding what was going on, but please allow me to illustrate some further shock-waves that would have hit the development mailing list too early;

The reference platform for server implementation is native packages on Red Hat Enterprise Linux 5 - not OpenPKG packages on Debian.
The reference implementation for the authentication and authorization database was the technical equivalent of Netscape Directory Server 7.2, and today is 389 Directory Server, not OpenLDAP.
Kolab 2.4 ships Cyrus IMAP 2.4 without any Kolab specific patches.
Kolab 2.4 does not use the Perl Kolab daemon, nor perl-Kolab, nor kolabconf, nor kolab_bootstrap.
Kolab 2.4 ships an LDAP schema that is stripped down (significantly) as to not include organization-specific schema extensions, and not include server configuration items.

All of this, the replacement of components you are comfortable with in Kolab 2.3, and development of new components and new features all needs documentation. This new documentation, of the software I have developed and we are using as the basis to work towards the future, Kolab Groupware 3.0, is what is on http://docs.kolab.org. Now you know why it refers to 2.4.

So why were most of you not informed about 2.4?

Kolab Groupware 2.4 requires a serious transition between what you run today, and what you would be running, regardless of whether you run an OpenPKG-based deployment, or native packages available through, for example, the Debian repositories.

Packages for distributions other then Red Hat Enterprise Linux are barely available, still - a shortage in resources contributes to this, and you, the community, is not yet participating in making anything happen in this area. This of course is quite a vicious circle as well. The changes involved require clear documentation - something I'm working on, but that'll remain a work in progress for quite some time to come. The setup process (you probably know as kolab_bootstrap) is not automated - something I'm working on. The Kolab web administration panel that is compatible with the other changes involved is under active development. Etcetera, etcetera.

How can you help?

The more things you throw back over the fence, the better. We'd like to do a good job, you know, and if you raise an issue you do not have to feel like you're also responsible for resolving it. Here's some ideas of what you could do.

Read the documentation at http://docs.kolab.org/.
I recommend starting with the Architecture and Design guide. It's only about 124 pages all-inclusive...
Let us know whether it makes sense, whether you understand what it says / what it is about, what you're missing, etcetera. If you don't understand what you read in the documentation, the issue is with the documentation. I recommend using the issue tracker to create tickets, or discuss on the development mailing list.
Help define how -you think- things should work.
You of all people know what you want better than anyone else. We're interested to learn about your use-cases, deployment scenarios, requirements. I recommend using the development mailing list for this.
Write documentation.
There's many things that currently require some text still. You'll recognize the blanks throughout the documentation currently available.
Writing documentation is one way to enjoy one of the steepest learning curves you'll ever get. Note that any documentation you do contribute doesn't have to be perfect right off the bat, language- or otherwise, it is a collaborative and an evolutionary process.
Give-It-A-Go(TM).
Follow the instructions in the Community Installation Guide using an Enterprise Linux 5 system, such as Red Hat Enterprise Linux 5, or CentOS 5 - for the part that has been completed. If you favor a different distribution or a different version, please consider contributing to the packaging effort. Contact me (RPM) or Christoph Wickert (APT) for more information. To avoid any confusion, Christoph is an excellent RPM packager as well, BTW.
Let us know where things go wrong or things don't make any sense.

Ten Reasons to Lock Your Desktop

jmeeuwen — Tue, 06 Mar 2012 11:15:04 +0000

You turn your attention away from your computer - you should lock your desktop. It is not just about level of trust you put in the people that you think may indeed gain physical access to your system. If like myself, you run a home office, physical access to your system is pretty restricted. If though, again like myself, you travel frequently and attend events, you better get used to locking your desktop as soon as your attention diverts away from the screen. Here's 10 reasons;

Privacy
Your desktop is your own, and what you choose to do on your computer is nobody's business. An open chat-window with a (girl)friend may hold contents that could make the people dearest to you believe something seems what it is not - I reckon all of us sometimes say things in the privacy of a conversation with someone (we think) we know. You rarely know who's scraping your screen and what they may think of it, though.
Oops!
Sometimes screens dim or power off and sometimes people use a key like space or enter to wake up the computer. Sometimes these buttons trigger an action such as submitting a form, or execute a command. Using the delete button to "wake up a computer" of course isn't any better.
FWIW, I use the left-hand shift key, as it is the furthest away from any key that does anything significant.
Confidential Communications and Documents
If you work for a company, sometimes somebody sends you information that is supposed to be for your eyes only. If the world knew you to not lock your desktop, how could they trust you with information that is supposed to not leak out?
Furthermore, communications and documents may be subject to a non-disclosure agreement, either directly with you or with your employer. Whom you trust doesn't matter when it's about who's subject to an NDA, you know.
"Switch User", not "Log Out, Log In"
Your favorite desktop's unlocking dialog likely offers a user that needs the computer the capability to log in as a different user, maintaining your session, whereas it is common for somebody else to just use your open browser window to check his/her email / Facebook / Google+ / Twitter a little - using sites you may be automatically logged on to when using your user account.
Your Cat / Dog / Hamster
If you have a pet, surely you've noticed how they are kee to walk over your desk possibly accidentally hitting any of those key you have managed to avoid using to wake up your computer...
su access es mi access
With an unlocked desktop, you are surrendering the access to your files - whether they be personal, private, confidential or public. Litterally anyone gaining physical access can modify, remove or share data from your desktop.
Furthermore, if you're anything like me, you probably have access to other systems. This may be through a certificate or two, a VPN connection, or an SSH key. You may also have a PGP key to sign and encrypt email with. Let's be honest, most people run agents or have no passphrase on these things at all. Go figure.
Unsaved Work
I'm fairly certain you do some things on your desktop that are of some significance to someone, especially while you perform tasks for work. Somebody else closing off an application you have running does not necessarily mean they save changes to documents, or save them to a location where you can find that version.
Frankly, though, if you manage to save all your changes constantly, perhaps using the Ctrl+S keyboard shortcut, I fail to recognize how you manage to do so but fail to press Ctrl+Alt+L (or Super+L if you will) when you step away.
Practical "Jokes"
There are screensavers that just never go away. There's applications that will force you to admit something rather embarrasing as well. Whether you trust other people (that you shouldn't trust) with confidential information, do you trust them to not pull a practical joke on you as well?
Keyloggers and other hackydihack
Once you've left your desktop unattended, and unlocked, how do you make sure that your desktop is secure from that point on forward? We know of keyloggers, and we know of programmable USB sticks that can present themselves as a HID keyboard and start typing as soon as they are plugged in. Admittedly, probably only a geeky forensic scientist can figure out what happened afterwards.
You Owe $x a Beer
My personal favorite is using some mailing list I know you are subscribed to (and I am too), to send on your behalf - using your account, an invitation for beers on your dime. Naturally I disclose the fact you are buying beers because you have not locked your desktop.
FWIW, most of the time I don't really have to have access to your unlocked desktop in order to be able to do this kind of thing using your account, since it's pretty likely lists you and I are both subscribed to (that are actually eligible for this, i.e. nothing like full-disclosure), run on servers I manage.

Running the Most Secure Multi-Domain Mailman List Server

jmeeuwen — Tue, 28 Feb 2012 22:53:20 +0000

Now that I've got it going, I could not stop myself from sharing this with you.

What do I mean by multi-domain mailman list server, you may be wondering? Well, imagine you have two development projects, foobar and bazbah, and each has their own domain name; foobar.org and bazbah.org.

If you where to take a standard mailman installation, you could only have one announce, devel and users, and you would need to choose to which of the two projects to attach those lists.

Usually this makes mailman site administrators choose for another option: prefix the name of the list with the name of the project. Then juggle around the multiple domain name spaces for each list and hope the footers, archives and other pages work out (there's a command in mailman, called withlist, with which you can fix_url after changing the URL for a mailing list... right).

An alternative of course is to run multiple mailman instances. Being the RPM package management oriented guy that I am though, I want those multiple instances to be packaged properly, of course, and available through YUM repositories.

Furthermore, I'm a self-diagnosed Security Enhanced Linux fanboy.

So, what did I do?

First, I got the sources for the mailman package in Fedora Rawhide (no point in taking an older one). I modified the RPM spec file so that it would take an optional %{domain} parameter all the way through. Since I'm using something Fedora Rawhide on Enterprise Linux 6, I needed to clause the various references to systemd stuff as well. You can see the result here.

Then, I made me this little script that makes things happen including using the original spec to spit out specs for individual mailman instances, build the source RPMs, and submit the build to Koji.

Presumably, you'll get httpd_t SELinux AVC denials against mailman_cgi_exec_t;

type=AVC msg=audit(1330454256.738:564): avc: denied { search } for pid=12091 comm="httpd" \
name="cgi-bin" dev=dm-0 ino=1183684 scontext=unconfined_u:system_r:httpd_t:s0 \
tcontext=system_u:object_r:mailman_cgi_exec_t:s0 tclass=dir
type=AVC msg=audit(1330454256.738:565): avc: denied { getattr } for pid=12091 comm="httpd" \
path="/usr/lib/mailman-lists.syncrotron.org/cgi-bin" dev=dm-0 ino=1183684 \
scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:mailman_cgi_exec_t:s0 tclass=dir

This is resolved with a relatively small policy, easily deployed with the Puppetmanaged.org SELinux module. Include in your node manifest:

selinux::policy { "httpd_mailman": }

Furthermore, you should set the context for the files deployed by the RPM packages, as is shown in the Puppetmanaged.org mail module from line #94 onward.

New Kolab Website Live

jmeeuwen — Tue, 28 Feb 2012 09:21:54 +0000

After some hard work, it it finally is: the new Kolab website.

It's seriously improved over the old website, but of course there's still some work to do. We'd like to be able to link to 'login' and 'register' pages, for example - so that you guys can all register and post to the forums, etc.

If you want to help out - we also have a test instance we can play with - please let us know on the websites-team mailing list. We seek skills in Drupal (6) + modules, JavaScript, CSS and of course, HTML.

Een bedrijf zonder email adres... moet je oplichten voor wat centen

jmeeuwen — Tue, 21 Feb 2012 13:45:18 +0000

Kennelijk is er een model waaronder een bedrijf, hede ten dage, kan opereren zonder een algemeen email adres voor bijvoorbeeld de afdeling Klantenservice, of om klachten naar op te sturen. Voorbeeld #1 en #2.

Beide voorbeelden zijn van Nuon, waarmee ik grappig genoeg, edoch niet grappig -na onvoldoende voldoenende communicatie vooraf, een dispuut probeer te openen over een factuur van enkele honderden euros.

Onbegrijpelijk, want Twitteren en Facebooken doen ze allemaal. Deze heeft zelfs een YouTube kanaal (voor filmpjes over de inmiddels bedreigde soort "tevreden klant", ongetwijfeld).

Gegeven welk formulier dan ook, daarbij, kun je niet eens een goed betoog opsturen - het is danwel maximaal 1.000 karakters (voor een vraag), danwel maximaal 2.000 karakters (voor een klacht). Het spijt me zeer, maar mijn klacht is (erg dichtelijk samengesteld) toch zeker 3.800 karakters.

De zaak draait erom, dat Nuon eist dat ik meer betaal over 2011 dan over 2010. Uitleggen kunnen ze het niet, en ikzelf heb de ballen verstand van meters - ik vertrouw een derde partij, stom genoeg, de netbeheerder. Ik heb wel iets verbruikt, natuurlijk, maar laat ze eerst maar eens zien dat de gegevens die ze denken te hebben kloppen, en uitgelegd kunnen worden. Afgeleid over de cijfers die ik van ze krijg ben ik tenminste 1 keer het klokje rond gegaan, en dan wel voor een apartement dat het afgelopen jaar (2011) heeft leeggestaan (het enige wat stroom consumeert is de verwarmingsketel die bevriezing van het hele zwikkie voorkomt). Ik verwacht, redelijkerwijs, een significant lager verbruik dan voor een apartement in gebruik (2010). Het zal op het laatste kilowattuurtje niet neerkomen, maar ik heb zo langzamerhand toch ongeveer een driedubbele vakantie naar een tropisch eiland in termijn-bedragen bij ze uitstaan - en nog willen ze meer.

Dit, voor mij, spelt oplichting. Factureren, inclusief de dreiging van het inschakelen van een incasso bureau en algehele afsluiting, om vervolgens zonder uitleg nog meer te gaan factureren, en (tot 2 jaar!!) later significante bedragen te crediteren, doet bij mij de emmer overlopen.

Sneak Preview of the Kolab Web Administration Panel

jmeeuwen — Tue, 21 Feb 2012 11:20:59 +0000

The Kolab web administration panel is being re-factored, or should I say, developed from the ground up.

We're splitting the user interface and the backend logic into a frontend "client" and a backend API, in order to allow for easier integration within other management and corporate products. The frontend client, the user interface I'm about to show off, therefore calls upon the API to get to certain settings, logic and other fancy stuff. Let's see what it can do already;

See here the client login screen. Once you press submit, it actually calls the API to create you a session, and tokens are being bounced back and forth. The way this works (or is supposed to work) exactly is documented in our Architecture and Design guide.

Currently, we only allow login with either the LDAP Distinguished Name of a user, or the primary mail attribute value - this is to be improved still.

After (successful) login, you'll be taken to an overview screen - I'm thinking this is to, in the future, display tasks pending (for sysadmins), and/or overall status of one's Kolab deployment.

You can see there's some icon work to be done, still, and that we're not yet "fully featured". We have an idea of how it's supposed to work, of course, but we're nowhere done implementing all of it.

The key functionality is to first implement administration for "users" and for "groups".

While this development deployment of the new Kolab Web Administration Panel runs against https://webmail.klab.cc, with currently over a hundred users or so(!), and with our larger deployments running with hundreds of thousands of users, we have considered user administration to become 'search based' as opposed to 'list and browse based'.

We've still provided a listing of (20) users, which is currently not configurable in size, with browsing capabilities. This, including a variety of other changes Kolab Systems has developed, should allow very large user databases in LDAP to still function properly with this interface.

Please note that I've logged in here with my personal credentials - not the System Administrator credentials, which is why I'm only seeing a sub-set of users that are actually in the system.

Now on to one of the nicest features we've developed; Automatic generation of certain form fields when adding a user (of a certain type). We currently ship with one default user type only; the "Kolab User". We're working on allowing administrators to define their own user and group types, so that adding a user or group offers you a quick way to identify required attribute values, and allows other attribute values to be generated using the information you supply. Have a look;

We're adding a user here. I give the user a given name attribute value of "John". Nothing is happening yet, but here it comes;
As soon as I leave the textbox in which I am to supply the given name attribute value, the frontend client calls the API to generate "other attribute values" given this new information. You can here see that the display name is being filled out automatically.
Now, having supplied the surname, please find the display name is completely filled out. The mechanism applied here contributes to consistency for multiple adminstrators working to add users to the same Kolab Groupware deployment. But that's not all of it!
In the System tab, other attribute values are filled out automatically as well - again using API calls. In the background, the API is using the same settings as are provided to the new Kolab daemon that I've developed, so that the daemon's "recipient_policy" plugin - if enabled, of course - does not have to change the same attribute values afterwards.

These "auto" form fields, calling the API in the background, are going to become fully configurable. That is to say, 1) which attribute values are to be generated automatically, 2) using what form data already provided, 3) rules to authorize someone to override automatically generated values, and 4) per user/group type.

I've mentioned "user and group types" a couple of times before, so let me illustrate what that's supposed to be able to provide you with.

Sometimes, you just want to add "a Kolab User" - this entry is supposed to have a mail attribute representing a valid email recipient address (and email envelope sender address), amongst other things. Suppose however you want the user to just be "a POSIX user" - but without Kolab Groupware. You would add a user type called "POSIX user", and set the mandatory, recommended, automatic and other form fields (and values), and from that point on forward, whenever you add a user, you get to choose what type of user that should be.

Of course you can make this "whatever you like" - if all "Kolab Users" are also supposed to have POSIX attributes, and Samba attributes, and the like, you can just add these form fields to the existing "Kolab User" type.

GNOME 3 Alt-Tab for Keyboard Addicts

jmeeuwen — Tue, 31 Jan 2012 15:24:21 +0000

As I'm addicted to using Alt+Tab to switch between open application windows, you can imagine that in GNOME 3, where Alt+Tab only switches between grouped applications (read: two open terminal windows are grouped) is... a little different. You would go to that terminal application icon, and then a little downward arrow would indicate multiple windows had been grouped.

If you were to release Alt at that point, you would be presented with the window from that group you last opened.

I had been using the arrow keys to navigate to the window I actually wanted (down to expand group, left-and-right to select window), but now I have a new thing to get addicted to.

I just discovered this magic key-combo, so I'm pleasantly surprised and I didn't want to withhold all that positive energy from you; Alt+`

Go fetch!

That's One Way to Learn a Language

jmeeuwen — Mon, 09 Jan 2012 18:45:36 +0000

Lydia and I have decided on a mechanism to learn Spanish. First things first, it's crucial we vastly increase our vocabulary.

Every week, starting this week (#2, 2012), we point at objects, think of activities, just tell eachother the time, every day life if you will, up and until we collect 50 or so, and find the Spanish translation.

Then, at the end of the week (this is going to be the exercise over the weekend) we learn those ~50 translations and start talking jibberish - It'll be a mixture between Spanish, Dutch and English, I imagine.

The more words we learn, as our vocabulary grows, the more we are (going to attempt) to actually speak Spanish. We should thus be able to learn about ~2.600 translations a year, and while our pocketsize translation dictionary holds about 37.000, we should be OK for the next decade and beyond :P

Kontact 4.7.4 does not work for me

jmeeuwen — Mon, 26 Dec 2011 14:42:08 +0000

I recently, very recently, purchased a Lenovo X220, fully beefed up with an i7 processor, 8GB of RAM, and the largest SSD (Intel 160GB), amongst other things.

Installing Fedora 16 (of course) went smooth (as was to be expected, as I know other people with Lenovo X220's). It's nicely locked down now, with startup, BIOS, GRUB passphrases, limited boot devices (SSD only) and an encrypted VG -which I can afford doing now without slowing down the entire system too much.

As a Kolab Systems employee, running multiple Kolab servers, naturally I install Kontact, the Kolab client, and I tend to do this using a fresh install (i.e. no copying data from the old laptop, no upgrading).

Fedora 16 includes a 4.7.4 KDE PIM stack, which turns out to not work for me. Having configured the Kolab accounts, it seems I cannot get to the messages in my Kolab INBOX -other folders work just fine.

In any case, I decided to try rawhide; the version of the KDE PIM stack included in rawhide at this moment is 4.7.95, KDE's latest release en route to 4.8 - this too, however, did not work for me.

So, I decided to try and build from GIT - my first time ever. KDE has a utility for this, called kdesrc-build. It's use is pretty straight-forward, but I had to install some build requirements on my system. This is what I have installed now:

# yum -y install \
    alsa-lib-devel attica-devel avahi-devel boost-devel bzip2-devel check-devel cups-devel \
    cyrus-sasl-devel dbus-devel dbusmenu-qt-devel enchant-devel fontconfig-devel \
    freetype-devel gamin-devel gettext-common-devel gettext-devel giflib-devel \
    glib2-devel glibc-devel glib-devel gnutls-devel gpgme-devel grantlee-devel \
    gstreamer-devel gstreamer-plugins-base-devel herqq-devel ilmbase-devel jasper-devel \
    kdebase-workspace-devel kdelibs-devel kdepimlibs-devel keyutils-libs-devel krb5-devel \
    libacl-devel libattr-devel libcom_err-devel libdrm-devel libgcrypt-devel \
    libgpg-error-devel libical-devel libICE-devel libjpeg-turbo-devel libpng-devel \
    libselinux-devel libsepol-devel libSM-devel libstdc++-devel libtasn1-devel \
    libudev-devel libutempter-devel libX11-devel libXau-devel libxcb-devel \
    libXcomposite-devel libXcursor-devel libXdamage-devel libXext-devel libXfixes-devel \
    libXft-devel libXi-devel libXinerama-devel libxkbfile-devel libxml2-devel libXpm-devel \
    libXrandr-devel libXrender-devel libXScrnSaver-devel libxslt-devel libXt-devel \
    libXtst-devel libXv-devel libXxf86misc-devel libXxf86vm-devel mesa-libGL-devel \
    mesa-libGLU-devel mysql-devel OpenEXR-devel openldap-devel openssl-devel \
    pcre-devel phonon-devel polkit-devel polkit-qt-devel PyKDE4-devel PyQt4-devel \
    python-devel qca2-devel qt-devel qt-gstreamer-devel qtwebkit-devel raptor2-devel \
    shared-desktop-ontologies-devel sip-devel soprano-devel sqlite-devel strigi-devel \
    xorg-x11-proto-devel xz-devel zlib-devel

Consider installing the "Fedora Packager" group as well;

# yum -y install @fedora-packager

After following the setup instructions, you should first initialize your copy of the various sources (otherwise failures would cause you to need to manually cleanup subversion repositories, for example):

$ kdesrc-build --src-only

This, when you run it for the first time, can take quite a while.

Once it's done, you can start building stuff:

$ kdesrc-build

This, too, can take quite a while. Furthermore, it requires a lot of energy, and drains my 7.5 hour battery life in about 90 minutes ;-)

UPDATE^1: The build dependencies for gwenview need to be added to the list of build requirements; exiv2-devel.

No time existed before the Big Bang?

jmeeuwen — Mon, 26 Dec 2011 14:12:31 +0000

I was watching this documentary I don't recall the name of. I remember recognizing Stephen Hawking though, which is one of the reasons one of the statements made in the documentary caused me to raise my eyebrow and question the rationale put forth.

Summarizing, the narrator said that in essence, no time exists inside (close to?) a black hole. A clock that would travel into a black hole would stop ticking, or so the audience were told. I suppose it's fair enough to reason time no longer exists inside a black hole, though from where I am sitting -no astrophysics background whatsoever- it sounds like quite the assumption.

Anyways, it was argued that the Big Bang itself, the event that supposedly caused the universe to exist as we know it (even though we know very little of it), was some sort of black hole imploding on itself.

It was then argued, that, therefore, no time existed before the Big Bang. The documentary further argued, that since no time existed before the Big Bang, it was therefore impossible for some sort of grand designer to have existed, let alone create the universe.

Now, I'm not exactly in favor of pointing to a grand designer that created it all, but this documentary narrates flawed reasoning for such grand designer to not have existed.

The link that is being drawn between one type of black hole (the ones we think we have in our universe, that exist with surroundings, in which time exists) and another type of "black hole" (the one we can only speculate about, for which it is assumed no surroundings existed, in which time could have existed), in that in each type of black hole, no time exists nor existed, neglects the fact that outside of such black hole, surroundings may exist or may have existed, other localities if you will, in which thus also time may have existed. It's not like current black holes cause time to not exist anywhere outside of it, right?

Maintenance of blog

gmzysk — Sun, 09 Oct 2011 15:11:00 +0000

Hey All,

Sorry for the blog post dump. I am doing a little maintenance on my blog and did not realize it would re-post everything again :-(

My apologies!

openSUSE Marketing Hackfest 2011

gmzysk — Tue, 04 Oct 2011 17:40:00 +0000

On the 15th and 16 of September 2011, following the oSC, the marketing team held a Marketing Hackfest at the SUSE headquarters in Nuremberg, Germany.

I was asked to attend this event for several reasons aside from the normal Marketing related things, two of which were the most important to me being new to this event. One, was to observe how the marketing team functions as a unit. And second, to hold meetings with different people to discuss certain issues with an outlook of solving them for the benefit of the openSUSE community. Moreover, many of us had a chance to further discuss (in person) initiatives started at the oSC, since we had a chance to digest them and come with some valuable input that was used to move things forward ;-)

The first day, was quite chaotic for one who had never attended and/or understood the process of how the team administered their hackfest. There were some communication issues, which eventually turned the event into an understanding of organized chaos on my part ;-) Things started out slow, but by the second day many people had an idea of the workload and were producing some awesome ideas and collaborating together to help each other implement those ideas. On the last day in the afternoon, Amie Johnson (SUSE's PR Manager) gave us a quick presentation on press releases: How to do them and the format that should be taken into account. Amie was nice enough to offer the community help with PR by collaborating between the community and SUSE, so we can work together on leveraging the messages we both have in common.

Given the circumstances and meeting place, we were able to have some other people from SUSE contribute, who were happy to join and help out also by demonstrating their commitment to the openSUSE community. So, Thanks to Jan Weber, Susanne Oberhauser, Michael Miller, Greg K.H, Alan Clark, Andreas Jaeger, and Amie Johnson for helping out and filling in the gaps were needed.

Also a great big thanks again for the input and work performed by the marketing team and those that attended: Bruno, Francoise, Manu, Kostas, Stella, George, Izabel, N.B. Prashanth, Bryen, Jos, Andrew, Sebastian, and JDD. You guys did a great job coming up with new ideas, as well as, building on the current ones!

Last, but not least, thanks to Jos for the Stroopwaffles (Dutch Treacle Waffles) and SUSE for the lunches, drinks and the use of there offices and infrastructure.

Thanks Geekos for once again demonstrating the openness and collaboration that is so specific to the openSUSE community culture. Looking forward to help make one of the best, even better!!!

Looking back at the openSUSE Conference 2011 (oSC)

gmzysk — Tue, 04 Oct 2011 15:55:00 +0000

Well, once again, I had a chance to meet a community, one of which, I have never met before ;-)

I arrived at Zentrifuge on the 10th of September for the warmup to the oSC. Immediately after arrival, I was greeted with warm smiles, open discussions, and cold beer ;-) No one knew who I was, but they all welcomed me. As the evening continued, I was witness to how the community also made sure that they welcomed everyone, once they arrived. This is pure class and I would like to say is very important to a newbie who is entering the community. This is one aspect where openSUSE makes the difference, since it is not practiced to this extent in many other communities.

The first day: After a great evening of meeting various contributors, members of openSUSE and SUSE employees, and having great technical and non-technical chats, the first day of the event was kicked off. It was hot, not only the event, but the weather. Around 35 centigrade with a lot of humidity, so the speakers, like me, were really put to the test. I had the chance to meet many people in the openSUSE community and spend some time with them one on one to discuss their experiences and how they viewed the project. Furthermore, I met a few others who were not a part of the openSUSE community, but others within our ecosystem who were there to show there dedication to collaboration. I, myself, also held a workshop entitled "Introduction to Cross-cultural Communication, Collaboration and Conflict" which attracted quite a crowd and I am very please with all that attended, showed interest and gave feedback. You guys and gals are awesome and did a remarkable job!!!

The second day: This is where the the fun and the heat started to both take their toll ;-) I made it a point to attend most all of the community track and also Greg KH's talk on Tumbleweed. The first BoF I attended was Ambassador Program: Current status, potential changes and inprovements held by Kostas and Manu. This was an interesting discussion on the current status of the program and what needs to be done to make the program more structured and what will be expected from new ambassadors when they join. The second talk I attended was Greg KH's talk on his initiative Tumbleweed. Greg is an excellent speaker and really has a knack for communicating technical things in a way non-technical people can understand. This is a major accomplishment in itself ;-), let alone his long-time appreciated contributions to the kernel. I learned that I practiced a couple of Greg's don'ts while using Tumbleweed and have since corrected those mistakes. Furthermore, I would like to add that I had some discussions with Greg about some certain kernel modules and he was very helpful, took the time to research them and got back to me in a very short time with the answers. Thanks again Greg!!! The next workshop I attended was Pascal's Packaging, hands on. Unfortunately, things did not go according to plan in this workshop, due to a number of issues: The network was not working correctly, the heat was almost unbearable, and there were people of various different experience levels that attended making it very hard for the host to keep a steady pace. These things happen sometimes, so let's not shoot the messenger! The next BoF, I attended was Mentoring New Contributors, held by Vincent Untz. This was quite an involved discussion about how to build a structure for a mentor-ship program for new people joining. This is quite a complex topic, still under discussion of how to mentor, who will mentor (given the limited resources and time) and how this program will be implemented. Overall, I think we came up with some good arguments to help build the program and of course we are still in the process of helping build it. In Final, this was quite an involved day, aside from all of the private discussions I had in between these workshops and BoF, which also yielded some solid initiatives for cross-community collaboration. Definitely , a very effective day that gave a great overview of the status of the project.

The third day: This day was quite ad-hoc, I hosted an open BoF to discuss issues/conflicts within the project and in our ecosystem. Thanks to all that attended and your input (for the sake of the issues themselves and trust, I will not write any details about this BoF). Furthermore, I attended BoF's regarding moderation held by Jos Poortvliet, and another held by Lydia Pintscher, which focused on how to get more women into openSUSE. The moderation discussion was interesting and always touchy subject, though we had the right people there to discuss. Thanks Henne, Pascal, Alan, Bryen, and Richard for your input and collaboration. We have come to agreement for a solid start to how we will approach this. This initiative should be implemented soon and IMHO all of the community will benefit from it. In final, last (not chronologically either) but not least was the BoF, held by Lydia Pintscher of KDE on her experiences and suggestions of how to get more women into openSUSE. This is a hot topic in all communities and IMHO, I believe it should be given more of a priority. We have come up with some things to build on and luckily have some of our own who have taken the initiative to continue the discussion and bring forth viable ideas. Thanks to Lydia, Pascal, Bruno, Stella, and Susanne for their suggestions and input. A special thanks to Susanne Oberhauser for taking the lead and initiative to build on the discussion. If any of you have any suggestions or would like to help, please contact her as we need your help to make openSUSE a more attractive project for women to become involved with.

On the final day: I attended one BoF hosted by Kostas entitled "Do we need an ambassador mentorship program? This was also a very interesting discussion, as it, in my eyes, ties into getting women into openSUSE and also to the discussion about a mentoring program in general held by Vincent Untz. Mentoring is a something all organizations and communities need. We need people who can answer questions, have patience with newbies and overall be a go-to person who can refer a new contributor to the right team/person in the project to get their initiatives started and to simply get their questions answered. Hopefully, within the next months, we will have worked out all the kinks and have a workable ambassador mentor-ship program that works together with the overall project mentor-ship program, so we have a clear line of communication that is also reflected down to the mentees.

Finally, I must admit, it was quite a wild ride for me ;-) I met and made some very good friends, got some great business contacts, had a chance to speak to many people individually to get a feeling of the overall health of the community, and also had time in the evenings to plan some social events. Thanks especially to Stephan whom was willing to take a small group of us on a tour of the Altstadt, be our guide, take us to dinner and drinks at a local brewery and not give up on us because we were late. Sorry for that Stephan, I know we broke the cardinal rule in German culture, we were late. It will not happen again. Thanks also to all those who attended. Thanks to those involved for the lunches, dinners and the fun we had after hours ;-) Oh, and who could forget, thanks to the Greek crew for providing their touch, getting people involved and most of all that Greek charm;-)

In Conclusion, I would like to extend my assistance to the openSUSE project with helping with community development, leadership, communication and conflict. I have already initiated some cases on pending issues brought to my attention by several contributors and will be working together with those contributors to help find a solution that best fits their needs and the needs of the openSUSE project. Moreover, I would like to extend a hand out to the openSUSE board and SUSE, so that we together can build a better capacity for clearer communication, a clear process for handling conflict, a more diverse and international community and a more effective and healthy community for all.

Overall, you Geekos should give each other a big hug and a pat on the back!!! You are a very unique, open, and welcoming community, one of which on this level is quite rare in our ecosystem. I look forward to working together with all of you to make openSUSE even better!!!

Enabling 'condstore' on your Kolab 2.3 mailboxes

jmeeuwen — Mon, 12 Sep 2011 16:38:23 +0000

What is referred to as 'condstore' is actually the feature-set that IMAP4Rev1 extension added in RFC 4551. It enables the quick synchronization of flags on messages as well as other conditional STORE operations.

I'm going to have to refer you to the RFC for the full details, but suffice it to say your Kolab 2.3 deployment could greatly benefit from enabling said extension on your mailboxes - it is not enabled by default as part of Cyrus IMAP 2.3, only with Cyrus IMAP 2.4 is the 'condstore' annotation set to 'true' by default.

You will have to execute two separate actions on your Kolab server:

Configure new mailboxes to have 'condstore' enabled by default,
Configure current mailboxes with 'condstore' enabled.

You would preferrably execute these actions in this order, to reduce the chance new mailboxes are being created while you have not yet switched on 'condstore' to be enabled by default.

Enable 'condstore' by default

To enable condstore by default, in your favorite editor, add the following line to /kolab/etc/kolab/templates/imapd.conf.template:

mailbox_default_options: 2

Afterwards, write out new templates and reload Kolab with the new configuration;

/kolab/sbin/kolabconf

Enabling 'condstore' on existing mailboxes

To enable 'condstore' on existing mailboxes, login to Cyrus IMAP using the cyradm utility:

cyradm -t "" -u manager localhost

From there, you can examine one of the existing mailboxes;

localhost> info user/john.doe@example.org
{user/john.doe@example.org}:
  condstore: false
  duplicatedeliver: false
  lastpop:  
  lastupdate: 12-Sep-2011 17:56:54 +0200
  partition: default
  pop3newuidl: true
  sharedseen: false
  size: 105382261
  folder-test: true

As you can see in the example, condstore has not yet been enabled for this mailbox. To enable condstore for a particular mailbox:

localhost> mboxcfg user/john.doe@example.org condstore true

You will not want to repeat this command for all mailboxes, but instead use wildcard matching:

localhost> mboxcfg user/*@example.org condstore true

NOTE: The two commands do not return any output.

NOTE^2: Don't forget to, at your option, also enable condstore for mailboxes in the shared namespace, in other authentication realms, and perhaps even for those mailboxes that reside in the DELETED namespace (just in case they are restored to a visible namespace later on in life).

Open Source Conferences

fab — Fri, 09 Sep 2011 11:42:44 +0000

In the next weeks three major distribution are planning conferences. If you have some holidays left and don't know what to do, spend these days on one of the below listed conferences ;-)

OpenSUSE: openSUSE Conference at Nürnberg, Germany - 11. to 14. September 2011
Fedora: FUDCon at Milan, Italy - 30. September to 2. October 2011
Ubuntu: Ubuntucon at Leipzig, Germany - 14. to 16. October 2011

openSUSE conference 2011

gmzysk — Wed, 31 Aug 2011 20:50:00 +0000

As promised a little look into the future: I will be attending the openSUSE conference in Nürnberg, Germany in 10 days. This years conference topic/focus is RWX3, which places a heavy emphasis on hands-on workshops and BoF's. It should be a great conference with many side activities and a Wild West themed social event. I also hear that there will be some cooking workshops which I definitely want to be a part of, since I have a great interest in cooking and have cooked professionally for several years, as well as, with and for many hackers and community members over the years and they love it :-) Now, this is the type of diversity and creativity all communities need to embrace!

In addition to my attendance, I will also be presenting a workshop entitled 'Introduction to Cross-cultural Communication, Conflict and Collaboration' on Sunday the 9th of September from 14:30 to 15:50 in Salon Brendl. This workshop will definitely be hands-on and will include a conflict simulation which all attendees will take part in to help better understand their fellow contributors, as well as, themselves. I also look forward to learning more about Greg KH's initiative and future plans with Tumbleweed at his talk on Monday. More information on my presentation and all others including the full timetable can be found here. It looks to be a pretty full timetable filled with hands-on sessions, so this event is sure to yield significant outcomes.

I look forward to meeting with those colleagues and contributors with whom I have met before, as well as, those new faces I have never met before, to have discussions and launch initiatives that support collaboration, organization and healthy community development. Most of all, I just look forward to (GTD) Getting Things Done!

See you there!

HCC Linux Day Bunnik NL: Looking back

gmzysk — Wed, 31 Aug 2011 17:04:00 +0000

I attended HCC linux day on Saturday the 21st of May in Bunnick, The Netherlands. I have always wanted to see how the local communities present themselves at events in the NL, since I mainly attend the international events. HCC is one of the largest, if not the largest, communities in the NL comprised of members that use a variety of different distros and projects that support development within the FOSS ecosystem. This event's focus was on Security and was hosted at the Postillion Hotel.

I first arrived at the event at 10:00 and was quite impressed with the venue for such a small event. It was easy to get to (by car at least) and the hotel was quite new, which provided a quaint, by specialized feel. The presentation rooms were new and fitted with new equipment which gave the event an added feeling of style and prestige. I decided to attend some presentations held by Jos Poortvliet, the community manager for openSUSE whom introduced the new initiatives (OBS, SUSEStudio, Tumbleweed, Evergreen) and the different desktops that are supported in openSUSE latest release 11.4 within the course of two separate presentations. I also got a chance to visit the openSUSE booth, which seemed to have quite a buzz going around it and Jos was nice enough to introduce me to his local team which consisted of some new members who looked very enthusiastic about the event and being involved in the openSUSE community. I also had a chance to speak to some of the local contributors, some from Ubuntu and others who were developers, gamers and just interested users. Many of the people attending this event had been users of FOSS for quite a while, either as a hobby or in their work. I had a feeling that actually most could be classified as users and not your hardcore developer types. I see absolutely no problem with this as these users help spread the message and play a part in keeping the ecosystem alive.

Overall, I really liked the event since I was able to speak to people who are not quite your "normal" FOSSies and saw aspects of our communities from a different point of view, which is always refreshing. In addition, this was quite a low key event, so it also carried a very relaxed feeling to it :-) There is still a need for these types of events, as there are for the events on other levels, since these events provide access points for people of all types to get involved in FOSS. Especially the locals, whom cannot or do not want to travel far to get their questions answered and to hang out with those that share the same interest ;-)

Thanks again HCC, I enjoyed the event and look forward to attending another event of yours. Also a great thanks to Jos and the local Lizards for the constructive discussions, openness, and engagement demonstrated by the openSUSE team.

LinuxTage 2011: looking back

gmzysk — Wed, 31 Aug 2011 16:32:00 +0000

Sorry about this post being quite belated, but I have been wanting to make this post for quite a while. This last May (11-14th) I attended LinuxTage in Berlin where it is hosted every year. It was my first time at the event and many of my hacker colleagues gave me mixes feelings about the event before I attended. There complaints with the event were that over the years that it has become more corporate oriented and that community presence has been less regarded over corporate interest when arranging and planning for community presence (booths, etc.).

I always try to keep and open mind when attending an event i which I have never been to before, so I arrived at the event on the 11th with a business colleague of mine to introduce him to the world of FOSS to see his thoughts on it, but more to try and give him a picture of what I have been investing a lot of my time into over the past 3 years. He, like many others, rarely see the point of FOSS and the meaning behind just having another operating system on your computer. As many others I have spoken to over the years, he had a hard time understanding why he should give FOSS a try when he had no problems with using Windows. My strategy was to just introduce him to the ecosystem and let him make his own assumptions on what he saw and then provide answers and support to the questions he had.

As we entered the exhibition hall, the first time, he was reluctant from the beginning and THEN he saw names of projects he was familiar with which he did not know stemmed from our ecosystem. Projects he used on windows, such as VLC, XMBC, to name a few. He then shifted his opinion to being a little less reluctant and began to open his mind a little more to this FOSS thing. We split up for a while, as I told him to get involved, ask questions, and just look around! In the meantime, I visited my old colleagues at the Fedora Project and CentOS to see how they are doing. Furthermore, I had a good talk with the Debian project about their plans, future development, and got all of of my questions answered in a nice informed way about the CUT/Rolling release initiative. In final, as always, I also had a chance to chat with some community managers and discuss some issues facing our communities and ecosystem and how we can improve cross-community collaboration.

Overall it was quite a decent event, I met some new people, got up to speed with the old and planted a seed in someones mind of what opportunities and tools FOSS can give the average individual and business person, but I will have to agree with my hacker colleagues, it was a little to corporate and presented itself as more of a hybrid event rather than a community one. Berlin, in itself is awesome, one of my favorite cities in the world, since there are just not too many places like it ;-) C-Base is also one of a kind hacker meeting place/lab which definitely demonstrates the unique qualities of this city and the local FOSS community in Berlin. Oh, and not to forget, my business colleague left with a greater understanding of our ecosystem and a smile on his face, so I think that speaks for itself ;-) Will be seeing you again shortly, Berlin, that I can guarantee!!

Catching up

gmzysk — Wed, 31 Aug 2011 15:52:00 +0000

I do not write blog posts very often, as you can see from my last post was over a year ago. That does not mean I have not been highly active within the FOSS ecosystem, but more so that the function I have and the topics I deal with (conflict management and community development) are not per say things I can freely speak about to those which are not directly involved. You might think, well, you are holding something back or being non-transparent, but that is not the case, it is more about trust. In open source, we all have our circles of trust. Those circles defined by who and what we trust and furthermore the level of trust that we have in these people or institutions. In my function, trust is at the highest level. I coordinate with many within our ecosystem to help resolve issues, some of these issue being highly sensitive for the parties involved. If I were to post these issues, I could foresee two things happening: a loss of trust from one or both parties, and furthermore, an escalation of the issue. Please remember that my function is compared to that of a doctor, just not a medical doctor, but an organizational doctor. Therefore, just as your doctor has ethical commitments to not share his/her patients information, the same goes for my function.

That said, I can post about other things, that is true. I will post a couple more posts about the events that I have been to this year (something that has been on my list for a while) and some that I will attend in the near future.

Updates from the Cyrus Project

jmeeuwen — Thu, 07 Jul 2011 18:01:44 +0000

First of all, Bron Gondwana has done a great job over the course of a number of releases, to resolve some of the bugs in Cyrus IMAP that may have been around for quite a while -though most of them you may not have noticed.

Since Cyrus IMAP has been around since 1993 (give or take), it inherently contains legacy implementations of features or required functionality, sometimes to the tune of "good enough". Seeking further compliance with IETF approved RFCs and allowing for further development has spawned a 2.4 software series, with large amounts of code refactoring and cleanup, and the addition of some interesting features -more on those later.

Just this week, the Cyrus IMAP team has released cyrus-imapd-2.4.10.tar.gz. One day later, I've submitted the build to Fedora rawhide, so it should be hitting your doorstep soon enough. I plan to follow up on releases upstream with packaging more quickly and more agile in the future. Yours truly being the Release Engineer for Cyrus IMAP & SASL, as part of my work for Kolab Systems, I like how we have established a culture of release early, release often within the Cyrus IMAP project, and how core developers like Bron can make releases happen almost autonomously, while in between the last version in the 2.3 product series and the first version of the 2.4 series, a good couple of years had past.

Further endeavors include our 2.5 roadmap (which I admit could use some love), documentation (which I work on) and of course testers and developers are always welcome!

In the Cyrus SASL realm, we're working to convert the CVS repository to GIT. This takes a long time, since like Cyrus IMAP, Cyrus SASL has been around for quite a while. I must say we have done our due dilligance over the past few months on this one though, so I expect the repository conversions to GIT I've been doing to be approved soon enough.

Using GIT for the Cyrus IMAP codebase has proven to be a lot more attractive to a lot more contributors (since they can now create their own working copies and collaborate on those), and I hope we achieve the same level of success for Cyrus SASL.

FUDCon Panama 2011, Day 1-2

jmeeuwen — Sat, 28 May 2011 19:53:40 +0000

I'm having a great time at FUDCon in Panama. For one, the weather is much better then back in Wales... :P Parties are at the villa of les Chiles Loco (the crazy Chileans), and last untill about 3am in the morning. Plenty of beer and plenty of barbeque steak usually do the trick for me :)

My first session on Thursday, titled "Why You Are All Idiots", was post-poned because someone from Dell needed to have his session on what seems to have been the busiest FUDCon day so far. Irony has it, the talk was on "Virtualization with KVM", and while my schedule was freed up, I went to assist Dell Panama with their KVM / Live-migration demonstration setup they were going to show on Friday :)

So, after all, my first session was on Friday, and on "Cloud", following two other presentations on virtualization, and the second was on "Software, RPM, Packaging, Guidelines and Build Systems... but why?", starting off in a small series of talks on packaging and the koji build system.

Other people are having many interesting talks as well -but in Spanish. Since I only hablo pocitto espanol (and that's about it), it is sometimes hard to follow. For most of today -outside of my "Why You Are All Idiots" and two lightning talks, I've been working to get a working GNOME3 desktop environment on my laptop.

Looking forward to FUDPub.

Day -1, Travelling to FUDCon Panama 2011, and Day 0

jmeeuwen — Thu, 26 May 2011 00:10:35 +0000

Please allow me to describe my day of travelling yesterday;

Having woken up at 05:30am ET, I started at Detroit airport, as I just so happened to be in the area already. From Detroit, a Continental (now United) flight to Newark (oops, high building, zig, oops, high building, zag, touch-down). Short layover, continued my trip to Miami -from the air it looks much like in the CSI series.

Note to self: do not wear black shoes, black trousers and a black T-shirt when travelling through Miami as you have to go outside to the designated smoking area which has no shaded area anywhere near it.

From Miami, I had an endurable Copa flight to Panama City, where immigration lines are as bad as they are in the U.S. Alejandro picked me up, dropped me off at the hotel, and took me back to Cuidad del Saber, where I met up with the rest of the guys -about 18 hours after I started.

One too many beers and a barbeque later, Alejandro drove me back to the hotel for some well-deserved, long-needed rest.

Today, I've been preparing some of the sessions I'm going to pitch or try and squeeze in the schedule, including but not limited to the following titles;

I suppose other sessions I could/should also be doing are on Spins, Fedora Trademark / EMEA / NPO, Extended Life-cycle Support, Configuration Management with Puppet and Fedora in the Enterprise. I can pitch'em all, but I'll have to see which ones actually make it on the rather tight schedule ;-)

Thoughts on Kolab and (3rd Party) Application Caching

jmeeuwen — Sat, 16 Apr 2011 09:17:17 +0000

Applications that we integrate with Kolab Groupware have a genuine need for caching. But what is it exactly that causes this need for caching?

Why Does One Cache?

Let's first think about why one caches in the first place. Caching is usually implemented to eliminate a bottleneck and boost performance. Data can then be obtained from the relatively quick cache -it is "close by", and it usually understands and is optimized for some form of querying- as opposed from the relatively slow original source of the data.

With Kolab, using Cyrus IMAP as the backend storage for all groupware related information like Email, Events and Contacts, it can hardly be argued the IMAP server does not perform up to specifications. Cyrus IMAP is extremely fast and scalable; it is, arguably, just as lean and mean as a cache would be.

So, Where's the Bottleneck?

Yet, the following topology does introduce and work around a bottleneck, seriously impacting and later improving performance. I'm off to explore what exactly is the bottleneck, and how to work around it.

We'll use Z-Push (Free Software ActiveSync implementation) in a regular, current scenario workflow as an example. The following happens, justifying caching, when a mobile device requests synchronization;

The 3rd party application connects to Cyrus IMAP to retrieve "the information". Since not all folders may need syncing, and some folders contain Email while others contain Events or Contacts, a list of IMAP folders needs to be obtained.
Cyrus IMAP, its efficiency in this matter aside, interacts with the mailbox storage to retrieve certain information from its mailbox database, its annotations database, the message files, etc.

Using the IMAP protocol, this means;

Listing the folders the user is authorized for.
Iterate over the list of folders and retrieve the following annotations for each folder:
- "Should this folder be synchronized with the mobile device at all?"
- "What type of groupware items does the folder contain?"
Then, excuse my paraphrasing, on a per IMAP folder target basis, the changes that may or may not have been applied on the mobile device, need to be compared with the changes that may or may not have been applied in the IMAP folder, and vice-versa. Retrieving changes, messages, parsing them, and comparing them, and applying the changes on either end, while tracking which changes have already been communicated to one or the other end of the synchronization exercise.

Naturally, the last step is what Z-Push is in charge of, in this example. and It does have certain characteristics and interactions with Cyrus IMAP as well as with its own caches to optimize the performance, scalability and user experience.

The former notwithstanding, this is just one application integrated with Kolab responsible of maintaining its own cache. In current generations of Kolab, Horde Webmail does the exact same but using a different cache, and future generations of Kolab will include RoundCube, which again also maintains its own cache.

One Cache per Application?

Maintaining a cache per 3rd party application integrated with Kolab isn't necessarily the most sustainable route to go. Feasible? Yes. Sustainable? Perhaps not. Let's take one step back and look at the bigger picture again;

Presumably, the interaction between Cyrus IMAP and its storage can not be optimized further (which the dotted double arrow is supposed to indicate). Not without intrusive changes at the very least, that is to say, while admittedly I'm unaware of our options to further increase performance in this part of the flow of information. If you have ideas and the necessary experience, let me know and I can get you hooked up.

It is, perhaps, the IMAP protocol used in between the Cyrus IMAP server and the 3rd party application that is the bottleneck. For example, Z-Push cannot do the following over IMAP, eliminating a number of iterations and sequences issuing IMAP commands;

SELECT folder FROM folders
    INNER JOIN annotations ON folders.id = annotations.folder_id
    WHERE annotations.key = '/vendor/kolab/activesync' AND annotations.value = 'true';

Hey, this does somewhat represent what it does against the cache it maintains, having obtained the information over IMAP once (slow) it uses its cache to obtain the information (fast) in a number of subsequent synchronizations -limited to an expiry interval, expiring and updating cache, of course. This builds us the following picture, where IMAP is "slow" for the task at hand, and SQL is fast;

Ignoring the interaction that Cyrus IMAP requires with the filesystem as being a negligible performance penalty, and focussing on how the 3rd party application wishes to optimize performance, apparently it would rather perform caching (cheap), then it would want to interact over the IMAP protocol (expensive).

Suggestion #1: One Cache To Rule Them ALL

It has been suggested, since most if not all of the 3rd party applications integrated with Kolab would require some form of caching, we create "one cache to rule them all";

Although probably this is in fact entirely feasible, the following constraints to such architecture come to mind;

Session reliability and personal information security, complex to implement but even more complex to audit, and implemented up to specifications with IMAP ACLs already,
Duplication of ((a significant) part of) the data,
Abstraction from caching required in all 3rd party applications, each of which has their own already (i.e. significant development effort right from the start, and continuous development effort for more 3rd party applications to integrate with Kolab Groupware), and one uniform caching specification across all of the 3rd party applications (i.e. significant design complexity).

We (within the Kolab community) regularly refer to the "one cache to rule them all" as "server-side akonadi" - currently the very efficient client-side (offline) caching in our primary smart client, Kontact.

Suggestion #2: Maintain Cyrus IMAP Databases in Networked SQL

It has also been suggested (by me, in fact), to have Cyrus IMAP use database formats other applications within a Kolab Groupware deployment could read from. By having Cyrus IMAP maintain its mailbox, annotations and perhaps even mail folder indexes and caches in a database format like SQL (instead of Berkely or skiplist), these would become available to the 3rd party applications without them having to populate the cache first, and the cache would be updated "automagically"; as a result, the level of interactions with Cyrus IMAP over the "inefficient" IMAP protocol would be further reduced -"inefficient" for the task at hand, that is.

However, this would greatly impact the scalability of Cyrus IMAP. It would, in fact, greatly impact the overall performance of Cyrus IMAP as an IMAP server. It's a valid option, but not considered feasible targetting for because of the projected performance penalties.

Suggestion #3: Use Cyrus IMAP

If you agree it's fair to label having to use the IMAP protocol to get to the data required as the bottleneck, here's the suggestion I have in mind; Add a thin, lean and mean, network-enabled, read-only C application to interface between the 3rd party applications and the Cyrus IMAP databases (on the filesystem), thus enabling the 3rd party applications to use a different protocol or querying language to obtain the data in a more efficient manner. Perhaps this would look as follows:

Benefits would include many requirements have already been implemented; Locking, networking, database maintenance, threading, thread safety, TLS/SSL, access control though IMAP ACLs and its handling and more of that stuff. The new application could, presumably, also maintain its own caching capabilities to be even quicker.

Just some early Saturday morning thoughts... let's see what the rest of the weekend brings.

Python LDAP module 2.4 Changes

jmeeuwen — Mon, 11 Apr 2011 11:15:11 +0000

Turns out the LDAP module for Python breaks the API while developing version 2.4 -with no backwards compability, but a workaround is relatively easy. If, like me, you need to be able to run code on platforms traditionally "slow" in adopting the latest and greatest, as well as those that are traditionally, relatively "fast", here's an idea:

# Catch python-ldap-2.4 changes
from distutils import version
if version.StrictVersion('2.4.0') <= version.StrictVersion(ldap.__version__):
    LDAP_CONTROL_PAGED_RESULTS = ldap.CONTROL_PAGEDRESULTS
else:
    LDAP_CONTROL_PAGED_RESULTS = ldap.LDAP_CONTROL_PAGE_OID

class SimplePagedResultsControl(ldap.controls.SimplePagedResultsControl):
    """

        Python LDAP 2.4 and later breaks the API. This is an abstraction class
        so that we can handle either.
    """

    def __init__(self, page_size=0, cookie=''):
        if version.StrictVersion('2.4.0') <= version.StrictVersion(ldap.__version__):
            ldap.controls.SimplePagedResultsControl.__init__(
                    self,
                    size=page_size,
                    cookie=cookie
                )
        else:
            ldap.controls.SimplePagedResultsControl.__init__(
                    self,
                    LDAP_CONTROL_PAGED_RESULTS,
                    critical,
                    (page_size, '')
                )

    def cookie(self):
        if version.StrictVersion('2.4.0') <= version.StrictVersion(ldap.__version__):
            return self.cookie
        else:
            return self.controlValue[1]

    def size(self):
        if version.StrictVersion('2.4.0') <= version.StrictVersion(ldap.__version__):
            return self.size
        else:
            return self.controlValue[0]

Example Usage

Where 'self.ldap' is the LDAP object;

    def _search(self,
            base_dn,
            scope=ldap.SCOPE_SUBTREE,
            filterstr="(objectClass=*)",
            attrlist=None,
            attrsonly=0,
            timeout=-1
        ):

        _results = []

        page_size = 500
        critical = True

        server_page_control = SimplePagedResultsControl(page_size=page_size)

        _search = self.ldap.search_ext(
                base_dn,
                scope=scope,
                filterstr=filterstr,
                attrlist=attrlist,
                attrsonly=attrsonly,
                serverctrls=[server_page_control]
            )

        pages = 0
        while True:
            pages += 1
            try:
                (
                        _result_type,
                        _result_data,
                        _result_msgid,
                        _result_controls
                    ) = self.ldap.result3(_search)

            except ldap.NO_SUCH_OBJECT, e:
                log.warning(_("Object %s searched no longer exists") %(base_dn))
                break
            _results.extend(_result_data)
            if (pages % 2) == 0:
                log.debug(_("%d results...") %(len(_results)))

            pctrls = [
                    c for c in _result_controls
                        if c.controlType == LDAP_CONTROL_PAGED_RESULTS
                ]

            if pctrls:
                size = pctrls[0].size()
                cookie = pctrls[0].cookie()
                if cookie:
                    server_page_control.cookie = cookie
                    _search = self.ldap.search_ext(
                            base_dn,
                            scope=scope,
                            filterstr=filterstr,
                            attrlist=attrlist,
                            attrsonly=attrsonly,
                            serverctrls=[server_page_control]
                        )
                else:
                    # TODO: Error out more verbose
                    break
            else:
                # TODO: Error out more verbose
                print "Warning:  Server ignores RFC 2696 control."
                break

        return _results

Or something like that ;-)

Now Online on Fedora Talk: Extension 5100680

jmeeuwen — Mon, 28 Feb 2011 15:36:42 +0000

I recently purchased a SIP phone, one of those hardware devices, so I'm now online on Fedora Talk as well. It's not that softphones such as Ekiga or Twinkle wouldn't work, they just wouldn't work as well while I'm connected to a VPN (with my laptop). A Siemens C475 IP DECT solves the problem of lag for me ;-)

I'm on extension 5100680, so if you need me, and you have Fedora Talk, give me a quick call!

Some Vulcan Logic

jmeeuwen — Fri, 18 Feb 2011 11:51:41 +0000

To the people failing to see a point, whether they value a point as much as the originator does or not, whether they agree with a point in part or in full or not at all;

A feed is created, with filtered content
People will subscribe to this new feed instead of the all-inclusive one, if not just for the fact there's plenty of people
To get your message out to these people, one must have their message included in this new feed

Whether the originator chooses words such as "having a voice" or "censored" or "justfedora" is utterly m00t, as the choice of words illustrates a point, but do not by themselves make a point.

For example, I see what Seth and Andrea intended with Planet "Just Fedora" Edited, and I applaud the initiative as well as the fact that somebody with a FAS account not even a month old today is enabled to make this big a dent.

That said, the point remains to be the same; people who think they have something to say will need to be included on Planet Edited or are, as part of the audience only reads what is on Planet Edited, silenced in part.

Re: On Ownership

jmeeuwen — Wed, 16 Feb 2011 13:59:12 +0000

In response to Mairin Duffy, whom, by the way, I respect very much, and I think deserves your respect as well.

Mo does an awesome job engaging an audience in Free Software that would have otherwise be left to their own fate wading through a hell for the rest of their lives, an audience that would never have been moved by us mortals focused on the technical side of things. I can't wait to hear of the results on SXSW, honestly. Note I know I'm leaving out an awful lot appreciation for other work she's done [for all of us] over many, many years of passionate engagement in what you probably care just as passionately about, as does the rest of us.

That said, however, on the subject of ownership... yes indeed we do make it. That doesn't say anything about the ownership though. I think every single one of us community members have given the Fedora brand the value it has today. Though I'm doubtful it requires the level of, or means through which it is getting such, protection to date, I do realize how something as valuable to so many of us must have someone be the owner in order to protect it.

However, history shows us that the people giving something value, and as such own that something, are not necessarily the ones deciding what to do with it. This, I think, is the underlying thought behind the recent protests - not whether we make it, but to what extent we actually own what we make.

Blog Now Included on the Censored Planet

jmeeuwen — Wed, 16 Feb 2011 13:23:52 +0000

My blog is now included on Fedora's "Planet Edited" - mind you various people won't like me for calling it censored. Originally, I thought the censored version of planet was going to filter out the 'I had this-and-that for breakfast' type of blog posts, which, usually anyway, have nothing to do with Fedora at all. However, after some clarification from Andrea Veri, it seems a relation between the posts content and Fedora isn't sufficient - the blog post must be specifically about Fedora.

I suppose what this will result in is a series of blog posts from team leaders and whatever other semi-official titles you can attach to the wide variety of Ninjas within the Fedora Project. Speculating about content, I can think of announcements, progress reports, invititations to attend meetings either in person or virtually, but also; event reports from our Ambassadors, speculation on pre-mature ideas and concepts, and blog posts like this one, from... let's call'em "opinion-makers" shall we?

I think that's great. It's censored, as technical posts like my post on noop I/O schedulers in KVM environments through Puppet and Augeas apparently do not seem to fit the filter "about Fedora" though I think they are related to Fedora or at the very least interesting to some small amount of Fedora people. However, as I've said, my misunderstanding of what the censored version of planet was about was clarified.

Ultimately, Planet Edited is what our dear self-regulating community should want from the original planet - but without the censorship. Somehow people on the original planet are unable to, forget or refuse to show constraint in what they'll make end up on the Fedora Planet... they omit the appropriate tagging or include an all inclusive feed on Planet. I'm one of those people including their entire blog on planet, but then again bits and bytes in Free Software is about all I live and breath for.

Let's not forget it is planet.fedoraproject.org that now has a moderated version to achieve the exact same measure of control over content, but top-down. It's supposed to work the other way around... anyone of us should show constraint pushing something out to planet, asking "Is this what I would like to see others post to planet?" - bearing in mind I lose it every once in a while, too. Now though, Planet Edited is going to make people feel excluded, not necessarily a positive influence on anyone's gut feeling. The people with their blog included in the edited version of Planet -like me- are now on some sort of virtual pedestal, with more exposure to the general audience - also the electorate. I think the moderated version of our planet is restrictive, divisive and exclusive, whereas I would want our community to be more inclusive - and yes that includes girl scouts.