1 Topic by broth

  • broth
  • Member
  • Offline
  • Registered: 2012-04-22
  • Posts: 145

Topic: Manual upgrade issues with "migrate_sql_alias_table.py"

================ Required information ====
- iRedMail version (check /etc/iredmail-release): 0.9.7 (just upgraded from fresh 0.9.6 installation)
- Linux/BSD distribution name and version: Ubuntu 16.04
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): MySQL
- Web server (Apache or Nginx): Nginx
- Manage mail accounts with iRedAdmin-Pro? yes (2.7.0 upgraded from 2.6.0)
- [IMPORTANT] Related original log or error message is required if you're experiencing an issue.
====

Hello all!

Today I was upgrading our iRedMail 0.9.6 server (fresh installation) to 0.9.7.

Everything works fine except the script "migrate_sql_alias_table.py" does produce a strange result.
Maybe some of you can confirm the same issue:

I have an example domain with only three users/mailboxes. Please see attached screenshot "domain_users.png".
This screenshot has been done with iRedAdmin-Pro 2.6.0.
There are *no* aliases configured on this domain.

Now I performed migration of the data to the two new MySQL tables. I did not remove the original data in vmail.alias table.

Output:

* [1/428] Migrating mail user 2016@xxxxxxx.com
* [2/428] Migrating mail user 2017@xxxxxxx.com
...
* [167/428] Migrating mail user info@xxxxxxx.com
...
* DONE.

iRedAdmin-Pro was upgraded as well to 2.7.0.

Now I have some aliases configured on that domain - which makes no sense IMHO.
Please see attached screenshot "domain_aliases.png".

The MySQL table forwardings does contain:

# id, address, forwarding, domain, dest_domain, is_list, is_forwarding, is_alias, active
'1', '2016@xxxxxxx.com', '2016@xxxxxxx.com', 'xxxxxxx.com', 'xxxxxxx.com', '0', '1', '0', '1'

Note that the domain and dest_domain values are the same. address and forwarding are the same as well.

Is this a "new" behaviour or a bug?

Many other domains have the same issue like

# id, address, forwarding, domain, dest_domain, is_list, is_forwarding, is_alias, active
'14', 'acronis.xxx@example.net', 'acronis.xxx@example.net', 'example.net', 'example.net', '0', '1', '0', '1'
'43', 'autoxxxx.de', 'info@autoxxxx.de', 'autoxxxx.de', 'autoxxxx.de', '0', '1', '0', '1'

Please help.

@Zhang: You can take a look to our server via SSH if you want, please just let me know.

Best regards,
Bernhard

Post's attachments

domain_aliases.png
domain_aliases.png 84.8 kb, file has never been downloaded. 

domain_users.png
domain_users.png 91.09 kb, file has never been downloaded. 

You don't have the permssions to download the attachments of this post.

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2 Reply by broth

  • broth
  • Member
  • Offline
  • Registered: 2012-04-22
  • Posts: 145

Re: Manual upgrade issues with "migrate_sql_alias_table.py"

Some additional informations:

This is the original dataset from vmail.alias

# address, goto, name, moderators, accesspolicy, domain, islist, is_alias, alias_to, created, modified, expired, active
'2016@xxxxxxx.com', '2016@xxxxxxx.com', '', '', '', 'xxxxxxx.com', '0', '0', '', '2016-06-17 08:26:39', '0000-00-00 00:00:00', '9999-12-31 00:00:00', '1'

"address" and "goto" are the same. May this be caused by "old" data from previous iRedMail installations?

I do not understand the purpose of this dataset.

I wonder if the migration script can be improved by *not* migrating these kind of "aliases" as they are useless.

Have other users experienced the same issues?

3 Reply by broth

  • broth
  • Member
  • Offline
  • Registered: 2012-04-22
  • Posts: 145

Re: Manual upgrade issues with "migrate_sql_alias_table.py"

One of the forwardings in the old table was set to "membersonly" (Mail Deliver Restriction).

Now after conversion it's set to "unrestricted".

When I remove the senseless datasets (address = forwarding) from the table via "DELETE FROM vmail.forwardings where address=forwarding;" the mail server works as before - no change.

Unfortunately iRedAdmin-Pro still shows all the mailboxes additionally as aliases.
This is wrong.

Summary:

- migrate_sql_alias_table.py does not check for "address = forwarding" and adds it to the new structure
-> Proposal: Implement check and do not migrate useless entries

- iRedAdmin-Pro 2.7.0 does show alias entries from vmail.alias even if "address = forwarding". Is this intended?
-> Proposal: Please show only real alias entries.

- The alias addresses iRedAdmin-Pro 2.7.0 shows do contain empty forwarding addreses. This makes no sense

4 Reply by broth

  • broth
  • Member
  • Offline
  • Registered: 2012-04-22
  • Posts: 145

Re: Manual upgrade issues with "migrate_sql_alias_table.py"

Update & Solution:

The upgrade guide was updated. The step of deleting unused rows in vmail.alias table is now mandatory.
If this step is not done, ghost entries may appear in iRedAdmin.

Once the unused rows are deleted, everything works normal.

Thanks Zhang for your help and for updating the documentation!