Garreth McDaid's questions

Eu tenho um problema no Nginx com segurança e X-Accel-Redirect.

Servidor Nginx 777

location /api {
   allow 100.100.100.1;
   deny all;
   proxy_pass http://api-server;
}

#The api-sever will respond with an `X-Accel-Redirect` header to the following location `@server888`

location @server888 {
   internal;
   proxy_pass http://server888$request_uri;
}

Nginx Server 888 tem configuração idêntica para/api

location /api {
   allow 100.100.100.1;
   deny all;
   proxy_pass http://api-server;
}

No entanto, todas as solicitações do ip de origem 100.100.100.1para o servidor 777 estão obtendo uma resposta 403 do servidor 777 , com o erro:

access forbidden by rule while reading response header from upstream

Pelo que vejo, o @server888local está bloqueando a solicitação, mas meu entendimento é que a internaldiretiva deve permitir solicitações originadas de X-Accel-Redirect, sem precisar fornecer uma allowdiretiva explícita para 100.100.100.1.

Isso está correto? Ou preciso conceder permissões mais extensas no @server888local para que isso funcione?

Estou tentando criar uma réplica hot-standby para um mestre do PostgreSQL 9.5.

O processo básico que usei é iniciar um backup no mestre:

SELECT pg_start_backup('label', true)

No escravo, eu executo, pg_basebackup:

pg_basebackup -h <master ip> -D /data/pgsql/9.5/data -U replicator -v -P  --xlog-method=stream

Depois que isso for concluído, executo o comando para interromper o backup no mestre:

SELECT pg_stop_backup()

Neste ponto, obtive o seguinte no STDOUT:

NOTICE:  pg_stop_backup cleanup done, waiting for required WAL segments to be archived
WARNING:  pg_stop_backup still waiting for all required WAL segments to be archived (60 seconds elapsed)
HINT:  Check that your archive_command is executing properly.  pg_stop_backup can be canceled safely, but the database backup will not be usable without all the WAL segments.

Isso continua e não sai.

O comando archive no mestre é definido como:

rsync -a %p <replica ip>:/data/wal-archive/%f

Inicialmente, isso não estava funcionando, pois a chave do servidor precisava ser aceita. Depois de fazer isso manualmente, o rsync foi iniciado e posso ver um grande acúmulo de arquivos (~ 15 GB até agora) em /data/wal-archive.

Este é um banco de dados de 20 TB, então eu realmente não quero ter que iniciar esse processo novamente estragando algo.

É seguro sair do terminal emitindo os AVISOS? Eu li em outros posts que o archive_mode só precisa estar ativado durante o processo de streaming dos DBs para a réplica para fins de configuração da réplica e, além disso, não é necessário.

Nesse caso, posso apenas fazer um CTRL-C no terminal e prosseguir com a configuração da réplica?

Posso então desligar o archive_mode no master?

Estou tentando centralizar o log em um ambiente que usa várias tecnologias de aplicativos (Java, Rails e vários bancos de dados).

Queremos que os desenvolvedores criem pilhas com o Docker Compose, mas queremos que eles se refiram a uma fonte de log central (ELK) para depurar problemas, em vez de tentar abrir shells em contêineres do Docker em execução.

Todos os aplicativos gravam no sistema de arquivos em vez de STDOUT/STDERR, o que remove todas as opções associadas ao driver de registro do Docker e logspout também.

O que fizemos foi configurar os contêineres para que o rsyslog inclua os arquivos de log do aplicativo e os encaminhe para logstash, que possui uma entrada syslog. Isso funciona em termos de mover os logs de A para B, mas gerenciar logs de multitecnologia em ELK com base na entrada do syslog é horrível (por exemplo, tentar capturar vários rastreamentos de pilha Java ou consultas lentas do MySQL).

Existe uma maneira melhor de fazer isso? Devo executar o logstash em cada contêiner, para poder aplicar filtros e codecs diretamente aos arquivos de log, para não precisar depender da entrada do syslog?

Existe alguma maneira de usar o driver de log do Docker com arquivos de log do aplicativo que são gravados no sistema de arquivos?

A documentação do logstash indica que você pode recolher as várias linhas recuadas em uma entrada de log de rastreamento de pilha Java em um único evento usando o codec multilinha:

https://www.elastic.co/guide/en/logstash/current/plugins-codecs-multiline.html

input {
   syslog {
       type => syslog
       port => 8514
       codec => multiline {
            pattern => "^\s"
            what => "previous"
       }
  }
}

Isso se baseia em logstash encontrar um recuo no início da linha e combiná-lo com a linha anterior.

No entanto, a documentação do logstash é o único lugar onde posso encontrar uma referência a isso. A comunidade geral de usuários parece estar usando elaborados filtros grok para obter o mesmo efeito.

Eu tentei o padrão de indentação básico fornecido pelo logstash, mas não funcionou. Alguém mais conseguiu fazer isso funcionar combinando o padrão de indentação?

O Boto tem uma função, update_environment, que permite ao usuário atualizar opções em um ambiente AWS ElasticBeanstalk.

Usando a AWS CLI, isso normalmente seria acionado da seguinte forma:

aws elasticbeanstalk update-environment --environment-name my-env --option-settings Namespace=aws:autoscaling:asg,OptionName=MinSize,Value=1

No Boto, update_environment usa um parâmetro List para option_settings, conforme descrito aqui:

http://boto.readthedocs.org/en/latest/ref/beanstalk.html

update_environment(environment_id=None, environment_name=None, version_label=None, template_name=None, description=None, option_settings=None, options_to_remove=None, tier_name=None, tier_type=None, tier_version='1.0')

Eu tentei vários métodos de passar a string

Namespace=aws:autoscaling:asg,OptionName=MinSize,Value=1

como uma lista, mas nenhum parece funcionar. A API continua me dizendo:

Invalid option specification 

Alguém sabe qual é o formato correto para a lista?

No momento, estou migrando uma zona DNS de um provedor de servidor DNS para outro. Estou tentando estimar quanto tempo levará para a alteração se propagar e entender qual pode ser o atraso se eu optar por reverter no meio do fluxo.

Anteriormente, pensei que poderia fazer:

dig example.com ns

Para ver qual era o TTL restante no registro NS, mas agora entendo que esse registro NS é o registro NS para subdomínios na zona, e não o registro NS que emana dos servidores raiz, que é o que determina em última instância qual servidor de nomes a consulta será enviada.

Eu testei isso configurando um registro de teste na zona em cada um dos provedores:

Provider1 test.example.com 10.0.0.1
Provider2 test.example.com 192.168.0.1

Para ambos os provedores, o TTL nos registros NS em 0, enquanto os registros NS no nível TLD Registrar apontam para os servidores de nomes do Provider1.

Quando altero os registros NS na zona em Provider1, posso ver isso refletido nas consultas NS quase imediatamente (usando 'dig example.com ns').

No entanto, quando envio uma consulta para um registro A, ou seja,

test.example.com

sempre volta

10.0.0.1

independentemente de como os registros NS na zona do Provedor 1 estão configurados.

Com base nisso, concluí que os registros NS dentro do arquivo de zona são irrelevantes para a migração e que apenas os registros dos servidores de nomes no nível TLD são importantes.

No entanto, não consigo ler quanto tempo é provável que uma alteração ali se propague, seja para frente ou para trás.

É possível consultar com que TTL estou trabalhando para registros provenientes dos servidores raiz do TLD?

Estou executando um servidor OpenSwan para facilitar as conexões cliente-servidor em um centro de dados seguro.

Tenho um problema com o cliente padrão L2TP sobre IPSEC no MacOS, especificamente ao usar WIFI.

Quando eu conecto pela primeira vez, funciona bem. Quando desligo e tento conectar novamente, falha na etapa de autenticação (segredo compartilhado).

Pelo que posso ver, quando o MAC está usando WIFI, não há tempo para enviar um sinal DELETE para o OpenSwan, portanto, no que diz respeito ao OpenSwan, o par ainda existe. Eu posso ver isso nos logs do OpenSwan:

Jun  8 12:23:43 vpn1 pluto[20030]: ERROR: asynchronous network error report on eth0 (sport=500) for message to 213.242.106.82 port 500, complainant 213.242.106.82: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]

Esta mensagem continua aparecendo nos logs do OpenSwan muito depois de eu ter desconectado o cliente Mac. Quando reinicio o serviço ipsec no servidor, a entrada de log desaparece e posso me conectar novamente.

Incluí detecção de ponto morto em minha configuração do OpenSwan:

 dpddelay=30
 dpdtimeout=120
 dpdaction=clear

Eu posso ver que Dead Peer Detection está habilitado quando eu inicio a conexão:

Jun  8 12:45:34 vpn1 pluto[11064]: "vpnpsk"[14] 213.242.106.82 #14: STATE_QUICK_R2: IPsec SA established transport mode {ESP/NAT=>0x0188ccda <0x7fe9af15 xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=213.242.106.82:4500 DPD=enabled}

No entanto, quando fecho a conexão no MAC, o DPD não parece entrar em ação. O OpenSwan apenas registra erros sobre a conexão.

Apenas procurando sugestões re. um conserto.

O documento de agrupamento do RabbitMQ

https://www.rabbitmq.com/clustering.html

descreve um processo pelo qual você pode implantar um arquivo de configuração para clustering para que um cluster seja criado automaticamente quando seus nós rabbitmq inicializarem.

[{rabbit,
  [{cluster_nodes, {['rabbit@rabbit1', 'rabbit@rabbit2', 'rabbit@rabbit3'], ram}}]}].

Você aplica esse arquivo em cada um dos 3 nós em /etc/rabbitmq/rabbitmq.config e, em seguida, inicia o rabbitmq em cada um e um cluster aparentemente se formará.

Isso não parece funcionar muito bem, por exemplo

Se você iniciar o rabbit2 e o rabbit3 ainda não tiver surgido, o serviço não será iniciado no rabbit2, pois está tentando criar um cluster com o rabbit3.

Da mesma forma, se você aplicar a configuração apenas no rabbit1 e pré-iniciar o rabbit2 e o rabbit3, o rabbit1 formará um cluster apenas com o rabbit2, pois, de acordo com a documentação (não entendo o porquê):

RabbitMQ will try to cluster to each node provided, and stop after it can cluster with one of them.

A única maneira de isso funcionar é se você aplicar o arquivo de configuração em todos os 3 nós e iniciá-los exatamente ao mesmo tempo. Estou tentando implantar isso com o Ansible, que cria os nós sequencialmente, para que não funcione.

O que estou perdendo aqui?

Estou com um problema de roteamento.

Eu tenho 2 sub-redes públicas: 172.31.1.0/24 e 172.31.100.0/24

Em cada um deles, tenho uma instância NAT. Cada instância NAT é um peer OpenSwan VPN para um local remoto. Isso permite a seguinte conectividade VPN:

172.31.1.0/24 -> 192.168.1.0/24
172.31.100.0/24 -> 192.168.100.0/24

Eu configurei uma única tabela de rotas associada a ambas as minhas sub-redes públicas. isso inclui entradas de rota como segue:

192.168.1.0/24 Target = NAT instance 1
192.168.100.0/24 Target = NAT instance 2

Tudo funciona bem para o primeiro, mas não importa o que eu faça, a entrada da tabela de rotas para o último não funciona.

Nenhuma rota que configurei para NAT Instance 2 funciona. Quando eu traceroute para qualquer endereço em 192.168.100.0/24, os pacotes são enviados diretamente para 192.168.100.0/24 (e, portanto, falham) em vez de rotear via NAT Instance 2.

Eu pensei que talvez houvesse um limite para o número de instâncias NAT simultâneas em uma Tabela de Rotas, mas mesmo quando eu excluo a rota para 192.168.1.0, de modo que a única rota que existe é a rota via instância NAT 2, ainda não t trabalho.

Eu verifiquei todas as coisas usuais (verificação Src/Dst, etc.), mas nada parece estar fora do lugar. Tudo isso foi criado com o CloudFormation, portanto, não é provável que ocorra um erro manual.

Eu tenho um servidor (Amazon Linux) que está ativo há 261 dias:

[server]$ uptime
 16:29:46 up 261 days,  4:47,  1 user,  load average: 0.05, 0.16, 0.18

Estou tentando descobrir se houve alguma tentativa de login malsucedida nos últimos meses:

[server]$ lastb

btmp begins Thu Jan  1 04:16:08 2015

Não há nada lá, e o servidor está me dizendo que o arquivo /var/log/btmp começou há 14 dias.

Há um outro arquivo de log btmp arquivado em /var/log/

-rw------- 1 root utmp 75 Jan  1 04:16 /var/log/btmp-20150101.gz

Quando eu descompacto isso e leio com lastb, recebo isto:

[server]$ lastb -f btmp-20150101 

btmp-20150101 begins Wed Jan 14 16:21:06 2015

Alguém pode me dizer o que está acontecendo aqui? Meu objetivo é provar que não houve tentativas de login inválidas nos 261 dias em que o servidor esteve ativo, mas o lastb não parece ser capaz de confirmar isso.