Install Mattermost in /home/domain instead of /opt

Troubleshooting
1

Hopefully this is the right place for this.

Summary

I would like to install Mattermost in my Apache vhost directory instead of /opt so that each domain can have it’s own forums in a virtual hosting environment.

Steps to reproduce

I have followed the Debian Jessie install instructions with Postgres, my vhosts are managed by the latest version of virtualmin (5.04). I am also running Mattermost 3.2.0. Debian and all packages are fully upgraded and running the latest versions. I am only running packages from the official debian repositories.

To reproduce my setup, install the latest debian, selecting only ssh server - no other services or desktops. Download and install the free 10 doamin version of Virtualmin which will install and configure apache, email, etc. Install PostgreSQL from inside Virtualmin. Virtual hosting will also be setup. Create a domain and enable PostgreSQL as the database for that domain, then create a subdomain. Install Mattermost into the subdomain (or parent domain if you prefer) following the Mattermost installation guide for Debian Jessie but not installing Postgres as it is already installed. Integrate the vhost info into the domain.conf or sub.domain.conf depending on where you want to access Mattermost. After following the instructions including tests, you should have a functioning install.

Now try having Mattermost run from /home/domain/mattermost or /home/domain/domains/sub-domain/mattermost or even just put the data directory in those locations with permissions for the mattermost directory structure owned by mattermost:mattermost.

Alternatively, leaving mattermost fully installed and running from /opt/mattermost, create domain2 and then set it up so that it also accesses the same server - without exposing the first domains teams.

Expected behavior

I would like to be able to have mattermost run completely from inside a vhost so that I can cleanly migrate or backup all domain assets as the occasion arises.

Observed behavior

Everything is working from /opt/mattermost, but if I move it to /home/domain/mattermost then it does not run, or try to put the data directory in /home/domain/mattermost/data then none of that profile images work, etc.

Alternatively, I want to be able to run mattermost from domain, domain1, etc. I haven’t tried this config yet and it might actually work. I will hopefully be testing the second option in the next couple of days, but it would still be nice to have the data stored in the domain for migration purposes as well as backup and restore.

2

@tripkin I know this post is ancient, but I have the same inquiry. Were you able to get it working within the confines of a Virtualmin virtual server?

Thanks.

3

Hi @infected and welcome to the Mattermost forums!

Mattermost should work just fine in a separate directory, it does not need to be /opt/mattermost. In fact, all the directories in the configuration file are relative to the base current working directory where Mattermost is being executed, so when you extract it to /home/youruser/mattermost, f.ex., just make sure your current working directory is /home/youruser/mattermost when you execute bin/mattermost from there.
It also does not need to run with the mattermost account, it can be any account, but the folders need to be writeable by this account.

Did you try that already and if so, can you describe your setup and the errors you’re seeing?

4

@agriesser It sounds like your recommendation is using the tarball installation method, is this correct? If so, is it possible to install it to a home directly through apt or dpkg, and thereby hopefully allowing cleaner package upgrades in the future (when compared to the tarball install)?

Thanks.

5

The apt package does not allow for specifying the install path, so that’s why I suggested the tarball method.
The mattermost binary supports the -c parameter which allows for specifying a config file per invocation, so in theory it could be possible to fork multiple instances off of one central directory, but I would not really fiddle around with that because you have to duplicate most of the directories anyways and I’m not sure about locks on the shared files then.

It would be an interesting usecase to have the systemd unit of the apt package support multiple instances with different config files though.