Dec 2024
3 / 3
Jan 7
Jan 7
Fernando
Dec '24
1

Hello,

We are currently making a migration from an LDAP server to another (more recent) LDAP server.
As per indications on previous post, we have chosen to give EGroupWare a “read-only” account on new LDAP.

What we are facing now is that all calendars are brand new ones. Groups also are brand new ones. All events are “lost”: there are present but with other accounts.

Has anyone already done so ?

Looking at database, it appears that there are no “LDAP accounts” in egw_accounts table.

The only solution we are thinking now is:

  • add a user to old LDAP giving permissions on all calendars
  • export all calendars (users and groups calendars) from “old” egroupware
  • change users and group names in this export to make them match new LDAP settings
  • add a user to new LDAP giving write permissions on all calendars
  • import all calendars to “new” egroupware

Is it possible to change LDAP server without losing calendars ? Or should we follow export/import path ?

Regards,
Fernando
PS: I’ll check with my company if we can have professional support for this, but this is not something we are familiar with. :-/

  • created

    Dec '24

  • last reply

    Jan 7
  • 2

    replies

  • 136

    views

  • 2

    users

  • 1

    like

  • 2

    links

RalfBeckerEGroupware GmbH
Jan 3

What you’re writing does NOT add up.

LDAP has absolutely nothing to do with access to calendars or not having access to them.

First you should be clear about what you mean when you talk about LDAP:
a) just authenticating agains LDAP (usernames match, and password check comes from LDAP server)
b) accounts are stored and read from LDAP (EGroupware uses internally uidNumber and gidNumber attributes in it’s DB)
c) EGroupware stores accounts in it’s own DB, but synchronizes them periodically with the LDAP server

That does NOT make any sense, you first need to understand were you coming from and were you want to go.

My guess would be you used b) and you’re new LDAP server simply uses different uid/gidNumber values then the old one. In which case you either need to change these IDs in the LDAP server, migrate the EGroupware DB to use the new IDs, or change EGroupware to sync with LDAP based on user- and group-names (ignoring IDs).

As Stefan already wrote: this is something trivial we can quickly fix through our support!

Ralf

Fernando
Jan 7
1

Hello,

I have not been clear enough sorry.

We are going:

  • from an (old) OpenLDAP used by EGroupware (with admin read/write access) for authentication and to store accounts
  • to an updated LDAP (IDM cluster) used by a future EGroupWare (with read only account) for authentication with users accounts in it’s own DB with periodical synchronization (including LDAP groups, if possible)

I have made an internal request for my company to hire your support services. :crossed_fingers:

Thanks and Regards

Edit: typo on updated LDAP