NS7 --> NS8 mail migration failed

Support
, , , ,
1

Hi there,

Long time no see :blush:

Holidays time : I finally decided to give NS8 a go and try to migrate my own personal server to see how things were going.

Nextcloud migration seems to be working although I can’t access it right now probably because the LDAP is not migrated yet.

Now trying to migrate my emails.

Foreword My NS7 is hosted at domain1.tld, and the email server handles some other domains. Additionally NS8 is now hosted at, say, domain2.tld

Initiating the migration was successful, but starting it fails immediately. The logfile contains this :

----------- start nethserver-mail Fri, 19 Jul 2024 18:18:38 +0200
mkdir: created directory ‘/var/lib/nethserver/nethserver-ns8-migration/nethserver-mail’
mkdir: created directory ‘/var/lib/nethserver/nethserver-ns8-migration/nethserver-sogo’
mkdir: created directory ‘/var/lib/nethserver/nethserver-ns8-migration/nethserver-mail-getmail’
[INFO] Created remote module instance imapsync2
[INFO] App nethserver-mail-getmail is bound to rsync://imapsync2@10.5.4.1:20028, waiting for task module/imapsync2/task/110afb12-9601-44bf-9bbb-71c866cc2ad4
[INFO] Created remote module instance mail2
[INFO] App nethserver-mail is bound to rsync://mail2@10.5.4.1:20029, waiting for task module/mail2/task/9c63e551-92ee-4006-835f-9bf59023113f
[INFO] Created remote module instance sogo2
[INFO] App nethserver-sogo is bound to rsync://sogo2@10.5.4.1:20030, waiting for task module/sogo2/task/94915038-31aa-4378-83d8-84e425a515a7
----------- sync nethserver-mail Fri, 19 Jul 2024 18:19:54 +0200
/usr/share/nethesis/nethserver-ns8-migration/apps/nethserver-mail/migrate: line 51: USER_DOMAIN: parameter null or not set
----------- abort nethserver-mail Fri, 19 Jul 2024 18:21:09 +0200

Can anybody help ? Tried to set a local environment variable to domain1.tld without success.
Also tried to create the domain1.tld in NS8, no working either.

Is the migration tool able to handle my user case ?

Thanks

Matthieu

2

Please share the output of this NS7 command (after replacing private information):

/usr/sbin/account-provider-test dump

Until you press the Finish button, the Nextcloud app runs on NS7. After Finish, it runs on NS8 and it must connect the LDAP DB on NS7 through the wireguard VPN until LDAP is migrated too, as the last migration step. NethServer 7 migration — NS8 documentation

3

Txs Davide.

[root@cloud ~]# /usr/sbin/account-provider-test dump
{
   "BindDN" : "cn=ldapservice,dc=directory,dc=nh",
   "LdapURI" : "ldap://127.0.0.1",
   "DiscoverDcType" : "dns",
   "StartTls" : "",
   "port" : 389,
   "host" : "127.0.0.1",
   "isAD" : "",
   "isLdap" : "1",
   "UserDN" : "ou=People,dc=directory,dc=nh",
   "GroupDN" : "ou=Groups,dc=directory,dc=nh",
   "BindPassword" : "redacted",
   "BaseDN" : "dc=directory,dc=nh",
   "LdapUriDn" : "ldap:///dc%3Dgaillet%2Cdc%3Dbe"
}

Looks like another UTF8 story :blush:

4

Oh.

Then there is something wrong too :grimacing:

2024-07-19T23:19:09+02:00 [1:nextcloud1:nextcloud-app] NOTICE: PHP message: [nextcloud][index][3] {"reqId":"Zi4Nu6Y9LL4XUxOWVsFH","level":3,"time":"2024-07-19T21:19:09+00:00","remoteAddr":"104.28.40.7","user":"--","app":"index","method":"POST","url":"/login","message":"
{\"Exception\":\"OC\\\\ServerNotAvailableException\",\"Message\":\"Lost connection to LDAP server.\",\"Code\":0,\"Trace\":[{\"file\":\"/var/www/html/apps/user_ldap/lib/LDAP.php\",\"line\":420,\"function\":\"processLDAPError\",\"class\":\"OCA\\\\User_LDAP\\\\LDAP\",\"type\":\"->\",\"args\":[\"*** sensitive parameters replaced ***\",\"*** sensitive parameters replaced ***\",-1,\"Can't contact LDAP server\"]},
{\"file\":\"/var/www/html/apps/user_ldap/lib/LDAP.php\",\"line\":309,\"function\":\"postFunctionCall\",\"class\":\"OCA\\\\User_LDAP\\\\LDAP\",\"type\":\"->\",\"args\":[\"*** sensitive parameters replaced ***\"]},
{\"file\":\"/var/www/html/apps/user_ldap/lib/LDAP.php\",\"line\":67,\"function\":\"invokeLDAPMethod\",\"class\":\"OCA\\\\User_LDAP\\\\LDAP\",\"type\":\"->\",\"args\":[\"*** sensitive parameters replaced ***\"]},
{\"file\":\"/var/www/html/apps/user_ldap/lib/Connection.php\",\"line\":718,\"function\":\"bind\",\"class\":\"OCA\\\\User_LDAP\\\\LDAP\",\"type\":\"->\",\"args\":[\"*** sensitive parameters replaced ***\"]},
{\"file\":\"/var/www/html/apps/user_ldap/lib/Connection.php\",\"line\":631,\"function\":\"bind\",\"class\":\"OCA\\\\User_LDAP\\\\Connection\",\"type\":\"->\",\"args\":[\"*** sensitive parameters replaced ***\"]},{\"file\":\"/var/www/html/apps/user_ldap/lib/Connection.php\",\"line\":239,\"function\":\"establishConnection\",\"class\":\"OCA\\\\User_LDAP\\\\Connection\",\"type\":\"->\",\"args\":[]},
{\"file\":\"/var/www/html/apps/user_ldap/lib/Connection.php\",\"line\":247,\"function\":\"init\",\"class\":\"OCA\\\\User_LDAP\\\\Connection\",\"type\":\"->\",\"args\":[]},
{\"file\":\"/var/www/html/apps/user_ldap/lib/Access.php\",\"line\":1110,\"function\":\"getConnectionResource\",\"class\":\"OCA\\\\User_LDAP\\\\Connection\",\"type\":\"->\",\"args\":[]},{\"file\":\"/var/www/html/apps/user_ldap/lib/Access.php\",\"line\":1290,\"function\":\"executeSearch\",\"class\":\"OCA\\\\User_LDAP\\\\Access\",\"type\":\"->\",\"args\":[\"(&(|(objectclass=inetOrgPerson))(|(uid=matthieu)(|(mail=matthieu))))\",\"ou=People,dc=directory,dc=nh\",[\"entryuuid\",\"nsuniqueid\",\"objectguid\",\"guid\",\"ipauniqueid\",\"And 8 more entries, set log level to debug to see all entries\"],500,0]},
{\"file\":\"/var/www/html/apps/user_ldap/lib/Access.php\",\"line\":977,\"fun
5

Please run these commands in NS7, and paste here their output

config show slapd
config show sssd
6 
# config show slapd
slapd=service
    TCPPorts=389,636
    access=
    status=enabled
[root@cloud ~]# config show sssd
sssd=service
    AdDns=
    DiscoverDcType=dns
    LdapURI=ldap://127.0.0.1
    Provider=ldap
    Realm=
    ShellOverrideStatus=enabled
    Workgroup=
    status=enabled
7

Please try to change access to “green” from the System> Services page.

8

Same :slightly_frowning_face:

/usr/share/nethesis/nethserver-ns8-migration/apps/nethserver-mail/migrate: line 51: USER_DOMAIN: parameter null or not set

9

echo "${USER_DOMAIN:?}" > user_domain.txt

who is supposed to set that environnement variable ?

10

Browing the nethserver-ns8-migration code right now.

FYI :

# cat /var/lib/nethserver/nethserver-ns8-migration/environment
NODE_ID=5

I had a domain already configured on NS8, I deleted it and tried again - no change.

11

Tried again from scratch. It’s currently transferring the files.

The mistake I may have made is setting up a domain name and letsencrypt certificate before starting the import.

Otherwise I can’t really identify what when wrong.

Maybe the migration process should be proposed as soon as the cluster is created to mitigate the risk that an user fiddles with settings that could keep the migration process to work correctly.

12

Are you sure of it? Do you have any log evidence?

The only thing I can be sure of, is the “unusual” value of Slapd access= prop. I say unusual because I see it in 0,05% of NS7 OpenLDAP installations. The default value is green and AFAIK NS8 requires it. I’m sorry if this corner case is not correctly handled: I wasn’t aware of it until now.

What may be happening is that while the NS8 temporary and external domain is configured, a validation error is returned from NS8. If this theory is true, you’d see a Task add_external_domain has failed message in NS7 logs.

The consequence of the sys.exit(1) line 241 is probably wrong. It is not enough to prevent further actions from the user. At this point the migration is destined to fail.

1 Like
13

Nope. Just an educated guess after trial and error.

No need to apologize - but I have no idea why this prop is weird. That system is old, it has been upgraded multiple times since the very first release of NS7 I think.

Sadly the source machine wasn’t working anymore after the migration tool “disabled” it, and has been corrupted by Hetzner’s crippled snapshot system and finally will probably never resuscitate since NS7’s data restore process doesn’t seem to work either as detailed in another post.

I’m not going to spend more time on this, currently migrating manually to NS8. Thanks for you support anyway.

14

@davidep I can reproduce, slapd access '' and the migration fails

2 Likes
15

Hi

Trying to rebuild my NS7 from backup after the NS8 migration disaster. After restoring the data backup, I can’t login to the IMAP server anymore, same for Sogo.

I believe that it might be due to the way authentication changed in NS8, the domain name is not taken into account anymore or something like this, the source system might have been affected ?

I might be using a configuration backup taken after I started the migration tool, that could be an explanation.

sogo.log :

Aug 13 01:09:35 sogod [2735]: [ERROR] <0x0x56264b1ace10[NGImap4ConnectionManager]> IMAP4 login failed:                                                                                                            
  host=localhost, user=matthieu@gaillet.be, pwd=yes                                                                                                                                                               
  url=imap://matthieu%40gaillet.be@localhost/?tls=NO&tlsVerifyMode=default                                                                                                                                        
  base=(null)                                                                                                                                                                                                     
  base-class=(null))                                                                                                                                                                                              
  = <0x0x56264ac18a20[NGImap4Client]: login=matthieu@gaillet.be(pwd) address=<0x0x56264afd6210[NGInternetSocketAddress]: host=localhost port=143>>                                                                
Aug 13 01:09:35 sogod [2735]: <0x56264adf9970[SOGoMailAccount]:0> renewing imap4 password                                                                                                                         
Aug 13 01:09:35 sogod [2735]: [ERROR] <0x0x56264b1ace10[NGImap4ConnectionManager]> IMAP4 login failed:                                                                                                            
  host=localhost, user=matthieu@gaillet.be, pwd=yes                                                                                                                                                               
  url=imap://matthieu%40gaillet.be@localhost/?tls=NO&tlsVerifyMode=default                                                                                                                                        
  base=(null)                                                                                                                                                                                                     
  base-class=(null))                                                                                                                                                                                              
  = <0x0x56264adc1480[NGImap4Client]: login=matthieu@gaillet.be(pwd) address=<0x0x56264b2599f0[NGInternetSocketAddress]: host=localhost port=143>>

Is there any obvious reason for this to happen ?

Txs

1 Like
16

Can you login with roundcubemail ?

Roundcubemail use imap to authenticate and sogo use ldap. Can you perform the login of sogo and then you fail to login to imap ?

2 Likes
17

Didn’t try. Let me check.

18

Nope. Doesn’t work.

Erreur de connexion au serveur de stockage.

maillog doesn’t report anything excepts that errors regularly :

postfix/pickup[31212]: 7E66B7EDAC: uid=0 from=<root>                                                         │
Aug 13 12:20:52 cloud postfix/cleanup[29855]: warning: hash:/etc/postfix/bcc_maps is unavailable. open database /etc/postfix/bcc_ma│
Aug 13 12:20:52 cloud postfix/cleanup[29855]: warning: hash:/etc/postfix/bcc_maps lookup error for "root@cloud.gaillet.be"         │
Aug 13 12:20:52 cloud postfix/cleanup[29855]: warning: 7E66B7EDAC: sender_bcc_maps lookup problem

Actually I can’t connect to IMAP either (from the outside) because of some certificate error. I didn’t configure letsencrypt because it’s running on a local VM. I could if needed however.

LDAP looks ok. System looks ok.

19

That’s exactly what happens indeed.

20

Finally found what happened.

First, imap activities are not logged in maillog but in imap.log :expressionless:

Secondly, I discovered I installed a custom dovecot plugin centuries ago that had not been correctly restored and therefore was keeping dovecot to do anything.

Txs anyway Stef.

Matthieu

2 Likes