Hi there,
We’re using the Docker container version 6.0.4 version of Percona Mongo and we’re running into what appears to be a bug in the container initialization. The problem we’re having is that the Percona instance in the container is ignoring our encryption directive in our config file on initial startup. What’s happening is that the container starts up in a minimal mode to initialize the database and create the initial user. Then it restarts but this time it uses the config file and any other options we pass it. This is a problem because the initial startup creates unencrypted data files and the second startup (with encryption enabled) tries to read those data files and thinks they are corrupted because they are not encrypted as expected.
A workaround was to create the encrypted data files in a different folder. The problem with that is that the initial user now does not exist in the encrypted database. If anyone has suggestions as to how to handle this I’d appreciate it. I’ve spent many hours on this now.
Hi Sandra,
Thanks for checking this out! I’m starting this from within Docker compose and it reads from a config file. I’ve also gotten to the point where I’m extending the Percona container directly so it’s easier to torubleshoot. I use that in the compose file below. My above report is based on using the container with no changes. That is, I’ve just copy-pasted Percona’s info into my own Docker container, without changes, and it works the same as using the container directly.
I’ve pasted the config file below. I’m also including the docker compose setup.
I just saw your follow-up note. We are using a local key file for the key, generated per the docs.
Any insight you can give would be great. Thanks!
Matt
# mongod.conf, Percona Server for MongoDB
# for documentation of all options, see:
# http://docs.mongodb.org/manual/reference/configuration-options/
# Where and how to store data.
storage:
dbPath: /data/db #-encrypted # Use a non-default folder name, like "db-encrypted", for containerized, encrypted version
# The reason is that the container already defaults to a non-encrypted set of files in
# /data/db, so when you start up in encrypted mode, the db will complain that the files
# are corrupted, since they already exist and are unencrypted.
journal:
enabled: true
# engine: wiredTiger
# engine: inMemory
# Storage engine various options
# More info for wiredTiger: https://docs.mongodb.com/v4.4/reference/configuration-options/#storage-wiredtiger-options
# wiredTiger:
# engineConfig:
# cacheSizeGB: 1
# checkpointSizeMB: 1000
# statisticsLogDelaySecs: 0
# journalCompressor: snappy
# directoryForIndexes: false
# collectionConfig:
# blockCompressor: snappy
# indexConfig:
# prefixCompression: true
# More info for inMemory: https://www.percona.com/doc/percona-server-for-mongodb/4.4/inmemory.html#configuring-percona-memory-engine
# inMemory:
# engineConfig:
# inMemorySizeGB: 1
# statisticsLogDelaySecs: 0
# Two options below can be used for wiredTiger and inMemory storage engines
setParameter:
auditAuthorizationSuccess: true
# wiredTigerConcurrentReadTransactions: 128
# wiredTigerConcurrentWriteTransactions: 128
# where to write logging data.
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
processManagement:
pidFilePath: /var/run/mongod.pid
# fork: true # This causes server to die, in a container
# network interfaces
net:
port: 27017
# bindIp: 127.0.0.1
bindIpAll: true
# tls:
# mode: requireTLS
# certificateKeyFile: /certs/settings_db/cert.pem
# CAFile: /certs/settings_db/key.pem
# allowInvalidCertificates: false
# allowConnectionsWithoutCertificates: false
# FIPSMode: true
security:
javascriptEnabled: false
authorization: enabled
enableEncryption: true # Temporarily commented out
encryptionCipherMode: AES256-CBC
encryptionKeyFile: /etc/mongodb-keyfile
relaxPermChecks: false
#operationProfiling:
#replication:
#sharding:
## Enterprise-Only Options:
auditLog:
destination: file
format: BSON
path: /var/log/mongodb/auditLog.bson
# filter: '{ atype: { $in: [ "createCollection", "dropCollection" ] } }' # If filters are desired
#snmp:
Hi Sandra,
Thanks, are you saying to replace config file options with command line arguments? Or only to pass the encryption arguments specifically? It appears so, but wanted to confirm.
Thank you again.
Matt
Thank you Sandra! I just tried this and it worked! Those were the magic incantations. I appreciate the help. The documentation or functionality should probably be updated to address the config file issue, as it’s basic functionality that appears broken though.
Thank you again!
Matt
Please try passing encryption options in addition to config, f.e.