How can I manage customer access across different facilities?

This guide covers configuring Foreman so operators have limited access to the miners at their facility, but customers are able to access their miners globally across all sites.

As cryptocurrency mining continues to grow, hosts are scaling their operations to span multiple geographic locations in search of competitively priced power.  For self-miners, separate sites are generally managed by different sets of operators.  Configuring Foreman for this model is relatively straightforward (guide here).

For colocation, however, there's additional complexity.  Each site's miners should only be manageable by the operators at that site, but customers may now cross site boundaries (example: a hosting company may have facilities in Ohio and Baltimore, each managed by different sets of operators, but half of Customer A's miners may be in Ohio and the other half may be in Baltimore).

This guide covers configuring Foreman for this model, where operators have limited access to the miners at their facility, but customers are able to access their miners globally across all sites.

Adding Sites

Your Foreman account should initially be created under the assumption that it will be the global parent; it will only provide a global view of miners across all sites.

For this example, assume we have a hosting company called Mine Magik and we're managing two different sites: one in Baltimore, MD and one in Canton, OH.

Under the Mine Magik parent account, click Add Client at the top of Foreman and create separate sub-clients for each location.

Configuring a Site

Running with GUARDrail

To install Foreman with GUARDrail, run the following command from a terminal:

curl https://tinyurl.com/service-install -Ls --output install.sh; GUARDRAIL=true sudo bash -E install.sh 0 0

The installation will take a few minutes.  Once it's complete, you can configure GUARDrail by opening a browser and accessing http://<computer_ip_address>:25452/.  You should see a page similar to the following:

The Client ID and API Key can be obtained from here.  These must be the credentials from the sub-client account.  In this example, this would be from the Baltimore sub-client.  Once those values are provided, a Pickaxe agent should appear here within ~1 minute.  We recommend that you name it to match the site name.

Now, it's time to import miners.  Follow the guide here.  When importing, you'll be prompted for how you'd like to name miners.  We recommend that you name them by miner worker name.

If IP restrictions were set in GUARDrail, only the IP addresses that are allowed will be reachable.  We believe in transparency.  GUARDrail is queried here every 30 seconds for restrictions that you apply. This is the code that we use to filter IPs.  Commands are discarded here and IPs are ignored here if somebody tries to manage a device that's out of scope.  Nothing gets through unless you allow it locally at the facility.

Running without GUARDrail

GUARDrail usage is not required and it's rarely used.  It's only intended for situations where the host wants to limit what miners can be managed by Foreman.  To install Foreman without it, follow the installation guide here.

When configuring a sub-client/site, it's important that the installation procedures be followed from the sub-client (select the appropriate site at the top, switch to it, and then proceed with the installation guide).  Pickaxe, our metrics agent, must be linked to the site and the installation guide changes depending on the client/site that you're viewing.

Now, it's time to import miners.  Follow the guide here.  When importing, you'll be prompted how you'd like to name miners.  We recommend that you name them by miner worker name.

Finalizing the Site

Now that Foreman is up and running, from the Site dashboard (Baltimore), go to My Company top-right, invite other operators at the site, and create custom permissions to limit what they can do.  You don't need to add anybody on the global parent account.  They get access by default.

Providing Customer Access

Now that we've configured a site and added some miners, it's time to give the customer access.  For this next step, transition back to the global parent account, which is Mine Magik in this example.

Similar to how a sub-dashboard was created for a site, repeat that process, but this time, name the sub-client by the customer.  For this example, we'll assume the client's name is Client A.

Now, select the miners that belong to that user from the table, click the Edit button, and assign them to the customer.

Then, switch to Client A's sub-dashboard and send them an invite from My Company top-right.

What This Does

For this example, the operators at Baltimore can still see and manage the miners that belong to Client A at their site.  The same goes for Canton - the operators there are unaffected.

Everything can be viewed globally from the parent account, but more importantly, Client A can now see their miners directly from their own private dashboard even though they're deployed across multiple locations.  They're also free to customize their dashboard as they find most useful.

Creating a Trigger to Auto-Assign Client Ownership

Now that you have your clients created and permissioned, you can create a trigger to automatically assign new miners to clients based on a set criteria. Setting a client ownership trigger saves the effort of having to bulk edit and assign every time a new miner comes online for a client.

From your parent dashboard, enter the 'Alerts & Triggers' tab and click on the 'Add Trigger' button. In the example below, the trigger is set to auto-assign miners to client John anytime a new miner comes online in the Texas 1 facility in the IP Range that is specified.