MAAS permits assigning a disk device to mount to itself

[Rod Smith]

In the MAAS web UI, it's possible to assign a disk device to mount to itself -- for instance, to mount /dev/sda3 at /dev/sda3. When so configured, MAAS will deploy the node, and that deployment will seem to succeed; however, it will be inaccessible via SSH. The console, if accessible, will not show a "login:" prompt, but a bash root prompt ("root@hostname:~#"); presumably the system is booted in maintenance mode. The /etc/fstab file shows the UUID value for the partition in the fs_spec field and the device filename (as inappropriately entered in MAAS) in the fs_file field.

This situation is obviously the result of user error; however, the symptoms are rather mysterious, and MAAS could easily handle this better by refusing to accept a mount point inside /dev, or perhaps in other locations. (In a quick check, MAAS initially seemed to accept a mount point of /etc, but then quietly removed it from the list of filesystems, so perhaps there's already some logic to handle this for some mount points.)

Below is my MAAS version information. I'm also attaching the /var/log/maas directory tree from the server, although I don't think it's relevant. (I tested this on the server "brennan.")

$ dpkg -l '*maas*'|cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===============================-====================================-============-==================================================
ii maas 2.2.2-6099-g8751f91-0ubuntu1~16.04.1 all "Metal as a Service" is a physical cloud and IPAM
ii maas-cert-server 0.2.30-0~76~ubuntu16.04.1 all Ubuntu certification support files for MAAS server
ii maas-cli 2.2.2-6099-g8751f91-0ubuntu1~16.04.1 all MAAS client and command-line interface
un maas-cluster-controller <none> <none> (no description available)
ii maas-common 2.2.2-6099-g8751f91-0ubuntu1~16.04.1 all MAAS server common files
ii maas-dhcp 2.2.2-6099-g8751f91-0ubuntu1~16.04.1 all MAAS DHCP server
ii maas-dns 2.2.2-6099-g8751f91-0ubuntu1~16.04.1 all MAAS DNS server
ii maas-proxy 2.2.2-6099-g8751f91-0ubuntu1~16.04.1 all MAAS Caching Proxy
ii maas-rack-controller 2.2.2-6099-g8751f91-0ubuntu1~16.04.1 all Rack Controller for MAAS
ii maas-region-api 2.2.2-6099-g8751f91-0ubuntu1~16.04.1 all Region controller API service for MAAS
ii maas-region-controller 2.2.2-6099-g8751f91-0ubuntu1~16.04.1 all Region Controller for MAAS
un maas-region-controller-min <none> <none> (no description available)
un python-django-maas <none> <none> (no description available)
un python-maas-client <none> <none> (no description available)
un python-maas-provisioningserver <none> <none> (no description available)
ii python3-django-maas 2.2.2-6099-g8751f91-0ubuntu1~16.04.1 all MAAS server Django web framework (Python 3)
ii python3-maas-client 2.2.2-6099-g8751f91-0ubuntu1~16.04.1 all MAAS python API client (Python 3)
ii python3-maas-provisioningserver 2.2.2-6099-g8751f91-0ubuntu1~16.04.1 all MAAS server provisioning libraries (Python 3)

[Adam Collard (adam-collard)]

This bug has not seen any activity in the last 6 months, so it is being automatically closed.

If you are still experiencing this issue, please feel free to re-open.

MAAS Team

[Rod Smith (rodsmith)]

This bug still exists in MAAS 2.6.0 (7802-g59416a869-0ubuntu1~18.04.1)

[Jerzy Husakowski (jhusakowski)]

While it would be useful to prevent this particular user error from happening, there's no way to prevent other types of user errors related to defining storage configuration using the current MAAS UI, and the operator could still make similar user error using the CLI. There's a roadmap item for MAAS to change the way storage configuration is handled, where it will be possible to address this and other UX issues.