Início / user-287984

giomanda's questions

Martin Hope
giomanda
Asked: 2017-12-09 03:34:44 +0800 CST
  • 6

Eu tive um problema hoje em que minha implantação em meus servidores de aplicativos não pôde ser concluída devido a problemas de conexão com o github.

Percebi que, quando executo uma pesquisa de DNS do github.com usando os servidores DNS do google, recebo os endereços IP "corretos/antigos" que também são documentados oficialmente pelo guthub AQUI .

root@server# host github.com 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

github.com has address 192.30.253.112
github.com has address 192.30.253.113
github.com mail is handled by 10 ALT4.ASPMX.L.GOOGLE.com.
github.com mail is handled by 10 ALT3.ASPMX.L.GOOGLE.com.
github.com mail is handled by 5 ALT1.ASPMX.L.GOOGLE.com.
github.com mail is handled by 1 ASPMX.L.GOOGLE.com.
github.com mail is handled by 5 ALT2.ASPMX.L.GOOGLE.com.

No entanto, quando uso os servidores DNS do meu provedor de hospedagem, recebo resultados diferentes:

root@server# host github.com 213.133.98.98
Using domain server:
Name: 213.133.98.98
Address: 213.133.98.98#53
Aliases: 

github.com has address 18.195.85.27
github.com has address 35.159.8.160
github.com has address 18.194.104.89
github.com mail is handled by 1 ASPMX.L.GOOGLE.com.
github.com mail is handled by 10 ALT4.ASPMX.L.GOOGLE.com.
github.com mail is handled by 10 ALT3.ASPMX.L.GOOGLE.com.
github.com mail is handled by 5 ALT1.ASPMX.L.GOOGLE.com.
github.com mail is handled by 5 ALT2.ASPMX.L.GOOGLE.com.

Quando entrei em contato com meu provedor para saber por que eles estão servindo esses resultados, eles afirmaram que os registros do githubs foram alterados. De fato, isso parece estar correto, pois quando executo um rastreamento de registros dns do githubs usando novamente o servidor dns do google, recebo os "novos" registros:

root@server# dig github.com +trace @8.8.8.8
...    
text omitted
...
github.com.     172800  IN  NS  ns-520.awsdns-01.net.
github.com.     172800  IN  NS  ns-421.awsdns-52.com.
github.com.     172800  IN  NS  ns-1707.awsdns-21.co.uk.
github.com.     172800  IN  NS  ns-1283.awsdns-32.org.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20171215054800 20171208043800 11324 com. mBRl9D0i8jmeYbtZzR527TfVtbq2x6RSECv23chq0usVGZzVCQz5BYbV JaWeaQ1QWRuTWz3snYFkQBaG7SLQbipDEaVaMgjQ9qnHitJxwzEYPTn0 mT5nweDT+IVqP3NpppB748HAr9IiqqNOar1IyQokv3S59E9cK+s1W3V0 Mik=
4KB3QDAGSO6KO9JK2O5F2FO8F4C5FTA2.com. 86400 IN NSEC3 1 1 0 - 4KB4PTQQ5CTA7POCTGM7RUFC8B1RKTEU NS DS RRSIG
4KB3QDAGSO6KO9JK2O5F2FO8F4C5FTA2.com. 86400 IN RRSIG NSEC3 8 2 86400 20171212052031 20171205041031 11324 com. DmETcOQrFR+iFYhCH4xGJT+khPaTF4Ay50o+FrdpBvRTOPT9WTFf1wOF Ew3cQlBGHdwS2TiT+tLsUlshkmiKZpdH753Lac9Z0ZBU6fcB/PWOwMQX NGPWwYZFrGb8I2QsEvQreBM+WcftfdHGXHn5ziUx8phz1lbJuQXhVYyl LBk=
;; Received 840 bytes from 192.43.172.30#53(i.gtld-servers.net) in 17 ms

github.com.     60  IN  A   18.195.85.27
github.com.     60  IN  A   18.194.104.89
github.com.     60  IN  A   35.159.8.160
github.com.     900 IN  NS  ns-1283.awsdns-32.org.
github.com.     900 IN  NS  ns-1707.awsdns-21.co.uk.
github.com.     900 IN  NS  ns-421.awsdns-52.com.
github.com.     900 IN  NS  ns-520.awsdns-01.net.
github.com.     900 IN  NS  ns1.p16.dynect.net.
github.com.     900 IN  NS  ns2.p16.dynect.net.
github.com.     900 IN  NS  ns3.p16.dynect.net.
github.com.     900 IN  NS  ns4.p16.dynect.net.
;; Received 307 bytes from 205.251.198.171#53(ns-1707.awsdns-21.co.uk) in 12 ms

Por que quando estou queering para o github.com usando o DNS do google, ele retorna "ips antigos", mas quando eu uso um rastreamento de DNS, ele retorna os novos? O google dns retornou registros em cache (mesmo um dia depois)?

Por outro lado, o github mudaria seus endereços IP sem notificar ninguém? A documentação deles não menciona esses "novos" endereços de ip e pelo que pesquisei, sempre que eles faziam essa alteração, eles também postavam em seu blog.

domain-name-system
Martin Hope
giomanda
Asked: 2017-10-13 03:08:08 +0800 CST
  • 0

Estou tentando definir logs criptografados com td-agent entre duas máquinas. Eu segui os exemplos da documentação oficial do fluentd, mas estou preso em uma situação muito estranha. O cliente e o servidor se recusam a negociar devido à incompatibilidade de shared_key.

A frase-chave está correta em ambos os servidores, no entanto, tanto o cliente quanto o servidor afirmam que as chaves não correspondem.

Aqui está a configuração do cliente (texto omitido):

<match uwsgi.**>
 type copy
<store>
    type secure_forward
    shared_key hello  
    send_timeout 30s
    self_hostname client.example.net

    <server>

            name server.example.net
            host server.example.net
            port 24225
    </server>
</store> 
</match>

E aqui está a configuração do servidor:

<source>
  type secure_forward
  shared_key    hello
  self_hostname server.example.net
  bind 0.0.0.0
  port 24225
  secure true
  ca_cert_path /etc/td-agent/mycert.crt
  ca_private_key_path /etc/td-agent/mykey.key
  ca_private_key_passphrase ""

Eu continuo recebendo essas mensagens de erro do servidor:

Shared key mismatch from 'client.example.net'

O mesmo do cliente:

[warn]: dead connection found: server.example.net, reconnecting...  
[warn]: connection refused to server.example.net:authentication failed: shared_key mismatch

Alguma ideia?

fluentd
Martin Hope
giomanda
Asked: 2017-08-13 15:43:26 +0800 CST
  • 2

Ontem fomos atingidos por um ataque DDoS atingindo nossos servidores web (apache2). O frontend consiste em conexões de balanceamento de carga haproxy para os servidores web. No access.log do apache vimos milhares de pedidos de dois ips e depois de algumas horas percebemos que eram falsos/falsificados e não eram os ips reais.

Por motivos de esclarecimento, fizemos um "curl GET /" com um ip de "137.137.136.136" e de fato esse é o ip (fake one) que vimos em nossos weblogs

Agora, em outro cluster onde usamos nginx como proxy reverso, alterar/criar o cabeçalho X-Forwarded-For não funciona. Ou seja, mesmo se você inserir um ip aleatório no cabeçalho específico, o nginx ainda passará o ip correto para o servidor web de back-end?

Isso tem a ver com haproxy?
Alguém pode confirmar que os cabeçalhos X-Forwarded-For criados podem passar pelo haproxy?
Por que isso não está acontecendo no nginx?
Como você evita isso?

nginx
Martin Hope
giomanda
Asked: 2017-05-24 14:16:05 +0800 CST
  • 1

Eu tenho três domínios de três registradores diferentes (por exemplo, example.com , example.net , example.org ). Os registros DNS para cada domínio são tratados separadamente usando o painel de controle de cada registrador. Desejo centralizar todas as zonas para um único serviço, alterando todos os Glue Records para apontar para um único servidor DNS, digamos ns1.example.net.

O procedimento que finalizo é:

  1. Crie cada zona no novo servidor.
  2. "Copiar" todos os registros ( A, AAAA, MXetc) dos registradores para a zona equivalente.
  3. Altere os registros de cola em todos os domínios para apontar para o novo servidorns1.example.net

No entanto, estou preocupado com o seguinte:

  1. Quaisquer consultas de registro em cache Ade clientes ou resolvedores não devem ser um problema, pois os registros do meu servidor NS apontarão para os mesmos IPs, assim como os registros originais. Isso é correto?

  2. E as NSconsultas de registro? Os clientes ou servidores DNS recursivos armazenam em cache NSas consultas de registro? Se este for o caso, então, existe a possibilidade, assim que eu alterar o registro de cola, os clientes tentarem consultar o servidor DNS antigo (registrador).

Em relação ao nº 2, a meu ver, se o registrador parar de responder às consultas de DNS assim que eu delegar a zona a outro servidor... então estou desamparado. Os registradores previram tais situações e continuam atendendo as consultas, digamos por mais 24 horas, a partir do momento em que você altera os registros da cola?

domain-name-system
Martin Hope
giomanda
Asked: 2017-03-29 02:30:08 +0800 CST
  • 65

Eu instalei o pimdserviço por meio de apt. systemdIsso vem com um arquivo de unidade upstream ( /lib/systemd/system/pimd.service).

Desejo que o serviço seja reiniciado quando, por algum motivo, for interrompido, portanto, desejo adicionar a linha Restart = alwaysno arquivo da unidade.

No entanto, não quero modificar o arquivo de unidade upstream.

Existe alguma solução alternativa para isso?

systemd
Martin Hope
giomanda
Asked: 2017-03-23 02:43:30 +0800 CST
  • 1

Eu instalei o mrd6 (daemon de roteamento Multicast) que vem com um script de inicialização. Decidi criar uma unidade de serviço systemd para gerenciar o serviço relevante. O arquivo de unidade que criei é o descrito abaixo:

[Unit]
Description=Multicast routing daemon
Wants=network-online.target
After=network-online.target

[Service]
ExecStart=/usr/sbin/mrd6 -D
PIDFile=/run/mrd6.pid
Type=simple
Restart=always
User=root

No entanto, quando inicio o serviço usando o systemd, obtenho o status Active (exited), o que significa que o systemd executou os comandos especificados no arquivo de unidade, mas não sabe se o processo está realmente em execução. A verificação dos processos em execução não indica que o serviço foi iniciado.

root@debsrv:/etc/systemd/system# systemctl status mrd6.service 
● mrd6.service - Multicast routing daemon
   Loaded: loaded (/etc/systemd/system/mrd6.service; static)
   Active: active (exited) since ....

Como posso fazer o systemd lidar adequadamente com esse serviço e ser capaz de reconhecer que o processo está em execução?

systemd
Martin Hope
giomanda
Asked: 2017-01-31 01:11:27 +0800 CST
  • 7

Eu tenho um grupo de volume (vg) com cerca de 127 GB de espaço livre. Estou tentando estender um volume lógico para +50 GB, mas estou obtendo

extensões alocáveis ​​adequadas insuficientes

Isso é bastante estranho, pois há espaço suficiente no VG para alocar. Abaixo você pode encontrar informações sobre a configuração do meu LV:

root@server:~# df -h
Filesystem                        Size  Used Avail Use% Mounted on
/dev/dm-0                          19G  4.3G   15G  23% /
udev                               10M     0   10M   0% /dev
tmpfs                              19G  341M   19G   2% /run
tmpfs                              48G     0   48G   0% /dev/shm
tmpfs                             5.0M     0  5.0M   0% /run/lock
tmpfs                              48G     0   48G   0% /sys/fs/cgroup
/dev/mapper/data-lvm1   158G  135G   24G  86% /srv/mongodb/lvm1
/dev/mapper/data-lvm2  543G  509G   35G  94% /srv/mongodb/lvm2

root@server:~# lvs
  LV             VG    Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lvm1  data  -wi-ao---- 160.00g                                                    
  lvm2  data  -wi-ao---- 551.00g                                                    
  root  local -wi-ao----  19.31g                                                    
  swap  local -wi-ao----  11.18g                                                    

root@server:~# vgs
  VG    #PV #LV #SN Attr   VSize   VFree  
  data    2   2   0 wz--l- 838.24g 127.24g
  local   1   2   0 wz--n- 136.70g 106.21g

root@server:~# pvs
  PV         VG    Fmt  Attr PSize   PFree  
  /dev/sda1  local lvm2 a--  136.70g 106.21g
  /dev/sdb   data  lvm2 a--  279.36g 119.36g
  /dev/sdc   data  lvm2 a--  558.88g   7.88g

root@server:~# lvextend -L +50G /dev/data/lvm2 
  Insufficient suitable allocatable extents for logical volume lvm2: 10783 more required

root@server:~# vgscan 
  Reading all physical volumes.  This may take a while...
  Found volume group "data" using metadata type lvm2
  Found volume group "local" using metadata type lvm2

root@server:~# pvscan 
  PV /dev/sdb    VG data    lvm2 [279.36 GiB / 119.36 GiB free]
  PV /dev/sdc    VG data    lvm2 [558.88 GiB / 7.88 GiB free]
  PV /dev/sda1   VG local   lvm2 [136.70 GiB / 106.21 GiB free]
  Total: 3 [974.94 GiB] / in use: 3 [974.94 GiB] / in no VG: 0 [0   ]

root@server:~# lvscan 
  ACTIVE            '/dev/data/lvm1' [160.00 GiB] inherit
  ACTIVE            '/dev/data/lvm2' [551.00 GiB] inherit
  ACTIVE            '/dev/local/root' [19.31 GiB] inherit
  ACTIVE            '/dev/local/swap' [11.18 GiB] inherit
lvm
Martin Hope
giomanda
Asked: 2016-01-27 03:33:59 +0800 CST
  • 0

Eu tenho serverA que atua como um proxy reverso para serverB. O que desejo realizar é porxypass uma conexão https do servidorA para o servidorB. Em outras palavras:

---https-->(serverA)---proxypass-https--->(serverB)

ServerA executa apache2 e ServerB executa nginx.
Isso é possível?

apache-2.2
Martin Hope
giomanda
Asked: 2015-11-19 01:28:44 +0800 CST
  • 0

Estou batendo cabeça nos últimos dois dias sobre este. Eu configurei um cluster elasticsearch de dois nós. A configuração de cada nó é bem simples:

node.name: "server1"
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: 192.168.1.212,192.168.1.213
index.store.compress.stored: True
index.store.compress.tv: True
index.number_of_shards: 5
compress.default.type: lzf
cluster.name: mycluster
discovery.zen.minimum_master_nodes: 1
discovery.zen.ping.timeout: 60
index.number_of_replicas: 1

Os nós do cluster "vêem" uns aos outros e os shards esperados são gerados, mas não as réplicas. Quando uso o plug-in "head" (interface da web para elasticsearch), não consigo ver apenas fragmentos primários e não réplicas. Isso também é confirmado pelo status de elasticsearch:

 curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'
 {
  "cluster_name" : "server1",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 2,
  "number_of_data_nodes" : 2,
  "active_primary_shards" : 10,
  "active_shards" : 10,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0
}

Outra coisa que notei nas configurações em execução do elasticsearch é que as réplicas são definidas como 0:

curl -XGET 'http://localhost:9200/_settings?pretty=true'
{
  "date" : {
    "settings" : {
      "index" : {
        "refresh_interval" : "1s",
        "number_of_shards" : "5",
        "creation_date" : "1447756143035",
        "store" : {
          "type" : "fs"
        },
        "uuid" : "mpVS_BB9R0WvoF0h8pFVfQ",
        "version" : {
          "created" : "1040299"
        },
        "number_of_replicas" : "0"
      }
    }
  },
  "scores" : {
    "settings" : {
      "index" : {
        "refresh_interval" : "1s",
        "number_of_shards" : "5",
        "creation_date" : "1447756144186",
        "store" : {
          "type" : "fs"
        },
        "uuid" : "KUlfG4UhQfmMP1L3xQiJOQ",
        "version" : {
          "created" : "1040299"
        },
        "number_of_replicas" : "0"
      }
    }
  }
}

Alguma ideia de por que nenhuma réplica é criada?

replication
Martin Hope
giomanda
Asked: 2015-06-25 00:55:12 +0800 CST
  • 0

Eu corro um servidor com Debian 7 (Wheezy) e uma nova instalação do tomcat7.

Quando tento iniciar o serviço tomcat a partir do init.d ou processando o comando de serviço, recebo o erro abaixo:

[FAIL] Starting Tomcat servlet engine: tomcat7 failed!

O que me deixa louco é que o log (catalina.out) está completamente vazio, portanto, não posso realmente solucionar isso.

Alguma ideia?

tomcat7