hookenz's questions

Esta é a primeira vez em muitos anos que uso o Windows Server. Fui incentivado a configurar o Windows Server 2016 e presumi que ele tivesse uma GUI.

Para minha surpresa, esta versão não tem experiência em desktop. Eu acredito que é chamado de "Core".

Tenho o sistema operacional instalado em um SSD e 2 discos rígidos de 12 TB conectados que desejo disponibilizar como um único disco virtual.

Como faço isso com o PowerShell? Cheguei a criar um Pool que chamei de "StoragePool1" que usa os dois discos. Mas agora estou preso na etapa do VirtualDisk. Ocorreu um erro quando executei um comando New-VirtualDisk regular com um tamanho de 21 TB

O Nginx possui este módulo útil chamado ngx_http_limit_req_module onde você pode limitar as solicitações ao servidor com base no IP ou no número de solicitações.

É possível limitar a taxa do local que inclui o cabeçalho personalizado? por exemplo, eu tentei isso, mas não consegue iniciar o nginx.

location /myservice {
    if ($http_x_custom_header) {
      limit_req zone=one burst=5;
    }
}

O erro específico é:

nginx: [emerg] a diretiva "limit_req" não é permitida aqui em /etc/nginx/sites-enabled/default

ou seja, não gosta da diretiva limi_req dentro do ifbloco. Está tudo bem fora do bloco if.

No entanto, posso viver com um conjunto diferente de parâmetros de limite fora do local.

Estou querendo definir corretamente o X-Real-IP para domínios com proxy por nginx que também ficam atrás de um Amazon ELB.

ou seja

AMAZON ELB <=> NGINX PROXY <=> REST APP1
                           <=> REST APP2

Até agora, descobri que o seguinte funciona corretamente e evita a falsificação do IP. Eu tenho isso definido globalmente em nginx.conf

real_ip_header X-Forwarded-For;
set_real_ip_from 10.0.0.0/8;
real_ip_recursive on;

No entanto, também tenho alguns aplicativos REST que ficam atrás do NGINX

Meus aplicativos de descanso usarão o x-real-ip se definido ou x-forwarded-for. Em uso normal, o IP real do cliente está correto.

Sob um ataque de IP falsificado em que um ou ambos os cabeçalhos x-real-ip e x-forwarded-for são definidos, vejo o IP falsificado no cliente REST. No entanto, o nginx mostra o IP do cliente correto.

Atualmente no host de domínio que defini

proxy_pass_request_headers ativado;

Como definir o x-real-ip para ser o IP confiável real para os aplicativos REST?

Presumo que preciso de uma proxy_set_headerlinha com o X-Real-IP. Mas como faço referência ao que o cabeçalho real-ip é definido pelo módulo real-ip?

O Nginx tem um bom recurso que permite restringir o acesso aos recursos por endereço IP de origem.

No entanto, notei que pode não funcionar em situações em que o nginx está por trás de um proxy ou balanceador de carga. No meu caso, o Amazon ELB.

Desejo fornecer uma página de status para o agente datadog e as verificações de integridade do Amazon ELB. Portanto, quero permitir conexões locais e do ELB, mas negar todo o resto.

O seguinte não funciona como esperado, pois permite que o tráfego originado fora do ELB também acesse a página de status. A razão é porque o IP parecerá originário do ELB e as regras de permissão não examinam os cabeçalhos para determinar a origem real da solicitação. Existe uma maneira de dizer ao nginx qual IP de origem usar para determinar as regras de permissão/negação?

location /status {
    stub_status;
    access_log off;
    allow 127.0.0.1;
    allow 10.0.0.0/16;
    deny all;
}

Comecei a aprender e usar o ansible para configurar meus servidores de teste e produção. Uma coisa que gostaria de fazer é configurar /etc/hosts por meio do arquivo de inventário.

Parece que isso é possível. Aqui está um desses usos: https://gist.github.com/rothgar/8793800

No entanto, sou um pouco verde para o Ansible e não entendo. Alguém pode explicar em inglês simples como faço isso funcionar na prática?

Por exemplo, se meu arquivo de inventário contiver.

[compute]
1.2.3.4 
5.6.7.8

[db]
2.3.4.5
6.7.8.9
10.11.12.13

[all]
compute
db

[all:vars]
...

Eu gostaria de dizer com consistência que meu arquivo hosts após executar o playbook contido

2.3.4.5 db1
6.7.8.9 db2
10.11.12.13 db3
1.2.3.4 compute1
5.6.7.8 compute2

Isso é possível?

Eu tenho um script de notificação iniciado pelo processo daemon keepalived sempre que seu estado muda.

O problema é que a saída de eco do meu script de notificação não aparece na saída exibida ao executar keepalived com a opção -l (registrar no console local)

Normalmente, eu poderia gravar essa saída em um arquivo e isso seria uma boa solução, exceto que, neste caso, o daemon keepalived está sendo executado em um contêiner docker e eu quero que o daemon docker veja o log de todas as saídas, incluindo as da minha notificação roteiro.

Isto é o que eu tentei para o meu script de notificação:

#!/bin/bash

MY_PPID=$(ps -o ppid= $$)
MY_PPID=${MY_PPID// }

function echo
{
  builtin echo $(date +"%b %e %H:%M:%S"): $1 >> /proc/${MY_PPID}/fd/0
}

echo "Notify state=$3"

E a saída do keepalived:

Starting VRRP child process, pid=8847
Interface queue is empty
No such interface, ib0
No such interface, ib1
No such interface, docker0
Interface queue is empty
No such interface, ib0
Registering Kernel netlink reflector
No such interface, ib1
No such interface, docker0
Registering Kernel netlink command channel
Registering gratuitous ARP shared channel
Registering Kernel netlink reflector
Initializing ipvs 2.6
Registering Kernel netlink command channel
Opening file '/etc/keepalived/keepalived.conf'.
Configuration is using : 5879 Bytes
Opening file '/etc/keepalived/keepalived.conf'.
Configuration is using : 61747 Bytes
Using LinkWatch kernel netlink reflector...
Using LinkWatch kernel netlink reflector...
VRRP_Instance(vip) Transition to MASTER STATE
VRRP_Instance(vip) Entering MASTER STATE
Opening script file /etc/keepalived/notify.sh

Se funcionasse, eu esperaria ver uma linha adicional:

Notify state=MASTER

Mas obviamente não funcionou. Alguma idéia de como eu poderia fazer isso funcionar corretamente?

Acho que encontrei o problema. MY_PPID não existe mais como um processo. Parece que, ao executar o script, o processo keepalived faz uma bifurcação dupla para desanexar o script. Quando escrevo no fd de um dos processos de manutenção de vida, ele funciona. Posso obter o pid do arquivo /var/run/keepalived.pid.

Vou tentar isso e retorno.

Eu tenho esse erro no meu log do gerenciador de sub-rede aberta.

Sep 22 01:49:53 router3-1 docker[12431]: Sep 22 01:49:53 089580 [68860700] 0x01 -> mcmr_rcv_join_mgrp: ERR 1B11: Port 0x10c37b1f7ebb0001 (MT25408 ConnectX Mellanox Technologies) failed to join non-existing multicast group with MGID ffff:0:ffff:0:180b:1493:fd7f:0, insufficient components specified for implicit create (comp_mask 0x10083)
Sep 22 01:49:57 router3-1 docker[12431]: Sep 22 01:49:57 328091 [6585A700] 0x01 -> mcmr_rcv_join_mgrp: ERR 1B11: Port 0x10bf482fd3ac0001 (MT25408 ConnectX Mellanox Technologies) failed to join non-existing multicast group with MGID ffff:0:ffff:0:1868:c9d6:fd7f:0, insufficient components specified for implicit create (comp_mask 0x10083)
Sep 22 01:50:04 router3-1 docker[12431]: Sep 22 01:50:04 973005 [60850700] 0x01 -> mcmr_rcv_join_mgrp: ERR 1B11: Port 0x10bf482fd3a60001 (MT25408 ConnectX Mellanox Technologies) failed to join non-existing multicast group with MGID ffff:0:ffff:0:9811:7b48:ff7f:0, insufficient components specified for implicit create (comp_mask 0x10083)
Sep 22 01:50:05 router3-1 docker[12431]: Sep 22 01:50:05 291935 [5F04D700] 0x01 -> mcmr_rcv_join_mgrp: ERR 1B11: Port 0x10bf482fd3a40001 (MT25408 ConnectX Mellanox Technologies) failed to join non-existing multicast group with MGID ffff:0:ffff:0:88f3:3bdf:fd7f:0, insufficient components specified for implicit create (comp_mask 0x10083)
Sep 22 01:50:09 router3-1 docker[12431]: Sep 22 01:50:09 699903 [6685C700] 0x01 -> mcmr_rcv_join_mgrp: ERR 1B11: Port 0x10c37b1f7e110001 (MT25408 ConnectX Mellanox Technologies) failed to join non-existing multicast group with MGID ffff:0:ffff:0:787e:40cb:fd7f:0, insufficient components specified for implicit create (comp_mask 0x10083)
Sep 22 01:50:22 router3-1 docker[12431]: Sep 22 01:50:22 389193 [63856700] 0x01 -> mcmr_rcv_join_mgrp: ERR 1B11: Port 0x10bf482fd3f00001 (MT25408 ConnectX Mellanox Technologies) failed to join non-existing multicast group with MGID ffff:0:ffff:0:c867:44ab:fe7f:0, insufficient components specified for implicit create (comp_mask 0x10083)

Ocorre bastante.

É um problema de aparência muito semelhante ao seguinte relatório de bug arquivado aqui: https://bugzilla.redhat.com/show_bug.cgi?id=1138851

Nesse relatório específico, o erro é contra o grupo NTP mcast.
ou seja, MGID ff12:401b:ffff::101 onde de alguma forma 101 é interpretado como 224.0.1.1 e a partir disso eles dizem que é NTP.

Como esse 101 se tornou isso e o que é um MGID?

No meu caso, o MGID mostrado é: ffff:0:ffff:0:c867:44ab:fe7f:0

Isso se traduz em 224.0.0.0? afirma ser reservado. O que está acontecendo aqui?

Originalmente, eu tinha esse script rodando no Ubuntu, lançado basicamente em rc.local

#!/bin/bash

IBSYSDIR="/home/matthewh/tmp"
hca_id=1
if [ -d ${IBSYSDIR} ]; then
  for hca in ${IBSYSDIR}/*; do
    if [ -e ${hca}/node_desc ]; then
      echo -n "$(hostname -s) HCA-${hca_id}" >> ${hca}/node_desc
    fi
    hca_id=$((hca_id+1))
  done
fi

Agora minha infraestrutura é CoreOS e gostaria de restabelecer este script para definir os nomes de host Infiniband para todos os nós.

Idealmente, para economizar sobrecarga de administração, gostaria de apenas colocar um único arquivo de serviço no cloud-init uma vez e iniciá-lo. Então eu criei o arquivo de serviço systemd mostrado abaixo. Ao criar a maravilha do arquivo único, consegui encurtar o comando para uma única linha no script do arquivo original.

[ -d ${IBSYSDIR} ] && for hca in ${IBSYSDIR}/*; do [ -e ${hca}/node_desc ] && echo -n "$(hostname -s) HCA-${hca_id}" >> ${hca}/node_desc; done

No entanto, eu não consigo correr/bin/sh -c "[ -d ${IBSYSDIR} ] && for hca in ${IBSYSDIR}/*; do [ -e ${hca}/node_desc ] && echo -n "$(hostname -s) HCA-${hca_id}" >> ${hca}/node_desc; done"

Talvez não esteja puxando o ambiente corretamente para o sh. Como faço para que isso funcione em apenas um único arquivo de serviço (sem outros scripts dependentes)?

Seguem o arquivo de serviço e o erro real.

[Unit]
Description=Set the infiniband hostname

[Service]
Type=oneshot
Environment="IBSYSDIR=/sys/class/infiniband"
Environment="hca_id=1"
ExecStart=/bin/bash -c "[ -d ${IBSYSDIR} ] && for hca in ${IBSYSDIR}/*; do [ -e ${hca}/node_desc ] && echo -n "$(hostname -s) HCA-${hca_id}" >> ${hca}/node_desc; done"

[Install]
WantedBy=multi-user.target

O erro real que estou vendo:

Sep 10 00:30:21 service2-2 systemd[1]: Starting Set the infiniband hostname...
Sep 10 00:30:21 service2-2 sh[11134]: -s): -c: line 0: unexpected EOF while looking for matching `)'
Sep 10 00:30:21 service2-2 sh[11134]: -s): -c: line 1: syntax error: unexpected end of file

Então eu fui um pouco mais longe, mas ainda não funciona.

[Unit]
Description=Set the infiniband hostname
After=docker.service
Requires=docker.service

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'IBSYSDIR=/sys/class/infiniband && hca_id=1 && [ -d ${IBSYSDIR} ] && for hca in ${IBSYSDIR}/*; do [ -e ${hca}/node_desc ] && echo -n "$(hostname -s) HCA-${hca_id}" >> "${hca}/node_desc"; done'

[Install]
WantedBy=multi-user.target

Mas se eu executar diretamente

sudo /bin/bash -c 'IBSYSDIR=/sys/class/infiniband && hca_id=1 && [ -d ${IBSYSDIR} ] && for hca in ${IBSYSDIR}/*; do [ -e ${hca}/node_desc ] && echo -n "$(hostname -s) HCA-${hca_id}" >> "${hca}/node_desc"; done'

Ele funciona. O que há de especial no arquivo de serviço? O código de erro retornado é 1. Presumo que seja um erro de permissão negada ou algo assim.

Esta é uma pergunta de acompanhamento de: Como faço para montar um dispositivo rbd do fstab que perguntei há algum tempo.

Como faço para montar dispositivos rbd com o driver de fusível? (Não consigo usar o driver do kernel do docker sem abrir muitos privilégios)

Tanto quanto eu posso dizer, crio uma entrada no arquivo fstab com algo como:

id=client.admin /mnt fuse.ceph 0 0

No entanto, não consigo ver como especificar o dispositivo de bloco rbd. Se eu executar esta montagem, vejo um arquivo em /mnt/mariadb1 (mariadb1 é o nome do meu dispositivo rbd criado com rbd create --size 250000 mariadb1)

Como eu realmente o monto como um sistema de arquivos?

Nota: Sim, eu realmente gostaria de usar o driver rbd do kernel e montá-lo no host e, em seguida, expô-lo ao meu contêiner docker, mas .... Estou usando o CoreOS.

Se for possível montar o sistema de arquivos no namespace de montagem do host, eu aceitaria isso, mas ainda não vejo um caminho a seguir. O melhor que consegui foi montá-lo a partir de um contêiner com muitos privilégios. Mas não posso compartilhar esse contêiner com --volumes-from. Eu realmente não gosto de ter esse contêiner específico com acesso total ao host.

Eu tenho um sistema de armazenamento SSD que contém dois nós com 6 unidades SSD. Não é o ideal e, em algum momento, apresentarei outro nó. No momento, estou querendo uma replicação de 3 vias.

Sob uma regra padrão, isso não acontecerá porque temos apenas dois nós. Então, pensei em tentar modificar o mapa de esmagamento e definir o conjunto de regras para os nós de armazenamento SSD para colocar dados nos dois nós e o terceiro conjunto pode estar em outro OSD no mesmo nó.

Sendo um novato e não entendendo totalmente como as instruções choose firstne chooseleaf firstnfuncionam, não tenho certeza se isso fará o que pretendo.

Aqui está o que eu tenho até agora:

rule ssd-all {
  ruleset 1
  type replicated
  min_size 1
  max_size 5
  step take ssd
  step choose firstn 0 type host
  step chooseleaf firstn 2 type osd
  step emit
}

Onde ssd é um tipo de raiz contendo alguns hosts e os hosts contendo vários (6) OSDs.

Isso funcionaria? De alguma forma, não acho certo. Gostaria de entender melhor quando usar choosee onde usar chooseleaf. E uma melhor compreensão do número após firstn. A documentação carece de exemplos claros. A leitura do whitepaper CRUSH fez algum sentido, mas o psuedocode não está tão claro para mim. Alguém pode ajudar?

Eu tenho algumas instâncias bare metal do CoreOS que estão exibindo um comportamento incomum no dispositivo de ponte docker0.

Em uma das instâncias em que isso ocorreu, estou executando o servidor couchbase e isso causou alguns problemas com o rebalanceamento. Quando mudei o couchbase para um nó onde isso não estava acontecendo, o problema desapareceu.

O que poderia estar causando isso? o que determina o estado do dispositivo de ponte?

hardware é idêntico. A configuração é idêntica, exceto o endereço IP.

Veja a seguinte saída:

[   11.219278] igb 0000:02:00.1 eno2: renamed from eth1
[   11.233382] igb 0000:02:00.0 eno1: renamed from eth0
[   11.254416] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: commit=600
[   11.458737] IPv6: ADDRCONF(NETDEV_UP): ib0: link is not ready
[   11.579397] IPv6: ADDRCONF(NETDEV_UP): eno2: link is not ready
[   11.698029] IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
[   12.010779] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this.
[   12.024156] IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready
[   12.036945] ip_tables: (C) 2000-2006 Netfilter Core Team
[   12.051018] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[   14.650802] igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[   14.660237] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
[   14.742461] IPv6: ADDRCONF(NETDEV_CHANGE): ib0: link becomes ready
[   45.805457] random: nonblocking pool is initialized
[  111.008838] IPv6: ADDRCONF(NETDEV_UP): vetha6b1e7a: link is not ready
[  111.015941] IPv6: ADDRCONF(NETDEV_CHANGE): vetha6b1e7a: link becomes ready
[  111.023065] device veth7ef24ab entered promiscuous mode
[  111.043171] eth0: renamed from vetha6b1e7a
[  112.009927] docker0: port 1(veth7ef24ab) entered forwarding state
[  112.016158] docker0: port 1(veth7ef24ab) entered forwarding state
[  112.022483] IPv6: ADDRCONF(NETDEV_CHANGE): docker0: link becomes ready
[  112.099447] docker0: port 1(veth7ef24ab) entered disabled state
[  112.107076] device veth7ef24ab left promiscuous mode
[  112.112173] docker0: port 1(veth7ef24ab) entered disabled state
[  122.461130] device vethf877e85 entered promiscuous mode
[  122.466924] IPv6: ADDRCONF(NETDEV_UP): vethf877e85: link is not ready
[  122.473684] IPv6: ADDRCONF(NETDEV_CHANGE): vethf877e85: link becomes ready
[  122.480738] docker0: port 1(vethf877e85) entered forwarding state
[  122.486970] docker0: port 1(vethf877e85) entered forwarding state
[  122.506427] eth0: renamed from vethf26c9f2
[  122.632319] docker0: port 1(vethf877e85) entered disabled state
[  122.639992] device vethf877e85 left promiscuous mode
[  122.645123] docker0: port 1(vethf877e85) entered disabled state
[  132.921279] device vethb82e1be entered promiscuous mode
[  132.927131] IPv6: ADDRCONF(NETDEV_UP): vethb82e1be: link is not ready
[  132.933864] IPv6: ADDRCONF(NETDEV_CHANGE): vethb82e1be: link becomes ready
[  132.940925] docker0: port 1(vethb82e1be) entered forwarding state
[  132.947184] docker0: port 1(vethb82e1be) entered forwarding state
[  132.964347] eth0: renamed from veth6449c8e
[  133.013215] docker0: port 1(vethb82e1be) entered disabled state
[  133.021003] device vethb82e1be left promiscuous mode
[  133.026104] docker0: port 1(vethb82e1be) entered disabled state
[  143.403885] device vethddb7ee6 entered promiscuous mode
[  143.409539] IPv6: ADDRCONF(NETDEV_UP): vethdd4d268: link is not ready
[  143.416339] IPv6: ADDRCONF(NETDEV_CHANGE): vethdd4d268: link becomes ready
[  143.433351] eth0: renamed from vethdd4d268
[  144.404045] docker0: port 1(vethddb7ee6) entered forwarding state
[  144.410292] docker0: port 1(vethddb7ee6) entered forwarding state
[  144.480602] docker0: port 1(vethddb7ee6) entered disabled state
[  144.488347] device vethddb7ee6 left promiscuous mode
[  144.493480] docker0: port 1(vethddb7ee6) entered disabled state
[  154.925053] IPv6: ADDRCONF(NETDEV_UP): vethadcefb2: link is not ready
[  154.931794] device veth6087f8b entered promiscuous mode
[  154.937610] IPv6: ADDRCONF(NETDEV_CHANGE): vethadcefb2: link becomes ready
[  154.956632] eth0: renamed from vethadcefb2
[  155.924469] docker0: port 1(veth6087f8b) entered forwarding state
[  155.930718] docker0: port 1(veth6087f8b) entered forwarding state
[  156.007957] docker0: port 1(veth6087f8b) entered disabled state
[  156.015658] device veth6087f8b left promiscuous mode
[  156.020781] docker0: port 1(veth6087f8b) entered disabled state
[  166.387105] IPv6: ADDRCONF(NETDEV_UP): veth407dccf: link is not ready
[  166.394294] IPv6: ADDRCONF(NETDEV_CHANGE): veth407dccf: link becomes ready
[  166.401417] device veth8f92cbb entered promiscuous mode
[  166.420099] eth0: renamed from veth407dccf
[  167.386861] docker0: port 1(veth8f92cbb) entered forwarding state
[  167.393107] docker0: port 1(veth8f92cbb) entered forwarding state
[  167.476477] docker0: port 1(veth8f92cbb) entered disabled state
[  167.484157] device veth8f92cbb left promiscuous mode

Preciso fazer o roteamento de políticas em minhas instâncias CoreOS que usam systemd. Mas não encontrei nenhuma documentação ou exemplos de como fazer isso com systemd-network.

Como faço isso?

Até agora, só consegui criar outra tabela de roteamento adicionando uma entrada a um novo arquivo /etc/iproute2/rt_tablese ela está sendo reconhecida pelas ferramentas de linha de comando.

Por fim, tenho dois roteadores separados na mesma sub-rede. Quero garantir que o tráfego proveniente de um roteador destinado ao meu host seja retornado pelo mesmo roteador.

Desejo criar um disco no CoreOS que seja montado automaticamente em /var/lib/docker

Então, criei um arquivo de unidade var-lib-docker.mount para fazer isso e decidi usar o caminho por rótulo em /dev/disk.

Inicialmente, descobri que minhas partições aparecem no caminho by-partlabel. No entanto, funciona muito bem.

No processo, descobri que existe um programa chamado e2label e, também, no modo especialista do fdisk, também posso criar um rótulo de partição.

Não tendo encontrado o e2label inicialmente, descobri que poderia rotular as partições com a palavra "DOCKER" no fdisk. Mas eles realmente chegam ao caminho /dev/disk/by-partlabel e não /dev/disk/by-label

Quais são as diferenças entre estes? um deve ser favorecido em detrimento do outro?

Estou tendo problemas para configurar o cluster etcd sem usar um URL de descoberta em execução no CoreOS.

A configuração é via cloud-init. Os 3 servidores no cluster estão listados em pares abaixo. Cada um tem um IP diferente e tem addr e peer-addr configurados estaticamente.

Por exemplo, o primeiro servidor contém:

#cloud-config
coreos:
  etcd:
      addr: 192.168.0.50:4001
      peer-addr: 192.168.0.50:7001
      peers: 192.168.0.50:7001,192.168.0.51:7001,192.168.0.52:7001

O que estou vendo no journalctl é:

AVISO | cluster de sincronização de falha ([ http://192.168.0.50:7001 http://127.0.0.1:7001] )

E erros como estes:

locksmithd[12262]: etcd.service está ativo locksmithd[12262]: Erro ao inicializar o cliente etcd: 402: Erro interno em espera (

Presumo que o etcd não esteja funcionando corretamente.

Infelizmente, o site do CoreOS não detalha uma configuração estática do CoreOS e etcd na prática.

Depois que estiver funcionando, como seria minha configuração de nuvem para uma instância etcd com proxy?

Eu tenho uma imagem docker que executa o Couchbase Enterprise 3.0.2

Está em um repositório privado atualmente. Então vamos apenas dizer que o nome dele é:

matt/couchbase

Para permitir que os dados persistam caso o matt/couchbase seja removido, criei um contêiner somente de dados baseado no matt/couchbase chamado matt/couchbase-data

O Dockerfile se parece com

FROM matt/couchbase
CMD ["true"]
VOLUME ["/opt/couchbase/var/lib/couchbase/data"]

De acordo com as docas do couchbase, o caminho do volume acima deve ser onde o couchbase armazena seus dados.

Portanto, executo matt/couchbase-data e, em seguida, executo matt/couchbase com um link --volumes-from.

Isso funciona bem. docker inspecionar programas couchbase:

"Volumes": {
        "/opt/couchbase/var/lib/couchbase/data": "/var/lib/docker/vfs/dir/f129a034a2b0474392fe98bdc37429f172be26c93a058540f3a1043d324c0b1c"
    },
    "VolumesRW": {
        "/opt/couchbase/var/lib/couchbase/data": true
    }

e docker inspecionar couchbase-data contém:

"Volumes": {
        "/opt/couchbase/var/lib/couchbase/data": "/var/lib/docker/vfs/dir/f129a034a2b0474392fe98bdc37429f172be26c93a058540f3a1043d324c0b1c"
    },
    "VolumesRW": {
        "/opt/couchbase/var/lib/couchbase/data": true
    }

Portanto, parece que os dois contêineres se conectaram perfeitamente.

No entanto, o problema é este. Quando paro o contêiner chamado "couchbase" e o removo com o docker rm e, em seguida, inicio o couchbase novamente, os dados desaparecem, apesar do docker-inspect indicar que o volume ainda está ativo com o mesmo caminho real de antes. ou seja, /var/lib/docker/vfs/dir/f129a034a2b0474392fe98bdc37429f172be26c93a058540f3a1043d324c0b1c

Isso pode ser relevante. O servidor couchbase está sendo iniciado com o seguinte script init que obtive de outro projeto docker couchbase (desculpe, perdi o link temporariamente).

Achei que talvez o cluster-init abaixo (que é o que eu executo por padrão para couchbase) possa estar redefinindo os dados. Mas, de acordo com os documentos, ele apenas define o nome de usuário, a senha e a porta do cluster.

Alguma ideia?

#!/bin/bash
set +e



echo 'removing document size limit'
sed -i 's/return getStringBytes(json) > self.docBytesLimit;/return false/g' /opt/couchbase/lib/ns_server/erlang/lib/ns_server/priv/public/js/documents.js

echo 'starting couchbase'
/etc/init.d/couchbase-server restart

wait_for_start() {
    "$@"
    while [ $? -ne 0 ]
    do
        echo 'waiting for couchbase to start'
        sleep 1
        "$@"
    done
}


if [ -z "$CLUSTER_INIT_USER" ] || [ -z "$CLUSTER_INIT_PASSWORD" ]; then
       echo >&2 'error: Couchbase not initialized because CLUSTER_INIT_USER or CLUSTER_INIT_PASSWORD was not set'
       echo >&2 '       Did you forget to add -e CLUSTER_INIT_USER=... -e CLUSTER_INIT_PASSWORD=... ?'
       exit 1
fi

if [ -z "$COUCHBASE_PORT_8091_TCP" ]; then

    if [ -z "$CLUSTER_RAM_SIZE" ]; then
        CLUSTER_RAM_SIZE=1024
    fi

    echo 'initializing cluster...'
    wait_for_start /opt/couchbase/bin/couchbase-cli cluster-init -c 127.0.0.1:8091 --cluster-init-username="$CLUSTER_INIT_USER" --cluster-init-password="$CLUSTER_INIT_PASSWORD" --cluster-init-ramsize="$CLUSTER_RAM_SIZE" -u "$CLUSTER_INIT_USER" -p "$CLUSTER_INIT_PASSWORD"

    if [ -n "$SAMPLE_BUCKETS" ]; then
    curl http://"$CLUSTER_INIT_USER":"$CLUSTER_INIT_PASSWORD"@127.0.0.1:8091/sampleBuckets/install --data "[$SAMPLE_BUCKETS]"
    fi
else
    ip=`hostname --ip-address`
    wait_for_start /opt/couchbase/bin/couchbase-cli server-add -c $COUCHBASE_PORT_8091_TCP_ADDR:$COUCHBASE_PORT_8091_TCP_PORT --user="$CLUSTER_INIT_USER" --password="$CLUSTER_INIT_PASSWORD" --server-add=$ip:8091
fi

trap "/etc/init.d/couchbase-server stop" exit INT TERM

pid_file=/opt/couchbase/var/lib/couchbase/couchbase-server.pid
# can't use 'wait $(<"$pid_file")' as process not child of shell
while [ -e /proc/$(<"$pid_file") ]; do sleep 1; done

Digamos que eu comece com um certificado.

Usando o openssl, posso imprimi-lo assim:

openssl x509 -in cert.pem -text -noout

E obterei alguma saída como Validity, Issuere Subjectjunto com Authority Key Identifiere Subject Key Identifier.

Como uso esses campos para calcular o próximo certificado da cadeia?

E então, quando eu obtiver o próximo certificado, decida qual deve ser o próximo certificado, etc.

Basicamente, estou querendo trabalhar toda a cadeia e colocar as coisas na ordem certa para o balanceador de carga EC2. Já que as soluções de rede não parecem oferecer apenas um pacote que funciona. Eles fornecem certificados individuais e eu tentei e tentei vários pedidos diferentes para o EC2 e ainda não consegui fazê-lo funcionar. Minha última aposta é tentar o openssl e resolver isso manualmente, em vez de adivinhar.

Eu recebi um arquivo de certificado que é um nome de domínio curinga. Ele vem como uma chave e um arquivo crt. Nenhum outro arquivo foi fornecido.

Estou tendo problemas para fazê-lo funcionar corretamente com o balanceador de carga elástico.

Eu tentei esta ordem:

http://www.networksolutions.com/support/installation-of-an-ev-ssl-certificate-for-tomcat-apache/

Com os certificados intermediários obtidos aqui: http://www.networksolutions.com/support/where-can-i-locate-the-network-solutions-nsprotect-root-and-intermediate-certificate-files/

Eu também tentei o seguinte:

• Soluções de rede Adicionar raiz CA externa confiável
• Soluções de Rede UTN Adicionar Confiança CA
• Soluções de Rede Servidor UTN CA
• CA de Validação Estendida (EV) de Soluções de Rede
• Certificado intermediário de soluções de rede
• Soluções de rede EV Root

O erro que o ELB retorna é:

Não foi possível validar a cadeia de certificados. A cadeia de certificados deve começar com o certificado de assinatura imediato, seguido por quaisquer intermediários em ordem. O índice dentro da cadeia do certificado inválido é: -1

Há tantas informações conflitantes e desatualizadas por aí e nada parece funcionar. Como faço isso funcionar?

Existe um método que eu possa usar com o OpenSSL para descobrir manualmente quais certificados preciso em cada etapa?

Estou querendo passar o infiniband para um contêiner docker para que eu possa executar alguns aplicativos de alto desempenho no ipoib e usar o rdma.

Atualmente, estou fazendo isso com máquinas virtuais xen. Agora estou pensando em usar o CoreOS e o docker como uma alternativa muito mais leve e fácil de gerenciar.

Eu tenho um dispositivo IPoIB ib0 com um IP estático atribuído a ele de 10.10.10.10. Consegui expor isso dentro de um contêiner docker com o seguinte:

docker run --net=host --device=/dev/infiniband/uverbs0 --device=/dev/infiniband/rdma_cm -t -i ubuntu:14.04 /bin/bash

Ótimo, isso funciona. ib0 está disponível dentro do contêiner docker.

Agora vamos supor que eu tenha um HCA de porta dupla. No host, eles aparecem como ib0 e ib1 e têm dois ips atribuídos. 10.10.10.10/ib0 e 10.10.10.11/ib1

E agora quero passar ib0 para o primeiro container e ib1 para o segundo. Usando o método acima, ambos aparecerão em ambos os contêineres devido à opção --net=host. No entanto, não especificá-lo significa que os dispositivos não aparecem.

Outro cenário é que tenho muitas máquinas que usam SR-IOV para passar por dispositivos infiniband para máquinas virtuais xen. Como eu poderia passar, em vez disso, um dispositivo infiniband de função virtual para um contêiner docker e fazer isso aparecer?

Nota: o pipework não funciona nesta situação, mas se eu entender melhor, pode ser hackeado para fazer o que eu quero. Só não entendo muito bem o que está fazendo... ainda.

É possível ter um único volume montado btrfs somente leitura montado em várias máquinas?

Um dos hosts pode montá-lo para leitura/gravação para fornecer atualizações aos outros?

A razão pela qual estou perguntando isso é se é sensato montar /var/lib/docker em várias instâncias do CoreOS. O que as pessoas fazem na prática para nuvens privadas? instâncias particularmente inicializadas em rede.

Ou devo criar um dispositivo de bloco exclusivo montado em /var/lib/docker para cada host físico e vinculá-lo a um registro privado?

https://coreos.com/docs/cluster-management/setup/mounting-storage/

Eu tenho um firewall/roteador (não estou fazendo NAT).

Eu pesquisei e vi respostas conflitantes. Parece que o UDP 500 é o comum. Mas os outros são confusos. 1701, 4500.

E alguns dizem que eu também preciso permitir gre 50, ou 47, ou 50 e 51.

Ok, quais portas são as corretas para o IPSec/L2TP funcionar em um ambiente roteado sem NAT? ou seja, eu quero usar o cliente Windows embutido para conectar a uma VPN por trás deste roteador/firewall.

Talvez uma boa resposta aqui seja especificar quais portas abrir para diferentes situações. Acho que isso seria útil para muitas pessoas.