Posts Tagged ‘horde’

9. August 2013

by

In: horde, OpenSUSE, Tech

Kommentare deaktiviert

Michael Slusarz of Horde LLC started a crowdfunding experiment: He offered a 3000 $ project at crowdtilt.com to back up development of the IMP multi-account feature. Multi-Account support allows users to manage multiple mail boxes within one horde account. The feature is meant to replace Horde 3’s fetchmail feature which has not been ported for Horde 4 and 5 because technically, it’s not desirable anymore.

Michael Slusarz: The old fetchmail functionality is not coming back. It simply doesn’t work coherently/properly in a PHP environment with limited process times (and is non-threaded).
The replacement MUST be the ability to access multiple accounts within a single session. But this is not a trivial change

After Slusarz started the fundraising campaign, long-time supporters and users of horde contributed funds.

Currently, after three days, more that 80% of funding have been raised. About 500 US $ are still missing. The change is not trivial and probably going into IMP 6.2 for Horde 5.

As mentioned previously, this is a multi-week project, at least from a project planning perspective. And that doesn’t include the bug-fixing that is likely to be significant, given the fact that this is 1) an invasive UI change and 2) is involving connections to remote servers.

That being said – this is something I personally would *really* like to see in IMP also, so I am willing to provide a discount and prioritize this over some other activities I am currently involved in.
[..]
* This won’t be available for IMP 6.1. This will go into 6.2, at the earliest.

The Horde IMP Webmailer is among the most popular webmail applications in the world. It is shipped with most widespread linux distributions like openSUSE and Debian and has been used to drive webmail and groupware applications for large-scale userbases all over the world.

Currently, Horde 5 / IMP 6 is integrated into the cpanel administration product.

Update: After roughly a week, by 2013-08-14 the crowdfunding tilted: 3090 USD had been contributed.

http://lists.horde.org/archives/imp/Week-of-Mon-20130812/055265.html

http://lists.horde.org/archives/imp/Week-of-Mon-20130812/055265.html
I proudly get to make the announcement that the IMP Multiple Accounts
feature has been fully funded, as we reached the funding goal on
Crowdtilt this afternoon: http://tilt.tc/Evs2

I wanted to take the opportunity to thank all of the contributors:

– Simon Wilson
– Luis Felipe Marzagao
– Ralf Lang
– Digicolo.net srl
– Elbia Hosting
– Thomas Jarosch
– Andrew Dorman
– Henning Retzgen
– Michael Cramer
– Harvey Braun
– SAPO/Portugal Telecom
– Matthias Bitterlich
– Allan Girvan
– Bill Abrams
– Markus Wolff
– CAIXALMASSORA (Jose Guzman Feliu Vivas)
– Wolf Maschinenbau AG (Samuel Wolf)

It feels good to put a definite milestone into the enhancement ticket:

http://bugs.horde.org/ticket/8077

Should be able to start on this soon… hopefully tomorrow. Still
undecided on which branch I’m going to do development in but I will
post information to the dev@ list once I decide. Those that
contributed may get status updates.

Once again, thanks to everyone for supporting the Horde Project. Not
only was this an interesting experience from my standpoint (hopefully
others as well), but now we will soon get a feature that is obviously
desired by a large portion of the user base.

michael

30. Juli 2013

by

In: horde, Tech

2 comments

The passwd app is a password management/changing utility for Horde which normally lives in a menu “my account” in the toolbar.

While it has been released and is in production use at many sites, it is also under development to expand and improve the module.

Passwd provides fairly complete support for changing passwords via Poppassd, LDAP, Unix expect scripts, SMB/CIFS (under unix), Kolab, ADSI, Pine, Serv-U FTP, VMailMgr, vpopmail, SQL passwords and other more complicated setups.For a certain horde 5 installation, I needed to move the passwd app under the gearwheel/settings menu and out of the toolbar. After setting up passwd to work correctly, I added only one line to the registry.local.php file:

<?php
$this->applications['passwd']['menu_parent'] = 'settings';
?>

Everything you put into the menu labelled “settings” automatically appears in the gearwheel menu.

10. Juli 2012

by

In: horde, Tech

Kommentare deaktiviert

All’s well that ends well. During the last few days, the first alpha releases of the Horde Framework and some of its core apps hit the announcement list. Horde 5 sports a completely revamped user interface which allows a much tighter integration of the portal dashboard, ajax mode applications like the IMP Webmailer or traditional mode applications (whups ticketing etc).

Horde 5 has a completely renewed user interface (Image shows the IMP 6 webmailer)

While IMP, turba and the Ingo Mailfilter are already available as alpha packages, the calendar (kronolith) is not yet done.

However, today Horde release the first alpha version of the sesha inventory app. I have been working on sesha and related packages since horde 4, but things dragged on.

Sesha allows to organize any kind of items in a searchable inventory. First you have to define properties like age, weight, length or location of an item.

A defined group of properties makes up a category, something like an inventory type: Books, DVDs, network interfaces or computer monitors all have very different sets of properties. With sesha, there is no limit on the things you can put into your catalog. Just create categories of properties and finally add stock.

Sesha has been released under the GNU General Public License and may be used free of charge.

10. Mai 2012

by

In: Allgemein, horde, OpenSUSE, Tech

4 comments

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

22. Februar 2012

by

In: horde, OpenSUSE, Tech

Kommentare deaktiviert

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.

22. Februar 2012

by

In: horde, Tech

Kommentare deaktiviert

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.

18. Februar 2012

by

In: Allgemein, horde, Tech

Kommentare deaktiviert

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 Appname_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:totallysecretrpcuserpass
adminuser:adminpass
localdebuguser:secretlocaldebugpass

We also want to get rid of any components which cannot work without an sql backend

$conf['log']['priority'] = 'DEBUG';
$conf['log']['ident'] = 'HORDE';
$conf['log']['name'] = LOG_USER;
$conf['log']['type'] = 'syslog';
$conf['log']['enabled'] = true;
$conf['log_accesskeys'] = false;

As the worker will probably only show the admin UI to localhost or VPN, you want to log any debug relevant data locally into a file
$conf['prefs']['driver'] = 'Session';
$conf['alarms']['driver'] = false;

We don’t want user prefs or alarms on the worker. You might consider setting up some basic email delivery and sending alarms by mail. I won’t cover this here.

$conf['datatree']['driver'] = 'null';
$conf['group']['driver'] = 'Mock';

Datatree support is sql-only. Datatree is mostly legacy support and it isn't particularly fast either. There is no guarantee future horde revisions will support datatree. You don't want it. Period. You don't want groups either. The primary user of your instance is the RPC user.
$conf['perms']['driver'] = 'Null'

Only the master speaks to your worker and this must be ensured on the ssl/https layer. No need for a perms backend

$conf['cache']['driver'] = 'File';

If we use caching at all, we want to use a primitive one.

$conf['lock']['driver'] = 'Null';
$conf['token']['driver'] = 'Null';

Horde_Locks is a cool library. Ben Klang wrote it in 2008 when I was working in a non-public project that needed it and I mailed some stuff to him. But it’s sql-only. We don’t want it here.
Horde_Tokens are essential for a lot of verification tasks but the worker is not the single source of truth.

$conf['vfs']['type'] = 'File';

You probably don’t want a vfs at all. Vfs means state.

$conf['sessionhandler']['type'] = 'Builtin';

Anything but sql. You probably don’t want sessions.

This should be the key parts to make your stock horde installation not want a database at all.

The RPC Worker app.

The key to your RPC worker app is Api.php

This is the entry point for any Horde RPC calls.

Basically it works this way:

  • The upper layer of array() is internal to the horde rpc request layer
  • In our client example we wrapped our params into an additional array() to facilitate optional parameters. This means any method in Api.php accepts an array as the single parameter. You could also use a fixed list of parameters with optionals in the rear positions.
  • While the horde registry calls applications apis as ‘domain/function’, the rpc api calls them as domain.function. Examples are horde.listApis and myvpnapp.fetchData

Any function  you can call from the outside is a method in Fooworkername_Api in Fooworkername/lib/Api.php.

Concurrency and queueing:

Horde is written in PHP. PHP is generally lacking in thread safety and doesn’t support real forking from within an apache module. You can however fork and detach processes using shell_exec. Horde ships some classes which help you use PHP in a shell environment but sometimes you want to resort to shell scripts or perl or anything else because it already exists or is more suitable to the job. shell_exec allows you use all of these. Usually you want your api calls to return fast. This doesn’t scale well. Make sure your individual call usually finishes in predictable worst case scenarios in 1/3 of the client’s response timeout. In our example we chose 20 seconds for timeout. Mind network latency and external script worst case runtime.

The solution here is decoupling:

  • Don’t make any UI element depend on live data from the worker
  • make a service/daemon or cron job collect worker state at short intervals and serialize these data points in time stamped files or directories
  • Create an api entry point to collect most recent state/results
  • Collect results of all workers from a commandline script, daemon, cron job or service in reasonable sequences.
  • Don’t expect most tasks immediately but add them to a queue. Horde_Queue may help you with that task.

Choose wisely where to call existing external apps and where to resort to PHP and the Horde Framework to solve common data collection, processing, formatting and returning tasks.

Remember to have fun.

The author is severly biased towards all things horde and has used horde classes and applications to solve various work-for-hire problems. The Horde Framework is one of the oldest and mature php projects and drives mission critical collaboration and data retrieval software all over the globe.

30. August 2011

by

In: horde, OpenSUSE, Tech

Kommentare deaktiviert

As you might know, the horde project does not only release a set of production quality software (and an interesting bunch more which are not yet release quality) but also provides over 80 well-designed loosely coupled libraries which help you build websites, business applications or even commandline tools. To stress that point, the Horde Project now put a link to the list of components right on their frontpage. Use Horde_Rdo, a lightweight ORM layer or use the RFC-compliant Imap_Client library which performs equally or even better compared to PHP’s interpreter extension written in c. Horde_Auth, a versatile and pluggable authentication layer, has recently been featured in a series of blog posts by lead developer Jan Schneider.
Like in Symfony or Zend Framework, Components are released along with a PHPUnit based test suite adapted in the Horde_Test class and can be obtained individually through the Horde Pear Channel.

15. Juni 2011

by

In: Allgemein, horde, Tech

Kommentare deaktiviert

Jan Schneider just posted a damn cool use case for the Horde_Service_Twitter library. Using this library, just a few lines of php code are enough to send messages to your twitter stream like this:

#!/usr/bin/env php
<!--?php
/* Keys - these are obtained when registering for the service */
$keys = array(
'consumer_key'        => '',
'consumer_secret'     => '',
'access_token'        => '',
'access_token_secret' => ''
);

/* Enable autoloading. */
require 'Horde/Autoloader/Default.php';

/* Create the Twitter client */
$twitter = Horde_Service_Twitter::create(array('oauth' => $keys));

/* Send tweet */
try {
$twitter->statuses->update($argv[1]);
} catch (Horde_Service_Twitter_Exception $e) {
$error = Horde_Serialize::unserialize($e->getMessage(), Horde_Serialize::JSON);
echo "$error->error\n";
exit(1);
}

Now that’s neat, isn’t it.
In another team I worked with, we used a perl library which sent jabber/xmpp streams to our chat accounts when something ran into an uncought exception.

This might be worth porting to PHP/Horde some day.

15. Juni 2011

by

In: Allgemein, horde, Tech

Kommentare deaktiviert

Traditionally, Horde only knows two kinds of users: Users with administration flag and users without. The list of admins is a static entry in the horde config file. It’s all or nothing – either a user gets access to all admin functions or to none. At least until recently.

Last October I wrote about a patch for Horde 3 which allows permission-based access to individual admin privileges. This patch has now been ported to Horde 4 and is incorporated in Horde 4.0.6. You can now assign a user the task of managing groups without allowing him to use the permissions admin and grant himself additional privileges. Or you can delegate emergency password resets to a group of trusted people without confusing them with icons like the PHP Shell. Only those admin functions are shown which the user has access to. Another side effect: Even if a user has all admin permissions, he is still not recognised as an admin and won’t be shown things that admins always have to see regardless of their permissions and settings.

In theory, you can now give yourself all admin permissions and safely delete yourself out of the admin list – as long as you have the “configuration” permission, you can always go back and restore without manually editing the conf.php file.

The Administration permissions are handled in the permissions screen just like any other user permissions. They live under the “horde” component. Currently only the “show” flag is actually recognized but this will be expanded later.

1. Juni 2011

by

In: Allgemein, horde, Tech

Kommentare deaktiviert

There have been some migrations of Horde 3 to Horde 4 recently – not all went smooth from the start.

Some top issues of messing things up and how to avoid it:

  1. initial application dimpIn Horde 3 dimp was a separate application which provided an ajax interface to imp. It has since been merged into the imp application. If your Horde installation had dimp before migration to Horde 4, this might create runtime issues for your users when
    • when you locked the initial application to dimp
    • when your users decided that their initial application should be dimp

    To get around this you should

    • make sure you didn’t blindly copy your locked settings from horde 3 to horde 4
    • run a mysql update statement on the horde_prefs table to update column pref_value to “imp” if it was “dimp” before (Consider hiring a professional admin for the migration if you don’t know how that looks like)
  2. Making changes in backends.php or prefs.php
    In Horde 3 admins used to edit prefs.php or backends.php/servers.php to change values. Horde 4 ships backends.php and prefs.php as default values. Admins are supposed to copy these to backends.local.php and prefs.local.php and make their changes there. Changes to the original files will be overridden with the next rpm or pear update of the horde apps.
  3. Not unchecking utc time in kronolith
    The Horde 3 Calendaring app defaulted to store calendar events in local user time. The Horde 4 default is UTC timestamps. If you migrate from horde 3 you either have to uncheck that setting or run a migration script on the data.
    Warning: You might end up with an unrecoverable state if you add new data in UTC mode to a calendar backend which has not been converted to UTC timestamps
  4. Not converting turba and kronolith databases to utf8
    In Horde 3 installations, the calendar app kronolith and the addressbook turba often had their database tables encoded in latin1. The system wide default in Horde 4 is utf8. Not adapting this setting to the tables or the tables to this setting results in corrupted display of international characters and symbols.
    Warning: You might end up with an unrecoverable state if you add new data to addressbooks or calendars where backend encoding does not match the set horde encoding
  5. Relying on menu.php’s javascript onclick handler or target attribute
    In the ajax views of kronolith and imp there is currently no support for the target and onclick handler attributes. I do not know of any plans to re-add this support. If you want to link external sites into the iframe, consider creating a custom portal block. There was a recent blog post on creating this kind of blocks on The Upstairs Room
  6. Using the ldap prefs backend
    The ldap backend for preferences is currently not yet ported to horde 4. If you want to migrate, you first have to extract your prefs from ldap and then convert them to sql. If you need ldap prefs, consider hiring a consultant or sponsoring the development of this feature.

26. Mai 2011

by

In: Allgemein, horde, OpenSUSE, Tech

3 comments

Today I submit-requested the Horde 4 Application Framework and the stable apps for openSUSE Factory.
This is becoming openSUSE 12.1 if the packages get accepted on time. They are currently in review.

openSUSE Legal team wants to review all packages’ licensing – I’m sure that’s NOT the fun part of their job.

If everything works fine, openSUSE 12.1 will be the first distribution to feature horde 4 in their mainstream repositories.

// read more >

18. Mai 2011

by

In: Allgemein, horde, Tech

Kommentare deaktiviert

Since the release of Horde 4 and select applications, people kept asking for a new release of the popular Horde Groupware and Horde Groupware Webmail Edition bundles.

Horde is now about to release such a bundle, which features new ajax frontends for calendaring, tasks and improved mobile frontend for mail.

The new bundles will be released as pear collections. Gone are the tarballs.

9. März 2011

by

In: horde, OpenSUSE, Tech

Kommentare deaktiviert

Yesterday the horde project released alpha versions of Horde Framework 4 and the Groupware apps (Notes, Calendar, Email, Filter,Address Book, Tasks)

I did a test drive and they basically work. IMP has been improved a lot and now integrates the mobile and ajax interface versions which came as separate apps in Horde 3. DIMP (Ajax version) now plays more nicely together with classic non-Ajax horde applications.

I will begin distribution packaging for SUSE Linux around the official release on April 05, 2011.

See also:

2. März 2011

by

In: horde, Tech

3 comments

Gunnar Wrobel today announced the new monthly horde newsletter:

Last month the Horde project sent out a first newsletter:

http://eepurl.com/ct4tP

The letter is meant to be sent monthly and summarizes progress and
plans concerning the Horde project.

You can subscribe to the newletter here:

http://horde.us2.list-manage.com

Of course, following this blog is an option, too ;-)