Email no longer working after upgrading to Mariadb 10

Hi there.
I’m in a bit of a panic.
I upgraded to Mariadb 10.2 today.

All went well i think! However, email isn’t working.

It was running for over a year with no issues. Now my phone seems to connect to the incoming server (doesn’t download emails though) but it won’t connect to outgoing. It just says cannot connect to server error 3014.

Would really appreciate some help with this as soon as possible!

Howdy,

Is Postfix on your server configured to use MySQL/MariaDB for usernames?

That’s not the case for most folks… but that’s the only reason changing MariaDB might cause that.

It’s possible another change around the same time affected things though.

What port are you trying to connect on?

You may want to ensure that there isn’t a firewall blocking that port.

You can also verify that the port is listening with this command:

netstat -anlp | grep :PORTNUMBER

Hi there,
Thanks very much for the reply.

The users for Postfix were initially created in the ‘Edit Users’ bit. Would this be using the MariaDB?

Also, I believe there is no filewall running.

I think I’m going to have to redo the server if I’m being honest. :frowning:

This is the site I used: http://www.2daygeek.com/upgrade-mariadb-from-5-5-to-mariadb-10-0-10-1-on-ubuntu-centos-rhel-debian-fedora-mint/

SOmething strange I’ve noticed, I disabled mail and then reenabled mail for the domain, but it doesn’t save. It shows this:

Failed to modify server : No virtual domains file (virtual_alias_maps) was found in your Postfix configuration!

In Virtual Domains against Postfix, the top options is $virtual_maps, and the second optoin is $virtual_alias_maps.

At the bottom though it says (No map is currently defined. Define a map first, then you can edit it).

If I click the lookup for the first, Map Source 1 is set to ‘None’
What should this be?

This problem is unrelated to MariaDB. As Eric mentioned, unless you specifically configured your mail server to use MariaDB (something we strongly discourage for almost all users), it has nothing to do with mail.

You’ve got multiple issues there.

Retrieving mail on your phone or computer would use the IMAP/POP server, which is Dovecot, in a default Virtualmin installation. I’d recommend checking to be sure the dovecot service is running. (service dovecot status)

That would be unrelated to the virtual_alias_maps error you’re seeing, which is about Postfix (which is not what your mail client talks to when you download your mail). That message seems to indicate your Postfix configuration has been removed or replaced with a default config file. I can’t think of why that would happen short of uninstalling and then reinstalling the package. Unless you have backups of the postfix config files, you’d need to reconstruct them manually (you can do that based on the users you have on the system). Did you, by chance, uninstall Postfix (or virtualmin-base) during the Mariadb upgrade and then reinstall it? That would cause the behavior you’re seeing.

Rebuilding the whole server seems like overkill and a lot of work. Got recent backups?

Hi Joe,
Dovecote appears to be running according to the status.

To perform the removal of MariaDB, I used this command, yum remove mysql* mariadb*
It just occurred to my that when I logged back in it it said Postfix wasn’t installed so I had to install it! Maybe that’s it!

What I did do before upgrading MariaDB is take a full backup, using the Virtual Backup Module, selecting all virtualmin features. Would this be enough do you think to restore the postfix settings?

If not, how do I go about reconstructing it manually using the users I have on the system?

Many thanks for the help so far (I think you helped me initially set this up a year or so ago…).

Craig

Do you think maybe the best thing I can do is restore the backup that I took.

The backup was taking using the backup function within VirtualMin. and I selected ALL VirtualMin settings to backup, as well as all features.

Will this restore correct it do you think?

Well, it appears after doing a bit of research that the method I used removes postfix which has a dependency on mariadb-libs.

I think I have no choice but to re-do the server from the start.

I will use yum remove mariadb-server to remove version 5.5, instead of yum remove mysql* mariadb*

Does that sound like it might work?

Removing services that are in production use is always a terrible idea. But, I guess you know that now. :wink:

RPM sometimes leaves behind rpmsave files for config files that have been modified after installation…so, you may be able to just go into /etc/postfix and copy the .rpmsave files back over the package-provided files. This maybe didn’t happen, though, since the /etc/postfix directory probably would have been removed, too.

Don’t yum remove anything, that’ll just replay the same problems. If the packages are upgrades, you just use yum update, and if the packages are not upgrades (like the SCL packages, which co-exist along-side the CentOS standard packages), just leave the standard ones installed. I have both mariadb-5.5 and mariadb-10 installed on Virtualmin.com, without trouble. You just have to set it up so that mariadb-10 is the one that starts on boot. You also need to configure Webmin to look for the right mariadb files (this is in Webmin->Webmin->Servers->MySQL Server under Module Configuration which is the gear icon in the corner, if you’re using Authentic Theme).

Hi Joe.
I certainly do know now, in fact, I’ve learnt the hard way.

Thanks for the advice on having them both installed.

Would you mind telling me your method of installing Mariadb 10?

It’s been a while, so I don’t recall any specifics, but I used the SCL mariadb 10.0 packages. There’s a 10.1, now, which would be the right choice.

https://www.softwarecollections.org/en/scls/rhscl/rh-mariadb101/

The SCL docs there cover sort of switching your system and shell to using it. But, you need to manually disable the old mariadb using systemctl (systemctl stop mariadb and systemctl disable mariadb, and start up the new one with something like systemctl start rh-mariadb101-mariadb and systemctl enable rh-mariadb101-mariadb).

From there, you need to convince Webmin to talk to this MariaDB rather than the default. The paths for SCL packages are all in “opt”, I think, but Webmin probably just needs the new service names (e.g. the start/stop commands need to change to point to “rh-mariadb101-mariadb” instead of “mariadb”). The old mariadb client can probably connect and work with the new database just fine, but if there’s new features in the command line client you need, Webmin can probably be told where to find it in /opt. I don’t recall what other bits are in the module configuration, but you’ll want to confirm it’s right before you start making new Virtualmin domains and installing stuff. Things can get confusing real fast if Webmin is fiddling with different databases and configurations.

One thing I don’t remember, which would be vital, is whether the SCL package uses the same config file as the original mariadb package (in /etc/my.cnf, I think?). It may have it’s own config file inside of /opt somewhere…Webmin needs to know about that if it does.

Please create a little tutorial how to upgrade from mariadb5.5 to latest mariaDB :slight_smile:

Hi Joe,
I think I installed 10.1 alongside 5.5 correctly last night.
As you pointed out there were a few settings in the module configuration that needed altering to look in the new location, but aside from that it was relatively straight forward.

Its stopping and starting correctly, and Webmin is displaying version 10.1!

Regarding the my.cnf file, I couldn’t see a new one inside of /opt, so have left it how it was. What would I notice if this isn’t correct?

Now to sort the Mail Server!