Migration from zarafa
-
I jsut started trying out kopano with my openldap system with existing zarafa and faking the new servers name with the old one within server.cfg hoping I can at least query users and login with webmail (cloned mysql as well for testing).
Almost worked with straight copy of zarafa ldap.cfg to kopano but getting this error
Tue Nov 27 18:23:09 2018: [notice ] Connection to database 'eit_kopano_anuke' succeeded Tue Nov 27 18:23:09 2018: [info ] Setting cell cache size: 1073741824 Tue Nov 27 18:23:09 2018: [info ] Setting object cache size: 16777216 Tue Nov 27 18:23:09 2018: [info ] Setting indexedobject cache size: 33554432 Tue Nov 27 18:23:09 2018: [info ] Setting quota cache size: 1048576 Tue Nov 27 18:23:09 2018: [info ] Setting userdetails cache size: 26214400 Tue Nov 27 18:23:09 2018: [debug ] PurgeCache took 0 ms Tue Nov 27 18:23:09 2018: [warning] Config warning: Option "ldap_port" is recognized but obsolete, and will be removed in a future release. Tue Nov 27 18:23:09 2018: [warning] Config warning: Option "ldap_protocol" is recognized but obsolete, and will be removed in a future release. Tue Nov 27 18:23:09 2018: [warning] Config warning: Option "ldap_company_scope" has no effect anymore, and will be removed in a future release. Tue Nov 27 18:23:09 2018: [warning] WARNING: "server_listen_tls" is empty, but LDAP returns "https://172.16.200.190:237/" Tue Nov 27 18:23:09 2018: [warning] WARNING: Inconsistencies detected between local and LDAP based configuration. Tue Nov 27 18:23:09 2018: [notice ] Querying database for searchfolders. This may take a while. Tue Nov 27 18:23:09 2018: [notice ] Loading search folders. Tue Nov 27 18:23:09 2018: [notice ] Done loading search folders. Tue Nov 27 18:23:09 2018: [notice ] Startup succeeded on pid 27964 Tue Nov 27 18:23:32 2018: [debug ] Accepted incoming connection from file:///var/run/zarafa Tue Nov 27 18:23:32 2018: [error ] Unable to resolve object from relational attribute type "uidNumber"I can see uniqueNumber set in ldap.cfg and there’s is a _type defined as ‘text’ but it ignores it or no longer used so not sure what’s going on.
# above ldap port/server/bind details removed # ldap_search_base = dc=domain,dc=tld ldap_object_type_attribute = objectClass ldap_user_type_attribute_value = zarafa-user ldap_group_type_attribute_value = zarafa-group ldap_contact_type_attribute_value = zarafa-contact ldap_company_type_attribute_value = zarafa-company ldap_addresslist_type_attribute_value = zarafa-addresslist ldap_dynamicgroup_type_attribute_value = zarafa-dynamicgroup ldap_user_search_filter = (objectClass=zarafa-user) ldap_user_unique_attribute = uidNumber ldap_user_unique_attribute_type = text ldap_fullname_attribute = displayName ldap_loginname_attribute = uid ldap_password_attribute = userPassword ldap_authentication_method = bind ldap_emailaddress_attribute = mail ldap_emailaliases_attribute = zarafaAliases ldap_isadmin_attribute = zarafaAdmin ldap_nonactive_attribute = ldap_resource_type_attribute = zarafaResourceType ldap_resource_capacity_attribute = zarafaResourceCapacity ldap_sendas_attribute = zarafaSendAsPrivilege ldap_sendas_attribute_type = text ldap_sendas_relation_attribute = ldap_user_certificate_attribute = userCertificate #!propmap /etc/zarafa/ldap.propmap.cfg ldap_group_search_filter = ldap_group_unique_attribute = cn ldap_group_unique_attribute_type = text ldap_groupname_attribute = cn ldap_groupmembers_attribute = uniqueMember ldap_groupmembers_attribute_type = dn ldap_groupmembers_relation_attribute = uid ldap_group_security_attribute = zarafaSecurityGroup ldap_group_security_attribute_type = boolean ldap_company_search_filter = (objectClass=zarafa-company) ldap_company_unique_attribute = ou ldap_company_unique_attribute_type = text ldap_companyname_attribute = ou ldap_company_scope = sub ldap_company_view_attribute = zarafaViewPrivilege ldap_company_view_attribute_type = text ldap_company_view_relation_attribute = ldap_company_admin_attribute = zarafaAdminPrivilege ldap_company_admin_attribute_type = text ldap_company_admin_relation_attribute = ldap_company_system_admin_attribute = zarafaSystemAdmin ldap_company_system_admin_attribute_type = text ldap_company_system_admin_relation_attribute = ldap_addresslist_search_filter = (objectClass=zarafa-addresslist) ldap_addresslist_unique_attribute = cn ldap_addresslist_unique_attribute_type = text ldap_addresslist_filter_attribute = zarafaFilter ldap_addresslist_search_base_attribute = zarafaBase ldap_addresslist_name_attribute = cn ldap_dynamicgroup_search_filter = (objectClass=zarafa-dynamicgroup) ldap_dynamicgroup_unique_attribute = cn ldap_dynamicgroup_unique_attribute_type = text ldap_dynamicgroup_filter_attribute = zarafaFilter ldap_dynamicgroup_search_base_attribute = zarafaBase ldap_dynamicgroup_name_attribute = cn ldap_quota_userwarning_recipients_attribute = zarafaQuotaUserWarningRecipients ldap_quota_userwarning_recipients_attribute_type = text ldap_quota_userwarning_recipients_relation_attribute = ldap_quota_companywarning_recipients_attribute = zarafaQuotaCompanyWarningRecipients ldap_quota_companywarning_recipients_attribute_type = text ldap_quota_companywarning_recipients_relation_attribute = ldap_quotaoverride_attribute = zarafaQuotaOverride ldap_warnquota_attribute = zarafaQuotaWarn ldap_softquota_attribute = zarafaQuotaSoft ldap_hardquota_attribute = zarafaQuotaHard ldap_userdefault_quotaoverride_attribute = zarafaUserDefaultQuotaOverride ldap_userdefault_warnquota_attribute = zarafaUserDefaultQuotaWarn ldap_userdefault_softquota_attribute = zarafaUserDefaultQuotaSoft ldap_userdefault_hardquota_attribute = zarafaUserDefaultQuotaHard ldap_quota_multiplier = 1048576Not sure what else could be the issue, tried the C source but couldn’t read that part exactly.
-
@djtremors said in Migration from zarafa:
faking the new servers name with the old one within server.cf
fyi: chaning
server_namein a running setup is generally not a good idea, as the value of this is used in a variety of places (changing the server_name will for example break archived messages when using kopano-archiver).I can see uniqueNumber set in ldap.cfg and there’s is a _type defined as ‘text’
these are also still the default values for these settings: https://stash.kopano.io/projects/KC/repos/kopanocore/browse/installer/linux/ldap.m4#60-68
-
Well the fake name is purely so it can find the server name in ldap which is linked to the cloned database of users on the database. the only thing that doesn’t match is the ldap entry has a server IP address which this migrating server is on a different IP. But I’m running in /var/zarafa/sock file atm.
I’m just finding a migration path to be very limited without having to hard switch it over. -
also getting this which I haven’t been able to debug, I did have users displayed but in fixing the above weirdness, the below broke. error meaningss are as useful as ex-wives. connect as default? where is it getting this from and connect to where what… ??
$ sudo kopano-cli --list-users
[error ] gsoap connect: ()
[error ] HrLogon server “default:” user “SYSTEM”: network error
could not connect to server at ‘default:’ -
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/kopano/server.sock"}, 110) = -1 ECONNREFUSED (Connection refused)
strace to the rescure… so it’s not using the zarafa old socket that the server is listening on. It’s python so I’ll figure it out
-s sockfilebut all I get is XML out and hangs…weird
-
@djtremors said in Migration from zarafa:
connect as default
that is a simplification within kopano-client (can’t seem to find the code location for it) to make it easier to get the switch from zarafa, to kopano. “default:” its an alias for the usual file sockets.
For kopano-cli you can configure your desired socket in admin.cfg (which is still the same as it was before with kopano-admin)
