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 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 installed and try a couple things to see if my node can talk to the internet:
ubuntu@supermicro:~$ host ubuntu.com
ubuntu.com has address 91.189.94.156
ubuntu.com mail is handled by 10 mx.canonical.com.
I am able to install something:
ubuntu@supermicro:~$ sudo apt-get install ksh
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
ksh
0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded.
Need to get 1,583 kB of archives.
After this operation, 3,229 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com//ubuntu/ trusty/universe ksh amd64 93u+20120801-1 [1,583 kB]
Fetched 1,583 kB in 7s (223 kB/s)
Selecting previously unselected package ksh.
(Reading database ... 69996 files and directories currently installed.)
Preparing to unpack .../ksh_93u+20120801-1_amd64.deb ...
Unpacking ksh (93u+20120801-1) ...
Processing triggers for man-db (2.6.7.1-1) ...
Setting up ksh (93u+20120801-1) ...
update-alternatives: using /bin/ksh93 to provide /bin/ksh (ksh) in auto mode
but is that going through the squid deb proxy?
Because I am unable to manually touch archive.ubuntu.com:
--2014-04-22 18:38:29-- http://archive.ubuntu.com/ubuntu/pool/universe/k/ksh/ksh_93u+20120801-1_amd64.deb
Resolving archive.ubuntu.com (archive.ubuntu.com)... 91.189.92.200, 91.189.91.13, 91.189.91.14, ...
Connecting to archive.ubuntu.com (archive.ubuntu.com)|91.189.92.200|:80... failed: Connection timed out.
Connecting to archive.ubuntu.com (archive.ubuntu.com)|91.189.91.13|:80... failed: Connection timed out.
Connecting to archive.ubuntu.com (archive.ubuntu.com)|91.189.91.14|:80... failed: Connection timed out.
So now I start NAT:
ubuntu@critical-maas:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
I don't have anything fancy set up here... my setup is literally:
node <--1Gb--> Cheap 8port Switch <--1Gb--> NUC <--1Gb--> Ext. LAN cheap 8 port swtich <-- 1Gb --> Gateway <--10Mb DSL --> Internet
I am not doing any weird packet filtering or other firewalling on my external connection, nor anywhere else. Nothing sitting in a DMZ.
So my theory is that by default, I am able to install things via archive.ubuntu and maybe even ppa.launchpad because of the deb proxy running on the MAAS server, however, as soon as I try any other type of request directly from the node, it fails without something like NAT on the MAAS server to pass traffic.
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: critical- maas:~$ sudo iptables -L
ubuntu@
[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) critical- maas:~$ sudo iptables -L -t nat
target prot opt source destination
ubuntu@
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) critical- maas:~$ critical- maas:~$ COLUMNS=150 dpkg -l |grep maas 0ubuntu1 all MAAS server all-in-one metapackage 0ubuntu1 all MAAS command line API tool controller 1.5+bzr2252- 0ubuntu1 all MAAS server cluster controller 0ubuntu1 all MAAS server common files 0ubuntu1 all MAAS DHCP server 0ubuntu1 all MAAS DNS server controller 1.5+bzr2252- 0ubuntu1 all MAAS server complete region controller controller- min 1.5+bzr2252- 0ubuntu1 all MAAS Server minimum region controller 150+10~ pp all Utility to test hardware compatibility with MAAS 0ubuntu1 all MAAS server Django web framework 0ubuntu1 all MAAS python API client maas-provisioni ngserver 1.5+bzr2252- 0ubuntu1 all MAAS server provisioning libraries
target prot opt source destination
ubuntu@
ubuntu@
ii maas 1.5+bzr2252-
ii maas-cli 1.5+bzr2252-
ii maas-cluster-
ii maas-common 1.5+bzr2252-
ii maas-dhcp 1.5+bzr2252-
ii maas-dns 1.5+bzr2252-
ii maas-region-
ii maas-region-
ii maas-test 0.1+bzr147+
ii python-django-maas 1.5+bzr2252-
ii python-maas-client 1.5+bzr2252-
ii python-
Now I have the server installed and try a couple things to see if my node can talk to the internet: supermicro: ~$ host ubuntu.com
ubuntu@
ubuntu.com has address 91.189.94.156
ubuntu.com mail is handled by 10 mx.canonical.com.
ubuntu@ supermicro: ~$ sudo ping -c 10 www.ubuntu.com
PING www.ubuntu.com (91.189.89.103) 56(84) bytes of data.
--- www.ubuntu.com ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9071ms
I am able to install something: supermicro: ~$ sudo apt-get install ksh archive. ubuntu. com//ubuntu/ trusty/universe ksh amd64 93u+20120801-1 [1,583 kB] 93u+20120801- 1_amd64. deb ... alternatives: using /bin/ksh93 to provide /bin/ksh (ksh) in auto mode
ubuntu@
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
ksh
0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded.
Need to get 1,583 kB of archives.
After this operation, 3,229 kB of additional disk space will be used.
Get:1 http://
Fetched 1,583 kB in 7s (223 kB/s)
Selecting previously unselected package ksh.
(Reading database ... 69996 files and directories currently installed.)
Preparing to unpack .../ksh_
Unpacking ksh (93u+20120801-1) ...
Processing triggers for man-db (2.6.7.1-1) ...
Setting up ksh (93u+20120801-1) ...
update-
but is that going through the squid deb proxy?
Because I am unable to manually touch archive.ubuntu.com: archive. ubuntu. com/ubuntu/ pool/universe/ k/ksh/ksh_ 93u+20120801- 1_amd64. deb ubuntu. com)... 91.189.92.200, 91.189.91.13, 91.189.91.14, ... ubuntu. com)|91. 189.92. 200|:80. .. failed: Connection timed out. ubuntu. com)|91. 189.91. 13|:80. .. failed: Connection timed out. ubuntu. com)|91. 189.91. 14|:80. .. failed: Connection timed out.
--2014-04-22 18:38:29-- http://
Resolving archive.ubuntu.com (archive.
Connecting to archive.ubuntu.com (archive.
Connecting to archive.ubuntu.com (archive.
Connecting to archive.ubuntu.com (archive.
So now I start NAT: critical- maas:~$ sudo iptables -L
ubuntu@
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT) critical- maas:~$ sudo iptables -L -t nat
target prot opt source destination
ubuntu@
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
MASQUERADE all -- anywhere anywhere
And try again: supermicro: ~$ wget http:// archive. ubuntu. com/ubuntu/ pool/universe/ k/ksh/ksh_ 93u+20120801- 1_amd64. deb archive. ubuntu. com/ubuntu/ pool/universe/ k/ksh/ksh_ 93u+20120801- 1_amd64. deb ubuntu. com)... 91.189.91.14, 91.189.92.201, 91.189.92.200, ... ubuntu. com)|91. 189.91. 14|:80. .. connected. x-debian- package] 20120801- 1_amd64. deb’
ubuntu@
--2014-04-22 18:46:23-- http://
Resolving archive.ubuntu.com (archive.
Connecting to archive.ubuntu.com (archive.
HTTP request sent, awaiting response... 200 OK
Length: 1583190 (1.5M) [application/
Saving to: ‘ksh_93u+
100%[== ======= ======= ======= ======= ======= ======= ======= ======= ======= ======= ======= ======= ======= ===>] 1,583,190 173KB/s in 5.9s
2014-04-22 18:46:29 (262 KB/s) - ‘ksh_93u+ 20120801- 1_amd64. deb’ saved [1583190/1583190]
et voila!
I don't have anything fancy set up here... my setup is literally:
node <--1Gb--> Cheap 8port Switch <--1Gb--> NUC <--1Gb--> Ext. LAN cheap 8 port swtich <-- 1Gb --> Gateway <--10Mb DSL --> Internet
I am not doing any weird packet filtering or other firewalling on my external connection, nor anywhere else. Nothing sitting in a DMZ.
So my theory is that by default, I am able to install things via archive.ubuntu and maybe even ppa.launchpad because of the deb proxy running on the MAAS server, however, as soon as I try any other type of request directly from the node, it fails without something like NAT on the MAAS server to pass traffic.