Kolab.org Groupware Solution

Previously, my nightly builds of Kolab have been built and hosted here: https://obs.kolabsys.com/project/show/home:tpokorra:branches:Kolab:Development There were 2 problems recently: I was not able to add builds for CentOS7. The error message is: ... [More] Failed to add project or repository: unable to walk on path 'CentOS:7/standard' Each time there was a new patch or release on Kolab:Development, I needed to manually remove the patch from the nightly package because the patch was already part of git master. I also needed to resolve conflicts in the debian.changelog and package dsc file because the version number changed. UPDATE: since there was an easy fix for Point 1 (just edit the Meta file of the project to add different Operating System), I also realised I could update the OBS packaging instructions the same way as I do for LBS, avoiding conflicts. So we will see if that works over the coming weeks… After some improvements to my LightBuildServer, I am now able to build the nightly packages on my own LBS server. This is done in two steps: Updating the package instructions: This is done by an LBS job, that basically is running this script: The package instructions are downloaded from https://obs.kolabsys.com/project/show/Kolab:Development, and the source tarballs are downloaded from https://git.kolab.org/. Then the changelog is updated, patches removed, some other patches applied… Also some conversion is done on the files to make Debian happy to build them. The result is uploaded to https://github.com/TBits/lbs-kolab-nightly Then I run different jobs on LBS, for each Operating System that I currently support: CentOS6, CentOS7, and Debian, to rebuild the selected packages with nightly tarballs. The result can be viewed here: https://lbs.solidcharity.com/project/tbits.net/kolab-nightly These steps are executed each night, by a cronjob that initiates the builds on the LBS, by calling for example tbitscredentials=tbits.net/secret wget -O /dev/null https://lbs.solidcharity.com/triggerbuildproject/tbits.net/kolab-nightly/centos/6/amd64/$tbitscredentials To test the nightly builds, you can install the nightly repository like this, additionally to the Kolab 3.4 and Kolab Development repo: For CentOS6: yum install yum-utils yum-config-manager --add-repo https://download.solidcharity.com/repos/tbits.net/kolab-nightly/centos/6/lbs-tbits.net-kolab-nightly.repo For CentOS7: yum install yum-utils yum-config-manager --add-repo https://download.solidcharity.com/repos/tbits.net/kolab-nightly/centos/7/lbs-tbits.net-kolab-nightly.repo For Debian Wheezy: apt-get install apt-transport-https echo 'deb https://download.solidcharity.com/repos/tbits.net/kolab-nightly/debian/wheezy/ /' >> /etc/apt/sources.list apt-get update With the LightBuildServer I have full control over the builds, can just modify a config file to add a new target OS (if my LXC scripts support it), and can review the history of the package instructions on Github. Of course, one disadvantage of LBS compared to OBS is: the LightBuildServer is not intended to directly support the work in a team. Team-work happens via Github (or your self hosted Gitlab), and every team member could install his own LightBuildServer. A feature that LBS is still missing is that multiple build containers are just assigned with any job, without checking if one job should wait for another job to finish. A first step would be to distribute the jobs per Operating System to different build containers. Well, still lots of room for improvement…   [Less]

Hello @all, +Kolab.org Community released Version 3.4 and it was time to get the new updates up and running. This time there is a new driver for "chwala" integrated for +Seafile.VN so I gave it a try and tried to mix it all together. After lots pf ... [More] solving dependencies and so on I managed to get the new version up and running with Seafile attached. That's quite amazing, for this you have to configure Seafile through Apache and connect to the LDAP. When you were able to manage all these things, you can easily save attachments in your cloud and syncing them to your smartphone. :-) There are still some issues on my Cubietruck which I have to solve but my Idea is to rebuild all the stuff from scratch in a chroot environment and track down all steps to get it working. Two Screenshots showing the new skin for +Roundcube and the integration of Seafile into Chwala. That's the new Chameleon skin for Roundcube The same folders in seafile and chwala except the password protected one. So the next couple of days I'm trying to set up a new build environment for the ARM-HF packages for Kolab and a Step-By-Step description. Greetz   [Less]

​ With the recently announced Kolab Groupware 3.4 Version a new default skin got introduced: "Chameleon". The new skin (which is still based on larry) provides a very clean layout which is very easy to customize. Thanks to the LESS CSS Compilier you ... [More] basically only need to define a few main colors (I changed 2), compile the style sheets and exchange the skinlogo. Most of the the other colors used within roundcube are based on your main-color (lighten by 30%, etc.). If you don't like some of the colors in the icons, change them too by either changeing the psd files or just edit the png files (which sufficent) and within 10-120 minutes you got your personal kolab skin running. The file structure The roundcube theme is split into 2 componentes. The internal skin parts which consists of templates, configuration files, etc. and the asset part like CSS and images. /usr/share/roundcubemail/skins/<name>/ /usr/share/roundcubemail/public_html/assets/skins/<name>/Let's start Duplicate the existing chameleon skin cd /usr/share/roundcubemail cp -a skins/chameleon skins/mytheme ​cp -a public_html/assets/skins/chameleon public_html/assets/skins/mytheme   Give your theme a name skins/mytheme/meta.json "name": "My Theme",  Set the 2 most important colors (main color + link color) public_html/assets/skins/colors.less @main-color:  #C1D72E; @link-color:  #ADAA38; ​  To compile and minifiy your stylesheets you need the node-less compiler. You can either install nodejs and node-less (version >= 1.8.5) from your favorite repo or just use the version from the kolab repository. lessc public_html/assets/skins/styles.less > public_html/assets/skins/styles.css   Replace the kolab logo (which is used in the upper left corner) with your logo. cp ~/mytheme_logo.png public_html/assets/skins/images/kolab_logo.png   Change the skin in roundcube's configuration /etc/roundcubemail/config.inc.php $config['skin'] = 'mytheme'; ​$config['dont_override'] = array('skin'); Be Happy :-) The optional part (icons) For those who think that the color of the icons doesn't match their new color scheme: Here's a quick walk through on how to quickly change the colors using Gimp. And even me (usually using photoshop and yelling why my keyboard shortcuts don't work) managed to get things done fairly quickly (if you know the basics about layers and blending modes). The majority of icons or images can be broken down into 2 categories: Single-Color Icons with transparent background (example: buttons.png) Single-Color Icons with white background (example: contactpic.png) Example 1 (buttons.png) Open the Image File > Open > buttons.png   For images that have indexed colors switch to RGP mode Image > Mode > RGP   In the "Layers" Panel click on the [Lock alpha channel] to preserve the transparent background.   Grab a pencil with a brushsize of around 10 pixel   Pick your favorite color and start painting over the icons you like to change. Pay attention to not draw over the neighbour icons or parts you don't want to change. For icons like the thread open/close icons we use a different way (see below).   Save the image File > Overwrite buttons.png Example 2 (contactpic.png) Open the Image File > Open > buttons.png   For images that have indexed colors switch to RGP mode Image > Mode > RGP   (Optional) Make a selection on what you want to change (if you only want to change selected icons)   Now change everything black/white Colors > Hue-Saturation > Saturation = -100 Colors > Levels > Click [Auto] The contactpic should have have black borders and a white background.   Create a new transparent layer and change the blending mode to "Lighten Only"   Draw on the empty layer with your favorite color and everything which was black before will be filled with your color. ​   Flatten the image again Layers > Merge Down   Save the image ​File > Overwrite contactpic.png   [Less]

What is the most original birthday present one can give their spouse? Well, how about a release of your favorite collaboration software suite! I'm pleased to announce that Kolab 3.4 is available via our OBS repositories immediately! Please see our ... [More] Installation Guide for instructions on getting you some Kolab on your favorite platform, and if you already have Kolab running, check out the Upgrade Note from Kolab 3.3 to 3.4, kindly contributed for your benefit by Daniel Hoffend. Kolab 3.4 comes with a new skin, called chameleon, that is a nice and clean-cut, modern skin for the web client -- courtesy of Kolab Systems, patron of the Kolab Groupware solution. Two weeks ago, we have had our first release planning meeting on IRC, which has resulted in very fruitful feedback, contributions and most importantly a significant chunk of quality assurance from various participants in the community. A special thanks goes out to Daniel Hoffend and Timotheus Pokorra, who've spent plenty of their spare time on ensuring that Kolab 3.4 is the best it can be right out of the box. One slice of the pie on your right is theirs. We're definitely going to continue to open up more processes, such as, for example, the Kolab 3.5 Roadmap. The Kolab 3.4 release also marks the first release with an actual release party - though naturally many people are not able to attend. We're celebrating the Kolab 3.4 release is probably the best quality assured stable release Kolab.org has yet performed   [Less]

Hello, currently my +Raspberry Pi compiles the packages to the latest version available. (Update from 01.01.2015) In the next couple of weeks I'm going to migrate from +Raspberry Pi  to my new Cubietruck. I decided to upgrade to a new SBC because ... [More] the Cubietruck has more power (2 GB Ram instead of 512MB, ARMv7 instead ARMv6 a.s.o.) For the Cubietruck I decided to go the debootsrap way for a debian image and followed these instructions : http://blog.night-shade.org.uk/2013/12/building-a-pure-debian-armhf-rootfs/ http://blog.night-shade.org.uk/2013/12/create-a-bootable-sd-for-a-cubietruck/ After that I had an amazing fast boot sequence on my "truck". :-)  I had to fix an  issue on my host because the module "binfmt_misc" was not integrated in my kernel which I compiled myself. The main difference beetween Raspberry Pi and the Cubietruck is the CPU. Debian is available for ARMv7 CPUs as "armhf" and for ARMv6 CPUs as "armel" (soft float). The difference is the performance. If you use "armel" on the Raspberry Pi you will loose lots of performance, that's why the guys from Raspbian created their own repository for ARMv6 and "hard float". They compiled nearly every package for the Pi and I did that for the +Kolab packages. The debian-armhf repository does not contain all of the packages which are necessary for the Kolab installation so my "truck" is compiling all the stuff as well. :-) Greetz Andreas   [Less]

I have recently updated my Kolab Groupware install from version 3.2 to version 3.3, there are not a ton of new features but I wanted to see if this would be a huge process or go fairly quickly. First of all, take a backup. Really take a backup. You ... [More] never know what your going to blow up with Kolab updates. Sometime they work great, and they are getting better. Just do it. At the very least backup your IMAP store. If you are like me at all and have your IMAP mounted over NFS, stop the Cyrus service and unmount the IMAP store. Also, I am using CentOS 6 this guide will be based on that, the fixes at the end might apply though if you are not running CentOS 6. Here is what I did, also I will list a few things I did to fix some issues. Backup the server. I use VMWare ESX so I made a snapshot. Stop the Cyrus Server. service cyrus-imapd stop I unmounted the IMAP store since I use NFS. umount /var/spool/imap Follow this guide (I will copy it’s content below, possibly with some differences). https://docs.kolab.org/administrator-guide/upgrading-from-kolab-3.1-to-3.3.html Update your CentOS Installation # cd /etc/yum.repos.d/ # rm Kolab*.repo # wget http://obs.kolabsys.com/repositories/Kolab:/3.3/CentOS_6/Kolab:3.3.repo # wget http://obs.kolabsys.com/repositories/Kolab:/3.3:/Updates/CentOS_6/Kolab:3.3:Updates.repo # yum updateFILE TO EDIT: /etc/kolab/kolab.conf Replace example.org with your LDAP and installation primary domain name. [ldap] sharedfolder_acl_entry_attribute = acl modifytimestamp_format = %Y%m%d%H%M%SZ [kolab_smtp_access_policy] delegate_sender_header = True alias_sender_header = True sender_header = True xsender_header = True cache_uri = <copy and paste mysql uri from the kolab_wap section> [wallace] modules = resources, invitationpolicy, footer kolab_invitation_policy = ACT_ACCEPT_IF_NO_CONFLICT:example.org, ACT_MANUALIf you’re planning to make use of wallace please make sure wallace is enabled to start using chkconfig on RHEL/Centos or /etc/default/wallace on debian. # service kolab-server restart # service wallace restartFILE TO EDIT: /etc/kolab-freebusy/config.ini Instead of editing the configuration by hand it’s easier to just recreate the configuration using the setup-kolab tool. Your choice. This step did not work for me, but I do not use freebusy! # cp /etc/kolab-freebusy/config.ini.rpmnew /etc/kolab-freebusy/config.ini or # setup-kolab freebusyFILE TO EDIT: /etc/roundcubemail/config.inc.php The plugins where correct on my server excepting adding the new ones, kolab_notes and kolab_tags. Change the plugin load order the follwing way: move kolab_auth to the top position move kolab_config after kolab_addressbook add kolab_notes after kolab_folders add kolab_tags after kolab_notes$config['use_secure_urls'] = true; $config['assets_path'] = '/roundcubemail/assets/';FILE TO EDIT: /etc/roundcubemail/password.inc.php Change the password driver from ldap to ldap_simple. $config['password_driver'] = 'ldap_simple';FILE TO EDIT: /etc/roundcubemail/kolab_files.inc.php Update the kolab_files_url to /chwala/ to be protocol independent. This would not work for me, I kept my old setup. $config['kolab_files_url'] = '/chwala/';FILE TO EDIT: /etc/iRony/dav.inc.php The iRony configuration doesn’t have anything special configurations. You might want to consider just to take the new default config file or change it based on the differences between the previous version. For me, nothing changed from 3.2 to 3.3 but you should check. # cp /etc/iRony/dav.inc.php.rpmnew /etc/iRony/dav.inc.phpFILE TO EDIT: /etc/postfix/ldap/virtual_alias_maps_sharedfolders.cf To fix the handling of resource invitations you’ve to adjust your existing virtual alias maps, otherwise you end up with non-delivery-reports. I just had to add the last part. query_filter = (&(|(mail=%s)(alias=%s))(objectclass=kolabsharedfolder)(kolabFolderType=mail)) FILE TO EDIT: /etc/postfix/master.cf This will put wallace as the next content-filter after the mail has been returned from amavis to postfix. If you’re don’t want to make use of iTip processing or resource management you can skip this section. [...] 127.0.0.1:10025 inet n - n - 100 smtpd -o cleanup_service_name=cleanup_internal -o content_filter=smtp-wallace:[127.0.0.1]:10026 -o local_recipient_maps= [...]Restart Postfix # service postfix restartUpdate MySQL Database Connect to MySQL, use the password you use for SQL on that server. # mysql -u root -p -D kolab-- -- Table structure for table `ou_types` -- DROP TABLE IF EXISTS `ou_types`; /*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; CREATE TABLE `ou_types` ( `id` int(11) NOT NULL AUTO_INCREMENT, `key` text NOT NULL, `name` varchar(256) NOT NULL, `description` text NOT NULL, `attributes` longtext NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `name` (`name`) ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1; /*!40101 SET character_set_client = @saved_cs_client */; -- -- Dumping data for table `ou_types` -- LOCK TABLES `ou_types` WRITE; /*!40000 ALTER TABLE `ou_types` DISABLE KEYS */; INSERT INTO `ou_types` VALUES (1,'unit','Standard Organizational Unit','A standard organizational unit definition','{"auto_form_fields":[],"fields":{"objectclass":["top","organizationalunit"]},"form_fields":{"ou":[],"description":[],"aci":{"optional":true,"type":"aci"}}}'); /*!40000 ALTER TABLE `ou_types` ENABLE KEYS */; UNLOCK TABLES; -- -- Table structure for table `sharedfolder_types` -- DROP TABLE IF EXISTS `sharedfolder_types`; /*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; CREATE TABLE `sharedfolder_types` ( `id` int(11) NOT NULL AUTO_INCREMENT, `key` text NOT NULL, `name` varchar(256) NOT NULL, `description` text NOT NULL, `attributes` longtext NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `name` (`name`) ) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=latin1; /*!40101 SET character_set_client = @saved_cs_client */; -- -- Dumping data for table `sharedfolder_types` -- LOCK TABLES `sharedfolder_types` WRITE; /*!40000 ALTER TABLE `sharedfolder_types` DISABLE KEYS */; INSERT INTO `sharedfolder_types` VALUES (1,'addressbook','Shared Address Book','A shared address book','{"auto_form_fields":[],"fields":{"kolabfoldertype":["contact"],"objectclass":["top","kolabsharedfolder"]},"form_fields":{"acl":{"type":"imap_acl","optional":true,"default":"anyone, lrs"},"cn":[]}}'),(2,'calendar','Shared Calendar','A shared calendar','{"auto_form_fields":[],"fields":{"kolabfoldertype":["event"],"objectclass":["top","kolabsharedfolder"]},"form_fields":{"acl":{"type":"imap_acl","optional":true,"default":"anyone, lrs"},"cn":[]}}'),(3,'journal','Shared Journal','A shared journal','{"auto_form_fields":[],"fields":{"kolabfoldertype":["journal"],"objectclass":["top","kolabsharedfolder"]},"form_fields":{"acl":{"type":"imap_acl","optional":true,"default":"anyone, lrs"},"cn":[]}}'),(4,'task','Shared Tasks','A shared tasks folder','{"auto_form_fields":[],"fields":{"kolabfoldertype":["task"],"objectclass":["top","kolabsharedfolder"]},"form_fields":{"acl":{"type":"imap_acl","optional":true,"default":"anyone, lrs"},"cn":[]}}'),(5,'note','Shared Notes','A shared Notes folder','{"auto_form_fields":[],"fields":{"kolabfoldertype":["note"],"objectclass":["top","kolabsharedfolder"]},"form_fields":{"acl":{"type":"imap_acl","optional":true,"default":"anyone, lrs"},"cn":[]}}'),(6,'file','Shared Files','A shared Files folder','{"auto_form_fields":[],"fields":{"kolabfoldertype":["file"],"objectclass":["top","kolabsharedfolder"]},"form_fields":{"acl":{"type":"imap_acl","optional":true,"default":"anyone, lrs"},"cn":[]}}'),(7,'mail','Shared Mail Folder','A shared mail folder','{"auto_form_fields":[],"fields":{"kolabfoldertype":["mail"],"objectclass":["top","kolabsharedfolder","mailrecipient"]},"form_fields":{"acl":{"type":"imap_acl","optional":true,"default":"anyone, lrs"},"cn":[],"alias":{"type":"list","optional":true},"kolabdelegate":{"type":"list","autocomplete":true,"optional":true},"kolaballowsmtprecipient":{"type":"list","optional":true},"kolaballowsmtpsender":{"type":"list","optional":true},"kolabtargetfolder":[],"mail":[]}}'); /*!40000 ALTER TABLE `sharedfolder_types` ENABLE KEYS */; UNLOCK TABLES;Go ahead and restart the server now to load stuff, you don’t really have to I suppose. Stuff I fixed/updated/changed to make stuff work…. The assets will not load, images, css and such on roundcube web interface: Edit /etc/roundcubemail/config.inc.php and change $config['assets_path'] = '/roundcubemail/assets/';to $config['assets_path'] = '/assets/';Still no assets, using SSL? No images and stuff? Let’s check your Apache configuration. I had to add an Include line in the ssl.conf Edit /etc/httpd/conf.d/ssl.conf I just added the Include line below, your setup may be different as some people use a VHOST some use SSL some use mod_ssl (like me) some use other SSL setups. Some people need to include the roundcubemail.conf and some won’t. #SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \ # and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \ # and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \ # and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \ # and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \ # or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9] $/ #</Location> Include conf.d/roundcubemail.conf # SSL Engine Options:Okay, I also use a custom port number with my setup to access the web, it’s SSL but it’s not on port 443. You need to turn off secure_urls and change a PHP variable. Edit /etc/roundcubemail/config.inc.php $config['use_secure_urls'] = false;Edit /usr/share/roundcubemail/program/include/rcmail_output_html.php Line ~187. You can see I changed the $_SERVER line to be HTTP_HOST this will catch the custom port. $base = implode('/', $_base); } $path = (rcube_utils::https_check() ? 'https' : 'http') . '://' . $_SERVER['HTTP_HOST'] . $base . '/' . $path; } $this->assets_path = $path; $this->set_env('assets_path', $path);Do you use the files portion of Kolab and it’s not working? Lets check our configuration for Chwala. Edit /usr/share/roundcubemail/config/kolab_files.inc.php Here is my file, check the top lines, the URL fields. I at one point needed to specify HTTPS, maybe you do. I no longer need to. <?php // URL of kolab-chwala installation //$config['kolab_files_url'] = 'http://' . $_SERVER['HTTP_HOST'] . '/chwala/'; //$config['kolab_files_url'] = 'https://' . $_SERVER['HTTP_HOST'] . '/chwala/'; $config['kolab_files_url'] = '/chwala/'; // List of files list columns. Available are: name, size, mtime, type $config['kolab_files_list_cols'] = array('name', 'mtime', 'size'); // Name of the column to sort files list by $config['kolab_files_sort_col'] = 'name'; // Order of the files list sort $config['kolab_files_sort_order'] = 'asc'; ?>Have an android device or other Exchange client that you know supports sub-folders and user created folders and they never show up? Do the emails all clump together in the inbox? Try this. Edit /usr/share/kolab-syncroton/lib/kolab_sync_data_email.php Line ~108. Change the windowsoutlook15 to android public function __construct(Syncroton_Model_IDevice $device, DateTime $syncTimeStamp) { parent::__construct($device, $syncTimeStamp); $this->storage = rcube::get_instance()->get_storage(); // Outlook 2013 support multi-folder //$this->ext_devices[] = 'windowsoutlook15'; $this->ext_devices[] = 'android'; if ($this->asversion >= 14) { $this->tag_categories = true; } }Make sure you go into roundcube settings, and then folders. Check the new folders are checked. Then settings and ActiveSync and under your device check the new folders as well. After everything was good, I was still getting some odd errors with the notes portion. I could make a new Noteboot in Roundcube and add notes there, but I could not add or move notes into the primary notebook ‘Notes’ I kept getting an error. My androids could not add or read notes from it either. Very odd. After poking around I figured it’s probably something with the IMAP storage portion. I was right for my issue, and this is what I did. Login to kolab server using SSH or console as root and then change user to cyrus. su - cyrusIf you get an error with that command, then you need to probably check the login shell for cyrus. I changed the users login shell to bash. usermod -s /bin/bash cyrusOnce you are running as Cyrus we need to reconstruct the IMAP mailbox. cd /usr/lib/cyrus-imapd ./reconstruct -r user/test.userFor me the user/test.user was user/[email protected] While here I also ran ./cyr_expire -E 3 -D 3 -X 3To remove some deleted crap and clear out stuff.   [Less]

I thought it might be helpful if I wrote a quick note about my previous work on Debian packaging and Kolab. As my blog can attest, I have written a few articles about packaging and the effort required to make Kolab somewhat more amenable to a ... [More] convenient and properly functioning installation on Debian systems. Unfortunately, perhaps due to a degree of overambition and perhaps due to me being unable to deliver a convincing and/or palatable set of modifications to achieve these goals, no progress was made over the year or so I spent looking at the situation. I personally do not feel that there was enough of a productive dialogue about aligning these goals with those of the core developers of Kolab, and despite a certain level of interest from others, I no longer have the motivation to keep working on this problem. Occasionally, I receive mails from people who have read about my experiments with Debian packaging or certain elements of Kolab configuration that became part of the packaging work. This message is intended to communicate that I am no longer working on such things. Getting Kolab to work with other mail transport/delivery/storage systems or other directory systems is not particularly difficult for those with enough experience (and I am a good example of someone who has been able to gain that experience relatively quickly), but integrating this into setup-kolab in an acceptable fashion ultimately proved to be an unrealisable goal. Other people will presumably continue their work packaging various Kolab libraries for Debian, and some of these lower-level packages may even arrive in the stable release of Debian fairly soon, perhaps even delivering a recent version of those libraries. I do not, however, see any progress on getting other packages into Debian proper. I continue to have the opinion that this unfortunate situation will limit wider adoption of the Kolab technologies and does nobody but the proprietary competition any good. Since I do not believe in writing software that will never be used – having had that experience in a professional setting where I at least had the consolation of getting paid for such disappointing outcomes (and for the waste of my time) – my current focus is on developing a low-impact form of standards-based calendaring for existing mail systems, without imposing extensive infrastructure requirements when adopting such a solution, and I hope to have something useful to show in the fairly near future. This time last year, I was much more upbeat about the prospect of getting Kolab into Debian and into more people’s hands. Now, I only wish that I had changed course earlier and started on my current endeavour considerably sooner. But as people like to say: better late than never. I look forward to sharing my non-Kolab groupware developments in the coming months.   [Less]

In our current kdepim code we use some classes throughout the codebase. I’m going to line out the problems with that and propose how we can do better. The Application Domain Each application has a “domain” it was created for. KOrganizer has for ... [More] instance the calendar domain, and kmail the email domain, and each of those domains can be described with domain objects, which make up the domain model. The domain model of an application is essential, because it is what defines how we can represent the problems of that domain. If Korganizer didn’t have a domain model with attendees to events, we wouldn’t have any way to represent attendees internally, and thus couldn’t develop a feature based on that. The logic implementing the functionality on top of those domain objects is the domain logic. It implements for instance what has to happen if we remove an event from a calendar, or how we can calculate all occurrences of a recurring event. In the calendaring domain we use KCalCore to provide many of those domain objects and a large part of the domain logic. KCalCore::Event for instance, represents an event, can hold all necessary data of that event, and has the domain logic directly built-in to calculate recurrences. Since it is a public library, it provides domain-objects and the domain-logic for all calendaring applications, which is awesome, right? Only if you use it right. KCalCore KCalCore provides additionally to the containers and the calendaring logic also serialization to the iCalendar format, which is also why it more or less tries to adhere to the iCalendar RFC, for both representation an interpretation of calendaring data. This is of course very useful for applications that deal with that, and there’s nothing particularly wrong with it. One could argue that serialization and interpretation of calendaring data should be split up, but since both is described by the same RFC I think it makes a lot of sense to keep the implementations together. Coupling A problem arises when classes like KCalCore::Event are used as domain objects, and interface for the storage layer, and as actual storage format, which is precisely what we do in kdepim. The problem is that we introduce very high coupling between those components/layers and by choosing a library that adheres to an RFC the whole system is even locked down by a fully grown specification. I suppose that would be fine if only one application is using the storage layer, and that application’s sole purpose is to implement exactly that RFC and nothing else, ever. In all other cases I think it is a mistake. Domain Logic The domain logic of an application has to evolve with the application by definition. The domain objects used for that are supposed to model the problem at hand precisely, in a way that a domain logic can be built that is easy to understand and evolve as requirements change. Properties that are not used by an application only hide the important bits of a domain objects, and if a new feature is added it must be possible to adjust the domain object to reflect that. By using a class like KCalCore::Event for the domain object, these adjustments become largely impossible. The consequence is that we employ workarounds everywhere. KCalCore doesn’t provide what you need? Simply store it as “custom property”. We don’t have a class for calendars? Let’s use Akonadi::Collection with some custom attributes. Mechanisms have been designed to extend these rigid structures so we can at least work with it, but that only lead to more complex code that is ever harder to understand. Instead we could write domain logic that expresses precisely what we need, and is easier to understand and maintain. Zanshin for instance took the calendaring domain, and applied the GettingThingsDone (GTD) methodology to it. It takes a rather simple approach to todo’s and initially only required a description, a due date and a state. However, it introduced the notion that only “projects” can have subtodo’s. This restriction needs to be reflected in the domain model, and implemented in the domain logic. Because there are no projects in KCalCore, it was simply defined that todo’s with a magic property “X-Project” are defined as project. There’s nothing wrong with that itself, but you don’t want to litter your code with “if (todo->hasProperty(X-Project))”. So what do you do? You create a wrapper. And that wrapper is now already your new domain object with a nice interface. Kevin fortunately realized that we can do better, and rewrote zanshin with its own custom domain objects, that simply interface with the KCalCore containers in a thin translation layer to akonadi. This made the code much clearer, and keeps those “x-property”-workarounds in one place only. Layering A useful approach to think about application architecture are IMO layers. It’s not a silver bullet, and shouldn’t be done too excessively I think, but in some cases layer do make a lot of sense. I suggest to think about the following layers: The presentation layer: Displays stuff and nothing else. This is where you expose your domain model to the UI, and where your QML sits. The domain layer: The core of the application. This is where all the useful magic happens. The data access layer: A thin translation layer between domain and storage. It makes it possible to use the same storage layer from multiple domains and to replace the storage layer without replacing all the rest. The storage layer: The layer that persists the domain model. Akonadi. By keeping these layer’s in mind we can do a better job at keeping the coupling at a reasonable level, allowing individual components to  change as required. The presentation layer is required in any case if we want to move to QML. With QML we can no longer have half of the domain logic in the UI code, and most of the domain model should probably be exposed as a model that is directly accessible by QML. The data access layer is where akonadi provides a standardized interface for all data, so multiple applications can shared the same storage layer. This is currently made up by the i.e. KCalCore for calendars, the akonadi client API, and a couple of akonadi objects, such as Akonadi::Item and Akonadi::Collection. As this layer defines what data can be accessed by all applications, it needs to be flexible and likely has to be evolved frequently. The way forward For akonadi’s client API, aka the data access layer, I plan on defining a set of interfaces for things like calendars, events, mailfolders, emails, etc. This should eventually replace KCalCore, KContacts and friends from being the canonical interface to the data. Applications should eventually move to their own domain logic implementation. For reading and structuring data, models are IMO a suitable tool, and if we design them right this will also pave the way for QML interfaces. Of course i.e. KCalCore still has its uses for its calendaring routines, or as a serialization library to create iTip messages, but we should IMO stop using it for everything. The same of course applies to KContacts. What we still could do IMO, is share some domain logic between applications, including some domain objects. A KDEPIM::Domain::Contact could be used across applications, just like KContact::Adressee was. This keeps different applications from implementing the same logic, but of course also introduces coupling between those again. What IMO has to stay separate is the data access layer, which implements an interface to the storage layer, and that doesn’t necessarily conform to the domain layer (you could i.e. store “Blog posts” as notes in storage). This separation is IMO useful, as I expect the application domain to evolve separately from what actual storage backends provide (see zanshin). This is of course quite a chunk of work, that won’t happen at once. But need to know now where we want to end up in a couple of years, if we intend to ever get there.   [Less]

We’re proud to announce the next service release to the stable version 1.0. It contains a security fix along with some bug fixes and improvements for the long term support branch of Roundcube. The most important ones are: Security: Fix possible CSRF ... [More] attacks to some address book operations as well as to the ACL and Managesieve plugins. Fix attachments encoded in TNEF containers (from Outlook) Fix compatibility with PHP 5.2 It’s considered stable and we recommend to update all productive installations of Roundcube with this version. Download it from roundcube.net/download, see the full changelog here. Please do backup before updating!   [Less]

I have shown in the last article Kolab/Roundcube with Squirrelmail’s IMAPProxy on CentOS6 how to easily configure an IMAPProxy for Roundcube, and explained the reasons for an IMAP Proxy as well. Because I did investigate the Nginx IMAP Proxy as well ... [More] , and got it to work after some workarounds, I want to share it here as well. stunnel With Nginx I had this problem: I was not able to connect to the Cyrus IMAP if /etc/imapd.conf had the line allowplaintext: no. The error you get in /var/log/nginx/error.log is: Login only available under a layer I did not want to change it to allowplaintext: yes See also this discussion on ServerFault: Can nginx be an mail proxy for a backend server that does not accept cleartext logins? The solution is to use stunnel. On CentOS6, you can run yum install stunnel. Unfortunately, there seems to be no init script installed, so that you can run it as a service. I have taken the script from the source tar.gz file from stunnel, and saved it as /etc/init.d/stunnel: #!/bin/sh # stunnel SysV startup file # Copyright by Michal Trojnara 2002,2007,2008   PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin DAEMON=/usr/bin/stunnel PIDFILE=/var/run/stunnel/stunnel.pid   # Source function library. . /etc/rc.d/init.d/functions   test -f $DAEMON || exit 0   case "$1" in start) echo -n "Starting universal SSL tunnel: stunnel" daemon $DAEMON || echo -n " failed" echo "." ;; stop) echo -n "Stopping universal SSL tunnel: stunnel" if test -r $PIDFILE; then kill `cat $PIDFILE` 2> /dev/null || echo -n " failed" else echo -n " no PID file" fi echo "." ;; restart|force-reload) echo "Restarting universal SSL tunnel" $0 stop sleep 1 $0 start echo "done." ;; *) N=${0##*/} N=${N#[SK]??} echo "Usage: $N {start|stop|restart|force-reload}" >&2 exit 1 ;; esac   exit 0 I have created this configuration file /etc/stunnel/stunnel.conf: ; Protocol version (all, SSLv2, SSLv3, TLSv1) sslVersion = TLSv1   ; Some security enhancements for UNIX systems - comment them out on Win32 chroot = /var/run/stunnel/ setuid = nobody setgid = nobody pid = /stunnel.pid   ; Some performance tunings socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1   ; Use it for client mode client = yes ; foreground = yes   ; Service-level configuration   [imaps] accept = 8993 connect = 993 Some commands you need to run for configuring stunnel: chmod a+x /etc/init.d/stunnel service start stunnel chkconfig stunnel on Nginx IMAP Proxy Install with yum install nginx. You have to provide a service for authentication. In my case, I let Cyrus to decide if the password is correct. So I just return the IP and port of the Cyrus server. I point to port 8993 which is the stunnel to port 993 of Cyrus. This is my file /etc/nginx/nginx.conf worker_processes 1;   events { worker_connections 1024; }   error_log /var/log/nginx/error.log info;   mail { auth_http localhost:81/auth;   proxy on; imap_capabilities "IMAP4rev1" "UIDPLUS"; ## default server { listen 8143; protocol imap; } }   http { server { listen localhost:81; location = /auth { add_header Auth-Status OK; add_header Auth-Server 127.0.0.1; # backend ip add_header Auth-Port 8993; # backend port return 200; } } } And the usual: service nginx start chkconfig nginx on Roundcube configuration You need to change the port that Roundcube connects to, instead of port 143 now use 8143 where your Nginx IMAP Proxy is running. In file /etc/roundcubemail/config.inc.php: $config['default_port'] = 8143; I have added the initIMAPProxy.sh script to my TBits scripts: initIMAPProxy.sh Just change the line at the top with up-imapproxy to nginx.   [Less]