Kolab.org Groupware Solution

Das Vorgehen entspricht im Wesentlichen: http://docs.kolab.org/de-DE/Kolab_Groupware/3.0/html/Community_Installation_Guide/index.html, jedoch mit neueren Repoisitories und einer Fehlerbehebung (Punkt8) … unter Debian7 (wheezy, 64bit) - minimale ... [More] Installation, ohne X - sda ist die Systemplatte - sdb ist die Datenplatte 1) Partitionen separieren (auf Datenpartition) … der Einfachheit halber /media/sdb nach /var gemountet: cat /etc/fstab: # /var auf Datenplatte einbinden /media/sdb    /var        auto    bind    0    0 2) /etc/hosts der FQDN muss auf die echte IP-Adresse aufgelöst werden und nicht auf die loopback-Adresse!! Test: ping $(hostname -f) 3) Repositories Hinzufügen zu /etc/apt/sources.list: deb http://mirror.kolabsys.com/pub/debian/kolab-3.0/ wheezy release development deb-src http://mirror.kolabsys.com/pub/debian/kolab-3.0/ wheezy release development 4) Apt Pininng Datei erstellen: /etc/apt/preferences.d/kolab: Package: * Pin: origin mirror.kolabsys.com Pin-Priority: 501 5) Exim (Debian-Standard MTA) entfernen apt-get remove exim4 exim4-base exim4-config exim4-daemon-light 6) kolab installieren apt-get update apt-get install kolab 7) kolab konfigurieren setup-kolab 8) Der Punkt “Neue Benutzer anlegen” fehlt im http://mykolabserver/kolab-webadmin Lösung: echo /usr/lib/x86_64-linux-gnu/nss/ > /etc/ld.so.conf.d/mozldap.conf ldconfig 9) reboot 10) Erstes Login am Webadmin-Frontend (http://mykolabserver/kolab-webadmin) user: “cn=Directory Manager” 11) Benutzer anlegen kolab-admin;  Rolle: kolab-admin (weitere Benutzer nach Bedarf) 12) Erstes Login am Webmailer (http://mykolabserver/roundcubemail)   [Less]

This is a guest post by Alexej Ruseckij. Here's a config for nginx&php5-fpm that works under Debian7 and CentOS6. It still needs some testing under CentOS6, though. All features seem to be working at first, second and third glance, but I didn't ... [More] go much past glances. It does work in Debian7 pretty well. It's set to enforce https connection to all of web interfaces of Kolab3. Roundcube webmail will be accessable as: https://kolab3.example.net/and Kolab webadmin as: https://kolab3.example.net/kolab-webadmin/ActiveSync and freebusy also work. In Debian7 you can just copy and paste the nginx config into /etc/nginx/sites-available/ and fpm pools into /etc/php5/fpm/pool.d/, fix server names and restart nginx and php5-fpm, it should work. If you don't change it, It will use snakeoil autogenerated certificates for SSL. For CentOS6 you'll need to put nginx config into /etc/nginx/conf.d/, change server names and direct it to correct ssl certificates. Php5-fpm pools should be put into /etc/php-fpm.d/, user:group in php5-fpm pools changed to apache:apache. Then restart both. The difference between CentOS6 and Debian7 defaults were that in Debian's nginx/fastcgi_params there was a line: fastcgi_param SCRIPT_FILENAME $request_filename;A note on use of caches. Caches declared in config are not mandatory and have default values for Debian7 amd64. But they speed up roundcube significantly and I prefer to use them whenever I can. HTTP part, the first 4 lines not counting commentary, are supposed to be within http{}, so you might want to put them into nginx.conf, instead of per-site config file. Looking forward to your feedback and hope someone can test it more under CentOS6.   [Less]

After a somewhat brief overview over the world we find ourselves in, the question is what does this mean to us as a society? As highlighted in the previous article, governments have no realistic option not to engage in some form of activities to ... [More] protect their people from threats that originate on-line or have an on-line component. These were the grounds for German chancellor Angela Merkel to make statements of support for PRISM. The problem is that I doubt it is effective and adequate to the threat. The side effects seem out of sync with the gain. That this gain is only claimed, not proven due to alleged security concerns, also does nothing to help the case. It has become public knowledge these technologies exist and make mass surveillance can and is being implemented, and works efficiently. Calling for a general ban is unrealistic, and naive. Of course these technologies will be used against people, businesses and governments by someone – be they states or organisations. So the actual question is: Which are the circumstances under which use of such technology is acceptable? Looking at the initial reactions, a great number of people – consciously or not – base their reaction on Article 12 of the Universal Declaration of Human Rights. And considering the consequences, that does not seem very far fetched. Consequences of the Surveillance Society There are some stories floating around where people have suffered repercussions such as being denied entry to the United States. But that’s probably the extent of it for many of us unless you are a public figure, or ever find yourself in a job where you would have influence on a decision that might be of major consequence to the United States. But that’s only the fairly superficial perspective. Consider for a moment the Arab spring where governments desperately tried to remain in power. In several cases the governments overthrown were the same ones that received strategic and practical support by the United States – including military and secret service activities – as part of their plans for the region. These governments in their desperate attempts to retain control knew which activists to imprison, sometimes torture and often confronted them with their own private messages from Facebook and Twitter. Could those governments have to obtained that data itself? Possibly. But there is another option. FISA makes it legal for the United States to obtain and make use of that data for the strategic interests of the United States. And Prism would have made it almost trivial. So the simpler way for those governments to know what was planned would have been to receive dossiers from their US contacts. Does this prove it happened that way? Certainly not. But it demonstrates the level of influence this combination of technical ability is giving the United States and other countries. “Still,” most people think ‘I am living in a safe country and have no plans to overthrow my government.’ “Nothing to hide, nothing to fear” has been used to justify surveillance for a long time. It’s a simple and wrong answer. Because everyone has areas they would prefer to remain private. If someone has the ability to threaten you with exposing something you do not wish to see exposed, they have power over you. But what’s more: People who have to assume to be watched at all times, even in their most intimate moments and inner thoughts, behave differently. A culture of surveillance leads to self regulation, with fundamental impact how people behave at all times. Will you still speak up against things you perceive as wrong when you fear there might be repercussions? Or would you perhaps ask yourself whether this particular issue is important enough to risk so much, and hope that it won’t be as bad, or that someone else will take action? Also, consider the situation of people who absolutely rely upon a certain level of privacy for their professional lives, such as lawyers, journalists and others. That no-one in these professions should be using these services should be self-evident. But if a society adopts the “Nothing to hide, nothing to fear” dogma, those who communicate for good reason with such professions will stand out as dark shadows in an otherwise fully lit room, and will raise suspicion. If privacy becomes the exception those who require privacy will easily be singled out. The only way to avoid this is to make privacy the norm: If everyone has privacy, no-one will be suspicious for it. And there are good reasons you would want to do your part to live in such a society, because the functioning of democracy as a whole is linked to a set of factors, including a working media, ability to form political opinion, and become politically active to achieve change for the better. And even if you yourself have no ambition in this way at this point in time. Privacy is one of the essential building blocks of a free society. You might find yourself activated by misspent tax money, a new highway being planned through your back yard, or the plans to re-purpose your favourite city park for a shopping mall. And if it isn’t yourself, perhaps something will make your parents, siblings, spouse, kids, best friend want to take action and then require a society that grants privacy in order not to be intimidated into silence. So there are good reasons why people worry about this level of surveillance. Why, then, are they choosing to voluntarily support it? Feudal Agents of the Totalitarian State It has been subject of discussion in the software freedom community for some time, but only now appears to hit the radar of a larger subset of the forward thinking IT literates: The large US service providers own users and their data in ways that led security guru Bruce Schneier to comparing them to feudal lords, leaving their users as hapless peasants in a global Game of Thrones power struggle. Some time ago already, Geek & Poke probably summarized it slightly more pointedly: One aspect of using these services is that users place themselves under surveillance as part of their payment for the service. The plethora of knowledge Facebook keeps on everyone that is using it, and everyone that is not using it, has been disclosed time and again, last time during the shadow profile exposure. But this has not been the first time. Nor can anyone reasonably expect Google, Microsoft or Apple to behave any different. What is important to understand is that the centralisation of these services, and turning devices into increasingly dumb data gathering and supply devices is not accidental, nor is it technologically necessary. We all carry around a lot more computing power all the time than was readily available just some years ago. So these devices and services could operate in a de-centralized and meshed fashion. But then the companies would not get to profile their users in such detail, potentially gathering every intimate detail about them, such as whether they were aroused when they last used voice search to find the nearest hotel. Or did you think that command was analysed on your smart phone, and not by the (almost) infinitely powerful processing power in the data centres of your service provider? Data is the new gold, and these companies are mining it as best they can. Naturally these companies are always downplaying the amount of data collected, or the impact that use of this data might have on individuals. PRISM exposed this carefully crafted fallacy to some extent. It also raised the question: What is it worse? That the government which can be held accountable to a larger degree gets access to some data gathered by a company? Or that a company that is responsible to no-one but its shareholders gathered all of it? In fact, cynically speaking, one might even think these companies are mostly unhappy about the fact that the US government wants free, unlimited access to the raw data rather than the paid for refined access they offer as part of their business model. But the root cause is in the centralised gathering of such data under terms that do not make these companies your service providers, but you their peasant. This treasure trove will always attract desires, and countries have ways to get access because they have ways to impact profits. Now that the PRISM disclosure taught them what’s possible, countries such as Turkey are quickly catching on, demanding access to details of Gezi protesters. So while these companies are often wrapping themselves in liberty, the internet and all that is good for humankind, by their existence and business model they make a contribution to a totalitarian society. Whether that contribution is decisive, or outweighs the instances where they do good, I cannot judge. But using these providers for your services and getting all up in arms about PRISM is somewhat hypocritical, I’m afraid. It’s a bit like complaining about losing your foot when you’ve voluntarily and without need amputated your entire leg before to be able to make use of the special “one-legged all you can eat buffet.” Choices for Free Citizens So assuming you want to break free of this surveillance and the tendencies towards a totalitarian society, which are your options? Firstly, choose Open Source / Free Software and Open Standards. There is a plethora of applications out there and the way in which their internal workings and control structures are transparent and publicly developed makes it much more likely they will not provide back doors to your data. Following the PRISM leaks, sites such as http://prism-break.org have sprung up that try to help you do just that. Secondly, start making use of encryption, which is easier and more effective than you might think. Chances are that someone in your circle of friends or family is already using some or even many of these applications. Get them to help you get started yourself. But assuming you are not a technical person, which is most of society, the most important choice you can likely make is with your feet and wallet by choosing services that work for you and put themselves at your service – rather than services that process you and put you at their service. The important place for this is to look at the terms of the services you are using. I know this is tedious, and these terms are often deliberately written to make eyes glaze over when trying to understand what they actually say. But there is a web site that can help you with it: Terms of Service; Didn’t Read. Check out the services you are currently using, and get yourself the browser extension so you at least start getting an idea of what kinds of rights you are surrendering by making use of the services. As for providers that offer you the same convenience, but without the mandatory cavity search, there are still quite a few. Naturally it makes sense to look at their terms of services carefully, ensure they are based in a legislation of your choice, and use technologies that you can trust. If you are not sure, ask them to explain what standards they observe with regards your data. And ensure you can switch providers, even switch to self-hosting if you want to, without necessarily changing technologies. And once you’ve looked through all those criteria and made your homework on which solutions can deliver all of this, without compromise, take control of your data and software. Disclaimer I’m not a party without interest in this debate. You can easily inform yourself about what I’ve done in the past in this area. And my past years I’ve dedicated to building a technology that would allow people to own their data and software, while providing all the features users have grown accustomed to. That technology is called Kolab, and of course I’d be delighted if you got in touch with us, or installed Kolab.org on your own, or even made use of the http://MyKolab.com service. Because all of this will help us continue to work to the goal of allowing people secure, powerful collaboration across platforms while owning their own data and software. But it’s this work that has followed from my analysis, not the other way around. So make up your own mind.   [Less]

Sixteen weeks have passed since my last post – quite some time! About a week ago I switched my private mail system to Kolab 3, using openSUSE 12.3 as a base. Works really great! We progressed far and I'm proud to announce: Kolab 3.0 for openSUSE 12.2 ... [More] and openSUSE 12.3 STABLE repositories are published! (Or at least they are building at the moment, so they will be published in the next hours ;)   Installation instructions: As root, use the following commands to get Kolab 3 running on your openSUSE 12.3 system: 1) Add the Kolab 3 repositories to your openSUSE system # zypper ar http://download.opensuse.org/repositories/server:/Kolab:/STABLE/openSUSE_12.3 server:Kolab:STABLE # zypper ar http://download.opensuse.org/repositories/server:/Kolab:/Extras/openSUSE_12.3 server:Kolab:Extras # zypper refresh  2) Install Kolab 3 and required packages # zypper install kolab(This pulls about 40 MiB of package data)   3) Run kolab-pre-setup to prepare the system environment and start the setup afterwards. # kolab-pre-setup(Don't forget to provide your FQDN while cretaing your certificates using kolab-pre-setup, or the creation will fail!) # kolab-setup  That's all you have to do, it's just that easy!   Progress since week 10 Richard Bos and I enhanced kolab-scripts a lot, making it modular, giving the ability to disable installation checks using /etc/kolab/pre-setup.conf check-certs.sh and kolab-cert are more verbose about failed certificate creations! All the spec files were revised, making them easier to maintain. kolab-syncroton was updated to 2.1.rc2 A new package kolab-freebusy has been packaged, handling access to our generated free/busy data pykolab and all sub packages were updated to version 0.5.12 kolab-cli: setup_roundcube.py now has a more verbose text when asking for the user dirsrv should run under and reccommends 'kolab' as a default (instead of 'nobody'). kolab-cli: setup_roundcube.py got a patch, so it now applies its template and again kolab-cli: setup_freebusy.py is re-included, working and sets up your free/busy web access! I updated kolab-utils to 3.0.5 and afterwards to git snapshot bd6ee4f libkolab was updated to version 0.4.2 libkolabxml is now ready in version 0.8.4 and kolab-utils and libkolabxml build successfully on SLE 11 SP2, even mono and php bindings roundcubemail was updated to 0.9.2, a few integrated plugins were seperated into different packages in server:Kolab:Extras I switched build repos for 12.2 from KDE:Distro:Factory to KDE:Distro:410 The wiki page had some updates. Ideas for further updates can be found here. Outdated and obsoleted Roundcube plugins in kolab-syncroton got dropped. In previous installations, these were overidden by roundcubemail-plugins-kolab, which contained newer versions. Kontact/Akonadi in openSUSE:Factory now have LDAP presets for handling Kolab 3 servers Sieve port in openSUSE:Factory now is mapped to port 4190 TCP instead of 2000 TCP (see IANA service and port numbers) cyrus-imapd in openSUSE:Factory now ships with full pts support! 389-admin from server:Kolab:Extras was buggy on uninstall and built with a wrong init script path. Moreover systemd support was disabled. Both have been fixed now. We're using libcalendaring as default when building libkolab and kolab-utils. This fixes some nastsy bugs when trying to create the free/busy data and removes some overhead. All packages are built and packaged on OBS (server:Kolab:UNSTABLE and server:Kolab:Extras). The repositories can be easily added via zypper or YaST.   Tasks We still have plenty of TODOs for our Wiki pages on opensuse.org. There are plans to provide support for OpenLDAP - this includes schema, packages and dependencies, automatic setup and so on. There are also plans to provide support for Dovecot. We have lots of user_deny.db fetching: this will reduce to one time fetching, when cyrus-imapd is upgraded from 2.3.18 to 2.4.x. Currently systemd support on 389-admin is broken, so we ship with init scripts. Push packages from server:Kolab:Extras without devel projects into adequate projects and re-link them to s:K:E. Submit packages from server:Kolab:Extras to openSUSE:Factory If you want to help, to contribute, to test Kolab 3 on openSUSE or if you encounter a bug, don't hesitate to contact me.   On a sidenote: I'm in a process to submit all server:Kolab:Extras packages to openSUSE:Factory to only have dependencies left in server:Kolab:STABLE and the upcoming openSUSE releases. A next step includes pushing our server:Kolab:STABLE packeges into openSUSE:Factory, having Kolab included in the distribution per default, making it more accessible and thus bringing Kolab on openSUSE to a broader audience!   [Less]

Questions of privacy, security and control have occupied me for a long time, both personally and professionally. In fact it was a significant aspect of my decision to switch focus from the Free Software Foundation Europe to Kolab Systems: I wanted to ... [More] reduce the barriers to actually putting the principles into practice. That required a professional solution which would offer all the benefits and features people have grown accustomed to, but would provide it as high quality Open Source / Free Software with a strong focus on Open Standards. What surprised me at the time was the amount of discussions I had with other business people and potential customers whether there was really a point in investing so much into such a business and technology since Google Apps and similar services were so strong already, so convenient, and so deceptively cheap. I remember similar conversations about Free Software in the 90s, where people were questioning whether the convenience of the proprietary world could ever be challenged. Now the issues of control over your software strategy and the ability to innovate are increasingly becoming commonplace. Data control wasn’t really a topic for many so far although the two are clearly inseparable. But somehow too much of it sounded like science fiction or bad conspiracy theories. There have of course been discussions among people who paid attention. Following the concerns about the United States’ capabilities to monitor most of the world’s transmitted information through ECHELON, many people were alarmed about the Foreign Intelligence Surveillance Act (FISA). It has given rise to many conspiracy theories about how the United States have access to virtually all the information hosted with US technology companies anywhere in the world and would be able to use that information to their military, political and economic advantage. But no-one wanted to believe them, as the United States feel so familiar thanks to Hollywood and other cultural exports, and in Europe still thanks to the gratefulness many people still hold for the US contribution to liberating Europe 50 years ago. Only stories about US surveillance weren’t conspiracy theories, it seems. There has been a flurry of public reports around a large number of security and privacy relevant issues in the past weeks. But due to the complexity of the issue, most articles only deal with a tiny piece of the puzzle, and often miss the bigger picture that I am seeing right now. Trying to provide that picture has quickly left me with an article much too long for general reading, so I’ve decided to try and break it up into four articles, of which this is the first. Its goal is to get you up to speed with some of today’s realities, in case you hadn’t been paying attention. Part I: What We Know The recent disclosures about the NSA PRISM program have made it quite clear that what is written in black and white in US law is also being put into action. As Caspar Bowden summarized clearly in his presentation at the ORGCon2013, FISA provides agents of the United States with access to “information with respect to a foreign based political organization or foreign territory that relates to the conduct of the foreign affairs of the United States.” It’s limiting factor is the 4th Amendment, which does not apply to people who are not located in the United States. Which is most of us. In other words: The United States have granted themselves unlimited access to all information they deem relevant to their interests, provided at least one party to that information is not located in the United States. And they have installed a very effective and largely automated system to get access to that kind of information. Michael Arrington has done a good job at speculating how this system likely works, and his explanation is certainly consistent with the known facts as well as knowledge of how one would design such a system. If true, mining all this information would be as easy and not much slower as any regular Google search query. What’s more, there is no functioning legal oversight over this system, as the US allow for warrantless wiretapping and access to information. The largest amount of queries most likely never saw a judge while simultaneously being labelled secret. And according to what one has to intepret from the statements of Edward Snowden, only the smallest number of queries ever make it to the secret FISA Court (FISC). A court which is secret itself and has been described as a “rubberstamping court” in many reports. And we know the United States is far from the only country involved in such activities. Turns out the United Kingdom has been just as active, and might even have gone to further extremes in their storing, analysis and access of personal information as part of its “Mastering the Internet” activities. It would be naive to assume that is where it stops. We know that other countries have well trained IT specialists working on similar activities, or even offensive measures. China has been a major target. But it also successfully read the internal documents of German ministries for years, and managed to even breach into Google‘s internal infrastructure. Israel has been known to have some of the best IT security specialists in the world, and countries such as India and Brazil are certainly large enough and with major IT expertise. Naturally there is not a whole lot of publicly documented evidence, but given that this subject has been discussed for over a decade one would have to assume total ineptitude and incompetence in the rest of the world outside the US and UK to assume these are the only such programs. The most reasonable working assumption under these circumstances is: Surveillance is omnipresent and commonly employed by everyone with sufficient ability. But it’s not just surveillance of readily available data with support from companies that are required by law to comply with such requests. Offensive Measures Another way in which countries engage in the digital world is through active intrusion. In Germany there was a large debate around the ‘Federal Trojan‘, which in some ways goes a good step further than PRISM. Such active intrusion damages the integrity of systems, has the potential to leave them damaged, and potentially subject to easier additional break-ins. How easy it is to make use of this kind of technology has become clear during the public FinFisher debate. The price tag of this kind of tool is easily within reach of any government worldwide, and it would be naïve to assume that countries and their secret agencies do not make use of it. But in the flurry disclosures another interesting aspect has also been revealed: At least some software vendors are complicit with a number of governments to facilitate break-ins into customer systems. The company that has been highlighted for this behaviour is Microsoft, source of the world’s dominant desktop platform. Rumours about a door in Microsoft Windows to allow the US government access have been floating around now for a long time, but always been denied. And rightly so, apparently. It is not that Microsoft has deliberately weakened their software in a specific place. They didn’t have to. Instead, they manipulated the process of addressing vulnerabilities in ways to allow the NSA and others to break into 95% of the world’s desktop systems. But Microsoft is not the only party with knowledge about vulnerabilities in their systems. So the situation of users would arguably have been better if they had installed a back door as that would limit the exploit to a number of parties that are given access through SSL or other mechanisms. That would have been imperfect, but still better than the current situation: There is no way to know who has knowledge of these vulnerabilities, and what use they made of it. How that kind of information can be used in addition to the FinFisher type of software has been demonstrated by Stuxnet, the computer worm that was apparently targeted at the Iranian uranium centrifuges and was in fact capable of killing people. We now live in a world where cyber-weapons can kill. Just a couple of days ago, the death of Michael Hastings in a car crash in Los Angeles was identified as a possible cyber-weapon assassination. I have no knowledge of whether that is the case, but what I know is that it has become possible. And of course anyone sufficiently capable and motivated is generally capable of creating such a weapon – no manufacturing plants or special materials required. All of this of course is also known to all the security agencies around the world. So they are trying to increase their detection and defence. But since this is an asymmetrical threat scenario, it is hard to defend against. PRISM wasn’t motivated by an anti-democratic conspiracy Too many comments following the PRISM disclosures sounded like there was a worldwide conspiracy involving hundreds of thousands of people, including many heads of states, to undo democracy. And it seems that some people, such as US president Barack Obama, became part of the conspiracy when they came into power. To me it seems more likely they received more information and became deeply concerned about what would happen if we for instance started seeing large-scale attacks on the cars in a country. To them, PRISM probably looked like an appropriate, measured response. That is not to say I believe it is an effective countermeasure against such threats. And if Edward Snowden is to be believed, it has likely been subverted for other purposes. Considering he threw away his previous life and took substantial personal risk, and reading up on what people such as Caspar Bowden have to say, I have little reason to doubt his credibility. Given the physical and other security implications of all of the above I guess only very few people would argue that the state has no role in digital technologies. So I think governments should in fact be competent in these matters and ensure that people are safe from harm. That is part of their responsibility, after all. Just banning all the tools would put a country at a severe disadvantage to fulfil that role for its people. At the same time these tools are extremely powerful and intrusive. So what should governments be allowed to do in this pursuit, and how should they do it? Also, how do we have sufficient control to uphold the principles and liberties of our democratic societies? Also, what does all of this mean for international business and politics? These will be some questions for the upcoming articles, so stay tuned.   [Less]

Brief description of the Kolab Groupware integration with Dokuwiki. This process uses slightly modified commit 65dfbee of the roundcubemail-plugins-kolab. Kolab Download Dokuwiki plugin. Extract it to the following directory. ... [More] /usr/share/roundcubemail/plugins/ Open plugin configuration file config.inc.php and define authentication exchange secret. Edit Roundcube configuration file (main.inc.php) and add dokuwiki plugin to the $rcmail_config['plugins'] array to enable it. Dokuwiki Extract Dokuwiki to the /var/www/dokuwiki/ directory and use install.php script to enable ACL, and set superuser credentials. Provided superuser credentials will be needed when LDAP service is disabled. Define LDAP parameters in the conf/local.protected.php configuration file (replace KolabServicePassword and example.org). <?php $conf['useacl'] = 1; $conf['openregister']= 0; $conf['authtype'] = 'authldap'; $conf['auth']['ldap']['server'] = 'localhost'; $conf['auth']['ldap']['usertree'] = 'dc=example,dc=org'; $conf['auth']['ldap']['grouptree'] = 'dc=example,dc=org'; $conf['auth']['ldap']['userfilter'] = '(&(uid=%{user}))'; $conf['auth']['ldap']['groupfilter'] = '(&(objectClass=posixGroup)(uniqueMember=%{dn}))'; $conf['auth']['ldap']['mapping'] = array(); $conf['auth']['ldap']['version'] = 3; $conf['auth']['ldap']['binddn'] = 'cn=Directory Manager'; $conf['superuser'] = '@DokuwikiAdmins'; $conf['auth']['ldap']['bindpw'] = 'KolabServicePassword'; $conf['auth']['ldap']['debug'] = 0; $conf['auth']['ldap']['kolab_server'] = 'http://10.0.0.1/roundcubemail/'; $conf['auth']['ldap']['kolab_secret'] = ''; Do not forget to set kolab_server and kolab_secret. Create POSIX groups DokuwikiAdmins and DokuwikiEditors using Kolab Admin Interface. First group is for wiki administrators, second for editors. Configure ACL. # acl.auth.php # <?php exit()?> # Don't modify the lines above # # Access Control Lists # # Auto-generated by install script # Date: Mon, 24 Jun 2013 17:50:42 +0000 * @ALL 0 * @user 1 * @DokuwikiEditors 8 Anonymous users cannot access wiki. Logged in users can read articles. DokuwikiEditors group grants editor rights. DokuwikiAdmin group grants administrator rights. Enable LDAP plugin in the conf/plugins.local.php configuration file: <?php $plugins['authad'] = 0; $plugins['authldap'] = 1; $plugins['authmysql'] = 0; $plugins['authpgsql'] = 0; Replace authldap plugin (lib/plugins/authldap directory) using this modified version to enable single sign-on.   [Less]

Brief description of the Kolab Groupware integration with Tiny Tiny RSS. This process uses slightly modified commit 65dfbee of the roundcubemail-plugins-kolab. Kolab Download Tiny Tiny RSS plugin. Extract it to the following directory. ... [More] /usr/share/roundcubemail/plugins/ Open plugin configuration file config.inc.php and define authentication exchange secret. Edit Roundcube configuration file (main.inc.php) and add ttrss plugin to the $rcmail_config['plugins'] array to enable it. Tiny Tiny RSS Create new MySQL user, database , and use /var/www/ttrss directory to install Tiny Tiny RSS on the Kolab Groupware server. Perform first login and change password as you will use this account later for administration purposes. Default Tiny Tiny RSS username is admin, and password is password. LDAP authentication plugin is available here but download the modified version. This modified version use the same single sign-on mechanism as ownCloud plugin. Extract it to the /var/www/ttrss/plugins/ directory. Now you need to modify Tiny Tiny RSS configuration (config.php file). Make sure that AUTH_AUTO_CREATE is set to true Enable auth_ldap plugin. define('PLUGINS', 'auth_ldap, auth_internal, note, updater'); Define LDAP parameters (replace KolabServicePassword and example.org). define('LDAP_AUTH_SERVER_URI', 'ldap://localhost:389/'); define('LDAP_AUTH_BINDDN', 'uid=kolab-service,ou=Special Users,dc=example,dc=org'); define('LDAP_AUTH_BINDPW', 'KolabServicePassword'); define('LDAP_AUTH_BASEDN', 'ou=People,dc=example,dc=org'); define('LDAP_AUTH_ANONYMOUSBEFOREBIND', FALSE); define('LDAP_AUTH_SEARCHFILTER', '(uid=???)'); // ??? will be replaced with the entered username(escaped) at login Define Kolab Groupware URL and authentication exchange secret which needs to be the same as defined earlier in the Roundcube plugin. define('KOLAB_SERVER','http://10.0.0.1/roundcubemail/'); define('KOLAB_SECRET','<shared-secret-string>'); Additional notes To update feeds use the following crontab entry (source). */30 * * * * /bin/su www-data -c "/usr/bin/php /var/www/ttrss/update.php --feeds --quiet" Read about other configuration file options. Check out Storm theme as it fits Kolab almost perfectly.   [Less]

Quite lengthy but very straightforward description of the Kolab Groupware integration with Piwik Web Analytics. Integration process is simpler than you think as the additional application (Piwik) is hosted externally, and doesn't use single sign-on. ... [More] This process can be used to quickly integrate any other web based application as it only requires simple modifications to the already existing code. Preparations Create kolab_plugins directory and enter it. # cd # mkdir kolab_plugins # cd kolab_plugins Download 8297464 commit of the roundcubemail-plugins-kolab. I have chosen this version because it uses only simple iframe object. # wget https://git.kolab.org/roundcubemail-plugins-kolab/snapshot/roundcubemail-plugins-kolab-8297464ab4273f5662f1ce47a0c75bf602494e8a.tar.gz Extract downloaded archive, move and rename owncloud plugin to piwik, remove archive and extracted directory. # tar xfz roundcubemail-plugins-kolab-8297464ab4273f5662f1ce47a0c75bf602494e8a.tar.gz # mv roundcubemail-plugins-kolab-8297464ab4273f5662f1ce47a0c75bf602494e8a/plugins/owncloud piwik # rm roundcubemail-plugins-kolab-8297464ab4273f5662f1ce47a0c75bf602494e8a.tar.gz # rm -r roundcubemail-plugins-kolab-8297464ab4273f5662f1ce47a0c75bf602494e8a Change working directory. # cd piwik Configuration file Look at the config.inc.php.dist file. # cat config.inc.php.dist <?php // ownCloud URL $rcmail_config['owncloud_url'] = 'https://owncloud.webmail.tld'; Rename config.inc.php.dist to config.inc.php, remove comment, modify parameter name, and provide desired URL address. I will use http://blog.sleeplessbeastie.eu as an example. # mv config.inc.php.dist config.inc.php # sed -i -e "/^\//d" config.inc.php # sed -i -e "s|owncloud_url|piwik_url|" config.inc.php # sed -i -e "s|https://owncloud.webmail.tld|http://blog.sleeplessbeastie.eu|" config.inc.php Verify applied modifications. # cat config.inc.php <?php $rcmail_config['piwik_url'] = 'http://blog.sleeplessbeastie.eu'; Localization List localization files. # find localization -name *.inc | grep -v en_US localization/ru_RU.inc localization/fr_FR.inc localization/es_ES.inc localization/pl_PL.inc localization/en_US.inc localization/et_EE.inc localization/nl_NL.inc localization/ja_JP.inc localization/de_DE.inc localization/de_CH.inc Remove unnecessary localization files (everything except en_US). # find localization -name *.inc | grep -v en_US | xargs rm Look at the localization file. # find localization -name *.inc -exec cat {} \; <?php $labels = array(); $labels['owncloud'] = 'Files'; ?> Modify this file accordingly. # sed -i -e "s|owncloud|piwik|" localization/en_US.inc # sed -i -e "s|Files|Piwik|" localization/en_US.inc Verify applied modifications. # cat localization/en_US.inc <?php $labels = array(); $labels['piwik'] = 'Piwik'; ?> Plugin Rename owncloud PHP script. # mv owncloud.php piwik.php Replace every owncloud occurence with piwik. # sed -i -e "s|owncloud|piwik|g" piwik.php Remove lines from 69 to 73 as you do not want to pass username and password. $user = $_SESSION['kolab_uid']; // requires kolab_auth plugin $pass = $rcmail->decrypt($_SESSION['password']); $src = preg_replace('/^(https?:\/\/)/', '\\1' . urlencode($user) . ':' . urlencode($pass) . '@', $src); # sed -i -e "69,73d" piwik.php Do not forget to remove these lines as this is was very important. Skin Remove classic skin. # rm -r skins/classic I removed classic theme but you should keep and modify it. Rename image displayed before text link. # mv skins/larry/{cloud.png,piwik.png} Look at the style sheet. # cat skins/larry/owncloud.css /***** ownCloud plugin styles *****/ #taskbar a.button-owncloud span.button-inner { background: url(cloud.png) 5px 5px no-repeat; height: 14px; } #taskbar a.button-owncloud:hover span.button-inner, #taskbar a.button-owncloud.button-selected span.button-inner { background: url(cloud.png) 5px -16px no-repeat; height: 14px; } Rename and modify style sheet. # mv skins/larry/{owncloud.css,piwik.css} # sed -i -e "s|owncloud|piwik|g" skins/larry/piwik.css # sed -i -e "s|ownCloud|Piwik|g" skins/larry/piwik.css # sed -i -e "s|cloud.png|piwik.png|g" skins/larry/piwik.css Verify style modifications. # cat skins/larry/piwik.css /***** Piwik plugin styles *****/ #taskbar a.button-piwik span.button-inner { background: url(piwik.png) 5px 5px no-repeat; height: 14px; } #taskbar a.button-piwik:hover span.button-inner, #taskbar a.button-piwik.button-selected span.button-inner { background: url(piwik.png) 5px -16px no-repeat; height: 14px; } Look at the template. <roundcube:object name="doctype" value="html5" /> <html> <head> <title><roundcube:object name="pagetitle" /></title> <roundcube:include file="/includes/links.html" /> <link rel="stylesheet" type="text/css" href="/this/owncloud.css" /> <link rel="stylesheet" type="text/css" href="/settings.css" /> </head> <body class="owncloud noscroll"> <roundcube:include file="/includes/header.html" /> <div id="mainscreen" class="uibox" style="overflow: hidden"> <roundcube:object name="owncloudframe" /> </div> <roundcube:include file="/includes/footer.html" /> </body> </html> Rename and modify template in the same way as before. # mv skins/larry/templates/{owncloud.html,piwik.html} # sed -i -e "s|owncloud|piwik|g" skins/larry/templates/piwik.html Verify template modifications. # cat skins/larry/templates/piwik.html <roundcube:object name="doctype" value="html5" /> <html> <head> <title><roundcube:object name="pagetitle" /></title> <roundcube:include file="/includes/links.html" /> <link rel="stylesheet" type="text/css" href="/this/piwik.css" /> <link rel="stylesheet" type="text/css" href="/settings.css" /> </head> <body class="piwik noscroll"> <roundcube:include file="/includes/header.html" /> <div id="mainscreen" class="uibox" style="overflow: hidden"> <roundcube:object name="piwikframe" /> </div> <roundcube:include file="/includes/footer.html" /> </body> </html> Installation Change working directory and copy piwik plugin to the following directory. /usr/share/roundcubemail/plugins/ # cd .. # cp -r piwik /usr/share/roundcubemail/plugins/ Edit /usr/share/roundcubemail/config/main.inc.php file and add plugin to the $rcmail_config['plugins'] array to enable it. You can do it by hand or use the following command. # sed -e "/'contextmenu',/a \\\t\t\t'piwik'," /usr/share/roundcubemail/config/main.inc.php Read Piwik FAQ if you get empty response (white page). Download the source code roundcubemail_piwik.tgz   [Less]

In a previous article, I described my experiences setting up Kolab for groupware functionality on Debian Wheezy. One of the problems I encountered was that of searching for resources when creating events, and it didn’t seem possible to start typing ... [More] the name of a resource and to have the details autocompleted. Given that Kolab integrates Roundcube webmail with other services including LDAP directories, and given that Roundcube seemed happy to look up people in such directories, I suspected that fixing this problem would probably involve refining the search criteria for each search performed when a key is pressed in the participant field of the event dialogue (or in the recipient field of the compose mail screen). After some digging in the source code for the purpose of getting some familiarity with what goes on inside Roundcube, I found a guide to LDAP address books in Roundcube that mentions some of the queries one might expect to happen when autocompletion is taking place. And, sure enough, such information can be found in the /etc/roundcubemail/main.inc.php file provided by the Kolab-related Debian packages. So it then becomes a matter of specifying some other queries to permit resources to be found as well as people. My solution to the problem, which may not be the most appropriate (so I welcome corrections and comments), is to add another address book provider as follows: $rcmail_config['ldap_public'] = array( ... 'kolab_resources' => array( 'name' => 'Global Resources', ... 'base_dn' => 'ou=Resources,dc=example,dc=com', ... 'LDAP_Object_Classes' => array("top", "mailrecipient"), 'required_fields' => array("cn", "mail"), ... 'search_fields' => array('cn', 'mail'), 'sort' => array('cn', 'mail'), ... 'filter' => '(objectClass=mailrecipient)', ... 'fieldmap' => Array( // Roundcube => LDAP 'name' => 'cn', 'email:primary' => 'mail', 'email:alias' => 'alias', ), ), ... );     $rcmail_config['autocomplete_addressbooks'] = Array(             'kolab_addressbook',             'kolab_resources',         );Here, the new entry for kolab_resources augments the existing kolab_addressbook entry (not shown), and it changes the nature of the search by modifying the base_dn to refer to the “Resources” organisational unit, where Kolab puts all the resources in the LDAP store. Since resources do not seem to provide various fields that people provide, some changes are also required to indicate which fields are provided, and in the fieldmap section the name expected by Roundcube is mapped to the cn provided by the LDAP store, thus enabling the name of each resource to appear alongside the mail address by which the resource is known. With the new entry added, the autocomplete_addressbooks setting needs to be updated to include this new source of data in any future searching operations. And with that, it should be possible to specify a resource and have it autocompleted in Roundcube: Resource autocompletion in Roundcube   [Less]

I have recently had the inclination to evaluate Free Software groupware solutions in more detail, and perhaps the first that came to mind was Kolab: a long-running project that provides a range of groupware functions including e-mail, calendaring ... [More] , address books, task management, and various other functions for a fairly wide range of organisation sizes. Of course, there are plenty of Free Software groupware projects offering complete and integrated solutions as well as individual components for use with existing infrastructure; the Debian Wiki page on groupware provides a fair (but probably incomplete) overview of the more interesting projects. Installing and Configuring Kolab Intrigued by accounts that Kolab is fairly easy to install on Debian Wheezy – the latest stable release of the Debian GNU/Linux software distribution – I set out to investigate, making use of my own tools to set up a User Mode Linux environment in which I could install the software. Initially, I tried to re-use an existing virtual environment, but a quick attempt to configure the software using the setup-kolab program was not successful, and a brief excursion via the #kolab IRC channel (on freenode), indicated that I might be better off starting with a completely fresh installation of Wheezy. Although I imagine it is possible to deal with the problems I encountered – setup-kolab did not like the presence of an existing LDAP server – the easiest way to troubleshoot is to start with a known configuration and see if things can be made to work from there. Installation of Kolab 3.0 on Debian is fairly straightforward, as described both in the manual and more concisely in the blog article mentioned above (and also in older reports). The Kolab packages in Debian are set up to prefer the postfix packages to the apparent default of the exim4 packages and thus want to replace the latter. This might be a problem in some environments, and it may be possible to retain Exim for use with Kolab, but I haven’t investigated this. A somewhat undesirable feature of the currently available packages is that they are unsigned: Debian makes extensive use of package signatures to prevent tampering, and although it can be an annoyance to sign and publish packages and to publish the necessary keys for verification, hopefully Kolab will make its way into Debian as a collection of official packages once again. Some Current Pitfalls With a fresh system, setup-kolab seems fairly happy, and with the initial configuration performed it is possible to log into the administration interface, although it seems to be necessary to explicitly start the Apache server first. One strange problem with the Debian packages seems to be in the absence of a library file in the correct location, and this manifests itself in the administration interface as the absence of any way to add users. I fixed this for my system as follows: ln -s /usr/lib/i386-linux-gnu/nss/libsoftokn3.so /usr/lib/libsoftokn3.so(Unlike the message linked above describing this fix, I still use a machine with the i386 architecture, not the x86_64 architecture, and the underlying problem seems to be related to the way that libraries are now stored to permit support multiple architectures on the same computer.) I also noticed that some Kolab component, at least after some administrative tasks have been performed, tries to communicate with the IMAP server unsuccessfully but persistently. To reset their relationship, the following seemed to be required: service cyrus-imapd restartSome other complaints emerged on the console about mailbox creation, perhaps due to some resources I created, but it is possible to verify the state of the mailboxes as follows: kolab list-mailboxesI noticed that no matter which resource type I specified, the type of created resources would always be “Beamer”. But it's a Porsche! This probably doesn’t matter so much for actual resource booking, but I imagine that there’s a problem here needing to be fixed. It is possible that the Debian packages suffer from the above problems but that these problems have since been fixed in the project’s repository and in subsequent non-Debian package or distribution releases; I haven’t verified this, however. Fun With Administration Administration is never really much fun, but the administrative interface seems to provide a reasonable way of adding users and resources, populating the different information stores with user and mailbox details. The main page of the administrative interface With the packaging issues mentioned above all sorted out, users can be added in the users section: Adding a user in the administrative interface And resources can be added in the resources section: Adding a resource in the administrative interface Given that Kolab is based on conventional services like LDAP directories, IMAP mailboxes, and so on, if you needed to integrate with existing infrastructure and accommodate existing user populations, you probably wouldn’t spend much time in the administrative interface, but it is nice to see that an interface exists for quick edits to the system. What About the Users? With some users set up, one might be interested in seeing things from their perspective. Out of the box, the Debian packages provide a Roundcube webmail interface: The Kolab Roundcube login page On the inside, the interface is much like the Roundcube many people have come to know. For instance, the mail interface is more or less what you would expect. Here, the folders on the left are IMAP folders that are also available to IMAP clients, but to start with there obviously aren’t any mails to look at: The Kolab Roundcube mail interface Amongst the usual view buttons at the top of the window, featuring the mail, address book and settings, we find additional buttons for the calendar and tasks. First, the address book: The address book in Roundcube Here, it seems to pick up other users added via the administrative interface. Meanwhile, the calendar interface is probably slightly more interesting to look at because it’s something that you don’t usually get in Roundcube: The calendar in the Kolab version of Roundcube The calendar widgets seem to be rather familiar and those who do more JavaScript programming than I do will probably be able to identify the project that pioneered them. Nevertheless, they seem to behave mostly as I would expect from having used them elsewhere on other sites and services. One strange thing is the date numbering above the days in the week view (“Mon 6-10” meaning “Monday 10th June”, for example) which I imagine could be customised somewhere, although I didn’t see a setting to do exactly that. Fun With Events Given the existence of the calendar in Roundcube, and given that calendaring interests me already, I decided to make an attempt at creating a new event, inviting a participant, and requesting a resource. Dragging an area in the calendar caused the event dialogue to appear: Adding a new event in Roundcube The location field appears to be non-autocompleted free text, but it would be nice to have a menu of recognised locations or resources, and perhaps there is some kind of setting or extension to provide that. With the main details filled out, on I went to the participants tab: Finding participants for an event in Roundcube Just like the mail interface in Roundcube, the calendar also supports address lookups and offers autocompletion of names. However, I found that autocompletion didn’t take place for resources, so I ended up having to invite resources by using their full e-mail addresses (which were defined previously in the administrative interface). For example, for the “Forest” resource, I had to specify [email protected] as a participant. Maybe this is also something that should be done another way, but I didn’t manage to figure it out. Finding the availability of participants seems possible. Kolab does support the retention of free/busy information, so for those people making this information available to Kolab, their status should be visible in the user interface: Participant availability in the event dialogue In principle, it should be possible for people to exchange free/busy information via e-mail and for the recipient to record this information and use it to schedule events, but I haven’t looked into whether Kolab or Roundcube support this at their respective levels. I found that in the availability view, it is possible to change the role of each participant by clicking on the icon next to their name, and this made it possible to give a resource the appropriate role. Again, if there were a better way of choosing a resource that I missed, maybe this wouldn’t be necessary. With an event created and participants invited, Kolab manages to notify those participants, and to make things interesting I decided to configure Kontact in a KDE 4 environment (running in Debian Squeeze) to connect on behalf of the invited participant. Here is what that participant sees when they check their mail: Kontact showing an event notification message Although it is rather small in the above screenshot, Kontact shows a collection of links that allow the recipient to act on an incoming event notification. Here is a close-up: The event invitation actions in a message For Kontact to be able to do this, it appears that the kdepim-groupware package is required, and indeed this functionality supports the iTIP technology mentioned above (here, in an invitation context instead of the free/busy context discussed above). It is important to understand that the open standards underpinning this workflow do not require that everyone have a login to a common server and manipulate information on that server directly: a critical feature of the iCalendar-related standards is that people are able to schedule events collaboratively without all being part of the same monolithic organisation and/or infrastructure. It is also interesting to see that where a recipient’s e-mail program cannot handle the workflow defined by iTIP, the message includes a link to the Roundcube webmail that can be used to signal a participant’s attendance or absence. When a participant responds using one of the links provided in the message, the organiser gets a notification. Here, the Roundcube user gets to see a mail message telling them that the participant accepted the invitation: A received acceptance of an event invitation Upon pressing the update button provided, the status of the event is updated in the calendar: The updated event in the calendar Here, the organiser is shown with a crown next to his name, the participant (using Kontact) has accepted the invitation to the event, and the resource has apparently been secured. In Conclusion There are obviously plenty of other experiments that could be performed here, as well as other features that could be explored. For instance, some more evaluation of the free/busy information, how local and remote users interact with it, and how well those with non-iTIP mail clients fare with over-the-Web notification of attendance or absence might be in order. Publishing calendars for over-the-Web consumption is also apparently supported, and it might be interesting to see how well Kolab supports the general “invite people you hardly know” event-planning paradigm that the likes of Doodle have been attempting to popularise. It seems that Kolab at the very least supports basic calendar functionality in association with standards-compatible clients, and perhaps a brief investigation with Thunderbird (plus Lightning) and even more elementary mail and calendar clients might be informative. Since Kolab is Free Software, of course, the chances of resolving any shortcomings are increased for those willing and able to peruse and modify the code, and maybe I will take a closer look at that, too. As noted above, calendaring and scheduling systems are already an interest of mine. The only problem now is that there’s just so much to look at and yet so little time to do so!   [Less]