wazoox's questions

Eu tenho um servidor Debian rodando KVM+libvirt. Os discos de VMs são LVs no host. O problema é que, se eu criar LVs dentro dos convidados, eles são detectados recursivamente no host e isso cria todo tipo de problema, como a incapacidade de redimensionar ou excluir LVs corretamente.

Então eu adicionei uma regra de filtro /etc/lvm/lvm.confcomo esta, para excluir LVs de varredura dentro de outros LVs:

filter = [ "r|/dev/dm-*|", "a|/dev/sd.*|" ]

Agora meu problema é: como faço para que o LVM redigitalize apenas os VGs e LVs "reais"? Agora tenho erros como este:

# lvs
  WARNING: Device for PV 73C0Ma-sAYV-Aa10-pAHB-ZAZA-3QjH-Rk1eTS not found or rejected by a filter.
  WARNING: Device for PV fcEG5k-BLzO-dbAr-Yw8o-dPw2-1hAk-VyluvW not found or rejected by a filter.
  LV              VG              Attr       LSize    Pool Origin    Data%  Meta%  Move Log Cpy%Sync Convert
  HaProxy         data            -wi-ao----   20,00g                                                       
  backup          data            -wi-ao----    4,00t                                                       
  database        data            -wi-ao----   16,00g                                                       
  lvol0           data            swi-a-s---   16,07g      stone-web 70,43                                  
  stone-vtls      data            -wi-ao----    2,00t                                                       
  stone-web       data            owi-aos---   16,00g                                                       
  lv0             ftpstorage      -wi-----p-   10,00t                                                       

O último lv neste caso é na verdade um LV de uma VM, não do host... Como me livrar dele sem reiniciar o host?

Para redirecionar vários subdomínios no mesmo IP para hosts diferentes, estou usando o haproxy (1.7.5, Debian estável) e funciona bem. No entanto, também quero restringir o acesso a alguns hosts por IP e exibir uma mensagem limpa (página de erro 403 adequada) para hosts rejeitados, e é aí que não consigo encontrar uma solução.

O melhor que tenho até agora é uma configuração que usa um backend "reject"; no entanto, não sei como configurar este para obter nada além de erros SSL do final do navegador.

A configuração fica assim:

frontend http_redirect
    bind *:80
    redirect scheme https if !{ ssl_fc }

frontend tls_router
    bind *:443
    mode tcp
    option tcplog
    option tcpka

    acl demo_acl req_ssl_sni -i demo.myhost.org
    acl www_acl req_ssl_sni -i www.myhost.org
    acl demo_network_allowed src 10.1.1.0/24

    use_backend demo_tls if demo_acl
    use_backend wwww_tls if www_acl
    use_backend reject_access if demo_acl !demo_network_allowed

backend www_tls
    mode tcp
    option tcpka
    server www_srv 192.168.1.2:443

backend demo_tls
    mode tcp
    option tcpka
    server demo_srv 192.168.1.3:443

backend reject_access
    mode http
    # errorfile 403 /etc/haproxy/errors/403.http
    # server demo  192.168.1.2:443
    http-request set-path www.myhost.org/403.html
    http-request redirect scheme https if ! { ssl_fc }

Como fica claro no backend "reject_access", tentei várias coisas com o mesmo resultado:

$ LANG=C wget  --no-check-certificate -S https://demo.myhost.org
--2019-07-01 18:48:31--  https://demo.host.org/
Résolution de demo.myhost.org? 10.12.24.1
Connexion à demo.myhost.org|10.12.24.1|:443? connecté.
OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Incapable d'établir une connexion SSL.

Qualquer ajuda nesta configuração é bem-vinda.

Eu tenho um Debian/Jessie Samba 4.2.14 rodando como um membro do AD. ADC é um servidor Windows2008R2. Join funcionou sem problemas.

# net ads testjoin
Join is OK

wbinfo -ue wbinfo -gfuncionam perfeitamente e fornecem uma lista de usuários e grupos do AD conforme o esperado. wbinfo -i <user>funciona também:

# wbinfo -i TESTAD\\testuser
TESTAD\testuser:*:4294967295:4294967295:testuser:/home/TESTAD/testuser:/bin/false

Editar: algo está errado aqui, porque wbinfo -imapeia todos os usuários e grupos para o id 4294967295 que é, como observou @TheSkunk, 2 ^ 32 -1.

Editar 2: wbinfo --sid-to-uid TESTAD\\testuser falha. Certamente devo configurar explicitamente alguns idmapparâmetros (os padrões aparentemente não funcionam), mas como?

Editar 3: adicionei essas 2 linhas ao smb.conf:

idmap config * : backend = tdb
idmap config * : range = 10000-30000

E agora ẁbinfo -i TESTDOMAIN\testuser reports a valid id, and a different one for each and every user. However I still have the same problems (all users mapping to nobody,id andgetent` não conhecendo usuários AD, etc).

No entanto getent passwd TESTAD\\testuserfalha:

# getent passwd TESTAD\\testuser
# echo $? 
2

Posso me conectar ao servidor com qualquer conta AD usando smbclient:

# smbclient //srv1/data -U TESTAD\\testuser
Enter TESTAD\testuser's password: 
Domain=[TESTAD] OS=[Windows 6.1] Server=[Samba 4.2.14-Debian]
smb: \> ls
  .                                   D        0  Fri Feb 17 16:23:04 2017
  ..                                  D        0  Wed Feb  1 16:47:02 2017
  test.txt                            N        5  Fri Feb 17 14:38:21 2017
  popo                                D        0  Fri Feb 17 16:23:04 2017

                117125466112 blocks of size 1024. 117052392484 blocks available
smb: \> 

No entanto, a conexão é mapeada para nobody/nogroup, e os arquivos criados também pertencem a nobodyele. As máquinas Windows falham ao se conectar usando qualquer conta do AD. No entanto, se eu criar uma conta local com smbpasswd -a <user>, eles poderão se conectar usando-a. No entanto, seus parâmetros de conexão, arquivos etc. são todos mapeados, nobodyembora a conta também exista localmente.

Aqui está o atual smb.conf(o mais próximo possível do padrão):

[global]
        workgroup = TESTAD
        realm = TESTAD.lan
        server role = member server
        security = ADS
        map to guest = Bad User
        obey pam restrictions = Yes
        pam password change = Yes
        passwd program = /usr/bin/passwd %u
        passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
        unix password sync = Yes
        syslog = 0
        log file = /var/log/samba/log.%m
        max log size = 1000
        dns proxy = No
        usershare allow guests = Yes
        panic action = /usr/share/samba/panic-action %d
        idmap config * : backend = tdb
        inherit permissions = Yes
        inherit acls = Yes


[DATA]
        path = /mnt/raid/
        read only = No
        guest ok = Yes

aqui está /etc/nsswitch.conf(eu tentei adicionar e remover 'winbindd da sombra, nenhuma mudança):

# cat /etc/nsswitch.conf 
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat winbind
group:          compat winbind
shadow:         compat winbind
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns wins
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

Não entendo por que a autenticação nunca parece passar pelo winbind. Estou ficando desesperada, alguma ideia?

Preciso migrar um servidor de armazenamento existente executando o Debian 6, com muitos TB de dados, para uma configuração HA. Não posso simplesmente desligar este servidor por muito tempo (afinal, HA é necessário).

Pretendo migrar este servidor para um cluster DRBD. Não posso comprar dois novos servidores para este cluster; Preciso reutilizar o servidor existente como membro do cluster por motivos de custo. Lembre-se, não consigo desligar nada por mais de alguns minutos de cada vez.

Tenho um novo servidor pronto, rodando Debian 8 para ser o "mestre". Eu precisaria configurar um cluster de "cérebro dividido" usando este servidor "mestre"; copie todos os dados do servidor antigo existente para o cluster; alternar os serviços existentes para o cluster; reconfigure o servidor antigo com o Debian 8, adicione-o ao cluster como um "escravo", sincronize novamente os dados e, por fim, tenha uma configuração redundante.

Configurei o cluster na nova máquina, porém, como proceder? Não consigo nem iniciar o serviço drbd, pois o outro "nó" ainda nem existe ...

Estou iniciando a partir de uma configuração drbd anterior que funcionou bem... com dois nós disponíveis.

Qualquer ajuda apreciada.

Configurei um par de servidores idênticos com matrizes RAID (8 núcleos, 16 GB de RAM, 12x2 TB RAID6), 3 interfaces 10GigE, para hospedar alguns serviços altamente disponíveis.

Atualmente, os sistemas estão executando o Debian 7.9 Wheezy oldstable (porque o corosync/pacemaker não está disponível no 8.x estável nem no teste).

• O desempenho do disco local é de cerca de 900 MB/s de gravação, 1600 MB/s de leitura.
• a taxa de transferência de rede entre as máquinas é superior a 700 MB/s.
• por meio do iSCSI, cada máquina pode gravar no armazenamento da outra a mais de 700 MB/s.

No entanto, independentemente da maneira como configuro o DRBD, a taxa de transferência é limitada a 100 MB/s. Realmente parece algum limite codificado. Posso diminuir o desempenho de forma confiável ajustando as configurações, mas nunca ultrapassa 1 Gbit (122 MB/s são atingidos por alguns segundos de cada vez). Estou realmente puxando meu cabelo em um presente.

• kernel vanilla simples 3.18.24 amd64
• drbd 8.9.2~rc1-1~bpo70+1

A configuração é dividida em dois arquivos: global-common.conf:

global {
        usage-count no;
}

common {
        handlers {
        }

        startup {
        }

        disk {
                on-io-error             detach;
         #       no-disk-flushes ;
        }
        net {
                max-epoch-size          8192;
                max-buffers             8192;
                sndbuf-size             2097152;
        }
        syncer {
                rate                    4194304k;
                al-extents              6433;
        }
}

e cluster.res:

resource rd0 {
        protocol C;
        on cl1 {
                device /dev/drbd0;
                disk /dev/sda4;
                address 192.168.42.1:7788;
                meta-disk internal;
        }

        on cl2 {
                device /dev/drbd0;
                disk /dev/sda4;
                address 192.168.42.2:7788;
                meta-disk internal;
        }
}

Saída do cat /proc/drbdescravo:

version: 8.4.5 (api:1/proto:86-101)
srcversion: EDE19BAA3D4D4A0BEFD8CDE 
 0: cs:SyncTarget ro:Secondary/Secondary ds:Inconsistent/UpToDate C r-----
    ns:0 nr:4462592 dw:4462592 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:16489499884
        [>....................] sync'ed:  0.1% (16103024/16107384)M
        finish: 49:20:03 speed: 92,828 (92,968) want: 102,400 K/sec

Saída do vmstat 2mestre (ambas as máquinas estão quase completamente ociosas):

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0      0 14952768 108712 446108    0    0   213   254   16    9  0  0 100  0
 0  0      0 14952484 108712 446136    0    0     0     4 10063 1361  0  0 99  0
 0  0      0 14952608 108712 446136    0    0     0     4 10057 1356  0  0 99  0
 0  0      0 14952608 108720 446128    0    0     0    10 10063 1352  0  1 99  0
 0  0      0 14951616 108720 446136    0    0     0     6 10175 1417  0  1 99  0
 0  0      0 14951748 108720 446136    0    0     0     4 10172 1426  0  1 99  0

Saída iperfentre os dois servidores:

------------------------------------------------------------
Client connecting to cl2, TCP port 5001
TCP window size:  325 KByte (default)
------------------------------------------------------------
[  3] local 192.168.42.1 port 47900 connected with 192.168.42.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  6.87 GBytes  5.90 Gbits/sec

Aparentemente, a sincronização inicial deve ser um pouco lenta, mas não tão lenta ... Além disso, ele realmente não reage a nenhuma tentativa de acelerar a taxa de sincronização como drbdadm disk-options --resync-rate=800M all.