mongos

Opciones principales

--help, -h

Devuelve información sobre las opciones y el uso de mongos.

--version

Devuelve el número de la versión mongos.

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

Especifica un archivo de configuración para las opciones de configuración en tiempo de ejecución. El archivo de configuración es el método preferido para la configuración en tiempo de ejecución de mongos. Estas opciones son equivalentes a las opciones de configuración de la línea de comandos. Consulta Opciones del archivo de configuración autogestionada para obtener más información.

Asegúrese de que el archivo de configuración utilice codificación ASCII. La instancia mongos no admite archivos de configuración con la codificación no ASCII, incluido UTF-8.

--configExpand <none|rest|exec>

Por defecto: ninguno

Permite usar Directivas de expansión en archivos de configuración. Las directivas de expansión permiten establecer valores de origen externo para las opciones del archivo de configuración.

--configExpand ofrece soporte para las siguientes directivas de expansión:

Valor	Descripción
none	Predeterminado. mongos no expande las directrices de expansión. mongos no se inicia si alguna configuración de archivo utiliza directivas de expansión.
rest	mongos expande __rest directivas de expansión al analizar el archivo de configuración.
exec	mongos expande __exec directivas de expansión al analizar el archivo de configuración.

Puede especificar varias directivas de expansión como una lista separada por comas, por ejemplo: rest, exec. Si el archivo de configuración contiene directivas de expansión no especificadas en --configExpand, el mongos devuelve un error y termina.

Consulte Valores de archivos de configuración de origen externo para implementaciones autoadministradas para obtener más información sobre las directivas de expansión de los archivos de configuración.

--verbose, -v

Aumenta la cantidad de reportes internos devueltos en la salida estándar o en las entradas de registro. Aumente el nivel de verbosidad con el formulario -v al incluir la opción varias veces, por ejemplo: -vvvvv.

--quiet

Ejecuta mongos en modo silencioso que intenta limitar la cantidad de salida.

Esta opción suprime:

• resultado de los comandos de base de datos

• Actividad de replicación

• eventos de aceptación de conexión

• eventos de cierre de conexión

--port <port>

Por defecto: 27017

El puerto TCP en el que la instancia mongos escucha las conexiones de los clientes.

Modificado en la 6.0.12 versión: La --port opción acepta un rango de valores entre 0 y.65535 Al establecer el puerto en, se 0 configura mongos para usar un puerto arbitrario asignado por el sistema operativo.

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

Por defecto: localhost

Los nombres de host, las direcciones IP y las rutas completas de los sockets de dominio Unix en los que mongos debería escuchar las conexiones de los clientes. Puedes conectar mongos a cualquier interfaz. Para vincularse a varias direcciones, introduce una lista de valores separados por comas.

Ejemplo

localhost,/tmp/mongod.sock

Se puede especificar tanto direcciones IPv4 como IPv6, o nombres de host que se resuelvan en una dirección IPv4 o IPv6.

Ejemplo

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

Nota

Si especifica una dirección IPv6 o un nombre de host que se resuelva a una dirección IPv6 para --bind_ip, debe empezar mongos con --ipv6 para habilitar el soporte IPv6. Especificar una dirección IPv6 en --bind_ip no habilita el soporte para IPv6.

Si se especifica una dirección IPv6 de enlace local(),fe80::/10 debe agregar el índice de zona a esa dirección (esfe80::<address>%<adapter-name> decir,).

Ejemplo

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

Importante

Para evitar actualizaciones de configuración debido a cambios en las direcciones IP, utilice nombres de host DNS en lugar de direcciones IP. Es particularmente importante usar un nombre de host DNS en lugar de una dirección IP al configurar miembros de set de réplicas o miembros de clústeres particionados.

Utiliza nombres de host en lugar de direcciones IP para configurar clústeres en un horizonte de red dividido. A partir de MongoDB 5.0, los nodos que solo están configurados con una dirección IP no pasan la validación de inicio y no se inician.

Advertencia

Antes de vincular una dirección IP que no sea local (por ejemplo, de acceso público), asegúrese de proteger su clúster contra accesos no autorizados. Para obtener una lista completa de recomendaciones de seguridad, consulte la Lista de verificación de seguridad para implementaciones autogestionadas. Como mínimo, considere habilitar la autenticación y reforzar la infraestructura de red.

Para obtener más información sobre la vinculación de IP, consulta la documentación de Vinculación de IP en implementaciones autogestionadas.

Para vincularse a todas las direcciones IPv4, introduzca 0.0.0.0.

Para conectarse a todas las direcciones IPv4 e IPv6, introduzca ::,0.0.0.0 o un asterisco "*" (escriba el asterisco entre comillas para evitar la expansión del patrón de nombre de archivo). O bien, utilice la configuración net.bindIpAll.

Nota

• --bind_ip y --bind_ip_all son mutuamente excluyentes. Especificar ambas opciones hace que mongos genere un error y se detenga.

• La opción de línea de comandos --bind anula la configuración del archivo net.bindIp.

--bind_ip_all

Si se especifica, la instancia mongos se enlaza a todas las direcciones IPv4 (es decir, 0.0.0.0). Si mongos comienza con --ipv6, --bind_ip_all también se enlaza a todas las direcciones IPv6 (es decir, ::).

mongos Solo admite IPv6 si se inicia con.--ipv6 --bind_ip_all Especificar por sí solo no6 habilita la compatibilidad con IPv.

Advertencia

Antes de vincular una dirección IP que no sea local (por ejemplo, de acceso público), asegúrese de proteger su clúster contra accesos no autorizados. Para obtener una lista completa de recomendaciones de seguridad, consulte la Lista de verificación de seguridad para implementaciones autogestionadas. Como mínimo, considere habilitar la autenticación y reforzar la infraestructura de red.

Para obtener más información sobre la vinculación de IP, consulta la documentación de Vinculación de IP en implementaciones autogestionadas.

Si no, puede establecer la opción --bind_ip en ::,0.0.0.0 o en un asterisco "*" (escriba el asterisco entre comillas para evitar la expansión del patrón de nombre de archivo).

Nota

--bind_ip y --bind_ip_all son mutuamente excluyentes. Es decir, puede especificar uno u otro, pero no ambos.

--listenBacklog <number>

Por defecto: constante SOMAXCONN del sistema de destino

La cantidad máxima de conexiones que puede haber en la cola de escucha.

Advertencia

Se debe consultar la documentación del sistema local para entender las limitaciones y los requisitos de configuración antes de usar este parámetro.

Importante

Para prevenir un comportamiento indefinido, se especifica un valor para este parámetro entre 1 y la constante SOMAXCONN del sistema local.

El valor predeterminado para el listenBacklog parámetro se establece SOMAXCONN enSOMAXCONN el momento de la compilación en la constante del sistema de destino. es el valor válido máximo que se documenta para el parámetro backlog en la llamada del sistema de escucha.

Algunos sistemas pueden interpretar SOMAXCONN de forma simbólica y otros numéricamente. El listen backlog real aplicado en la práctica puede diferir de cualquier interpretación numérica de la constante SOMAXCONN o argumento de --listenBacklog, y también puede estar limitado por configuraciones del sistema como net.core.somaxconn en Linux.

Pasar un valor para el parámetro listenBacklog que exceda la constante SOMAXCONN del sistema local es, según la letra de las normas, un comportamiento indefinido. Los valores más altos pueden ser truncados silenciosamente como enteros, ser ignorados, provocar un consumo inesperado de recursos o tener otras consecuencias adversas.

En sistemas con cargas de trabajo que presentan picos de conexión, para los cuales se sabe empíricamente que el sistema local puede respetar valores más altos para el parámetro backlog que la SOMAXCONN constante, configurar el listenBacklog parámetro en un valor más alto puede reducir la latencia de la operación según lo observado por el cliente al reducir la cantidad de conexiones que se ven obligadas a entrar en un estado de retroceso.

--maxConns <number>

El número máximo de conexiones simultáneas que mongos acepta. Esta configuración no tiene efecto si es superior al umbral máximo de seguimiento de conexión configurado por el sistema operativo.

No asignes un valor demasiado bajo para esta opción, o encontrarás errores durante la operación normal de la aplicación.

Esto es particularmente útil para un mongos si se tiene un cliente que crea múltiples conexiones y permite que expiren en lugar de cerrarlas.

En este caso, establezca maxIncomingConnections en un valor ligeramente superior al número máximo de conexiones que el cliente crea o al tamaño máximo del pool de conexiones.

Esta configuración evita que mongos provoque picos de conexión en los fragmentos individuales. Estos picos pueden interrumpir el funcionamiento y la asignación de memoria del clúster fragmentado.

--logpath <path>

Se debe enviar toda la información de registro de diagnóstico a una entrada de registro en lugar de a la salida estándar o al sistema syslog del host. MongoDB crea la entrada de registro en la ruta que se especifique.

Por defecto, MongoDB moverá cualquier entrada de registro existente en lugar de sobrescribirlo. Para añadir a la entrada de registro en su lugar, configurar la opción --logappend.

--syslog

Envía toda la salida de registro al sistema syslog del host en lugar de a la salida estándar o a una entrada de registro (--logpath).

La opción --syslog no es compatible con Windows.

Advertencia

El demonio syslog genera marcas de tiempo cuando registra un mensaje, no cuando MongoDB emite el mensaje. Esto puede llevar a marcas de tiempo engañosas en las entradas de registro, especialmente cuando el sistema está bajo una carga pesada. Recomendamos utilizar la opción --logpath para los sistemas de producción a fin de garantizar marcas de tiempo precisas.

MongoDB incluye el componente en sus mensajes de registros para syslog.

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

--syslogFacility <string>

Por defecto: usuario

Especifica el nivel de instalación utilizado al registrar mensajes en syslog. El valor que especifique debe ser compatible con la implementación de syslog de su sistema operativo. Para usar esta opción, debe activar la opción --syslog.

--logappend

Se anexan nuevas entradas al final del archivo de registro existente cuando la instancia mongos se reinicia. Sin esta opción, mongod realizará una copia de seguridad del registro existente y creará un nuevo archivo.

--logRotate <string>

Por defecto: renombrar

Determina el comportamiento del comando logRotate al rotar el registro del servidor y/o el registro para auditoría. Especifique ya searename o reopen:

• rename Renombra la entrada de registro.

• reopen Cierra y vuelve a abrir la entrada de registro siguiendo el comportamiento típico de rotación de registros en Linux/Unix. Utilice reopen cuando use la utilidad de rotación de registros en Linux/Unix logrotate para evitar la pérdida de registros.

  Si especifica reopen, también debe usar --logappend.

--redactClientLogData

Disponible solamente en MongoDB Enterprise.

Un mongos que se ejecuta con --redactClientLogData redacta cualquier mensaje que acompaña a un evento de registro determinado antes de registrarlo. Esto impide que el mongos escriba datos potencialmente sensibles almacenados en la base de datos en el registro de diagnóstico. Los metadatos, como los códigos de error u operación, las cantidades de líneas y los nombres de los archivos fuente, siguen siendo visibles en los registros.

Utilice --redactClientLogData en conjunto con Cifrado en Reposo y TLS/SSL (Cifrado de Transporte) para ayudar al cumplimiento de los requisitos regulatorios.

Por ejemplo, una implementación de MongoDB podría almacenar Información Personal Identificable (PII) en una o más colecciones. mongos registra eventos como los relacionados con operaciones CRUD, metadatos de particionado, etc. Es posible que mongos pueda exponer PII como parte de estas operaciones de registro. Un mongos que se ejecuta con --redactClientLogData remueve cualquier mensaje que acompañe a estos eventos antes de que se envíe al registro, y elimina efectivamente la PII.

El diagnóstico en un mongos que funciona con --redactClientLogData puede ser más complicado debido a la falta de datos relacionados con un evento de registro. Consulte la página del manual de registro de procesos para ver un ejemplo del efecto de --redactClientLogData en la salida de los registros.

En un mongos en ejecución, utilice setParameter con el parámetro redactClientLogData para configurar esta opción.

--timeStampFormat <string>

Default: iso8601-local

El formato de hora para las marcas de tiempo en los mensajes de registro. Especifique uno de los siguientes valores:

Valor	Descripción
iso8601-utc	Muestra las marcas de tiempo en Tiempo Universal Coordinado (UTC) en el formato ISO-8601. Por ejemplo, para Nueva York al inicio del Epoch: 1970-01-01T00:00:00.000Z
iso8601-local	Muestra las marcas de tiempo en la hora local en el formato ISO-8601. Por ejemplo, para Nueva York al inicio del Epoch: 1969-12-31T19:00:00.000-05:00

Nota

--timeStampFormat ya no es compatible con ctime. Un ejemplo de una fecha con formato ctime es: Wed Dec 31 18:17:54.811.

--pidfilepath <path>

Especifica una ubicación de archivo para almacenar el ID de proceso (PID) del proceso mongos. El usuario que ejecuta el proceso mongod o mongos debe poder escribir en esta ruta. Si no se especifica la opción --pidfilepath, el proceso no crea un archivo PID. Esta opción generalmente solo es útil en combinación con la opción --fork.

Nota

Linux

En Linux, la gestión de archivos PID generalmente es responsabilidad del sistema de inicialización de la distribución: usualmente un archivo de servicio en el directorio /etc/init.d, o un archivo de unidad systemd registrado con systemctl. Se debe usar solo la opción --pidfilepath si no se usa uno de estos sistemas de inicialización. Para obtener más información, se debe consultar la Guía de instalación correspondiente al sistema operativo.

Nota

macOS

En macOS, la gestión de archivos PID generalmente la brew realiza. Use la --pidfilepath opción solo si no usa brew en su sistema macOS. Para más información, consulte la Guía de instalación correspondiente a su sistema operativo.

--keyFile <file>

Especifica la ruta a un archivo de claves que almacena el secreto compartido que las instancias de MongoDB utilizan para autenticarse entre sí en un clúster particionado o Set de réplicas. --keyFile implica client authorization. Consulta Autenticación interna/autogestionada de miembros para obtener más información.

Los archivos de claves para la autenticación interna de miembros utilizan el formato YAML para permitir múltiples claves en un archivo de claves. El formato YAML acepta:

• Una string de clave única (igual que en versiones anteriores)

• Una secuencia de cadenas clave

El formato YAML es compatible con los archivos de claves de una sola clave existentes que utilizan el formato de archivo de texto.

--setParameter <options>

Especifica uno de los parámetros de MongoDB descritos en Parámetros de MongoDB Server para una implementación autogestionada. Puedes especificar múltiples campos setParameter.de

--noscripting

Se desactiva el motor de scripts. Cuando está deshabilitado, no se pueden utilizar operaciones que realicen la ejecución del código JavaScript en el lado del servidor, como el operador del query $where, el comando mapReduce, $accumulator y $function.

Si no utiliza estas operaciones, desactive el script del lado del servidor.

--nounixsocket

Desactiva la escucha en el socket de dominio UNIX. --nounixsocket solo se aplica a sistemas basados en Unix.

El proceso mongos siempre escucha en el socket UNIX a menos que se cumpla alguna de las siguientes condiciones:

• --nounixsocket está configurado

• net.bindIp no está configurado

• net.bindIp no especifica localhost ni su dirección IP asociada

mongos instalados desde los paquetes oficiales de instalación de MongoDB Community Edition en Debian y de instalación de MongoDB Community Edition en Red Hat o CentOS tienen la configuración bind_ip establecida en 127.0.0.1 por defecto.

--unixSocketPrefix <path>

Por defecto: /tmp

La ruta para el socket UNIX. --unixSocketPrefix se aplica únicamente a sistemas basados en Unix.

Si esta opción no tiene valor, el proceso mongos crea un socket con /tmp como prefijo. MongoDB crea y escucha en un socket UNIX a menos que una de las siguientes condiciones sea verdadera:

• net.unixDomainSocket.enabled es false

• --nounixsocket está configurado

• net.bindIp no está configurado

• net.bindIp no especifica localhost ni su dirección IP asociada

--filePermissions <path>

Por defecto: 0700

Establece los permisos para el archivo de socket de dominio UNIX.

--filePermissions se aplica únicamente a sistemas basados en Unix.

--fork

Activa el modo demonio que ejecuta el proceso mongos en segundo plano. La opción --fork no es compatible con Windows.

Por defecto, mongos no se ejecuta como demonio. Debe gestionar mongos como un demonio mediante --fork o un proceso de control que gestione la demonización, como upstart o systemd.

Para utilizar la opción --fork, es necesario que configure la salida de registros para el mongos con una de las siguientes opciones:

• --logpath

• --syslog

--transitionToAuth

Permite al mongos aceptar y crear conexiones autenticadas y no autenticadas hacia y desde otras instancias de mongod y mongos en la implementación. Se utiliza para realizar la transición continua de sets de réplicas o clústeres particionados de una configuración sin autenticación a autenticación interna. Requiere especificar un mecanismo de autenticación interno como --keyFile.

Por ejemplo, si se utilizan keyfiles para autenticación interna, el mongos crea una conexión autenticada con cualquier mongod o mongos en la implementación utilizando un keyfile coincidente. Si los mecanismos de seguridad no coinciden, el mongos utiliza una conexión no autenticada en su lugar.

Un mongos que se ejecuta con --transitionToAuth no aplica controles de acceso de usuarios. Los usuarios pueden conectarse a su implementación sin ninguna verificación de control de acceso y realizar operaciones administrativas y de lectura y escritura.

Nota

Un mongos que se ejecuta con autenticación interna y sin --transitionToAuth requiere que los clientes se conecten con controles de acceso de usuario. Actualice los clientes para conectarse a mongos con el usuario apropiado antes de reiniciar mongos sin --transitionToAuth.

--networkMessageCompressors <string>

Default: snappy,zstd,zlib

Especifica los compresores por defecto que se utilizarán para la comunicación entre esta instancia mongos y:

• otros miembros del clúster particionado

• mongosh

• controladores con soporte para el formato de mensaje OP_COMPRESSED.

MongoDB es compatible con los siguientes compresores:

• rápido

• zlib

• zstd

Tanto mongod como las instancias de mongos tienen por defecto los compresores snappy,zstd,zlib, en ese orden.

Para desactivar la compresión de red, establezca el valor en disabled.

Importante

Los mensajes se comprimen cuando ambas partes permiten la compresión de red. De lo contrario, los mensajes entre las partes no se comprimen.

Si especificas varios compresores, el orden en el que enumeres los compresores importa, al igual que el iniciador de la comunicación. Por ejemplo, si mongosh especifica los siguientes compresores de red zlib,snappy y mongod especifica snappy,zlib, los mensajes entre mongosh y mongod utiliza zlib.

Si las partes no comparten al menos un compresor común, los mensajes entre las partes no se comprimen. Por ejemplo, si mongosh especifica el compresor de red zlib y mongod especifica snappy, los mensajes entre mongosh y mongod no se comprimen.

--timeZoneInfo <path>

La ruta completa desde la cual cargar la base de datos de la zona horaria. Si no se proporciona esta opción, MongoDB utiliza su base de datos de zona horaria incorporada.

El archivo de configuración incluido con los paquetes de Linux y macOS establece la ruta de la base de datos de la zona horaria en /usr/share/zoneinfo por defecto.

La base de datos de zonas horarias incorporada es una copia de la base de datos de zonas horarias Olson/IANA. Se actualiza junto con las versiones de MongoDB, pero el ciclo de lanzamiento de la base de datos de zonas horarias es diferente al ciclo de lanzamiento de MongoDB. La versión más reciente de la base de datos de zonas horarias está disponible en nuestro sitio de descarga.

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

Advertencia

MongoDB utiliza la biblioteca de terceros timelib para proporcionar conversiones precisas entre zonas horarias. Debido a una actualización reciente, timelib podía crear conversiones de zonas horarias inexactas en las versiones anteriores de MongoDB.

Para vincular explícitamente a la base de datos de zona horaria en versiones de MongoDB anteriores a 5.0, descarga la base de datos de zona horaria. y utilice el parámetro timeZoneInfo.

--outputConfig

Envía las mongos opciones de configuración de la instancia, con formato YAML, a stdout y sale de la mongos instancia. Para las opciones de configuración que utilizan valores de archivo de configuración de origen externo para implementaciones autogestionadas, --outputConfig devuelve el valor resuelto de dichas opciones.

Advertencia

Esto puede incluir cualquier contraseña configurada o secretos previamente ocultos a través de la fuente externa.

Para ejemplos de uso, consulte:

• Genere el archivo de configuración con los valores resueltos de la directiva de expansión

• Convierta las opciones de línea de comandos autogestionadas a YAML

Opciones de clúster fragmentado

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

Especifica los servidores de configuración para el clúster fragmentado.

Los servidores de configuración para clústeres fragmentados se implementan como un set de réplicas. Los servidores de configuración del set de réplicas deben ejecutar el motor de almacenamiento WiredTiger.

Especifica el nombre del set de réplicas del servidor de configuración y el nombre de host y el puerto de al menos uno de los nodos del set de réplicas del servidor de configuración.

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

Las mongos instancias para el clúster deben especificar el mismo nombre del set de réplicas del servidor de configuración, pero pueden especificar el nombre de host y el puerto de diferentes miembros del set de réplicas.

--localThreshold

Por defecto: 15

Especifica el tiempo de ping, en milisegundos, que mongos utiliza para determinar qué miembros del Set de réplicas secundarias deben recibir las operaciones de lectura de los clientes. El valor por defecto de 15 corresponde al valor por defecto en todos los controladoresdel cliente.

Cuando mongos recibe una solicitud que permite lecturas a miembros secundarios, este:

• Encuentra el nodo del conjunto con el tiempo de ping más bajo.

• Construye una lista de nodos del set de réplicas que están dentro de un tiempo de ping de 15 milisegundos del nodo adecuado más cercano del set.

  Si se especifica un valor para la opción--localThreshold, mongos construye la lista de miembros de réplica que están dentro de la latencia permitida por este valor.

• Selecciona un nodo al azar de esta lista para leer.

El tiempo de ping utilizado para un nodo comparado por la configuración --localThreshold es un promedio móvil de tiempos de ping recientes, calculado como máximo cada 10 segundos. Como resultado, algunas consultas pueden alcanzar a miembros por encima del umbral hasta que el mongos recalcule el promedio.

Consulta la sección Preferencia de lectura para sets de réplicas de la documentación sobre preferencia de lectura para obtener más información.

Opciones de TLS

--tlsMode <mode>

Habilita el uso de TLS para todas las conexiones de red. El argumento de la opción --tlsMode puede ser uno de los siguientes:

Valor	Descripción
disabled	El servidor no usa TLS.
allowTLS	Las conexiones entre servidores no emplean TLS. Para las conexiones entrantes, el servidor acepta tanto TLS como conexiones no TLS.
preferTLS	Las conexiones entre servidores utilizan TLS. Para las conexiones entrantes, el servidor acepta tanto TLS como conexiones no TLS.
requireTLS	El servidor utiliza y acepta únicamente conexiones cifradas mediante TLS.

Si no se especifica --tlsCAFile o tls.CAFile, y no estás utilizando la autenticación X.509, debes establecer el parámetro tlsUseSystemCA en true. Esto hace que MongoDB utilice el almacén de certificados de CA de todo el sistema al conectarse a un servidor con TLS activado.

Si se utiliza la autenticación X.509, --tlsCAFile o tls.CAFile deben especificarse a menos que se utilice --tlsCertificateSelector.

Para más información sobre TLS y MongoDB, consulta Configurar mongod y mongos para TLS/SSL y Configuración de TLS/SSL para clientes .

--tlsCertificateKeyFile <filename>

Nota

En macOS o Windows, puedes usar un certificado del almacén seguro del sistema operativo en lugar de especificar un archivo PEM. Consulta --tlsCertificateSelector.

Especifica el archivo .pem que contiene tanto el certificado TLS como la clave.

• En Linux/BSD, debes especificar --tlsCertificateKeyFile cuando TLS está habilitado.

• En Windows o macOS, debes especificar --tlsCertificateKeyFile o --tlsCertificateSelector cuando TLS está activado.

Para más información sobre TLS y MongoDB, consulta Configurar mongod y mongos para TLS/SSL y Configuración de TLS/SSL para clientes .

--tlsCertificateKeyFilePassword <value>

Especifica la contraseña para descifrar el archivo de clave del certificado (es decir, --tlsCertificateKeyFile). Utilice la opción --tlsCertificateKeyFilePassword solo si el archivo de clave del certificado está cifrado. En todos los casos, el mongos elimina la contraseña de todos los registros y reportes de salida.

• En Linux/BSD, si la llave privada en el archivo PEM está cifrada y no se especifica la opción --tlsCertificateKeyFilePassword, MongoDB solicitará una frase de contraseña. Se debe consultar la frase de contraseña del certificado TLS/SSL.

• En macOS o Windows, si la llave privada en el archivo PEM está cifrada, se debe especificar explícitamente la opción --tlsCertificateKeyFilePassword. Alternativamente, se puede utilizar un certificado del almacén seguro del sistema (consultar --tlsCertificateSelector) en lugar de un archivo PEM o utilizar un archivo PEM sin cifrar.

Para más información sobre TLS y MongoDB, consulta Configurar mongod y mongos para TLS/SSL y Configuración de TLS/SSL para clientes .

--clusterAuthMode <option>

Por defecto: archivo de clave

El modo de autenticación utilizado para la autenticación del clúster. Si utilizas autenticación interna de X.509, especifícalo aquí. Esta opción puede tener uno de los siguientes valores:

Valor	Descripción
keyFile	Utilice un archivo de clave para la autenticación. Acepte únicamente archivos de clave.
sendKeyFile	Para actualizaciones continuas. Envía un archivo de claves para la autenticación, pero acepta tanto archivos de claves como certificados X.509.
sendX509	Para actualizaciones continuas. Envía el certificado X.509 para la autenticación, pero acepta tanto archivos de claves como certificados X.509.
x509	Opción recomendada. Envía el certificado X.509 para la autenticación y acepta solo certificados X.509.

Si no se especifica --tlsCAFile o tls.CAFile, y no estás utilizando la autenticación X.509, debes establecer el parámetro tlsUseSystemCA en true. Esto hace que MongoDB utilice el almacén de certificados de CA de todo el sistema al conectarse a un servidor con TLS activado.

Si se utiliza la autenticación X.509, --tlsCAFile o tls.CAFile deben especificarse a menos que se utilice --tlsCertificateSelector.

Para más información sobre TLS y MongoDB, consulta Configurar mongod y mongos para TLS/SSL y Configuración de TLS/SSL para clientes .

--tlsClusterFile <filename>

Nota

En macOS o Windows, puedes usar un certificado del almacén seguro del sistema operativo en lugar de un archivo PEM. Consulta --tlsClusterCertificateSelector.

Especifica el archivo .pem que contiene el archivo de llave de certificado X.509 para la autenticación de membresía del clúster o el set de réplicas.

Si --tlsClusterFile no especifica el archivo .pem para la autenticación interna del clúster o la alternativa --tlsClusterCertificateSelector, el clúster utiliza el archivo .pem especificado en la opción --tlsCertificateKeyFile o el certificado devuelto por el --tlsCertificateSelector.

Si se utiliza la autenticación X.509, --tlsCAFile o tls.CAFile deben especificarse a menos que se utilice --tlsCertificateSelector.

mongod / mongos registra una advertencia en la conexión si el certificado X.509 presentado expira dentro de los 30 días del tiempo del sistema host mongod/mongos.

Para más información sobre TLS y MongoDB, consulta Configurar mongod y mongos para TLS/SSL y Configuración de TLS/SSL para clientes .

--tlsClusterPassword <value>

Especifica la contraseña para descifrar el archivo de clave de certificado X.509 especificado con --tlsClusterFile. Utiliza la opción --tlsClusterPassword solo si el archivo de clave del certificado está cifrado. En todos los casos, el mongos elimina la contraseña de todos los registros y reportes de salida.

• En Linux/BSD, si la llave privada en el archivo X.509 está cifrada y no especificas la opción --tlsClusterPassword, MongoDB solicita una frase de contraseña. Consulta Frase de contraseña del certificado TLS/SSL.

• En macOS o Windows, si la llave privada en el archivo X.509 está cifrada, debes especificar explícitamente la opción --tlsClusterPassword. Alternativamente, puedes utilizar un certificado del almacén seguro del sistema (consulta --tlsClusterCertificateSelector) en lugar de un archivo PEM del clúster o utilizar un archivo PEM sin cifrar.

Para más información sobre TLS y MongoDB, consulta Configurar mongod y mongos para TLS/SSL y Configuración de TLS/SSL para clientes .

--tlsCAFile <filename>

Especifica el archivo .pem que contiene la cadena de certificados raíz de la Autoridad Certificadora. Especifica el nombre del archivo .pem con rutas relativas o absolutas.

En macOS o Windows, puede usar un certificado del almacén seguro del sistema operativo en lugar de un archivo de llave PEM. Consulte --tlsCertificateSelector. Cuando utilice el almacén seguro, no necesita, pero puede, también especificar el --tlsCAFile.

Para más información sobre TLS y MongoDB, consulta Configurar mongod y mongos para TLS/SSL y Configuración de TLS/SSL para clientes .

--tlsClusterCAFile <filename>

Especifica el archivo .pem que contiene la cadena de certificados raíz de la Autoridad de Certificación utilizada para validar el certificado presentado por un cliente que establece una conexión. Especifica el nombre del archivo .pem utilizando rutas relativas o absolutas.

Si --tlsClusterCAFile no especifica el archivo .pem para validar el certificado de un cliente que establece una conexión, el clúster utiliza el archivo .pem especificado en la opción --tlsCAFile.

--tlsClusterCAFile le permite utilizar autoridades de certificación independientes para verificar las partes del protocolo de enlace TLS de cliente a servidor y de servidor a cliente.

En macOS o Windows, puede usar un certificado del almacén seguro del sistema operativo en lugar de un archivo de llave PEM. Consulte --tlsClusterCertificateSelector. Cuando utilice el almacén seguro, no necesita, pero puede, también especificar el --tlsClusterCAFile.

Requiere que --tlsCAFile esté configurado.

Para más información sobre TLS y MongoDB, consulta Configurar mongod y mongos para TLS/SSL y Configuración de TLS/SSL para clientes .

--tlsCertificateSelector <parameter>=<value>

Nota

Disponible en Windows y macOS como alternativa a --tlsCertificateKeyFile.

Las opciones --tlsCertificateKeyFile y --tlsCertificateSelector son mutuamente excluyentes. Solo puedes especificar uno.

Especifica una propiedad de certificado para seleccionar un certificado coincidente de los almacenes de certificados del sistema operativo.

--tlsCertificateSelector acepta un argumento en el formato <property>=<value> donde la propiedad puede ser una de las siguientes:

Propiedad	Tipo de valor	Descripción
subject	string ASCII	Nombre del sujeto o nombre común en el certificado
thumbprint	cadena hexadecimal	Una secuencia de bytes, expresada en hexadecimal, utilizada para identificar una llave pública mediante su resumen SHA-1. El thumbprint a veces se conoce como fingerprint.

Al utilizar el almacén de certificados SSL del sistema, se emplea OCSP (Protocolo de estado de certificados en línea) para validar el estado de revocación de los certificados.

Nota

No puedes usar el comando rotateCertificates o el método shell db.rotateCertificates() cuando utilizas net.tls.certificateSelector o --tlsCertificateSelector configurado en thumbprint

--tlsClusterCertificateSelector <parameter>=<value>

Nota

Disponible en Windows y macOS como alternativa a --tlsClusterFile.

--tlsClusterFile y --tlsClusterCertificateSelector son opciones mutuamente excluyentes. Solo puedes especificar uno.

Se especifica una propiedad del certificado para seleccionar un certificado coincidente del almacén de certificados del sistema operativo para utilizar en la autenticación interna.

--tlsClusterCertificateSelector acepta un argumento en el formato <property>=<value> donde la propiedad puede ser una de las siguientes:

Propiedad	Tipo de valor	Descripción
subject	string ASCII	Nombre del sujeto o nombre común en el certificado
thumbprint	cadena hexadecimal	Una secuencia de bytes, expresada en hexadecimal, utilizada para identificar una llave pública mediante su resumen SHA-1. El thumbprint a veces se conoce como fingerprint.

mongod / mongos registra una advertencia en la conexión si el certificado X.509 presentado expira dentro de los 30 días del tiempo del sistema host mongod/mongos.

--tlsCRLFile <filename>

Especifica el archivo .pem que contiene la Lista de revocación de certificados. Especifica el nombre del archivo .pem con rutas relativas o absolutas.

Nota

• No puedes especificar un archivo CRL en macOS. En su lugar, puedes utilizar el almacén de certificados SSL del sistema, que utiliza OCSP (Protocolo de estado de certificados en línea) para validar el estado de revocación de los certificados. Para utilizar el almacén de certificados SSL del sistema, consulta --tlsCertificateSelector.

• Para verificar la revocación de certificados, MongoDB enables utiliza OCSP (Protocolo de Estado de Certificados en línea) por defecto como alternativa a especificar un archivo CRL o usar los almacenes de certificados SSL del sistema.

Para más información sobre TLS y MongoDB, consulta Configurar mongod y mongos para TLS/SSL y Configuración de TLS/SSL para clientes .

--tlsAllowConnectionsWithoutCertificates

Por defecto, el servidor omite la validación del certificado del cliente a menos que esté configurado para utilizar un archivo de la Autoridad de Certificación (CA). Si se proporciona un archivo de CA, se aplican las siguientes reglas:

• Para los clientes que no proporcionan certificados, mongod o mongos cifra la conexión TLS/SSL, suponiendo que la conexión se realice con éxito.

• Para los clientes que presentan un certificado, mongos realiza la validación del certificado utilizando la cadena de certificados raíz especificada por --tlsCAFile y rechaza a los clientes con certificados inválidos.

Utiliza la opción --tlsAllowConnectionsWithoutCertificates si tienes una implementación mixta que incluya clientes que no presentan o no pueden presentar certificados al mongos.

Para más información sobre TLS y MongoDB, consulta Configurar mongod y mongos para TLS/SSL y Configuración de TLS/SSL para clientes .

--tlsAllowInvalidCertificates

Evita las comprobaciones de validación de los certificados TLS en otros servidores del clúster y permite el uso de certificados no válidos para conectarse.

Nota

Si especificas --tlsAllowInvalidCertificates o tls.allowInvalidCertificates: true al utilizar la autenticación X.509, un certificado no válido es suficiente solo para establecer una conexión TLS, pero es insuficiente para la autenticación.

Al utilizar la configuración de --tlsAllowInvalidCertificates, MongoDB registra una advertencia sobre el uso del certificado no válido.

Para más información sobre TLS y MongoDB, consulta Configurar mongod y mongos para TLS/SSL y Configuración de TLS/SSL para clientes .

--tlsAllowInvalidHostnames

Desactiva la validación de los nombres de host en los certificados TLS al conectarse a otros nodos del set de réplicas o del clúster para la autenticación entre procesos. Esto permite que mongos se conecte a otros nodos si los nombres de host en sus certificados no coinciden con su nombre de host configurado.

Para más información sobre TLS y MongoDB, consulta Configurar mongod y mongos para TLS/SSL y Configuración de TLS/SSL para clientes .

--tlsDisabledProtocols <protocol(s)>

Impide que un servidor MongoDB que se ejecute con TLS acepte conexiones entrantes que utilicen un protocolo o protocolos específicos. Para especificar varios protocolos, utiliza una lista de protocolos separada por comas.

--tlsDisabledProtocols reconoce los siguientes protocolos: TLS1_0, TLS1_1, TLS1_2 y TLS1_3.

• En macOS, no puedes desactivar TLS1_1 y dejar TLS1_0 y TLS1_2 activados. Debes desactivar al menos uno de los otros dos, por ejemplo, TLS1_0,TLS1_1.

• Para enumerar varios protocolos, especifíquelos como una lista de protocolos separados por comas. Por ejemplo TLS1_0,TLS1_1.

• Especificar un protocolo no reconocido impide que el servidor se inicie.

• Los protocolos deshabilitados especificados anulan cualquier protocolo deshabilitado por defecto.

MongoDB desactiva el uso de TLS 1.0, si TLS 1.1+ está disponible en el sistema. Para habilitar el TLS deshabilitado 1.0, especificanone para --tlsDisabledProtocols.

Los nodos de los sets de réplicas y los clústeres fragmentados deben tener al menos un protocolo en común.

Tip

Prohibir protocolos

--tlsFIPSMode

Indica al mongos que utilice el modo FIPS de la librería TLS. Su sistema debe tener una librería compatible con FIPS para usar la opción --tlsFIPSMode.

Nota

TLS/SSL compatible con FIPS está disponible solo en MongoDB Enterprise. Ve Configurar MongoDB para FIPS si deseas obtener más información.

Opciones de auditoría

--auditCompressionMode

Novedades en la versión 5.3.

Especifica el modo de compresión para el cifrado de registros de auditoría. Debes también habilitar el cifrado del registro de auditoría con --auditEncryptionKeyUID o --auditLocalKeyFile.

--auditCompressionMode puede configurarse en uno de estos valores:

Valor	Descripción
zstd	Utiliza el algoritmo zstd para comprimir el registro de auditoría.
none (por defecto)	No comprimas el registro de auditoría.

Nota

Disponible solo en MongoDB Enterprise. MongoDB Enterprise y Atlas tienen diferentes requisitos de configuración.

--auditDestination

Permite auditar y especifica dónde mongos envía todos los eventos de auditoría.

--auditDestination puede tener uno de los siguientes valores:

Valor	Descripción
syslog	Registra los eventos de auditoría en syslog en formato JSON. No está disponible en Windows. Los mensajes de auditoría tienen un nivel de severidad syslog de info y un nivel de facilidad de user. El límite de mensajes de syslog puede resultar en el truncamiento de los mensajes de auditoría. El sistema de auditoría no detecta ni el truncamiento ni los errores cuando ocurren.
console	Genera los eventos de auditoría en stdout en formato JSON.
file	Exporta los eventos de auditoría al archivo especificado en --auditPath en el formato especificado en --auditFormat.

Nota

Disponible solo en MongoDB Enterprise y MongoDB Atlas.

--auditEncryptionKeyUID

Novedades en la versión 6.0.

Especifica el identificador único de la clave del Protocolo de Interoperabilidad de Gestión de Claves (KMIP) para el cifrado del registro de auditoría.

No puede usar --auditEncryptionKeyUID y --auditLocalKeyFile al mismo tiempo.

Nota

Disponible solo en MongoDB Enterprise. MongoDB Enterprise y Atlas tienen diferentes requisitos de configuración.

--auditFormat

Especifica el formato del archivo de salida para auditoría si --auditDestination es file. La opción --auditFormat puede tener uno de los siguientes valores:

Valor	Descripción
JSON	Exporta los eventos de auditoría en formato JSON al archivo especificado en --auditPath.
BSON	Exporta los eventos de auditoría en formato binario BSON en el archivo especificado en --auditPath.

La impresión de eventos de auditoría en un archivo en formato JSON degrada el rendimiento del servidor más que imprimirlos en un archivo en formato BSON.

Nota

Disponible solo en MongoDB Enterprise y MongoDB Atlas.

--auditLocalKeyFile

Novedades en la versión 5.3.

Especifica la ruta y el nombre de archivo para un archivo de clave de auditoría local para el cifrado del registro de auditoría.

Nota

Utilice --auditLocalKeyFile solo para pruebas porque la clave no está segura. Para asegurar la clave, utilice --auditEncryptionKeyUID y un servidor externo del Protocolo de Interoperabilidad de Gestión de Claves (KMIP).

No puede usar --auditLocalKeyFile y --auditEncryptionKeyUID al mismo tiempo.

Nota

Disponible solo en MongoDB Enterprise. MongoDB Enterprise y Atlas tienen diferentes requisitos de configuración.

--auditPath

Especifica el archivo de salida para la auditoría si --auditDestination tiene el file valor. La opción puede tomar una ruta completa o --auditPath relativa.

Nota

Disponible solo en MongoDB Enterprise y MongoDB Atlas.

--auditFilter

Especifica el filtro para limitar los tipos de operaciones que el sistema de auditoría registra. La opción toma una representación en forma de string de un documento de query del tipo:

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

El <field> puede ser cualquier campo en el mensaje de auditoría, incluidos los campos devueltos en el documento param. La <expression> es una expresión de condición de query.

Para especificar un filtro de auditoría, encierre el documento del filtro entre comillas simples para pasarlo como un string.

Para especificar el filtro de auditoría en un archivo de configuración, debe utilizar el formato YAML del archivo de configuración.

Nota

Disponible solo en MongoDB Enterprise y MongoDB Atlas.

Opciones del perfilador

--slowms <integer>

Por defecto: 100

El umbral de tiempo de operación lenta, en milisegundos. Las operaciones que se ejecutan durante más tiempo que este umbral se consideran lentas.

Cuando logLevel se establece en 0, MongoDB registra las operaciones lentas en el registro de diagnóstico a una tasa determinada por slowOpSampleRate.

Con configuraciones más altas de logLevel, todas las operaciones aparecen en el registro de diagnóstico independientemente de su latencia.

Para las instancias de mongos, afecta únicamente al registro de diagnóstico y no al perfilador, ya que la creación de perfiles no está disponible en mongos.

--slowOpSampleRate <double>

Por defecto: 1.0

La fracción de operaciones lentas para su registro. --slowOpSampleRate acepta valores entre 0 y 1, inclusive.

Para las instancias de mongos, --slowOpSampleRate afecta solo al registro de diagnóstico y no al generador de perfiles, ya que la generación de perfiles no está disponible en mongos.

Opciones de autenticación y autorización por LDAP

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

Disponible solamente en MongoDB Enterprise.

El servidor LDAP contra el cual el mongos autentica a los usuarios o determina qué acciones está autorizado a realizar un usuario en una base de datos dada. Si el servidor LDAP especificado tiene instancias replicadas, puedes especificar el host y el puerto de cada servidor replicado en una lista delimitada por comas.

Si su infraestructura LDAP particiona el directorio LDAP entre varios servidores LDAP, especifique un servidor LDAP o cualquiera de sus instancias replicadas en. MongoDB admite las siguientes --ldapServers referencias LDAP, tal como se define en RFC..4511 4.110 No utilice para listar todos los servidores LDAP de su --ldapServers infraestructura.

Esta configuración se puede configurar en un mongos en ejecución al utilizar setParameter.

Si no se configura, mongos no puede utilizar la autenticación o la autorización LDAP.

--ldapValidateLDAPServerConfig <boolean>

Disponible en MongoDB Enterprise

Una bandera que determina si la instancia mongos verifica la disponibilidad de LDAP server(s) como parte del inicio:

• Si es true, la instancia de mongos realiza la comprobación de disponibilidad y solo continúa iniciándose si el servidor LDAP está disponible.

• Si es false, la instancia mongos omite la verificación de disponibilidad; es decir, la instancia se inicia incluso si el servidor LDAP no está disponible.

--ldapQueryUser <string>

Disponible solamente en MongoDB Enterprise.

La identidad con la que mongos se vincula al conectarse o realizar queries en un servidor LDAP.

Solo es necesario si alguna de las siguientes condiciones es verdadera:

• Usando autorizacion LDAP.

• Uso de una query LDAP para username transformation.

• El servidor LDAP no permite conexiones anónimas

Debe utilizar --ldapQueryUser con --ldapQueryPassword.

Si no se establece, mongos no intenta vincularse al servidor LDAP.

Esta configuración se puede configurar en un mongos en ejecución al utilizar setParameter.

Nota

Las implementaciones de MongoDB en Windows pueden usar --ldapBindWithOSDefaults en lugar de --ldapQueryUser y --ldapQueryPassword. No puedes especificar --ldapQueryUser y --ldapBindWithOSDefaults al mismo tiempo.

--ldapQueryPassword <string>

Disponible solamente en MongoDB Enterprise.

La contraseña utilizada para enlazarse a un servidor LDAP al usar --ldapQueryUser. Debes utilizar --ldapQueryPassword con --ldapQueryUser.

Si no se establece, mongos no intenta vincularse al servidor LDAP.

Esta configuración se puede configurar en un mongos en ejecución al utilizar setParameter.

Nota

Las implementaciones de MongoDB en Windows pueden usar --ldapBindWithOSDefaults en lugar de --ldapQueryPassword y --ldapQueryPassword. No puedes especificar --ldapQueryPassword y --ldapBindWithOSDefaults al mismo tiempo.

--ldapBindWithOSDefaults <bool>

Por defecto: false

Disponible solo en MongoDB Enterprise para la plataforma Windows.

Permite que mongos se autentique o vincule mediante sus credenciales de inicio de sesión de Windows al conectarse al servidor LDAP.

Solo es requerido si:

• Usando autorizacion LDAP.

• Uso de una query LDAP para username transformation.

• El servidor LDAP no permite conexiones anónimas

Utiliza --ldapBindWithOSDefaults para reemplazar --ldapQueryUser y --ldapQueryPassword.

--ldapBindMethod <string>

Por defecto: simple

Disponible solamente en MongoDB Enterprise.

El método que mongos utiliza para autenticarse en un servidor LDAP. Utilícelo con --ldapQueryUser y --ldapQueryPassword para conectarse al servidor LDAP.

--ldapBindMethod admite los siguientes valores:

• simple - mongos utiliza autenticación sencilla.

• sasl - mongos utiliza el protocolo SASL para la autenticación

Si especifica sasl, puede configurar los mecanismos SASL disponibles mediante --ldapBindSaslMechanisms. mongos tiene por defecto el uso del mecanismo DIGEST-MD5.

--ldapBindSaslMechanisms <string>

Por defecto: DIGEST-MD5

Disponible solamente en MongoDB Enterprise.

Una lista separada por comas de los mecanismos SASL que mongos puede utilizar al autenticarse en el servidor LDAP. El mongos y el servidor LDAP deben coincidir en al menos un mecanismo. mongos carga dinámicamente cualquier biblioteca de mecanismos SASL instalada en la máquina host en tiempo de ejecución.

Instale y configure las librerías adecuadas para los mecanismos SASL seleccionados tanto en el host mongos como en el host del servidor LDAP remoto. Su sistema operativo puede incluir ciertas bibliotecas SASL por defecto. Consulte la documentación asociada con cada mecanismo SASL para obtener orientación sobre la instalación y configuración.

Si usas el mecanismo SASL GSSAPI para la autenticación Kerberos en implementaciones autogestionadas, verifica lo siguiente para la máquina host mongos:

Linux

• La variable de entorno KRB5_CLIENT_KTNAME se resuelve en el nombre de los Archivos Keytab de Linux del cliente para la máquina host. Para obtener más información sobre las variables de entorno de Kerberos, consulta la documentación de Kerberos.

• El keytab del cliente incluye un Usuario principal para que mongos lo utilice al conectarse al servidor LDAP y ejecutar consultas LDAP.

Windows

Si se conecta a un servidor de Active Directory, la configuración de Kerberos de Windows genera automáticamente un Ticket-Granting-Ticket cuando el usuario inicia sesión en el sistema. Establezca --ldapBindWithOSDefaults en true para permitir que mongos utilice las credenciales generadas al conectarse al servidor de Active Directory y ejecutar queries.

Establece --ldapBindMethod en sasl para usar esta opción.

Nota

Para obtener una lista completa de los mecanismos SASL, se debe consultar el listado de IANA. Se debe consultar la documentación del servicio LDAP o Active Directory para identificar los mecanismos SASL compatibles con el servicio.

MongoDB no es una fuente de bibliotecas de mecanismos SASL, ni la documentación de MongoDB es una fuente definitiva para instalar o configurar cualquier mecanismo SASL. Para obtener documentación y soporte, consulte al proveedor o propietario de la biblioteca de mecanismos SASL.

Para obtener más información sobre SASL, consulte los siguientes recursos:

• Para Linux, consulta la documentación de Cyrus SASL.

• Para Windows, consulta la documentación de Windows SASL.

--ldapTransportSecurity <string>

Por defecto: tls

Disponible solamente en MongoDB Enterprise.

Por defecto, mongos crea una conexión segura TLS/SSL al servidor LDAP.

Para las implementaciones de Linux, debe configurar las opciones adecuadas de TLS en el archivo /etc/openldap/ldap.conf. El administrador de paquetes de su sistema operativo crea este archivo como parte de la instalación de MongoDB Enterprise, mediante la dependencia libldap. Consulte la documentación para TLS Options en la documentación ldap.conf de OpenLDAP para obtener instrucciones más completas.

Para la implementación de Windows, debe agregar los certificados CA del servidor LDAP a la herramienta de gestión de certificados de Windows. El nombre exacto y la funcionalidad de la herramienta pueden variar según la versión del sistema operativo. Consulte la documentación de su versión de Windows para obtener más información sobre la gestión de certificados.

Establezca --ldapTransportSecurity en none para desactivar TLS/SSL entre mongos y el servidor LDAP.

Advertencia

Si se establece --ldapTransportSecurity en none, se transmite información en texto plano y posiblemente credenciales entre mongos y el servidor LDAP.

--ldapTimeoutMS <long>

Por defecto: 10000

Disponible solamente en MongoDB Enterprise.

La cantidad de tiempo en milisegundos mongos que debería esperar a que un servidor LDAP responda a una solicitud.

Incrementar el valor de --ldapTimeoutMS puede evitar la falla de conexión entre el servidor MongoDB y el servidor LDAP, si la causa de la falla es un tiempo de espera de conexión. Disminuir el valor de --ldapTimeoutMS reduce el tiempo que MongoDB espera una respuesta del servidor LDAP.

Esta configuración se puede configurar en un mongos en ejecución al utilizar setParameter.

--ldapUserToDNMapping <string>

Disponible solamente en MongoDB Enterprise.

Asocia el nombre de usuario proporcionado a mongos para la autenticación con un nombre distinguido (DN) de LDAP. Es posible que deba utilizar --ldapUserToDNMapping para transformar un nombre de usuario en un nombre distinguido de LDAP en los siguientes escenarios:

• Realizar autenticación LDAP con enlace simple de LDAP, donde los usuarios se autentican en MongoDB con nombres de usuario que no son nombres distinguidos completos de LDAP.

• Utilizando un LDAP authorization query template que requiere un nombre distinguido.

• Transformar los nombres de usuario de los clientes que se autentican en MongoDB mediante diferentes mecanismos de autenticación, como x.509 o Kerberos, a un nombre distinguido completo de LDAP para la autorización.

--ldapUserToDNMapping espera una cadena JSON entre comillas que represente un arreglo ordenado de documentos. Cada documento contiene una expresión regular match y una plantilla substitution o ldapQuery utilizada para transformar el nombre de usuario entrante.

Cada documento en el arreglo tiene la siguiente forma:

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

Campo	Descripción	Ejemplo
match	Una expresión regular (regex) con formato ECMAScript para hacer coincidir con un nombre de usuario proporcionado. Cada sección entre paréntesis representa un grupo de captura de regex utilizado por substitution o ldapQuery.	"(.+)ENGINEERING" "(.+)DBA"
substitution	Una plantilla de formato de nombre distinguido (DN) de LDAP que convierte el nombre de autenticación que coincide con la expresión regular match en un DN de LDAP. Cada valor numérico encerrado entre llaves se reemplaza por el grupo de captura de expresión regular correspondiente extraído del nombre de usuario de autenticación mediante la expresión regular match. El resultado de la sustitución debe ser una string escapada RFC4514.	"cn={0},ou=engineering, dc=example,dc=com"
ldapQuery	Una plantilla de formato de query LDAP que inserta el nombre de autenticación que coincide con la expresión regular match en un URI de query LDAP codificado respetando el RFC4515 y el RFC4516. Cada valor numérico entre llaves se reemplaza por el grupo de captura de expresión regular correspondiente extraído del nombre de usuario de autenticación mediante la expresión match. mongos ejecuta el query en el servidor LDAP para recuperar el nombre distinguido de LDAP para el usuario autenticado. mongos requiere exactamente un resultado devuelto para que la transformación sea exitosa o mongos omite esta transformación.	"ou=engineering,dc=example, dc=com??one?(user={0})"

Nota

Una explicación de RFC4514, RFC4515, RFC4516, o las consultas LDAP están excluidas de la documentación de MongoDB. Se debe revisar el RFC directamente o usar el recurso LDAP preferido.

Para cada documento del arreglo, debe usar substitution o ldapQuery. No puede especificar ambos en el mismo documento.

Al realizar la autenticación o autorización, mongos recorre cada documento del arreglo en el orden dado, y verifica el nombre de usuario de autenticación contra el filtro match. Si se encuentra una coincidencia, mongos aplica la transformación y utiliza el resultado para autenticar al usuario. mongos no comprueba el resto de los documentos del arreglo.

Si el documento dado no coincide con el nombre de autenticación proporcionado, mongos continúa revisando la lista de documentos para encontrar coincidencias adicionales. Si no se encuentran coincidencias en ningún documento, o si la transformación que el documento describe falla, mongos devuelve un error.

mongos también devuelven un error si una de las transformaciones no puede evaluarse debido a errores de red o de autenticación con el servidor LDAP. mongos rechaza la solicitud de conexión y no verifica los documentos restantes en el arreglo.

A partir de MongoDB 5.0, --ldapUserToDNMapping acepta una string vacía "" o un arreglo vacío [ ] en lugar de un documento de asignación. Si proporcionas una string vacía o un arreglo vacío a --ldapUserToDNMapping, MongoDB asigna el nombre de usuario autenticado como el nombre distinguido de LDAP. Anteriormente, proporcionar un documento de mapeo vacío provocaba que el mapeo fallara.

Ejemplo

A continuación, se muestran dos documentos de transformación. El primer documento coincide con cualquier string que termine en @ENGINEERINGy coloca todo lo que proceda al sufijo en un grupo de captura de expresiones regulares. El segundo documento coincide con cualquier string que termine en @DBAy coloca todo lo que preceda al sufijo en un grupo de captura de expresiones regulares.

Importante

Debe pasar el arreglo a --ldapUserToDNMapping como una 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})"
   }
]"

Un usuario con el nombre de usuario alice@ENGINEERING.EXAMPLE.COM coincide con el primer documento. El grupo de captura de regex {0} corresponde al string alice. La salida resultante es el nombre distinguido "cn=alice,ou=engineering,dc=example,dc=com".

Un usuario con el nombre de usuario bob@DBA.EXAMPLE.COM coincide con el segundo documento. El grupo de captura de expresiones regulares {0} corresponde al string bob. La salida resultante es la query LDAP "ou=dba,dc=example,dc=com??one?(user=bob)". mongos ejecuta esta query en el servidor LDAP, devolviendo el resultado "cn=bob,ou=dba,dc=example,dc=com".

Si --ldapUserToDNMapping no está configurado, mongos no realiza ninguna transformación al nombre de usuario al intentar autenticar o autorizar a un usuario en el servidor LDAP.

Esta configuración se puede ajustar en un mongos en ejecución al utilizar el comando de base de datos setParameter.

Opciones adicionales

--ipv6

Habilita el soporte para IPv6. mongos desactiva el soporte de IPv6 por defecto.

Configurar --ipv6 no dirige a mongos a escuchar en ninguna dirección o interfaz local IPv6. Para configurar mongos para escuchar en una interfaz IPv6, debe:

• Configura --bind_ip con una o más direcciones IPv6 o nombres de host que se resuelvan en direcciones IPv6, o

• Establece --bind_ip_all en true.