Назад | Перейти на главную страницу

Нужно ли в MAAS 2.0 перенастроить Squid на прокси HTTP / HTTPS для всех развернутых узлов?

В Документация MAAS 2.0 поясняет следующее:

Заметка: Несмотря на то, что веб-интерфейс помечает поле внешнего прокси «Прокси для APT и HTTP / HTTPS», прокси предназначен только для APT, а не для HTTP / HTTPS, как подразумевается.

Итак, если бы я хотел, чтобы мой узел контроллера региона MAAS действовал как прокси-сервер HTTP / HTTPS для всех облачных узлов, как изменить конфигурацию Squid, чтобы взять на себя роль прокси HTTP / HTTPS (а также трафик APT - я предполагаю, что Squid является прокси APT).

В моей конфигурации у моего регионального контроллера первый сетевой адаптер подключен к офисному модему / маршрутизатору WAN, а следующий сетевой адаптер подключен к управляемому коммутатору, к которому подключены все остальные узлы. Контроллер региона - единственная машина с прямым выходом в Интернет. Все узлы MAAS могут обновлять, обновлять и устанавливать пакеты APT, но Juju не может раскручивать контейнеры LXD, потому что они не могут разрешить образы с linuxcontainers.org.

Дополнительный контекст: я тестировал руководство по настройке, представленное на http://blog.naydenov.net/2015/11/deploying-openstack-on-maas-1-9-with-juju-network-setup/ который описывает конфигурацию со всеми VLAN и подсетями, настроенными перед установкой. К сожалению, мне сложно заставить Squid позволить maas-management подсеть вне.

Было необходимо две вещи:

Squid по умолчанию блокирует все, что не является HTTPS, даже включая safe_ports.

Чтобы позволить Safe_ports, Я добавил следующие строки после acl объявления (после строки acl CONNECT method CONNECT, если убрать строки комментариев):

http_access deny !Safe_ports

http_access allow CONNECT Safe_ports
http_access deny CONNECT !SSL_ports

Я также добавил несколько строк, чтобы разрешить некоторым из VLAN http_access:

acl maas_external       src     192.168.0.0/24
http_access allow maas_external

MAAS должен иметь curtin (установщик системы) установите http_proxy переменные среды.

Я изменил late_commands раздел /etc/maas/preseeds/curtin_userdata на следующее:

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"]

По сути, это устанавливает несколько шагов для curtin следовать. Среда, в которой работает установка, недолговечна, поэтому нам нужно указать curtin чтобы применить это к самой целевой среде и убедиться, что среда настроена правильно, используйте новую (curtin in-target -- sh -c). Последнее предложение добавляет команду экспорта в конец /etc/profile чтобы он всегда жил в окружающей среде.

Надеюсь, это не перебор. По крайней мере, когда узел развернут, он может подключиться к Интернету, даже если он подключен только к контроллеру региона MAAS.