Informações de gateway para o MAAS e falha no comissionamento

0

Estou tentando configurar um ambiente MAAS (MAAS Versão 2.1.1 + bzr5544-0ubuntu1 (16.04.1)) e executando alguns problemas de gateway. O sintoma é que o comissionamento falha em alguns casos durante o cloud-init inicial (incapaz de ssh para o servidor) e em outros casos durante a tentativa de extrair pacotes (capaz de ssh para o servidor).

Sub-rede: 10.71.0.0/16 Gateway: 10.71.0.1 Proxy da Web (acessível para nós com gateway padrão definido como 10.10.0.1): 192.85.88.10:8080

Servidor MAAS: Ubuntu 16.04.01, IP: 10.71.4.10

  • Abordagem nº 1: defina o IP do gateway MAAS para o gateway global IP 10.71.0.1 em a GUI

O MAAS install relata falha ao tentar acessar 169.254.169.254 e não permite o login em um sistema inicializado.

  • Abordagem # 2: Defina o IP do gateway MAAS para o endereço IP principal no MAAS servidor, ou seja, 10.71.4.10

O MAAS é instalado com êxito, o host recebe o nome, consegue fazer login no host.

ubuntu@unique-quail:~$ uname -a
Linux unique-quail 4.4.0-57-generic #78-Ubuntu SMP Fri Dec 9 23:50:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@unique-quail:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
4: eno3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq portid 0100000000000000000000563035304833 state UP group default qlen 1000
    link/ether 38:63:bb:2b:20:d0 brd ff:ff:ff:ff:ff:ff
    inet 10.71.4.20/16 brd 10.71.255.255 scope global eno3
       valid_lft forever preferred_lft forever
    inet6 fe80::3a63:bbff:fe2b:20d0/64 scope link
       valid_lft forever preferred_lft forever

No entanto, o MAAS falha no comissionamento, pois não é capaz de extrair e instalar pacotes dos arquivos do Ubuntu. Um excerto do cloud-init-output.log está abaixo

E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/f/freeipmi/libipmidetect0_1.4.11-1.1ubuntu2~0.16.04_amd64.deb  Unable to connect to 192.85.88.10:8080:

No entanto, dentro do host, vejo que a rota padrão está definida para o IP do gateway (10.71.4.10) em vez do gateway padrão 10.71.0.1, uma vez que foi especificado no campo Gateway IP da GUI.

ubuntu@unique-quail:~$ ip route
default via 10.71.4.11 dev eno3
10.71.0.0/16 dev eno3  proto kernel  scope link  src 10.71.4.20

Com essa configuração, não consigo acessar a Internet porque o servidor MAAS não está configurado para fazer NAT-ing. Por exemplo, uma atualização do apt-get falha com essa configuração.

ubuntu@unique-quail:/var/log$ sudo apt-get -y install apache2
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  apache2-bin apache2-data apache2-utils libapr1 libaprutil1 libaprutil1-dbd-sqlite3
  libaprutil1-ldap liblua5.1-0 ssl-cert
Suggested packages:
  www-browser apache2-doc apache2-suexec-pristine | apache2-suexec-custom openssl-blacklist
The following NEW packages will be installed:
  apache2 apache2-bin apache2-data apache2-utils libapr1 libaprutil1 libaprutil1-dbd-sqlite3
  libaprutil1-ldap liblua5.1-0 ssl-cert
0 upgraded, 10 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,554 kB of archives.
After this operation, 6,412 kB of additional disk space will be used.
0% [Connecting to 16.85.88.10 (16.85.88.10)]

Quando eu altero o gateway padrão para o gateway real ou quando adiciono uma rota estática ao meu servidor proxy por meio do gateway padrão, consigo extrair os pacotes conforme o esperado.

ubuntu@unique-quail:/var/log$ sudo ip route add 192.85.88.10 via 10.71.0.1
sudo: unable to resolve host unique-quail: Connection refused
ubuntu@unique-quail:/var/log$ ip route
default via 10.71.4.11 dev eno3
10.71.0.0/16 dev eno3  proto kernel  scope link  src 10.71.4.20
192.85.88.10 via 10.71.0.1 dev eno3

Após adicionar a rota, as coisas funcionam como esperado (abaixo, com alguns recortes para brevidade)

ubuntu@unique-quail:/var/log$ sudo apt-get -y install apache2
sudo: unable to resolve host unique-quail: Connection refused
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  apache2-bin apache2-data apache2-utils libapr1 libaprutil1 libaprutil1-dbd-sqlite3
  libaprutil1-ldap liblua5.1-0 ssl-cert
Suggested packages:
  www-browser apache2-doc apache2-suexec-pristine | apache2-suexec-custom openssl-blacklist
The following NEW packages will be installed:
  apache2 apache2-bin apache2-data apache2-utils libapr1 libaprutil1 libaprutil1-dbd-sqlite3
  libaprutil1-ldap liblua5.1-0 ssl-cert
0 upgraded, 10 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,554 kB of archives.
After this operation, 6,412 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu xenial/main amd64 libapr1 amd64 1.5.2-3 [86.0 kB]
Get:2 http://archive.ubuntu.com/ubuntu xenial/main amd64 libaprutil1 amd64 1.5.4-1build1 [77.1 kB]
Get:3 http://archive.ubuntu.com/ubuntu xenial/main amd64 libaprutil1-dbd-sqlite3 amd64 1.5.4-1build1 [10.6 kB]
Processing triggers for ureadahead (0.100.0-19) ...
Processing triggers for ufw (0.35-0ubuntu2) ...
ubuntu@unique-quail:/var/log$ dpkg -l | grep -i apache2
ii  apache2                          2.4.18-2ubuntu3.1                  amd64        Apache HTTP Server
ii  apache2-bin                      2.4.18-2ubuntu3.1                  amd64        Apache HTTP Server (modules and other binary files)

A causa raiz da falha no comissionamento parece ser a incapacidade de acessar a Internet depois que o sistema é inicialmente configurado. No entanto, se eu alterar o gateway para apontar para o gateway real em vez do IP do servidor MAAS, o cloud-init falhará procurando pelo 169 IP (que, suponho, é endereçado pela instância maas)

Eu tentei adicionar um script de comissionamento através da GUI para adicionar a rota estática que criei, pois não consegui adicionar uma rota estática a um destino fora do CIDR da sub-rede. Alguém pode me apontar na direção certa?

  • Como posso fazer o cliente consultar o servidor MAAS para o init inicial da nuvem e depois para o proxy regular dos pacotes?

  • Eu observei que o processo maas-proxy não estava em execução mesmo se eu o iniciei manualmente. Este é um problema em potencial? Nenhum registro de erros é relatado e basicamente é encerrado.

  • Como posso ativar meu servidor MAAS para atuar como um proxy ou fazer com que ele redirecione IPs para o gateway real para que os nós possam acessar a Internet para obter pacotes?

por Carrot Irounfoundersson 22.12.2016 / 01:04

0 respostas