Errors or typos? Topics missing? Hard to read? Let us know.
Problem: Deployment of a JUJU controller or an OS directly on a node fails with the error “cloud-init Data source not found.”
Environment: - MAAS version: stable (2.8 mentioned) - Single NIC for MAAS node and JUJU controller node - Ubuntu 16.04 and 18.04 tried
Potential causes and solutions:
maas $profile subnet update $subnet_id dns_servers="[$MAAS_IP]"maas $profile maas set-config name=http_proxy value="http://proxy.example.com:8000/"
maas $profile maas set-config name=http_proxy value=""sudo systemctl restart maas-rackd maas-regiond# Ensure DNS is correctly set
maas admin subnet update $subnet_id dns_servers="[$MAAS_IP]"
# Restart MAAS services
sudo systemctl restart maas-rackd maas-regiond
# Check MAAS logs
# insert relevant commands hereBy following these steps and checking these configurations, you should be able to resolve the “cloud-init Data source not found” error and successfully deploy your OS using MAAS.
Problem: MAAS restarted after an update, causing DNS to fail due to duplicate subnets and configurations. This led to BIND9 failing to start, creating repeated crashes and restarts of the DNS service.
Solution:
Run the following command to list all subnets and identify duplicates:
maas $profile subnets readIdentify any duplicate subnets in the output. Pay special attention to subnets with odd subnet masks or those that appear more than once.
Remove the duplicate subnets using the MAAS CLI or web interface:
maas $profile subnet delete $subnet_idAfter removing the duplicate subnets, restart the MAAS services to apply the changes:
sudo systemctl restart maas-regiond maas-rackdCheck the DNS configuration files to ensure there are no remaining issues. The relevant files can be found in:
# deb
/etc/bind/maas/
# snap
/var/snap/maas/current/bind/If you wish to decouple DNS entirely from MAAS and use an external DNS server, you can disable the MAAS-managed DNS service:
sudo maas $profile dns update 1 enabled=falseConfigure your external DNS server to handle all DNS queries.
# List all subnets to find duplicates
maas admin subnets read
# Delete a problematic subnet (replace $subnet_id with the actual ID)
maas admin subnet delete $subnet_id
# Restart MAAS services to apply changes
sudo systemctl restart maas-regiond maas-rackd
# Disable MAAS-managed DNS
sudo maas admin dns update 1 enabled=falseBy following these steps, you can decouple DNS from MAAS, resolve configuration issues, and ensure a stable DNS environment for your OpenStack cluster and other services.
Problem: You have managed to deploy machines with two NICs using MAAS. The first NIC uses PXE/DHCP, but configuring the second NIC to use external DHCP is proving challenging.
Solution:
eth1 or ens19).eth1 or ens19).ip a or ifconfig to check if the second NIC has acquired an IP address from the external DHCP server.ip aBy following these steps, you should be able to configure the second NIC on a machine deployed with MAAS to use an external DHCP server for IP address allocation.
Problem: A user was trying to set up MAAS with an existing DHCP server on an Edgerouter 12. However, when attempting to PXE boot machines, they received a ‘no media found’ error. The goal was to use MAAS without creating VLANs or replacing the existing DHCP server.
Solution:
The user ultimately resolved the issue by disabling the router’s DHCP and using the built-in DHCP service in MAAS.
Understand MAAS DHCP configuration:
MAAS configuration:
Existing DHCP server configuration:
pxelinux.0.Example DHCP configuration for PXE boot:
dhcp-option=66, "192.168.1.100" # IP address of the MAAS server
dhcp-option=67, "pxelinux.0" # Bootloader fileCheck MAAS DHCP configuration:
/var/snap/maas/common/maas/dhcpd.conf for a snap installation.Test PXE boot:
tcpdump or Wireshark to capture DHCP and TFTP traffic to troubleshoot any issues with PXE booting.If integrating with the existing DHCP server proves too challenging or unreliable, consider using the built-in DHCP service in MAAS as Robert-datacare eventually did. This approach simplifies the setup and leverages MAAS’s full capabilities for managing DHCP, DNS, and PXE booting seamlessly.
By following these steps, you can configure MAAS to work with an existing DHCP server or switch to using the built-in MAAS DHCP service to manage network booting and machine provisioning effectively.
Problem: You want to configure a machine with two NICs. NIC #1 is connected to a private subnet managed by MAAS, while NIC #2 is connected to a public subnet used for internet access. The user struggled to find a way to configure NIC #2 through the MAAS UI.
Solution:
Yes, it is possible to have two NICs working on a machine in MAAS. Here’s how you can configure both NICs:
Ensure that the netplan configuration reflects the settings from MAAS. Here is an example of how the 50-cloud-init.yaml might look:
network:
version: 2
ethernets:
ens18:
addresses:
- 192.168.10.5/24
match:
macaddress: 8e:57:8a:55:d4:2d
mtu: 1500
nameservers:
addresses:
- 192.168.10.10
search:
- maas
set-name: ens18
ens19:
addresses:
- 192.168.1.10/24 # Set this according to your network
gateway4: 192.168.1.1 # Default gateway for internet access
nameservers:
addresses:
- 8.8.8.8 # Google's DNS or your preferred DNS
- 8.8.4.4
match:
macaddress: c6:11:fb:c9:5e:e2
mtu: 1500
set-name: ens19netplan apply command or reboot the machine to ensure the settings take effect.Note: There was a mention of a bug when selecting a Fabric in the “Edit Physical” mask, causing it to jump back. Ensure that the correct fabric and subnet are selected before saving the configuration.
By following these steps, you should be able to configure both NICs on your machine, allowing it to communicate on both the private MAAS-managed network and the public internet-facing network.
Problem: A casual user is considering using MAAS for his homelab, primarily for learning configuration and deployment of containers on Raspberry Pi clusters. He has traditionally used manual DHCP allocations for server IP addresses to simplify IP address management and DNS. He is concerned whether this approach will conflict with MAAS’s use of DHCP.
Solution:
You can use manual DHCP allocations with MAAS, but you need to ensure that the DHCP offers set the next-server address to the TFTP boot server. This is crucial as it allows MAAS machines (such as your Raspberry Pi clusters) to get the address of boot servers to request a Network Boot Program (NBP).
Steps:
Configure DHCP server:
next-server option in your DHCP server configuration to point to the MAAS TFTP server.Example DHCP configuration snippet:
host raspberrypi1 {
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address 192.168.1.10;
next-server 192.168.1.2; # IP address of the MAAS TFTP server
filename "pxelinux.0"; # Or the appropriate boot file for your environment
}Ensure proper MAAS configuration:
Testing:
Managing IP address assignments:
By following these steps, you can integrate manual DHCP allocations with MAAS, maintaining your existing IP address management strategy while leveraging MAAS’s powerful provisioning capabilities.
Problem: MAAS 2.9.2 (snap) DHCP services stopped working after memory and disk issues were resolved. Despite fixing the memory and disk problems and rebooting, the DHCP services are not starting.
Solution:
Look into the MAAS logs.
The error log shows something like this:
2021-06-09 08:58:43 maasserver.rack_controller: [critical] Failed configuring DHCP on rack controller 'id:1'.
File "/snap/maas/12555/lib/python3.8/site-packages/maasserver/dhcp.py", line 864, in configure_dhcp
config = yield deferToDatabase(get_dhcp_configuration, rack_controller)
File "/snap/maas/12555/lib/python3.8/site-packages/maasserver/dhcp.py", line 783, in get_dhcp_configuration
config = get_dhcp_configure_for(
File "/snap/maas/12555/lib/python3.8/site-packages/maasserver/dhcp.py", line 663, in get_dhcp_configure_for
File "/snap/maas/12555/lib/python3.8/site-packages/maasserver/dhcp.py", line 444, in make_subnet_config
File "/snap/maas/12555/lib/python3.8/site-packages/maasserver/dhcp.py", line 447, in <listcomp>Go to the MAAS UI and check if the subnets are assigned to the correct fabrics.
If a subnet appears under the wrong fabric, reassign it to the correct fabric.
Steps:
sudo systemctl restart maas-rackd
sudo systemctl restart maas-regiondsudo mv /var/snap/maas/common/proxy /var/snap/maas/common/proxy.old
sudo mkdir -p /var/snap/maas/common/proxy
sudo chown -R proxy:proxy /var/snap/maas/common/proxy
sudo chmod -R 0750 /var/snap/maas/common/proxy
sudo systemctl restart maas-proxysudo maas-region dbshell
# Inside the database shell
VACUUM FULL;By following these steps, you should be able to diagnose and resolve the issues preventing the DHCP services from starting in MAAS.
Problem: You have set up a MAAS environment with DHCP and DNS enabled. However, your MAAS-deployed devices are unable to resolve hostnames using upstream DNS. Specifically, you are trying to resolve the hostname “grafana” but it only resolves via IP.
Solution:
Verify upstream DNS configuration: Ensure that your MAAS configuration includes the correct upstream DNS servers. You can set this up in the MAAS UI or via the command line.
Edit DNS configuration in MAAS:
Verify /etc/netplan configuration: Ensure that the netplan configuration on your MAAS-deployed device points to the correct DNS servers.
network:
version: 2
ethernets:
enp1s0:
dhcp4: no
addresses:
- 192.168.178.139/24
gateway4: 192.168.178.1
nameservers:
search:
- maas
addresses:
- 192.168.178.70
- 192.168.178.1Check systemd-resolved configuration: Verify that systemd-resolved is correctly configured to use the upstream DNS servers.
sudo systemctl restart systemd-resolved
sudo systemctl status systemd-resolvedEnsure that /etc/resolv.conf is correctly linked to systemd-resolved.
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.confTest DNS resolution: Use the dig command to test DNS resolution directly against your upstream DNS.
dig @192.168.178.70 grafana
dig @192.168.178.1 grafanaCheck MAAS DHCP and DNS configuration: Ensure that MAAS is correctly configured to provide the right DNS settings to its deployed devices.
sudo maas <profile> dhcp-snippet read 0Restart network services: Restart network services on your MAAS-deployed device to apply changes.
sudo netplan apply
sudo systemctl restart systemd-networkdUpdate DNS search domain: Ensure that the search domain includes the external domain if needed.
sudo nano /etc/systemd/resolved.conf
# Add or update the DNS and Domains entries
[Resolve]
DNS=192.168.178.70 192.168.178.1
Domains=maasRestart systemd-resolved again.
sudo systemctl restart systemd-resolvedBy following these steps, your MAAS-deployed devices should be able to resolve hostnames using the upstream DNS servers.
Problem: You are experiencing an issue where newly commissioned servers in your MAAS 3.1 environment fail with the cloud-init error “Can not apply stage final, no datasource found!” This problem is preventing you from commissioning new servers while your existing OpenStack environment has been running properly for some time.
Solution:
# Check network interfaces
ip a
# Check routing
ip route
# Check DNS resolution
nslookup maas-server-ip/etc/cloud/cloud.cfg file to ensure the datasource is correctly specified.# Edit the cloud-init configuration file
sudo nano /etc/cloud/cloud.cfg
# Ensure the datasource list includes MAAS
datasources:
- MAAS# Recommission the server via CLI
maas $PROFILE machine commission $SYSTEM_ID# Reset the node via CLI
maas $PROFILE machine release $SYSTEM_ID
maas $PROFILE machine commission $SYSTEM_ID# Update MAAS
sudo snap refresh maas
# Update cloud-init
sudo apt-get update
sudo apt-get install --only-upgrade cloud-initBy following these steps, you should be able to troubleshoot and resolve the issue preventing your servers from commissioning successfully in MAAS.
Problem: When the network connection between the MAAS region controller and rack controllers is interrupted, the DHCP services on the rack nodes stop, causing deployed machines to lose their IP addresses after the lease time expires. The issue resolves itself when the network hardware is rebooted.
Solution:
echo 'dhcp-lease-time 86400; # 1 day' | sudo tee /etc/maas/dhcpd.conf.d/lease-time.conf
sudo systemctl restart maas-rackd
sudo systemctl restart maas-regiondSet up ISC DHCP server on Ubuntu:
sudo apt update
sudo apt install isc-dhcp-serverConfigure the DHCP server by editing /etc/dhcp/dhcpd.conf:
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.100;
option routers 192.168.1.1;
option domain-name-servers 8.8.8.8, 8.8.4.4;
}Restart the DHCP server:
sudo systemctl restart isc-dhcp-serverEnsure that the DHCP server is detected by MAAS. Configure at least one node to use DHCP so that MAAS can recognize the external DHCP server.
Conclusion: By implementing redundancy, extending DHCP lease times, using external DHCP servers, and planning network maintenance effectively, you can ensure that DHCP services continue to function even during network disruptions.
Problem: Some machines encounter errors while commissioning, specifically failing to locate packages due to issues with the APT proxy in MAAS. The error appears as follows:
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package lldpdWhen entering rescue mode and manually running apt update, the error shows a connection failure to the APT proxy IP:
sudo apt update
Err:1 http://archive.ubuntu.com/ubuntu focal InRelease
Connection failed [IP: 10.8.8.183 8000]
Hit:2 http://archive.ubuntu.com/ubuntu focal-updates InRelease
Hit:3 http://archive.ubuntu.com/ubuntu focal-security InRelease
Hit:4 http://archive.ubuntu.com/ubuntu focal-backports InReleaseSwitching to an external proxy (standard HTTP proxy) resolves the issue, indicating a problem with the MAAS proxy.
Solution:
Identifying the issue: The error may be related to the Squid proxy on the MAAS node. Errors similar to:
Err:4 http://archive.ubuntu.com/ubuntu focal InRelease
Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)Cleaning the proxy cache: The issue can often be resolved by cleaning the Squid proxy cache on the MAAS node.
Steps to clean squid cache:
Commands:
sudo mv /var/spool/maas-proxy /var/spool/maas-proxy.old
sudo mkdir -p /var/spool/maas-proxy
sudo chown -R proxy:proxy /var/spool/maas-proxy
sudo chmod -R 0750 /var/spool/maas-proxy
sudo systemctl restart maas-proxyExplanation:
sudo mv /var/spool/maas-proxy /var/spool/maas-proxy.old: Moves the existing cache directory to a backup location.sudo mkdir -p /var/spool/maas-proxy: Creates a new cache directory.sudo chown -R proxy:proxy /var/spool/maas-proxy: Sets the ownership of the new cache directory to the proxy user.sudo chmod -R 0750 /var/spool/maas-proxy: Sets the permissions for the cache directory.sudo systemctl restart maas-proxy: Restarts the MAAS proxy service to apply changes.Confirmation: After performing the above steps, verify if the commissioning process completes successfully without encountering the APT proxy errors.
Conclusion: Cleaning the Squid proxy cache on the MAAS node has resolved similar issues for other users. If the issue persists, further investigation into network configurations or MAAS proxy settings may be required.
Problem: Clarification needed on how MAAS handles IP address allocation in subnets, particularly concerning managed allocation, reserved ranges, dynamic ranges, and the difference between auto-assigned and DHCP-assigned IP addresses.
Solution:
Managed allocation in subnets:
Managed allocation: When managed allocation is enabled for a subnet, MAAS takes charge of assigning IP addresses. It uses specific ranges for different purposes.
Dynamic range: This is the range from which MAAS leases addresses for DHCP during commissioning or enlistment. MAAS DHCP server picks IPs from this range.
Reserved range: IP addresses within the reserved range are not assigned by MAAS. These ranges are set aside for infrastructure systems, network hardware, external DHCP, or other uses outside of MAAS’s automatic management.
Unmanaged allocation: If managed allocation is disabled, MAAS does not automatically assign IP addresses from the subnet.
Explanation from documentation:
MAAS glossary and forum: The glossary mentions that MAAS will not assign IPs inside the reserved range for managed subnets. The forum clarifies that during commissioning or enlistment, the dynamic range is used for DHCP leases, which means that nodes in these phases will get IPs from the dynamic range.
Dynamic range usage: Managed allocation uses the dynamic range for temporary leases during commissioning or enlistment but excludes these from auto-assignments for provisioned nodes. This ensures a clear separation between IPs used temporarily and those assigned for operational use.
Auto-assigned vs. DHCP-Assigned IPs:
Auto-assigned IPs: These IPs are automatically assigned by MAAS during the node provisioning process. These are typically static IPs allocated outside the reserved dynamic range.
DHCP-assigned IPs: Nodes can be configured to use DHCP, where they will obtain their IP addresses from the MAAS-managed dynamic range. This mode is useful for nodes that may need to change their IP addresses frequently or for short-lived operations.
Steps to resolve:
By clarifying these points, you should have a better understanding of how MAAS handles IP address allocation within subnets and the difference between auto-assigned and DHCP-assigned IP addresses.
For more detailed information, refer to the MAAS documentation and the MAAS glossary for explanations on IP ranges and allocation modes.
Problem: The MAAS UI was accessible until the network configuration was changed, putting it in its own network without an external DHCP. Now, the user gets an error: “Bad Gateway”.
Solution:
Since the IP address of the MAAS server was changed, update the MAAS configuration to reflect the new IP address:
sudo maas config --maas-url=http://<new-ip-address>:5240/MAASThe error logs may show an issue with the PostgreSQL connection. Verify that PostgreSQL is running and accepting connections on the new IP address.
Update the PostgreSQL configuration to allow connections from the new IP address:
sudo nano /etc/postgresql/12/main/pg_hba.confAdd or update the line to allow connections:
host all all <new-ip-address>/32 md5Restart PostgreSQL:
sudo systemctl restart postgresqlEnsure that MAAS is configured to manage DHCP on the new network if needed:
maas $PROFILE vlan update $FABRIC_ID $VLAN_TAG dhcp_on=True primary_rack=$PRIMARY_RACK_CONTROLLERRestart the MAAS services to apply the new configurations:
sudo systemctl restart maas-regiond maas-rackdUse the “Validate networking configuration” button in the MAAS UI or run the following command to ensure network settings are correct:
maas $PROFILE subnet read $SUBNET_IDBy following these steps, you should be able to resolve the “Bad Gateway” error and restore access to the MAAS UI. If the issue persists, consider additional troubleshooting on the network level or consult the MAAS documentation for further guidance.
Problem: MAAS is sending out DHCP leases to both a BMC and a machine set to PXE boot, but the MAAS UI does not show any machines or used IP addresses in the subnet. This issue is hindering the auto-discovery and provisioning process.
Solution:
dhcpd.leases file in MAAS. You should see entries for both the BMC and the machine you’re trying to PXE boot.fabric-0 and that MAAS is configured to relay through the untagged VLAN.Example command for checking DHCP leases: - View the dhcpd.leases file to ensure that leases are being given out: sh cat /var/lib/dhcp/dhcpd.leases
Next steps: - If the machine is still not discovered, consider manually adding the machine to MAAS as a last resort by following the MAAS guide on adding machines manually.
By following these steps, you should be able to diagnose and resolve the issue with MAAS not recognizing the used IP addresses and new machines in the subnet.
Problem: You have successfully set up a Dell server using MAAS, but network interfaces are not being recognized correctly in the MAAS UI, particularly when trying to create a bond interface (port channel). The second network interface (eno2) is UP and recognized by the operating system but is not shown as connected in the MAAS UI.
Solution:
On the server, try running the following command to manually bring up the eno2 interface and see if it gets detected by MAAS:
sudo ip link set eno2 upAfter running the command, check the MAAS UI again to see if the second interface is now recognized.
Example command for commissioning script: - To run a commissioning script, follow the steps in the MAAS UI to commission the machine. During commissioning, MAAS will run various scripts to validate the hardware configuration. The output of these scripts can be found in the logs section of the MAAS UI.
Follow-up actions: - If the BMC (Baseboard Management Controller) of the server is powered off, manually power it up and check if the network interfaces are detected correctly. - If the issue persists after all troubleshooting steps, consider reaching out to the MAAS support team or community forums for further assistance.
By methodically verifying and comparing configurations, you should be able to pinpoint the cause of the interface detection issue and resolve the networking problem in MAAS.
Problem: You are experiencing an issue where MAAS is not responding to DHCP requests from the iDRAC of a Dell server. The iDRAC’s IP address is 0.0.0.0, and DHCP requests sent to MAAS do not receive replies. The DHCP logs indicate that DHCP DISCOVER messages are received on VLAN 5004, which is outside the valid VLAN range. Additionally, replacing one switch with another resolves the issue, suggesting a potential switch configuration problem.
Solution:
/var/log/syslog) on the MAAS server for any further insights or repeating patterns. Check if the MAC address of the iDRAC is consistently seen in the logs.Example commands for switch troubleshooting: - To display VLAN configuration on a Cisco switch: sh show vlan brief
To display interface configuration:
show running-config interface <interface-id>Follow-up actions: - If you identify a misconfiguration on SWITCH1, correct it and test the DHCP process again. - If the issue persists after all troubleshooting steps, consider isolating the network further or engaging with the switch vendor’s support for deeper diagnostics.
By methodically verifying and comparing configurations, you should be able to pinpoint the cause of the VLAN misidentification and resolve the DHCP leasing issue.
Problem: You are running a MAAS 3.3 server from an LXD container with two interfaces, each on a different VLAN. PXE booting from “network 2” results in the server only getting an IP and timing out on the TFTP request for bootx64.efi. The issue does not occur on “network 1”. A temporary workaround involved moving the subnet to a separate fabric and recommissioning/deploying, but the subnet eventually reverts to the original fabric, causing the problem to recur.
Solution:
dhcpdump or tcpdump to detect any rogue DHCP servers.network:
version: 2
ethernets:
eth0:
addresses:
- 10.25.51.3/23
dhcp4: false
nameservers:
addresses:
- 10.25.52.2
- 10.25.51.3
routes:
- to: default
via: 10.25.50.1
eth1:
addresses:
- 10.25.54.100/24
dhcp4: false
nameservers:
addresses:
- 10.25.51.3
- 10.25.52.2sudo netplan apply inside the MAAS container.If the issue persists after following these steps, it might be beneficial to work closely with your network team to identify any potential network-level misconfigurations or conflicts. Additionally, you may want to check for any recent changes or updates that could have affected the network or MAAS configuration.
To get a complete list of DNS resources from the MAAS API using Python, you need to include the all=True parameter in your request URL. Here is a working example using the requests library:
import json
from requests import Request, Session
from requests_oauthlib import OAuth1
# Replace with your actual keys and URL
consumer_key = 'xxxxxxxxxx'
token_key = 'yyyyyyyyyyy'
token_secret = 'zzzzzzzzzz'
base_url = 'https://my-maas-instance.com/MAAS/api/2.0/dnsresources/'
# Authentication
auth = OAuth1(consumer_key, '', token_key, token_secret)
# Headers
headers = {'Accept': 'application/json'}
# Full URL with all=True parameter
url = f'{base_url}?all=True'
# Create a session and send the request
session = Session()
request = Request('GET', url, headers=headers, auth=auth)
prepped = request.prepare()
response = session.send(prepped)
# Print the response
print(response.text)In this script, make sure to replace the placeholder values (xxxxxxxxxx, yyyyyyyyyyy, zzzzzzzzzz, and https://my-maas-instance.com/MAAS/api/2.0/dnsresources/) with your actual consumer key, token key, token secret, and the MAAS instance URL, respectively.
This will retrieve the full list of DNS resources from the MAAS API, including all entries when all=True is used.
Encountering SNMP errors when attempting to query a device’s BMC. The errors include ‘Cannot find module’ for various MIBs and ‘Timeout’ when communicating with the target IP address.
Check SNMP Configuration: Ensure SNMP is correctly configured on the BMC device. Verify the community string, SNMP version, and access control settings.
Install missing MIBs:
Install the required MIBs on the MAAS server. Missing MIBs often cause ‘Cannot find module’ errors.
Update the SNMP MIB repository:
sudo apt-get install snmp-mibs-downloader
sudo download-mibsVerify network connectivity:
Ensure the MAAS server can reach the BMC device. Check the network connectivity and firewall rules.
Use ping or telnet to verify:
ping <BMC_IP>
telnet <BMC_IP> 161Test SNMP communication:
Use the snmpwalk command to test SNMP communication manually:
snmpwalk -v 2c -c <community_string> <BMC_IP>Check for timeout errors or specific MIB module errors.
Update MAAS and dependencies:
Ensure you are using the latest version of MAAS and its dependencies. Update the system packages:
sudo apt-get update
sudo apt-get upgrade
sudo snap refresh maasConfigure SNMP on MAAS:
/etc/maas/maas.cfg file or through the MAAS web interface.Check SNMP logs:
Review the SNMP logs for detailed error messages:
sudo journalctl -u maasRestart services:
Restart the MAAS and SNMP services to apply the changes:
sudo systemctl restart maas-regiond
sudo systemctl restart maas-rackdSNMP timeout troubleshooting:
If timeouts persist, increase the SNMP timeout value and retry:
snmpwalk -v 2c -c <community_string> -t 60 <BMC_IP>Community support:
By following these steps, you should be able to resolve the SNMP errors and successfully query your device’s BMC using MAAS.
Scenario: You need to disable BIND (named) from listening on IPv6 addresses in a MAAS setup. The solution involves editing the BIND configuration to disable IPv6.
For Snap installation: Snap installations of MAAS do not allow direct editing of the named configuration files because they are contained within the snap. However, you can manage named options indirectly.
For Apt Installation: If MAAS is installed using apt, you can directly edit the BIND configuration files.
Open the named configuration options file:
sudo nano /etc/bind/named.conf.optionsEdit the file to disable IPv6: Find the line that specifies the IPv6 listening options and change it to disable IPv6. The line typically looks like:
listen-on-v6 { any; };Change it to:
listen-on-v6 { none; };Save and exit the file:
Ctrl+O to write the changes.Enter to confirm.Ctrl+X to exit the editor.Restart BIND to apply the changes:
sudo systemctl restart bind9Check the BIND status:
sudo systemctl status bind9Ensure there are no errors.
Verify that BIND is not listening on IPv6:
sudo netstat -plnt | grep namedThis should show that named is not listening on any IPv6 addresses.
By following these steps, you should be able to disable BIND from listening on IPv6 in a MAAS environment installed via apt.
Problem: Difficulty in creating and resolving DNS SRV records in MAAS, where records added via the MAAS GUI do not resolve correctly despite appearing in the zone file.
Solution: Ensure that DNS SRV records are created correctly and troubleshoot potential issues with the web GUI by verifying the records directly in the zone file and ensuring that named.conf is properly updated.
Steps to Resolve:
Verify SRV record creation via MAAS GUI:
Log in to the MAAS web interface.
Navigate to the DNS settings and add the desired SRV records.
Ensure the format is correct:
_service._protocol.name. TTL class SRV priority weight port target.Example:
_myservice._tcp.test. 30 IN SRV 10 10 1234 t1.test.Check zone file directly:
Access the MAAS server and check the DNS zone file for the domain.
Verify that the SRV record appears correctly in the zone file.
cat /var/lib/bind/maas/zone.testExample:
; Zone file modified: 2023-12-09 16:00:59.338123.
$TTL 30
@ IN SOA test. nobody.example.com. (
0000000951 ; serial
600 ; Refresh
1800 ; Retry
604800 ; Expire
30 ; NXTTL
)
@ 30 IN NS maas.
t2 30 IN A 192.168.1.2
t3 30 IN A 192.168.1.3
t1 30 IN A 192.168.1.1
_myservice._tcp 30 IN SRV 10 10 1234 t1.test.Test SRV record resolution:
Use the dig command to query the SRV record and check the response.
dig @localhost SRV _myservice._tcp.testExpected output:
; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> @localhost SRV _myservice._tcp.test
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10147
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;_myservice._tcp.test. IN SRV
;; ANSWER SECTION:
_myservice._tcp.test. 30 IN SRV 10 10 1234 t1.test.
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(localhost) (UDP)
;; WHEN: Sat Dec 09 16:05:35 UTC 2023
;; MSG SIZE rcvd: 135Troubleshoot GUI issues:
If records do not appear or resolve correctly, manually edit the zone file and named configuration.
Ensure there are no stale or incorrectly formatted entries.
Restart the DNS service to apply changes:
sudo systemctl restart bind9Check named configuration:
Ensure that the named configuration includes the correct zone settings and paths to the zone files.
cat /etc/bind/named.confExample:
test and add the SRV record _myservice._tcp.test.Confirm the zone file has the correct entries.
cat /var/lib/bind/maas/zone.testUse dig to test the SRV record.
dig @localhost SRV _myservice._tcp.testEdit zone file if the GUI fails and restart DNS service.
sudo nano /var/lib/bind/maas/zone.test
sudo systemctl restart bind9By following these steps, you can create and manage DNS SRV records in MAAS, ensuring they are correctly configured and resolvable.
Problem: When using MAAS with machines that boot via legacy BIOS, there’s an issue where PXE booting from the second NIC results in a “No boot filename received” error. This occurs despite the machine receiving a DHCP offer.
Solution: The issue is likely due to the limitation that, until MAAS version 3.5, booting from the first NIC is required for machines using legacy BIOS. To resolve this, you need to configure the machines to boot from the first NIC and use the second NIC for other network configurations.
Steps to resolve:
Detailed steps:
a. Check and configure BIOS settings:
b. Update MAAS configuration:
Re-add machine with first NIC:
Example command to add machine with first NIC:
maas $PROFILE machines add mac_addresses=$FIRST_NIC_MACVerify DHCP configuration:
Example DHCP configuration check: bash sudo nano /etc/dhcp/dhcpd.conf - Ensure the correct interface and subnet are specified.
c. Re-commission the machine:
Commission the machine:
Example command to commission machine:
maas $PROFILE machine commission $MACHINE_IDCheck logs for errors:
Example workflow:
Verify boot order in BIOS:
Add machine to MAAS with first NIC:
maas $PROFILE machines add mac_addresses=$FIRST_NIC_MACConfigure and verify DHCP for first NIC:
sudo nano /etc/dhcp/dhcpd.confCommission the machine:
maas $PROFILE machine commission $MACHINE_ID**Monitor the MAAS logs.
By following these steps, you can ensure that machines with legacy BIOS can successfully PXE boot from the first NIC, resolving the “No boot filename received” error and enabling proper commissioning and deployment in MAAS.
Problem: The MAAS server is set up on VLAN 1000 with subnet 10.10.10.0/24 and is configured to serve another subnet 10.20.20.0/24 via DHCP relay. Devices in the 10.20.20.0/24 subnet can receive DHCP addresses but fail to connect to the TFTP server, resulting in timeouts.
Solution: To resolve this issue, you need to ensure that TFTP and other necessary services can communicate properly across subnets. This involves verifying network configurations and ensuring that MAAS is set up to handle requests from both subnets.
Steps to resolve the issue:
Check the MAAS logs to verify that the TFTP requests are being received and to identify any potential issues.
Verify network configuration:
Example configuration check:
Enable ProxyDHCP:
Example command to enable ProxyDHCP:
maas $PROFILE maas set-config name=enable_proxy value=trueCheck TFTP configuration:
Example TFTP configuration check:
sudo nano /etc/default/tftpd-hpaEnsure IP forwarding:
Example command to enable IP forwarding:
sudo sysctl -w net.ipv4.ip_forward=1Firewall configuration:
Example firewall check:
sudo ufw statusNetwork device configuration:
Example network configuration:
Router Configuration:
- DHCP relay pointing to 10.10.10.2
- IP routes allowing traffic between 10.20.20.0/24 and 10.10.10.0/24Example workflow:
Check the MAAS logs:
Verify network devices configuration:
Enable ProxyDHCP on MAAS:
maas $PROFILE maas set-config name=enable_proxy value=trueCheck TFTP server configuration:
sudo nano /etc/default/tftpd-hpaEnable IP forwarding:
sudo sysctl -w net.ipv4.ip_forward=1Check firewall status:
sudo ufw statusBy following these steps, you can troubleshoot and resolve the issue of the MAAS server not responding to TFTP requests from the 10.20.20.0/24 subnet, ensuring that all devices can properly communicate with the MAAS server across different subnets.
Problem: The commissioning process fails at the “lldpd” installation step due to the error “Unable to locate package lldpd.” This issue occurs in a disconnected environment where a local mirror of the Ubuntu repository is used.
Solution: The issue is likely due to missing repository components in the local mirror configuration, particularly the “universe” component where the lldpd package resides.
Steps to resolve:
Check repository components:
main, universe, restricted, and multiverse).Update MAAS settings:
Verify and update preseed configuration:
Detailed steps:
a. Verify local mirror configuration:
universe component.Example local mirror configuration:
deb http://192.168.1.100/repos/archive.ubuntu.com/ubuntu focal main universe restricted multiverseb. Update MAAS proxy settings:
Example MAAS proxy configuration:
sudo maas $PROFILE maas set-config name=http_proxy value="http://192.168.1.100:8000/"c. Verify preseed configuration:
Example command to access preseed:
http://<maas_ip>:5240/MAAS/metadata/latest/by-id/<system_id>/?op=get_preseedExample preseed configuration:
sources:
repo_infra_3:
source: deb http://192.168.1.100/repos/archive.ubuntu.com/ubuntu $RELEASE main universe restricted multiversed. Disable official repositories:
Example configuration to disable official repositories:
sources:
repo_infra_3:
source: deb http://192.168.1.100/repos/archive.ubuntu.com/ubuntu $RELEASE main universe restricted multiversee. Re-run commissioning:
Verify package availability:
lldpd package is available in the local mirror by running the following command on a test machine:sudo apt-get update
sudo apt-get install lldpdBy following these steps, you can ensure that the necessary repository components are included and configured correctly, allowing the commissioning process to complete successfully without errors related to the lldpd package.
Problem: You want to add two additional domains to the DNS search list for a subnet in MAAS, but there doesn’t seem to be an option to set this directly in the UI or through typical configuration methods.
Solution: To add additional domains to the DNS search list for a subnet in MAAS, you can use a custom cloud-init script to configure the resolv.conf file. Follow these steps:
Use cloud-init configuration:
Steps to configure DNS search list:
a. Create a custom cloud-init script:
resolv.conf file.Example cloud-init script:
#cloud-config
write_files:
- path: /etc/cloud/cloud.cfg.d/99-custom-dns.cfg
content: |
network:
config: disabled
runcmd:
- echo "search domain1.com domain2.com" >> /etc/resolv.conf
- netplan applyb. Update MAAS machine configuration:
Example command to apply custom cloud-init script:
maas $PROFILE machine update $MACHINE_ID user_data="$(base64 -w 0 /path/to/your/cloud-init.yaml)"c. Verify DNS configuration:
resolv.conf file has the correct DNS search list entries.Example command to check resolv.conf:
cat /etc/resolv.confEnsure persistence:
Example configuration to disable network configuration by cloud-init:
network:
config: disabledExample workflow:
Create custom cloud-init script:
#cloud-config
write_files:
- path: /etc/cloud/cloud.cfg.d/99-custom-dns.cfg
content: |
network:
config: disabled
runcmd:
- echo "search domain1.com domain2.com" >> /etc/resolv.conf
- netplan applyApply script to MAAS machine:
maas $PROFILE machine update $MACHINE_ID user_data="$(base64 -w 0 /path/to/your/cloud-init.yaml)"Deploy and verify:
cat /etc/resolv.confBy following these steps, you can add additional domains to the DNS search list for your MAAS-managed subnets, ensuring proper DNS resolution for your deployed machines.
Problem: Clients (VMs) receive the image and boot correctly from MAAS, but they do not appear in the MAAS GUI under the Machines section.
Solution: This issue could be due to network misconfiguration or incorrect settings in MAAS that prevent the clients from being properly enlisted and commissioned. Follow these steps to resolve the issue:
Verify network configuration:
Check MAAS logs:
Ensure proper enlistment:
Steps to resolve the issue:
a. Verify DHCP configuration:
Example command to check DHCP configuration:
maas $PROFILE dhcps readb. Check MAAS logs:
c. Verify network interface configuration:
d. Ensure correct enlistment:
Example steps to verify PXE boot:
e. Check commissioning status:
Example command to check commissioning status:
maas $PROFILE machines readAdditional configuration:
Example workflow:
Check DHCP and network configuration:
maas $PROFILE dhcps readCheck the MAAS logs.
Verify PXE boot settings:
Check commissioning status:
maas $PROFILE machines readBy following these steps, you can diagnose and resolve the issue of clients receiving images but not appearing in the MAAS GUI. This approach ensures proper network configuration and correct commissioning of the VMs.
Problem: Implementing high availability (HA) for DHCP in relayed subnets using MAAS is not straightforward, and the standard architecture restricts adding a secondary rack controller in these scenarios.
Solution: To achieve HA for DHCP services in relayed subnets with MAAS, follow these steps:
Understand MAAS DHCP configuration:
Update VLAN configuration via CLI:
Steps for Configuration:
a. Identify VLAN and fabric IDs:
b. Configure primary and secondary rack controllers:
Example commands:
maas $PROFILE vlan update $FABRIC_ID $VLAN_TAG dhcp_on=True \
primary_rack=$PRIMARY_RACK_CONTROLLER \
secondary_rack=$SECONDARY_RACK_CONTROLLER c. Configure DHCP relay:
Example command:
maas $PROFILE vlan update $FABRIC_ID $VLAN_ID_SRC relay_vlan=$VLAN_ID_TARGETNetwork considerations:
HA setup with IP helpers:
Verify configuration:
Example workflow:
Get fabric and VLAN IDs:
maas $PROFILE fabrics read
maas $PROFILE vlans read $FABRIC_IDUpdate VLAN for DHCP and relay:
maas $PROFILE vlan update $FABRIC_ID $VLAN_TAG dhcp_on=True \
primary_rack=$PRIMARY_RACK_CONTROLLER \
secondary_rack=$SECONDARY_RACK_CONTROLLER
maas $PROFILE vlan update $FABRIC_ID $VLAN_ID_SRC relay_vlan=$VLAN_ID_TARGETConfigure IP helpers on network switch:
By following these steps, you can set up HA for DHCP in relayed subnets using MAAS, ensuring redundancy and high availability for your network configuration. This approach leverages both the MAAS CLI for detailed configuration and network infrastructure for effective DHCP relay.
Problem: MAAS passes the commissioning and deployment stages but gets stuck in the “rebooting” stage with an errno 101 network is unreachable error. This issue may be related to the external DHCP configuration.
Solution: To resolve issues related to external DHCP configuration in MAAS, follow these steps:
Verify external DHCP server:
Enable network discovery:
Check logs:
Set static IP configuration:
Detailed steps:
a. Verify external DHCP server:
b. Enable network discovery:
Example:
maas admin subnet update <subnet-id> manage_discovery=truec. Check logs:
d. Set static IP configuration:
Example netplan configuration (static IP):
network:
ethernets:
ens16:
addresses:
- 192.168.30.20/23
nameservers:
addresses:
- 192.168.30.1
- 192.168.30.2
routes:
- to: default
via: 192.168.30.10
version: 2Apply the changes:
sudo netplan applyAdditional configuration:
By following these steps, users can resolve the errno 101 network is unreachable error and ensure that the MAAS deployment process completes successfully. This approach addresses both DHCP configuration issues and network interface settings.
Problem: MAAS passes the commissioning and deployment stages but gets stuck in the “rebooting” stage with an errno 101 network is unreachable error. This occurs even with a standard installation without using a cloud-init script.
Solution: This issue can often be related to external DHCP configuration or network misconfiguration. Here are steps to resolve the issue:
Verify network configuration:
Check DHCP settings:
Modify cloud-init configuration:
Detailed steps:
a. Verify network interfaces:
Example commands:
ip addr show
ip route showb. Check DHCP and DNS configuration:
Example:
c. Modify cloud-init configuration:
Example cloud-init script:
#!/bin/bash
# disable cloud-init network configuration after deployment
sudo touch /etc/cloud/cloud-init.disabledd. Update network configuration:
Example netplan configuration:
network:
version: 2
ethernets:
enp1s0:
dhcp4: true
nameservers:
addresses:
- 8.8.8.8
- 8.8.4.4Apply the changes:
sudo netplan applyCheck external DHCP configuration:
By following these steps, you can resolve the errno 101 network is unreachable error during the rebooting stage in MAAS, ensuring that the deployed machine can correctly communicate with the MAAS server and complete the deployment process.
Problem: Users face issues when switching the network interface of a deployed VM from an isolated deployment network to a bridged network, causing the VM to hang or freeze during boot.
Solution: MAAS does not support reassigning a deployed machine to a new subnet directly. To address this, follow these steps:
Avoid switching networks:
Use a different router:
Manual network configuration:
Detailed steps:
a. Update cloud-init configuration:
Example script:
#!/bin/bash
# disable cloud-init network configuration after deployment
sudo touch /etc/cloud/cloud-init.disabledb. Modify network configuration:
Example netplan configuration:
network:
version: 2
ethernets:
enp1s0:
dhcp4: truec. Apply network changes:
Example commands:
sudo netplan applyAdd a custom router:
Example setup:
By following these steps, users can manage network configurations more effectively and avoid issues related to switching network interfaces post-deployment. This approach ensures that VMs operate correctly within the desired network setup.
Problem: Users experience issues with MAAS using unintended network interfaces, particularly in multi-homed environments with Docker running on the same system. Specific challenges include unwanted interface detection, persistent subnets, and network discovery on unselected subnets.
Solution: To address these issues and better manage network interfaces and subnets in MAAS, follow these steps:
Bind MAAS to a single interface:
Remove unwanted interfaces:
docker0.Ignore certain interfaces:
Configure network services:
named.conf file to control DNS behavior and prevent unwanted DNS resolution on specific subnets.Detailed steps:
a. Exclude Docker interface:
docker0 interface by configuring the system to exclude it. Create a script to modify the network configuration.Example script:
#!/bin/bash
# Exclude docker0 interface from MAAS management
INTERFACE="docker0"
IP_ADDR=$(ip addr show $INTERFACE | grep "inet\b" | awk '{print $2}' | cut -d/ -f1)
if [ -n "$IP_ADDR" ]; then
echo "Exclude $INTERFACE ($IP_ADDR) from MAAS"
ip link set $INTERFACE down
ip addr flush dev $INTERFACE
fib. Customize named.conf:
named.conf file to prevent named from using specific subnets.Example configuration:
options {
...
listen-on { 127.0.0.1; <your-desired-interface-ip>; };
...
};c. Modify network configuration:
Example for nginx:
server {
listen <your-desired-interface-ip>:80;
server_name maas.local;
...
}d. Disable unwanted subnet management:
Example CLI commands:
maas admin subnet update <subnet-id> manage_allocation=false
maas admin subnet update <subnet-id> manage_discovery=false
maas admin subnet update <subnet-id> allow_dns=falseReview and restart services:
Restart MAAS services:
sudo systemctl restart maas-regiond
sudo systemctl restart maas-rackdBy following these steps, users can better control which network interfaces and subnets are managed by MAAS, addressing issues related to unwanted interface usage and persistent subnets. This approach ensures that MAAS operates within the desired network configuration parameters.
Problem: Users need to add VLAN interfaces to LXD VMs in MAAS but face limitations in modifying VMs post-creation and ensuring proper VLAN tagging.
Solution: To add VLAN interfaces to LXD VMs, follow these steps:
Configure VLAN interfaces on the VM host:
Create bridges for VLAN interfaces:
Step-by-step configuration:
a. Add VLAN interface to MAAS rack controller:
Example:
# Add VLAN 500 to physical interface eth0
sudo ip link add link eth0 name eth0.500 type vlan id 500
sudo ip addr add 150.150.150.1/24 dev eth0.500
sudo ip link set dev eth0.500 upb. Create bridge interface:
Example:
# Create bridge br500 and add eth0.500 as a member
sudo brctl addbr br500
sudo brctl addif br500 eth0.500
sudo ip link set dev br500 upc. Configure netplan (if using):
Example:
network:
version: 2
ethernets:
eth0:
dhcp4: true
vlans:
eth0.500:
id: 500
link: eth0
addresses: [150.150.150.1/24]
bridges:
br500:
interfaces: [eth0.500]
dhcp4: nosudo netplan applyCreate VMs in MAAS:
By following these steps, users can successfully add VLAN interfaces to LXD VMs in MAAS, ensuring proper VLAN tagging and network configuration. This setup allows VMs to operate with untagged interfaces while maintaining VLAN traffic tagging at the host level.
Problem: The Netplan configuration provided in the cloud-init script is being ignored, resulting in static IP settings instead of the desired DHCP configuration.
Solution: To ensure the network configuration is correctly applied during deployment, follow these steps:
Edit machine’s interfaces in MAAS:
cloud-init to handle network configuration.Default DHCP for future machines:
Custom cloud-init script:
cloud-init script, ensure it correctly sets up the network interfaces. However, due to current limitations, you may need a workaround to apply Netplan configuration.Workaround with bash script:
cloud-init to manually write the Netplan configuration and apply it. This can be done using the runcmd section of the cloud-init script.Example cloud-init script with bash workaround:
#cloud-config
packages:
- qemu-guest-agent
- openssh-server
users:
- default
- name: untouchedwagons
gecos: untouchedwagons
primary_group: untouchedwagons
groups: sudo
sudo: ALL=(ALL) NOPASSWD:ALL
shell: /bin/bash
ssh_import_id:
- gh:UntouchedWagons
runcmd:
- [ systemctl, enable, --now, qemu-guest-agent ]
- [ systemctl, enable, --now, ssh ]
- |
cat <<EOF > /etc/netplan/01-netcfg.yaml
network:
version: 2
ethernets:
ens18:
match:
macaddress: 'bc:24:11:e5:41:b7'
dhcp4: true
dhcp-identifier: mac
EOF
netplan applyAutomation integration:
By following these steps, you can ensure that the network configuration is applied correctly during machine deployment in MAAS, avoiding the issues with ignored Netplan settings.
Problem: Users encounter issues when trying to set the IPMI IP address field as an FQDN in MAAS. The machine gets registered with an IPv4 address associated with the FQDN, and the commissioning process does not complete.
Solution: To address this issue and implement workarounds, follow these steps:
Direct FQDN usage:
power_address field. The power_address must be an IPv4 or IPv6 address as per the BMC enlistment documentation.Workarounds:
a. Use Unique hostnames in the cluster:
b. Assign FQDN management hostnames:
[hostname]-mgmt as the FQDN for the IPMI address.c. Update BMC IP using Python script:
cron.Example Python script:
import maas.client
from maas.client import login
from maas.client.enum import NodeStatus
MAAS_API_URL = 'http://<MAAS_SERVER>/MAAS/'
API_KEY = '<YOUR_API_KEY>'
FQDN_SUFFIX = '-mgmt'
def update_bmc_ips():
client = login(MAAS_API_URL, API_KEY)
nodes = client.machines.list(status=NodeStatus.READY)
for node in nodes:
hostname = node.hostname
fqdn = f"{hostname}{FQDN_SUFFIX}"
ip_address = socket.gethostbyname(fqdn)
node.power_address = ip_address
node.save()
if __name__ == "__main__":
update_bmc_ips()Add the script to crontab to run every 5 minutes:
*/5 * * * * /usr/bin/python3 /path/to/update_bmc_ips.pyBy following these steps, users can manage their MAAS setup more effectively, even when direct FQDN usage is not supported for IPMI addresses. The provided workarounds ensure that the IPMI addresses are updated and managed correctly using the MAAS API and periodic scripts.
Problem: Users need to manually configure network interfaces to DHCP and set power configurations to Manual for new machines added to MAAS, seeking a way to automate these settings.
Solution: To automate the initial configuration settings for new machines in MAAS, follow these steps:
Use preseed scripts:
Curtin userdata:
curtin_userdata to include early commands for setting network interfaces to DHCP and power configuration to Manual. Add these configurations to the preseed file.Example preseed configuration:
early_commands:
10_dhcp: |
for nic in $(ls /sys/class/net/ | grep -v lo); do
echo "dhclient ${nic}" >> /etc/network/interfaces.d/${nic};
dhclient ${nic}
done
20_power: |
echo "manual" > /etc/maas/power.confMAAS CLI:
Example script:
#!/bin/bash
MACHINE_ID=$1
# Set network interface to DHCP
maas admin interface link-subnet $MACHINE_ID \
$(maas admin interfaces read $MACHINE_ID | jq '.[0].id') \
mode=DHCP
# Set power configuration to Manual
maas admin machine update $MACHINE_ID power_type=manualAutomate through hooks:
Check certified hardware:
Custom automation:
By implementing these steps, users can automate the initial configuration settings for new machines in MAAS, reducing manual intervention and streamlining the deployment process.
Problem: Users encounter issues with VLANs not being utilized on any rack controller, leading to problems with DHCP and network connectivity.
Solution: To troubleshoot and resolve VLAN issues in MAAS, follow these steps:
Ensure that VLAN interfaces are correctly configured on the rack controller with proper IDs, links, and IP addresses. Use netplan to apply configurations:
sudo netplan applyBy following these steps, users can troubleshoot and resolve issues with VLAN utilization on rack controllers in MAAS, ensuring proper network configuration and connectivity.
Problem: Deploying servers in MAAS results in an error stating “No more IPs available in subnet,” despite having unused IP addresses.
Solution: To release old DHCP leases and resolve IP allocation issues, follow these steps:
Run the following SQL query to identify orphaned IP addresses in the MAAS database:
sudo -u postgres psql -d maasdb -c "
SELECT count(*)
FROM maasserver_staticipaddress
LEFT JOIN maasserver_interface_ip_addresses ON maasserver_staticipaddress.id = maasserver_interface_ip_addresses.staticipaddress_id
LEFT JOIN maasserver_interface ON maasserver_interface.id = maasserver_interface_ip_addresses.interface_id
WHERE maasserver_staticipaddress.ip IS NULL
AND maasserver_interface.type = 'unknown'
AND maasserver_staticipaddress.alloc_type = 6;
"This will help you identify any orphaned addresses that are not properly allocated.
Use the MAAS CLI to clear discovered neighbors, which might be causing IP conflicts:
maas admin discoveries clear all=True -kAfter clearing, check if the discoveries were successfully removed:
maas admin discoveries read -kIf necessary, clear the ARP table on the Rack server to ensure no stale entries exist:
arp -d [IP address]Example to clear all entries:
arp -d 172.21.68.79
arp -d 172.21.68.69Attempt to deploy the server again to check if the issue persists. If the error still occurs, check the discoveries once more without cleaning:
maas admin discoveries read -kBy following these steps, users can release old DHCP leases and address IP exhaustion issues in MAAS, ensuring successful server deployment.
Problem: Configuring the loopback interface (lo) using MAAS is not straightforward, especially when deploying nodes for use with Free Range Routing (FRR) and BGP.
Solution: To configure loopback addresses in MAAS, follow these steps:
00:00:00:00:00:00 but ensure it does not conflict with other nodes.By following these steps, users can effectively configure loopback interfaces on nodes managed by MAAS, facilitating advanced network setups like L3 routing and BGP.
Problem: Users may encounter errors when attempting to shrink the dynamic IP address range in MAAS due to conflicts with existing IP addresses or ranges.
Solution: To troubleshoot and resolve this issue, follow these steps:
Use the following SQL queries to check the current IP ranges and static IP addresses in the MAAS database:
SELECT * FROM maasserver_iprange;
SELECT * FROM maasserver_staticipaddress WHERE text(ip) LIKE '192.168.0.%' ORDER BY ip;Identify any existing IP addresses that may conflict with the desired new range.
By following these steps, users can effectively shrink the dynamic IP address range in MAAS without encountering conflicts with existing IP addresses or ranges.
Ensure that your subnets don’t overlap to avoid deployment failures. Check and delete any outdated or redundant subnets through the Web UI.
If you need to modify your MAAS server’s IP, simply re-run the setup:
sudo dpkg-reconfigure maas-region-controllerIBM Power servers with OPAL firmware utilise Petitboot for PXE interactions. For smooth deployment, configure a specific NIC as the network boot device via Petitboot.
If both MAAS and LXD are managing DNS, disable LXD’s DNS and DHCP:
lxc network set $LXD_BRIDGE_NAME dns.mode=none
lxc network set $LXD_BRIDGE_NAME ipv4.dhcp=false
lxc network set $LXD_BRIDGE_NAME ipv6.dhcp=falseTiming issues: Make sure the hardware clocks on your nodes and MAAS server are synchronised.
Network drivers: Use Linux-compatible network adaptors if commissioning hangs due to driver issues.
Feel free to contribute additional issues and solutions.
When you try to run packer or execute a make command, you may encounter an error message indicating that packer is not installed. The issue can be resolved by referring to this section.
packer:stormrider@neuromancer:~$ packer
Command 'packer' not found...make:stormrider@neuromancer:~/mnt/Dropbox/src/git/packer-maas/ubuntu$ make
sudo: packer: command not found...Should you see an error like the one below, you’ve forgotten to install a needed dependency.
make: *** No rule to make target '/usr/share/OVMF/OVMF_VARS.fd'...Encountering the following error means you’re missing a dependency. Refer to this section for resolution.
Failed creating Qemu driver: exec: "qemu-img": executable file not found in $PATHIf you’ve modified the session timeout settings in the MAAS web interface but don’t see the changes, do the following:
If users are getting logged out before the session timeout you’ve set, consider these checks:
You can’t set an “infinite” session timeout in MAAS. The maximum allowed duration is 14 days. This limit strikes a balance between security and usability.
MAAS will auto-logoff users when the session timeout duration is reached. If this happens more often than desired, consider increasing the timeout value to prevent frequent “idle-time” logouts.
MAAS only supports a global session timeout setting. While you can’t customise this by user group, you could deploy separate MAAS instances with different configurations to achieve similar effects.
The timeout duration resets every time there’s activity from the user. To extend a session, simply refresh the page before the timeout period ends. This will reset the session timer.
Sometimes, you may face the following Django error:
django.core.exceptions.ValidationError: ['Subarchitecture(<value>) must be generic when setting hwe_kernel.']To solve this, try specifying a different commissioning kernel—perhaps upgrading from Xenial to Focal.
If you forget your MAAS admin password but have sudo privileges, you can reset it like so:
sudo maas changepassword $PROFILEReplace $PROFILE with the username.
The default MAAS web UI is at http://<hostname>:5240/MAAS/. If it’s unreachable:
sudo /etc/init.d/apache2 status.http://127.0.0.1:5240/MAAS/.Ephemeral images boot nodes during MAAS activities. If you need emergency access, you can create a temporary backdoor in these images. This lets you log in to check logs and debug issues.
Download the appropriate image and extract its files:
wget https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-root.tar.gz
mkdir xenial
sudo tar -C xenial -xpSf xenial-server-cloudimg-amd64-root.tar.gz --numeric-owner --xattrs "--xattrs-include=*"Create a SHA-512 hashed password:
python3 -c 'import crypt; print(crypt.crypt("ubuntu", crypt.mksalt(crypt.METHOD_SHA512)))'Modify the xenial/etc/shadow file to insert this hash.
Create a new SquashFS file with your changes:
sudo mksquashfs xenial/ xenial-customized.squashfs -xattrs -comp xzReplace the existing MAAS image with this customised one.
For snap-based MAAS in ‘all’ mode, you can migrate to a local PostgreSQL:
sudo /snap/maas/current/helpers/migrate-vd SnapatabaseTo manually move your MAAS database, run:
export PGPASS=$(sudo awk -F':\\s+' '$1 == "database_pass" {print $2}' \
/var/snap/maas/current/regiond.conf)
sudo pg_dump -U maas -h /var/snap/maas/common/postgres/sockets \
-d maasdb -F t -f maasdb-dump.tarStop the MAAS snap (sudo snap stop maas) and create a new PostgreSQL user and database for MAAS on the destination machine.
This should cover various miscellaneous issues you may encounter while using MAAS. Feel free to contribute with your own experiences.
If MAAS hardware sync leaks your admin API key, you can:
Or swap the token manually:
Query the database to identify machines with hardware sync enabled:
select system_id
from maasserver_node
where enable_hw_sync = true;Rotate API keys on any affected machines. To verify an API key belongs to an admin, perform this database query:
select u.username, u.email
from auth_user u
left join piston3_consumer c
on u.id = c.user_id
where key = 'your-leaked-api-key';To remove the leaked API key, log in to the MAAS UI and delete it. Then reconfigure your MAAS CLI and hardware sync as needed.