When it comes to the administration of systems and infrastructure, one should always be wary if they find themselves manually repeating the same process too many times. This is especially true when said manual process involves touching potentially security-related data like passwords. However, if you're connecting directly to a database, like the one your Jira application uses, you can gain an added layer of protection by wrapping the entire process in a script.
Ideally, this is tackled with a fully developed shortcut like a Python script with full input validation that can account for all of the gotchas that one has the foresight to imagine.
As many system admins are aware, though, it is often the case that the ideal world is something being moved toward rather than something already in place. In some cases, the limiting factor is time, and prioritizing it means that you must make the best of what you have until you can (eventually) circle back to building out your toolkit. Other times, the infrastructure you're working with could be locked in so that you do not have access to all of the bells and whistles that would allow you the best of all worlds.
As long as you understand the caveats you're working with as they pertain to scripting out reapeated processes, scripts can save countless minutes (which eventually add up to countless hours). They also remove the need to copy and paste a password, where there is only downside if something doesn't go as expected. ("Oops, that wasn't the gif I meant to paste into chat.") To that end, here is an example of something you could add to a .bashrc that will run in most linux environments* to allow you to jump directly into a postgres client.
(*There are far more powerful options in most modern systems, such as a stronger regex parser than basic sed, but the idea is to make this as portable as possible.)
jirapsqljump () { |
The only things that would serve as prerequisites for this are:
- The postgres client must be installed on the workspace you run this from.
- Your ssh connection must be configured and keyed properly so that you can normally connect to the application server with "ssh jirahostname".
- The user you connect with can either directly read the dbconfig.xml file or can do so via sudo (in which case, just make it "sudo cat" instead of "cat"!)
From there, the expected functionality is "jirasqljump hostname [path to dbconfig]" and line by line does the following:
- Return if missing a host – change the return code to match your other functions accordingly.
- Autofill the path so you can exclude it if you traditionally manage systems with the same data path for Jira applications – update CFGPATH accordingly.
- Connect to the supplied host to slurp in the config file to a local variable.
- Use sed to parse out the database password from said slurp – if your database password contains the string <password>, well, we're going to need something more like perl and less like sed for the regex parsing.
- ...username...
- ...hostname...
- ...port...
- ...database name...
- Create a temporary tunnel through the host to the database port via a background ssh – if the port the host uses is also in use for you locally, simply update this (and the following connection line) to an available port (e.g. -L 9999:$SQLH:$SQLN).
- Connect to the database via the tunnel (note: this will, in effect, hold the tunnel open so that instead of closing at the end of 'sleep 10' it will instead close immediately once the psql client connection closes).
If all is working correctly, it looks like this when put into action:
~$ jirapsqljump jira_dev_hostA |
Which makes it a lot easier to do database-related work until the previously considered ideal world can be fully realized.
Sign up to receive more great content
Learn more about Atlassian and how Isos can help by signing up to receive our latest blogs, eBooks, whitepapers and more.