The docs for installing integrated mattermost with HTTPS say:
Place the SSL certificate and SSL certificate key inside
/etc/gitlab/ssl
i.e. it sounds like it’s not going to get a certificate for you like it does for the GitLab installation. Is this correct? Do I have to obtain and manage the certificate for mattermost? Or is this documentation outdated?
After running reconfigure after setting the mattermost external URL (using HTTPS), it seems that it does indeed obtain a certificate automatically (so the docs are wrong), however, it’s very odd that the hostname for the mattermost service does not appear at all in the output from reconfigure.
After that, I can reach the mattermost URL, but it just gives me a 502 bad gateway. Running gitlab-ctl restart doesn’t help, and gitlab-ctl status mattermost shows it is down. Logs show it’s throwing this error about once per second:
chpst: fatal: unable to run: /opt/gitlab/embedded/bin/mattermost: exec format error
Searching for that didn’t find me anything 
Any ideas?
Aha. file /opt/gitlab/embedded/bin/mattermost:
/opt/gitlab/embedded/bin/mattermost: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=7kt7GwN6TFz1Y-
35GULl/RM95CJKVi_UY_oV17cJr/Y35wScs4bx7UJxhUel1b/C0zRU_SjMHnx-g7i2h6n, with
debug_info, not stripped
This would explain the “exec format error”: I’m running on an ARM CPU, so it’s not going to be able to run a x84-64 binary.
How can I get omnibus to install ARM binaries instead?
I gather from various people that have tried to install Mattermost on RPi that Mattermost aarch64 binary packages are not available, even though they are for GitLab, so this breaks the omnibus install. There is a project that builds Mattermost for other architectures, but it’s unsupported and only has outdated builds. Hm. I really don’t want to think about building Mattermost from source, so it looks like I will have to do without Mattermost altogether.
It seems that Mattermost is the only part of the Omnibus stack that does not provide aarch64 packages, and while it will build for that architecture, they are not officially supported. This bug report in omnibus documents the problem.
This is something of a shame - I’ve just migrated GitLab from a 4-core AMD64 instance to a single-core ARM (Ampere) VM, and as well as being substantially cheaper, it is much, much faster.
Hi @MarcusCC! 
I see you’ve done some extensive troubleshooting and I appreciate your detailed posts. You’re correct on both accounts.
The documentation instructing you to place your own SSL certificate and key within the /etc/gitlab/ssl directory is only relevant if you wish to use your own custom certificate.
If you don’t want or need to provide your own certificate, you can use the Let’s Encrypt integration, and GitLab will attempt to obtain a Let’s Encrypt certificate for your Mattermost instance as well.
Mattermost officially supports any 64-bit x86 processor architecture. If/when Mattermost officially supports ARM, we have issues to discuss adding arm64 version of mattermost to GitLab here:
Thanks for providing background. It’s a shame that MM is the only thing left to fix here! I guess I’ll archive my old data and restore it when the ARM64 build is available, and use something else in the mean time.
Regarding my original question, it would help to mention this in the docs, as it doesn’t mention that this is optional - the title is simply “Running GitLab Mattermost with HTTPS”, which is obviously something I want to do, and so it leads me astray. A little mention that it will be handled automatically by default would remove this ambiguity.