Install a license

This procedure puts the MooseFS PRO license file on the Master Servers and verifies that every Master Server runs under it. You need this procedure when you bring up a new PRO cluster. You need it again whenever you replace the license: after you raise its size, after you extend a license granted for a period, or after you move to a product version that the current license does not cover. How licensing works describes what a license is and what it limits.

A PRO installation always has a license. Every Master Server has a built-in 10 TiB license and runs under that license until you provide a license file of your own. A Master Server that finds no file at the configured path reports this in its log and starts: Can't load licence file /etc/mfs/mfslicence.bin (using built-in NONCOMMERCIAL). mfslicinfo then reports that license with type NON-COMMERCIAL, no expiry, and a maximum version equal to the version running. This built-in license is the Personal license, which serves personal, non-commercial use only. PRO Personal covers the terms of each license type.

Each Master Server reads a local license file

The license comes as a single file, mfslicence.bin. A Master Server reads the file from its own disk. The LICENSE_FILENAME option in mfsmaster.cfg holds the full path to the file, not a bare file name. The default is /etc/mfs/mfslicense.bin (/usr/local/etc/mfs/mfslicense.bin on FreeBSD). A license stored at that path needs no configuration at all. If your file is elsewhere, or has another name (older licenses were sometimes delivered with a different extension, .key among them), set the option to its full path:

LICENSE_FILENAME = /etc/mfs/mfslicense.bin

The Master Server re-reads the file on every process reload, whether or not the path changed. Because the path is local, a cluster with several Master Servers needs the file installed on each of them.

A Master Server that cannot open the file at that path runs on its built-in license instead. A Master Server that opens a file and then cannot load it stops with an error. It does not fall back to the built-in license. How licensing works compares the two cases.

The Master Server opens the file as the account that it runs as, not as root. Before it reads the license, the process switches to WORKING_USER (mfs in the MooseFS packages). The process therefore cannot open a file that root owns with mode 640. Make mfs the owner of the file, or leave the owner as root and set mode 644. A reload reads the file as the same account. A Master Server that cannot read the file logs a warning and falls back to the built-in license, on a reload as well as at startup. Wrong permissions therefore cost a running cluster the license it ran under. Only the system log has that warning. Neither mfsmaster start nor mfsmaster reload prints it. The output of the command ends with mfsmaster daemon initialized properly and says nothing about the license. Read the license from mfslicinfo, not from that output.

The same file also entitles Windows Clients. A Windows Client checks its entitlement through the Master Server that it connects to. Install clients describes how to install Windows Clients.

Install the license on a new cluster

1. Copy mfslicence.bin into /etc/mfs/ on every Master Server, or put it at the path that LICENSE_FILENAME points to and set that option in each Master Server's mfsmaster.cfg. Give the file an owner and permissions that let the account in WORKING_USER read it.
2. Start the Master Servers, as described in Starting and stopping.
3. Confirm with mfslicinfo that every Master Server reports the license that you purchased.

Replace the license on a running cluster

A running Master Server loads the new license on a configuration reload. No restart is needed. Work on one Master Server at a time and verify it before you move to the next.

Update the Followers first and the Leader last. A file that the Master Server can open but not load stops the process during the reload itself, not at the next start. On a Follower this mistake costs less, because the Leader keeps serving. By the time the Leader's turn comes, at least one Follower already runs under the new license. The same mistake on the Leader moves the Leader role to a Follower instead. The handover is safe, but the cluster takes seconds to stabilize.

1. Place the new mfslicence.bin at the path that LICENSE_FILENAME points to on this Master Server. When the previous license file has a different name or path, replace that file or update the option. Keep the owner and permissions that let the account in WORKING_USER read it.

2. Reload the Master Server (the reload action is described in mfsmaster(8)):

   mfsmaster reload

   If the Master Server runs with a configuration file outside the default location, name it with -c:

   mfsmaster -c /path/to/mfsmaster.cfg reload

   Then run the same command a second time. The second reload refreshes the quotas. A license replacement needs that refresh.

3. Check the most recent mfsmaster entries in the system log and confirm that they contain neither an error nor a warning about the license. When this Master Server cannot read the file, it logs (using built-in NONCOMMERCIAL) at warning severity and stays on its built-in license.

4. Confirm that this Master Server reports the new license:

   mfslicinfo 192.0.2.10

Repeat these steps on every remaining Master Server.

Verify that all Master Servers run under the same license

mfslicinfo ships in the CLI package rather than the master package (Install server components), so run it wherever the CLI package is installed. The tool queries each Master Server named on its command line on the client port (9421, see Network ports). The tool prints the license that each Master Server reports. The tool expands a host name to every IPv4 address that the name resolves to. A name that resolves to all Master Servers therefore checks the whole cluster in one call. With no argument, the tool queries the name mfsmaster:

mfslicinfo mfsmaster

All 3 masters share the same licence.

Masters (3): mfsmaster (192.0.2.10):9421, mfsmaster (192.0.2.11):9421, mfsmaster (192.0.2.12):9421
+---------------------------------------+
| Master version     : 5.1.0 PRO        |
| Licence ID         : 0123456789ABCDEF |
| Issuer             : Saglabs SA       |
| Client             : Example Company  |
| cluster            : MainStorage      |
| Type               : COMMERCIAL       |
| Max version        : 5.x              |
| Expires            : never            |
| Max raw data usage : 20 TiB           |
+---------------------------------------+

When the Master Servers report different licenses, each distinct license is printed in its own block, together with the list of Master Servers that report it. Go back to the Master Servers that are listed under the wrong license. Master Servers that cannot be reached are listed in error blocks and make the exit status non-zero (see mfslicinfo(1)).

mfscli prints the same data in its license section:

mfscli -SLI -H mfsmaster

In the GUI, the license properties are in the Licence info table on the Info tab:

The Licence info table on a cluster that has not been given a license file: NON-COMMERCIAL in Type, no client, and a maximum version equal to the version running. A cluster under a license of your own reports that license in the same table.

The license limit also appears on the Quotas tab, as the quota with path *. The Master Server keeps one cluster-wide quota to compare the current raw data usage against the license.

The license limit as the cluster-wide quota with path *, in row 1 of the Quotas tab. The quota is a soft limit on real size. That limit is the only figure that this quota has.

Alerts warn before expiry and before the cap

A time-limited license raises a warning in the GUI when less than 30 days remain, and an error once the license expires. After the expiry date the cluster shuts down. A size-limited license raises a warning when the current raw data usage crosses 80% of the licensed size. It raises an error at 95% and again when the usage reaches the limit. From that point no new data can be written. A Master Server whose product version is newer than the license covers does not start. It prints Version in licence too old on the screen and in the system log. The Alerts reference lists the exact messages and the suggested solutions.