MAAS could be more helpful with scripted installation scenarios to cover common network setups

Hi Jeff,

My nodes can access the Internet perfectly well, which demonstrates that your problem is entirely dependent on each kind of network set up.

This is partly why there is a proxy setting on the region controller, but this is not used after the node is installed.

So I think MAAS can do better in a couple of ways:
 1. Set up the proxy on installed nodes if it's set on the region's settings
 2. Allow admins to configure ip forwarding on the region controller

However #2 is problematic because the region controller is not really a single machine on scaled-out installation, there could be many appservers and Postgres slaves.

How do you think MAAS could help in that scenario where the region is not a single machine?

Cheers.

Hi Julian,

I've got several MAAS servers that seem to suffer the same fate, depending on what your definition of "Access the internet" is.

We first saw this at the Orange Box sprint in london where nodes could be deployed via d-i which was pulling packages from MAAS's squid-deb-proxy, IIRC, however they couldn't pull packages afterwards from ppa.launchpad.net or "the internet" in general (e.g. I couldn't ssh to a node and they wget a file from somewhere else).

A good example of this was when we tried usign juju to deploy certain charms that pull from places like github, the charms would fail because those sites were unreachable from the node itself (but not from the MAAS Server). So we configured NAT to allow the nodes to pass through to the internet to reach "anywhere".

In our immediate case with certification, we have several NUCs that are configured as MAAS servers for deploying both the OS and certification tools.

So here is IP Tables after a fresh reboot of my NUC running the latest 14.04 MAAS:
ubuntu@critical-maas:~$ sudo iptables -L
[sudo] password for ubuntu:
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ubuntu@critical-maas:~$ sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
ubuntu@critical-maas:~$
ubuntu@critical-maas:~$ COLUMNS=150 dpkg -l |grep maas
ii maas 1.5+bzr2252-0ubuntu1 all MAAS server all-in-one metapackage
ii maas-cli 1.5+bzr2252-0ubuntu1 all MAAS command line API tool
ii maas-cluster-controller 1.5+bzr2252-0ubuntu1 all MAAS server cluster controller
ii maas-common 1.5+bzr2252-0ubuntu1 all MAAS server common files
ii maas-dhcp 1.5+bzr2252-0ubuntu1 all MAAS DHCP server
ii maas-dns 1.5+bzr2252-0ubuntu1 all MAAS DNS server
ii maas-region-controller 1.5+bzr2252-0ubuntu1 all MAAS server complete region controller
ii maas-region-controller-min 1.5+bzr2252-0ubuntu1 all MAAS Server minimum region controller
ii maas-test 0.1+bzr147+150+10~pp all Utility to test hardware compatibility with MAAS
ii python-django-maas 1.5+bzr2252-0ubuntu1 all MAAS server Django web framework
ii python-maas-client 1.5+bzr2252-0ubuntu1 all MAAS python API client
ii python-maas-provisioningserver 1.5+bzr2252-0ubuntu1 all MAAS server provisioning libraries

Now I have the server inst...

Status changed to 'Confirmed' because the bug affects multiple users.

As for your question about the region... I don't know... that's operating at scale. The question there is probably one of hierarchy... for example, would you have multiple, linked region controllers, or more like a few region controllers and several cluster controllers under each?

And in that case, perhaps you'd want to be able to arbitrarily set this assuming each region and cluster controller is a physical machine:

Region1 -- Dashboard -- cluster 1
                                                 |-- cluster 2
                                                 |-- cluster 3
                                                 |-- cluster 4
                                                              |---node 1
                                                              |---node 2
                                                              |---node X

So perhaps you would want to be able to, via the dashboard, or some other means say, Cluster 1 shoud be segregated and never pass packets out, but cluster 4 are all web-servers and associated servers and DO need to be able to send and recieve from the internet and cluster 3 contains the things teh web servers need on the back end (SQL, etc) so Cluster 3 should only talk to cluster 4 and NEVER talk to the internet.

Or I don't know, that's really a VERY ugly example.

My original point was just that, by default on my very simple use case (and also as seen with the Orange Boxes), the deployed nodes can't talk to the internet without some manual futzing behind the scenes, and there's no simple way to fix that if you don't know iptables scripting and what bits to flip.

Then again, perhaps something as simple as a 'maas-enable-nat' command for these simple cases would be sufficient so new users don't have to also understand iptables... and makes it optional on the maas server so you can or can not enable it... maybe it is a per-cluster-controller thing, as my understanding is that the region controller just handles certain things whie the clusters do the bulk of the work for the nodes...

I dont have the hardware really to set up a different cluster controller... for now.

To add to this, as I also am experiencing this problem:

My maas has 2 nics and 2 networks:
  Outbound eth1: talks to the world (or in thsi case my partner OEM's lab network
  Private eth0: talks only to maas-create nodes. Call it 10.0.0.0/24 .

I've set up maas as DHCP & DNS manager for eth0. I have *not* NATed eth0 as the Partner OEM does not like private NATs on its lab network. My /etc/resolv.conf, /etc/maas/dhcp.conf and /etc/dhcp/dhclient.conf are saying the right things.

When I create node1 (using fastpath install) I can ping other things on the 10.0.0.0/24 network (by name or address) but cannot ping google.com (even though the name resolves correctly). If I turn on NAT this works.

This makes post-node-startup installation and configuration very problematic.

Actually, my last comment encompasses a different problem (that of isolation), so ignore it.

But do count this as a vote to some kind of "NAT on/off" tooling in MAAS.

Jeff,

Everyone's network setup can be different and MAAS tries not to be prescriptive at all but does assume that anyone setting this stuff up will know a bit about networks. If you are hiding your nodes from the internet behind your MAAS server then I don't think I'd say that MAAS is actively doing anything to harm you here, you just need to know to enable ip_forward and NAT.

As I said in my first reply, I think MAAS can do a bit better at helping these simple "seed cloud" setups and encourage a scripted installation that will configure everything for you. This sort of thing would rarely get used on large installs though as most large users will be a bit more paranoid about explicitly configuring every tiny detail themselves. Many of them don't even want MAAS to manage DHCP.

I'll amend the title of this bug now to reflect the fact that we want MAAS to do some scripted installation scenarios to cover common "small" use cases.

Thanks for filing this!