Recently in Support Category

In the "Case Study" category we present recent customer projects. This case study focuses on one of our most prolific public sector projects to date, the administration of the Bavarian Capital, the City of Munich.

credativ GmbH have been providing support for the LiMux-Project of Munich's city council since 2008, during which time some 15,000 workstations have been migrated to Linux. After years of planning and a long start phase, the migration recently made real headway.

At the end of November 2012, the goal of the project was finally realized, with more than 12,000 migrated LiMux desktops in operation. The LiMux project has has been hailed as a "Success Story" of mass migration in the public sector, with financial savings of switching from Microsoft Windows and Microsoft Office amounting to more than 10 million euros.

Each Linux desktop is installed, configured and administrated by the council's so-called distribution server. The two main components are the LDAP-based configuration and administration management solution, GOsa², and the Installation Management tool FAI (Fully Automatic Installation).

These backend components have been the main focus of credativ's work for the City of Munich to date. Part of this work has involved planning and developing new features to facilitate daily administrative tasks. Another focus was to improve the scalability in mass installations, whereby the mass rollout of migration was made possible. In the course of this, credativ were able to eliminate many bugs, both small and complex, and standardise the user interface.

LiMux project lead, Peter Hoffman said,

"We have been completely satisfied throughout our collaboration with credativ GmbH in recent years. As a local, open-source oriented, medium-sized service company, credativ GmbH embodies our commitment to advancing the LiMux Project independently of the manufacturer and with open standards".

The main reason for the required work is the nature of the use of GOsa² by the LiMux project: GOsa² is basically a web application that enables the management of users and associated services such as email or file-sharing. The city of Munich did not use GOsa² to create users or change user data (a different program is used to do this), but for configuring users and administrating workstations. Additionaly GOsa² is used extensively by the city of Munich to manage a large number of clients and users.

Main menu of GOsa²

Most of the functionality has been developed specifically for the migration requirements of the City of Munich, it is used rarely, if ever, elsewhere. The main areas where GOsa² is deployed at the City of Munich are:

1. Configuring users' (or groups of users') desktop settings, such as: desktop shortcuts, start menu entries, login / logoff scripts, shares, printers, etc. These settings are queried in LDAP when a user logs in to a workstation and are configured by a corresponding script.

2. Configuring workstations (or groups of workstations) and distribution servers, such as LDAP / NTP server, system-wide shared services and printers. Various services can also be configured for (distribution) servers, such as some LDAP, NTP, or logging servers, as well as software repositories.

3. Configuration of FAI classes for software distribution. FAI is usually managed through text files; changing the different installation profiles and their partitioning schemes, package lists and configuration scripts is simple when the data is stored in LDAP with the GOsa² Web application.

4. Remote maintenance of workstations and distribution servers is possible with the GOsa-SI client / server system, through which systems can be restarted, reinstalled, or switched on and off. This client / server communication enables messages to be sent to logged-in users and allows monitoring of the progress of a system installation.

credativ implemented the extensive changes detailed here over the last few years. By mid-2011, the established code-base of the LiMux project was based on version 2.6 of GOsa² and was publicly available in the 2.6-lhm-branch in the Subversion repository of GOsa². credativ have added over 250 Change Sets to this branch since 2008.

In Autumn 2011 it was decided to move the LiMux Project to the latest version of Gosa², 2.7. To achieve this, changes which were still necessary but not yet integrated into the main development branch were ported to the 2.7 code-base by the end of 2011. This resulted in about 90 changesets.

In GOsa² 2.7, software distribution with FAI and system administration with GOsa-SI had been gradually replaced through new projects, which meant some of the functions used by the City of Munich no longer worked properly. Since the beginning of 2012, these broken functions have been fixed or reimplemented, along with a number of new problems found during extensive testing of GOsa² 2.7. A series of new features have also been implemented. This has led to a further 200 changesets and 4000 new lines of code (while eliminating 1000 lines of code) in the space of around 4 months. This work was made available in the summer of 2012 in a public git repository and sent back upstream to the Open Source Community.

Concerning the paid work, Michael Dusel, Director of the LiMux Project's workstation development, said:

"The years of successful collaboration with credativ GmbH employees have been an absolute pleasure. Particularly during the migration from GOsa² 2.6 to 2.7, we were able to access their prompt and professional support. This meant that newfound problems were quickly resolved by the developers at credativ during the test phase in GOsa² 2.7 and significant new functionality was implemented to our satisfaction."

In addition to the work on GOsa², credativ GmbH has also provided extra support for the City of Munich. Various problems with the workstations have been successfully diagnosed; Debian specialists at credativ GmbH have, for example, supported the packaging and backporting of various packages (such as Firefox and its addons).

In summary, it can be said that the LiMux project is well on its way and we at credativ are proud of our part in it. We hope that the success of this project at the City of Munich will encourage other councils or public sector organisations to consider similar migrations, and we would be glad to offer our expertise and support. If you would like to know more please email limux@credativ.com.

OpenERP is increasingly becoming a serious contender in the ERP market, as its features and usability improve. This tip explains how its flexible views provide ways to save time retrieving the data you want. You can search for the exact data you are interested in by just filling out the necessary search filters, but if there is a search which you perform on a regular basis, you have the option of saving filters to make life easier.

This feature was added in the OpenERP webclient from version 6.0.0 and is available for all users. Simply go to any tree view and you will notice to the bottom right of the search filters, there is a drop down selection box '-- Filters --'... this is where the magic happens.

To get started creating your own saved filter, enter the search as normal and after pressing the 'Search' button, simply select 'Save filter' from the drop down box, give it a name and press 'Save'.

If you already have a filter defined for the view you are currently in, select your filter from the options available and it will be immediately applied on top of your current search results, replacing the currently selected filter if one is already selected.

For the power users there are ways to customize your filters to exactly how you want them. You can select 'Manage Filters' from those available, or under Administration -> Customization -> Low Level Objects -> Actions -> Filters, you will see a list of all filters for all views and you will even be able to fine tune the search domain that the filter uses.

At the time of writing there are a few pit falls to watch out for. When it comes to editing your filters it may just be easier to create a new one from scratch. The reason for this is that when you use a filter as well as other search parameters, when it comes to saving the filter it will save the two search conditions to the same filter, rather than exchanging the existing search condition. You may end up with much fewer results than you would expect, and might not even get any at all! Also, the hint text for the filter suggests that if a filter is not assigned to a user (by making it 'False'), it will be viewable by all users; currently this is not the case does not currently work but should be resolved in the next release.

All tips in this blog can be found in the Tip Category. Should you need further Support for Linux, you've come to the right place at credativ.

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

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.

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.

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:

1. Shared storage like iSCSI or Fibre Channel.
2. For each node a method to detach it from the cluster (fencing), either by network or by a controllable power switch.
3. At least two nodes with a network connection.
4. 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.

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:

1. The package open-ssh must be installed and be the newest version.
2. Each node's sshd_config file has to be the same as the one saved on the master.
3. In the event that the sshd_config is changed on any node, the sshd service should be restarted.
4. 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 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.

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 <mhlavink@redhat.com> - 1.0.7-7

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).