This Improvement request (usability, performance, tech debt, etc.) affects these Traffic Control components:
Current behavior:
The Traffic Ops db/admin tool relies on the postgres user requiring no password when connecting as root.
|
userExistsCmd := exec.Command("psql", "-h", hostIP, "-U", dbSuperUser, "-p", hostPort, "-tAc", "SELECT 1 FROM pg_roles WHERE rolname='"+dbUser+"'") |
#7142, which made Traffic Ops run as a non-root user, set PGPASSWORD for the entire binary, which worked for Dev CDN in a Box because the password in dbconf.yml, which this strategy set PGPASSWORD to,
|
open: host=db port=5432 user=traffic_ops password=twelve12 dbname=traffic_ops_development sslmode=disable |
happened to be "twelve12", the same password set for the postgres user of the Postgres server.
|
- POSTGRES_PASSWORD=twelve12 |
However, once #7142 was merged, the Cache Config integration tests started failing, because its postgres user password
|
POSTGRES_PASSWORD=secretrootpass |
is different than its traffic_ops password (which ends up in dbconf.yml).
|
DB_USER=traffic_ops |
|
DB_USER_PASS=twelve |
|
open: host=$DB_SERVER port=$DB_PORT user=$DB_USER password=$DB_USER_PASS dbname=$DB_NAME sslmode=disable |
We reverted the change to db/admin from #7142 in #7198 to make the Cache Config integration tests pass again without knowing, at the time, why that change made them fail.
As a side note, finding the reason the Cache Config integration tests were failing was not straightforward because the errors go only to a file that is not printed to the to_server container's output anywhere.
|
cd /opt/traffic_ops/app && db/admin --env=production reset >> /var/log/traffic_ops/to_admin.log 2>&1 |
|
cd /opt/traffic_ops/app && db/admin --trafficvault --env=production reset >> /var/log/traffic_ops/tv_admin.log 2>&1 |
New behavior:
db/admin should not depend on the postgres user requiring no password when the connecting client is the root user locally.- In CDN in a Box for Developers, the
postgres password should not be the same as the traffic_ops password, because that potentially hides issues like this one.
This Improvement request (usability, performance, tech debt, etc.) affects these Traffic Control components:
Current behavior:
The Traffic Ops
db/admintool relies on thepostgresuser requiring no password when connecting as root.trafficcontrol/traffic_ops/app/db/admin.go
Line 307 in 02b9f04
#7142, which made Traffic Ops run as a non-root user, set
PGPASSWORDfor the entire binary, which worked for Dev CDN in a Box because the password indbconf.yml, which this strategy setPGPASSWORDto,trafficcontrol/dev/traffic_ops/dbconf.yml
Line 21 in 02b9f04
happened to be
"twelve12", the same password set for thepostgresuser of the Postgres server.trafficcontrol/docker-compose.yml
Line 46 in 02b9f04
However, once #7142 was merged, the Cache Config integration tests started failing, because its
postgresuser passwordtrafficcontrol/cache-config/testing/docker/variables.env
Line 31 in 02b9f04
is different than its
traffic_opspassword (which ends up indbconf.yml).trafficcontrol/cache-config/testing/docker/variables.env
Lines 35 to 36 in 02b9f04
trafficcontrol/cache-config/testing/docker/traffic_ops/run.sh
Line 98 in 02b9f04
We reverted the change to
db/adminfrom #7142 in #7198 to make the Cache Config integration tests pass again without knowing, at the time, why that change made them fail.As a side note, finding the reason the Cache Config integration tests were failing was not straightforward because the errors go only to a file that is not printed to the
to_servercontainer's output anywhere.trafficcontrol/cache-config/testing/docker/traffic_ops/run.sh
Lines 144 to 145 in 02b9f04
New behavior:
db/adminshould not depend on thepostgresuser requiring no password when the connecting client is therootuser locally.postgrespassword should not be the same as thetraffic_opspassword, because that potentially hides issues like this one.