20
I Use This!
Activity Not Available

News

Posted over 11 years ago by vanmeeuwen
While only a warning in setup-kolab, some people set up a Kolab Groupware server with with an improper system fully qualified domain name, with all sorts of undesirable effects. I'm actually seriously considering making this warning a fatal error. ... [More] Why does a system require a proper FQDN? Is it actually required? I'll answer the second question first, since it has the shortest possible answer: No. Of course a proper FQDN is not absolutely required. But it is strongly recommended. For example, the default "localhost" and "localhost.localdomain" names you'll find in /etc/hosts (with address 127.0.0.1) are not "fully qualified domain names". Right after you install a system (unless you have a fancy network infrastructure with (dynamic) DNS and DHCP, or a prepared DNS entry for a static IP address), the only way a system knows how to refer to itself is using these names "localhost" and "localhost.localdomain". With a Kolab Groupware setup, this is somewhat problematic. Not because there's a guarantee it won't work, but because it is an insensible default, and secundary components that install alongside Kolab Groupware won't work as expected. So what is a proper FQDN? Well, it exists of at least two parts: the host's name, and a domain name. For example, if the host's name is 'kolab01', and the domain name is 'example.org', the FQDN would be 'kolab01.example.org'. Please note that the domain name itself 1) exists of the domain name you (probably) registered and the top-level domain name you registered it with - apologies to those in the know, for bastardizing the terminology, and 2) may actually be a sub-domain name, such as 'ch.kolabsys.com'. When you set a system's FQDN it is important that it exists of at least these three parts divided by a dot (.) character. Why? A domain name (for example, 'example.org') is used for three purposes: 1) its IN A is probably pointed at a webserver, so that people can navigate to http://example.org equally well as http://www.example.org, 2) its IN A is used as a fallback recipient SMTP server address should no IN MX records exist, 3) it contains the SOA and NS records (authority statements, signatures, and other things). Because of 1), the server to which the IN A for the domain name is pointing, it is unlikely (for larger deployments) that this is also the server on which the groupware deployment runs. Furthermore, it is best practice to set your MX records, possibly to the same system, but MX records nonetheless, so that you may have a level of redundancy (by supplying more than one MX record). That said, the Kolab Groupware component that is the 389 Directory server refers to itself using the configured system's FQDN. While this can work should the IN A for "example.org" never change, it is more problematic should the system only be using 'localhost' or 'localhost.localdomain' - your 389 graphical console won't be able to connect to the administrator server with that set. Furthermore, it is just bad, bad practice. A domain like 'example.org' is like a particular forest, and one of your systems is one of the trees. Unless you had a very specific deployment in mind, I'm sure you'll want to be able to refer to a single tree rather than only being able to refer to the entire forest as a whole. That said, this is not what setup-kolab is developed to handle either. It'll chop off the first part of the "FQDN", so using 'example.org' will lead the setup to conclude you're going to want to set up for domain 'org'. It'll use that domain to build you a standard root dn as well, which in this example case would become 'org'. Settings that relate to login realms, and other sorts of stuff all over the place will result in unexpected behaviour, not to say fail. [Less]
Posted over 11 years ago by grote
The Kolab Groupware Solution lets you synchronize your contacts and calenders over multiple devices and easily share them selectively with other users. It is a 100% Free Software and historically close to the KDE community, but you can also use it ... [More] with a multitude of different clients such as Thunderbird. Ever since the first alpha version of the brand new Kolab 3.0 Groupware Solution was released, I wanted to give it a try. The new features and especially the freshly skinned webclient based on Roundcube got me excited. I’m still running an old Kolab 2.2 server on Debian for personal use and hope to be able to switch to 3.0 as soon as Debian packages are ready. So far the best system to run Kolab on is CentOS, because native packages exist. Even though I have virtually no experience with CentOS, I tried a test install in a virtual machine. Read on for my experiences. Installing CentOS in VirtualBox Being an advanced user, I started to follow the quick howto from kolab.org. So at first I had to download an ISO image of CentOS from a mirror. I decided to use VirtualBox because it has a nice GUI and is fairly easy to setup. Then I created a new VM called “Kolab Server” with Redhat GNU/Linux 64bit as an operating system because that was closest to CentOS. Afterwards, I hooked in the ISO image as a virtual CD drive and booted the VM. It booted right into a graphical GNOME environment showing me a button to install CentOS to the hard drive. Pressing that button a couple of times didn’t produce any result, so I figured out what the button was actually starting and ran that command from the terminal. There I was told that there wasn’t enough RAM available to execute the graphical installer. Thankfully the terminal installer was started right away for me and I could get going. The install was quite easy. Just a few questions here and there. I decided to disable the firewall completely to not run into any trouble with that later. As soon as the installation was complete I didn’t want to work with the cumbersome VM window anymore and was looking into ways to access the VM with ssh. Turned out, I just had to configure Port Forwarding for the VM. So in VM Settings I selected “Attached to: NAT” in the “Network” tab. In “Advanced” I configured “Port Forwarding” as follows: Name | Protocol | Host IP | Host Port | Guest IP | Guest Port guestssh | TCP | | 2222 | | 22This allowed me to login with ssh from the host machine using ssh -p 2222 root@localhostInstalling and Setting Up Kolab Then I continued to follow the quick installation howto. Since the URL of the release package changed since the howto was written, I had to look up the proper URL by clicking on the provided link. The installation of Kolab itself took some time, but it went through without errors. Starting setup-kolab resulted in the following warning: WARNING: The Fully Qualified Domain Name or FQDN for this system is incorrect. Falling back to 'localdomain'.Since I had already heard about problems with incorrect domain names, I decided to take the warning seriously and abort the setup by pressing Ctrl+C. To get some more advanced help on the issue I moved over to docs.kolab.org for the extensive installation guide. It told me that the setup “requires that the Fully Qualified Domain Name (FQDN) for the system resolves back to the system”. So in /etc/sysconfig/network I added HOSTNAME=kolab.example.org and in /etc/hosts I added 10.0.2.15 kolab.example.org since 10.0.2.15 was the IP adress of the VM. Apparently, it is important not to use 127.0.0.1 here. Then I had to reboot for the hostname change to take effect. After the VM came back up, I logged into ssh and ran again: # setup-kolabThis time, it started without warnings and asked me to provide many many passwords. You can see that Kolab still takes security seriously. I’ll post the output of setup-kolab below. Please supply a password for the LDAP administrator user 'admin', used to login to the graphical console of 389 Directory server. Administrator password [ZqtSz8nIQI6f4hR]: Please supply a password for the LDAP Directory Manager user, which is the administrator user you will be using to at least initially log in to the Web Admin, and that Kolab uses to perform administrative tasks. Directory Manager password [KzHd2dVQ2o9JkXr]: Please choose the system user and group the service should use to run under. These should be existing, unprivileged, local system POSIX accounts with no shell. User [nobody]: Group [nobody]: This setup procedure plans to set up Kolab Groupware for the following domain name space. This domain name is obtained from the reverse DNS entry on your network interface. Please confirm this is the appropriate domain name space. example.org [Y/n]: n Domain name to use: kolab.example.org The standard root dn we composed for you follows. Please confirm this is the root dn you wish to use. dc=kolab,dc=example,dc=org [Y/n]: Setup is now going to set up the 389 Directory Server. This may take a little while (during which period there is no output and no progress indication). Shutting down dirsrv: kolab... [ OK ] Starting dirsrv: kolab... [ OK ] Please supply a Cyrus Administrator password. This password is used by Kolab to execute administrative tasks in Cyrus IMAP. You may also need the password yourself to troubleshoot Cyrus IMAP and/or perform other administrative tasks against Cyrus IMAP directly. Cyrus Administrator password [kplMHHzS_U3QRP2]: Please supply a Kolab Service account password. This account is used by various services such as Postfix, and Roundcube, as anonymous binds to the LDAP server will not be allowed. Kolab Service password [IWx-2tE0QoC-VcZ]: Shutting down postfix: [ OK ] Starting postfix: [ OK ] Shutting down amavisd: The amavisd daemon is apparently not running, no PID file /var/run/amavisd/amavisd.pid [FAILED] Starting amavisd: [ OK ] Stopping clamd.amavisd: [FAILED] Starting clamd.amavisd: LibClamAV Warning: ************************************************** LibClamAV Warning: *** The virus database is older than 7 days! *** LibClamAV Warning: *** Please update it as soon as possible. *** LibClamAV Warning: ************************************************** [ OK ] Stopping wallaced: [FAILED] Starting wallaced: [ OK ] Initializing MySQL database: [ OK ] Starting mysqld: [ OK ] Please supply a root password for MySQL. This password will be the administrative user for this MySQL server, and it should be kept a secret. After this setup process has completed, Kolab is going to discard and forget about this password, but you will need it for administrative tasks in MySQL. MySQL root password [gOZS47jIzy8HOXy]: Please supply a password for the MySQL user 'kolab'. This password will be used by Kolab services, such as the Web Administration Panel. MySQL kolab password [gsc5FFDJOgGGsOX]: Please supply the timezone PHP should be using. Timezone ID [UTC]: CEST Please supply a password for the MySQL user 'roundcube'. This password will be used by the Roundcube webmail interface. MySQL roundcube password [j_dvolYPbVVfT8I]: Stopping httpd: [FAILED] Starting httpd: [ OK ] Shutting down cyrus-imapd: [FAILED] Starting cyrus-imapd: [ OK ] Stopping kolab-saslauthd: [FAILED] Starting kolab-saslauthd: [ OK ] Stopping kolabd: [FAILED] Starting kolabd: [ OK ]At first I was afraid seeing these [FAILED] services, but then I realized that stopping services that haven’t been started yet will of course fail. There’s already an enhancement request for suppressing this and other unecessary output from the setup script. Feel free to work on this request. It is a simple python script, so that should be an easy exercise. Trying out Kolab So now Kolab was installed and setup. Surprised by how smoothly that went I was asking myself “What now?”. So I looked in the documentation which pointed me to first login in the web-based administration panel. Since I had no graphical environment installed on the server, I had to forward ports again, to be able to access it from the host machine. Name | Protocol | Host IP | Host Port | Guest IP | Guest Port guesthttp | TCP | | 8080 | | 80 So now I could go to http://localhost:8080/kolab-webadmin/ and login with cn=Directory Manager and the password KzHd2dVQ2o9JkXr that was supplied during the setup process. The login worked well and I could see the shiny webadmin. I was only surprised to find no way to add users, so I asked in IRC. There I was pointed to the documentation again. Since I used the quick install guide, I completely missed the section “Preparing the System”. There was a paragraph on SELinux that says “Not all components of Kolab Groupware are currently completely compatible with running under SELinux enforcing the targeted policy”. So in /etc/selinux/config I had to change SELINUX=enforcing to SELINUX=permissive. This way SELinux just prints a warning, but doesn’t enforce the policy. I again restarted VM, reloaded the webadmin page and had still no links to add users. It turned out that I just had to terminate the current webadmin session by logging out and in again, and there the link appeared. Now I created a test user and ran the following to verify that it was created successfully. # kolab list-mailboxes user/[email protected] user/test.test/[email protected] user/test.test/[email protected] user/test.test/Calendar/Personal [email protected] user/test.test/[email protected] user/test.test/[email protected] user/test.test/Contacts/Personal [email protected] user/test.test/[email protected] user/test.test/[email protected] user/test.test/[email protected] user/test.test/[email protected] user/test.test/[email protected] user/test.test/[email protected] user/test.test/[email protected] is how it looked for me. But this screenshot is taken from kolab.org. Great! It worked. Now I moved on to try the webmailer based on Roundcube by going to http://localhost:8080/roundcubemail. I was quite pleased by what I saw. It looke quite nice, a lot better than the old Roundcube skin and seemed to work flawlessly. Only when I sent a test mail to the test user, I noticed that there was a ServerError when checking for new mails. A look in /var/log/httpd/error_log indicated that I had foolishly specified the wrong timezone during setup. So I had to change it in /etc/php.ini from date.timezone=CEST to date.timezone=Europe/Berlin and restart apache with # /etc/init.d/httpd restartFrom now on everything went smoothly and I had a working Kolab server running. Overall I was quite pleased how easy and fast the installation went. Configuration also improved significantly compared to the old Kolab release in Debian. There were a few problems during the installation, but all of them were caused by mistakes on my side and by not starting with the full documentation. So if you are interested in Kolab, please give it a try and let me know about your experiences! [Less]
Posted over 11 years ago by vanmeeuwen
In our web client based on Roundcube, we have had a need to get very large LDAP directories to function as an address book. While "large" is a relatively subjective term, in terms of LDAP "large" simply means running out of time, or meeting the ... [More] look-through or size limits. Additionally, of course, PHP itself is subject to memory size and maximum execution time restrictions. We weren't the first to run into these problems, of course, but with a little help we came up with a very, very good solution. Using Virtual List View (VLV) control and Server-Side Sort (SSS) control, browsing very large address books page-by-page takes maybe a tenth of a second per page. Roundcube address book problem solved (thanks Thomas, thanks Robert!) But are they complex? VLV and SSS controls are both very complex (the former more than the latter), with configuration on the LDAP server required and client-side BER encoding magic involved. I am not a programmer, let alone traditionally educated, so to me the PHP code (or the code's capabilities, rather) resulting from this effort is simply awesome. To properly function, it requires a patch to PHP to be applied, which I've now submitted for upstream inclusion. Kolab Groupware ships its own PHP packages solely to include this patch. There's many other gotchas to take into account as well. Gotcha! To use server-side sorting, you have to create an index on the LDAP server with a single attribute containing a list of attribute names using which entries can be sorted. When using LDAP from a client, you have to specify that exact same sort order. To use Virtual List View controls, you require a successful hit on the server-side sorting (as that is the index). You also have to configure the LDAP server with a search (for which it requires a base, filter and scope). When using LDAP from a client, in addition to hitting the server-side sorting, you have to hit those three exact same search parameters as well. That may not sound so difficult... Complications with the User Interface Context However, an LDAP client like Roundcube lists and/or searches differently based on the context. One context is the address book. Typically one would browse an addtress book sorted by "Surname, Givenname" or "Givenname Surname". These one or two attributes (displayName can be put to very good use here) would then be included in the server side sorting. But then again, who sensibly browses a very large address book page by page? A 1000 entries with a page size of 40 results in 25 pages already - address book sizes I speak of when I say "large" are literally hundreds of thousands of entries. So the keyword is searching - but searching is a complex realm in and by itself. If you were allowed to search only on the attributes included in a SSS and VLV, searching is virtually useless (all puns intended). Searching would basically allow you to list VLV entries starting with the first result your search had found. You would like to search by location, phone number, department, organization, email address and other attributes. This is difficult to do efficiently, but can be done. The show-case is in what I'm sort of announcing in this blog post. After your search results are in, you would still like them sorted somehow. If you would like to know who lives in Narnia and search for it, your results should not look like so: Narnia Narnia but like so (for example): Doe, Jane Doe, John A second context is auto-complete. In it's very nature, auto-completion is always a search (and not simply a paginated list of all entries), similar to the search for people living in Narnia. You can imagine how a set of search results could need to be paginated if there were many people living in Narnia. Furthermore, in the user interface context where you use auto-complete (the compose window, the ACL entry management on folders), no address book interface pop-up is available, as only a small list with hits is displayed. The pages are much smaller, increasing the change the result set needs pagination. Naturally, auto-completion searches for a limited set of attributes - but also most likely different attributes than an address book listing. Most likely, a search for the purpose of auto-completion looks at a display name ("Doe, J. (Engineer)", perhaps), a given name ("Jane", "John"), a surname ("Doe"), any email address (mail, alias, mailalternateaddress, mailforwardingaddress attributes), etc. Imagine these searches would occur without the help of pre-sorted indexes. A million-and-one LDAP entries may need to be searched, all results would need to be obtained, the results would then need to be sorted, to then return only the first 10-15 entries. Wouldn't it be great if you could search, sort and paginate with the help of pre-sorted indexes? But... I did mention earlier, the three magic search parameters need to match the server-side VLV search configured. As it turns out you can actually specify additional search parameters, but only in a very specific way. More awesome stuff I'm announcing in this blog post. And all of this is only in Roundcube? Within the Kolab Groupware realm, we have more components that hook into LDAP and perform listings and searches. Two of them are the Kolab Web Administration Panel (or actually, its API) and Syncroton. So I've had multiple agenda's to attend to; 1) avoid needing to do actual programming for the Web Administration Panel, 2) avoid requiring Roundcube libraries with both the WAP and Syncroton and 3) further enhance our LDAP capabilities for yet even more awesome stuff. I give to you Net_LDAP3 - not yet a PHP PEAR module, because it's a work in progress, and I don't like their license requirements and I don't like their function naming conventions (camel-case, basically). My target is to integrate all of the LDAP functionallity required with Roundcube, our Kolab plugins for Roundcube, the WAP and Syncroton. I've already achieved the following milestones: Unless specifically configured, or specifically disabled, or not a supported control on the LDAP server, the Net_LDAP3 module automatically discovers available settings for VLV/SSS listings (method list_entries()) A method search_entries() with an argument for additional search parameters that automatically uses VLV/SSS configured or discovered but with the additional filter settings, Validation of the desired sorting, Automatic selection of one sorting configuration out of available sorting configurations, Allow a method login() to find a user entry before binding as the user being logged in, The execution of a registered hook to obtain or set configuration items using a routine external to Net_LDAP3, The execution of a registered hook to use for logging, Trace and debug levels Obviously there's still many things on my TODO list, which ends with patching Roundcube, the WAP and Syncroton to use this module. [Less]
Posted over 11 years ago by grote
Version 2.0.2 of the Thunderbird Extension SyncKolab was just released. It is a maintainance release fixing many bugs and is available for direct download. If you are new to SyncKolab, we have a step by step guide on how to use SyncKolab with ... [More] Thunderbird and Lightning. These bugs were fixed: #24933 Hide folders does not work. Remove periodic sync option (this is deprecated by the listener). Add close-window-when-done option to configuration dialog. #24934 message date checking on contacts removed. #24938 Fix for window to small. #24936 Fix problem with list sync. #24954 Fix problem with auto sync. #24957 Fix problem with list names with spaces. Fix problems with name in the uid (i.e. for mailing lists or irregular clients). #24959 Fix problem with multiple accounts. #24967 Add utf-8 en-/decoding when writing the sync cache files. #24986 Make status columns resizable. #24960 Fix monthly recurrence rules. [Less]
Posted over 11 years ago by vanmeeuwen
With the release of the Kolab 3.0 alpha1, we now enter a stage in the development process and release management called testing. Usually an alpha release is sort of a development snapshot, but to be honest with you we didn't change as much as you ... [More] might think, between 2.4 and 3.0. One of the things that needs testing is the upgrade of your system to Kolab 3.0, be it from Kolab 2.2, 2.3 or 2.4. I am, therefore, writing some documentation on performing that upgrade. [Less]
Posted over 11 years ago by grote
The new version of the Kolab Groupware Server is now feature complete and ready for the first alpha. Alongside with today's release of Kolab 3.0 alpha1, the Kolab web client Roundcube was released in version 0.8. The Kolab Groupware solution now ... [More] integrates better into existing user directory setups. Security as well as scalability has been improved. It is now possible to scale all functional components of Kolab separately. Also, there is a new unified command line utility for administrative tasks. This alpha version is meant for testers and early adopters and is explicitly not intended for use in production environments. Installation instructions can be found on docs.kolab.org. There are also quick installatioin instructions for the impatient. All bugs should be reported on issues.kolab.org. Thanks to native packages, Kolab 3.0 alpha can be used as a rolling release. This way, users effortlessly stay close to the latest development, do not have to upgrade to beta, rc and final releases, and receive bug fixes immediately. Once Kolab 3.0 is matured and stable, enterprise packages of certified Kolab can be obtained from Kolab Systems. Web Client Roundcube 0.8 With Kolab 3.0 Roundcube becomes the default web client for the Kolab Groupware solution. Development of this Free Software initiative is therefore funded by Kolab Systems. Contacts, Calendars and, with Kolab 3, also Tasks can be managed by Roundcube. The new 0.8 release features a brand new skin for an enhanced visual experience that should make day to day work more pleasant. Generally Roundcube was made more stable and its performance was improved. It also includes more robust session handling that fixes the accidental session timeouts of earlier versions. The LDAP address book now properly supports photos, country object classes and serialized address values. A new address book widget now simplifies the selection of recipients when composes emails. Last but not least, Roundcube's license was changed from GNU GPLv2 to GNU GPLv3 or any later version. Web Administration Panel Kolab 3.0 comes with a customizable web based administration front-end that allows management of users and groups. New in version 3.0 is the management of resources, domains and roles. New mail domains and domain aliases can easily be added and user roles such as administrators and domain maintainer can be created and assigned. It is also possible to set role- or group-based plugins and settings for the Kolab web client and to enforce access policies for the Kolab server. Furthermore, an API is provided to access all functionality of the web administration panel. This way it is easy to integrate Kolab administration tasks into existing administration front-ends. A sample API client is included that can be used by webmail providers to sign up Kolab users. Kolab Server The server components have been rewritten completely for the 3.0 release and ensure that the code-base is easier to maintain and to contribute to. For example, all dependencies of old Horde code have been removed. The Kolab daemon that ships with Kolab 3.0 has also been rewritten. It now supports mail-flow monitoring, enforces recipient policies, quota and can be extended with Python modules. These modules can handle emails on the fly and could for example add corporate footers or even do in-line translation of emails. Kolab now uses the 389 Directory Server per default, but still supports OpenLDAP. The system that shows when users are free or busy without revealing their detailed calendars has undergone a rewrite as well and benefits from a more modern code-base. The Open Standards Kolab uses to store its data are governed by the Kolab Enhancement Proposals. Over the years, several enhancements have been proposed and accepted which made an overhaul of the Kolab Format necessary. The new format saves calendar data in the xCal and Contacts data in the xCard format. It removes ambiguity and makes the Kolab format future proof and extensible for coming features. To ease transition to the new format a upgrade tool is provided. There is also a libkolab library with several language bindings that can read and write both formats. It can be used in Kolab clients to support the new format easily. Mobile Synchronisation Since version 2.3 Kolab relies on the ActiveSync protocol to connect mobile clients to its server. With Kolab 3.0 the new ActiveSync implementation Syncroton replaces the old Z-Push stack which improves performance significantly. Authentication is now harmonized with other Kolab clients and also supports credential separation. This security feature allows for different authentication credentials on mobile devices. Should a device get lost, the main credentials are not compromised. Screenshots [Less]
Posted over 11 years ago by grote
A new version of the Kolab client for Windows has just been released. The installation package can be downloaded from files.kolab.org. Even though it includes a huge amount of bugfixes and is fully usable, this Kolab client package is still named ... [More] "Rough Cut" by its maintainer Andre Heinecke, because there is still some room for more stabilization. If you want to deploy a Kolab client on Windows machines professionally, you can buy an enterprise version from Kolab Systems. They offer professional support and can assist you with deployment and configuration. If you find any bugs, please report them to bugs.kde.org and add <aheinecke at intevation dot de> to the CC list, so he will be notified. This Kolab client for Windows release will be the last one of the 4.8 series. Further development will now focus on the 4.9 branch of Kontact and will include features such as Kolab 3 support, new Google PIM data import and improved search functionality. [Less]
Posted over 11 years ago by grote
This week members of the Kolab Community met in Berlin for some very productive face to face work on the upcoming release of Kolab 3.0 alpha. Developers from ownCloud, Roundcube, KDE, Cyrus IMAP, Fedora, and of course Kolab sat together for one ... [More] week, discussed, hacked and celebrated. Employees of Kolab Systems used the opportunity to meet with several business partners and a usability expert provided some valuable input that will be used to make Kolab clients more user friendly. The Syncroton maintainer assisted Kolab developers to finish the integration of a brand new mobile synchronisation framework for Kolab 3.0. The Kolab  backend was ported to a new API, many bugs were fixed, the synchronisation performance was  significantly improved and all essential features are finished. Roundcube already being the default Web-Client for the Kolab Groupware had two developers present. They put finishing touches on the new skin that improves the look of Roundcube enormously. Also, the groupware functionality of Roundcube is now feature complete, since it is able to handle tasks. But for coming versions of Kolab, there were plenty of ideas for new exciting features. The developers of ownCloud including the maintainer and founder Frank Karlitschek came to Berlin to help to integrate ownCloud into the Kolab web client. A basic integration was completed. ownCloud can now be shipped, installed and configured alongside Kolab. They can even share the same user directory based on LDAP. There were several lively discussions on how to integrate ownCloud even more seamlessly which resulted in many ideas and tasks that will be worked on in the coming weeks after the sprint. Several minor technical problems have been solved during the sprint. These include the management of resources such as cars by Kolab. People can reserve them on a first come first serve basis. After the sprint  there is still some potential for performance improvements when resolving conflicts with thousands of resources. Another technical detail that was resolved is integration into openldap that now works as well as with the 389 Directory Server. The free/busy daemon is now feature-complete and overall configuration management. Unfortunately, the planned work on native packages for common GNU/Linux distributions did not happen, since nobody from these communities was present. We are still welcoming and supporting any packaging efforts that are developing. Overall, it was a great event. Some people met for the first time, had many beers together and got to know each other so well that future collaboration will benefit a great deal. The Kolab community would to like to especially thank KDAB for providing the office space and refreshments for the Sprint. We are all looking forward to meet each other at the next Kolab event which will hopefully happen soon. [Less]
Posted over 11 years ago by greve
If you follow our streams at Identi.ca, Twitter, Google+ or Facebook, you’ll have noticed that we pushed out the first installable Kolab 3.0 release yesterday. I lack the words that adequately describe how excited I am about this, to be honest. This ... [More] is not a full release yet, mind you, as we are just getting ready to sprint, so this is not yet feature complete – a pre-alpha, if you will. It is however nearing feature equivalence for the 2.3 series, so we are quite confident for the upcoming Kolab 3.0 release. Whatever we manage to complete during the sprint, including whatever the community manages to come up with during the sprint, will then end up in the Kolab 3.0 release. In order to make that even easier, we’ll also have a series of talks during the sprint, starting with a Kolab 3.0 walk through by Jeroen van Meeuwen, our Systems Architect, who will give you the tour de force of what has been done for Kolab 3.0. On Tuesday Christian Mollekopf will talk about libkolab which provides an API for any technology that wishes to integrate with Kolab 3.0. Never before has it been more easy to hook other technologies up with Kolab. Wednesday and Thursday will then be covered by the Kolab Systems Web Powerhouse, Thomas Brüderli and Aleksander Machniak, the original architect and author, as well as the most active contributor of the Roundcube Web Client and the new Kolab Web Client which incorporates Roundcube and adds more groupware functionality. Their talks will be about the new ActiveSync stack we have been experimenting with, and the next generation of the web client, including the new skin. With regards the new skin, Michael Krautwasser, Roundcube’s designer for many years, has provided a new set of designs for the Kolab Community Web Client and seeks comments. You can find them at https://bueroflint.box.com/s/d1b730349d9d15fbf913 https://bueroflint.box.com/s/9bade049a121ac47b320 https://bueroflint.box.com/s/49ead7309af10852ad2b https://bueroflint.box.com/s/77095416933ec022eff6 and your comments are best sent to [email protected]. So if you want to take a look, help iron out last glitches, participate in the sprint remotely or on site, here are the installation instructions for the pre-sprint pre-alpha Kolab 3.0 release. More information on the sprint is found here and of course on the Kolab Community Wiki. Hope to see you next week in Berlin! [Less]
Posted over 11 years ago by grote
The first Kolab Technology sprint is about to happen next week. Many developers will meet in Berlin to have some fun with awesome new technology. For example, three ownCloud developers will be present to work with the Kolab community on integrating ... [More] ownCloud with Kolab 3.0. Check out the sprint's wiki page for more information on topics and participants. In order to enable everybody to work on the same brand new code and to have a common platform, we are already releasing a pre-alpha version of Kolab 3.0. This version is only intented for development and should never ever be used on a production system. We also provide straight-forward and easy instructions for the installation. The presentations will start with Jeroen van Meeuwen who will give a fast-paced walk-through of Kolab 3.0, with what changed, and motivations to have changed, and how it looks/works today. Thomas Brüderli, the Roundcube maintainer and Kolab Systems employee will talk about Roundcube – The new Web Client for Kolab. He will give a short introduction into the Roundcube project and how it became a fully functional web client for the Kolab Groupware. Alexander Machniak and Lars Kneschke are going to present and work on Syncotron the new ActiveSync stack which will replace z-push in Kolab 3.0. KDE PIM developer Christian Mollekopf will talk about libkolab and client integration possibilities. His presentation titled "libkolab: Kolab made easy, everywhere" will feature a short introduction to the new xCal/xCard based Kolab Format 3.0 and the problems that are addressed with the specification, as well as an overview over the two new kolab libraries, libkolab and libkolabxml, showing what they can provide to client implementors, to make their implementation easier, while at the same time improving interoperability. Here's the current schedule of the presentations: Time Speaker Presentation Monday 10am Jeroen van Meeuwen Kolab 3.0 walk-through Tuesday 6pm Christian Mollekopf libkolab: Kolab made easy, everywhere Wednesday 6pm Alexander Machniak and Lars Kneschke Syncotron - Synchronization done right Thursday 6pm Thomas Brüderli Roundcube – The new Web Client for Kolab [Less]