Kopano & NethServer?

Feature
1

Deviating this thread out of http://community.nethserver.org/t/horde-groupware/5679:

Is there maybe some interest for Kopano in Nethserver? Since Kopano is also like in Univention and there (according to them) the most popular App in their App Store, I just wanted to check out here whether there is some interest from the community in making this happen?

If you would like to read up on Kopano, you can find everything at kopano.com - We do provide a subscription based model for anyone who want support for their environment and Kopano is (not our own words) the most popular open source groupware solution in Europe at least. But the most important aspect is: We are 100% open source, and we are included in Univention as mentioned above, and we’re also now downstream in openSUSE and also in the process of getting included in Debian and others - You can check out my blog about that here: https://kopano.com/kopano-opensuse-yes-open/

Disclaimer: Yes, I do work at Kopano and I’m just checking in here.

5 Likes
2

At least you are clear :wink:

Ns is modular then you can install several groupware, whatever it is community or company care. However ns uses dovecot as imap server and it is easy to share email between several groupware. I believe that like zarafa you have your own imap-like server…probably incompatible with others ?

It doesn’t change that kopano is a great software and i must admit, i don’t know at all

3

Sure, you can still install your own IMAP server, then you have IMAP, you can then interface IMAP via some generic IMAP client.

But that’s a bit comparing Apples with Oranges, since IMAP is email, no calendarding, notes, contacts, no web meetings, etc… Kopano is a complete communication stack, and it is in itself already very modular and only uses what it really needs for itself.

IMAP is really shipped by ourselves, indeed, but then you could argue then that we would be a dovecot replacement then, also that would not really match well, since yes, you can use Horde, to access also a Kopano backend. But that is the very beauty (I admit I’m biased ;)): You have a complete communication stack and not “just” email, and not mobile device synchronization and also for example also very very limited usage (only IMAP) if you’re ising MS Outlook as client for example. So IMAP is for us “just” a very small part, we do way more. And when it comes nowadays even to mail many (also private people) like Activesync, therefore real push-mail, and no IMAP IDLE that keeps sucking out the battery of the mobile device - So yeah. IMAP is nice, but I believe it’s just one factor out of many when it comes to todays communication requirements… Don’t you think so as well?

We do integrate with the OS, we use mysql/mariadb as MAPI property store, we store attachments in the file system. We do not (unlike other solutions in our area) ship our own MTA like postfix, we use the OS provided SSL stack, allowing you perfect integration into the OS you’re using without compromising any installed packages or libraries.

4

that’s another good point

I’d have sogo and use also roundcube and any email client with no issues

switching to another imap server means that all the imap client must be configured to work differently and onboard default imap server must be disabled… this is something prone to errors…

many of us are just home users… they need something “install, configure and forget”… and all of us need something that can be easily managed… let’s say I want to use kopano… when/if I’ll decide to remove it, everything must be usable and every email must be available (which won’t be the case)

moreover, I don’t know (so just wondering) if kopano is different from zarafa about how/where the emails are stored… but I worked (a lot) with zarafa in the past… everything was inside a big database… when you have, let’s say, 450 GB of emails, just doing the backup is an issue, because the dump of the db takes time, and during the dump the mail features can’t work (db must be locked if you want a good dump)
this is not the case when you manage hundreds of accounts, at least IMO

5

I’m happy to see you’re not complete silent and opened a new thread. :wink:
A community needs discussions about alternatives. So I appreciate you checked in and I think we should be interessted in your opinions and inputs. :slight_smile: I also have to say, that I don’t know much about kopano.

3 Likes
6

If that is what you need, go for it: As mentioned above. You are talking IMAP. For Kopano IMAP is an interface, nothing more but also nothing less.

To the “install, configure, forget”: Try it with Univention. It’s like in 5 minutes ready. I seriously believe that specifically this is not an issue.

This argument is actually EXACTLY the reason why I brought up Kopano here, since this is what our community tells us what they like. You have the ability to configure a lot if you want, but you are far away from having to do so, since sane defaults are everywhere.

Of course when you get into 100+ users installations, there we have some recommendations to tune the database slightly better (the same applies for any installation, including dovecot with caches, etc.), but Kopano runs even up to 7-digit user count installations, maybe too much to start with Nethserver at the moment. :wink:

Storage: It’s up to you. 450GB of emails end up (based on your attachment usage) in 50GB of database and 400GB of attachments, which you can store on the filesystem (default), in the DB (not recommended, even in the docs) or on S3-compatible storage like minio, openstack swift. With something like percona backup (free and open source and easy to use) we’ve made environments happen where TB’s of databases are snapshotted (and perfectly restoreable in short time) in 30 minutes rhythms.

If you do this comparison, as I said: This is mixing apples and oranges here, on multiple levels. But just for kicks:

Sogo: Web
Roundcube: Web
Kopano: Web, Desktop (Lin+Mac+Win), Mobile (Z-Push) + Office integrations (+ Add-on-features like Web Meetings, mobile device management, Outlook extension with native Activesync, Archiving and more.

Therefore: Apples vs. Oranges. You can’t simply do this with IMAP alone :wink:

  • mike
7

Hi Michael and welcome here, if I remember well @fbartels mentioned us Kopano in the past as well.
Do you provide any rpm for CentOS yet? It could be interesting give it a try. What do you mean as Trial on your site? Which license?

8

Oh and reagarding the remark with NS being highly integrated: Check out Univention what they do, they do a quite good job in that area, and there is not just us - There is Open-Xchange and many others, all as “Apps” that perfectly integrate in the system. I mean, running 2 groupwares on 1 system is quite pointless anyways, right, so where is the IMAP problem then?

9

Hi Alessio, yes, @fbartels is also a “Kopanian”. You can find the community packages here: https://download.kopano.io/community/core:/ for the core and https://download.kopano.io/community/webapp:/ for the primary web client. The RHEL packages perfectly work for CentOS as well. For the community you don’t require any license, you’re just running an unsupported version then basically and you can not use dashboard and we simply cannot provide you with anything else but community support. With a trial you would be able to use these features with a time limit - But honestly: As a community user, you don’t need that.

10

fine for me…

NS aims to be as much as upstream alligned as possible

at this point, start creating a POC of integration package which:

  • disable the default dovecot service
  • install and configure kopano to be the default imap service
  • use NS’ users provider (LDAP or AD)
  • give users an UI to work with kopano

finally, keep in mind the “remove” part… I know, you (and I can’t blame you) think “no one will uninstall kopano once installed and tested”, but you’ll be surprised how many times customers ask for a radical change… to be clear, once you remove kopano, the default imap service must be restored and the migration from kopano of all the exportable items (mail, calendar, address book) must be as easier as possible…

I worked with zarafa and I was in touch with italian official reseller… we had good time chatting about all the features… but the sensation is that, since zarafa is an exchange replacement (and kopano is a fork of it), once you adopted it you’re locked in… extracting info and data is an hassle…
finally, I clearly remember that zarafa was such an exchange replacement that the error messages were identical to M$ ones, and so quite useless for debug… :slight_smile:

regarding the tuning… I can manage 450 GB of mails with 2 hundred users without any kind of special HW (well, cpu, ram and disk are of course well sized), nor I need any special/additional sw to make a backup… I can access my server with ssh, and find a single email with easy CLI commands… it’s just a text file and, you know, in linux “everything is a file”… why should I add some additional layers/elements to the chain? (I’m making a question, I’m serious)

11

So the thing is: I personally have never used NS, but I’ll be certainly looking into it. So this thread was actually about reaching out and asking for anyone to be interested. Specifically when it comes to the part of integration it would be great to get in touch with someone at NS who does packaging here.

Regarding “remove”: You can perfectly remove Kopano without issues, but what you are asking here is quite an impossible task when it comes to the migration part, and I can give you the reasons here:

Let’s say Mail (which is the easiest): Since the data backend is not the same (see reasons above) you need to do a migration. Migration is not heavy, and we even ship scripts for that, just check out the latest Kopano 8.2. But both systems need to be up and running ->.

But: That’s also the same the other way around…?! You need to migrate you IMAP data somewhere else as well. Yes, there is Maildir, but there is also mbox, too for example. So you definitely also end up having some issues here. Especially when it comes to calendar and adressbook. How does roundcube store this data? As far as I know, roundcube also stores this in SQL. So seriously: Where’s the difference? :wink:

Zarafa was/is a MS exchange replacement. Kopano is a complete communications solution, going way beyond the traditional feature-set of Exchange. Yes, we use MAPI, that is our similarity for the core groupware part. Yes, we use MAPI error codes which are all well documented - from Microsoft AND from us. Yes, you can import PSTs with a breeze (since PST is a MAPI container format). Kopano has evolved heavily, so it might be worth having another look, we are by far not just a “replacement” anymore, just check our DeskApp for example.

Tuning: for 200 users or 450 GB mail data with Kopano you also don’t need “special” HW. Reasonable HW, sure, and AGAIN: Yes, you need higher specs than you would with a dovecot, but again: Apples and Oranges. ;). IMAP is not a complete communication solution. It’s a protocol! You also don’t need to use special SW for backup, a mysqldump is also perfectly fine. Certainly you would use that also in the case of roundcube. SSH also works with Kopano and we have a super-simple python API called python-kopano which allows you to do even more you could than with a plain RFC822 representation of you mail (and yes, reasonably only mail): https://documentation.kopano.io/kopano_python_kopano/getting_started.html

2 Likes
12

fine again

/me with a beer in an hand an popcorn in the other, will wait for an integration example :slight_smile:

thank you for your time :wink:

13

Guys, guys, guys… I have just “arrived”: another “new kid in town”!

At the moment I’m only reading the forum - trying to find my way around and to discover NethServer.

Please read carefully the words of Stefano_Zamboni “…many of us are just home users (and SOHO, I must add)… they need something “install, configure and forget”… and all of us need something that can be easily managed… let’s say I want to use kopano… when/if I’ll decide to remove it, everything must be usable and every email must be available (which won’t be the case)”. This is the “Force”!

14

I recall a rpm with smeserver-zarafa, it could be a good starting point for someone who wants to throw his gloves in the arena. We don’t have the same mind, the same languages, even the ways of life…we need a lot of differences in this world to make a great community.

Thanks @mkromer for all these enlightenments

1 Like
15

First of all: I read very carefully through what @Stefano_Zamboni wrote.

Maybe I don’t get it, but sorry, maybe you are misunderstanding but that has nothing to do with forcing someone anywhere. Not even a mail-server no matter how much you turn it is not a piece of interchangeable thing, it is an application. Let me ask this way: If you use a MySQL database, can you just with removing it and installing PostgreSQL run the data from the MySQL? No! It’s simply an application that has a certain data storage format.

As I pointed out earlier, also with Dovecot you have mbox, Maildir, CyDir, dbox and even dovecot does not support all “standard”-formats such as mailstore or mbx.

The reality is: If you have a different format, you have to do a migration. That is exactly the same case with a dovecot from another mail server for example or from a format which dovecot does not support, such as mailstore for example. There is no difference what Kopano does. We have MAPI as a storage format, and since we are the only open source MAPI backend we have this specific type of storage. Even if we wanted to: Maildir or any of the above storage formats are not capable of storing the metadata MAPI can, so yes: You have to migrate. This has nothing to do with forcing someone in a certain format, sorry.

Sure, It’s not nice you would need to do a migration, but simply: If you don’t need/want Kopano: Perfectly fine! Fortunately, we live in a great world with freedom of choice. If you don’t like Kopano? Just use the migration scripts we provide (also away from Kopano). You won’t have all the extensive feature-set then, but if you don’t need it then Kopano is maybe something you simply don’t need at all - and you still get the data you had in Kopano. Don’t get me wrong, and I’d love to live in a world with one “storage-format-to-rule-them-all”. But I believe you are asking for the impossible.

Let me give you an example: There are no contacts, notes, tasks, calendars, files in IMAP. How should you then be interfacing them with something else then? At last, let me give you this example the other way round: Please uninstall roundcube with the calendar plugin and install anything else with calendar support. I don’t know any other solution which can work with that format - Wouldn’t that also be “Forced” based on your definition?

Please realize: Kopano is not a mail-server, it’s much more. If you want a plain mail-server with nothing ontop, dovecot is CERTAINLY a better choice.

So after all as for RPMs: https://download.kopano.io/community/ - Use it if you like it, leave it if you don’t. :slight_smile:

2 Likes
16

I saw the Kopano booth at FOSDEM and I asked some information :slight_smile:
They were very kind and explained me all the features and I’m really impressed ( I didn’t even know Kopano was a fork from Zarafa ).

When I explained how NethServer works, they told me that Kopano is not easy to integrate because it has its own stack.

I’m good with Kopano using its own stuff for Active Sync, contacts, calendar etc, but I don’t like the idea to use mail implementation other than a pure mail server (like Dovecot or Cyrus). I like the UNIX philosophy: many software, each for a specific task.

We did a lot of work around Dovecot and we use many features of it, the web interface is tailored on configuring it to fit user needs.
AFAIK if you install Kopano you need to use it for configuring mail addresses and everything else related to the mail server. Am I wrong @mkromer?

Thank you Michael to share this opportunity!

7 Likes
17

@giacomo: You can use either an internal DB format which would require to create all the users, etc. by hand, yes, but the recommended way is anyways to use some LDAP as user directory, that can be literally anything that speaks LDAPv3, that includes openLDAP, AD (also Samba4 AD), eDirectory, Oracle Directory Server, like anything you can find nowadays. With LDAP you have the best integration possibilities also with other software such as the used MTA (postfix for example). As a comparison: Univention also uses their LDAP with Kopano and it works really well, so you can manage the users, groups, contacts, resources all via their web interface. We also like the UNIX philosophy, which is why we do not have one monolithic service, but instead components that all serve a specific purpose, such as spooler for sending mails to the MTA, server doing the core MAPI work, dagent for delivering mails from the MTA, monitor which takes care of quotas, etc.

8 Likes
18

Fist of all, I want to clarify that I’m not against kopano… it’s amazing, I played with the demo and it runs smooth… but…

As Giacomo said, if Kopano can’t use standard daemons (all of them), it’ll be very difficult to integrate it into NS, as it was with SME server… the fact that Uninvention does it it’s not relevant… other distro follow different approaches…

when I spoke about “user lock in”, I refer to the fact that moving from a solution to another is hard… let’s say I have a standard NS… my server dies… I have the backup but for any reason can’t build a new NS… I can extract all maildirs form the backup, restore on another server (debian, ubuntu, *BSD, $whatever running dovecot), change ownership and I’m almost done, my emails are there

in the same situation, using a solution like Kopano will make the restore harder… or, at least, will lock me in using Kopano… this is the kind of “lock” I don’t like, for the same reason I don’t like exchange or any other solution that use “proprietary” db/storage.

finally… yes… horde, roundcube, sogo and almost any other GW/email solution uses a db to store info/data… but not to store emails… I can always recover my address book or my calendar form emails (hard but possible), if I loose email but I have address book and calendar I have almost nothing in my hands…

1 Like
19

If I understood well, integrating Kopano on NethServer wouldn’t appear so hard. Who wants to study the related documentation and give it a try?

3 Likes
20

I’d say you’re wrong… And Giacomo explained why :wink: