mongos

Opções principais

--help, -h

Retorna informações sobre as opções e uso de mongos.

--version

Retorna o número de versão mongos.

--config <filename>, -f <filename>

Especifica um arquivo de configuração para opções de configuração do tempo de execução. O arquivo de configuração é o método preferido para a configuração de tempo de execução do mongos. As opções são equivalentes às opções de configuração da linha de comando. Consulte Opções de arquivo de configuração autogerenciadas para obter mais informações.

Certifique-se de que o arquivo de configuração use codificação ASCII. A instância mongos não suporta arquivos de configuração com codificação não ASCII, incluindo UTF-8.

--configExpand <none|rest|exec>

Padrão: nenhum

Habilita o uso de diretivas de expansão em arquivos de configuração. As diretivas de expansão permitem que você defina valores de origem externa para opções de arquivo de configuração.

--configExpand suporta as seguintes diretivas de expansão:

Valor	Descrição
none	Padrão. mongos não expande diretivas de expansão. mongos falha ao iniciar se alguma configuração do arquivo de configuração usar diretivas de expansão.
rest	mongos expande as diretivas de expansão __rest ao analisar o arquivo de configuração.
exec	mongos expande as diretivas de expansão __exec ao analisar o arquivo de configuração.

É possível especificar várias diretivas de expansão como uma lista separada por vírgula, por exemplo: rest, exec. Se o arquivo de configuração tiver diretivas de expansão não especificadas para --configExpand, o mongos retornará um erro e encerrará.

Consulte Valores de arquivo de configuração de origem externa para implantações autogerenciadas para arquivos de configuração para obter mais informações sobre diretivas de expansão.

--verbose, -v

Aumenta a quantidade de relatórios internos retornados no resultado padrão ou em arquivos de log. Aumente a verbosidade com o formato -v incluindo a opção várias vezes, por exemplo: -vvvvv.

--quiet

Executa mongos em um modo silencioso que tenta limitar a quantidade de resultado.

Esta opção suprime:

• resultado de comandos do banco de dados

• atividade de replicação

• eventos aceitos de conexão

• eventos fechados de conexão

--port <port>

Padrão: 27017

A porta TCP na qual a instância mongos escuta conexão de cliente.

Alterado na versão 6.0.12: A opção --port aceita um intervalo de valores entre 0 e 65535. A definiçãso da porta como 0 configura mongos para usar uma porta arbitrária atribuída pelo sistema operacional.

--bind_ip <hostnames|ipaddresses|Unix domain socket paths>

Padrão: localhost

Os nomes de host e/ou endereços IP e/ou caminhos completos de soquete de domínio Unix nos quais mongos deve escutar as conexões do cliente. Você pode anexar mongos a qualquer interface. Para vincular a vários endereços, insira uma lista de valores separados por vírgula.

Exemplo

localhost,/tmp/mongod.sock

Você pode especificar endereços IPv4 e IPv6 ou nomes de host que resolvem para um endereço IPv4 ou IPv6.

Exemplo

localhost, 2001:0DB8:e132:ba26:0d5c:2774:e7f9:d513

Observação

Se estiver especificando um endereço IPv6 ou um nome de host que resolva para um endereço IPv6 para --bind_ip, é preciso executar o mongos com --ipv6 para habilitar o suporte a IPv6 . Especificar um endereço IPv6 para --bind_ip não habilita o compatibilidade com IPv6.

Se estiver especificando um endereço IPv6 de link local (fe80::/10), você deve anexar o índice de zona para esse endereço (ou seja fe80::<address>%<adapter-name>).

Exemplo

localhost,fe80::a00:27ff:fee0:1fcf%enp0s3

Importante

Para evitar atualizações de configuração devido a alterações de endereço IP, use nomes de host DNS em vez de endereços IP. É particularmente importante usar um nome de host DNS em vez de um endereço IP ao configurar membros de conjunto de réplicas ou membros de cluster fragmentado.

Use nomes de host em vez de endereços IP para configurar cluster em um horizonte de rede dividido. Começando no MongoDB 5.0, nós configurados apenas com um endereço IP falham na validação de inicialização e não são iniciados.

Aviso

Antes de vincular a um não localhost (por exemplo, acessível IP ), certifique-se de ter protegido seu cluster contra o acesso não autorizado. Para obter uma lista completa de recomendações de segurança, consulte a Lista de verificação de segurança para implementações autogerenciadas. No mínimo, procure habilitar a autenticação e fortalecer a infraestrutura de rede.

Para obter mais informações sobre vinculação de IP, consulte a documentação de vinculação de IP em implantações autogerenciadas.

Para vincular a todos os endereços IPv4, digite 0.0.0.0.

Para se vincular a todos os endereços IPv4 e IPv6, digite ::,0.0.0.0 ou um asterisco "*" (coloque o asterisco entre aspas para evitar a expansão do padrão de nome de arquivo). Como alternativa, use a configuração net.bindIpAll.

Observação

• --bind_ip e --bind_ip_all são mutuamente exclusivos. Especificar as duas opções faz com que mongos gere um erro e encerre.

• A opção de linha de comando --bind substitui a definição do arquivo de configuração net.bindIp.

--bind_ip_all

Se especificado, a instância do mongos se liga a todos os endereços IPv4 (ou seja, 0.0.0.0). Se mongos começar com --ipv6, --bind_ip_all também se vinculará a todos os endereços IPv6 (ou seja ::).

mongos só oferece suporte a IPv6 se iniciado com --ipv6. Especificar --bind_ip_all por si só não habilita o suporte a IPv6 .

Aviso

Antes de vincular a um não localhost (por exemplo, acessível IP ), certifique-se de ter protegido seu cluster contra o acesso não autorizado. Para obter uma lista completa de recomendações de segurança, consulte a Lista de verificação de segurança para implementações autogerenciadas. No mínimo, procure habilitar a autenticação e fortalecer a infraestrutura de rede.

Para obter mais informações sobre vinculação de IP, consulte a documentação de vinculação de IP em implantações autogerenciadas.

Como alternativa, você pode definir a opção --bind_ip como ::,0.0.0.0 ou como asterisco "*" (coloque o asterisco entre aspas para evitar a expansão do padrão de nome de arquivo).

Observação

--bind_ip e --bind_ip_all são mutuamente exclusivos. Ou seja, você pode especificar um ou outro, mas não ambos.

--listenBacklog <number>

Padrão: constante do sistema de destino SOMAXCONN

O número máximo de conexões que podem existir na fila de escuta .

Aviso

Consulte a documentação do seu sistema local para entender as limitações e os requisitos de configuração antes de usar este parâmetro.

Importante

Para evitar um comportamento indefinido, especifique um valor para esse parâmetro entre 1 e a constanteSOMAXCONN do sistema local.

O valor padrão do parâmetro listenBacklog é configurado no tempo de compilação para a constante SOMAXCONN do sistema de destino. SOMAXCONN é o valor máximo válido documentado para o parâmetro backlog da chamada de sistema de escuta.

Alguns sistemas podem interpretar SOMAXCONN simbolicamente e, outros, numericamente. O backlog de escuta real aplicado na prática pode ser diferente de qualquer interpretação numérica da constante SOMAXCONN ou do argumento --listenBacklog e também pode ser limitado por configurações do sistema, como net.core.somaxconn no Linux.

Passar um valor para o parâmetro listenBacklog que excede a constante SOMAXCONN para o sistema local é, de acordo com os padrões, comportamento indefinido. Valores mais altos podem ser silenciosamente truncados, podem ser ignorados, podem causar consumo inesperado de recursos ou ter outras consequências adversas.

Em sistemas com volumes de trabalho que exibem picos de conexão, para os quais é empiricamente conhecido que o sistema local pode honrar valores mais altos para o parâmetro backlog do que a constante SOMAXCONN, definir o parâmetro listenBacklog para um valor mais alto pode reduzir a latência da operação, conforme observado pelo cliente, reduzindo o número de conexões que são forçadas a um estado de backoff.

--maxConns <number>

O número máximo de conexões simultâneas que mongos aceita. Esta configuração não terá efeito se for maior do que o limite máximo de rastreamento de conexão configurado pelo sistema operacional.

Não atribua um valor muito baixo a esta opção para não encontrar erros durante a operação normal do aplicativo.

Isso é muito útil para um mongos se você tiver um cliente que cria várias conexões e permite que elas atinjam o tempo limite em vez de fechá-las.

Nesse caso, defina maxIncomingConnections como um valor um pouco maior que o número máximo de conexões que o cliente cria ou o tamanho máximo do pool de conexões.

Essa configuração impede que o mongos cause picos de conexão nos fragmentos individuais. Picos como esses podem interromper a operação e a alocação de memória do cluster fragmentado.

--logpath <path>

Envia todas as informações de registro de diagnóstico para um arquivo de log em vez de para o resultado padrão ou para o sistema syslog do host. O MongoDB cria o arquivo de log no caminho especificado.

Por padrão, o MongoDB moverá qualquer arquivo de log existente em vez de substituí-lo. Para anexar ao arquivo de log, defina a opção --logappend.

--syslog

Envia toda a saída de log para o sistema syslog do host em vez de para a saída padrão ou para um arquivo de log (--logpath).

A opção --syslog não é aceita no Windows.

Aviso

O daemon syslog gera logs de data/hora quando registra uma mensagem, não quando o MongoDB envia a mensagem. Isso pode levar a carimbos de data/hora enganosos para entradas de log, especialmente quando o sistema está sobrecarregado. Recomendamos usar a opção --logpath para sistemas de produção para garantir carimbos de data/hora precisos.

O MongoDB inclui o componente em suas mensagens de log para syslog.

...  ACCESS   [repl writer worker 5] Unsupported modification to roles collection ...

--syslogFacility <string>

Usuário padrão

Especifica o nível de instalação utilizado ao registrar mensagens para syslog. O valor especificado deve ser suportado pela implementação de syslog do seu sistema operacional. Para utilizar esta opção, você deve habilitar a opção --syslog.

--logappend

Acrescenta novas entradas ao final do arquivo de log existente quando a instância mongos é reiniciada. Sem essa opção, o mongod fará backup do registro existente e criará um novo arquivo.

--logRotate <string>

Padrão: renomear

Determina o comportamento do comando logRotate ao girar o log do servidor e/ou o log de auditoria. Especifique rename ou reopen:

• rename renomeia o arquivo de log.

• reopen fecha e reabre o arquivo de log seguindo o comportamento típico de rotação de registro Linux/Unix. Utilize o reopen ao usar o utilitário de rotação de registro Linux/Unix para evitar perda de registro.

  Se você especificar reopen, também deverá usar --logappend.

--redactClientLogData

Disponível apenas no MongoDB Enterprise.

Um mongos em execução com --redactClientLogData oculta qualquer mensagem que acompanhe um determinado evento de log antes do registro de log. Isso impede que mongos grave dados potencialmente confidenciais armazenados no banco de dados no log de diagnóstico. Metadados como códigos de erro ou operação, números de linha e nomes de arquivos de origem ainda são visíveis nos logs.

Use --redactClientLogData em conjunto com criptografia em descanso e TLS/SSL (criptografia de transporte) para auxiliar a conformidade com os requisitos normativos.

Por exemplo, uma implantação do MongoDB pode armazenar informações de identificação pessoal (PII, na sigla em inglês) em uma ou mais coleções. O mongos registra eventos como aqueles relacionados a operações CRUD, fragmentação de metadados etc. É possível que mongos exponha PII como parte dessas operações de registro. Um mongos em execução com --redactClientLogData remove qualquer mensagem que acompanhe esses eventos antes de ser enviada para o log, removendo efetivamente as PII.

O diagnóstico em um mongos em execução com --redactClientLogData pode ser mais difícil devido à falta de dados relacionados a um evento de log. Consulte a página Log de processos no manual para ver um exemplo do efeito de --redactClientLogData na saída de log.

Em um mongos em execução, utilize setParameter com o parâmetro redactClientLogData para definir esta configuração.

--timeStampFormat <string>

Default: iso8601-local

O formato de hora para carimbos de data/hora em mensagens de registro. Especifique um dos valores a seguir:

Valor	Descrição
iso8601-utc	Exibe carimbos de data/hora em Tempo Universal Coordenado (UTC) no formato ISO-8601. Por exemplo, para Nova Iorque no início da Época: 1970-01-01T00:00:00.000Z
iso8601-local	Exibe carimbos de data e hora na hora local no formato ISO-8601. Por exemplo, para Nova Iorque no início da Época: 1969-12-31T19:00:00.000-05:00

Observação

--timeStampFormat não aceita mais ctime. Um exemplo de data formatada ctime é: Wed Dec 31 18:17:54.811.

--pidfilepath <path>

Especifica uma localização de arquivo para armazenar o ID de processo (PID) do processo mongos. O usuário que executa o processo mongod ou mongos deve ser capaz de gravar nesse caminho. Se a opção --pidfilepath não for especificada, o processo não criará um arquivo PID. Em geral, essa opção só é útil em combinação com a opção --fork.

Observação

Linux

No Linux, o gerenciamento de arquivos PID geralmente é de responsabilidade do sistema de inicialização da sua distribuição: geralmente, um arquivo de serviço no diretório /etc/init.d ou um arquivo de unidade systemd registrado com systemctl. Só use a opção --pidfilepath se não estiver usando um desses sistemas de inicialização. Para obter mais informações, consulte o Guia de instalação do seu sistema operacional.

Observação

macOS

No macOS, o gerenciamento de arquivos PID geralmente é tratado pelo brew. Utilize somente a opção --pidfilepath se você não estiver utilizando o brew em seu sistema macOS. Para obter mais informações, consulte o respectivo Guia de instalação do seu sistema operacional.

--keyFile <file>

Especifica o caminho para um arquivo de chave que armazena o segredo compartilhado que instâncias do MongoDB usam para autenticar umas às outras em um cluster fragmentado ou conjunto de réplicas. --keyFile implica client authorization. Consulte Autenticação interna/de associação autogerenciada para obter mais informações.

Os arquivos de chaves para autenticação de associação interna usam o formato YAML para permitir várias chaves em um só arquivo. O formato YAML aceita:

• Uma única string de chave (igual às versões anteriores)

• Uma sequência de strings de chave

O formato YAML é compatível com os arquivos-chave de chave única existentes que usam o formato de arquivo de texto.

--setParameter <options>

Especifica um dos parâmetros MongoDB descritos em Parâmetros do MongoDB Server para uma implementação autogerenciada. Você pode especificar múltiplos campos setParameter .

--noscripting

Desabilita o mecanismo de roteiro. Quando desativado, você não pode usar operações que executam a execução de código JavaScript no lado do servidor, como o operador de query $where, o comando mapReduce, $accumulator e $function.

Se você não usar essas operações, desabilite os scripts do lado do servidor.

--nounixsocket

Desabilita a escuta no soquete de domínio UNIX. --nounixsocket se aplica somente aos sistemas baseados em Unix.

O processo mongos sempre escuta no soquete UNIX, a menos que uma das seguintes opções seja verdadeira:

• --nounixsocket está definido

• net.bindIp não está definido

• net.bindIp não especifica localhost ou seu endereço IP associado

mongos instalados a partir de pacotes .deb e .rpm oficiais têm a configuração bind_ip definida como 127.0.0.1 por padrão.

--unixSocketPrefix <path>

Padrão: /tmp

O caminho para o soquete UNIX. --unixSocketPrefix se aplica somente aos sistemas baseados em Unix.

Se esta opção não tiver nenhum valor, o processo mongos cria um soquete com /tmp como prefixo. O MongoDB cria e escuta em um soquete UNIX, a menos que um dos seguintes seja verdadeiro:

• net.unixDomainSocket.enabled é false

• --nounixsocket está definido

• net.bindIp não está definido

• net.bindIp não especifica localhost ou seu endereço IP associado

--filePermissions <path>

Padrão: 0700

Define a permissão para o arquivo de soquete de domínio UNIX.

--filePermissions aplica-se apenas a sistemas baseados em Unix.

--fork

Habilita um modo daemon que executa o processo mongos em segundo plano. A opção --fork não é suportada no Windows.

Por padrão, mongos não é executado como um daemon. Você executa mongos como um daemon utilizando --fork ou um processo de controle que lida com a daemonização, como upstart ou systemd.

O uso da opção --fork exige que você configure a saída de log para mongos com uma das seguintes opções:

• --logpath

• --syslog

--transitionToAuth

Permite que mongos aceite e crie conexões autenticadas e não autenticadas de e para outras instâncias mongod e mongos na implantação. Usado para realizar a transição contínua de conjunto de réplicas ou clusters fragmentados de uma configuração sem autenticação para autenticação interna. Requer a especificação de um mecanismo de autenticação interna, como --keyFile.

Por exemplo, se utilizar keyfiles para autenticação interna, o mongos criará uma conexão autenticada com qualquer mongod ou mongos no sistema utilizando um arquivo de chave correspondente. Se os mecanismos de segurança não corresponderem, mongos utilizará uma conexão não autenticada.

Um mongos em execução com --transitionToAuth não impõe controles de acesso do usuário. Os usuários podem se conectar a sua implantação sem nenhuma verificação de controle de acesso e realizar operações administrativas, de leitura e gravação.

Observação

Um mongos executando com autenticação interna e sem --transitionToAuth exige que os clientes se conectem usando controles de acesso de usuário. Atualize os clientes para conectar ao mongos usando o usuário apropriado antes de reiniciar o mongos sem --transitionToAuth.

--networkMessageCompressors <string>

Default: snappy,zstd,zlib

Especifica o(s) compressor(es) padrão(s) a ser(em) usado(s) para comunicação entre esta instância mongos e:

• outros membros do cluster fragmentado

• mongosh

• drivers que suportam o formato de mensagem OP_COMPRESSED .

MongoDB é compatível com os seguintes compactadores:

• snappy

• zlib

• zstd

Ambas as instâncias do mongod e mongos padrão para compressores do snappy,zstd,zlib, neste pedido.

Para desativar a compactação de rede, defina o valor como disabled.

Importante

As mensagens são compactadas quando ambas as partes habilitam a compactação de rede. Caso contrário, as mensagens entre as partes serão descompactadas.

Se você especificar vários compressores, a ordem na qual você os lista importa, bem como o iniciador de comunicação. Por exemplo, se o mongosh especificar os seguintes compressores de rede zlib,snappy e o mongod especificar snappy,zlib, as mensagens entre o mongosh e o mongod usarão zlib.

Se as partes não compartilharem pelo menos um compressor comum, as mensagens entre as partes serão descompactadas. Por exemplo, se o mongosh especificar o compressor de rede zlib e o mongod especificar snappy, as mensagens entre o mongosh e o mongod não serão compactadas.

--timeZoneInfo <path>

O caminho completo a partir do qual carregar o banco de dados de fuso horário. Se esta opção não for fornecida, o MongoDB usará seu banco de dados de fuso horário integrado.

O arquivo de configuração incluído com pacotes Linux e macOS define o caminho do banco de dados de fuso horário para /usr/share/zoneinfo por padrão.

O banco de dados de fuso horário integrado é uma cópia do banco de dados de fuso horário Olson/IANA. Ele é atualizado junto com as versões do MongoDB, mas o ciclo de lançamento da zona de fuso horário é diferente do ciclo de lançamento do MongoDB. A versão mais recente do banco de dados de fuso horário está disponível em nosso site de download.

wget https://downloads.mongodb.org/olson_tz_db/timezonedb-latest.zip
unzip timezonedb-latest.zip
mongos --timeZoneInfo timezonedb-2017b/

Aviso

O MongoDB usa a biblioteca timelib de terceiros para fornecer conversões precisas entre fusos horários. Devido a uma atualização recente, timelib pode criar conversões de fuso horário imprecisas em versões mais antigas do MongoDB.

Para vincular explicitamente ao banco de dados de fuso horário em versões do MongoDB anteriores à 5.0, baixe o banco de dados de fusos horários. e use o parâmetro timeZoneInfo .

--outputConfig

Envia as opções de configuração da instância do mongos , formatadas em YAML, para stdout e sai da instância do mongos . Para opções de configuração que usam Valores de arquivo de configuração de origem externa para implantações autogerenciadas, --outputConfig retorna o valor resolvido para essas opções.

Aviso

Isso pode incluir quaisquer senhas ou segredos configurados anteriormente pela fonte externa.

Para exemplos de uso, consulte:

• Enviar o arquivo de configuração com valores de diretiva de expansão resolvidos

• Converter opções de linha de comando autogerenciadas em YAML

Opções de cluster fragmentado

--configdb <replicasetName>/<config1>,<config2>...

Especifica os servidores de configuração para o cluster fragmentado.

Os servidores de configuração para clusters fragmentados são implantados como um conjunto de réplica. Os servidores de configuração do conjunto de réplica devem executar o mecanismo de armazenamento WiredTiger.

Especifique o nome do conjunto de réplicas do servidor de configuração e o nome do host e porta de pelo menos um dos membros do conjunto de réplicas do servidor de configuração.

sharding:
  configDB: <configReplSetName>/cfg1.example.net:27019, cfg2.example.net:27019,...

As instâncias do mongos para o cluster fragmentado devem especificar o mesmo nome do conjunto de réplicas do servidor de configuração, mas podem especificar o nome do host e a porta de diferentes nós do conjunto de réplicas.

--localThreshold

Padrão: 15

Especifica o tempo de ping, em milissegundos, que mongos usa para determinar quais nós do conjunto de réplicas secundárias passam operações de leitura dos clientes. O valor padrão de 15 corresponde ao valor padrão em todos os drivers do cliente.

Quando mongos recebe uma solicitação que permite leituras para nós secundários, ele:

• Localiza o nó do conjunto com o menor tempo de ping.

• Constrói uma lista de nós do conjunto de réplicas que esteja dentro de um tempo de ping de 15 milissegundos do nó adequado mais próximo do conjunto.

  Se você especificar um valor para a opção --localThreshold, o mongos criará a lista de nós da réplica que estão dentro da latência permitida por este valor.

• Seleciona um nó para ler aleatoriamente a partir desta lista.

O tempo de ping utilizado para um nó comparado pela configuração --localThreshold é uma média móvel de tempos de ping recentes, calculado no máximo a cada 10 segundos. Como resultado, algumas queries podem alcançar nós acima do limite até que o mongos recalcule a média.

Consulte a seção Preferência de leitura para conjuntos de réplicas da documentação de preferência de leitura para obter mais informações.

Opções de TLS

--tlsMode <mode>

Ativa o TLS usado para todas as conexões de rede. O argumento para a opção --tlsMode pode ser um dos seguintes:

Valor	Descrição
disabled	O servidor não usa TLS.
allowTLS	As conexões entre servidores não usam TLS. Para conexões recebidas , o servidor aceita TLS e não TLS.
preferTLS	As conexões entre servidores usam TLS. Para conexões recebidas , o servidor aceita TLS e não TLS.
requireTLS	O servidor usa e aceita apenas conexões criptografadas TLS.

Se --tlsCAFile ou tls.CAFile não for especificado e você não estiver usando a autenticação x.509, será necessário definir o parâmetro tlsUseSystemCA como true. Isso faz com que o MongoDB use o armazenamento de certificados CA em todo o sistema ao se conectar a um servidor habilitado para TLS.

Se estiver usando a autenticação x.509, --tlsCAFile ou tls.CAFile devem ser especificados, a menos que esteja usando--tlsCertificateSelector.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsCertificateKeyFile <filename>

Observação

No macOS ou no Windows, você pode usar um certificado de armazenamento seguro do sistema operacional em vez de especificar um arquivo PEM. Consulte --tlsCertificateSelector.

Especifica o arquivo .pem que contém o certificado e a chave TLS.

• No Linux/BSD, você deve especificar --tlsCertificateKeyFile quando o TLS estiver habilitado.

• No Windows ou macOS, você deve especificar --tlsCertificateKeyFile ou --tlsCertificateSelector quando o TLS estiver habilitado.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsCertificateKeyFilePassword <value>

Especifica a senha para descriptografar o arquivo de chave de certificado (ou seja, --tlsCertificateKeyFile). Utilize a opção --tlsCertificateKeyFilePassword somente se o arquivo da chave de certificado for criptografado. Em todos os casos, o mongos edita a senha de todos os resultados de geração de registros e relatórios.

• No Linux/BSD, se a chave privada no arquivo PEM estiver criptografada e você não especificar a opção --tlsCertificateKeyFilePassword, o MongoDB solicitará uma senha. Consulte Senha do certificado TLS/SSL.

• No macOS ou no Windows, se a chave privada no arquivo PEM estiver criptografada, você deverá especificar explicitamente a opção --tlsCertificateKeyFilePassword. Outra opção é usar um certificado do armazenamento seguro do sistema (consulte --tlsCertificateSelector) em vez de um arquivo PEM ou usar um arquivo PEM não criptografado.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--clusterAuthMode <option>

Padrão: keyFile

O modo de autenticação usado para autenticação de cluster. Se você usar a autenticação x.509 interna, especifique-a aqui. Esta opção pode ter um dos seguintes valores:

Valor	Descrição
keyFile	Use um arquivo-chave para autenticação. Aceite apenas arquivos-chave.
sendKeyFile	Para fins de atualização contínua. Envie um arquivo-chave para autenticação, mas pode aceitar arquivos-chave e certificados x.509.
sendX509	Para fins de atualização contínua. Envie o certificado x.509 para autenticação, mas pode aceitar arquivos-chave e certificados x.509.
x509	Recomendado. Envie o certificado x.509 para autenticação e aceite apenas certificados x.509.

Se --tlsCAFile ou tls.CAFile não for especificado e você não estiver usando a autenticação x.509, será necessário definir o parâmetro tlsUseSystemCA como true. Isso faz com que o MongoDB use o armazenamento de certificados CA em todo o sistema ao se conectar a um servidor habilitado para TLS.

Se estiver usando a autenticação x.509, --tlsCAFile ou tls.CAFile devem ser especificados, a menos que esteja usando--tlsCertificateSelector.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsClusterFile <filename>

Observação

No macOS ou no Windows, é possível usar um certificado do armazenamento seguro do sistema operacional em vez de um arquivo PEM. Consulte --tlsClusterCertificateSelector.

Especifica o arquivo .pem que contém o arquivo de chave de certificado x.509 para autenticação de associação para o cluster ou conjunto de réplicas.

Se --tlsClusterFile não especificar o arquivo .pem para autenticação de cluster interna ou a alternativa --tlsClusterCertificateSelector, o cluster utilizará o arquivo .pem especificado na opção --tlsCertificateKeyFile ou o certificado retornado por --tlsCertificateSelector.

Se estiver usando a autenticação x.509, --tlsCAFile ou tls.CAFile devem ser especificados, a menos que esteja usando--tlsCertificateSelector.

mongod / mongos registra um aviso na conexão se o certificado x.509 apresentado expirar dentro de 30 dias a partir do horário do sistema host mongod/mongos.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsClusterPassword <value>

Especifica a senha para descriptografar o arquivo de chave de certificado x.509 especificado com --tlsClusterFile. Utilize a opção --tlsClusterPassword somente se o arquivo da chave de certificado for criptografado. Em todos os casos, o mongos omite a senha de todos os resultados de emissão de relatório e registro.

• No Linux/BSD, se a chave privada no arquivo x.509 estiver criptografada e você não especificar a opção --tlsClusterPassword, o MongoDB solicitará uma senha. Consulte a página "Senha do certificado TLS/SSL".

• No macOS ou no Windows, se a chave privada no arquivo x.509 estiver criptografada, você deverá especificar explicitamente a opção --tlsClusterPassword. Outra opção é usar um certificado do armazenamento seguro do sistema (consulte --tlsClusterCertificateSelector) em vez de um arquivo PEM de cluster ou usar um arquivo PEM não criptografado.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsCAFile <filename>

Especifica o arquivo .pem que contém a sequência de certificados raiz da autoridade de certificação. Especifique o nome do arquivo .pem usando caminhos relativos ou absolutos.

No macOS ou no Windows, você pode usar um certificado do armazenamento seguro do sistema operacional em vez de um arquivo de chave PEM. Consulte --tlsCertificateSelector. Ao usar o armazenamento seguro, você não precisa, mas também pode, especificar o --tlsCAFile.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsClusterCAFile <filename>

Especifica o arquivo .pem que contém a sequência de certificados raiz da autoridade de certificação usada para validar o certificado apresentado por um cliente que estabelece uma conexão. Especifique o nome do arquivo .pem usando caminhos relativos ou absolutos.

Se --tlsClusterCAFile não especificar o arquivo .pem para validar o certificado de um cliente que está estabelecendo uma conexão, o cluster utilizará o arquivo .pem especificado na opção --tlsCAFile.

--tlsClusterCAFile permite que você use autoridades de certificação separadas para verificar as partes cliente-servidor e servidor-cliente do handshake TLS.

No macOS ou no Windows, você pode usar um certificado do armazenamento seguro do sistema operacional em vez de um arquivo de chave PEM. Consulte --tlsClusterCertificateSelector. Ao usar o armazenamento seguro, você não precisa, mas também pode, especificar o --tlsClusterCAFile.

Requer que --tlsCAFile esteja configurado.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsCertificateSelector <parameter>=<value>

Observação

Disponível no Windows e macOS como alternativa a --tlsCertificateKeyFile.

As opções --tlsCertificateKeyFile e --tlsCertificateSelector são mutuamente exclusivas. Você só pode especificar uma.

Especifica uma propriedade de certificado para selecionar um certificado correspondente do armazenamento de certificados do sistema operacional.

--tlsCertificateSelector aceita um argumento do formato <property>=<value> e a propriedade pode ser uma das abaixo:

Propriedade	Tipo de valor	Descrição
subject	string ASCII	Nome do assunto ou nome comum no certificado
thumbprint	string hexadecimal	Uma sequência de bytes, expressa em hexadecimal usada para identificar uma chave pública pelo seu resumo SHA-1. O thumbprint às vezes é denominado fingerprint.

Ao usar o armazenamento de certificados SSL do sistema, o OCSP (Online Certificate Status Protocol) é usado para validar o status de revogação dos certificados.

Observação

Você não pode usar o comando rotateCertificates ou o método de shell db.rotateCertificates() ao usar net.tls.certificateSelector ou --tlsCertificateSelector definido para thumbprint

--tlsClusterCertificateSelector <parameter>=<value>

Observação

Disponível no Windows e macOS como alternativa a --tlsClusterFile.

As opções --tlsClusterFile e --tlsClusterCertificateSelector são mutuamente exclusivas. Você só pode especificar uma.

Especifica uma propriedade de certificado para selecionar um certificado correspondente do armazenamento de certificados do sistema operacional para usar na autenticação interna.

--tlsClusterCertificateSelector aceita um argumento do formato <property>=<value> e a propriedade pode ser uma das abaixo:

Propriedade	Tipo de valor	Descrição
subject	string ASCII	Nome do assunto ou nome comum no certificado
thumbprint	string hexadecimal	Uma sequência de bytes, expressa em hexadecimal usada para identificar uma chave pública pelo seu resumo SHA-1. O thumbprint às vezes é denominado fingerprint.

mongod / mongos registra um aviso na conexão se o certificado x.509 apresentado expirar dentro de 30 dias a partir do horário do sistema host mongod/mongos.

--tlsCRLFile <filename>

Especifica o arquivo .pem que contém a lista de certificados revogados. Especifique o nome do arquivo .pem usando caminhos relativos ou absolutos.

Observação

• Você não pode especificar um arquivo CRL no macOS. Em vez disso, você pode usar o armazenamento de certificados SSL do sistema, que usa OCSP (Online Certificate Status Protocol) para validar o status de revogação dos certificados. Para usar o armazenamento de certificados SSL do sistema, consulte --tlsCertificateSelector.

• Para verificar a revogação de certificados, o MongoDB enables o uso do OCSP (Protocolo de Status de Certificado Online, Online Certificate Status Protocol na língua inglesa) por padrão, como alternativa à especificação de um arquivo CRL ou ao uso do armazenamento de certificados SSL do sistema.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsAllowConnectionsWithoutCertificates

Por padrão, o servidor ignora a validação do certificado de cliente, a menos que o servidor esteja configurado para utilizar um arquivo CA. Se um arquivo CA for fornecido, as regras a seguir serão aplicadas:

• Para clientes que não fornecem certificados, mongod ou mongos criptografa a conexão TLS/SSL, supondo que a conexão seja bem-sucedida.

• Para clientes que apresentam um certificado, mongos executa a validação do certificado usando a cadeia de certificados raiz especificada por --tlsCAFile e rejeita clientes com certificados inválidos.

Use a opção --tlsAllowConnectionsWithoutCertificates se você tiver uma implantação mista que inclua clientes que não apresentam ou não podem apresentar certificados para o mongos.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsAllowInvalidCertificates

Ignora as verificações de validação de certificados TLS em outros servidores no cluster e permite o uso de certificados inválidos para conexões.

Observação

Se você especificar --tlsAllowInvalidCertificates ou tls.allowInvalidCertificates: true ao usar a autenticação x.509, um certificado inválido será suficiente apenas para estabelecer uma conexão TLS, mas será insuficiente para autenticação.

Ao usar a configuração --tlsAllowInvalidCertificates, o MongoDB registra um aviso sobre o uso do certificado inválido.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsAllowInvalidHostnames

Desabilita a validação dos nomes de host em certificados TLS ao conectar-se a outros membros do conjunto de réplicas ou cluster fragmentado para autenticação entre processos. Isso permite que mongos se conecte a outros membros se os nomes de host em seus certificados não corresponderem ao nome de host configurado.

Para obter mais informações sobre TLS e MongoDB, consulte Configurar o mongod e o mongos para TLS/SSL e Configuração TLS/SSL para clientes .

--tlsDisabledProtocols <protocol(s)>

Impede que um servidor MongoDB em execução com TLS aceite conexões recebidas que usam um protocolo ou protocolos específicos. Para especificar protocolos, use uma lista de protocolos separados por vírgulas.

--tlsDisabledProtocols reconhece os seguintes protocolos: TLS1_0, TLS1_1, TLS1_2 e TLS1_3.

• No macOS, você não pode desativar TLS1_1 e deixar TLS1_0 e TLS1_2 ativados. Você deve desativar pelo menos um dos outros dois, por exemplo, TLS1_0,TLS1_1.

• Para listar vários protocolos, especifique uma lista de protocolos separados por vírgula. Por exemplo TLS1_0,TLS1_1.

• A especificação de um protocolo não reconhecido impede o servidor de iniciar.

• Os protocolos desabilitados especificados substituem qualquer protocolo padrão desabilitado.

O MongoDB desabilita o uso do TLS 1.0 se o TLS 1.1+ estiver disponível no sistema. Para habilitar TLS 1.0 desabilitado, especifique none para --tlsDisabledProtocols.

Os membros dos conjuntos de réplicas e cluster fragmentado devem falar pelo menos um protocolo em comum.

Dica

Veja também:

Não permitir protocolos

--tlsFIPSMode

Direciona mongos para usar o modo FIPS da biblioteca TLS. Seu sistema deve ter uma biblioteca compatível com FIPS para utilizar a opção --tlsFIPSMode.

Observação

O TLS/SSL compatível com FIPS está disponível apenas no MongoDB Enterprise. Consulte Configurar MongoDB para FIPS para obter mais informações.

Opções de auditoria

--auditCompressionMode

Novidades na versão 5.3.

Especifica o modo de compressão da criptografia de logs de auditoria. Você também deve habilitar a criptografia de logs de auditoria usando --auditEncryptionKeyUID ou --auditLocalKeyFile.

--auditCompressionMode pode ser definido para um destes valores:

Valor	Descrição
zstd	Use o algoritmo zstd para comprimir o registro de auditoria.
none (padrão)	Não comprima o registro de auditorias.

Observação

Disponível apenas no MongoDB Enterprise. MongoDB Enterprise e Atlas têm requisitos de configuração diferentes.

--auditDestination

Ativa a auditoria e especifica para onde mongos envia todos os eventos de auditoria.

--auditDestination pode ter um dos seguintes valores:

Valor	Descrição
syslog	Envie os eventos de auditoria para syslog no formato JSON. Não disponível no Windows. As mensagens de auditoria têm um nível de severidade syslog de info e um nível de facilidade de user. O limite de mensagens syslog pode resultar no truncamento de mensagens de auditoria. O sistema de auditoria não detecta o truncamento nem erros na sua ocorrência.
console	Envie os eventos de auditoria para stdout no formato JSON.
file	Envie os eventos de auditar para o arquivo especificado em no formato especificado --auditPath em --auditFormat.

Observação

Disponível somente em MongoDB Enterprise e MongoDB Atlas.

--auditEncryptionKeyUID

Novidades na versão 6.0.

Especifica o identificador exclusivo da chave KMIP (protocolo de interoperabilidade de gerenciamento de chaves) para criptografia de registro de auditorias.

Você não pode usar --auditEncryptionKeyUID e --auditLocalKeyFile juntos.

Observação

Disponível apenas no MongoDB Enterprise. MongoDB Enterprise e Atlas têm requisitos de configuração diferentes.

--auditFormat

Especifica o formato do arquivo de saída para auditoria se --auditDestination for file. A opção --auditFormat pode ter um dos seguintes valores:

Valor	Descrição
JSON	Saída dos eventos de auditar no formato JSON para o arquivo especificado --auditPath em.
BSON	Saída dos eventos de auditar no formato binário BSON para o arquivo especificado em --auditPath.

A impressão de eventos de auditoria em um arquivo no formato JSON degrada mais o desempenho do servidor do que a impressão em um arquivo no formato BSON.

Observação

Disponível somente em MongoDB Enterprise e MongoDB Atlas.

--auditLocalKeyFile

Novidades na versão 5.3.

Especifica o caminho e o nome do arquivo de uma chave de auditoria local para criptografia do registro de auditoria.

Observação

Use --auditLocalKeyFile apenas para testes porque a chave não está protegida. Para protegê-la, use --auditEncryptionKeyUID e um servidor de protocolo de interoperabilidade de gerenciamento de chaves (KMIP) externo.

Você não pode usar --auditLocalKeyFile e --auditEncryptionKeyUID juntos.

Observação

Disponível apenas no MongoDB Enterprise. MongoDB Enterprise e Atlas têm requisitos de configuração diferentes.

--auditPath

Especifica o arquivo de saída para auditoria se --auditDestination tiver valor de file. A opção --auditPath pode levar um nome de caminho completo ou um nome de caminho relativo.

Observação

Disponível somente em MongoDB Enterprise e MongoDB Atlas.

--auditFilter

Especifica o filtro para limitar os tipos de operações que o sistema de auditoria registra. A opção usa uma representação de string de um documento de consulta no formato:

{ <field1>: <expression1>, ... }

O <field> pode ser qualquer campo na mensagem de auditoria, incluindo os campos retornados no documento paramétrico. O <expression> é uma expressão de condição de consulta.

Para especificar um filtro de auditoria, coloque o documento do filtro entre aspas simples para passar o documento como uma string.

Para especificar o filtro de auditoria em um arquivo de configuração, você deve utilizar o formato YAML do arquivo de configuração.

Observação

Disponível somente em MongoDB Enterprise e MongoDB Atlas.

Opções de analisador

--slowms <integer>

Padrão: 100

O limite do tempo de operação lento, em milissegundos. As operações executadas por mais tempo que esse limite são consideradas lentas.

Quando logLevel é definido como 0, o MongoDB registra operações lentas no log de diagnóstico a uma taxa determinada por slowOpSampleRate.

Em configurações logLevel mais altas, todas as operações aparecem no registro de diagnóstico, independentemente da latência.

Para instâncias mongos, afeta somente o registro de diagnóstico e não o analisador, já que o analisador não está disponível em mongos.

--slowOpSampleRate <double>

Padrão: 1.0

A fração de operações lentas que devem ser registradas. --slowOpSampleRate aceita valores entre 0 e 1, inclusive.

Para instâncias mongos, --slowOpSampleRate afeta somente o log de diagnóstico e não o criador de perfil, já que a criação de perfil não está disponível em mongos.

Opções de autenticação e autorização LDAP

--ldapServers <host1>:<port>,<host2>:<port>,...,<hostN>:<port>

Disponível apenas no MongoDB Enterprise.

O servidor LDAP no qual o mongos autentica os usuários ou determina quais ações um usuário está autorizado a executar em um determinado banco de dados. Se o servidor LDAP especificado tiver quaisquer instâncias replicadas, você poderá especificar o host e a porta de cada servidor replicado em uma lista delimitada por vírgula.

Se sua infraestrutura LDAP dividir o diretório LDAP em vários servidores LDAP, especifique um servidor LDAP ou qualquer uma de suas instâncias replicadas no --ldapServers. O MongoDB suporta as seguintes referências LDAP, conforme definido em RFC 4511 4.1.10. Não utilize o --ldapServers para listar todos os servidores LDAP em sua infraestrutura.

Esta configuração pode ser configurada em um mongos executando utilizando setParameter.

Se não for definido, mongos não poderá usar autenticação ou autorização LDAP.

--ldapValidateLDAPServerConfig <boolean>

Disponível no MongoDB Enterprise

Um sinalizador que determina se a instância mongos verifica a disponibilidade do LDAP server(s) como parte de sua inicialização:

• Se o true, a instância do mongos executará a verificação de disponibilidade e somente continuará a iniciar se o servidor LDAP estiver disponível.

• Se false, a instância mongos ignora a verificação de disponibilidade; ou seja, a instância é iniciada mesmo se o servidor LDAP não estiver disponível.

--ldapQueryUser <string>

Disponível apenas no MongoDB Enterprise.

A identidade com a qual o mongos se liga, ao conectar ou executar queries em um servidor LDAP.

Obrigatório apenas se alguma das seguintes afirmações for verdadeira:

• Utilizando autorização LDAP.

• Utilizando uma query LDAP para username transformation.

• O servidor LDAP não permite ligações anônimas

Você deve usar --ldapQueryUser com --ldapQueryPassword.

Se não for definido, mongos não tentará vincular-se ao servidor LDAP.

Esta configuração pode ser configurada em um mongos executando utilizando setParameter.

Observação

As implantações do Windows MongoDB podem utilizar o --ldapBindWithOSDefaults ao invés do --ldapQueryUser e --ldapQueryPassword. Você não pode especificar --ldapQueryUser e --ldapBindWithOSDefaults ao mesmo tempo.

--ldapQueryPassword <string>

Disponível apenas no MongoDB Enterprise.

A senha costumava vincular a um servidor LDAP ao usar o --ldapQueryUser. Você deve usar --ldapQueryPassword com --ldapQueryUser.

Se não for definido, mongos não tentará vincular-se ao servidor LDAP.

Esta configuração pode ser configurada em um mongos executando utilizando setParameter.

Observação

As implantações do Windows MongoDB podem utilizar o --ldapBindWithOSDefaults ao invés do --ldapQueryPassword e --ldapQueryPassword. Você não pode especificar --ldapQueryPassword e --ldapBindWithOSDefaults ao mesmo tempo.

--ldapBindWithOSDefaults <bool>

Padrão: false

Disponível no MongoDB Enterprise apenas para a plataforma Windows.

Permite ao mongos autenticar ou vincular, utilizando suas credenciais de login do Windows ao conectar ao servidor LDAP.

Necessário apenas se:

• Utilizando autorização LDAP.

• Utilizando uma query LDAP para username transformation.

• O servidor LDAP não permite ligações anônimas

Use --ldapBindWithOSDefaults para substituir --ldapQueryUser e --ldapQueryPassword.

--ldapBindMethod <string>

Padrão: simples

Disponível apenas no MongoDB Enterprise.

O método mongos usa para autenticar em um servidor LDAP. Use com --ldapQueryUser e --ldapQueryPassword para fazer a conexão com o servidor LDAP.

--ldapBindMethod suporta os seguintes valores:

• simple - mongos utiliza autenticação simples.

• sasl - mongos utiliza protocolo SASL para autenticação

Se você especificar sasl, poderá configurar os mecanismos SASL disponíveis utilizando o --ldapBindSaslMechanisms. mongos usa como padrão o mecanismo DIGEST-MD5 .

--ldapBindSaslMechanisms <string>

Padrão: DIGEST-MD5

Disponível apenas no MongoDB Enterprise.

Uma lista separada por vírgulas de mecanismos SASL mongos pode utilizar ao autenticar para o servidor LDAP. O mongos e o servidor LDAP devem concordar com pelo menos um mecanismo. O mongos carrega dinamicamente quaisquer bibliotecas de mecanismos SASL instaladas na máquina host no runtime.

Instale e configure as bibliotecas apropriadas para o(s) mecanismo(s) SASL selecionado(s) no host do mongos e no host do servidor LDAP remoto. Seu sistema operacional pode incluir determinadas bibliotecas SASL por padrão. Respeite a documentação associada a cada mecanismo SASL para obter orientação sobre instalação e configuração.

Se estiver usando o mecanismo SASL GSSAPI para uso com a Autenticação Kerberos em Sistemas Autogerenciados, verifique o seguinte para a máquina host mongos :

Linux

• A variável de ambiente KRB5_CLIENT_KTNAME é resolvida para o nome do cliente Linux Keytab Files para a máquina host. Para obter mais informações sobre variáveis de ambiente Kerberos, consulte a documentação do Kerberos.

• O keytab do cliente inclui um User Principal para o mongos usar ao se conectar ao servidor LDAP e executar query LDAP.

Windows

Se estiver conectando a um servidor do Active Directory, a configuração do Windows Kerberos gerará automaticamente um Ticket-Granting-Ticket quando o usuário se conectar ao sistema. Defina --ldapBindWithOSDefaults como true para permitir que mongos use as credenciais geradas ao se conectar ao servidor do Active Directory e executar queries.

Defina --ldapBindMethod como sasl para usar esta opção.

Observação

Para obter uma lista completa dos mecanismos SASL, consulte a lista da IANA . Consulte a documentação do seu serviço LDAP ou Active Directory para identificar os mecanismos SASL compatíveis com o serviço.

MongoDB não é uma fonte de bibliotecas de mecanismo SASL nem a documentação do MongoDB é uma fonte definitiva para instalação ou configuração de qualquer mecanismo SASL. Para documentação e suporte, consulte o fornecedor ou proprietário da biblioteca do mecanismo SASL.

Para obter mais informações sobre SASL, consulte os seguintes recursos:

• Para Linux, consulte a documentação do Cyrus SASL.

• Para Windows, consulte a documentação do Windows SASL.

--ldapTransportSecurity <string>

Padrão: tls

Disponível apenas no MongoDB Enterprise.

Por padrão, o mongos cria uma conexão segura TLS/SSL para o servidor LDAP.

Para implantações do Linux, você deve configurar as Opções de TLS apropriadas no arquivo /etc/openldap/ldap.conf. O gerenciador de pacotes do seu sistema operacional cria esse arquivo como parte da instalação do MongoDB Enterprise, por meio da dependência libldap. Consulte a documentação do TLS Options na documentação ldap.conf OpenLDAP para instruções mais completas.

Para o sistema do Windows, você deve adicionar os certificados CA do servidor LDAP à ferramenta de gerenciamento de certificados do Windows. O nome exato e a funcionalidade da ferramenta podem variar dependendo da versão do sistema operacional. Consulte a documentação da sua versão do Windows para obter mais informações sobre o gerenciamento de certificados.

Configure o --ldapTransportSecurity para none para desabilitar TLS/SSL entre mongos e o servidor LDAP.

Aviso

Configurar o --ldapTransportSecurity para none transmite informações de texto simples e possivelmente credenciais entre o mongos e o servidor LDAP.

--ldapTimeoutMS <long>

Padrão: 10000

Disponível apenas no MongoDB Enterprise.

A quantidade de tempo em milésimos de segundo mongos deve aguardar a resposta de um servidor LDAP a uma solicitação.

Aumentar o valor de --ldapTimeoutMS pode evitar a falha de conexão entre o servidor MongoDB e o servidor LDAP, se a origem da falha for um tempo limite de conexão. Diminuir o valor de --ldapTimeoutMS reduz o tempo que o MongoDB espera por uma resposta do servidor LDAP.

Esta configuração pode ser configurada em um mongos executando utilizando setParameter.

--ldapUserToDNMapping <string>

Disponível apenas no MongoDB Enterprise.

Mapeia o nome de usuário fornecido ao mongos para autenticação para um nome diferenciado (DN) LDAP. Você pode precisar utilizar o --ldapUserToDNMapping para transformar um nome de usuário em um DN LDAP nos seguintes cenários:

• Executando autenticação LDAP com ligação LDAP simples, onde os usuários se autenticam no MongoDB com nomes de usuário que não são DNs LDAP completos.

• Utilizando um LDAP authorization query template que exige um DN.

• Transformar os nomes de usuário de clientes autenticados no Mongo DB usando diferentes mecanismos de autenticação, como x.509 ou Kerberos, em um DN LDAP completo para autorização.

--ldapUserToDNMapping espera uma JSON-string com aspas que represente uma array ordenada de documentos. Cada documento contém uma expressão regular match e um modelo substitution ou ldapQuery usado para transformar o nome de usuário recebido.

Cada documento na array tem o seguinte formato:

{
  match: "<regex>"
  substitution: "<LDAP DN>" | ldapQuery: "<LDAP Query>"
}

Campo	Descrição	Exemplo
match	Uma expressão regular (regex) formatada pelo ECMAScript para corresponder a um nome de usuário fornecido. Cada seção de parênteses representa um grupo de captura regex utilizado pelo substitution ou ldapQuery.	"(.+)ENGINEERING" "(.+)DBA"
substitution	Um modelo de formatação de nome diferenciado (DN) LDAP que converte o nome de autenticação correspondente pelo regex match em um DN LDAP. Cada valor numérico entre colchetes é substituído pelo grupo de captura regex extraído do nome de usuário de autenticação por meio da regex match. O resultado da substituição deve ser um RFC4514 string escapade.	"cn={0},ou=engineering, dc=example,dc=com"
ldapQuery	Um modelo de formatação de query LDAP que insere o nome de autenticação correspondente ao regex match em um URI de query LDAP criptografado respeitando RFC4515 e RFC4516. Cada valor numérico entre colchetes é substituído pelo grupo de captura regex extraído do nome de usuário de autenticação por meio da expressão match. O mongos executa a query no servidor LDAP para recuperar o nome diferenciado LDAP do usuário autenticado. mongos exige exatamente um resultado retornado para que a transformação seja bem-sucedida, ou mongos ignora essa transformação.	"ou=engineering,dc=example, dc=com??one?(user={0})"

Observação

Uma explicação da RFC4514, RFC4515, RFC4516, ou queries LDAP estão fora do escopo da documentação do MongoDB. Revise o RFC diretamente ou use o recurso LDAP da sua preferência.

Para cada documento na array, você deve usar substitution ou ldapQuery. Você não pode especificar ambos no mesmo documento.

Ao executar a autenticação ou autorização, mongos etapas através de cada documento na array no pedido fornecido, verificando o nome de usuário da autenticação no filtro match. Se uma correspondência for localizada, o mongos aplicará a transformação e utilizará a saída para autenticar o usuário. mongos não verifica os documentos restantes na array.

Se o documento fornecido não corresponder ao nome de autenticação fornecido, mongos continuará na lista de documentos para encontrar correspondências adicionais. Se nenhuma correspondência for encontrada em nenhum documento ou se a transformação descrita no documento falhar, mongos retornará um erro.

mongos também retorna um erro se uma das transformações não puder ser avaliada devido a falhas de rede ou de autenticação no servidor LDAP. mongos rejeita a solicitação de conexão e não verifica os documentos restantes no array.

A partir do MongoDB 5.0, --ldapUserToDNMapping aceita uma string vazia "" ou uma array vazia [ ] no lugar de um documento de mapeamento. Se fornecer uma string vazia ou uma array vazia para --ldapUserToDNMapping, o MongoDB mapeará o nome de usuário autenticado como o DN LDAP. Anteriormente, fornecer um documento de mapeamento vazio causaria falha no mapeamento.

Exemplo

O seguinte mostra dois documentos de transformação. O primeiro documento corresponde a qualquer cadeia de caracteres que termine em @ENGINEERING, colocando qualquer coisa que preceda o sufixo em um grupo de captura de regex. O segundo documento corresponde a qualquer cadeia de caracteres que termine em @DBA, colocando qualquer coisa que preceda o sufixo em um grupo de captura de regex.

Importante

Você deve passar a array para --ldapUserToDNMapping como uma string.

"[
   {
      match: "(.+)@ENGINEERING.EXAMPLE.COM",
      substitution: "cn={0},ou=engineering,dc=example,dc=com"
   },
   {
      match: "(.+)@DBA.EXAMPLE.COM",
      ldapQuery: "ou=dba,dc=example,dc=com??one?(user={0})"
   }
]"

Um usuário com o nome de usuário alice@ENGINEERING.EXAMPLE.COM corresponde ao primeiro documento. O grupo de captura regex {0} corresponde à cadeia de caracteres alice. A saída resultante é o DN "cn=alice,ou=engineering,dc=example,dc=com".

Um usuário com nome de usuário bob@DBA.EXAMPLE.COM corresponde ao segundo documento. O grupo de captura regex {0} corresponde à cadeia de caracteres bob. A saída resultante é a query LDAP "ou=dba,dc=example,dc=com??one?(user=bob)". mongos executa esta query no servidor LDAP, retornando o resultado "cn=bob,ou=dba,dc=example,dc=com".

Se --ldapUserToDNMapping estiver desmarcado, o mongos não aplicará nenhuma transformação no nome de usuário ao tentar autenticar ou autorizar um usuário no servidor LDAP.

Essa configuração pode ser definida em um mongos em execução usando o comando setParameter banco de dados.

Opções adicionais

--ipv6

Habilita o suporte a IPv6. mongos desabilita o suporte a IPv6 por padrão.

A configuração do --ipv6 não direciona o mongos para escutar em nenhum endereço ou interface IPv6 local. Para configurar o mongos para escutar em uma interface IPv6, você tem as seguintes opções:

• Configure --bind_ip com um ou mais endereços IPv6 ou nomes de host que resolvam para endereços IPv6, ou

• Definir --bind_ip_all como true.