smb-share tempo de conexão aumenta cada reinicialização no windows PE

2

No momento, estamos desenvolvendo um sistema que faz atualizações automáticas do BIOS para nossos computadores.

O sistema é executado no Windows 10 PE inicializado via PXE-Boot. Um dos primeiros passos é conectar-se a um SMB-Share, onde todos os dados necessários são armazenados.

O compartilhamento em si está hospedado no Debian 4.9.88-1 + deb9u1 com o smbd Versão 4.5.12-Debian.

O problema

O procedimento precisa de várias reinicializações e inicializar o Windows PE novamente.

O que descobrimos é que cada sistema é executado corretamente na primeira inicialização, mas a cada reinicialização no Windows PE, a conexão com o SMB-Share demora mais tempo e às vezes chega a atingir o tempo limite com o erro 63 do Windows.

Como o Windows PE é armazenado "novo" na RAM em cada reinicialização e não é persistente, em nossa opinião, o problema tem que estar no lado do servidor.

Os arquivos de log do Samba não continham erros referentes à conexão dos hosts.

Mount Command in PE

NET USE B: \SERVER\buffet \user:user password

Como o Windows 10 não permite logins de visitantes anônimos ou compartilha sem senha, não usar credenciais de login não é uma opção, apesar de eu pessoalmente não acreditar que o problema tenha a ver com autenticação.

Config do Samba

Como você pode ver, já tentamos muitas configurações de tempo limite:

[global]
    workgroup = WORKGROUP
    security = user
    server role = standalone
    disable netbios = no
    server string = %h
    map to guest = Bad User
    obey pam restrictions = Yes
    passdb backend = tdbsam
    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
    log file = /var/log/samba/log.%m
    log level = 10 winbind:5 auth:3
    max log size = 1000
    dns proxy = No
    usershare allow guests = Yes
    panic action = /usr/share/samba/panic-action %d
    create mask = 0777
    directory mask = 0777
    map hidden = no
    map system = no
    map archive = no
    store dos attributes = yes
    dos filemode = Yes
    acl map full control = Yes
    server min protocol = SMB3_10
    socket options = TCP_NODELAY IPTOS_LOWDELAY
    read raw = yes
    write raw = yes
    server signing = no
    strict locking = no
    min receivefile size = 16384
    use sendfile = Yes
    aio max threads = 250
    aio read size = 1
    aio write size = 1
    ldap timeout = 3
    deadtime = 1
    winbind request timeout = 10
    name cache timeout = 0
    winbind max domain connections = 50
    winbind max clients = 750
    inherit owner = No

[buffet]
    path = /share/buffet
    public = yes
    writeable = no
    browseable = yes
    guest ok = yes
    force user = nobody
    force group = nogroup
    read only = yes
    case sensitive = no
    default case = lower
    preserve case = yes
    short preserve case = yes

Como podemos consertar a configuração para que os hosts possam fazer reinicializações infinitas e ainda se conectar ao compartilhamento instantaneamente?

Tenta corrigi-lo

Tentamos várias configurações de tempo limite, como você pode ver no smb.conf acima, mas todas elas não tiveram efeito para nosso problema (a conclusão é que elas não podem ser o problema).

Também extraímos e analisamos uma tonelada de arquivos de log do samba, onde tentamos evitar qualquer "falha" ou "tempo limite" ou o que quer que aponte para um erro devido à configuração incorreta e finalmente resolvemos todos eles, mas mesmo assim, a questão ainda persiste.

Também tentamos algumas configurações diferentes do servidor DHCP, como definir o tempo de concessão padrão como um valor muito pequeno, como dez segundos, mas, novamente, isso não afeta nosso problema.

Também tentamos forçar o Samba a usar o SMB2 ou o SMB3_11, mas definir o protocolo SMB usado como um valor fixo também não foi capaz de corrigir o problema, que após três ou quatro reinicializações do nosso cliente winPE, o compartilhamento SMB não ligue mais imediatamente.

Depois que um ping rápido foi bem-sucedido, não há alta carga de CPU / memória no servidor, enquanto a tentativa de montar o compartilhamento dura. Também monitoramos a largura de banda da rede usando o velocímetro e só podemos ver cargas muito baixas (apenas alguns KB / s para cima e para baixo) na conexão. Os tempos de ping em si não aumentam durante essas tentativas atrasadas de montar o compartilhamento.

    
por MarcelKohlmeyer 31.08.2018 / 09:39

1 resposta

0

Como acompanhamento, gostaria de informar que hoje mudamos nossa arquitetura de transferência de arquivos do samba para HTTP, para verificar se o atraso vem do serviço (samba) ou do host / rede. Decidimos usar o apache2 para hospedar os arquivos necessários para o nosso aplicativo, e tentamos meio dia enfrentar o mesmo problema que tivemos com o samba, sem sucesso. Por mais de quatro horas de testes (fizemos reinicializações automáticas de clientes após o download bem-sucedido do payload do compartilhamento apache), não vimos uma única tentativa malsucedida de conexão!

Devido a isso, decidimos reduzir nossa configuração do samba para uma configuração bare-metal que realmente se parece com isso, para evitar a interferência entre as diferentes configurações que fizemos:

[global]
workgroup = WORKGROUP
security = user
server role = standalone
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
map to guest = Bad Password
log file = /var/log/samba/log.%m

Mas mesmo com essa configuração muito limitada, ainda vemos o problema que, após uma quantidade muito limitada de reinicializações, o atraso entre um ping bem-sucedido para o servidor (para verificar sua disponibilidade) e a conexão com o smb começam a aumentar, até finalmente, o tempo limite e lança um erro "caminho de rede não foi encontrado".

Fato interessante neste caso é que podemos repetir esse comportamento com qualquer cliente que tenhamos disponível. Acabamos de inicializar o nosso WinPE, deixe ping no servidor, se ele pings, conecte o compartilhamento samba, baixe alguns arquivos necessários (apenas alguns MB) e deixe o cliente reiniciar. Mesmo se estamos testando paralelamente em vários clientes que estão atrasados por digamos duas reinicializações, podemos ver que, se um cliente "trava", o outro cliente novo é iniciado imediatamente. A conclusão é que o problema deve ser causado por uma interferência do cliente / samba, ou algo que indique a direção de muitas conexões simultâneas de um determinado cliente para o compartilhamento de samba.

Pensamos que reduzimos completamente o problema ao samba, pois, com o apache, não poderíamos fazer com que o problema aparecesse por meio dia. Além disso, devido ao fato de que, com o apache, tudo está funcionando como esperado, pensamos, que um servidor ou uma configuração de rede não pode ser o caso.

Você pensaria a mesma coisa e diria que deve ser samba?

Agradecemos qualquer ideia que possa ser útil. Como resolvemos esse caso em particular (a solução para nós é não usar o samba), gostaríamos de saber a causa raiz desse problema, pois temos um problema semelhante em outro departamento de fábrica, onde não podemos evitar usar o samba para compartilhar arquivos através da rede. De acordo com isso, estamos dispostos a continuar a depurar este problema, se algum de vocês tiver mais informações para nós.

Para evitar mais confusão, gostaria de informar que Marcel Kohlmeyer e eu somos colegas, que trabalham com o mesmo problema simultaneamente.

    
por 04.09.2018 / 23:31