• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Question What's going on with "Kolab"?

ManuelGDot

Basic Pleskian
Hi!

I've been looking to integrate Calender Services and came across Kolab. Seems it's a premium extension, so far so good.

But now I'm confused, I came across news articles stating that Plesk is now working actively with Kolab to "provide it for every Plesk user"?

On the other hand I came across a Support Thread where it looks like "Kolab" isn't even fully supported with the current stable Plesk and the user had lots of issues getting it to work.

So what's the state with "Plesk&Kolab"?

Cheers,
Manuel.
 
Have you tried to use Kolab Plesk extension Plesk Premium Email, powered by Kolab - Plesk Extensions ?
Do you have any troubles with it?
Let's talk more specifically about the problems, if they really exist.

Please read my question again - I just want to know what's the currents status with Plesk and Kolab. Do I still need to buy it or is it included in a Plesk licence? Is it fully supported or will I have to expect issues if I install or remove it?
 
As you can see, vendor of this extension is Kolab, not Plesk. Therefore you have to forward your questions about development and support plans to Kolab.
You need to buy license for this extension. It is not included to Plesk license.
From Plesk side this extension is located in official Plesk Extension Catalog, therefore we offer this extension for our customers without any limitations.
 
As you can see, vendor of this extension is Kolab, not Plesk. Therefore you have to forward your questions about development and support plans to Kolab.
You need to buy license for this extension. It is not included to Plesk license.
From Plesk side this extension is located in official Plesk Extension Catalog, therefore we offer this extension for our customers without any limitations.

Here's why I'm asking: Plesk teams with Kolab for open source groupware
So what the article states isn't true?
 
So what would you suggest regarding this scenario:
- Install the Kolab Extension on an active production server with customer accounts already present <- do or don't?
 
I do not know the reasons why you are afraid of doing this, but in any case, it is only up to you.
 
I do not know the reasons why you are afraid of doing this, but in any case, it is only up to you.

Well "afraid" really is the right term here. I'm afraid it's gonna mess up ~100 business customer email accounts and I'll be blamed and will have to fix it.

Another thing I'm afraid of even more, is that it works initially but when I try to remove it 2 years later, it's gonna mess up everything and I won't even have a recent backup. The article I quoted states that there's no "plugin lock" to be expected but who am I to judge?
 
Coming to this topic a little late, here's what Kolab does to a given Plesk installation, to the extent that it concerns existing data for those subscriptions for which the Plesk Premium Email permission is enabled;

  • It reconfigures Dovecot to support SPECIAL-USE, and mailbox METADATA, and a Public namespace for folders to reside in, and adds the ACL plugin so users can share their folders among themselves.
  • It reconfigures 'webmail.<domain>' to point to a version of Roundcube that provides the calendar, tasks, and other such plugins, including better security features (CSRF protection would be the most visible), but only if the domain was configured to use Roundcube to begin with. Yes, we're actively engaged with Plesk to provide those kinds of things to core as well.
When the extension is removed, or a subscription is disabled, the CalDAV, CardDAV, ActiveSync, etc. services Kolab provides will obviously be rendered unavailable. However, the data will remain right where it was to begin with -- on the server's disk, included with your standard backup.

Please, if you have any more questions, remarks or concerns... don't hesitate.
 
Hi, sorry for hijacking the discussion, but in a bit of a rush and before delving into the excellent documentation Kolab provides, I haven't found a better place to ask few questions about Plesk & Kolab integration, so here it is. We're been investigating recently few options to offer our customers an exchange-like solution and Kolab is one of the options we're seriously looking into. However, the basic Plesk extension may not entirely cover all our requirements. What we want basically is to integrate Kolab with our existing mail solution, where we're running a number of Dovecot proxy servers in front of our Plesk servers, which are also running Dovecot for POP3/IMAP. The integration will basically require:
- A unique webmail login portal using a name like "webmail.hostingcompany.com" running Roundcube with Kolab.
- Users' email, calendars, contacts, tasks, notes etc. may be stored either on the Plesk server itself, or on proxy servers. So we're looking at implementing a "loose" integration with Plesk to be able to retain and further expand our proxy farm and benefit from the current load balancing and high-availability capabilities.
Is the Kolab Plesk extension capable to work in such an environment, where we'd be running a Kolab "proxy" farm with the ability to use the Kolab features interacting with the individual Plesk servers?
Thanks.
 
One IMAP related question on the kolab extension. For historical reasons, caused by migrating from Courier-IMAP to Dovecot, we're using the following configuration:

namespace inbox {
separator = .
prefix = INBOX.
inbox = yes

mailbox Archives {
auto = subscribe # autocreate, autosubscribe
special_use = \Archive
}

mailbox Drafts {
auto = subscribe # autocreate, autosubscribe
special_use = \Drafts
}

mailbox Sent {
auto = subscribe # autocreate, autosubscribe
special_use = \Sent
}

mailbox Spam {
auto = subscribe # autocreate, autosubscribe
special_use = \Junk
autoexpunge = 90d
}

mailbox Templates {
auto = subscribe # autocreate, autosubscribe
}

mailbox Trash {
auto = subscribe # autocreate, autosubscribe
special_use = \Trash
}
}

Looking at the kolab extension and at rOLDEXTPLESKbc7a79d41f25 looks like kolab requires a different namespace configuration that looks like this:
# Redefine the personal namespace
namespace inbox {
inbox = yes
prefix =
separator = .
type = private

mailbox Drafts {
auto = subscribe
special_use = \Drafts
}

mailbox Sent {
auto = subscribe
special_use = \Sent
}

mailbox "Sent Messages" {
auto = no
special_use = \Sent
}

mailbox Spam {
auto = create
special_use = \Junk
}

mailbox Trash {
auto = subscribe
special_use = \Trash
}
}

What will happen when activating the kolab config with the current IMAP mailboxes? Are the users going to start seeing folders like INBOX.Trash in their email clients?
 
Resurecting my topic again. Right now I'm test-driving Kolab on an isolated system. So far very underwhelming. There's close to zero configuration options for Kolab in Plesk. Usage of Plesk subscriptions becomes mandatory for Kolab.

But worst: The documentation. Again, close to none. When I google for this & that in relation to Kolab I basically need to scrap together pieces of information from 10 years old university servers.

After hours of configuration trial & error I'm still unable to upload more than 2MB sized files to Kolab. Sharing folders is very user-unfriendly when thinking about the actual users that will work with it. No notification of shared folders, everybody needs to dig into their own settings to make new shared folders visible.

I'm usually greeted with a CSRF-warning cause I didn't log out. That's it, really? That's the whole advantage I'll pay for more than for the actual server or Plesk itself? No integrated PGP, nothing. Even for https I had to dive into server configs.

The whole thing still could be somewhat reasonable but I haven't found out yet: So if I buy the "10 users package" what do I get? The answer remains undocumented as well. Can I give Kolab to 10 subscriptions where each subscriber can have unlimited Email accounts? Or is that 10 Email accounts? The first option might still make sense in terms of economics, the later - absolutely not.

Sorry for the bashing, but at that price I'd expect a modern, feature-rich application, at first glance though Kolab appears more like "Owncloud".
 
Back
Top