Criggie's questions

Temos desenvolvedores que gostam de fazer as coisas do seu jeito, independentemente dos conselhos dados. Uma delas é enviar e-mails com endereços de remetentes completamente falsos

Gostaria que o OpenDKIM rejeitasse ou descartasse e-mails que não consegue assinar - isso é possível?

Jan  4 21:30:25 smtp2 opendkim: 12345: no signing table match for '[email protected]'
Jan  4 21:30:25 smtp2 opendkim: 12345: no signature data

Não há opções de configuração que pareçam relevantes, exceto SendReports yesa que gera um novo e-mail de volta ao remetente enquanto continua a enviar o original não assinado.

Eu explorei Canonicalization, mas isso não tem relação.

Pergunta : O OpenDKIM pode interromper a entrega de um e-mail que não consegue assinar?

Como parte do meu trabalho diário, gerencio alguns pools de xenserver. Eu tenho trabalhado com os antigos, trazendo-os para o xenserver 6.5 de uma variedade de versões anteriores 5.5, 6.0, 6.1 e 6.2

Muitas das VMs agora têm uma versão mais antiga das ferramentas xenserver instaladas. Na guia Geral da VM, diz algo como

 Virtualisation state:  Tools out of date (version 5.5 installed)
 Virtualisation state:  Tools out of date (version 6.0 installed)

Ou confusamente

 Virtualisation state:  Optimised (version 6.2 installed)

Quais são as possíveis desvantagens de deixar as VMs como estão? Existem possíveis problemas de desempenho ou confiabilidade? Esta questão não é se o xentools deve ser instalado, mas se as atualizações das ferramentas são importantes.

Eu tenho um pool xenserver 6.5 funcional com dois nós. Ele é apoiado por um compartilhamento iscsi em um Dell MD3600i SAN e funciona bem. Foi criado antes do meu tempo.

Adicionamos mais três nós ao pool. No entanto, esses três novos nós não se conectarão ao armazenamento.

Aqui está um dos nós originais, funcionando bem:

[root@node1 ~]# iscsiadm -m session
tcp: [2] 10.19.3.11:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [3] 10.19.3.14:3260,2 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [4] 10.19.3.12:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [5] 10.19.3.13:3260,2 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)

Aqui está um dos novos nós. Observe a corrupção no endereço?

[root@vnode3 ~]# iscsiadm -m session
tcp: [1] []:-1,2 ▒A<g▒▒▒-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [2] 10.19.3.12:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [3] 10.19.3.11:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [4] 10.19.3.14:3260,2 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)

O endereço IP ausente é 0,13, mas outro nó está ausente 0,12

Comentários :

Tenho VMs de produção em execução ao vivo nos nós existentes e nenhum lugar para movê-las, portanto, reinicializar a SAN não é uma opção.

O multipathing está desabilitado nos nós originais, apesar do san ter 4 interfaces. Isso parece abaixo do ideal, então ativei caminhos múltiplos nos novos nós.

Os três novos nós têm cargas de sistema extremamente altas. As caixas originais têm uma média de carga de 0,5 para 1, e os três novos nós estão em cerca de 11,1, sem VMs em execução. top não mostra processos de alta CPU, então é algo relacionado ao kernel? Não há processos bloqueados no estado D (suspensão ininterrupta)

Se eu disser ao Xencenter para "consertar" esses repositórios de armazenamento, ele ficará girando por horas até que eu clique em cancelar. a mensagem éPlugging PDB for node5

Pergunta : Como faço para que meus novos membros do pool xenserver vejam o armazenamento do pool e funcionem conforme o esperado?

EDITAR Mais informações

• Nenhum dos novos nós fará uma reinicialização limpa - eles ficam presos em "parar o iSCSI" em uma reinicialização e eu tenho que usar o drac para religá-los remotamente.
• O Xencenter está convencido de que os nós estão em modo de manutenção e que não concluíram a inicialização.

Bom nó de pool:

[root@node1 ~]# multipath -ll
36f01faf000eaf7f90000076255c4a0f3 dm-36 DELL,MD36xxi
size=3.3T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=12 status=enabled
| |- 14:0:0:6 sdg 8:96  active ready running
| `- 15:0:0:6 sdi 8:128 active ready running
`-+- policy='round-robin 0' prio=11 status=enabled
  |- 12:0:0:6 sdc 8:32  active ready running
  `- 13:0:0:6 sdh 8:112 active ready running
36f01faf000eaf6fd0000098155ad077f dm-35 DELL,MD36xxi
size=917G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=14 status=enabled
| |- 12:0:0:5 sdb 8:16  active ready running
| `- 13:0:0:5 sdd 8:48  active ready running
`-+- policy='round-robin 0' prio=9 status=enabled
  |- 14:0:0:5 sde 8:64  active ready running
  `- 15:0:0:5 sdf 8:80  active ready running

Nó ruim

[root@vnode3 ~]# multipath
Dec 24 02:56:44 | 3614187703d4a1c001e0582691d5d6902: ignoring map
[root@vnode3 ~]# multipath -ll
[root@vnode3 ~]#                           (ie no response at all, exit code was 0)

Nó ruim

[root@vnode3 ~]# iscsiadm -m session
tcp: [1] []:-1,2 ▒A<g▒▒▒-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [2] 10.19.3.12:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [3] 10.19.3.11:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [4] 10.19.3.14:3260,2 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)

[root@vnode3 ~]# iscsiadm -m node --loginall=all
Logging in to [iface: default, target: iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb, portal: 10.19.3.13,3260] (multiple)
^C iscsiadm: caught SIGINT, exiting...

Então, ele tenta fazer login em um IP no SAN, mas gira suas rodas por horas até eu acertar ^ C.