Ok, i have just done it, i will see what happen next
Something must be wrong with dns resolving on my box, when i read syslog in /var/log :
Oct 23 17:49:25 box named[18014]: timed out resolving ‘box.DOMAIN_NAME/A/IN’: OLD_PUBLIC@IP#53
Oct 23 17:49:30 box named[18014]: REFUSED unexpected RCODE resolving ‘_.box.DOMAIN_NAME/A/IN’: NEW_PUBLIC@IP#53
Oct 23 17:50:06 box named[18014]: REFUSED unexpected RCODE resolving ‘autodiscover.DOMAIN_NAME/AAAA/IN’: NEW_PUBLIC@IP#53
Oct 23 17:50:06 box named[18014]: timed out resolving ‘autodiscover.DOMAIN_NAME/A/IN’: OLD_PUBLIC@IP#53
Oct 23 17:50:11 box named[18014]: REFUSED unexpected RCODE resolving ‘mta-sts.DOMAIN_NAME/A/IN’: NEW_PUBLIC@IP#53
Oct 23 17:50:11 box named[18014]: timed out resolving ‘autodiscover.DOMAIN_NAME/AAAA/IN’: OLD_PUBLIC@IP#53
Oct 23 17:50:16 box named[18014]: REFUSED unexpected RCODE resolving ‘mta-sts.DOMAIN_NAME/AAAA/IN’: NEW_PUBLIC@IP#53
Oct 23 17:50:16 box named[18014]: timed out resolving ‘mta-sts.metalbox.ovh/A/IN’: OLD_PUBLIC@IP#53
Oct 23 17:50:21 box named[18014]: REFUSED unexpected RCODE resolving ‘www.DOMAIN_NAME/A/IN’: NEW_PUBLIC@IP#53
Oct 23 17:50:22 box named[18014]: timed out resolving ‘mta-sts.DOMAIN_NAME/AAAA/IN’: OLD_PUBLIC@IP#53
Oct 23 17:50:26 box named[18014]: REFUSED unexpected RCODE resolving ‘www.DOMAIN_NAME/AAAA/IN’: NEW_PUBLIC@IP#53
Oct 23 17:50:27 box named[18014]: timed out resolving ‘www.DOMAIN_NAME/A/IN’: OLD_PUBLIC@IP#53
Oct 23 17:50:32 box named[18014]: timed out resolving ‘www.DOMAIN_NAME/AAAA/IN’: OLD_PUBLIC@IP#53
i deactivate UFW to be sure, just for a moment, i see that bind9 is activated beside nsd, is there any conflict with that ?
i tried to stop bind9, but i dont get anymore dns resolving then (cant get apt update so …)
i am nearly 48h dns update resolving with my DNS ISP, i didnt remember last time it took so much time
it seems my DNS resolving is refused according to the log file
Had the same issue, just ended up going with my registrar DNS manually. Waiting to see how this plays out.
I just noticed that fail2ban was disabled post-upgrade for some reason, at least on my box. I re-enabled and started it, and it seems to be working fine. Folks may want to check - I had some Iranian-based IPs hammering on my SMTP port every 10 seconds, which is what led me to investigate.
Really happy to see this project start to gain some steam again.
3 Likes
Problem was solved by adding line “ListenAddress 127.0.0.1” to sshd_config, because my sshd deamon doesnt listen on public address (vpn).
MiaB update script wanted to publish on public address (for DNS resolver) and stop working when he sees he cannot reach this public IP (because of sshd deamon)
if it can help
Any way we can bump this. It was indeed pretty critical moving forward with my new host… 
1 Like
by opening issues or pull requests here… GitHub - mail-in-a-box/mailinabox: Mail-in-a-Box helps individuals take back control of their email by defining a one-click, easy-to-deploy SMTP+everything else server: a mail server in a box.
are you refering to this post with the DNS issue? If yes, just restart NSD or reboot your server…
1 Like
I’m referring to the post I replied to? am I linking posts wrong here? This one > Version 60 for Ubuntu 22.04 is released - #50 by alento
Also @alento said he already made a pr, but I’m unable to find it… 
1 Like
No I didn’t realize that I could have loaded the parent post, by clicking on the arrow on the top right of your post 
1 Like
2 Likes
Does anyone know what is causing the message “ * Error: stepping, UNIQUE constraint failed: oc_users_external.uid, oc_users_external.backend (19)” after finishing final install steps?
This was a result of a backup on 57a, restore on new host to 60?
Every time I run the sudo mailinabox cud this message is emitted.
Thx,
Tony
1 Like
Thank you! to everyone who contributed!
1 Like
I also had to start F2B manually. Thank you for pointing this out.
1 Like
It wasn’t just stopped, it was also disabled from automatically starting on boot. To re-enable it:
sudo systemctl enable fail2ban
2 Likes
Just curious, is anyone else seeing this or is it just me?
1 Like
Like a few others I performed an in-place upgrade of Ubuntu from 18.04 to 20.04 and then 22.04, and then ran the mailinabox installer to get version 60. I know this isn’t supported, but It works, and I’m able to send and receive emails just as I could before.
I’m guessing the reason this method isn’t recommended is the warnings you get in /var/log/mail.log after doing this. Both postfix and dovecot retained the old configuration files, which causes warnings about settings no longer being required in dovecot and backwards compatibility mode in postfix.
I’m pretty sure these are going to cause an issue in the future, so I’ve fixed them myself by performing a clean install on a new instance and then copying /etc/postfix/main.cf, /etc/postfix/master.cf, and /etc/dovecot/conf.d/10-ssl.conf back (this seems to have covered all warnings so far)
Other than that I haven’t had any issues
2 Likes
I had tried the in-place way as well, but eventually, I had issues with python / pip venv variables, that I could not wrap my head around. So I went with a fresh install which was less painful than I anticipated it to be. Well, apart from the ssl issue. 
1 Like