Kopano menu item in Users

[BORNXenon]

Hi,

We have just completed a migration to Office365 and I am now in the process of decommissioning our Kopano server which so far has gone without incident, however, I still have the Kopano menu item left over in the Users module and also several entries left over in LDAP which I would like to remove.

Can anyone give me a heads up on how to do this?

Thanks

Chris

[fbartels]

hi @BORNXenon,

without having tested this I would expect that these modules are removed from your system after you have removed the app and all integration packages.

[BORNXenon]

Hi @fbartels,
I also would have expected this, but it appears not to have happenend.

What I have done:

• Uninstalled the Kopano Zpush, Kopano WebApp and Kopano Core apps, in that order

• Shutdown the mail server

• Removed the mail server from the domain

• Uninstalled zarafa4ucs-lib, zarafa4ucs-schema and zarafa4ucs-udm from both domain controllers via Package Management

• Rebooted both domain controllers

• Two packages (can’t remember which ones) were still listed in Package Management albeit marked as ‘not installed’ so with reference to this post I removed them using ‘univention-remove’ and ‘apt purge’

Everything appears to be working and there are no issues on the DC’s when I run the System Diagnostics, but I still have these errant LDAP entries and more annoying, the redundant Kopano menu item in Users.

There is still a schema file at the following location:

/var/lib/univention-ldap/local-schema/kopano4ucs.schema

I have renamed it hoping it could be safely deleted, but slapschema reports a config file error after that, so I have put it back for now!!

Thanks

Chris

[fbartels]

Uninstalled zarafa4ucs-lib, zarafa4ucs-schema and zarafa4ucs-udm from both domain controllers via Package Management

Are we talking about kopano or zarafa?

There is still a schema file at the following location:

/var/lib/univention-ldap/local-schema/kopano4ucs.schema

I have renamed it hoping it could be safely deleted, but slapschema reports a config file error after that, so I have put it back for now!!

yes, as long as you still have objects in your ldap that still make use of attributes or objectclasses defined in a schema it is not a good idea to remove the schema.

[BORNXenon]

Are we talking about kopano or zarafa?

Sorry, Kopano. That line should read:

Uninstalled kopano4ucs-lib, kopano4ucs-schema and kopano4ucs-udm from both domain controllers via Package Management

yes, as long as you still have objects in your ldap that still make use of attributes or objectclasses defined in a schema it is not a good idea to remove the schema.

Any idea how I find out what is still using the attributes / objectclasses?

[fbartels]

Any idea how I find out what is still using the attributes / objectclasses?

you could just execute univention-ldapsearch and then examine its output. I would keep the schema in there, its a lot of work to cleanly remove a once installed schema with very small benefits.

In case of the still present udm modules I also looked at the the linked thread and that also suggests that removing all integration packages will remove these modules.

If you still have a kopano subscription I would suggest to get in contact with our support so they can have a deeper look into this.

[BORNXenon]

you could just execute univention-ldapsearch and then examine its output. I would keep the schema in there, its a lot of work to cleanly remove a once installed schema with very small benefits.

I understand, and I’m not too bothered about the schema (it messes with my OCD a bit, but I can live with it! ), it’s more the udm module, I assumed that there was an ldap entry stopping it from being removed.

All integration packages are removed as far as I can tell, yet the udm persists.

If you still have a kopano subscription I would suggest to get in contact with our support so they can have a deeper look into this.

Unfortunately, I never had the subscription, I was running the community version.

[fbartels]

• now is paying someone else
• never paid for Kopano

unfortunately I just lost all my motivation to help you

[BORNXenon]

• now is paying someone else
• never paid for Kopano

unfortunately I just lost all my motivation to help you

Forgive me for saying this, but I find that comment a bit on the rude side, regardless of the winking emoji.
True, I didn’t pay for a Kopano subscription, but if you are going to release a ‘free community version’, you have to expect that some people are not going to pay for it, especially when they only have 4 users.

I understand that you are not ‘getting paid’ when looking into fixing issues with the community version, but the community version cannot be that far removed from the paid for version, your motivation to help should be based on making your product better by understanding what went wrong and why so that it can feed back into the version that you are getting paid for.

I actually didn’t expect a reply from anyone at Kopano in the first place as this appears to be an LDAP issue.
Thank you for the help you have provided, I think it has pointed me in the right direction. If anyone is interested, I appear to have both an orphaned User and an orphaned Contact that I cannot see either through the Users or the LDAP udms but they do showup when running univention-ldapsearch from the commandline. Presumably they are stopping me from removing the last remnants of Kopano.

[fbartels]

community version cannot be that far removed from the paid for version

actually the integration packages are the same, as with the paid edition you only get updated kopano packages.

Anyways looking into this requires setting up a system and reproducing the issue (which can only be experienced when removing the software again).

I actually didn’t expect a reply from anyone at Kopano in the first place as this appears to be an LDAP issue.

Well that is the schema, not the udm modules.

[Moritz_Bunkus]

There’s an official knowledge base entry that deals with removing LDAP schema extensions and getting rid of the attributes provided by those extensions:

Remove LDAP schema extensions

Abstract Several apps include their own LDAP schema extensions. They are automatically registered with the UCS LDAP servers on installation. On de-installation they are not removed automatically. They can be only removed if no LDAP objects use definitions from the schema extensions any longer. Warning The following procedure should be done by experienced administrators only. An error may severely damage your domain. The procedure should be performed in a test environment before working in the p…

[BORNXenon]

Anyways looking into this requires setting up a system and reproducing the issue (which can only be experienced when removing the software again).

I’ve actually reinstalled Kopano and the orphaned contact appeared, I have deleted it, I have also set each Users Kopano Account field to None and have repeated the uniinstallation. Although the Contact has now gone and I can now delete the kopano > contacts LDAP entry which I couldn’t before, ldapsearch is still telling me I have kopano accounts and the Kopano udm is still there. I am currently reinstalling Kopano again to try clearing the Kopano Account field completely to see if that finally kills off the orphaned kopano user object classes.

There’s an official knowledge base entry that deals with removing LDAP schema extensions and getting rid of the attributes provided by those extensions:

Thanks, I had seen that post but as it was 4 years old wasn’t sure if it was still relevant. I’ll give it a go if the third uninstallation doesn’t give the desired results.

[fbartels]

I’ve actually reinstalled Kopano and the orphaned contact appeared

weren’t you talking about the udm modules before? I am confused…

[BORNXenon]

I’ve actually reinstalled Kopano and the orphaned contact appeared

weren’t you talking about the udm modules before? I am confused…

I may be getting confused with the terminology, but, it is he Kopano menu item in the Users module that I wish to get rid of and if possible, the Kopano LDAP entries. When running the univention-ldapsearch command, it told me that I had a Kopano contact that I couldn’t see in the Contacts module, see earlier post…

Thank you for the help you have provided, I think it has pointed me in the right direction. If anyone is interested, I appear to have both an orphaned User and an orphaned Contact that I cannot see either through the Users or the LDAP udms but they do showup when running univention-ldapsearch from the commandline. Presumably they are stopping me from removing the last remnants of Kopano.

I thought that maybe that contact might be stopping the Kopano menu item from being removed.
I re-installed Kopano and that Contact magically reappeared, I removed it and for good measure went through all user accounts setting the Kopano Role field to None. It appears however that setting the field to ‘None’ isn’t enough to set the kopanoAccount LDAP entry for the user to 0, it must be blanked completely or kopanoAccount stays set at ‘1’.

[Moritz_Bunkus]

Hey,

Thanks, I had seen that post but as it was 4 years old wasn’t sure if it was still relevant. I’ll give it a go if the third uninstallation doesn’t give the desired results.

It may be old, but it is still very much relevant. There’s no automated way for removing those attributes & object classes. The steps described in the article still apply.

m.

[BORNXenon]

Thanks Moritz, I can’t get the ldapsearch-wrapper command to work, I get the following error:

sed: -e expression #1, char 59: unterminated `s’ command

[Moritz_Bunkus]

Hmm, yeah, it probably got mangled during the migration from the old forum. I’ve fixed the whole command (including the ldapsearch-wrapper line).

[BORNXenon]

Hmmm, still getting an error (Broken pipe), maybe because the schema package is no longer installed.

Anyway, I have for the most part acheived my goal which is get rid of the Kopano menu in the Users module.
For anyone who comes up on this issue in the future, here is what I did, this may or may not work in every circumstance and I take no responsibility for it breaking your system:

• Go through each user account and ensure that the ‘Kopano Role’ field is empty

• Remove any Kopano Contacts and Kopano Groups

• Run ‘univention-ldapsearch | grep kopano’ at the CLI and make sure that there are no users with kopanoAccount set to 1, likewise ensure there are no groups and contacts in the results

• Uninstall Kopano from the Kopano server in the following order: Kopano Z-push, Kopano Web App, Kopano Core

• On the DCs, uninstall kopano4ucs-lib, kopano4ucs-schema and kopano4ucs-udm via Package Management

• Run ‘apt purge kopano4ucs-lib’, ‘apt purge kopano4ucs-schema’ and ‘apt purge kopano4ucs-udm’ at the CLI

• Reboot the DCs

• In the LDAP module remove the following entries:
  domain > kopano > contacts
  domain > kopano > non-active
  domain > kopano
  domain > Kopano Address Lists
  domain > univention > apps > kopano
  domain > univention > apps > z-push-kopano
  domain > univention > custom attributes > kopano

After carrying out the above, I am still left with some errant kopano entries in the univention-ldapsearch and I am unable to remove the /var/lib/univention-ldap/local-schema/kopano4ucs.schema file as ‘slapschema’ throws a config error, however, the Kopano menu items in the Users and Groups modules are now no longer.

The left over kopano attributes / objectClasses appear to be tied to the user accounts and (on my system at least) are:

sudo univention-ldapsearch | grep kopano
kopanoSharedStoreOnly: 0
objectClass: kopano-user
kopanoAccount: 0
kopanoAdmin: 0
kopanoAdmin: 0
kopanoSharedStoreOnly: 0
objectClass: kopano-user
kopanoAccount: 0
kopanoAdmin: 0
kopanoSharedStoreOnly: 0
objectClass: kopano-user
kopanoAccount: 0
kopanoAdmin: 0
kopanoSharedStoreOnly: 0
objectClass: kopano-user
kopanoAccount: 0
kopanoAccount: 0
kopanoAdmin: 0
kopanoSharedStoreOnly: 0
objectClass: kopano-user
kopanoAdmin: 0
kopanoSharedStoreOnly: 0
objectClass: kopano-user
kopanoAccount: 0
kopanoAccount: 0
kopanoAdmin: 0
kopanoSharedStoreOnly: 0
objectClass: kopano-user