UNIX for Advanced & Expert Users

Hello all,

I have a question about what you think the best practice is to determine what region you are running on when you have a system setup with a DEV/TEST, QA, and PROD regions running the same scripts in all.

So, when you run in DEV, you have a different directory structure, and you don't want to email the entire group when you are testing something and you abend.

We use the hostname to determine what box we are running on, then a case statement that has the box names hardcoded.

Right there is the problem. Our hardware group just moved us from one box to another, and even though they kept the old DNS available and pointing to the new box, the hostname found the new box name - and nothing worked.

Yes, we missed the fact that the hostname was hardcoded in the common environment script, but this is where my question comes in.

What do you do to prevent having to make ANY changes to your scripts when the hostname changes due to a box move, but you can still tell you are running in DEV or QA or PROD?

The only thing that comes immediately to mind is a file located on each box, uniquely named for that box - something as simple as prod.dat, qa.dat, dev.dat. If one of those files exist, a case tells you what region you are in. However - that also has risk. Some newbie deletes it. If it's hidden - what if the SA doesn't copy it to the new box?

Another approach... Move all the 'environmental' depend dependencies from being 'hard-wired' in the script itself into a separate configuration script which gets "sources" by the 'main' script.
One of the settings in the config file could be:

Code:

# dev test prod
ENVIRON='dev'

You could reference the var ENVIRON in your main script and make needed choices without changing the script itself.
just my $.02

A script shouldn't know need to know or care whether it's in dev or production; never hardcode anything.

Directory paths: if [ "$HOSTNAME" = "DEV" ] is a bad idea. Do something like . /etc/myservice.conf. Then do sanity checks on every path to make sure they're valid and have sufficient access permissions, etc, etc, etc. If they're not, clearly log which one has failed and why before exiting safely. Use one myservice.conf in development, ship another to install it somewhere else.

Email: Depends on how your script handles that. It may be possible to leave it up to the server where email goes.

For that matter: Why are the settings so different in your development server than your deployment ones?

We have a configuration script - and we have used the type of approach you are talking about. However, that means that the environmental scripts are not IDENTICAL between the regions, which is something you want to prevent things being added and removed are done for each region. We also use PVCS for promoting, and each script should work as is, untouched, in each region.


I agree! However, we have not found a good alternative to this one.

To answer your last question first - at one time we had our DEV and QA regions on the same box. Therefore we could not have (ex) /app/scripts represent our scripts directory for both DEV and QA. So, we came up with /app/test/scripts for dev, and /app/prod/scripts for BOTH QA and Production. The theory is that QA should look exactly as production does, hence the same directory names.

Other things also create a need to handling things differently between regions, such as dealing with different DSNs on the MVS we have to communicate and send files to. Their dev region names are TEST.D, QA is TEST.X, prod is PCS.P. Our environmental script that determines what region we are running in, sets variables to build the correct DSN on the MVS, which may be participating in the test. The email thing - that's a safety feature. If a developer (and that's who we are - developers trying to figure this best practice) is working on a project, pressed for time, and everyone's hollering about getting the test emails, he can tell the script that when in DEV, send them to his email. Then if he forgets to change that back to the group email - the script handles it by saying "When I'm running in prod, send the email to the group".

Your first suggestion - sanity checks on directory names. If the directories are identical between QA and PROD, then directory checks to determine differences in the regions would not be able to tell the difference.

If you're not willing to use config files, you should enforce the same configuration on all three servers so your scripts don't have to change. Install symlinks if necessary.

Until you do, something, somewhere, will always have to know all the per-server settings for each server.

But why's it handled in your script and not on the server? Have the default sendmail address or somesuch end up in a mailing list on your dev server, or the other proper destination in production, instead of hardcoding different behavior in your script. That's not what they're for, and checking like you suggest isn't something your script ought to be doing.

Either use config files, or enforce the same configuration everywhere, don't build an unmaintainable rube-goldberg machine.