0

The MAAS 2.0 documentation clarifies the following:

Note: Despite the web interface labelling the external proxy field 'Proxy for APT and HTTP/HTTPS', the proxy is only for APT and not for HTTP/HTTPS as implied.

So if I wanted to have my MAAS region controller node to act as the HTTP/HTTPS proxy for all the cloud nodes, how do I change the Squid configuration to take on the HTTP/HTTPS proxy role (as well as the APT traffic - I assume Squid is the APT proxy).

In my configuration, my region controller has the first NIC connected to the office WAN modem/router, and the next NIC connected to a managed switch that all the other nodes are connected to. The region controller is the only machine with a direct line to the internet. All MAAS nodes can update, upgrade, and install APT packages, but Juju can't spin up LXD containers because they can't resolve the images from the linuxcontainers.org .

Additional context: I was testing out the setup tutorialized at http://blog.naydenov.net/2015/11/deploying-openstack-on-maas-1-9-with-juju-network-setup/ which describes a configuration with all the VLANs and subnets set up before install. Unfortunately, I'm having a hard time getting Squid to let the maas-management subnet out.

1 Answer 1

1

There were two things needed:

Squid by default blocks everything that isn't HTTPS, even including the safe_ports.

To allow the Safe_ports, I added the following lines after the acl declarations (after the line acl CONNECT method CONNECT, if you remove the comment lines):

http_access deny !Safe_ports

http_access allow CONNECT Safe_ports
http_access deny CONNECT !SSL_ports

I also added a number of lines to allow some of the VLANs http_access:

acl maas_external       src     192.168.0.0/24
http_access allow maas_external

MAAS needs to have curtin (the system installer) set the http_proxy environment variables.

I modified the late_commands section of /etc/maas/preseeds/curtin_userdata to the following:

late_commands:
  maas: [wget, '--no-proxy', '{{node_disable_pxe_url|escape.shell}}', '--post-data', '{{node_disable_pxe_data|escape.shell}}', '-O', '/dev/null']
  setup_http_proxy_01: ["curtin", "in-target", "--", "sh", "-c", "echo \"export http_proxy='{{http_proxy}}'\" | sudo tee --append  /etc/profile"]
  setup_http_proxy_02: ["curtin", "in-target", "--", "sh", "-c", "echo \"export HTTP_PROXY='{{http_proxy}}'\" | sudo tee --append  /etc/profile"]
  setup_http_proxy_03: ["curtin", "in-target", "--", "sh", "-c", "echo \"export https_proxy='{{http_proxy}}'\" | sudo tee --append  /etc/profile"]
  setup_http_proxy_04: ["curtin", "in-target", "--", "sh", "-c", "echo \"export HTTPS_PROXY='{{http_proxy}}'\" | sudo tee --append  /etc/profile"]
  setup_http_proxy_05: ["curtin", "in-target", "--", "sh", "-c", "echo \"export ftp_proxy='{{http_proxy}}'\" | sudo tee --append  /etc/profile"]
  setup_http_proxy_06: ["curtin", "in-target", "--", "sh", "-c", "echo \"export FTP_PROXY='{{http_proxy}}'\" | sudo tee --append  /etc/profile"]

Basically, this sets a few steps for curtin to follow. The environment that the setup runs in is ephemeral, so we need to instruct curtin to apply this to the target environment itself, and to make sure the environment is set up right, use a fresh one (curtin in-target -- sh -c). The final clause appends the export command to the end of /etc/profile to make sure that it's always live in the environment.


I'm hoping this isn't overkill. At the very least, when a node is deployed it can hit the internet even though it's only connected to the MAAS region controller.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .