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.

Greetings programs, in today’s post i will present a little issue i had with
an old box i needed to format and reuse:

root@nibelheim:~# mkfs.ext4 /dev/sdxy
mke2fs 1.41..12 (17-May-2010)
/dev/sdxy is apparently in use by the system; will not make a filesystem here!

this one might get triggered by a number of factors:
1. the drive could be mounted on the current system.
2. there are raid array data left marking the drive or partition as “in use”.

Disk /dev/md127: 10.5 GB, 10536091648 bytes
255 heads, 63 sectors/track, 1280 cylinders, total 20578304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/md127 doesn't contain a valid partition table

and here is our ‘little’ problem.

As you can see my case falls under the second “category”, there are some raid data left on the device,
now that we know what the problem is we can proceed with the solution.

root@nibelheim:~# mdadm --remove /dev/md127
root@nibelheim:~# mdadm --stop /dev/md127  
mdadm: stopped /dev/md127

then it was a simple:

root@nibelheim:~# mkfs.ext4 /dev/sdxy

and the driver was ready and formated :)

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.

collectd is a very nice metrics collection daemon for Linux, *BSD and a few other Unix variants. Essentially, what it does is run in the background, record a lot of metrics about the system and store them into RRD, from which you can then visualize time graphs.

There are around 100 plugins, going from low level things such as CPU load, memory usage to application level metrics like MySQL slow queries, Apache access log, memcached, etc..., as well as the ability of writing your own plugins in many languages using a nice, well documented and stable API.

I'm maintaining the latest version of collect for openSUSE in the server:monitoring repository.

Finally finished to upgrade to the latest, 5.0.3 -- please test and report any issues either directly to me by email, or using our bug tracker.

It has been a busy week where I was working on the ownCloud Desktop sync client. As described in my last post this will be based on a csync module to handle ownCloud as well as mirall, a Qt based desktop client to sync.

That involved basically three things: A csync module, a patch in ownCloud and work on mirall.

For csync, there needs to be a module that handles the connection to ownCloud, for code see [1]. ownCloud has a WebDAV interface, and its used for this. Csync requires the the implementation of a couple of POSIX functions such as opendir, readdir, closedir, stat and these kind of things. I did that using WebDAV equivalents.

Unfortunately one method is needed for the sync algorithms which has no equivalent in WebDAV, which is utime. utime sets the modification time of a file. csync needs that to fix the time after a file was copied to the other side.  For that, I made a little patch to ownCloud to allow a PROPPATCH method on the modified time of a resource. That makes csync happy and working, but that also means that the module is not a general csync webdav module but a csync owncloud module. Named it accordingly.

The first action I started on mirall this time is a bit cleanup. First, I introduced a class  to move all the code which loads, edits and monitors the folders out of the main application class, which was long overdue. That separates the sync folder management in mirall from the GUI stuff. Furthermore I added a few helper classes such as a config file class for mirall. Ah yes, a theming class was also added to handle the future two faces character of mirall easily, as said before mirall should either appear as traditional mirall client, or as ownCloud client. Duncan and me agreed to build that from one source, the theming class supports that.

Last but not least I polished the wizard in which a user connects to his ownCloud and added a test call that immediately evaluates the url and credentials. For the curious, the code is in my work repository but I promise to move it to the ownCloud repo on gitorious soon.

So far for now, if you have suggestions for me I’d love to hear them.  Thanks :-)

[1] Klaas’ WIP branch csync