May bee the Kopano people ( @fbartels ?) would like to include it somewhere on the Kopano site.
I’m afraid that if we include it in our official documentation people will expect us to maintain such an integration as well (even if we would put an all caps disclaimer about it). I have meanwhile checked with our support staff and so far we have had zero request for FreeIPA from our customers.
But lets focus on something more positive. For the Schema and potential GUI integration I would recommend to start a small git repository. The easiest is to host such a repository at Github, but I can also provide a repository on our community Bitbucket (stash.z-hub.io). To share the news about the existence of your project we could easily include it in https://stash.z-hub.io/projects/COM/repos/projects-and-resources/browse as well.
Hello to everyone in this thread! This thread has inspired us in creating a new “Kopano Contributor Edition”. Basically you provide feedback, keep your system up to date and when you see it fit tell the world how much you like Kopano and in exchange you get a subscription that you can use for private setups without any charge.
you should be able to remove the program itself from the control panel. Removing schemas that have been once installed is a pain in any given ldap (without cleaning up all used attributes) therefore the schema will not be removed by the uninstaller.
Just to continue a bit, -in case you’re also running opendkim- these were the config changes that were updated and the selections I made:
spamassassin: local.cf -> N
iptables before.rules -> N
50unattetended-upgrades -> Y
logind.conf -> N
sysctl.conf -> Y
apache2.conf -> N
default-ssl.conf -> N
samba -> Y
moduli -> Y
sshd_config -> N
jail.conf -> Y
security2.conf -> Y
/default/opendkim -> Y (!)
opendkim.conf -> Y (!)
apache.conf -> Y (!)
The (!) means changes were needed. Opendkim is now running chrooted so change to the sockets were made. The one thing that was a bit of a headache is that you need to re-compile the systemd init script by running “/lib/opendkim/opendkim.service.generate”, otherwise all change related to the socket settings in /etc/default/opendkim and /etc/opendkim.conf were ignored.
Nightly builds are “bleeding edge”, that means you don’t necessarily improve stability, if you update regularly .
I suppose, packages built shortly following a beta-release contain more matured code than in between development-cycles. So this might be a trigger to update your packages.
Generally, if you’re dependant on a reliable setup and want to sleep well, too, I wouldn’t recommend to use these builds.
If I decide to update my installation: Do I always have to upgrade all modules to the same version?
Up to now, this wasn’t necessary. But imho there’s no guarantee that there won’t be changes requiring an update on several components.
You might watch the commits in the repositories or clone a copy of the src-tree and check current changes by git log
If you manage to build from the git-repo, you have the possibility to switch to another (more stable) branch from the repo. As stated by the Kopano-devs somewhere else, nightly builds track the master-branch.
No changes within Kopano core are required for this, could all be done within webapp because you can just define custom mapi properties. These values will not be compatible with other interfaces, like Z-Push or Outlook.
This should be possible via a WebApp plugin, but I am not the specialist to give you any concrete hints for that.
Looks like your connection to Kopano Community Forum was lost, please wait while we try to reconnect.