I’m here in the belly of the Geeko at SUSE’s offices in Nuremberg, due to the fact that the new openSUSE Board had their Face to Face meeting yesterday (whole different topic needing its own post ;-) ). As I was coming here I thought it would be prudent to try and get the various people dealing with and interested in the ARM port around a table at some point to discus the status of things.

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.

Decided I am too anti-social for it.

Just on the off chance that anyone has tried to browse to my blog or any other part of my web presence on the wafaa.eu domain, you may have noticed that it was returning either with no content or pile of garbled mess. Well the reason is I decided to do a bit of a tidy up. I’ve finally migrated completely to my Microserver, and have retired my old but trusty Compaq Evo.

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

All of you probably know YaST, the installation and system configuration tool for openSUSE.

With current YaST, plenty of tasks that system administrator could image are doable using understandable UI: creating users, bootloader configuration, network setup and even Apache configuration. However, it has its drabacks. While being do-it-all tool, it comes with large package dependency even for only simple tasks. It is largely written in an outdated language which has its roots in last century and only few people in the world know it. It lacks the testing abilities of modern languages. It is SUSE specific and lacks larger developer community.

So last year, we (actually, Josef) came with the idea for YaST++: new configuration library that could be a common layer for configuration tools in SUSE (and beyond). Such library should provide simple and understandable API for all tools around. Written in up-to-date language many people know and like, so they can join the development (spoiler: we chose Ruby). Offering bindings  to various other languages, so different tools could benefit from it,

Now, this “YaST++” does not actually mean to be replacement of current YaST (with its Qt/GTK/ncurses UI), but it could replace the lower layer of YaST, which is doing the real system configuration. And it would be open for other library users as well: the obvious targets for now are WebYaST and SUSE Studio, but we’d like to see if other tools are interested: even from non-SUSE world.

From architecture point, YaST++ is itself divided into two layers, we call them YLib and config agents. YLib is the high-level library, providing the API (like ‘create user’, ‘set new time zone’ etc.). Config agents form the lower layer, that is actually touching the system. This low level consits of D-BUS services, which are running as a root (thus have the full access to the system) but are started only for users with proper permissions (we are using polkit for policies definition). So YaST++ offers role based access management, where specific users can be allowed to do specific sets of actions. For more, check our architecture document (still WIP).

We’ve started to work on several modules (none of them is finished, though). Let’s look at example in module for users configuration (packages yast++lib-users and config_agent-passwd). Look at example code in ‘users_read’ script of examples subdirectory. With simple ruby call of

YLib::Users::read({})

you get the list of current users. If the script gets additional parameters, it can list e.g. all data about selected user, or only specific information about all:

> ./users_read root
{“gid”=>”0”, “name”=>”root”, “uid”=>”0”, “shell”=>”/bin/bash”, “password”=>”x”, “home”=>”/root”}

> ./users_read only name
{“result”=>[“Batch jobs daemon”, “User for Avahi”, “bin”, “Daemon”, “dnsmasq”, “FTP account”, “Games account”, “User for haldaemon”, “User for OpenLDAP”, “LightDM daemon”, “Printing daemon”, “Mailer daemon”, “Manual pages viewer”, “User for D-Bus”, “MySQL database admin”, “News system”, “user for nginx”, “nobody”, “NTP daemon”, “User for build service backend”, “openslp daemon”, “PolicyKit”, “Postfix Daemon”, “PulseAudio daemon”, “qemu user”, “Router ADVertisement Daemon for”, “root”, “RealtimeKit”, “Smart Card Reader”, “user for smolt”, “SSH daemon”, “NFS statd daemon”, “Novell Customer Center User”, “TFTP account”, “usbmuxd daemon”, “Unix-to-Unix CoPy system”, “WWW daemon apache”, “User for YaST-Webservice”, “LXDE Display Manager daemon”]}

YaST++ developement is in its early stage (even the name is not final), but we already have something to offer.

Check the code and documentation at github project. There’s already a simple tutorial for those who want to try writing new parts.

Download packages from Build Service project.

Comment/propose/oppose in public YaST mailing list.