Kolab.org Groupware Solution

There is the suggestion on the page http://trac.roundcube.net/wiki/Howto_Config/Performance to use a caching IMAP proxy. This will cache the connections to the IMAP server for each user, so that not every click in Roundcube on a message leads to the ... [More] creation of a new connection. I found these alternatives: Cyrus IMAP Murder: http://www.cyrusimap.org/mediawiki/index.php/Cyrus_Murder Nginx IMAP Proxy: http://wiki.nginx.org Perdition: http://horms.net/projects/perdition/ Squirrelmail’s IMAP Proxy: http://www.imapproxy.org/ I had a closer look at Nginx IMAP Proxy and Squirrelmail’s IMAP Proxy. Squirrelmail’s IMAPProxy This is actually the easiest solution, at least compared to Nginx IMAP Proxy. Install from EPEL with: yum install up-imapproxy I have changed the following values in /etc/imapproxy.conf: server_hostname localhost listen_port 8143 listen_address 127.0.0.1 server_port 143 force_tls yes To install the service: service imapproxy start chkconfig imapproxy on Roundcube configuration You need to change the port that Roundcube connects to, instead of port 143 now use 8143 where your Squirrelmail’s IMAP Proxy is running. In file /etc/roundcubemail/config.inc.php: $config['default_port'] = 8143; I have added the initIMAPProxy.sh script to my TBits scripts: initIMAPProxy.sh Nginx Since the configuration of the Nginx IMAP Proxy is more complicated, I have created a separate post for that: Kolab/Roundcube with Nginx IMAP Proxy on CentOS6   [Less]

For testing, it is useful to run setup-kolab in unattended mode. There might be other reasons too, eg. as part of a docker setup etc. One option is to use Puppet: Github: puppet-module-kolab. I don’t know enough about Puppet yet myself, and I have ... [More] not tried it yet. My way for an unattended setup is to patch setup-kolab in this way (see initSetupKolabPatches.sh to see the action in full context): wget https://raw.githubusercontent.com/TBits/KolabScripts/Kolab3.3/kolab/patches/setupkolab_yes_quietBug2598.patch wget https://raw.githubusercontent.com/TBits/KolabScripts/Kolab3.3/kolab/patches/setupkolab_directory_manager_pwdBug2645.patch   # different paths in debian and centOS # Debian pythonDistPackages=/usr/lib/python2.7/dist-packages if [ ! -d $pythonDistPackages ]; then # centOS6 pythonDistPackages=/usr/lib/python2.6/site-packages if [ ! -d $pythonDistPackages ]; then # centOS7 pythonDistPackages=/usr/lib/python2.7/site-packages fi fi   patch -p1 -i setupkolab_yes_quietBug2598.patch -d $pythonDistPackages/pykolab patch -p1 -i setupkolab_directory_manager_pwdBug2645.patch -d $pythonDistPackages Now you can call setup-kolab this way: echo 2 | setup-kolab --default --timezone=Europe/Brussels --directory-manager-pwd=test I need the echo 2 for the mysql options, that is a quick solution for the moment.   [Less]

One of the things that came out of the Winter 2014 KDE PIM sprint in Munich is that people felt we, as a team, needed to coordinate more effectively and more often. Bringing together people from Kolab, upstream KDE PIM, downstream packagers and even ... [More] users of PIM was fantastically productive, and everyone wanted to keep that ball rolling. One suggestion was to do regular team meetings on IRC to formulate plans and keep up with each other's progress. While the mailing list is great for ongoing developer discussion and review board is fantastic for pushing forward technical steps, coordinating ourselves as a team can really be helped with an hour or two of real time discussion every so often.  So we lined up the first meeting for yesterday, and I have to say that I was very impressed at the turn-out. In all, 12 people signed up on the meeting's scheduling Doodle and I think there were even more in attendance, some just listening in but many participating. Aleix Pol was kind enough to take notes and sent a good summary to the mailing list. The big topics we covered were the Qt5 / KDE Frameworks 5 (KF5) ports of the KDE PIM libraries, a new revision of Akonadi and a release roadmap for a Qt5/KF5 based Kontact. These are all quite important topics for both Kolab, which relies on Kontact for its desktiop client, and KDE itself, so it was good to focus on them and make some progress. And make progress we did! There will be releases of the libraries for Qt5 as frameworks coming soon. The porting effort, led largely by Laurent Montel, has done a great job to get the code to the point that such a release can be made. The kdepimutils library is nearly gone, with the useful parts finding their way to more appropriate frameworks that already exist, and kcalcore needs a bit more love ... but otherwise we're "there" and just the repository creation remains. Aleix Pol and Dan Vratil will be heading up this set of tasks, and once they are done we will be left with just the small core of libraries that rely on Akonadi. Which brings us to the next topic. A possible major revision of Akonadi is currently being prototyped. This early development is happening in a separate repository until everyone is confident that the ideas are solid and workable in practice. The goals of this effort include producing a leaner, more robust foundation for applications that would need access to PIM data (such as Kontact), one which is also easier to develop with and for. It is still early days but we hope to have enough of an implementation in place by the end of December that we can not only start talking about it  publicly in more detail, but figure out a realistic and responsible release schedule for Kontact 5. ... and that is where we ended up with the release schedule discussion: we need more information, which  we won't have until January, before we can form a realistic schedule. So that topic has been tabled until the next IRC meeting in January. The PIMsters won't be waiting until January for our next IRC meeting, however. There will be another one on the 15th of December. Dan Vratil will be organizing, so look for the announcement on the kde-pim at kde.org mailing list if you are interested in joining us.   [Less]

ProFTPD is a versatile ftp server. I recently integrated it in my Kolab 3.3 server environment, so that user access be can easily organized by the standard kolab-webadmin. The design looks as follows: Kolab users are be able to login to ProFTPD but ... [More] every user gets jailed in his own separate (physical) home directory. According to his group memberships, aditional shared folders can be displayed and accessed within this home directory. You will need proftpd with support for ldap and virtual root environments. In Debian and Ubuntu, this is achieved via module packages: proftpd-mod-ldap, proftpd-mod-vroot On other platforms you may need to compile your own proftpd. Via kolab-webadmin I created a new organizational unit FTPGroups within parent unit Groups. Within this unit, you can now add groups of type (Pure) POSIX Group. These groups are later used to restrict or permit access to certain directories or apply other custom settings per group by using the IfGroup directive of ProFTPD. Note, that you stick to sub-units of ou=Groups here, so that this unit will be recognized by the kolab-webadmin. The LDAP-record of such a group may look like this: dn: cn=ftp_test_group,ou=FTPGroups,ou=Groups,dc=domain,dc=com cn: ftp_test_group gidnumber: 1234 objectclass: top objectclass: groupofuniquenames objectclass: posixgroup uniquemember: uid=testuser,ou=People,dc=domain,dc=com To make sure that our kolab-users and groups within the sub-unit get mapped correctly to their equivalents in the ftp-server, we have to edit the directives for mod_ldap. Just start with my working sample configuration ldap.conf on pastebin, which should be included in your main proftpd configuration. Because we use the standard kolab ldap-schema, the users do neither posess a user nor group ID. Therefore, ProFTPD will fallback to the LDAPDefaultUID (example: ID of “nobody”) and LDAPDefaultGID (example: 10000). From the system side, a user with this combination of UID and GID should be allowed to read from (and maybe write to) your physical FTP directory tree. You can either add the user or group to your system and set the permissions accordingly or use the access control list (ACL). Since I use the acl-approach, the group with ID 10000 does not have to exist in /etc/group. You may install acl by executing ~# apt-get install acland mount your ftp storage device with the acl option (to be persistent add it in /etc/fstab) by executing ~# mount -o remount,defaults,noexec,rw,acl /dev/sda1 /var/ftpTo allow the access for users in our default group 10000 (for both existing and newly created files), we have to use the setfacl command. Think carefully about this. We want the users not to be able to remove one of the shared folders accidentally! ~# setfacl -m g:10000:rx /var/ftp/ ~# setfacl -d -m g:10000:rx /var/ftp/ ~# setfacl -d -Rm g:10000:rwx /var/ftp/* ~# setfacl -Rm g:10000:rwx /var/ftp/* We wanted all users to have their own home directory, which resides in /var/ftp/home/, so make sure this directory exists. To jail each user to their own home directory, change the DefaultRoot directive in your main configuration file /etc/proftpd.conf to look like DefaultRoot /var/ftp/home/%u Nonexistent home directories /var/ftp/home/username will be created as requested by ldap.conf (see above). At this point, ldap users should be able to login and will be dropped in their empty home directory. Now we have to setup the directory permissions and have shared directories linked to the home directory. To achieve this we will make extensive use of the IfGroup directive. It’s very important, that the module mod_ifsession.c is the last module to load in /etc/proftpd/modules.conf! Additionally you should have lines, which load mod_vroot.c and mod_ldap.c. Linking is very simple and works as follows: <IfGroup ftp_test_group> VRootAlias /var/ftp/share /share> </IfGroup> Very useful in terms of security is to limit the use of particular FTP-Commands to the admin group # limit login to users with valid ftp_* groups <Limit LOGIN> AllowGroup ftp_admin_group,ftp_test_group </Limit> # in general allow ftp-commands for all users <Directory /> <Limit ALL ALL FTP> AllowGroup ftp_admin_group,ftp_test_group </Limit> </Directory> # deny deletion of files (does not cover overwriting) <Directory /> <Limit DELE RMD> DenyGroup !ftp_admin_group </Limit> </Directory>I think we are done here now. Restart your ftp server by ~# service proftpd restartHere you go! For testing purposes set the log level to debug and monitor the login process. Also force SSL (mod_tls.c), because otherwise everything, even passwords, will be transferred as cleartext! If you run into trouble somewhere, just let me know. Filed under: Linux, Technik Tagged: Kolab, ProFTPd   [Less]

The last month has been a wonderful romp through the land of Kolab for me, getting better acquainted with both the server and client(s) side of things. I had expected to learn quite a bit in that time, of course, but had little idea just what it ... [More] would end up being. That is half the fun of exploration. Rather than keeping it all to myself, I thought I'd share some of the more interesting bits with you here. First up: chwala. Ch-what-a? Those of you know Polish will recognize that word immediately; it means "glory". So, first thing learned: there are fun names buried in the guts of Kolab. Collect them all! Ok, so what does it do? It's the file storage backend for the Kolab web client. You can find the code here. As with Roundcube, the web-based groupware application that ships with Kolab, it is written in PHP and is there to glue file storage to groupware application. This is responsible for the "save to cloud" and "attach from cloud" features in the webmail client, for instance, which allows you to keep your files on the server side between recipients on the same host. The files are also available over webdav, making browsing and working with files from most any modern file manager easy. The default storage system behind the API is exactly what you'd expect from Kolab: IMAP. This makes the file store essentially zero-configuration when setting up stock Kolab, and it gives the file store the same performance and access mechanisms as the other groupware data Kolab stores for you. Quite an elegant solution. However, Chwala is not limited to IMAP storage. Let's say you want comprehensive offline file synchronization or you wish to integrate it with some network attached storage system you have. No problem: Chwala has a backend API with which you can implement integration with whatever storage system you wish. In addition to the default IMAP store, Chwala also comes with a backend for Seafile which is a free software storage cloud system that has a cross-platform synchronization client. (Which happens to be written with Qt, by the way.) Seafile code can be found here. I think that's pretty spiffy, and is certainly the sort of thing that makes Kolab attractive in professional settings as a "full solution". File storage is a requirement for such environments, and making it a part of a the "bigger picture" infrastructure can help lift the mundane task of file management up into where your daily workflow already is. Chwala! p.s. A start to a file storage access system was begun in Kontact by the ever moving, every typing, ever coding Laurent Montel. It would fantastic to see this mature over time into a full featured bridge to functionality such as provided by Chwala. I've use it to access files on MyKolab, but it isn't deeply integrated with Kontact yet (or at least that I've been able to find) or have support for the "to/from cloud" features. p.p.s. I haven't yet tried Seafile myself, but have read good things about it online. If you have used it, I'd love to hear about your experiences in the comments below.   [Less]

Today we’re showing how to extend thesingle domain setup done earlier to get a truly multi domain Kolab install. You should probably reserve a couple of hours as there are quite some changes to do and not everything totally trivial. Also, if you’ve ... [More] not read the blog about single domain setup, now is a good time First of all, you can find the official documentation here. It’s probably a good idea to read it as well. We start with the easy parts and end with postfix, which needs the most changes. At the very end there are a couple of things that may or may not be issues you should be aware of. Change Amavisd We tell amavisd to accept all domains. vi /etc/amavisd/amavisd.conf # Replace that line @local_domains_maps = ( [".$mydomain"] ); # With this line $local_domains_re = new_RE( qr'.*' );Change Cyrus IMAPD Tell the IMAP server how to find our other domains. Add the following to the bottom of /etc/imapd.conf ldap_domain_base_dn: cn=kolab,cn=config ldap_domain_filter: (&(objectclass=domainrelatedobject)(associateddomain=%s)) ldap_domain_name_attribute: associatedDomain ldap_domain_scope: sub ldap_domain_result_attribute: inetdomainbasednChange Roundcube (webmail) Basically you need to change the base_dn at several places. The placeholder ‘%dc’ is replaced during run-time with the real domain the user belongs to. To save me some typing I’m pasting the diff output produced by git here. So it looks more than it actually is… diff --git a/roundcubemail/password.inc.php b/roundcubemail/password.inc.php index c3d449c..eafc8e5 100644 --- a/roundcubemail/password.inc.php +++ b/roundcubemail/password.inc.php @@ -45,7 +45,7 @@      // LDAP base name (root directory)      // Exemple: 'dc=exemple,dc=com' -    $config['password_ldap_basedn'] = 'ou=People,dc=skolar,dc=de'; +    $config['password_ldap_basedn'] = 'ou=People,%dc';      // LDAP connection method      // There is two connection method for changing a user's LDAP password. @@ -99,7 +99,7 @@      // If password_ldap_searchDN is set, the base to search in using the filter below.      // Note that you should comment out the default password_ldap_userDN_mask setting      // for this to take effect. -    $config['password_ldap_search_base'] = 'ou=People,dc=skolar,dc=de'; +    $config['password_ldap_search_base'] = 'ou=People,%dc';      // LDAP search filter      // If password_ldap_searchDN is set, the filter to use whendiff --git a/roundcubemail/calendar.inc.php b/roundcubemail/calendar.inc.php index 98be7b9..8f98f8a 100644 --- a/roundcubemail/calendar.inc.php +++ b/roundcubemail/calendar.inc.php @@ -22,11 +22,11 @@              'hosts'                 => 'localhost',              'port'                  => 389,              'use_tls'               => false, -            'base_dn'               => 'ou=Resources,dc=skolar,dc=de', +            'base_dn'               => 'ou=Resources,%dc',              'user_specific'         => true,              'bind_dn'               => '%dn',              'bind_pass'             => '', -            'search_base_dn'        => 'ou=People,dc=skolar,dc=de', +            'search_base_dn'        => 'ou=People,%dc',              'search_bind_dn'        => 'uid=kolab-service,ou=Special Users,dc=skolar,dc=de',              'search_bind_pw'        => 'xUlA7PzBZnRaYV4',              'search_filter'         => '(&(objectClass=inetOrgPerson)(mail=%fu))',diff --git a/roundcubemail/config.inc.php b/roundcubemail/config.inc.php index bfbfba3..60dc0b2 100644 --- a/roundcubemail/config.inc.php +++ b/roundcubemail/config.inc.php @@ -6,7 +6,7 @@      $config['session_domain'] = '';      $config['des_key'] = "FMlzG7LeqiUSOSK2T8xKQTHR";      $config['use_secure_urls'] = true;      $config['assets_path'] = 'assets/'; @@ -154,11 +154,11 @@                      'hosts'                     => Array('localhost'),                      'port'                      => 389,                      'use_tls'                   => false, -                    'base_dn'                   => 'ou=People,dc=skolar,dc=de', +                    'base_dn'                   => 'ou=People,%dc',                      'user_specific'             => true,                      'bind_dn'                   => '%dn',                      'bind_pass'                 => '', -                    'search_base_dn'            => 'ou=People,dc=skolar,dc=de', +                    'search_base_dn'            => 'ou=People,%dc',                      'search_bind_dn'            => 'uid=kolab-service,ou=Special Users,dc=skolar,                      'search_bind_pw'            => 'xUlA7PzBZnRaYV4',                      'search_filter'             => '(&(objectClass=inetOrgPerson)(mail=%fu))', @@ -196,7 +196,7 @@                              'photo'             => 'jpegphoto'                          ),                      'groups'                    => Array( -                            'base_dn'           => 'ou=Groups,dc=skolar,dc=de', +                            'base_dn'           => 'ou=Groups,%dc',                              'filter'            => '(&' . '(|(objectclass=groupofuniquenames)(obj                              'object_classes'    => Array("top", "groupOfUniqueNames"),                              'member_attr'       => 'uniqueMember',diff --git a/roundcubemail/kolab_auth.inc.php b/roundcubemail/kolab_auth.inc.php index 9fb5335..8eff518 100644 --- a/roundcubemail/kolab_auth.inc.php +++ b/roundcubemail/kolab_auth.inc.php @@ -8,7 +8,7 @@          'port'                      => 389,          'use_tls'                   => false,          'user_specific'             => false, -        'base_dn'                   => 'ou=People,dc=skolar,dc=de', +        'base_dn'                   => 'ou=People,%dc',          'bind_dn'                   => 'uid=kolab-service,ou=Special Users,dc=skolar,dc=de',          'bind_pass'                 => 'xUlA7PzBZnRaYV4',          'writable'                  => false, @@ -26,11 +26,14 @@          'sizelimit'                 => '0',          'timelimit'                 => '0',          'groups'                    => Array( -                'base_dn'           => 'ou=Groups,dc=skolar,dc=de', +                'base_dn'           => 'ou=Groups,%dc',                  'filter'            => '(|(objectclass=groupofuniquenames)(objectclass=groupofurl                  'object_classes'    => Array('top', 'groupOfUniqueNames'),                  'member_attr'       => 'uniqueMember',              ), +        'domain_base_dn'           => 'cn=kolab,cn=config', +        'domain_filter'            => '(&(objectclass=domainrelatedobject)(associateddomain=%s))' +        'domain_name_attr'         => 'associateddomain',      );Change Postfix Now this is actually the hardest part that requires the most changes. Initially I thought there would be a way around that, but it looks like it is currently really needed. First we apply a couple of changes that allows us to have multiple domains besides our management domain (the domain we used to install Kolab). However those changes will not support domains having aliases. E.g. having the domain kodira.de with an alias of tourschall.com. To get domains with working aliases, we need to do even more. Postfix Part 1 (basics) Please follow the instructions given in the official documentation here. I don’t really see how I could write that part better or more compact. Do all the changes for: mydestination, local_recipient_maps, virtual_alias_maps and transport_maps. Now, if you don’t need aliases, you’re basically done and you can skip the next section. Postfix Part 2 (alias domains) For each domain that should support alias domains we need to add 4 files. We’re doing this based on the following example. Domain: kodira.de Alias: tourschall.com First create the directory /etc/postfix/ldap/kodira.de (name of the real domain) In that directory create the following 4 files, but do not just copy&past them. You have to adjust them to your setup. # local_recipient_maps.cf # Adjust domain, bind_dn, bind_pw server_host = localhost server_port = 389 version = 3 search_base = cn=kolab,cn=config scope = sub domain = ldap:/etc/postfix/ldap/kodira.de/mydestination.cf bind_dn = uid=kolab-service,ou=Special Users,dc=skolar,dc=de bind_pw = XXX query_filter = (&(|(mail=%s)(alias=%s))(|(objectclass=kolabinetorgperson)(|(objectclass=kolabgroupofuniquenames)(objectclass=kolabgroupofurls))(|(|(objectclass=groupofuniquenames)(objectclass=groupofurls))(objectclass=kolabsharedfolder))(objectclass=kolabsharedfolder))) result_attribute = mail# mydestination.cf # Adjust bind_dn, bind_pw, query_filter server_host = localhost server_port = 389 version = 3 search_base = cn=kolab,cn=config scope = sub bind_dn = uid=kolab-service,ou=Special Users,dc=skolar,dc=de bind_pw = XXX query_filter = (&(associatedDomain=%s)(associatedDomain=kodira.de)) result_attribute = associateddomain# transport_maps.cf # Adjust domain, bind_dn, bind_pw server_host = localhost server_port = 389 version = 3 search_base = cn=kolab,cn=config scope = sub domain = ldap:/etc/postfix/ldap/kodira.de/mydestination.cf bind_dn = uid=kolab-service,ou=Special Users,dc=skolar,dc=de bind_pw = XXX query_filter = (&(|(mailAlternateAddress=%s)(alias=%s)(mail=%s))(objectclass=kolabinetorgperson)) result_attribute = mail result_format = lmtp:unix:/var/lib/imap/socket/lmtp# virtual_alias_maps.cf # Adjust search_base, domain, bind_dn, bind_pw server_host = localhost server_port = 389 version = 3 search_base = dc=kodira,dc=de scope = sub domain = ldap:/etc/postfix/ldap/kodira.de/mydestination.cf bind_dn = uid=kolab-service,ou=Special Users,dc=skolar,dc=de bind_pw = XXX query_filter = (&(|(mail=%s)(alias=%s))(objectclass=kolabinetorgperson)) result_attribute = mailAlmost done, but don’t forget to reference those files from /etc/postfix/main.cf. The bad news is: you have to add and adjust those 4 files for each domain which should support aliases. But the good news is: once configured you can use as many aliases for that domain as you want. No need to change config files for that. Postfix Part 3 (finishing up) Restart all services or just reboot the machine. Most things should work now, but there are a couple of points you still might need to take care about. In our main.cf there have been references to some catchall maps that we do not use and that do not exist on the file system. Therefore postfix stopped looking at the rest of that maps. We simply deleted the catchall references from main.cf and got rid of that problem. In our setup we had an issue with a domain having an alias with more then two parts. E.g. mail.kodira.de. As we don’t need addresses in the form of [email protected] we removed this alias and thus solved the problem. Create domains and users using WAP Now you should be able to use the ‘Kolab Web Administration Panel’ (WAP) to create domains and users. Go to http://<yourserver>/kolab-webadmin Login as ‘cn=Directory Manager’ Go to ‘Domains’ and add a domain (simply giving it a name is enough) If you want add an alias to this domain by clicking the ‘+’ sign Logout Login again as ‘cn=Directory Manager’ In the top right corner you should be able to select your newly created domain. Select it. Go to ‘Users’ and add a user to your new domain If you want, give the user the role ‘kolab-admin’. If you do, that user is able to log into WAP and to administrate that domain. For that login you should not use LDAP notation, but simply [email protected]. Now maybe create a couple of test users on various domains and try to send some mails back and forth. It should work. If not have a look at those log files: /var/log/maillog /var/log/dirsrv/slapd-mail/access Also do a grep for ‘kodira’, ‘tourschall’, ‘example’ in /etc/ to make sure you didn’t accidentally forgot to change some example configuration. Last but not least, think about putting /etc/ into a git repository – that will help you to review and restore changes you’ve made. Good luck and have fun The post Kolab 3.3 Multi-Domain Setup on CentOS 7 appeared first on Kodira.   [Less]

After a lot of reading and some trial-and-error, I’ve figured out a way to reproducible install Kolab 3.3 on CentOS 7 with multi-domain support. Most information can be found in the official documentation, however some parts are not that easy to ... [More] understand for a Kolab noob. I won’t go into too much details here, so it will be mostly a step-by-step thing without a lot of explanation. You really should not use this document as your only source of information. At least read through the official documentation as well. Also you should feel confident with Linux admin stuff – otherwise Kolab might not be the best choice as it is not an of-the-shelf solution. In this document we will use the following hosts and domains. Replace them with your own. Hostname: mail.skolar.de Management domain: skolar.de Primary hosted domain: kodira.de Alias for primary hosted domain: tourschall.com We could go on with a secondary hosted domain, but works exactly like the primary hosted domain, so we won’t go there… Let’s start with a fresh minimal CentOS 7 install where you are root. First we disable SE-Linux and the firewall. You should re-enable that later, but for now we don’t won’t both to get into our way: # Check status of SE-Linux sestatus # Temporarily disable it setenforce 0 # Stop firewall systemctl stop firewalld # Disable firewall (dont't start on next boot) systemctl disable firewalldTo permanently disable SE-Linux edit /etc/selinux/config (I recommend you do this now) Set a valid host name (needs to be resolvable via DNS) echo "mail.skolar.de" > /etc/hostnameAdd Kolab repositories and GPG keys rpm -Uhv http://ftp.uma.es/mirror/epel/beta/7/x86_64/epel-release-7-1.noarch.rpm cd /etc/yum.repos.d/ wget http://obs.kolabsys.com/repositories/Kolab:/3.3/CentOS_7/Kolab:3.3.repo wget http://obs.kolabsys.com/repositories/Kolab:/3.3:/Updates/CentOS_7/Kolab:3.3:Updates.repo gpg --search [email protected] # Do it again, for me it always just worked the second time gpg --search [email protected] gpg --export --armor [email protected] > devel.asc rpm --import devel.asc rm devel.ascInstall Kolab (including dependencies) yum install kolabThe next command will start the various services like postfix and apache and should also start MariaDB (which is a replacement for MySQL). Due to bug #3877 it won’t, so we have to start MariaDB manually. systemctl enable mariadb systemctl start mariadbNow start the Kolab setup process. It will ask you many password, most of them you can just leave as they are, but pay attention to the password for “Directory Manager”. Either remember the one setup generated or type in your own. You’ll need that password later on quite often. setup-kolabBesides the passwords the right answers for me have been: Domain -> skolar.de What MySQL server are we setting up? -> 2: New MySql server Timezone -> Europe/BerlinNow might be a good time to reboot and see if all the services are starting up successfully. If you do, please make sure SE-Linux is turned off permanently. Great, you should now be able to login to the web admin. The URL and the credentials are as follows: http://<yourserver>/kolab-webadmin User: cn=Directory Manager Password: The password used in setup-kolabYou should be able to create a new Kolab user and log into webmail using that new user. But because of bug #3565 you’re incoming mail is not properly scanned. Do the following to resolve that issue: vi /etc/amavisd/amavisd.conf # Change that line \&ask_daemon, ["CONTSCAN {}\n", "/var/spool/amavisd/clamd.sock"], # To look like this \&ask_daemon, ["CONTSCAN {}\n", "/var/run/clamd.amavisd/clamd.sock"], # Save, close and restart amavisd systemctl restart amavisdThis should be all for a single-domain install. You should be able to send and receive mail using the web frontend or dedicated IMAP clients. That’s all for part 1. Have a look at part 2 where we’re extending this setup to support multiple domains. The post Kolab 3.3 Single-Domain Setup on CentOS 7 appeared first on Kodira.   [Less]

We’re proud to announce that the beta release of the next major version 1.1 of Roundcube webmail is now available for download and testing. With this milestone we introduce a bunch of new features and some clean-up with the 3rd party libraries ... [More] Roundcube uses: Allow searching across multiple folders Improved support for screen readers and assistive technology using WCAG 2.0 and WAI ARIA standards Support images in HTML signatures (copy & paste) Added namespace filter and folder searching in folder manager New config option to disable UI elements/actions Stronger password encryption using OpenSSL Support for the IMAP SPECIAL-USE extension Support for Oracle databases Moved 3rd party libs to vendor directory, managed by Composer And of course plenty of small improvements and bug fixes. IMPORTANT: with this version, we dropped support for PHP < 5.3.7 and Internet Explorer < 9. IE7/IE8 support can be restored by enabling the legacy_browser plugin. See the complete Changelog at trac.roundcube.net/wiki/Changelog and download the new packages from roundcube.net/download. Please note that this is a beta release and we recommend to test it on a separate environment. And don’t forget to backup your data before installing it.   [Less]

Recently, I noticed "Failed to save changes" error when tried to move events between distinct calendars. After a short investigation I found that this bug is already fixed, but not packaged for an easy upgrade, so I will shortly describe how to apply ... [More] fix for Debian Wheezy and Kolab 3.3. The above-mentioned bug is already fixed in roundcubemail-plugins-kolab repository. You can jump directly to the a3d5f717 commit and read details. Quick Remedy We need to replace calendar, and libkolab plugins. Download code from already fixed roundcubemail-plugins-kolab repository to /tmp temporary directory. # cd /tmp # wget http://git.kolab.org/roundcubemail-plugins-kolab/snapshot/roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz Rename mentioned roundcubemail plugins directories that will be replaced in next step. # mv /usr/share/roundcubemail/plugins/{calendar,calendar.before_fix} # mv /usr/share/roundcubemail/plugins/{libkolab,libkolab.before_fix} Extract both plugins from downloaded archive. # tar xvfz roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545/plugins/{calendar,libkolab} --strip-components 2 Install and configure plugins. # mv {calendar,libkolab} /usr/share/roundcubemail/plugins/ # ln -s /etc/roundcubemail/calendar.inc.php /usr/share/roundcubemail/plugins/calendar/config.inc.php # ln -s /etc/roundcubemail/libkolab.inc.php /usr/share/roundcubemail/plugins/libkolab/config.inc.php Remove downloaded archive. # rm roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz Simple and easy.   [Less]

Recently, I noticed "Failed to save changes" error when tried to move events between distinct calendars. After a short investigation I found that this bug is already fixed, but not packaged for an easy upgrade, so I will shortly describe how to apply ... [More] fix for Debian Wheezy and Kolab 3.3. The above-mentioned bug is already fixed in roundcubemail-plugins-kolab repository. You can jump directly to the a3d5f717 commit and read details. Quick Remedy We need to replace calendar, and libkolab plugins. Download code from already fixed roundcubemail-plugins-kolab repository to /tmp temporary directory. # cd /tmp # wget http://git.kolab.org/roundcubemail-plugins-kolab/snapshot/roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz Rename mentioned roundcubemail plugins directories that will be replaced in next step. # mv /usr/share/roundcubemail/plugins/{calendar,calendar.before_fix} # mv /usr/share/roundcubemail/plugins/{libkolab,libkolab.before_fix} Extract both plugins from downloaded archive. # tar xvfz roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545/plugins/{calendar,libkolab} --strip-components 2 Install and configure plugins. # mv {calendar,libkolab} /usr/share/roundcubemail/plugins/ # ln -s /etc/roundcubemail/calendar.inc.php /usr/share/roundcubemail/plugins/calendar/config.inc.php # ln -s /etc/roundcubemail/libkolab.inc.php /usr/share/roundcubemail/plugins/libkolab/config.inc.php Remove downloaded archive. # rm roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz Simple and easy.   [Less]