Install the server components

This procedure installs the MooseFS server packages on every machine that runs a server role: Master Server, Chunkserver, Metalogger, and the GUI and CLI. The packages come from the repositories added in Prepare the operating system. The procedure leaves each service installed and minimally configured, and every service except the Master Server enabled. Starting and stopping describes how to bring the cluster up in the right order. Machines that only mount the file system get their packages in Install clients.

Command examples use apt. On the RHEL family, replace apt install with dnf install. On FreeBSD, replace it with pkg install. FreeBSD has no systemd: a service is enabled by a line in /etc/rc.conf, written with sysrc mfschunkserver_enable=YES, and started with service mfschunkserver start. The Master Server's startup script contains nostart, so on FreeBSD the Master Server does not start with the machine even when its line is in place.

The package name carries the edition

MooseFS PRO and the Community Edition ship the same set of server packages. The PRO name has a -pro infix that the CE name does not have. The same rule names the systemd services: moosefs-pro-master.service in PRO is moosefs-master.service in CE. Examples on this page use the PRO names. The editions are released on separate lines, so the two sets of packages also come from separate repository paths.

Role	MooseFS PRO package	Community Edition package
Master Server	moosefs-pro-master	moosefs-master
Metalogger	moosefs-pro-metalogger	moosefs-metalogger
Chunkserver	moosefs-pro-chunkserver	moosefs-chunkserver
GUI	moosefs-pro-gui	moosefs-gui
CLI	moosefs-pro-cli	moosefs-cli

Each package contains its daemon together with the tools of its role. The Master Server package adds mfssupervisor and the metadata tools. The Chunkserver package adds the chunk file tools. The PRO CLI package adds mfslicinfo PRO (PRO Edition only). The full list is in Command-line tools.

Installation also creates what the daemons expect:

• the system user and group mfs, created if absent. The server processes run as this user.
• the configuration files in /etc/mfs (/usr/local/etc/mfs on FreeBSD), each created from its shipped .cfg.sample template when the file does not exist yet. That way a fresh install starts from the defaults. An upgrade never overwrites an edited file.
• the working directory /var/lib/mfs (/var/mfs on FreeBSD), owned by mfs.

You do not copy the .sample files by hand.

Install the Master Server first

Every other component connects to the Master Server, so give the Master Server its package first. Starting and stopping covers the start order that follows from this.

apt install moosefs-pro-master

The package puts mfsmaster.cfg, mfsexports.cfg, and mfstopology.cfg in /etc/mfs, each copied from the .cfg.sample file that the package includes. The package also puts an empty metadata file at /var/lib/mfs/metadata.mfs, so the first start brings up an empty file system. The package copies mfsipmap.cfg from its sample file the same way. The FreeBSD package leaves only metadata.mfs.empty in the data directory, so a first start there fails with init: metadata manager failed !!! until that file is copied to metadata.mfs. A single Master Server starts with the shipped defaults. Nothing in mfsmaster.cfg needs a value first.

Two things deserve attention before that start:

• As shipped, mfsexports.cfg exports the whole tree to every host read-write, with administrative privileges and with root left unmapped. The file also exports the meta directory read-write. These defaults are enough to bring a cluster up and verify it. Access control describes how to restrict who mounts what.
• A PRO Master Server PRO (PRO Edition only) reads its license from the path in LICENSE_FILENAME, by default /etc/mfs/mfslicense.bin (/usr/local/etc/mfs/mfslicense.bin on FreeBSD). Install a license describes how to get and install the file.

Do not leave the unit enabled. A Master Server that starts with the machine after an unclean stop finds no clean metadata image. The plain start therefore fails and keeps failing. On Debian and Ubuntu the package enables the unit itself, so disable the unit after installation:

systemctl disable moosefs-pro-master.service

On the RHEL family the package enables nothing. On FreeBSD the service stays off until rc.conf says otherwise. A person has to check the state that an unclean stop leaves. For the reasoning, and for what to do instead of automating the start, see starting and stopping the cluster.

A Chunkserver needs a master address and disk directories

Install the package on every machine that will store chunks:

apt install moosefs-pro-chunkserver

Two settings make the Chunkserver useful, both in /etc/mfs:

1. In mfschunkserver.cfg, set MASTER_HOST to the name that the Master Server is reachable at. The default is mfsmaster, so if that host name resolves to your Master Server, the file needs no change. An IP address works here only in a single-master installation.

2. In mfshdd.cfg, add one line per directory that stores chunks. Use the file systems prepared in Prepare the operating system:

   /mnt/chunk01

   As shipped, the file contains only comments: a Chunkserver started with that file runs but stores no chunks. mfshdd.cfg(5) describes prefixes and per-directory space limits.

The example names one directory. A machine with several data disks needs one line per disk. The Chunkserver process runs as user mfs. The process creates its files inside each listed directory, including a .lock file. Make that user the owner of every listed directory:

chown mfs:mfs /mnt/chunk01

Enable the service:

systemctl enable moosefs-pro-chunkserver.service

Repeat these steps on every Chunkserver machine.

A Metalogger takes one package and one setting

A Metalogger keeps an on-disk copy of the Master Server's metadata on a machine of its own. The Metalogger machine covers whether your cluster needs a Metalogger and which machine to use for it.

apt install moosefs-pro-metalogger

The Metalogger needs one setting, the master address: MASTER_HOST in mfsmetalogger.cfg, with the same mfsmaster default as on a Chunkserver. Then enable the service:

systemctl enable moosefs-pro-metalogger.service

The GUI and the CLI install anywhere reachable

The GUI and mfscli are clients of the cluster: they run on any machine that reaches the Master Server's ports. The GUI, the CLI, and the Prometheus exporter covers their place in the architecture.

apt install moosefs-pro-gui

The GUI package installs the CLI package as a dependency. On a machine that only needs the terminal tool, install moosefs-pro-cli alone.

The GUI is served by its own daemon, mfsgui, configured in mfsgui.cfg. No setting is required before the first start. Once the daemon runs, the interface answers on HTTP port 9425. Network ports lists that port with the other ports. Older releases served this interface through mfscgiserv from separate CGI packages. The GUI package replaces those packages. mfscgiserv remains only as a stub that points to mfsgui.

The GUI has no login of its own: whoever reaches its port sees the cluster. Secure that port separately from the rest of the installation, at the latest when the cluster goes into production. Keep the port away from untrusted networks with a firewall, or bind it to localhost and put an authenticating reverse proxy in front of it. Access control describes the options, with a worked proxy example.

Enable the service:

systemctl enable moosefs-pro-gui.service

Each binary confirms its installation

Every binary prints its version without contacting the cluster, so the check works before anything is started:

mfsmaster -v
mfschunkserver -v
mfsmetalogger -v
mfsgui -v
mfscli -v

Run the command that matches the role of each machine. It prints the installed MooseFS version. When every machine prints its version, the packages are in place and the cluster is ready to be brought up: continue with Install a license PRO (PRO Edition only) and Starting and stopping.