Open allout58 opened 3 months ago
Hitting this same issue in Ubuntu 22.04.
{
"couchdb": "Welcome",
"version": "3.3.3",
"git_sha": "40afbcfc7",
"uuid": "REDACTED",
"features": [
"access-ready",
"partitioned",
"pluggable-storage-engines",
"reshard",
"scheduler"
],
"vendor": {
"name": "The Apache Software Foundation"
}
}
.ini
files are read in a hierarchy. The later ones override the early ones. It goes something like default.ini
, default.d/*.ini
, local.ini
and local.d/*.ini
. The *.ini
ones are sorted, so typically there you'd want to add a numeric prefix indicating the order it should be local.d/10-admins.ini
vs local.d/50-admins.ini
.
Config values are written to the last file in the chain, so make sure to put your admins in the last file in the chain, say local.d/80-mysettings.ini
for instance. Another approach is to pre-hash the password with an external tool. This is a bit more advanced but then it wouldn't rely on writing to the last .ini
file rule.
Description
I am trying to configure a CouchDB instance on Rocky Linux 8. I have it installed and functioning, but if I put any configuration .ini files in
etc/local.d
, it seems to break the hash-and-update for admin passwords, both in files inlocal.d
and inlocal.ini
Steps to Reproduce
etc/local.ini
[admins]
section to have, for example,admin = himom
etc/local.d/admins.ini
with contentsetc/local.ini
andetc/local.d/admins.ini
files to see that contents have not been updated with hashed passwordsExpected Behaviour
At a bare minimum, having config files in local.d should not break hashing and updating local.ini.
Ideally, I'd also like admin passwords in config files under local.d to be hashed and updated as well.
Your Environment
{"couchdb":"Welcome","version":"3.3.3","git_sha":"40afbcfc7","uuid":"7ca12332e50b19feef607ad452e6df09","features":["access-ready","partitioned","pluggable-storage-engines","reshard","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}
Additional Context
I have not tried having any configuration files under default.d to know if the same problem occurs.
I know that
[admins]
section inlocal.d/admins.ini
is being read as I can log into Fauxton with the credentials set thereThis is not just related to
[admins]
section inlocal.d
, any configuration files in there cause this issue.