I've been asked to copy the data from a live server in order to create a new test server. The data is pretty much a snap shot of the live server. It contains two databases, a bunch of .jar files and some NTP configurations. I take backups from both these databases and create test versions, I set up all the other little bits and pieces (FTP etc..) and I'm done.
I start to create the systemd files which will be used to run daemons on startup, most of them work perfectly fine...but one particular file ( a master daemon used to kick off multiple daemons) fails.
Turns out one of the daemons connects to the first database in order to grab credentials for the second database, which it then connects to and runs some stored procedures. This was failing with an SQLException wrong username or password.
This is strange because I have other daemons that follow this procedure and connect successfully. Both are getting there username and password from the same place...or are they...
Digging around in the code I release there are multiple ways in which the user can obtain the username and password, by default they look in the database, the credentials found can be overridden via
- config file
- command line arguments
The credentials are not being overridden in the config file as this would mean all daemons would have the same issue, no, it must be that someone somewhere has hard coded the credentials are arguments.
After searching around I find that within the master daemon someone has indeed done this. How massively irritating... Removing these arguments and letting the daemon get its credentials from the database solves the issue.
What grinds my gears
This seems to me to be either a lack of communication between the original developers or old code which should have been removed. Admittedly this issue wouldn't take to long to resolve for someone working on it full time, but that's not really the point here.
I can understand getting the values from the database and then also writing a override function which lets the user set there own credentials, this makes sense, but keep it in one place! In this software this is the only daemon that lets the user use command line arguments to override the credentials. Why? We have a perfectly good config file specifically for that reason...