MAAS supports the following modes, which dictate what services will run on the local system:
||X||Region API server only|
||X||Rack controller only|
||X||X||Region API server and rack controller|
||Reinitialises MAAS and stops services|
MAAS uses your Launchpad or Github SSH keys to access machines that have been deployed. Normally, you enter this key during the initialisation of MAAS. If you don’t have a key associated with either of these services, you will have an opportunity to paste your public key into the MAAS SSH key list, after you’ve started MAAS for the first time as part of the welcome screens.
All run modes (except
none) prompt for a MAAS URL, interpreted differently depending on the mode:
region: Used to create a new region controller.
rack: Used to locate the region controller.
The ‘rack’ and ‘region+rack’ modes will additionally ask for a shared secret that will allow the new rack controller to register with the region controller.
This article will show you:
- How to check system requirements for MAAS
- How to upgrade from MAAS 2.8 or lower to MAAS 2.9
- How to do a fresh install of MAAS 2.9 from packages
- How to create a MAAS user
- How to check the status of MAAS services
- How to re-initialise MAAS
- How to list additional MAAS initialisation options
- How to configure MAAS
Note that all headings are hyperlinks for bookmarking.
Before installing MAAS for the first time, you should make sure that the target system meets the minimum requirements for the machines that run MAAS, which vary widely depending on local implementation and usage. Below, you will find resource estimates based on MAAS components and operating system (Ubuntu Server). We consider both a test configuration (for proof of concept) and a production environment.
Here is a proof-of-concept scenario, with all MAAS components installed on a single host. This scenario assumes two complete sets of images (latest two Ubuntu LTS releases) for a single architecture (amd64).
|Memory (MB)||CPU (GHz)||Disk (GB)|
|Region controller (minus PostgreSQL)||512||0.5||5|
|Ubuntu Server (including logs)||512||0.5||5|
Based on this table, the approximate requirements for this scenario are 2 GB memory, 2 GHz CPU, and 20 GB of disk space.
Here is a production scenario designed to handle a high number of sustained client connections. This scenario implements both high availability (region and rack) and load balancing (region). MAAS reserves extra space for images (database and rack controller), while some images, such as those for Microsoft Windows, may require a lot more – so plan accordingly.
|Memory (MB)||CPU (GHz)||Disk (GB)|
|Region controller (minus PostgreSQL)||2048||2.0||5|
|Ubuntu Server (including logs)||512||0.5||5|
So, based on the above, the approximate requirements for this scenario are:
- A region controller (including PostgreSQL) installed on one host, with 4.5 GB memory, 4.5 GHz CPU, and 45 GB of disk space.
- A duplicate region controller (including PostgreSQL) on a second host, also with 4.5 GB memory, 4.5 GHz CPU, and 45 GB of disk space.
- A rack controller installed on a third host, with 2.5 GB memory, 2.5 GHz CPU, and 40 GB of disk space.
- A duplicate rack controller on a fourth host, also with 2.5 GB memory, 2.5 GHz CPU, and 40 GB of disk space.
The tables above refer to MAAS infrastructure only. They do not cover the resources needed by subsequently-added nodes. Note that machines should have IPMI-based BMC controllers for power cycling, see Power management for more details.
Some examples of factors that influence hardware specifications include:
- the number of connecting clients (client activity)
- how you decide to distribute services
- whether or not you use high availability/load balancing.
- the number of images that you choose to store (disk space affecting PostgreSQL and the rack controller)
Also, this discussion does not take into account a possible local image mirror, which would be a large consumer of disk space.
One rack controller should only service 1000 machines or less, regardless of how you distribute them across subnets. There is no load balancing at the rack level, so you will need additional, independent rack controllers. Each controller must service its own subnet(s).
MAAS 2.8 is the last supported version for Ubuntu 18.04 LTS. Newer versions of MAAS will not be back-portable, and consequently, to upgrade to MAAS 2.9 and all future versions, you will also need to upgrade the base operating system to Ubuntu 20.04. You do these two operations all at once, with the following procedure:
sudo add-apt-repository ppa:maas/2.9
You will get a message similar to this:
For stable releases of 2.9.x More info: https://launchpad.net/~maas/+archive/ubuntu/2.9 Press [ENTER] to continue or Ctrl-c to cancel adding it. Hit:1 http://security.ubuntu.com/ubuntu bionic-security InRelease Hit:2 http://ppa.launchpad.net/maas/2.8/ubuntu bionic InRelease Hit:3 http://archive.ubuntu.com/ubuntu bionic InRelease Hit:4 http://archive.ubuntu.com/ubuntu bionic-updates InRelease Ign:5 http://ppa.launchpad.net/maas/2.9/ubuntu bionic InRelease Hit:6 http://archive.ubuntu.com/ubuntu bionic-backports InRelease Err:7 http://ppa.launchpad.net/maas/2.9/ubuntu bionic Release 404 Not Found [IP: 184.108.40.206 80] Reading package lists... Done E: The repository 'http://ppa.launchpad.net/maas/2.9/ubuntu bionic Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details.
This message seems to indicate that nothing happened, but, in fact, this command still creates the file:
This file identifies the path to the 2.9 PPA, even though it incorrectly implies there’s a Bionic release there:
deb http://ppa.launchpad.net/maas/2.9/ubuntu bionic main
Still, that’s enough for
do-release-upgrade to figure out that there is a 2.9 PPA, and when it checks, it will find a Focal version of MAAS, which it will bring over and install in place of 2.8. It isn’t necessary to stop MAAS or do anything else, except go ahead and run the upgrade:
sudo do-release-upgrade --allow-third-party
This command will produce a lot of output, ask you a few questions (for which the defaults are usually fine), and eventually ask you to reboot. Once your machine has come back up, you can check whether your upgrade has been successful by entering:
If the ugprade was successful, this command should yield output similar to the following:
No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.1 LTS Release: 20.04 Codename: focal
You have now upgraded to the Ubuntu 20.04 LTS base, and if you check your running MAAS install, you should see that the version has been updated to the latest stable 2.9 release.
The recommended way to set up an initial MAAS environment is to put everything on one machine:
sudo apt-get -y install maas
Executing this command leads you to a list of dependent packages to be installed, and a summary prompt that lets you choose whether to continue with the install:
Choosing “Y” proceeds with a standard
apt package install.
For a more distributed environment, you can place the region controller on one machine:
sudo apt install maas-region-controller
and the rack controller on another:
sudo apt install maas-rack-controller sudo maas-rack register
These two steps will lead you through two similar
apt install sequences.
You will need to create a MAAS administrator user to access the web UI:
sudo maas createadmin --username=$PROFILE --email=$EMAIL_ADDRESS
$PROFILE is the administrative MAAS username you wish to create. $EMAIL_ADDRESS is an email address you may type in at random (currently, MAAS does not use this email address).
createadmin option will ask for an SSH key. If you have an SSH key associated with your launchpad or github accounts, you can enter the username here to use the associated key. For launchpad, just enter
lp:username, and for github, enter
gh:username at the prompt. In both cases, the actual username has to be supplied after the
You can check the status of running services with:
sudo maas status
Typically, the output looks something like this:
bind9 RUNNING pid 7999, uptime 0:09:17 dhcpd STOPPED Not started dhcpd6 STOPPED Not started ntp RUNNING pid 8598, uptime 0:05:42 postgresql RUNNING pid 8001, uptime 0:09:17 proxy STOPPED Not started rackd RUNNING pid 8000, uptime 0:09:17 regiond:regiond-0 RUNNING pid 8003, uptime 0:09:17 regiond:regiond-1 RUNNING pid 8008, uptime 0:09:17 regiond:regiond-2 RUNNING pid 8005, uptime 0:09:17 regiond:regiond-3 RUNNING pid 8015, uptime 0:09:17 tgt RUNNING pid 8040, uptime 0:09:15
It is also possible to re-initialise MAAS to switch modes. For example, to switch from
sudo maas init region
init command can takes optional arguments. To list them, as well as read a brief description of each, you can enter:
sudo maas init --help
Once you’ve successfully installed MAAS (regardless of method), you can now login here:
where $API_HOST is the hostname or IP address of the region API server, which was set during installation. You will see a screen like this:
Log in at the prompts, with the login information you created when initialising MAAS.
After a fresh MAAS installation, the web UI presents a couple of welcome screens. From these screens, you can set many system-wide options, including connectivity, image downloads, and authentication keys.
Your main concerns for this experiment are the DNS forwarder, the Ubuntu image import section, and the SSH public key, though you might want to set the region name to something memorable, since this text will appear at the bottom of every MAAS screen in this install domain. Set the DNS forwarder to something obvious, e.g.,
220.127.116.11, Google’s DNS server. Set this to your own internal DNS server if you know the IP address.
Select an Ubuntu image to import, noting that you may be required to select at least one LTS version, depending upon the version of MAAS that snap installed. In this example, we’ve already chosen an image, and downloading is partially complete.
When you click on “Continue,” the screen will shift to a screen labelled, “SSH keys for admin:”
In the source drop-down, select “Launchpad,” “Github,” or “Upload.” If you choose one of the first two, you will need to enter your username for that service. For example, if you want to upload your SSH public key from Launchpad, you would enter:
Likewise, if you want to upload your github public SSH key, you would enter:
If you want to use your existing public key from your home directory, you can select “Upload”and then copy your entire public key from
.ssh/id_rsa.pub (or wherever you may have stored the key):
and paste it into the block labelled “Public key.” Finally, press the “Import” button to import this key:
With this complete, you’ll see that MAAS has been successfully set up. Click ‘Go to the Dashboard’ to proceed.
Note that you may have to wait a few moments for your selected images to sync locally.
Before moving forward with MAAS, you’ll want to enable DHCP. You can do this very easily from the web UI by selecting “Subnets” from the top menu, choosing the VLAN on which you want to enable DHCP, and select the button marked, “Enable DHCP.”
The Dashboard landing page lists non-registered devices that MAAS detected automatically on the network. This network discovery process allows you to easily add or map devices already connected to your network – devices that you may not necessarily want to manage with MAAS.