en.credativ blog: Category Support

credativ and Black Duck announce International Partnership

2010-12-06T15:13:54Z

Rugby, 6 December 2010 - credativ Ltd and Black Duck Software Inc. have announced an international partnership to help further the deployment and integration of Open Source Software.

The OSSC (Open Source Support Centre) run by credativ in the UK, US, Germany and Canada will now also be providing support for customers of Black Duck Software Inc.

Black Duck Software is a worldwide provider of “managed software component reuse” solutions; they support businesses and organisations who use Open Source and third party source code in adhering to relevant licensing obligations, thereby reducing the associated business risks.

Through this partnership with credativ, Black Duck can now also offer comprehensive technical support for the many free software projects which are developed through extensive developer communities rather than through an organisation. This service guarantees Black Duck customers additional security for complex Open Source services and provides an alternative which is comparable to the manufacturer's support available with proprietary software.

Mr. Chris Halls, Managing Director of credativ Ltd in the UK, explains:

“We are delighted about the partnership with Black Duck. We hope that combining our competencies will enable us to cover all the requirements for safe operation of Open Source software. Our partnership is a good basis for further international expansion - our Open Source Support Centres will be enhancing Black Duck's service offering, not only for the US but also the European market.”

If you would like to know more about our Open Source involvement simply leave us a comment here... alternatively please contact us directly.

About credativ

Founded in 1999, credativ is an independent consulting and services company which operates from Germany, the U.K., Canada, and the U.S. With a large team of experts in open source software, credativ offers a vast knowledge base that can be tapped into by its clients. The company focuses on the service and support of open source software with a comprehensive range of services, including open source consulting, architectural and technical advice, open source software development, open source training, and personalized support. credativ is “Your One-Stop Shop for Open Source Support” ^TM.

The Open Source Support Centre (OSSC) offers support for the following:

Debian, Kubuntu, Ubuntu, Xandros, SUSE, Red Hat, Fedora, CentOS, Linspire, Mandriva, Slackware, Open BSD, Gnome, KDE, MySQL, PostgreSQL, PostGIS, Slony, Zarafa, eGroupware, Kolab Groupware, Scalix, SugarCRM, vtiger, CITADEL, Mozilla-Firefox, Mozilla-Suite, OpenOffice, Thunderbird, Wine, Apache, Asterisk, OpenSER, FreePBX, OpenPBX, CallWeaver, SpamAssassin, ClamAV, OpenLDAP, OTRS, RT, Samba, Cyrus, Dovecot, Exim, Postfix, sendmail, Amanda, Bacula, DRBD, Heartbeat, Keepalived, Nagios, Open Security Filter, Ferm, FAI, Squid, XEN, VirtualBox.

For further information please contact:

credativ Ltd,
36 Regent Street,
Rugby,
Warwickshire,
CV21 2PS

Press contact

Simon Bowring

Tel: +44 (0) 1788 298150
Fax: +44 (0) 1788 298159
Email: simon.bowring@credativ.co.uk

About Black Duck Software Inc

Black Duck Software is the leading provider of products and services for automating the management, governance and secure use of open source software, at enterprise scale, in a multi-source development process. Black Duck™ enables companies to shorten time-to-solution and reduce development costs while mitigating the management, compliance and security challenges associated with open source software. Black Duck Software powers Koders.com, the industry’s leading code search engine for open source, and is among the 500 largest software companies in the world, according to Softwaremag.com. The company is headquartered near Boston and has offices in San Mateo, California, London, Paris, Frankfurt, Hong Kong, Tokyo and Beijing.

For more information, visit www.blackducksoftware.com.

Black Duck, Know Your Code and the Black Duck logo are registered trademarks of Black Duck Software, Inc. in the United States and other jurisdictions. Koders is a trademark of Black Duck Software, Inc. All other trademarks are the property of their respective holders.

Press contacts

Peter Vescuso
Black Duck Software
press@blackducksoftware.com
+1 781-891-5100

Ann Dalrymple
TopazPartners

credativ leads the market with a pre-paid, international Open Source support solution

2010-03-24T15:30:40Z

This week, credativ launches its Open Source Support Card. With this card Open Source Support can be bought at a fixed price - without a binding contract.

After a long preparation phase we are now offering our trusted services in a new, simple format; with the Open Source Support Card you get a fixed contingent of project-specific, pre-paid services.

Customers using the Open Source Support Card have the unique advantage of full cost control; the card can be purchased as a product, without any obligation to sign an agreement for a specific length of time. This may be of particular benefit to larger companies, where new contracts have to be reviewed and cross-reviewed before they can be authorised. A summary of the advantages of the new pre-paid support format include:

Open Source Support for a specific project
Support not restricted to a specific number of desktops and servers within a company
A tempting price model, starting at just £480
Full control of costs
Support available via telephone, e-mail and remote access
Bilingual support - help given in English or even German, if required! ;-)
Cost of support NOT determined by the number of CPUs or users
NO binding contract - easy way to purchase
NO call centre - direct access to the experts
Support units can be used for the following services:

administration
installation (remote)
consultancy

All support is provided to the usual credativ standard. Just as you would expect from our usual contracts, the cost of the service is not determined by the number of CPUs, users, or DB entries. Support units purchased through the Support Card can be used for all related problems within a company - no matter which workstation or server they come up on. The support itself is provided by our Open Source Support Centre: you won't have to deal with non-technical staff or battle through FAQ scripts - our Linux experts and Open Source specialists are on hand to take calls directly. Many of us are actively involved in contributing to a number of Open Source projects - as regular readers will already be aware. ;-)

The new Open Source Support Card is also an exciting development for the wider Open Source community. By offering yet another attractive support option for free distributions, we hope to prove that there is now no reason not to consider Debian and CentOS as viable alternatives to commercial distributions.

The Open Source Support Card is designed and marketed in such a way that resellers can also get on board, making access to support that bit easier for consumers: imagine purchasing your server online and while you're at it being able to drop a Support Card into the shopping basket as well - Open Source Support with just one click!

Currently the Support Card is just available for Debian and CentOS in the UK and in Germany, although we will soon be offering it in the US and Canada too. If you have any questions or comments we'd be pleased to hear from you - we've put a lot of effort into this new product, and are looking forward to the response from our customers and the wider community.

[Howto] Sys admin tool of the week: sysstat

2010-03-19T11:20:07Z

The tool chain of a sys admin should always be comprised of effective tools. Today we are introducing the package sysstat.

Sysstat is a collection of command line tools dedicated to providing the system administrator with a quick overview of the performance of the system. They work as front-ends to the Kernel and therefore can never provide more data than the Kernel itself gathers, although the interface is much more user-friendly than querying Kernel parameters manually.

iostat

iostat is the way to go if there are problems with the throughput of a disk, NFS storages or the CPUs. For example, if your system is behaving strangely, iostat can be used to identify I/O waits:

Linux 2.6.31-19-generic (mymachine)         04.03.2010      _x86_64_        (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          11,82    0,29    3,44    1,25    0,00   83,20

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               9,39       161,19       168,44    4264806    4456696

There are many options available for iostat but these are the most interesting, and they deal with specific outputs:

-d
Just show the hard disk data.: -c
Just show the CPU data.: -p
Show the I/PO data for each partition.: -n
Show the I/O data for the NFS partitions.: -x
Extended information for the hard disks.: -t $NUM1
Tells the program after how many seconds the result should be refreshed.

mpstat

mpstat is the next tool in the chain: it helps when analysing the CPU load. If you call it with no options, the default information will be shown, in the same way that the iostat results are.

Linux 2.6.31-19-generic (mymachine)         04.03.2010      _x86_64_        (2 CPU)

17:01:52     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
17:01:52     all   11,96    0,29    3,26    1,23    0,10    0,11    0,00    0,00   83,06

In contrast to iostat, you see the actual load on hard and software interrupts. The option -A extends this information further: for each processor, the statistics and interrupts per second are shown.

If you add an int $NUM after the command, the process runs without end and refreshes the output every $NUM seconds.

pidstat

pidstat concentrates on the processes itself: it shows a list of all processes. The option -C enables you to filter these by a given string:

Linux 2.6.31-19-generic (mymachine)         04.03.2010      _x86_64_        (2 CPU)

17:02:32          PID    %usr %system  %guest    %CPU   CPU  Command
17:02:32            1    0,00    0,00    0,00    0,00     1  init
17:02:32         2888    0,00    0,00    0,00    0,00     0  start_kdeinit
17:02:32         2889    0,00    0,00    0,00    0,00     0  kdeinit4

The additional option -d shows I/O statistics about the given processes, -p takes the PID as an argument to focus on known processes. Finally -r brings up an overview of the memory load.

Again, an int $NUM after the command lets the process run continuously, refreshing the output every $NUM seconds.

sar

All sysstat tools so far have had one flaw, only showing a snapshot of the current state and unable to look into the behaviour of the system in the past or during load time. Such information must be collected in the background, which is exactly what sar and its tools are all about: it collects the performance data of the system every ten minutes via cron job. If you call the tool with the default values you get a first impression:

Linux 2.6.31-19-generic (mymachine)         04.03.2010      _x86_64_        (2 CPU)

09:30:30          LINUX RESTART

09:35:02        CPU     %user     %nice   %system   %iowait    %steal     %idle
09:45:01        all     17,38      1,02      5,10      3,87      0,00     72,63
09:55:01        all     11,90      0,27      2,86      0,75      0,00     84,23
10:05:01        all     10,20      3,52      3,46      2,55      0,00     80,27
10:15:02        all     12,96      0,32      3,18      0,65      0,00     82,89
10:25:01        all      7,94      0,18      3,17      2,42      0,00     86,30
10:35:01        all     12,41      0,89      4,55      0,56      0,00     81,60
10:45:02        all      8,97      0,09      3,51      0,89      0,00     86,55

All possible information can be collected with sar -A although the amount of output will be too much for any screen size. There are too many options involved in decreasing the output with sar to cover here, but they are discussed in detail on the man page.

RHCS: an Introduction

2010-03-03T13:55:40Z

The Red Hat Cluster Suite is a framework to bind two or more machines together to jointly handle one task. The following article gives an introduction to RHCS in terms of service failover.

Linux is used daily in mission-critical environments all over the world. It follows that Linux can be required to fulfil a range of needs with relation to availability and stability. The Red Hat Cluster Suite (RHCS) is designed with these needs in mind; it enables the admin to set up a cluster of machines which all handle the same task or provide the same service. If the machine providing the service goes down, another machine then steps in and takes over.

Core elements of RHCS

RHCS consists of four core components:

cluster infrastructure
high availability service management
tools for the cluster administration
Linux virtual server routing

The cluster infrastructure includes all the core components necessary for the set up and running of a cluster of several nodes. These components manage the integration of nodes, shutting them down where problems occur (fencing), replicating the configuration and so on.

After the cluster has been set up the next step is to define the high availability service management. This is a service running on one node with other nodes configured for failover. The HA service management includes defining the service, start/stop scripts, ports, storage places and other resources as well as the priority of the different failover nodes.

The next core component is not so much a necessary key element but more a set of helpful tools: the cluster administration tools. In theory they are not critical to the running of the RHCS, although in practise it would be stupid to run the RHCS without them. They incorporate GUI tools, web pages for accessing cluster data and tools for status queries, among other things.

The situation is similar for the Linux virtual server routing; although RHCS documentation lists Linux virtual server routing as a core component, this functionality is not always needed as it "only" provides load balancing functions on IP level and re-routes the traffic when a node brakes down.Besides these official core components of RHCS the system can incorporate other services when they are available: GFS (Global File System) and Cluster Logical Volume Manager. They help with mounting network block devices, making storage management much easier.

Structure of a RHCS Cluster

To create an initial RHCS cluster a substantial set of machines is needed:

Shared storage like iSCSI or Fibre Channel.
For each node a method to detach it from the cluster (fencing), either by network or by a controllable power switch.
At least two nodes with a network connection.
A switch.

It is important that the shared storage is not running on one of the nodes itself - that would render the idea of fencing useless. Also keep in mind that the machines listed here only describe the minimum hardware configuration - a larger cluster would of course require many more nodes.

Closing words

RHCS offers a well thought out framework for managing a cluster, especially when it comes to service failover. Using RHCS makes securing your mission-critical systems easy, and makes them highly available with standard hardware.

The R in RHCS implies that this method only runs on RHEL machines - but this is not the case, as we will demonstrate in one of our upcoming articles.

[Howto] Introduction to Puppet

2010-03-02T11:29:47Z

The administration of a large number of servers can be quite tiresome without a central configuration management. This article gives a first introduction into the configuration management tool, Puppet.

Introduction

In our daily work at the Open Source Support Center we maintain a large number of servers. Managing larger clusters or setups means maintaining dozens of machines with an almost identical configuration and only slight variations, if any. Without central configuration management, making small changes to the configuration would mean repeating the same step on all machines. This is where Puppet comes into play.

As with all configuration management tools, Puppet uses a central server which manages the configuration. The clients query the server on a regular basis for new configuration via an encrypted connection. If a new configuration is found, it is imported as the server instructs: the client imports new files, modifies rights, starts services and executes commands, whatever the server says. The advantages are obvious:

Each configuration change is done only once, regardless of the actual number of maintained servers. Unnecessary - and pretty boring - repetition is avoided, lucky us!
The configuration is streamlined for all machines, which makes it much easier to maintain.
A central infrastructure makes it easier to quickly get an overview about the setup - "running around" is not necessary anymore.
Last but not least, a central configuration tree enables you to incorporate a simple version control of your configuration: for example, playing back the configuration "PRE-UPDATE" on all machines of an entire setup only takes a couple of commands!

Technical workflow

Puppet consists of a central server, called "Puppet Master", and the clients, called "Nodes". The nodes query the master for the current configuration. The master responds with a list of configuration and management items: files, services which have to be running, commands which need to be executed, and so on - the possibilities are practically endless:

The master can hand over files which the node copies to a defined place - if it does not already exist.
The node is asked to check certain file and directory permissions and to correct them if necessary.
Depending upon the operating system, the node checks the state of services and starts or stops them. It can also check for installed packages and if they are up to date.
The master can force the node to execute arbitrary commands

Of course, in general all tasks can be fulfilled by handing over files from the master to the client. However, in more complex setups this kind of behaviour is not easily arranged, nor does it simplify the setup. Puppet's strength is that it facilitates abstract system tasks (restart services, ensure installed packages, add users, etc.), regardless of the actual changed files in the background. You can even use the same statement in Puppet to configure different versions of Linux or Unix.

Installation

First, you need the master, the center of all the configuration you want to manage: apt-get install puppetmaster Puppet expects that all machines in the network have FQDNs - but that should be the case anyway in a well maintained network.

Other machines become a node by installing the Puppet client: apt-get install puppet

Puppet, main configuration

The Puppet nodes do not need to be configured - they will check for a machine called "Puppet" in the local network. As long as that name points to the master you do not have to do anything else.

Since the master provides files to the nodes, the internal file server must be configured accordingly. There are different solutions for the internal file server, depending on the needs of your setup. For example, it might be better for your setup to store all files you provide to the nodes on one place, and the actual configuration you provide to the nodes somewhere else. However, in our example we keep the files and the configuration for the nodes close, as it is outlined in Puppet's Best Practice Guide and in the Module Configuration part of the Puppet documentation.Thus, it is enough to change the file /etc/puppet/fileserver.conf to:

[modules]
allow 192.168.0.1/24
allow *.credativ.de

Configuration of the configuration - Modules

Puppet's way of managing configuration is to use sets of tasks grouped by topic. For example, all tasks related to SSH should go into the module "ssh", while all tasks related to apache should be placed in the module "apache" and so on. These sets of tasks are called "Modules" and are the core of Puppet - in a perfect Puppet setup everything is defined in modules! We will explain the structure of a SSH module to highlight the basics and ideas behind Puppet's modules. We will also try to stay close to the Best Practise Guide to make it easier to check back against the Puppet documentation.

Please note, however, that this example is an example: in a real world setup the SSH configuration would be a bit more dynamic, but we focused on simple and easy-to-understand methods.

The SSH module

We have the following requirements:

The package open-ssh must be installed and be the newest version.
Each node's sshd_config file has to be the same as the one saved on the master.
In the event that the sshd_config is changed on any node, the sshd service should be restarted.
The user credativ needs to have certain files in his/her directory $HOME/.ssh.

To comply with these requirements we start by creating some necessary paths:

mkdir -p /etc/puppet/modules/ssh/manifests
mkdir -p /etc/puppet/modules/ssh/files

The directory "manifests" contains the actual configuration instructions of the module and the directory "files" provides the files we hand over to the clients.

The instructions themselves are written down in init.pp in the "manifests" directory. The set of instructions to fulfil aims 1 - 4 are grouped in a so called "class". For each task a "class" has one subsection, a type. So in our case we have four types, one for each aim:

class ssh{
        package { "openssh-server":
                 ensure => latest,
        }
        file { "/etc/ssh/sshd_config":
                owner   => root,
                group   => root,
                mode    => 644,
                source  => "puppet:///ssh/sshd_config",
        }
        service { ssh:
                ensure          => running,
                hasrestart      => true,
                subscribe       => File["/etc/ssh/sshd_config"],
        }
        file { "/home/credativ/.ssh":
                path    => "/home/credativ/.ssh",
                owner   => "credativ",
                group   => "credativ",
                mode    => 600,
                recurse => true,
                source  => "puppet:///ssh/ssh",
                ensure  => [directory, present],
        }
}

Each type is another task and calls another action on the node:

package
Here we make sure that the package openssh-server is installed in the newest version.: file
A file on the node is compared with the version on the server and overwritten if necessary. Also, the rights are adjusted.: service
Well, as the name says, this deals with services: in our case the service sshd must be running on the node. Also, in case the file /etc/ssh/sshd_config is modified, the service is restarted automatically.: file
Here we have again the file type, but this time we do not compare a file, but an entire directory.

As mentioned above, the files and directories you configured so that the server provides them to the nodes must be available in the directory /etc/puppet/modules/ssh/files/.

Nodes and modules

We now have three parts: the master, the nodes and the modules. The next step is to tell the master which nodes are related to which modules. First, you must tell the master that this module exists in /etc/puppet/manifests/modules.pp:

import "ssh"

Next, you need to modify /etc/puppet/manifests/nodes.pp. This specifies which module is loaded for which node, and which modules should be loaded as default in the event that a node does not have a special entry. The entries for the nodes support inheritance.

So, for example, to have the module "rsyslog" ready for all nodes but the module "ssh" only ready for the node "external" you need the following entry:

node default {
    include rsyslog
}
node 'external' inherits default {
    include ssh
}

Puppet is now configured!

Certificates - secured communication between nodes and master

As mentioned above, the communication between master and node is encrypted. But that implies you have to verify the partners at least once. This can be done after a node queries the master for the first time. Whenever the master is queried by an unknown node it does not provide the default configuration but instead puts the node on a waiting list. You can check the waiting list with the command: # puppetca --list

To verify a node and incorporate it into the Puppet system you need to verify it: # puppetca --sign external.example.com The entire process is explained in more detail in the puppet documentation.

Closing words

The example introduced in this article is very simple - as I noted, a real world example would be more complex and dynamic. However, it is a good way to start with Puppet, and the documentation linked throughout this article will help the willing reader to dive deeper into the components of Puppet.

We, here at credativ's Open Source Support Center have gained considerable experience with Puppet in recent years and really like the framework. Also, in our day to day support and consulting work we see the market growing as more and more customers are interested in the framework. Right now, Puppet is in the fast lane and it will be interesting to see how more established solutions like cfengine will react to this competition.

PostgreSQL Agenda 2010

2010-02-11T11:36:02Z

PostgreSQL is taking some big steps forward this year. The publishing of version 9.0 is just around the corner, while some of the older versions are coming to the end of their lifetime.

PostgreSQL 9.0

2010 will see PostgreSQL release its first major new version for a long time: version 9.0. The release of version 9.0 is an important milestone in the evolution of PostgreSQL. Integral to this release are new features such as the operation of standby servers in read-only mode (hot standby) and an integrated replication solution.

Hot Standby

Hot standby will allow a PostgreSQL instance to receive read requests on so-called standby nodes. The basic principle is the same as that included since version 8.0 under the name PITR (Point In Time Recovery) or WAL-Shipping. At regular intervals a copy of the database complete with transaction logs is generated (known as the Write Ahead Log or WAL), so that the standby nodes can be kept up to date with changes in the master database. In practice, this means incrementally applying all changes that were made on the master database from the point when the standby node was created. This was implemented as warm standby in previous versions, i.e. the database contained within a standby node could not be used by applications. However, with hot standby, it is possible to execute transactions on the node as long as they do not contain write operations. This is especially useful for high availability systems or analyses that can be run on separate nodes.

Streaming Replication - inbuilt asynchronous replication

For a long time in the PostgreSQL community, it was widely thought amongst developers that the infrastructure of an integrated replication system was difficult to maintain due to the complex requirements and variety of deployment scenarios. Therefore the flexibility and security expected of such solutions has been implemented in various specialised external projects. In recent years however, extensive communication with users has led to a large proportion of the desired functionality being implemented within PostgreSQL, mostly in the area of high availability. Thanks to this, an integrated solution is no longer just a dream, even for systems containing hundreds of gigabytes of data. Furthermore, the availability of an integrated replication solution is a critical factor for many data centres when choosing a database management system. Streaming replication means that PostgreSQL can now offer an integrated solution for asynchronous replication of a primary database server (read- and writeable) to multiple additional secondary servers (read only). This functionality, based in part on the infrastructure implemented for WAL-Shipping, has made possible the replication of transactions in much smaller intervals. (Data is sent directly from the primary to the secondary server, hence the name "streaming"). Moreover, streaming replication permits the simple implementation of PostgreSQL replication clusters with multiple nodes. Whilst this is already possible with the existing hot-standby solution, it is much more complicated. Since the replicating data is based upon information from the WAL, this solution is extremely robust. Deployment scenarios such as partially replicated databases or modified database schemas are not currently possible on each replicated node, although these requirements are still achievable through the use of solutions such as Slony-I, Londiste or Bucardo.

Farewell to PostgreSQL 7.4, 8.0 and 8.1

2010 will herald the end of support for some versions of PostgreSQL. For the first time, three main versions are due to be phased out in the same year:

PostgreSQL 7.4, Juli 2010
PostgreSQL 8.0, Juli 2010
PostgreSQL 8.1, November 2010

Support for PostgreSQL 8.0 and 8.1 on Windows was discontinued with the release of PostgreSQL 8.3 in February 2008. PostgreSQL 8.0 was the first release that could run natively on Windows, with many bugs being patched during development that could no longer be backported to older versions. So for quite some time now, Windows users have had to use at least PostgreSQL 8.2. We are now officially coming to the end of support for all other platforms, and also the last of the 7 series releases; PostgreSQL 7.4 is finally being phased out after 7 years. "Phased out" in PostgreSQL terms means that, primarily, no further binary packages or releases will be made and no further complex fixes will be ported, although the source code will continue to be available. As a rule, the PostgreSQL development team limit the lifetime of a main release to five years. However, the Windows variants of PostgreSQL 8.0 and 8.1 are proof that the lifetime of releases for single platforms can be shortened. The Release Policy can be found in the developer wiki on the PostgreSQL project site.

Outlook

Although PostgreSQL 9.0 is not yet finished, hot standby can be tested with version 8.5alpha3. Incidentally, the current alpha version is still named after the developer's branch 8.5, as it was named before the decision was made to move to version 9.0. Version 9.0alpha4 can be expected by late February, and should also include streaming replication. For those interested in testing, we are planning a guide with the title "How To Beta Test", which provides some guidelines for testing and feedback.

[Howto] Using dovecot with Sieve in RHEL/CentOS 5

2010-02-02T15:06:11Z

The current RHEL/CentOS 5 package has one flaw: it was compiled without Sieve support. However, with a bit of rpm magic, the package can be rebuilt and produces an additional sieve package.
The current RHEL/CentOS 5 version has a rather old dovecot, 1.0.7. Even worse, the plugin for Sieve wasn't included in this build. Of course, given the old version of dovecot, an update to a newer version with Sieve is worth a thought; however, there are situations where that is simply not an option.

In such cases you can still rebuild the old package with a modified rpm file: download the source RPM, install it with
rpm -Uvh dovecot-1.0.7-7.el5.src.rpm
get the diff from below and apply it to the spec file:
patch < dovecot.diff
Download the sources as given in the now modified spec file to your SOURCES directory, and rebuild the package:
rpmbuild -ba dovecot.spec
and welcome the new sieve plugin dovecot-sieve-1.0.4-7.x86_64.rpm. Install it and continue as usual. And as a small help for writing Sieve scripts: you can verify them on various online services like the one from the PHP Sieve library.

Be careful, however: you have to maintain this package on your own - especially when a dovecot update comes along or when the sieve plugin code is updated. Do bear in mind, though, that this information, as with all howtos, should be followed at your own discretion; it comes with no warranty, and might eat your cats.

And here is the patch for the spec file:

--- dovecot.old.spec    2010-03-11 09:59:38.598277799 +0100
+++ dovecot.spec        2010-03-11 09:58:08.639526842 +0100
@@ -1,7 +1,10 @@
 %define upstream 1.0.7
+%define sieve_upstream 1.0.4
 %define pkg_version 1.0.7
 %define my_release 7
 %define pkg_release %{my_release}%{?dist}
+%define pkg_sieve_version 1.0.4
+%define pkg_sieve_release %{my_release}%{?dist}
 
 Summary: Dovecot Secure imap server
 Name: dovecot

@@ -12,6 +15,7 @@
 
 %define build_postgres 1
 %define build_mysql 1
+%define sieve_name dovecot-sieve
 
 Source: http://dovecot.org/releases/%{name}-%{upstream}.tar.gz
 Source1: dovecot.init

@@ -22,6 +26,7 @@
 Source6: perfect_maildir.pl
 Source7: dovecot-REDHAT-FAQ.txt
 Source8: dovecot.sysconfig
+Source9: http://dovecot.org/releases/sieve/%{sieve_name}-%{sieve_upstream}.tar.gz
 Patch100: dovecot-1.0.7-default-settings.patch
 Patch102: dovecot-1.0.rc2-pam-setcred.patch
 Patch103: dovecot-1.0.beta2-mkcert-permissions.patch

@@ -80,6 +85,16 @@
 primarily in mind.  It also contains a small POP3 server.  It supports mail 
 in either of maildir or mbox formats.
 
+%package sieve
+Requires: %{name}
+Summary: CMU Sieve plugin for dovecot LDA
+Group: System Environment/Daemons
+Version: %{pkg_sieve_version}
+Release: %{pkg_sieve_release}
+
+%description sieve
+This package provides the CMU Sieve plugin for dovecot LDA.
+
 %prep
 %setup -q -n %{name}-%{upstream}

@@ -94,6 +109,8 @@
 %patch503 -p1 -b .CVE-2008-4577
 %patch504 -p1 -b .CVE-2008-4870
                               
+%setup -q -n %{name}-%{upstream} -D -T -a 9
+
 %build
 rm -f ./configure
 libtoolize -f

@@ -115,6 +132,16 @@
 
 make %{?_smp_mflags}
 
+cd %{sieve_name}-%{sieve_upstream}
+rm -f ./configure
+libtoolize -f
+autoreconf
+%configure                           \
+    INSTALL_DATA="install -c -p -m644" \
+    --with-dovecot=../
+
+make %{?_smp_mflags}
+
 %install
 rm -rf $RPM_BUILD_ROOT
 make install DESTDIR=$RPM_BUILD_ROOT

@@ -169,6 +196,11 @@
 mv $RPM_BUILD_ROOT%{docdir} $RPM_BUILD_ROOT%{docdir}-%{version}
 mkdir -p $RPM_BUILD_ROOT/var/lib/dovecot
 
+# dovecot-sieve
+pushd %{sieve_name}-%{sieve_upstream}
+make install DESTDIR=$RPM_BUILD_ROOT
+popd
+
 %pre
 /usr/sbin/useradd -c "dovecot" -u %{dovecot_uid} -s /sbin/nologin -r -d /usr/libexec/dovecot dovecot 2>/dev/null || :
 
@@ -243,6 +275,9 @@
 %attr(0750,root,dovecot) %{docdir}-%{version}/examples/mkcert.sh
 %attr(0750,dovecot,dovecot) %dir /var/lib/dovecot
 
+%files sieve
+%defattr(-,root,root)
+%{_libdir}/%{name}/lda/lib90_cmusieve_plugin.so
 
 %changelog
 * Mon Nov 24 2008 Michal Hlavinka  - 1.0.7-7

News flash: OpenLogic and credativ announce Partnership

2010-01-27T13:55:23Z

credativ and OpenLogic today announced a partnership, broadening enterprise-grade Open Source support in Europe and North America.

The news is spreading across the net fast: OpenLogic and credativ have teamed up so that credativ can offer support to OpenLogic's enterprise customers across North America and Europe. This will combine credativ's extended experience and knowledge in supporting Open Source software with OpenLogic's enterprise-ready and certified Open Source software solutions.

With this partnership, OpenLogic's customers will get in-depth 3rd level support by credativ as *THE* global, independent provider of expertise in a variety of open source technologies. Besides the 3rd level support by the Open Source Support Center, key points of the partnership also include backstop support for CentOS - OpenLogic announced full enterprise support of CentOS in December 2009 - as well as global backstop support for OpenLogic's 500+ certified Open Source enterprise packages.

In the words of Steve Gandchamp, CEO of OpenLogic:

OpenLogic already serves a number of Fortune 500 global clients. This partnership with credativ significantly strengthens our ability to serve these customers in Europe."

Joe Conway, president of credativ US, added:

credativ is uniquely positioned as a global, independent provider of technical expertise across a wide spectrum of open source technologies. Our partnership with OpenLogic will allow us to assist organizations already benefiting from OpenLogic's enterprise offerings to expand their successful use of open source software.

The press releases can be read on all big news sites, for example here (OpenLogic) or here (credativ US).

Bringing Groupware to KDE - Akonadi resources for Open-Xchange and Groupdav

2010-01-19T12:39:47Z

Akonadi is the central point of accessing PIM data for all KDE applications. It abstracts all the different implementation details of various sources so that the mail program or calendar application does not need to know the details of how to access the sources itself. However, Akonadi does need these details, which is where its resources come into play.

Akonadi communicates with other e-mail or calendar sources via so called "resources". Currently there are resources for accessing locally stored information (mostly from older KDE installations) as well as to access IMAP folders and maildirs. But there is a huge gap when it comes to calendar data: many users store their calendars on groupware servers like Google Calendar, Apple's Calendar Server, Citadel, Open-XChange and so on; and while support wasn't perfect in KDE 3.x times, it was almost non-existent within Akonadi in KDE 4.x.

For that reason, we at credativ GmbH put two of our KDE developers to the task: Marco Nelles (mne) developed a plugin for the GroupDav protocol and Tobias König (tko) sat down to implement support for Open-XChange. In the near future, one or both plan to help with the development of a CalDav plugin, THE groupware interface for Google, Apple and the others.

Here are some Q&A regarding their work:

First things first, since we are an Open Source company: where is the code?

mne, tko: The code for both plugins can be found in the KDE svn in playground: the Open-Xchange plugin can be found in resources/openxchange, the GroupDAV plugin is called CAlgo and can be found in /pim/calgo.

What is the stage of the source? Alpha, Beta, RC?

tko: Brave people can already test the OX plugin, I would consider it as RC. Compared to its KDE 3.x equivalent it supports the same features plus some extras: display of more than one calendar or addressbook through one resource, support of contact lists and offline/caching support by Akonadi. I've developed against OX 6.14.0, but it should work well with all OX releases of the 6.x cycle.

mne: Well, the resource is in playground for a reason. It is somewhat between Alpha and Beta.

And how does the feature set compare to its KDE 3.x equivalent? Against which software was it tested?

mne: It should offer the same features as its KDE 3.x equivalent, although the KDE 3.x one was better tested. I've tested it against Citadel and eGroupWare.

You've said the plugins are still in playground - when will they be shipped with the KDE Software Compilation (KDE SC?

tko: The development started too late for KDE SC 4.4, but it will definitely be shipped with KDE SC 4.5.

mne: Never. Most likely, it won't leave the playground. I will concentrate on the development of a CalDav resource which seems to be more popular and is more important. Also, there is a chance that the CalDav plugin might even handle the GroupDav part as well.

And why did you develop it as an Akonadi plugin?

tko: Akonadi is the PIM framework for KDE SC 4.5 and following. It offers fundamental advantages in comparison to the old KDE 3.x KResources, and since a number of credativ employees use KDE desktops, it was a natural step to provide Akonadi plugins to the most common groupware servers.

mne: You could also ask: why did I develop for KDE? :-) To be honest, Akonadi provides a great API to quickly develop efficient plugins to arbitrary PIM data soures. What's more, in an environment where PIM data are becoming more and more important, Akonadi is just the next logical step. For me personally it was also a great opportunity to get in touch with this new KDE technology.

Thanks for your time and of course for your code, guys!

SkoleLinux project for German schools continues after the pilot phase

2009-10-15T13:34:16Z

Using Linux in schools gives children the ability to experience technologies aside of main stream operating systems, thus learning about technical diversity and enhancing their skills in different information technologies. credativ is about to finish a pilot phase using an adapted version of SkoleLinux with about ten schools over a year, and another two dozen schools are preparing to join the project.

Beginning this year, credativ and a local government authority formed a alliance to explore the possiblities of Linux usage in schools. For this reason the local government decided to pick about ten test schools and provided them with an adapted version of SkoleLinux which includes Cipux for a comprehensive pupil data management.

The hardware setup is notable since it was especially designed with the needs of the schools in mind: besides the usual main server (called 'Tjener' in SkoleLinux), all schools were provided with so-called laptop trolleys. A trolley contains 12-16 laptops, two wireless access points, a switch and a lan cable. When the trolley is brought into a class room, the lan cable is connected to the main network via a plug in the class room. The laptops, which are taken out of the trolley by the pupils, use the wireless lan to access the trolley and thus have a connection to the server. Additionally, schools, if they had the hardware, were able to use a terminal server.

credativ's job was to install and set up the systems, whilst providing the schools with 2nd and 3rd level support. Since at that time only a virtual image for the server was available, credativ had to develop the installation mechanism for the terminal server as well as for the clients. The installation was based on preseeding to enable schools to re-install the systems via network on the fly if for some reason a system failed. This method was also used to bring up the terminal servers - so even when an entire terminal server crashed it could be re-installed immediately by the school in just two clicks.

Looking back now, the project was highly interesting and provided valuable experience. A good number of bugs were discovered and solved, and we were also able to give the developers lots of feedback about workflow and tools required in a school environment. In addition, we gained an insight into the needs of teachers concerning what tools, software and associated training would be required to enable them to use the system; we were then able to pass this information and our ideas on to local government.

From our perspective it was interesting to see what software was requested by the schools and which setups worked best. For example, not all schools were equipped with terminal servers, but those that did were highly satisfied with the setups. Also, many school admins were used to clone windows images and play them back as soon as they had problems, which is not that common in the Linux world, and wasn't possible in the pilot phase.Out of these experiences and the success of the pilot phase a new round has now been set up, which will include many more schools and a certification program for SkoleLinux business partners. Starting next year, even more schools will have the ability to run Linux based systems - giving pupils freedom of choice and diversity in an otherwise single vendor environment.