Topic: Bug: Failing SOGo install on CentOS 7.6 (with workaround!)
==== REQUIRED BASIC INFO OF YOUR IREDMAIL SERVER ====
- iRedMail version (check /etc/iredmail-release): 0.9.9 MARIADB edition
- Deployed with iRedMail Easy or the downloadable installer? Downloadable
- Linux/BSD distribution name and version: CentOS 7.6
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): MySQL
- Web server (Apache or Nginx): Nginx
- Manage mail accounts with iRedAdmin-Pro? Nope
- [IMPORTANT] Related original log or error message is required if you're experiencing an issue.
So this was a bit troublesome to figure out and involved running a shell script to revert the box back to a "clean" state several times, but I eventually got it.
Suggestion #1: Oh, for the record, the CentOS box was built with the "minimal installation" profile, which /doesn't include rsync/. It might be a good idea to add that to the list of packages to be installed by the iRedAdmin.sh script so things don't mysteriously fail when some of those shell scripts call rsync instead of cp.
Suggestion #2: The shiny new /etc/my.cnf the installer script provides /lacks/ an include line to bring in the rest of the files from /etc/my.conf.d/ which could leave some people in the lurch (and it's kind of bad practice to make that kind of an architectural change to the way the maintainers defaults work). Such a line should probably be added.
So, long story short, the default setup for MariaDB is pretty happy with everything that happens except for SOGo. SOGo is apparently incredibly sensitive to charset stuff. Without the workaround in place, the following symptoms occur:
* The transient box for password length claims to require an 8 character password ("but at least 0" what??) while the interface itself will only be satisfied with a _nine-character_ password. Yes that's very weird, and I didn't think it was related until I got past the SOGo problem and it went away as well.
* sogo-tool running from cron will fail, and in some cases may begin gobbling up 100% in a spin which is just loads of fun to workaround if you've waited more than a few minutes to login over ssh after a reboot.
* sogod itself just won't launch, with systemd throwing a red card after the default timeout has been reached.
* The only table sogo will have will be "users". (This is the big, obvious one!)
The solution is that immediately after MariaDB has been installed, but _before you even start it_ go ahead and drop these details (cobbled together from what's on the SOGo support docs) into /etc/my.conf.d/utf9mb4support.cnf
default-character-set = utf8mb4
default-character-set = utf8mb4
character-set-client-handshake = FALSE
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
innodb_file_per_table = TRUE
innodb_file_format = barracuda
innodb_large_prefix = TRUE
After that you can `systemctl enable mariadb && systemctl start mariadb` and do the dance of the mysql_secure_installation.
Also, since the EPEL version of gnustep and gnustep-libs are now a few teeny releases ahead of the one SOGo uses and are no longer 100% binary-compatible, various parts of SOGo will crash with a segmentation fault unless one forces yum to use the version from the SOGo repo. This tidbit was also found in SOGo forums, but here's the simple way to adjust the epel.repo from the command line:
yum-config-manager --save --setopt=epel.exclude=gnustep*
Note that if you have already installed the EPEL versions of gnustep or gnustep-libs, you'll need to /remove/ them and then reinstall them (after which the above directive will pull them from SOGo, not EPEL).