Kolab.org Groupware Solution

Sometimes it is just quicker to test the building of a CentOS package locally, than to wait for the OBS server to build it. You also get a chance to search the BUILD directory for files that you might be missing. I have written how to do this for ... [More] Debian in an earlier post (see near the bottom): http://www.pokorra.de/2013/10/howto-improve-debian-packages-using-obs/ See also http://software.opensuse.org/download?package=osc&project=openSUSE%3ATools how to install osc for all sorts of Linux distributions! For CentOS, you do this: cd /etc/yum.repos.d/ wget http://download.opensuse.org/repositories/openSUSE:Tools/CentOS_6/openSUSE:Tools.repo yum install ocs build osc -A https://obs.kolabsys.com:444/ checkout home:timotheus:branches:Kolab:Development cd home:timotheus:branches:Kolab:Development/kolab-utils osc build CentOS_6 x86_64 kolab-utils.spec --no-verify Without the –no-verify parameter, you get errors like these: /var/tmp/osbuild-packagecache/CentOS:6/release/x86_64/acl-2.2.49-6.el6.x86_64.rpm : public key not available /var/tmp/osbuild-packagecache/CentOS:6/release/x86_64/attr-2.4.44-7.el6.x86_64.rpm : public key not available [...] By the way, you find the BUILDROOT in: /var/tmp/build-root/CentOS_6-x86_64/home/abuild/rpmbuild/BUILDROOT/   [Less]

It’s quite annoying when you click somebody’s name or email on a web page and that Firefox cannot figure out how to rely on your system preferences to send an email. For instance, my system is set up so that when I click on an email address or ... [More] mailto: link anywhere, gnome-terminal opens up with mutt ready to send an email. For some reason, Firefox tries to figure out all by itself which program I should use. I have tried to make Firefox use gnome-terminal with mutt, but it didn’t work. However, it’s possible to add your own webmail there (for some reason, I could choose between Yahoo Mail, Gmail and Mykolab.com but I can’t remember how I did that). Now that I have my own Kolab instance with roundcube, I decided to add my own webmail there. Unfortunately, it seems there’s no way from the graphical interface, so I went straight to: ~/.mozilla/firefox/iceweaselprofile.hugo/mimeTypes.rdf. It’s quite a big file FWIW (885 lines here). I did not have a look at the details, but hopefully just adding this helps (for the second block, make sure to merge with existing mailto handlers): <RDF:Description RDF:about="urn:handler:web:https://kolab.example.org/roundcubemail/?_task=mail&amp;_action=compose&amp;_to=%s" NC:prettyName="Kolab Groupware" NC:uriTemplate="https://kolab.example.org/roundcubemail/?_task=mail&amp;_action=compose&amp;_to=%s" /> <RDF:Description RDF:about="urn:scheme:handler:mailto" NC:alwaysAsk="true"> <NC:possibleApplication RDF:resource="urn:handler:web:https://kolab.example.org/roundcubemail/?_task=mail&amp;_action=compose&amp;_to=%s"/> </RDF:Description> (Just replace https://kolab.example.org/roundcubemail/ with your own Roundcube location. And of course, if you don’t use Kolab replace “Kolab Groupware” by whatever.)   [Less]

For Quality Assurance, it is important that the testing of functionality can be automated. Depending on the detail of the tests, the tests are called Unit Tests or Integration tests. This article shows how to write tests in Python, and run them ... [More] against an installed instance of Kolab, using Selenium, on CentOS. Useful links are: Python unittest — Unit testing framework Selenium Python Bindings: Getting started Selenium HQ WebDriver We are using the Firefox browser on a headless CentOS machine. We need to install the following packages: sudo yum install python-setuptools Xvfb firefox sudo easy_install selenium sudo dbus-uuidgen > /var/lib/dbus/machine-id To run Firefox on a headless system, you need to start the X Virtual FrameBuffer (Xvfb): sudo Xvfb :10 -ac -screen 0 1280x1024x24On another console, you can now run: export DISPLAY=:10python test.py For a first example of a test for Kolab, see testCreateUserAndEditSelf.py. This test assumes that the password of the Directory Manager is "test", and it will create a new user, check that the default folders in the mailbox have been created, login with that user, and attempt to change the initials of the user and save them. By the way, the test currently fails on Kolab 3.1 updates (check /var/log/httpd/error_log for details), due to bug https://issues.kolab.org/show_bug.cgi?id=2414, which was the whole point of setting up this test case...   [Less]

This should work with any carddav server, but if you use Kolab’s carddav server here’s some extra tip! The problem you want to fix is: it’s impossible to remember everyone’s email address. This problem is solved by most email programs because they ... [More] are linked to a contact list already. However, for those of us using mutt, there’s no full contact integration so you need to rely on something else. One obvious solution is to rely on a mail indexer to search and find addresses in emails from the past. If you use mu, here’s how Karsten does it. However, that’s not really helping if you have contact information from multiple sources (e.g. typing on your mobile the email address of somebody you just met AFK). This is where a contact server is handy. If you use Google’s contacts, you can use goobook it works well but it’s quite slow IMHO. And obviously, the problem is that you have given up your whole contact list to Google. Find your Kolab addressbook With Kolab 3.1 comes a CardDav/CalDav/webDav server! Version 3.1 was just released today. So let’s use that instead. When I set up Kolab 3.1 before the official release, I got a packaging bug in CentOS, but it’s easy to fix. The *Dav server is located at https://kolab.example.org/iRony. Now, you need to find how to link to a specific addressbook. I tried to have a look at the Roundcube interface, for a folder id or something, but I could not find any that was working. Just connect a webDav client (in Nautilus, File > Connect to a server) to the iRony folder, and then just navigate to find the addressbook identifier (look in the address bar!) Hopefully, this will soon not be needed any longer. There will be a “Show address book URL” setting directly in Roundcube’s contacts menu. Sync your CardDav addressbook with pyCardDAV Now install pyCardDav which just landed on Debian last month: # apt-get install pycarddav Sync pycarddav after you entered the Kolab addressbook resource in the config file with pycardsyncer I advise you run this with --debug to make sure that it does not get stuck in case you have some illegal characters inside one of your vCards. If it gets stuck, then you can just go back to your webDav client and edit the file that’s causing trouble. If all goes well, you should be able to search for contacts inside your local copy: % pc_query hugo searching for hugo... Name: Hugo Roy TEL (CELL): +... EMAIL (INTERNET\, WORK): hugo at fsfe dot org Lookup directly from mutt I just added this to my ~/.muttrc: set query_command="pc_query -m '%s'" bind editor <Tab> complete-query That way, in mutt, just type ‘Q’ to search for a contact. Or you can also press ‘m’ to start a new message, start typing in the ‘To:’ field the name of your contact and just press [Tab] to have autocompletion!   [Less]

CardDav and CalDav server After setting up Kolab 3.1, which includes a cardDav and CalDav server, it is possible that, going with a web browser to https://totosh.ampoliros.net/iRony/ gives the error: Requested uri (/iRony/) is out of base uri To fix this, change “null” in /etc/iRony/dav.inc.php $rcmail_config['base_uri'] = '/iRony/';  

Here at Kolab Systems, we've all been excited about the launch of MyKolab.com as a professional, secure, privacy-aware-for-a-change, commercial service offering to those appreciative of what privacy means exactly - our customers. You can read all ... [More] about what MyKolab.com can do, why your private parts are truly private, and how we do not mislead you in pretending that something is what it is not. But that is not all there is to it... While we've had to put in a lot of time to scramble the first production deployment of Kolab 3.1, not even released yet, at the large scale that the environment was already thanks to its thousands of beta program users, making it the largest known entirely Free Software hosted groupware environment in the world right off the bat, what truly inspites me is that only a very limited number of the problems reported are exclusively our problem, as MyKolab.com runs vanilla Kolab Groupware - the Free Software groupware solution - and a Customer Control Panel we've developed, that we are not shipping in any software repository yet (but is Free Software nonetheless) - and nothing else. I cannot under-emphasize the fact that what we do to run a thing like MyKolab.com, you are at liberty to run yourself, for any purpose. All we did is apply a little bit of our own consultancy sauce (available in-house, as you can imagine), to an otherwise vanilla Kolab 3.1 deployment. And in continuing to further develop the solution, making sure that what can be applied to MyKolab.com can be applied to the Kolab server you run yourself, we continue to explore technological opportunities to provide privacy and protection to an even larger extent. Just to state one example, some of my most recent messages on the subject is about us (Kolab Systems, the propietor of MyKolab.com) not mis-selling a feature called Perfect Forward Secrecy (PFS). When applied to sending and receiving email communications (over SMTP), I consider PFS be subject to quite a list of other parameters, some of which we can't enforce, such as the requirement to have the receiving SMTP server support STARTTLS even before PFS can be used - more about these and other things later. Long story short, I would rather de-emphasize "featuring PFS" and not make you aware that that is what happens (if at all available), than tell you it happens (and sell you on it) while in fact it may not - simply because that, to me, constitutes misleading you and I would feel dishonest, guilty, and I could not raise my kids right feeling like that. Back to the original topic, MyKolab.com being the first production deployment of Kolab 3.1, though, by now, not the only one any longer, in effect the problems that are reported directly pay towards getting the fixes end up in your pocket, in a way that (and I myself am responsible for this) is sustainable - there's no quick fixes solely for our business (although our business can apply proper fixes quickly, and very probably much quicker than anyone else can). If you look at it like so, and you draw the line just a little further, the MyKolab.com customers are Free Software contributors. As such, if you'll pardon my French, MyKolab.com and Kolab Systems are to kolab.org or "Kolab" what "Red Hat" (Uncle Shadowman) is to the Fedora Project and Enterprise Linux derivatives such as CentOS. With one major difference, which at the same time is a commonality - with MyKolab.com we invite you to, and in fact we facilitate you should you choose to, walk away with your data, no hard feelings - though we might have some questions you're not obliged to answer (such as "Why?" so we can learn how to improve the product and our service). These facts, as are others, are not to be underestimated when you consider we believe that the best decision you can make is a well-informed decision, using your own judgement, whether that be the correct decision in anyone else's view or not. All of that - the level of transparency, and honesty, and the fact that you can inform yourself, and that you can Do It Yourself At All Liberty - I believe builds a sustainable solution. A business, the Kolab Groupware guardian and patron, that works to further increase software freedom for people, along with the people sustaining the business, makes for a wonderful world to live in. As such, in many, many more ways than one, My Kolab Es Su Kolab, truly. There's no two ways about it or I, for one, wouldn't be anywhere near it.   [Less]

I just had a good day ☺ The results of the first part of the bar exam were announced earlier today. I passed! So I’ve got no more excuses now: I’ve got to work to pass the second part (oral exams). Of course, that’s kind of a relief because with ... [More] these kinds of exams you’re never really sure if you succeeded. To make things even better today, it looks like Kolab on Debian is going to get some love from the Free Software community! Kolab now has nightly builds for both CentOS and Debian Torsten published a Call for Participation explaining some of the reasons why Kolab on Debian does not benefit from the same level of involvement than Kolab on CentOS. So now, it’s our job as a community to take care of it and make sure that Kolab becomes a first-class citizen on Debian! If you have some experience in packaging: please go read HowTo improve Debian packages using OBS It seems like Paul is already looking into helping! As far as I’m concerned, this is all great news. It is a bit sad that I was too impatient and already went for CentOS to try Kolab. But at least now, I know I can recommend Kolab to my friends who use Debian: the community is here to help! I’ll have to find a way to contribute personally though ☺ Oh and BTW, I’m now in London until Monday. Mozilla invited me to run a session at the Mozilla festival on “Fighting the biggest lie on the Web” (I agree to the terms of service!) I am really looking forward to this. Mozilla is one of the most important organisation building the technologies that empower people! I don’t even want to think about what the web would look like today without the work they have done (including a lot of volunteers and a very open way). I can’t wait to feel the atmosphere of the festival! So if you’re in London too, even if you’re not attending #MozFest (I have read the event is already full!) do not hesitate to get in touch. Tomorrow I’ll try to meet with my friend Andreas who’s been a volunteer with the Free Software Foundation Europe for a long time, and who’s moving in London. I’ll also try to catch up with Mark Lizar who’s one of the core persons behind Open Notice, the place where projects related to ToS and privacy policies collaborate. Exciting week-end ahead!   [Less]

Well, after my recent blog post highlighting some surprising problems with my Kolab installation – not at all a complaint about the packages, really, but more of a contribution towards improving the packaging situation, as I see it at least – some ... [More] more interest in the situation around Kolab packaging for Debian has been shown: HowTo improve Debian packages using OBS describes the documented packaging-related process in more detail for a specific improvement. A Call for Participation invites those interested in Debian packaging to get involved. Packaging for Debian can be a challenge. My own experience involved a pure-Python tool and still required lots of iterations to satisfy the Debian gatekeepers; this is understandable given that they try to virtually guarantee a coherent experience and provide a large selection of software whose copyright and licensing status must be clear, acceptable and without nasty surprises. I respect the effort that has gone into Kolab packaging for Debian already: without that effort, I probably wouldn’t even have tried the software. The plan now must surely involve input from the Debian groupware initiative, especially as the Kolab architecture presumably resembles some of the other packaged solutions, and those who have contributed to the existing packaging work, as well as some discussion on the Kolab development mailing list, and some effort with the Open Build Service tools (with the “build commander” tool fortunately being available as a Debian package). It is unfortunate that as Torsten points out, “Currently, there’s only one volunteer working on the Debian packages in his limited spare time, but hundreds of people who want to use reliable Debian packages.” Meanwhile, Timotheus points out, “Since there seems to be no corporate funding available for the Debian packages, we all need to pull together as a community and get it done!” It seems to me that those organisations that stand to benefit from more adoption of Free Software groupware, especially those using Debian as their foundation, might do well to assist this work instead of waiting for people to get it done in their free time.   [Less]

This is a quick tutorial how to branch packages on OBS (hosted by Kolab Systems), for improving the Debian packages. Please see also the step by step instructions in the Kolab documentation. My steps show how to fix the bug 2404: Register a ... [More] user https://obs.kolabsys.com/user/register_user Create a home project by clicking “Home Project” in the upper right corner. Go to project “Kolab Development”: https://obs.kolabsys.com/project/show?project=Kolab%3ADevelopment Since the problem is a missing file (auth_cache.py) in package pykolab, go to package https://obs.kolabsys.com/package/show?package=pykolab&project=Kolab%3ADevelopment Branch the package by clicking “Branch package”. Confirm with “OK” Now you are redirected to your branched version of the package, in my example: https://obs.kolabsys.com/package/show?package=pykolab&project=home%3Atimotheus%3Abranches%3AKolab%3ADevelopment Go back to your project, https://obs.kolabsys.com/project/show?project=home%3Atimotheus%3Abranches%3AKolab%3ADevelopment; click on Repositories, and remove all distributions that are of no interest to you. That way there are no unnecessary builds on the server. I keep only Debian 7.0. If the 64 bit version is what you want, you can also disable the 32 bit build, by hovering over the green icon, and selecting “Explicitly disable”. Also make sure that the “publish” flag is set for the distribution that you want to use. Now go back to “Overview”, and click on package “pykolab”. You could actually edit files directly in the web interface, and that would trigger a new build. But for the issue regarding the missing file, we need to edit a file inside the debian.tar.gz, and it is easier to use the osc command line tool for that. Install osc on your own local machine. It is a bit like a git client. It is availabe for many distributions. Checkout your project to your local machine: osc -A https://obs.kolabsys.com:444/ checkout home:timotheus:branches:Kolab:Development cd home:timotheus:branches:Kolab:Development/pykolab Now you untar the file debian.tar.gz, and edit the file tar xzf debian.tar.g cd debian vi pykolab.install check https://git.kolab.org/pykolab/tree/pykolab/auth/ldap for the missing files, and add new lines, and save: usr/lib*/python*/*-packages/pykolab/auth/ldap/auth_cache.py usr/lib*/python*/*-packages/pykolab/auth/ldap/syncrepl.py tar the file again, and delete the debian directory: tar czf debian.tar.gz debian rm -Rf debian In order for the package to be actually installed when you want to test it, and because it is good practise anyway, you have to update the files debian.changelog and pykolab.dsc as well: pykolab.dsc: modify the line with Version, eg. Version: 0.6.8-0~kolab1 to Version: 0.6.8-0~kolab1.1 debian.changelog: copy the top lines, change the version number the same way as in pykolab.dsc, modify the description, and your author name Before you can commit, make sure you add the following lines to your file ~/.oscrc: [https://obs.kolabsys.com:444] user=timotheus pass=*** Now commit your changes with the osc tool: osc commit -m “adding missing files auth_cache.py and syncrepl.py, fixing bug 2404″ This will upload your changes to the OBS server, and immediately trigger a rebuild of the package pykolab. You can now install your packages, similar to installing the nightly packages, just replace the username in /etc/apt/sources.list.d/kolab.list When you have tested your packages, you can click “Submit package” on your pykolab project page: https://obs.kolabsys.com/package/show?package=pykolab&project=home%3Atimotheus%3Abranches%3AKolab%3ADevelopment to allow your fixes to go upstream again! You can see the submit request here: https://obs.kolabsys.com/request/show/168   [Less]