To get an idea on how Horde 5 will look like: click the link or the image of this post.

Why does Horde 5 get a face lift? Simply because the current UI was mentioned often enough as an issue by many Horde users. And since the Horde 4 release had a very technical focus the switch from Horde 3 to Horde 4 last year did not help - it even degraded consistency between the applications. At the same time the competition does not sleep and there are more and more large installations that offer their user base two different webmails - one of them being Horde for the power users that feel they need a lot of features but that care less about the UI. Time to get our act together.

So what is the primary target of the redesign? First and foremost we want to unify the main user interfaces. At the moment we have the static application views, the dynamic webmailer, and the dynamic calender as the core parts. All looked somewhat different. These are the elements that we wish to give a consistent look. The special views such as the minimal webmailer or the smartphone UI will remain untouched.

We also hope the new design looks somewhat fresher than what we had before but please keep in mind that we are oriented towards people that use the interface for their daily work. We do not aim for a UI that looks like the last hype. It should be functional instead.

The Horde LLC has been the driving factor behind the redesign. At least financially. A subset of the Horde core developers started the LLC a while back as a contact point for people that want to pay for Horde support or feature development. A part of the money that such contracts pay goes to the developers dealing with the particular customer request. But another part of the money remains within the LLC. The idea is to use the latter to drive features that we consider to be important for Horde and its community. The redesign is the first project that has been financed this way. The Horde team tried finding designers interested in contributing to an Open Source project several times before. This was unsuccessful however and paying a designer for the work remained the only reasonable alternative.

We contracted No agency for the design. After several rounds of communication between them and all Horde developers we managed to end up with the draft displayed above. This has been converted to html and CSS this week and will be hammered into code during the next week by Jan Schneider. We do hope to present you with an alpha of Horde 5 - including the draft of the new design - on the 22nd May of 2012.

Feedback and comments - as usual - are welcome!

Dear folks, I am very pleased to announce:
The Sesha Inventory application is ready for Horde 5 and it is in good shape. Sesha is a simple inventory keeping application which originally developed by Bo Daley and Andrew Coleman on Horde 3. The product was never officially released but it went into production at several sites. Sesha release cycle can now start together with the Horde 5 Alpha release cycle.

Sesha inventory can be configured to hold any number of stock categories with any number and type of attributes.
Like the original version, Sesha for Horde 5 can provide its stock categories as ticket queues for the horde ticketing application whups.
There are a lot of plans and ideas for upcoming versions but for this time the focus was on finishing a releasable product.There are no surprises for existing users of Horde 3 based sesha. Most work happened invisibly under the hood:

• The Horde_Template library was exchanged by new Horde_View code
• A migration script for database was added
• Users can keep their original Horde 3 Sesha tables and data.
• The sql backend driver was completely reworked into a driver based on the Horde_Rdo ORM library The new Driver Api provides enhanced search capabilities but the current frontend doesn’t make use of it. I do not plan to add any features to the classic view but start working on an Ajax view once the Horde 5 Redesign is completed. This may ship with Sesha 1.1 later on.
• Object oriented code has replaced complicated hashes in many places

The Horde Rdo library is the new work horse inside Sesha. Rdo means Rampage Data Objects and is a lightweight ORM layer by Horde founder Chuck Hagenbuch. It maps database tables to PHP Objects. This is similar to the ActiveRecord pattern. Each database row can be turned into one Rdo item. For Sesha and another – non-public – software project, some enhancements went into the Rdo library for Horde 5:

• Rdo now provides a caching factory or root object which speeds up creation of mapper objects
• Methods for add, removing or checking many-to-many relations have been added
• A number of edge case bugs have been fixed

I think the Horde 5 release cycle will start with alpha1 releases sometime in May. I know we’re a little late but it’s worth the wait.
That said, I welcome any early testing or updates of the language files. Provided everything works as expected, Sesha will be shipped with Horde 5 for OpenSUSE 12.2

Here at CeBIT we support our friendly neighbor project with a constant and vital support of gummy bears. As anyone knows these sweet animals can make the difference between one line of brilliant code and a dreadful spaghetti mess. Thus it is probably hard to deny that this fruitful collaboration turned Horde into one of the biggest KDE sponsors.

That being said: KDE, I'm already here, breakfast is ready ;)

Beside having fun in the open source area the second day was already packed with people here at CeBIT. We had plenty of Horde users which provided kind feedback. Some of them we could surprise with features they didn't know about. Others were happy to hear that "GPL" really means that they can use the software and modify it without being harassed with a lawsuit afterwards.

We had Horde newbies as well as free software newbies. Explaining how free software can result in a revenue was the easy part. Explaining why we have no strong interest in a product for obfuscating our code so that there is a decent protection against people trying to find security holes was ... sigh ... harder.

The most fascinating thing was a company that installed Horde and wants to run it from -25°C to 65°C - like putting Horde to the extreme. There were other extremes involved and I omit the details but it is always fascinating what people do with free software.

Wonderful start at CeBIT yesterday. Meeting people with an interest in Horde face-to-face is a refreshing alternative to the work behind the screen at home or at work. The positive feedback helps tremendously in building up energy.

The most important part yesterday was talking to well known contacts, chatting about the progress of some projects which will hopefully result in a few interesting feature additions to Horde during this year.

I also visited ownCloud at their Univention booth to chat a bit about integrating the tool with a webmailer.

And last but not least it is always fun seeing Jan in person. Nothing against having a "distributed" type of project with people scattered in Germany and US. But it would be so much fun having all of you guys here. Can't really wait for the next hackathon ;)

When installing horde to a custom pear location, you need to run the pear of your custom location, not the system pear with the custom location’s config.

So the steps would be:

1  mkdir /srv/horde
2  pear config-create /srv/horde/ /srv/horde/pear.conf
3  pear -c /srv/horde/pear.conf install PEAR

as the install docs say but then:

4 /srv/horde/pear/pear -c /srv/horde/pear.conf channel-discover pear.horde.org
5 /srv/horde/pear/pear -c /srv/horde/pear.conf run-scripts horde/Horde_Role
6 /srv/horde/pear/pear -c /srv/horde/pear.conf install --alldeps horde/groupware

Otherwise running the Horde_Role script will fail saying

config-set (horde_dir, /srv/horde/, user) failed, channel pear.php.net

This was experienced on SLES11SP1, SLES11SP2 and openSUSE Factory.

I did not test this for any debian based products yet.

When we discovered the successful attack on ftp.horde.org two weeks ago we were of course frantic to determine which packages had been affected in addition to the one Horde 3 archive Jan identified as modified initially.

For the Horde 4 packages we had no hashes to verify the file integrity though. While PEAR supports signing of packages via GPG that seems to be a feature which is virtually unused. For one thing not that many PHP based projects use PEAR packaging and in addition there is no way to automatically verify package integrity on the user side when installing via PEAR. So we also didn't consider signing our packages when switching to installing Horde via PEAR.

Obviously you gain a different perspective on that issue once a hacker implanted a backdoor in some of your packages. Of course we invested a lot of time into securing our infrastructure now to ensure that such an event never happens again. On our side the file integrity is constantly monitored now. But we will also have to investigate how we can improve the PEAR based installation procedure so that it also allows for the required amount of security on the user side.

But if we had no hashes how did we ensure the Horde 4 packages were indeed unmodified? Git to the rescue! As we tag all our releases it was a matter of creating a short script to automatically compare the current state of the packages on our PEAR server against the state we had within git.

Without further ado - here is the script I used:

#!/bin/bash

git reset --hard HEAD
git clean -f -d

STAMP=`date +%y%m%d-%H%M`
mkdir ../diffs-$STAMP
mkdir -p ../validate-$STAMP/pear.horde.org
mkdir -p ../validate-$STAMP/rebuild

for package in `cat ../pear-recovery-packages.txt | grep -v ".tar$"`
do
  TAG=${package/.tgz/}
  TAG=${TAG,,}
  PPATH=${package/-*/}
  if [ "x${PPATH/Horde_*/}" == "x" ]; then
      PPATH=framework/${PPATH/Horde_};
  fi
  if [ "x${PPATH/groupware*/}" == "x" ]; then
      PPATH=bundles/$PPATH;
  fi
  if [ "x${PPATH/webmail*/}" == "x" ]; then
      PPATH=bundles/$PPATH;
  fi
  PRESENT=`git tag -l $TAG`
  if [ "x$PRESENT" == "x" ]; then
      echo
      echo "======================================================================"
      echo "Tag $TAG for package $package is missing!"
      echo "======================================================================"
      echo
      echo "$package: TAG MISSING" >> ../status-$STAMP
  else
      rm *.tgz                                                                                                               
      rm -rf ../validate-$STAMP/pear.horde.org/*
      rm -rf ../validate-$STAMP/rebuild/*
      GIT=`git checkout $TAG`
      horde-components -z $PPATH --keep-version
      if [ -e $package ]; then
          cp *.tgz ../validate-$STAMP/pear.horde.org/
          cp ../pear.horde.org/get/$package ../validate-$STAMP/rebuild/
          tar -C ../validate-$STAMP/pear.horde.org/ -x -z -f ../validate-$STAMP/pear.horde.org/*.tgz
          tar -C ../validate-$STAMP/rebuild/ -x -z -f ../validate-$STAMP/rebuild/*.tgz
          DIFF=`diff -Naur ../validate-$STAMP/pear.horde.org/${package/.tgz/} ../validate-$STAMP/rebuild/${package/.tgz/}`
          if [ "x$DIFF" != "x" ]; then
              echo
              echo "======================================================================"
              echo "Diff for package $package detected!"
              diff -Naur ../validate-$STAMP/pear.horde.org/${package/.tgz/} ../validate-$STAMP/rebuild/${package/.tgz/} > ..$
              echo "======================================================================"
              echo
              echo "$package: DIFF" >> ../status-$STAMP
          else
              echo
              echo "======================================================================"
              echo "$package CLEAN!!!"
              echo "======================================================================"
              echo
              echo "$package: CLEAN" >> ../status-$STAMP
          fi
      else
          echo
          echo "======================================================================"
          echo "Failed rebuilding package $package!"
          echo "======================================================================"
          echo
          echo "$package: FAILED REBUILDING" >> ../status-$STAMP
      fi
  fi
done

The script walks through the list of packages we had on the PEAR
server, moves back in time within ou

Truncated by Planet Horde, read more at the original (another 1668 bytes)

The spring 2012 release of the Horde Application Suite and Framework will probably be called Horde 5. In a recent discussion the majority of developers agreed on a new major revision for some changes that some view as minor backward compatibility break. Currently planned features include:

• New standard UI for “traditional view”
• Move of Ajax code from specific apps to a common framework
• Release of a small inventory management app (sesha)
• complete configuration via UI (likely)
• Webmail: Write support for smartphone view
• Calendar: Resource calendar support for ajax view

At the same time, Horde 3 will no longer receive any support. Horde 3 has been around since 2005 and really has reached its end of life.

Since the Horde 4 release, The Horde 3 family of applications has only received critical bugfixes and security updates, the last being released this february. You should really consider updating to Horde 4 – the transition from Horde 3 to Horde 4 has been tested and done by numerous people and the transition from Horde 4 to Horde 5 should run smoothly as both releases are PEAR based.

I have already removed all things horde3 from OpenSUSE-Factory. OpenSUSE 12.2 will not ship Horde 3 any longer. Depending on packaging progress, openSUSE 12.2 will very likely ship Horde 5 or the most recent Horde 4 release. Horde 4 maintainence will continue.

Horde 3 Packages in the server:php:applications repository (see here) will be available at least until openSUSE 12.1 runs out of maintainence. I won’t give these much attention though. Please also note Eleusis Password Manager will be dropped with currently no planned replacement.

Horde provides system wide customisation and configuration of applications through php configuration files. These files can be edited by hand or written from an administrator config UI. This ui is automatically generated from a file called conf.xml located in your $application/config/ directory.

The config xml allows dropdowns, multiselect fields, tick boxes, radio buttons and even conditionally adding or removing a field or inserting a valid php expression.

For example a  dropdown box in the horde base application’s config is generated by this snippet:

<configenum name="use_ssl" quote="false" desc="Determines how we generate
  full URLs (for location headers and such).">2
   <values>
    <value desc="Assume that we are not using SSL and never generate https
    URLs.">0</value>
    <value desc="Assume that we are using SSL and always generate https
    URLs.">1</value>
    <value desc="Attempt to auto-detect, and generate URLs
    appropriately">2</value>
    <value desc="Assume that we are not using SSL and generate https URLs only
    for login.">3</value>
   </values>
  </configenum>

This is all nice but what if you need to provide application data rather than static values? The answer is configspecial

<values>
    <configspecial application="turba" name="sources" />
</values>

How does that work?

<configspecial> calls the horde api. the “application” part tells you which application’s api to call. You can either reference an application by its registry name (horde, imp, kronolith, turba…) or by its api name (horde,mail, calendar, addressbook)

What’s the difference? When you call turba, you get turba. When you call addressbook, you can hook into whatever application provides addressbook. For example, spam handling and ticket queues have been implemented by multiple applications. You can even implement your own handlers for any existing api.

The called application must have a method configSpecialValues() in its lib/Application.php class file. This method gets called and its only parameter is the “name” property from the xml. In our example it’s “sources”. This method will return an array of source names to use in your config screen.

    /**
     * Returns values for <configspecial> configuration settings.
     *
     * @param string $what  The configuration setting to return.
     *
     * @return array  The values for the requested configuration setting.
     */

    public function configSpecialValues($what)
    {
        switch ($what) {
        case sources:
            try {
                $addressbooks = Turba::getAddressBooks(Horde_Perms::READ);
            } catch (Horde_Exception $e) {
                return array();
            }
            foreach ($addressbooks as &$addressbook) {
                $addressbook = $addressbook['title'];
            }

            $addressbooks[''] = _("None");
            return $addressbooks;
        }
    }

Et voila – you have a list of addressbooks to choose from.

Synopsis

Horde’s powerful RPC API has been used numerous times to allow integration of horde-based data into external applications or remote sites. It also provides an easy to set up basis for distributed applications with headless workers. In this article I will give you a brief introduction on how to build a scalable distributed architecture based on Horde 4.

Distributed Architecture

Assumptions:

•  You want your application to be scalable over several hosts. We call the controlling instance the master and the reacting instances the workers.
•  You don’t want to keep a lot of state on the worker. Adding or removing a worker instance should not require complicated setup. Most cloud layers like OpenStack assume worker instances to be virtually stateless. The master is the single source of truth and should be able to rebuild any broken or lost worker setup from stored information.
• You are working in a hostile environment, e.g. the internet. Firewall only allows select ports and data has to travel over lines you cannot trust. You want to resort to https transport with real certificates.

The master:

I won’t go into too many  details on the master setup this time. Create a basic app from the skeleton as the horde wiki describes. Separate a communication driver for worker Api calls from the driving logic in your app and don’t couple them too tightly. Usually you want small commits of changes to both the master’s idea and the worker’s reality and you want to check back if everything worked out. This doesn’t scale well on large-scale changes though.

Sometimes you want to make complex changes to the “truth” or “theory” in the master’s db before you commit them to the worker world out there.

Accessing the worker from the master:

The core piece of your communication with the worker are just a few lines of code

   protected function callWorker(WorkerInstance $worker, $callMethod, array $parameters = array()) {

       try {
            $http = new Horde_Http_Client(array('request.username' => $worker->rpcuser, 'request.password' => $worker->rpcuserpass, 'request.timeout' => 20 ));
            $response = Horde_Rpc::request(
                    'xmlrpc',
                    'https://' . $worker->worker_hostname . '/' . $worker->worker_subdir .'/rpc.php',
                    $callMethod,
                    $http,
                    array($parameters)
            );
        }
        catch (Exception $e) {
            throw new Insysgui_Exception($e);
        }
        return $response;
    }

This is a dumbed down version for demonstration purposes. You might want to model WorkerInstance based on Horde_Rdo, the horde ORM layer. It is desirable to evaluate lazy relations and lazy attributes. This has important performance implications but more on this in another post. We’re also selling consulting

Worker setup:

We want a stateless worker instance. Obviously, this is theory. Truth is: You need a unique IP and you probably want a unique hostname. Nowadays cloud layers can provide that level of configuration. How about a horde instance without db?

horde/config/registry.local.php

You want the worker to talk under a specific api name. Add a block to your registry.local.php

 'myvpnworkerworker' => array (
        'name' => _("someworkerfooname"), /* we can even drop the _() as nobody will localize this */
        'provides' => 'myvpnworkerapp',
    )

horde/config/conf.php

This is stripped down to just the important lines

$conf['auth']['params']['htpasswd_file'] = '/not/in/webroot/passwords.secret';
 $conf['auth']['params']['encryption'] = 'plain'; /* In real world, you want to use some encryption instead */
 $conf['auth']['driver'] = 'http'; /* We want authentication by http layer after all */

We want the server to be stateless and not to rely on external data. We don’t want a local mysqld running and we don’t want a remote ldap either. We will store the credentials in a .htpasswd style file. For demonstration purposes, we use plain authentication.

The file would look like this:

passwd.passwd would look like this: 

rpcuser:totall

Truncated by Planet Horde, read more at the original (another 4911 bytes)

It is official now: Horde gets a booth on CeBIT 2012! Sponsored by Linux New Media the company behind the Linux Magazine. Thanks! Simply awesome!

Hope to see you there!

In addition I updated the list of Horde deployments in our Horde wiki. I also added a list of Horde hosting providers and a list of alternate installation methods for Horde. I couldn't refrain from adding a short abstract on why we only offer PEAR with Horde 4 to the latter article.

Of course corrections and additions are very welcome!

I don't know the people I call there. But it is fun, I train my english, and on top they are usually happy about my call.

What we talk about? I explain them what a provider is. And why I'm actually unable to help them. Which maybe helpful information in its own right.

Of course these people called the Horde LLC before. The Horde webmail is running on so many servers around the world that we get a constant stream of requests for help from users that mistake Horde for their service provider. Usually we get a handful of e-mails every day asking whether we could reset the password, restart the server, or in general just "HELP!!!". Once in a week the line

I can't log in. My username is ABC, my password is XYZ.

E-Mails are simple: sending out a friendly response with a link to one of our most successful wiki pages is an easy thing to do.

Phone calls are a different matter though. The phone number for calling us in the US has been set up by MojoLingo based on Adhearsion a while back. And of course we get a certain number of "I can't get my mail!" calls as well. We usually didn't answer these until MojoLingo helped us with setting up Voip access so that calls into the US generate negligible costs.

So I can sit here, run SipDroid on my little droid and call into US when I need a break or have a minute to spare. A few more pleas for help that do not get lost unanswered.

In case you ever get called by a stranger with a weird German accent after your Horde webmail broke you probably didn't read this blog post.