This article originally appeared on Chris Sanders’ blog
MAAS is designed to run in a data center where it expects to have control of DNS and DHCP. The use of an external DHCP server is listed as ‘may work but not supported’ in the MAAS documentation. This guide will describe how I configured MAAS to coexist with a home router with the router providing DHCP and DNS. Some of this will depend on the router allowing advanced configurations and not all routers will support it.
There are some limitations when MAAS doesn’t control DHCP and DNS but none of those limitations affect me in home lab use today. One day I might switch my DNS and DHCP from the consumer grade Asus I have today to a more robust solution. That’s a project for another day and another post, the configurations I describe here are a good stop-gap until that time.
If you already have a MAAS server you can skip directly to the Network Configuration section.
I’ve chosen to install MAAS in a LXD container. While this requires a minimal amount of extra setup it allows me to migrate the LXD to another machine in the future and keeps MAAS separated from anything else on the machine. I have a repository (maas-lxd) with some scripts and profiles to help set it up. You can use the buttons at the top of this post to star or fork the repository to make it easier to find later.
The README file from the maas-lxd repository explains how to use it but is intended to setup a self contained environment where LXD is providing NAT (the LXD default). For the home lab we’re going to modify that to use a bridged setup since we want MAAS to receive PXE requests from the network.
You’ll need to have LXD installed, here’s how you can do that with snaps.
$ sudo snap install lxd
On my host machine
br0 is a bridge I already have configured in
/etc/network/interface. Be sure you have a bridge ready for use, here’s my configuration as an example.
auto enp4s0 iface enp4s0 inet manual auto br0 iface br0 inet dhcp bridge-ifaces enp4s0 bridge-ports enp4s0 up ifconfig enp4s0 up
We want to reconfigure LXD to use this bridge so the containers will be bridged onto the network. To configure LXD to use
br0 instead of LXD’s default
lxdbr0. Use the configuration wizard.
$ sudo lxd init
LXD configuration isn’t the focus of this post, but if you want to learn more check it out on github.
Clone the maas-lxd repository:
$ git clone https://github.com/chris-sanders/maas-lxd.git $ cd maas-lxd
maas-profile, at the bottom modify the devices by removing the eth1 device and setting eth0 to use
devices: eth0: name: eth0 nictype: bridged - parent: lxdbr0 + parent: br0 type: nic - eth1: - name: eth1 - nictype: bridged - parent: lxdbr0 - type: nic
Also at the top of the profile modify the device configuration to match.
config: - type: physical name: eth0 subnets: - type: dhcp - - type: physical - name: eth1 - type: bridge name: br0 bridge_interfaces: - - eth1 + - eth0 subnets: - type: dhcp
We’re ready to create the container, run the make-maas.sh script with a single argument which is the name you want your container to have. I’m using the container name
maas-test for this setup.
$ ./make-maas.sh maas-test Creating container maas-test Creating maas-test Starting maas-test Sleeping to wait for IP LXC Stable branch not scripted for dnsmasq settings PXE will not work To install the backport: apt install -t xenial-backports lxc lxc-client MAAS will become available at: http://192.168.1.56/MAAS with user/password admin/admin
I’m doing this on Xenial, if you’re running a newer LXD you won’t see the error about ‘Stable branch’ shown above. It won’t affect anything we aren’t using the dnsmasq setting of LXD in this setup.
You can see the new container with lxd’s list command.
$ lxc list +---------------+---------+----------------------+------+------------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +---------------+---------+----------------------+------+------------+-----------+ | maas-test | RUNNING | 192.168.1.56 (eth0) | | PERSISTENT | 0 | +---------------+---------+----------------------+------+------------+-----------+
The container is running but it has a lot to install and configure. Cloud-init is installing packages for maas, bridge utils, qemu/kvm, and configuring a network for qemu. You can watch the progress in the container by tailing syslog from inside the container.
$ lxc exec maas-test -- tail -f /var/log/syslog
Once it has completed check that the
br0 interface was added on the container.
$ lxc list +---------------+---------+----------------------+------+------------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +---------------+---------+----------------------+------+------------+-----------+ | maas-test | RUNNING | 192.168.1.56 (eth0) | | PERSISTENT | 0 | | | | 192.168.1.56 (br0) | | | | +---------------+---------+----------------------+------+------------+-----------+
Having both interfaces dhcp will wreck havok on the containers networking, so remove the dhcp from
eth0 and let
br0 manage it.
$ lxc exec maas-test -- vim /etc/network/interfaces.d/50-cloud-init.cfg
Remove the line shown below.
auto lo iface lo inet loopback auto eth0 -iface eth0 inet dhcp auto br0 iface br0 inet dhcp bridge_ports eth0
Reboot the container
$ lxc restart maas-test
Now the container should have a single
$ lxc list +---------------+---------+----------------------+------+------------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +---------------+---------+----------------------+------+------------+-----------+ | maas-test | RUNNING | 192.168.1.56 (br0) | | PERSISTENT | 0 | +---------------+---------+----------------------+------+------------+-----------+
At this point you can log in at the URL that the make-maas script provided earlier.
MAAS will become available at: http://192.168.1.56/MAAS with user/password admin/admin
You should provide a static IP address for your MAAS container. If the IP address changes you will have to update configurations in maas and your router. There is a script in the scripts folder
set_url.sh which will update the IP address in MAAS if you want to do that now and set it to something different from what it got on dhcp.
In order for MAAS to commission a node and provide the operating system the machine must PXE boot from MAAS. This means the router that is providing DHCP will need to forward PXE requests to MAAS. Many consumer routers today will allow this as an advanced setting.
Containers created on MAAS managed machines do not DHCP. Instead they get a static IP assigned by MAAS. We will have to account for that when setting aside IP space, also those machines will not register with the routers DNS. MAAS deployed machines will show up in both DNS servers and MAAS deployed containers will only be in the MAAS DNS Server since they do not DHCP. Not a problem, just something to be aware of.
For IP space I’m be using.
To setup PXE requests to be redirected to MAAS you have to first enable SSH access to the router. The setting is found in
Administration/System/Services/Enable SSH. Set it to “LAN only”. Once set you can ssh into your router with the user/pass you use to log into the web UI.
$ ssh email@example.com
Once you’re on the router you want to edit the file /etc/dnsmasq.conf
admin@gateway:/tmp/home/root# vi /etc/dnsmasq.conf
Add the following line to the bottom, notice I’m using the MAAS address.
Now the router will provide DHCP and DNS but redirect PXE to MAAS.
Since we’re using IP space outside of the standard 192.168.1.x range that home routers frequently come configured with, the router needs to be configured to route the extra addresses in the 192.168.0.x range by adjusting the subnet mask from
This setting is found on the settings page
Add the MAAS IP as an additional DNS server, and be sure “Advertise router’s IP” is enabled. This will put MAAS first in the DNS list and the router second. If the MAAS machine is down for some reason DNS will work the same as before.
This setting is found on the settings page
When logging into MAAS for the first time set DNS forwarding to forward to the router.
If your MAAS is already running set it in
In MAAS go to the tab
Subnets and in the drop down box on the right labeled “Add” choose “Space”. Fill in the a name and click the green “Add space” button to save it. I used “home-space” for the name.
Now select the Subnet
192.168.0.0/23 from the table below. Verify that your CIDR, Gateway, and DNS are set correctly. These are the settings that match the IP table shown above and the subnetmask setup on the router. Additionally, add your space to the Space field.
Finally scroll down to the Reserved section and add reservations via the “Reserve range” button. Set reservations which cover the DHCP and Static assignments from the table above.
With this configuration MAAS will use IP address in the CIDR, which are not reserved, for assignemnt to LXD containers. MAAS and the local router are now configured so you can use MAAS without affecting the pre-maas network. DHCP/DNS from the router are still used and if MAAS is down it won’t affect your non-maas network clients.
Time to verify everything works with a KVM inside the MAAS LXD. That will confirm that MAAS is working as expected and the KVM can be used as the controller node for juju.
virsh-install is available in the container to create the VM but the –pxe option only applies to the first boot. A quick work around is to generate the VM, export the xml, destory the domain, and create it from the xml. At least you don’t have to write the xml file!
Run this command to get the KVM setup.
$ lxc exec maas-test -- virt-install \ --name=juju-controller \ --os-type=Linux \ --os-variant=ubuntu16.04 \ --ram=4096 \ --vcpus=2 \ --disk size=10 \ --pxe \ --network bridge:br0 \ --graphics vnc,listen=127.0.0.1 --noautoconsole &&\ lxc exec maas-test -- virsh dumpxml juju-controller > controller.xml &&\ lxc exec maas-test -- virsh destroy juju-controller &&\ lxc exec maas-test -- virsh undefine juju-controller &&\ lxc file push ./controller.xml maas-test/root/ &&\ lxc exec maas-test -- virsh define ./controller.xml &&\ lxc exec maas-test -- virsh start juju-controller
Once the VM finishes creation it should be picked up in MAAS under the “Nodes” tab.
Click on the node name and then the “Configuration” tab, configure the power setting for Virsh.
After saving, use the “Take Action” menu on the top right and choose “Commission” and then click the green “Commission machine” button to start.
Give MAAS some time and the node should enter the “Ready” state having passed commissioning. This verifies your PXE process is working and you have a KVM ready for bootstrapping a juju controller. This was by far the most manual processes of preparing my home lab. With this setup everything is in place to deploy software to bare metal and containers with MAAS providing the machines and juju managing the application configuration.
Ubuntu offers all the training, software infrastructure, tools, services and support you need for your public and private clouds.
With recent updates to MAAS and Curtin, deploying Ubuntu with a ZFS root disk is now possible! Curtin added zfsroot support earlier this year and MAAS has now exposed the option. ZFS is known for an amazing list of features: copy-on-write…
This article on Kubernetes & vSphere integration originally appeared at Kevin Monroe’s blog Background Recently, Juju began supporting cloud-native features via “integrator” charms (e.g.: aws-integrator, gcp-integrator,…
Introduction Managing a service with deployments in multi-cloud environments can be a challenge in terms of troubleshooting and scalability due to the complexity of dealing with different public cloud providers. An effective way to manage…