arne.z's questions

Estou tentando configurar um ambiente Kerberos simples que consiste em um servidor Kerberos (KDC), uma máquina cliente e uma máquina servidora executando um daemon OpenSSH. O cliente deve ser autenticado por meio do Kerberos ao estabelecer uma conexão SSH com a máquina do servidor.

O nome do usuário Kerberos que estou tentando autenticar é krbuser. Este usuário existe na máquina de serviço e possui um uid de 1001. O estranho é que preciso digitar a senha do usuário Kerberos ao fazer login com SSH. Cada vez que entro. Não apenas para minha primeira conexão. Isso parece estranho porque o objetivo do Kerberos é autenticar sem senha.

Fiz um tcpdump durante o processo de autenticação e notei que o cliente está fazendo AS-REQs para o KDC com cname root. Este nome de usuário Kerberos não e não tenho ideia de por que o cliente está usando esse nome. Como esperado, o KDC responde com uma eRR-C-PRINCIPAL-UNKNOWNmensagem, pois não há rootusuário no banco de dados.

Para mim, parece que o principal problema é o fato de o cliente tentar autenticar como rootem vez de krbuser.

Vou postar algumas informações sobre minha configuração atual abaixo. Por favor, deixe-me saber se você precisar de alguma informação adicional.

No KDC:

/etc/krb5.conf

[logging]
    default = FILE:/usr/local/krb5/var/log/krb5lib.log 
    kdc = FILE:/usr/local/krb5/var/log/krb5kdc.log
    admin_server = FILE:/usr/local/krb5/var/log/kadmin.log

[libdefaults]
    default_realm = metz.prac.os3.nl
    rdns = false

# The following krb5.conf variables are only for MIT Kerberos.
    krb4_config = /etc/krb.conf
    krb4_realms = /etc/krb.realms
    kdc_timesync = 1
    ccache_type = 4
    forwardable = true
    proxiable = true

[realms]
    metz.prac.os3.nl = {
        kdc = krb-0.metz.prac.os3.nl
        admin_server = krb-0.metz.prac.os3.nl
    }

Na máquina de serviço:

/etc/ssh/sshd config(um extrato)

# Kerberos options
KerberosAuthentication yes
# KerberosGetAFSToken no
# KerberosOrLocalPasswd no
# KerberosTicketCleanup yes

# GSSAPI options
GSSAPIAuthentication yes
# GSSAPICleanupCredentials yes

Arquivos de log capturados durante a autenticação SSH:

debug1: rekey after 4294967296 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user root service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "root"
debug1: PAM: setting PAM_RHOST to "218.65.30.30"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: inetd sockets after dupping: 5, 5
Connection from 145.100.110.115 port 51946 on 145.100.110.116 port 22
debug1: Client protocol version 2.0; client software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 pat OpenSSH* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: permanently_set_uid: 106/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: algorithm: [email protected] [preauth]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256 [preauth]
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none [preauth]
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: rekey after 134217728 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: rekey after 134217728 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user krbuser service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "krbuser"
debug1: PAM: setting PAM_RHOST to "145.100.110.115"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user krbuser service ssh-connection method gssapi-with-mic [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 2 failures 1 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 3 failures 2 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
debug1: userauth-request for user krbuser service ssh-connection method password [preauth]
debug1: attempt 2 failures 0 [preauth]
debug1: temporarily_use_uid: 1001/1001 (e=0/0)
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1001/1001 (e=0/0)
debug1: restore_uid: 0/0
debug1: do_pam_account: called
Accepted password for krbuser from 145.100.110.115 port 51946 ssh2
debug1: monitor_child_preauth: krbuser has been authenticated by privileged process
debug1: monitor_read_log: child log fd closed
debug1: temporarily_use_uid: 1001/1001 (e=0/0)
debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism
debug1: restore_uid: 0/0
debug1: PAM: establishing credentials
User child is on pid 20617
debug1: SELinux support disabled
debug1: PAM: establishing credentials
debug1: permanently_set_uid: 1001/1001
debug1: rekey after 134217728 blocks
debug1: rekey after 134217728 blocks
debug1: ssh_packet_set_postauth: called
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_global_request: rtype [email protected] want_reply 0
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_new: session 0
debug1: SELinux support disabled
debug1: session_pty_req: session 0 alloc /dev/pts/2
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
Starting session: shell on pts/2 for krbuser from 145.100.110.115 port 51946 id 0
debug1: Setting controlling tty using TIOCSCTTY.
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 4 failures 3 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 5 failures 4 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 6 failures 5 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
maximum authentication attempts exceeded for root from 218.65.30.30 port 18460 ssh2 [preauth]
Disconnecting: Too many authentication failures [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup
debug1: PAM: cleanup
debug1: Killing privsep child 20604
debug1: audit_event: unhandled event 12
debug1: inetd sockets after dupping: 5, 5
Connection from 218.65.30.30 port 58146 on 145.100.110.116 port 22
debug1: Client protocol version 2.0; client software version nsssh2_4.0.0032 NetSarang Computer, Inc.
debug1: no match: nsssh2_4.0.0032 NetSarang Computer, Inc.
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: permanently_set_uid: 106/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: algorithm: diffie-hellman-group14-sha1 [preauth]
debug1: kex: host key algorithm: ssh-rsa [preauth]
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none [preauth]
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none [preauth]
debug1: expecting SSH2_MSG_KEXDH_INIT [preauth]

Na máquina cliente:

kinite klistantes da autenticação:

$ kinit -p krbuser
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: [email protected]

Valid starting     Expires            Service principal
06/15/17 00:24:05  06/15/17 10:24:05  krbtgt/[email protected]
    renew until 06/16/17 00:23:56

/etc/ssh/ssh config(um extrato):

    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials yes
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no

E finalmente a autenticação SSH:

$ ssh [email protected] -vvv
...
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "service-0.metz.prac.os3.nl" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to service-0.metz.prac.os3.nl [145.***.***.***] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
...
debug1: Found key in /home/client/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/client/.ssh/id_rsa ((nil))
debug2: key: /home/client/.ssh/id_dsa ((nil))
debug2: key: /home/client/.ssh/id_ecdsa ((nil))
debug2: key: /home/client/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: send packet: type 50
debug2: we sent a gssapi-with-mic packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: send packet: type 50
debug2: we sent a gssapi-with-mic packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: send packet: type 50
debug2: we sent a gssapi-with-mic packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: send packet: type 50
debug2: we sent a gssapi-with-mic packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
...
debug1: Next authentication method: password
[email protected]'s password: <entering PW of Kerberos user> !!!
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (password).
Authenticated to service-0.metz.prac.os3.nl ([145.***.***.***]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug3: receive packet: type 91
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
...
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Thu Jun 15 00:28:57 2017

Connection established

Now klist shows the following tickets:

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: [email protected]

Valid starting     Expires            Service principal
06/15/17 00:24:05  06/15/17 10:24:05  krbtgt/[email protected]
    renew until 06/16/17 00:23:56
06/15/17 00:27:37  06/15/17 10:24:05  host/service-0.metz.prac.os3.nl@
    renew until 06/16/17 00:23:56
06/15/17 00:27:37  06/15/17 10:24:05  host/[email protected]
    renew until 06/16/17 00:23:56

So, to sum up: The Kerberos user on the client can establish an SSH session to the server by entering its Kerberos (!) password. Not its UNIX password. The tcpdump showed that the client authenticates as root which is not a Kerberos user and I have no idea why it is using this username instead of krbuser. Which is the one I used with the kinit command.

Can anyone tell me why this authentication is not working correctly? Please let me know if you need additional information. I tried to keep it short.

A documentação do MIT Kerberos lista sete maneiras diferentes de armazenar credenciais Kerberos:

1. API
2. DIR
3. ARQUIVO
4. KCM
5. CHAVEIRO
6. MEMÓRIA
7. MSLSA

No momento, minha configuração do Kerberos está armazenando credenciais em um arquivo no /tmp diretório. No meu krb5.confarquivo, a ccache_typeopção é definida como 4 por padrão:

# The following krb5.conf variables are only for MIT Kerberos.
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true

E na documentação do MIT Kerberos sobre o krb5.confarquivo diz sobre a ccache_typeopção:

Este parâmetro determina o formato dos tipos de cache de credenciais criados pelo kinit ou outros programas. O valor padrão é 4, que representa o formato mais atual. Valores menores podem ser usados ​​para compatibilidade com implementações muito antigas de Kerberos que interagem com caches de credenciais no mesmo host.

Parece que o valor da ccache_typeopção não corresponde aos sete tipos de ccache que a documentação lista. Desde 4que especifica para usar o "formato mais atual" e não "KCM".

Portanto, minha pergunta é: Como posso configurar o Kerberos para usar um tipo de ccache diferente, por exemplo, um chaveiro ou memória?

Estou tentando configurar um ambiente Kerberos simples no qual um servidor cliente se autentica em um webservice (no meu caso OpenSSH) por meio de um servidor Kerberos.

Gerei um arquivo keytab no KDC, mas não tenho certeza de quais servidores copiar o arquivo. Preciso apenas copiá-lo para a máquina que está oferecendo o serviço ou também para a máquina cliente que deseja autenticar o serviço?

Estou usando o Weave Net para conectar meus contêineres Docker em diferentes hosts. O Weave está usando o "Fast Datapath" que lida com o roteamento no Kernel Space (dentro do módulo OVS (Open vSwitch) conforme mostrado no diagrama abaixo).

Para entender melhor como o Weave roteia o tráfego, gostaria de ver as entradas de roteamento do Módulo OVS. Existem comandos como ovs-vsctl show"imprime uma breve visão geral do conteúdo do banco de dados", mas isso não funcionou. Parece que o Weave está executando sua própria instância OVS que não pode ser acessada com este comando.

Eu também tentei inspecionar o Weave com o

weave status        [targets | connections | peers | dns | ipam]

comandos, mas isso também não mostrou nenhuma informação de roteamento detalhada.

Então, alguém sabe como ver a tabela de roteamento que o weave usa para decidir para onde rotear pacotes destinados a um determinado contêiner docker?

nmapoferece funcionalidade de detecção de sistema operacional baseada em impressão digital TCP/IP enviando seis pacotes de sondagem e analisando suas respostas. Na documentação é dito que alguns deles são enviados para uma porta aberta e alguns são enviados para uma porta fechada.

Alguém sabe como nmapdecide para qual porta enviar as sondas? Ele apenas procura a primeira porta fechada e as primeiras portas abertas que encontra? Ele os procura em uma determinada ordem? Ou ele escolhe aleatoriamente uma porta?

Estou tentando configurar o EXIM para usar o Rspamd como um filtro de spam. Estou executando o Exim versão 4.87 e instalei o Rpsam dos repositórios usando apt-getconforme explicado aqui . Em seguida, adicionei a configuração sugerida da documentação do Rspamd ao meu arquivo de configuração:

begin acl

# configure Rspamd
# Please note the variant parameter
spamd_address = 127.0.0.1 11333 variant=rspamd   # error occurs here

acl_smtp_data = acl_check_spam

acl_check_spam:
  # do not scan messages submitted from our own hosts
  accept hosts = +relay_from_hosts

  # do not scan messages from submission port
  accept condition = ${if eq{$interface_port}{587}}

  # skip scanning for authenticated users
  accept authenticated = *

  # add spam-score and spam-report header when told by rspamd
  warn  spam       = nobody:true
        condition  = ${if eq{$spam_action}{add header}}
        add_header = X-Spam-Score: $spam_score ($spam_bar)
        add_header = X-Spam-Report: $spam_report

  # use greylisting available in rspamd v1.3+
  defer message    = Please try again later
        condition  = ${if eq{$spam_action}{soft reject}}

  deny  message    = Message discarded as high-probability spam
        condition  = ${if eq{$spam_action}{reject}}

  accept

Quando tento reiniciar o Exim, recebo a seguinte mensagem de erro:

error in ACL: unknown ACL condition/modifier in "spamd_address = 127.0.0.1 11333 variant=rspamd"

Que se refere à 4ª linha do código de configuração que postei acima: spamd_address = 127.0.0.1 11333 variant=rspamd. Encontrei exatamente a mesma linha na documentação oficial do Exim . Então deve funcionar. Alguém encontrou esse problema antes, ao configurar o Exim para usar o Rspamd?

Estou usando Ubuntu:

$ uname -a
Linux calais 4.4.0-36-generic #55-Ubuntu SMP Thu Aug 11 18:01:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Gostaria de saber se minha VM do Ubuntu usa tcp-offloading para aumentar o desempenho do encapsulamento VXLAN. Onde posso encontrar essas informações na minha máquina?

Escrevi um programa Python que é executado iperf3em um loop for com diferentes tamanhos de datagrama. Estou usando a subprocess.callfunção do Python para rodar iperf3assim:

 iperf3 -u -c 185.82.21.60 -b 100M -t 5 -l <datagram size>

O tamanho do meu datagrama começa com 1000 e aumenta em 100 após cada iteração e deve ser executado até atingir o tamanho de 2000. Toda vez que estou executando meu programa, o iperf3 continua travando após a 6ª vez e começa a usar 100% de uma das minhas CPUs. Depois disso, não posso mais usar o iperf3 até encerrar o processo do cliente em execução e reiniciar o servidor iper3.

Aqui está uma imagem para ilustrar o meu problema:

Estou medindo a taxa de transferência UDP entre dois contêineres do Docker conectados pela rede de sobreposição nativa do Docker. Eu já usei, iperfmas também quero medir a taxa de transferência com arquivos nuttcp. Mas quando estou iniciando a instância do servidor e, em seguida, inicio a instância do cliente, a instância do servidor trava com a seguinte mensagem de erro: Segmentation fault (core dumped). Foi assim que iniciei o servidor:

nuttcp -S -u --nofork

e foi assim que iniciei o cliente:

nuttcp -u -T 115 10.0.0.3

A instância do servidor trava logo após a inicialização do cliente. Usei os mesmos comandos para rodar nuttcpfora do Docker sem problemas.

Aqui estão algumas informações adicionais sobre as versões que estou usando:

# inside the container:
$ uname -a
Linux 310d92462ac0 3.19.0-58-generic #64~14.04.1-Ubuntu SMP Fri Mar 18 19:05:43 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ nuttcp -V
nuttcp-6.1.2

# outside the container:
$ uname -a
Linux libAMS 3.19.0-58-generic #64~14.04.1-Ubuntu SMP Fri Mar 18 19:05:43 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ docker -v
Docker version 1.10.3, build 20f81dd

Alguém tem alguma ideia de como resolver isso?

No momento, estou examinando o desempenho (especialmente a taxa de transferência UDP) de diferentes redes de sobreposição do Docker. Eu faço isso criando conexões ponto a ponto entre dois hosts que estão conectados com uma rede de sobreposição do Docker e, em seguida, executo iperfdentro dos contêineres do Docker para examinar a taxa de transferência. Percebi que sempre que estou executando iperfcomo cliente para enviar dados para outro contêiner que é executado iperfcomo servidor, o uso da CPU do host do cliente chega a 100%. Eu obtive esse resultado executando o seguinte comando que encontrei aqui :

top -bn1 | grep "Cpu(s)" | \
       sed "s/.*, *\([0-9.]*\)%* id.*/\1/" | \
       awk '{print 100 - $1"%"}'

Então, para mim, parece que o fator limitante dos meus testes de throughput é a capacidade da CPU do meu host, pois ele roda a 100% e não consegue gerar mais tráfego para saturar a conexão de rede. Eu estou querendo saber se este é um iperfproblema específico, então eu queria executar os mesmos testes com uma ferramenta diferente, mas não tenho certeza de qual alternativa seria melhor . Os hosts estão executando o Ubuntu. Por exemplo, encontrei qperf, uperfe netpipe.

Além disso, de maneira mais geral, comecei a me perguntar qual é normalmente o gargalo para o desempenho da taxa de transferência. Não é sempre a capacidade da CPU ou a largura de banda do link? Que são fatores que não estão diretamente relacionados às redes overlay.

Isso significa que a taxa de transferência de um aplicativo (ou rede de sobreposição) depende apenas de quantos ciclos de CPU ele precisa para transferir uma certa quantidade de dados e como ele os compacta para ajustá-los à rede (se esse for o gargalo).