Marco's questions

Estou trabalhando na migração de um cluster vSphere 6.7 de 2 hosts existente para um novo vCenter Server Appliance 8.0. Os hosts vSphere e ESXi de ambos os clusters estão na versão mais recente disponível.

Novo cluster: vSphere 8.0.3.00200 (Build: 24262322)

Novo host: ESXi, 8.0.3, 24280767

Cluster antigo: vSphere 6.7.0.55000 (Build: 22509723)

Hosts antigos: ESXi, 6.7.0, 20497097

Para realizar essa tarefa, comprei um novo host baseado em Raptor Lake (Xeon E-2468). Os hosts antigos são idênticos, ambos Coffee Lake (Xeon E-2146G).

Não consigo encontrar uma compatibilidade EVC que corresponda a ambos os tipos de hosts. Os hosts Coffee Lake são admitidos com sucesso no cluster habilitado para a geração Broadwell, mas quando tento adicionar o host mais novo, recebo um erro informando:

The host's CPU hardware does not support the cluster's current Enhanced vMotion Compatibility mode. The host CPU lacks features required by that mode.

Eu esperava que apenas os processadores mais antigos não tivessem recursos disponíveis para os mais novos, mas não parece. O modo Broadwell Generation mais antigo requer alguns recursos que o mais novo Raptor Lake E-2468 aparentemente não tem.

Encontrei muito pouca literatura sobre esse problema, inclusive no KB da Broadcom, onde surpreendentemente a Arquitetura "Coffee Lake" nem sequer é mencionada. Também não posso pedir suporte VMware porque o contrato de suporte 6.7 já acabou, e o vSphere 8.0 ainda está em avaliação.

Estou prestes a desistir de usar o modo EVC porque não consigo fazê-lo funcionar com essa combinação de hosts, então estou perguntando aqui apenas para ter certeza de que não estou esquecendo nada importante para a configuração. Os hosts mais antigos serão desativados em qualquer caso, mas como isso acontecerá em 6 a 9 meses, eu não queria desistir do EVC, se possível.

Nota relevante: todos os três hosts são hardware Dell Enterprise, R340 e R360.

Acabei de receber a licença acima da VMware para um dos meus clientes. O dispositivo VCA 6.7 e os dois hosts ESXi estavam sendo executados no modo de avaliação. Não tive problemas para inserir a licença do appliance VCA, mas ao tentar licenciar um dos hosts, recebo a seguinte mensagem:

A licença não oferece suporte a alguns dos recursos atualmente em uso pelos ativos licenciados.

-vSphere FT

Não tenho esse recurso habilitado em nenhuma máquina virtual e, até onde sei, isso não é uma coisa de nível de cluster ou host, é apenas um recurso de nível de VM.

Também tentei migrar qualquer máquina virtual para fora do host e remover o host do cluster, mas nada muda.

Também abri um ticket com eles e ficarei feliz em compartilhar sua solução mais tarde.

Cenário:

Este é um servidor de correio de produção há 4 anos, com cerca de 2.000 caixas de correio em ~ 50 domínios, e funciona bem com quase qualquer outro servidor de correio. Os logs são constantemente observados e o seguinte problema surgiu recentemente.

Edit 1 : Ubutntu 16.04.6 - postfix (3.1.0-3ubuntu0.3)

Questão:

Há um servidor de correio que parece incapaz de entregar correio a este sistema.

Ele falha com 4.7.25 Host do cliente rejeitado.

NOQUEUE: reject: RCPT from unknown[159.135.224.3]: 450 4.7.25 Client host rejected: cannot find your hostname, [159.135.224.3]

Foi assim que configurei o postfix, pois quero evitar retransmissores sem registro de DNS reverso.

root@mail:~# grep restrictions /etc/postfix/main.cf
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_rbl_client zen.spamhaus.org, check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf, check_recipient_access mysql:/etc/postfix/mysql-virtual_policy_greylist.cf, check_policy_service unix:private/policy-spf
smtpd_helo_restrictions = permit_sasl_authenticated, permit_mynetworks, check_helo_access regexp:/etc/postfix/helo_access, reject_invalid_hostname, reject_non_fqdn_hostname, reject_invalid_helo_hostname, reject_unknown_helo_hostname, check_helo_access regexp:/etc/postfix/blacklist_helo
smtpd_sender_restrictions = check_sender_access regexp:/etc/postfix/tag_as_originating.re , permit_mynetworks, permit_sasl_authenticated, check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf, check_sender_access regexp:/etc/postfix/tag_as_foreign.re, reject_unknown_sender_domain, reject_unknown_reverse_client_hostname, check_client_access hash:/etc/postfix/client_access, reject_unknown_client_hostname
smtpd_client_restrictions = check_client_access mysql:/etc/postfix/mysql-virtual_client.cf

MAS tem um válido, teste executado localmente no servidor de correio:

Testes de DNS em 159.135.224.3

root@mail:~# nslookup 159.135.224.3
Server:         1.1.1.1
Address:        1.1.1.1#53

Non-authoritative answer:
3.224.135.159.in-addr.arpa      name = relay.teamgioia.it.

Authoritative answers can be found from:

root@mail:~# dig 159.135.224.3

; <<>> DiG 9.10.3-P4-Ubuntu <<>> 159.135.224.3
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23656
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;159.135.224.3.                 IN      A

;; AUTHORITY SECTION:
.                       10165   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2019083000 1800 900 604800 86400

;; Query time: 6 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Aug 30 12:18:21 CEST 2019
;; MSG SIZE  rcvd: 117

Em resolv.conf:

nameserver 1.1.1.1
nameserver 1.0.0.1

Perguntas:

Por que não reject_unknown_client_hostnameestá funcionando como eu esperava?

Se isso não for culpa do servidor, mas do remetente, como posso colocar alguns remetentes na lista de permissões para evitar que seus e-mails sejam rejeitados?

Você também poderia explicar ou especular qual é a culpa deles?

No esforço de trazer algumas das vantagens do Linux para meus clientes que executam o Windows 10, desenvolvi alguns scripts bash para automatizar algumas de suas tarefas diárias.

Eu costumo deixá-los executar os scripts através de um lote do Windows com o seguinte conteúdo:

Ubuntu1804 run /usr/local/bin/script.sh

Infelizmente, alguns dos scripts estão demorando muito, seja para grandes consultas sql ou operações lentas de rede e E/S, e durante essa espera alguns usuários simplesmente não conseguem evitar fechar a "janela preta estranha", matando assim o processo.

O comando acima será eliminado mesmo se colocado entre aspas com & no final.

Eu tentei o seguinte e não consegui testOKna minha área de trabalho.

Ubuntu1804 run "sleep 10 && touch /mnt/c/Users/myuser/Desktop/testOK &"

Enquanto isso mantém a janela aberta e cria o arquivo testOK.

Ubuntu1804 run "sleep 10 && touch /mnt/c/Users/myuser/Desktop/testOK"

Eu queria saber se existe uma maneira de evitar que o processo no Ubuntu WSL seja morto assim que a janela for fechada.

Impedir que a janela apareça seria ótimo também.

Impedir que o usuário interaja com ele seria uma solução alternativa aceitável.

Os clientes são o Windows 10 Professional com o pacote cumulativo de segurança e qualidade mais recente, não estou fornecendo detalhes do site, pois isso está acontecendo em mais de um cliente, alguns deles são grandes domínios do MS AD, outros são pequenos escritórios com apenas um grupo de trabalho.

Estou tentando agrupar uma operação que conta arquivos em uma determinada subpasta de uma unidade NFS remota.

O cliente NFS é o Ubuntu 16.04 LTS. Eu tenho muito poucas informações sobre o servidor NFS remoto. É um NFS v3. É montado anonimamente em rw e sua autenticação é baseada em IP. A largura de banda do cliente é 100/10 e pode carregar em torno de 1,1 MB/s. O provedor anuncia que seu armazenamento de backup é garantido de 1 Gbit/1 Gbit. O tamanho utilizável do volume é <4 TB, a contagem esperada de arquivos é estimada em > 600.000 unidades.

-- Editar #1 :

Os IOPs garantidos anunciados do armazenamento são 2000, mas testar o fs remoto resulta em 7-800iops.

As opções de montagem usadas no cliente são as sugeridas pelo provedor:

rsize=8192,wsize=8192,timeo=14,intr

Para realizar a contagem, minha escolha foi este script:

#!/bin/bash
if [[ $# -eq 0 ]] ; then
   echo 'no folder supplied, use $0 /path/to/folder'
   exit 0
else
   COUNT=$(find $1 -type f|wc -l)
   echo $1 contains $COUNT files.
fi
exit 0

Eu tentei em minha casa, e obviamente foi muito rápido, produzindo:

/home/user contains 12 files.

Quando tento obter essa estatística da unidade NFS remota, o script fica "para sempre".

--Editar #2:

Eu tentei remover o |wc -le adicionar >> $LOGFILEno final do find, mas parece que ele trava aleatoriamente em um intervalo de 2 a 24 horas e, quando trava após muito tempo, a lista está longe de ser completa.

Achei que poderia dividir o achado em pedaços, para evitar esse problema, talvez produzindo uma lista de todas as subpastas ...

for d in $FOLDERLIST;
do
   find $d -maxdepth 0 -type f|wc -l >> $TMPLOG
done

..e então some todos os números em $TMPLOG, então talvez em operações menores o script não trave.

PERGUNTA: Estou usando a melhor maneira possível de economizar recursos para realizar essa contagem? Talvez haja uma maneira mais barata do findque obter a contagem de arquivos?

Estou considerando que talvez seja a abordagem errada para contar arquivos, pois vi quanto tempo leva na unidade remota, deve haver uma sobrecarga... Lembro-me de quando tive alguma experiência em sistemas de arquivos remotos montados via curlftpfs. Enorme sobrecarga, enorme atraso.

NFS deveria ser muito melhor sobre isso, mas neste caso não parece!

Cenário: Tenho um cliente executando um Win7 Pro e um cliente OpenVPN; esta estação de trabalho é usada por um de seus funcionários para enviar cmds remotos para o servidor OpenVPN (Windows), ambos usando psexec e smb.

O que aconteceu: tudo correu bem por anos, até que o administrador do sistema atualizou a estação de trabalho para o Windows 10 Pro. Ele confiou no consultor de atualização do Windows e acabou de desinstalar o antivírus antigo que estava marcado como incompatível. Após a atualização, ele - de boa fé - fez os seguintes testes:

-verifique o serviço openvpn no cliente -> runningnning

-ping 10.8.0.1 (ip do servidor) -> OK

Então ele obviamente achava que estava tudo bem.

Como esta estação de trabalho é usada pelo funcionário à noite, na manhã seguinte, fui envolvido pelo administrador de sistema interno, pois o funcionário não conseguiu enviar atualizações. Ele disse que nenhum dos serviços enviou resposta pela vpn, apenas o icmp estava funcionando. Em primeiro lugar, fiz um telnet para as portas que esperava serem alcançáveis ​​e descobri que a conexão instantânea foi recusada. Fiz um ping e encontrei um valor de TTL na resposta de 250!?!? Fiz o seguinte tracert:

C:\>tracert -w 100 10.8.0.1

Traccia instradamento verso 10.8.0.1 su un massimo di 30 punti di passaggio

  1     3 ms     2 ms     2 ms  192.168.0.4
  2     1 ms     2 ms     2 ms  192.168.22.41
  3     1 ms     3 ms     1 ms  10.139.59.130
  4     5 ms     3 ms     3 ms  10.3.132.113
  5    15 ms    13 ms    15 ms  10.254.12.202
  6    15 ms    15 ms    15 ms  10.254.1.245
  7    27 ms    25 ms    23 ms  10.8.0.1

A primeira vez que olhei para isso era inacreditável, mas 0,4 é o GW padrão interno deles, 22,41 é um de seus roteadores e esse roteador está conectado apenas ao ISP.

Correção para o problema do Openvpn: rapidamente descobri que, em relação à atualização do Win10 e ao cliente openvpn, era apenas uma questão de confusão de rotas, e os logs do openvpn confirmaram isso, e a solução (atualização para o último openvpn) corrigiu. Ainda consigo pingar 10.8.0.1 de qualquer outro computador em sua rede que não esteja executando OpenVPN , se a política de roteamento trouxer a conexão neste uplink 22.41. Se eu encaminhar a conexão para qualquer outro de seus 4 (tot. 5) uplinks o problema não acontece. Como este "dizer pirata" 10.8.0.1 responde em todas as portas com rejeições instantâneas e tudo está fechado, acho que pode ser um roteador. Eu só estou querendo saber se o ISP está violando o RFC 1918 ou então como é possível que eu possa pingar um ip do Espaço de Endereços Privados na rede pública!?

--- Editar 2

Pergunta: Como o Cliente sente que esse comportamento inesperado prejudicou seus negócios, ele pode mencionar algum documento como RFC informando que o ISP violou alguma regra de serviço para fornecer serviços de internet?

Sistema: ubuntu fresco e atualizado Xenial Xerus 16.04.2. Começou a partir de um sistema mínimo limpo, onde apenas o openssh foi instalado. Para instalar o backuppc 3.3.2 eu fiz o seguinte:

apt-get install backuppc rsync libfile-rsyncp-perl par2 smbfs

O Apt fez o resto, instalando dependências como apache2 e perl. Se você acha que pode ser importante, editarei a pergunta e colarei as linhas relevantes dos logs do apt.

Depois disso, fiz todas as configurações necessárias para fazer backup do primeiro host, e depois de alguns dias voltei ao laboratório de testes para verificar como estava. Devo dizer que o backuppc é um belo software e fez exatamente - ou até melhor do que - o que eu esperava!

Acabei de notar que os gráficos do pool da tela inicial não eram exibidos; a solução de problemas me retornou apenas uma informação dos logs do apache:

ERROR: opening '/var/lib/backuppc/log/pool.rrd': Permission denied

Definitivamente um problema de permissões: /var/lib/backuppc é de propriedade de backuppc:backuppc enquanto o apache é executado na conta www-data.

A busca do erro no Google retornou essa correção:

Resource | Actual perms | Solution's perms
/var/lib/backuppc | 2750 | 2751
/var/lib/backuppc/log | 750 | 751
/var/lib/backuppc/log/pool.rrd | 640 | 754

Essas alterações de permissões corrigiram o problema e agora os gráficos são exibidos. De qualquer forma, ainda estou preocupado com a segurança do serviço exposto após as alterações de permissão. Neste caso estou planejando uma implementação em um ambiente seguro e isolado, mas e se o cliente pedir para expor o serviço, ou pior se ele mesmo expor? Eu não quero deixar uma brecha de segurança potencial exatamente onde eles irão para recuperação se algo der errado no ambiente de produção.

Outra solução pode ser adicionar o usuário do backuppc ao grupo www-data, mas isso pode ser ainda pior do ponto de vista da segurança.

Outra solução pode ser corrigir o código executado pelo backuppc para lidar com esse problema (e, talvez, algumas linhas no arquivo sudoers), mas não tenho habilidades de programação nem posso ler nada além de scripts bash.

Então, minha pergunta é: Qual é a solução mais segura para obter a exibição de gráficos?