Niels Basjes's questions

Ao tentar configurar um cluster experimental do Kubernetes (em algumas VMs no meu laptop) como "alta disponibilidade", encontrei o conselho de fazer isso usando a combinação de keepalived e haproxy ( https://github.com/kubernetes/kubeadm/blob /master/docs/ha-considerations.md#options-for-software-load-balancing ).

Olhando para as definições de configuração que eu li

${STATE} é MASTER para um e BACKUP para todos os outros hosts, portanto, o IP virtual será inicialmente atribuído ao MASTER.

${PRIORITY} deve ser maior no mestre do que nos backups. Portanto, 101 e 100, respectivamente, serão suficientes.

e essas configurações me surpreendem. Aparentemente, tenho que escolher qual desses sistemas será o mestre inicial e tenho que configurar isso "hard" nos próprios nós.

Para mim, essa configuração de "alta disponibilidade" se desvia da analogia "animal de estimação"/"gado" que encontro no Kubernetes.

Outros sistemas como, por exemplo, o HBase têm uma configuração semelhante (um ativo e vários líderes de espera) e todos são configurados "identicamente" (a seleção é feita via ZooKeeper).

Existe uma maneira de configurar o Keepalived (para uso no Kubernetes) de forma que todos os nós tenham a mesma configuração e ainda funcione corretamente?

Tenho dificuldade em entender um efeito específico na resolução de nomes DNS para nomes de subdomínios que vieram à tona ao habilitar o permite criptografar.

O contexto da minha pergunta:

Eu tenho um domínio (basjes.nl) e defini todos os nomes de host nesse domínio para resolver para o mesmo endereço IP.

Na interface do meu provedor de DNS (Transip), vejo algo assim:

@                      A      x.x.x.x
*                      CNAME  @

Agora posso fazer isso para obter o endereço IP especificado.

dig blurp.basjes.nl

Recentemente, implantei a ferramenta ACME-DNS e configurei as entradas DNS apropriadas (ou seja, delegue auth.basjes.nl ao meu próprio servidor ACME-DNS) para permitir que Lets Encrypt verifique se eu possuo o nome de host especificado via DNS.

Para este nome de host específico, quero ter um certificado HTTPS de 'nome completo' (ou seja, não o curinga), então adicionei algo assim:

_acme-challenge.blurp  CNAME  something.auth.basjes.nl.

Depois de adicionar esta entrada, acho que fazer dig blurp.basjes.nlnão funciona mais. O estranho é que eu não recebo um erro (portanto, não há NXDOMAIN), ou não recebo nada ou apenas

;; AUTHORITY SECTION:
basjes.nl.      300 IN  SOA ns0.transip.net. hostmaster.transip.nl. 2018041107 14400 1800 2419200 300

Então neste momento eu tenho algo assim:

@                      A      x.x.x.x
*                      CNAME  @
_acme-challenge.blurp  CNAME  something.auth.basjes.nl.

Descobri que, se eu adicionar um registro DNS explícito para este nome de host, de repente ele funcionará novamente:

@                      A      x.x.x.x
*                      CNAME  @
blurp                  CNAME  @
_acme-challenge.blurp  CNAME  something.auth.basjes.nl.

Os efeitos que eu gostaria de entender:

• Por que não resolve mais ao perguntar a um servidor DNS normal?

  O registro '*' ainda está presente!

  dig blurp.basjes.nl @1.1.1.1

• Por que resolve ao perguntar diretamente ao servidor DNS SOA da Transip?

  dig blurp.basjes.nl @ns0.transip.net

• Por que resolve ao adicionar o registro explícito?

  Isso é o que eu uso atualmente como uma solução alternativa para fazê-lo funcionar para mim.

PS Entrei em contato com o suporte da Transip antes de postar esta pergunta. Eles não sabiam o que deu errado aqui e/ou por que isso acontece.

Eu tenho uma VM CentOS 7.0 com um volume montado em um servidor de arquivos Windows 2012-R2. O volume contém alguns arquivos grandes relacionados a um site interno do Wordpress.

Cerca de uma semana atrás, o site ficou 'quebrado' e o que descobri é que no Linux os arquivos ficam assim:

A ferramenta readlink no Linux mostra as mesmas letras 'chinesas' mostradas na captura de tela.

No Windows, os mesmos arquivos se parecem com isso:

Conversei com o administrador do sistema do servidor Windows e ele me disse que ativaram a desduplicação de arquivos no servidor Windows há cerca de uma semana.

Observar as propriedades em um desses arquivos revela que o 'tamanho no disco' é realmente pequeno, além disso, os arquivos de 'problema' têm o atributo 'L' que parece suportar o relacionamento com a desduplicação.

A maneira como vejo isso atualmente é que o que aparentemente é algum tipo de 'hardlink' no servidor Windows é interpretado como um softlink pelo meu sistema CentOS.

Tenho experimentado algumas configurações de montagem, mas não consegui corrigir esse problema (além de desativar a desduplicação).

Minha configuração atual (cliente):

• CentOS 7.0
• samba-client-4.1.1-38.el7_0.x86_64
• samba-comum-4.1.1-38.el7_0.x86_64
• samba-libs-4.1.1-38.el7_0.x86_64
• cifs-utils-6.2-7.el7.x86_64

O comando no meu /etc/fstab

\\xxxxxxxx\file\video /var/www/html/wp-content/uploads cifs nouser_xattr,nounix,iocharset=utf8,credentials=/etc/fstab.cifs.sa_video.credentials,_netdev,uid=apache,gid=apache,rw,auto 0 0

Como faço para que o Linux veja esses arquivos como arquivos novamente?

Atualização 2015-06-15:

Atualizei o sistema para o CentOS 7.1. Embora ainda execute o Kernel "3.10" (para ser exato: 3.10.0-229.4.2.el7.x86_64), esse problema não ocorre mais. Portanto, a solução é realmente 'simplesmente atualizar' para o CentOS 7.1.