Konfigurieren der MongoDB Shell: Von Default zu maßgeschneidert

mongosh funktioniert out-of-the-box mit sinnvollen Defaults: Verbindung zu localhost:27017, keine Authentifizierung, Standard-Timeouts und -Batch-Sizes. Für schnelle lokale Tests ist dies perfekt. Aber produktive Nutzung erfordert Konfiguration – Remote-Verbindungen, Authentifizierung, TLS, Custom-Prompts, wiederverwendbare Helper-Functions. Die Shell ist hochgradig konfigurierbar, von einfachen CLI-Flags bis zu komplexen JavaScript-Konfigurationsdateien.

Die Kunst liegt darin, die richtige Balance zu finden zwischen ad-hoc-Flexibilität und persistenter Konfiguration. Manche Settings – wie Credentials – sollten nie in persistenten Files stehen. Andere – wie Custom-Functions oder Prompt-Styles – sind perfekt für .mongoshrc.js. Dieses Kapitel durchläuft die Konfigurations-Optionen systematisch, mit Fokus auf praktische Use-Cases und Security-Bewusstsein.

31.1 Connection Strings: Die moderne Art der Verbindung

Der primäre Weg, mongosh zu konfigurieren, ist der MongoDB Connection String – ein URI-Format, das alle Verbindungsparameter in einer einzigen String kodiert. Dies ist nicht nur praktisch, sondern auch portabel – derselbe Connection String funktioniert in mongosh, in Application-Treibern und in MongoDB Compass.

mongosh "mongodb://localhost:27017"

Die Anführungszeichen sind wichtig, besonders wenn der String Sonderzeichen enthält. Für Remote-Hosts:

mongosh "mongodb://db.example.com:27017"

mongosh "mongodb://mongo1.example.com:27017,mongo2.example.com:27017,mongo3.example.com:27017/mydb?replicaSet=rs0"

Der replicaSet-Parameter ist kritisch – ohne ihn treated mongosh die Verbindung als zu standalone Instances, nicht als Replica Set. Die Hosts müssen mit ihren Replica-Set-Namen erreichbar sein, nicht mit IP-Adressen, wenn DNS-SRV-Records genutzt werden.

Für Sharded Clusters verbindet man sich mit mongos-Routern, nicht direkt mit Shards:

mongosh "mongodb://mongos1.example.com:27017,mongos2.example.com:27017/mydb"

Multiple mongos-Hosts für Redundanz sind empfohlen – fällt einer aus, connected die Shell automatisch zum nächsten.

31.2 Authentifizierung: Credentials sicher handhaben

Produktive MongoDB-Deployments haben Authentifizierung aktiviert. Credentials können auf mehrere Arten übergeben werden, mit unterschiedlichen Security-Implikationen.

mongosh "mongodb://username:password@db.example.com:27017/admin"

Dies ist praktisch für Quick-Tests, aber die Credentials erscheinen in Shell-History, Process-Listings (ps aux) und möglicherweise in Logs. Für Production ist dies inakzeptabel.

mongosh "mongodb://username@db.example.com:27017/admin"

Wenn das Password fehlt, prompted mongosh interaktiv danach. Das Password wird nicht angezeigt beim Tippen (maskiert als ***) und erscheint nicht in History. Dies ist der empfohlene Weg für manuelle Verbindungen.

mongosh --username myUser --password myPassword --host db.example.com --port 27017 --authenticationDatabase admin

Dies ist die alte Syntax, funktioniert aber noch. Der Connection-String-Ansatz ist moderner und kompakter.

export MONGODB_URI="mongodb://username:password@db.example.com:27017/admin"
mongosh "$MONGODB_URI"

Environment-Variables sind besser als Hardcoded-Credentials in Scripts. Sie können in CI/CD-Pipelines als Secret-Variables injected werden. Aber sie sind immer noch in Process-Environment sichtbar.

Für sehr sensitive Umgebungen kann man Credentials in einer File mit restriktiven Permissions speichern:

# credentials.txt (chmod 600)
mongodb://username:password@db.example.com:27017/admin

mongosh "$(cat credentials.txt)"

Dies ist besser als Environment-Variables, weil die File außerhalb des Process-Space ist. Aber Filesystem-Permissions sind kritisch – chmod 600 oder besser 400 (read-only für Owner).

31.3 Authentication Mechanisms: Mehr als Username/Password

MongoDB unterstützt mehrere Auth-Mechanismen. Der Default ist SCRAM-SHA-256, aber andere sind verfügbar für spezielle Use-Cases.

mongosh "mongodb://user:pass@host/db?authMechanism=SCRAM-SHA-256"

mongosh "mongodb://user:pass@host/db?authMechanism=SCRAM-SHA-1"

mongosh "mongodb://host/db?authMechanism=MONGODB-X509" \
  --tls \
  --tlsCertificateKeyFile /path/to/client.pem \
  --tlsCAFile /path/to/ca.pem

Der Username ist aus dem Certificate-Subject extrahiert. Dies ist sehr sicher – keine Passwords im Spiel.

mongosh "mongodb://ldapUser@host/db?authMechanism=PLAIN"

Für LDAP-Integration in Enterprise-Umgebungen. Das Password wird gegen einen LDAP-Server validiert.

mongosh "mongodb://user%40REALM@host/db?authMechanism=GSSAPI"

Für die meisten Anwendungen ist SCRAM-SHA-256 ausreichend und sicher. Die fortgeschrittenen Mechanismen sind für spezielle Compliance- oder Integration-Requirements.

31.4 TLS/SSL: Verschlüsselte Verbindungen

Über öffentliche Netzwerke oder das Internet sollten MongoDB-Verbindungen immer TLS-verschlüsselt sein. mongosh unterstützt vollständiges TLS-Setup:

mongosh "mongodb://host:27017/db?tls=true" \
  --tlsCertificateKeyFile /path/to/client.pem \
  --tlsCAFile /path/to/ca.pem

Die tlsCAFile ist das Certificate Authority Certificate, das die Server-Certificates validiert. Ohne dies accepted mongosh any Certificate, was Man-in-the-Middle-Attacks ermöglicht.

Für Self-Signed-Certificates in Dev/Test kann man CA-Validation disablen (NICHT in Produktion):

mongosh "mongodb://host:27017/db?tls=true&tlsAllowInvalidCertificates=true"

Dies ist gefährlich – es gibt keine Garantie, dass man wirklich mit dem richtigen Server spricht. Nur für lokales Testing akzeptabel.

mongosh "mongodb://host:27017/db?tls=true&authMechanism=MONGODB-X509" \
  --tlsCertificateKeyFile /path/to/client-cert-and-key.pem \
  --tlsCAFile /path/to/ca.pem

Die tlsCertificateKeyFile enthält sowohl das Client-Certificate als auch den Private Key. Dies muss eine kombinierte PEM-File sein. Generierung typischerweise mit OpenSSL:

cat client-cert.pem client-key.pem > client-combined.pem
chmod 400 client-combined.pem

Die Permissions sind kritisch – der Private Key darf nicht world-readable sein.

31.5 .mongoshrc.js: Personalisierung und Helper-Functions

Die .mongoshrc.js-File in ~/.mongodb/mongosh/ wird bei jedem mongosh-Start automatisch executed. Dies ist der Platz für persistente Konfiguration – Custom-Functions, Prompt-Styling, Auto-Connects, häufige Queries.

// ~/.mongodb/mongosh/.mongoshrc.js

// Custom Prompt mit Hostname und Timestamp
prompt = function() {
  const hostname = db.hostInfo().system.hostname;
  const dbName = db.getName();
  const time = new Date().toLocaleTimeString();
  return `[${time}] ${dbName}@${hostname}> `;
}

// Helper-Functions
function countAll(collectionName) {
  return db.getCollection(collectionName).countDocuments();
}

function findRecent(collectionName, limit = 10) {
  return db.getCollection(collectionName)
    .find()
    .sort({ _id: -1 })
    .limit(limit)
    .toArray();
}

function explainQuery(collectionName, query) {
  return db.getCollection(collectionName)
    .find(query)
    .explain("executionStats");
}

// Shortcuts für häufige Datenbanken
function useProd() {
  db = db.getSiblingDB('production');
  print('Switched to production database - BE CAREFUL!');
}

function useDev() {
  db = db.getSiblingDB('development');
  print('Switched to development database');
}

// Warnings für gefährliche Datenbanken
if (db.getName() === 'production') {
  print('⚠️  WARNING: You are connected to PRODUCTION database!');
  print('⚠️  Double-check all commands before executing!');
}

// Disable Telemetry (optional)
disableTelemetry();

// Custom greeting
print('Custom mongoshrc loaded! Type "help()" for custom commands.');
print('Available helpers: countAll(), findRecent(), explainQuery(), useProd(), useDev()');

Diese Konfiguration gibt einen informativen Prompt mit Timestamp, definiert häufig genutzte Helper-Functions und warnt beim Connect zu Production-DBs. Das Warning ist nicht technisch enforced – es ist nur ein Reminder – aber psychologisch effektiv.

31.6 Advanced Configuration: Read Preferences und Write Concerns

Für Replica Sets und Sharded Clusters kann man Read Preferences und Write Concerns via Connection String konfigurieren:

# Read von Secondaries bevorzugen
mongosh "mongodb://host/db?readPreference=secondary"

# Read von nearest (geringste Latenz)
mongosh "mongodb://host/db?readPreference=nearest"

# Write Concern majority
mongosh "mongodb://host/db?w=majority&wtimeoutMS=5000"

Diese Settings beeinflussen, wie Reads und Writes gehandled werden. readPreference=secondary routet Reads an Secondaries, was Primary-Load reduziert aber potentiell stale Data returned. w=majority garantiert, dass Writes zu einer Mehrheit des Replica Sets replicated sind, bevor acknowledged – sicherer aber langsamer.

Für Analytics-Workloads, wo stale Data akzeptabel ist, ist readPreference=secondary oder nearest sinnvoll. Für transactional Workloads sollte man primary nutzen (der Default).

31.7 Environment-Specific Config: Multiple Profiles managen

Wer mit mehreren Environments arbeitet (Dev, Staging, Production), braucht unterschiedliche Konfigurationen. Ein Pattern: Environment-spezifische Shell-Aliases:

# In .bashrc oder .zshrc

alias mongosh-dev='mongosh "mongodb://dev.example.com:27017/myapp" --tlsCAFile ~/certs/dev-ca.pem'
alias mongosh-staging='mongosh "mongodb://staging.example.com:27017/myapp" --tlsCAFile ~/certs/staging-ca.pem'
alias mongosh-prod='mongosh "mongodb://prod.example.com:27017/myapp" --tlsCAFile ~/certs/prod-ca.pem'

mongosh-dev
# Verbindet automatisch zu Dev mit korrekten Certs

# config-dev.conf
mongodb://dev.example.com:27017/myapp?tls=true

# config-prod.conf
mongodb://prod.example.com:27017/myapp?tls=true&w=majority

mongosh --config config-dev.conf

Achtung: mongosh hat kein eingebautes --config-Flag für Connection-String-Files. Der obige Command funktioniert nicht direkt. Stattdessen:

mongosh "$(cat config-dev.conf)"

#!/bin/bash
# mongosh-wrapper.sh
CONFIG_FILE=$1
CONNECTION_STRING=$(cat "$CONFIG_FILE")
mongosh "$CONNECTION_STRING"

./mongosh-wrapper.sh config-dev.conf

31.8 SSH Tunneling: Sicherer Zugriff auf Remote-Datenbanken

Manchmal sind MongoDB-Server nicht direkt erreichbar – etwa hinter Firewalls oder in Private-Networks. SSH-Tunneling erlaubt sicheren Zugriff:

# Port-Forwarding via SSH
ssh -L 27017:localhost:27017 user@jumphost.example.com

# In separatem Terminal
mongosh "mongodb://localhost:27017"

Der SSH-Tunnel mapped lokalen Port 27017 zum Port 27017 auf dem Remote-Host via verschlüsselte SSH-Connection. mongosh connected zu localhost, aber der Traffic geht durch den Tunnel zum Remote-Server.

Für Persistent-Tunnels kann man -N (no command) und -f (background) nutzen:

ssh -fN -L 27017:localhost:27017 user@jumphost.example.com

Dies startet den Tunnel im Background. Er bleibt offen bis manuell gekilled. Für automatisches Tunneling beim mongosh-Start kann man ein Wrapper-Script schreiben:

#!/bin/bash
# start-tunnel-and-mongosh.sh

# Start Tunnel
ssh -fN -L 27017:localhost:27017 user@jumphost.example.com

# Wait for tunnel to establish
sleep 2

# Connect with mongosh
mongosh "mongodb://localhost:27017"

# Cleanup on exit
trap "pkill -f 'ssh.*27017:localhost:27017'" EXIT

Dies ist ein einfacher Approach. Für Produktions-Use sollte man robustere Tunnel-Management-Tools wie autossh nutzen.

31.9 Performance Tuning: Batch Sizes und Timeouts

// In Shell oder .mongoshrc.js
DBQuery.shellBatchSize = 50  // Default ist 20

Dies kontrolliert, wie viele Dokumente per Batch fetched werden. Größere Batches reduzieren Roundtrips, brauchen aber mehr Memory. Für große Dokumente sollte man kleinere Batches nutzen, für viele kleine Dokumente größere.

mongosh "mongodb://host/db?connectTimeoutMS=5000"

Der Default ist 30 Sekunden. Für schnelle Fail-Fast in Scripts kann man dies reduzieren.

mongosh "mongodb://host/db?socketTimeoutMS=60000"

Dies ist der Timeout für einzelne Operationen. Für Long-Running-Queries (große Aggregations) sollte man dies erhöhen.

mongosh "mongodb://host/db?maxPoolSize=10"

Dies limitiert, wie viele Verbindungen der Driver offen hält. Für mongosh (single-threaded) ist dies meist irrelevant, aber für Consistency mit Application-Treibern kann man es setzen.

31.10 Troubleshooting: Verbindungsprobleme debuggen

# Test mit ping/telnet
ping db.example.com
telnet db.example.com 27017

Wenn ping funktioniert aber telnet nicht, ist MongoDB nicht erreichbar (Firewall, MongoDB nicht gestartet).

# Resolve Hostname
nslookup db.example.com

Entweder ist die CA-File falsch oder das Server-Cert ist invalide. Für Debugging:

# Disable Cert-Validation temporär
mongosh "mongodb://host/db?tls=true&tlsAllowInvalidCertificates=true"

Prüfe: - Username korrekt? - Password korrekt? - authenticationDatabase korrekt? (typischerweise admin) - User hat Permissions auf der Datenbank?

mongosh --verbose "mongodb://host/db"

Dies gibt detaillierte Logs über Connection-Attempts, was beim Debugging hilft.

Option	Default	Zweck	Beispiel
`tls`	false	TLS/SSL aktivieren	`?tls=true`
`replicaSet`	-	Replica Set Name	`?replicaSet=rs0`
`authMechanism`	SCRAM-SHA-256	Auth-Methode	`?authMechanism=MONGODB-X509`
`readPreference`	primary	Read-Routing	`?readPreference=secondary`
`w`	1	Write Concern	`?w=majority`
`wtimeoutMS`	-	Write Timeout	`?wtimeoutMS=5000`
`connectTimeoutMS`	30000	Connection Timeout	`?connectTimeoutMS=5000`
`socketTimeoutMS`	-	Socket Timeout	`?socketTimeoutMS=60000`
`maxPoolSize`	100	Max Connections	`?maxPoolSize=10`
`retryWrites`	true	Retry fehlgeschlagene Writes	`?retryWrites=false`

Die Konfiguration von mongosh ist flexibel und mächtig, aber mit Flexibilität kommt Komplexität. Die Best Practice: Start mit simplen Defaults, füge Konfiguration hinzu wenn nötig, nicht präventiv. Credentials niemals in persistent Files. TLS für alle Verbindungen über unsichere Netzwerke. .mongoshrc.js für Helper-Functions und Prompt-Customization, nicht für Connection-Logik. Mit diesen Prinzipien wird mongosh zu einem sicheren, effizienten und personalisierten Tool für alle MongoDB-Interaktionen.

31 Konfigurieren der MongoDB Shell: Von Default zu maßgeschneidert