I have a cache warming script I want to start in response to a certain server-side event. That script needs user credentials to perform its job (read-only account). So far I have avoided automating this process because I didn't want to store ANY credentials on the server, but I've come to a point where I really need to automate the process. The server is CentOS 6.

I know storing any credential is a risk, so I'm curious what the industry standard is if I can't be at a terminal to enter a credential every time I need this process to run.

Update The root question: If it is NOT ok to have credentials stored in the clear, what are the other options?

2 Answers 2


To avoid using the credentials completely, decouple the trigger of the cache warming script from the server-side event.

The concept is:

  • server-side event sets a flag in a shared location
  • persistent process run by cache warming script user monitors that shared location
  • if persistent process sees flag is set, flag is cleared and cache warming script is run

Since the persistent process can be run via cron or as a daemon owned by the cache warming script user, you just set that up once, never need to pass user account credentials.

Shared Location:

Decide on a shared location that can be accessed and written to both by the server-side event and the user that needs to run the cache warming script. In a system with a database, this could be a variable in a configuration table. But this could also be just a file in a directory that is +rw by both users and is touch'd by the server-side event.

Setting the flag:

If you are using a database, an example of setting a flag would be if you have a variables table that has key and value columns, setting a particular key's value to 1. If its a file, it would be the existence of a file.

Side benefits:

If you need to restrict how often the cache warming script is run, you can always implement logic in the persistent process to keep track of the last time the script was run to prevent overuse if something goes bad.

You can easily add multiple triggers of the cache warming script from other server-side events because the method of triggering the script is hidden behind the shared location interface.

  • Thanks, but the cron job entry would still need to pass a password to the cache warming script, and that password would then be in the clear in the crontab, right?
    – Jeremy Mullin
    Commented Jan 17, 2013 at 19:56
  • Perhaps that would be OK if the cron job was running on a different machine in the data center that was not exposed to the internet...
    – Jeremy Mullin
    Commented Jan 17, 2013 at 20:06
  • If you create a text file that is only readable by the cache warming script user that contains user/password, but give it 600 permissions, have a script read in the file to get the credentials, then only that user will ever be able to see it. That's something else the decoupling enables to be more secure because its a user other than the web server user. If not acceptable to have user/pass in a file like that, you might change the call to the web site to use a different authentication like using OAuth2, or use IP address restrictions so only that one machine could hit a particular URL.
    – Jeremy Zerr
    Commented Jan 17, 2013 at 21:28
  • Thanks, I guess that's the root of my question, if it is NOT ok to have credentials stored in the clear, what are the other options?
    – Jeremy Mullin
    Commented Jan 17, 2013 at 21:33

Regarding the update: If it is NOT ok to have credentials stored in the clear, what are the other options?

Generally once an entity wants to authenticate itself to a service, the entity must have an authentication token. That said, if you are using password authentication and want to do it automatically, you must make the password accessible somehow somewhere in plaintext - otherwise you'd need another token to transform it from safe" form to plaintext.

Getting back to your original problem, it's always good to consider who, why and how somebody might (want to) misuse the credentials (if they were in plaintext file readable only by the user running the cache warm-up script for example). It may turn out that securing it doesn't make much sense or that the overall security concept of the project is flawed.

You might want to ask on Security SE - chances are you'll more in depth answer there.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .