As you all probably are painfully aware, root access is required to do installations. In a larger group or set of groups this sometimes presents an issue. I was wondering what some of you have done to get around this?

I've poked about a bit for any real solutions, but have turned up nothing of value, perhaps I'm using the wrong magic words.

DB2 code release "SQL08020" with level identifier "03010106".
Informational tokens are "DB2 v8.1.1.64", "s040812", "U498350", and FixPak "7".
DB2 Enterprise Server Edition 8.2

We are temporarily given root access for the install. The SAs give it a temp password then change it back when we are done. Sometimes they are sitting with us to make sure we don't do anything stupid.

Julie

Thanks for the reply.

I thought about that ... but having recently moved from the SA arena to the DB side, I can poke holes full of that before I even ask. For starters, it's incredibly easy to change more than just database related objects, either accidentally or intentionally. Also, instance creation is not always done on a new box, sometimes we add to an existing installation on a production system.

Sitting the SA/DBA down together is a viable solution if you are in one building, but we have teams across the country and sometimes we're separated by two timezones and thousands of miles.

In this time of SOX compliance requirements, it's hard to do anything easy anymore.

I was thinking that adding sudo entries to allow the DBA to run the various scripts as root might be a potential solution but I was hoping there was a glamorous solution out there, or at least an accepted one I with which could make a case.

Most places I have been have the SA run the install script to lay down the DB2 code, and then give the DBA's sudo root athority on the DB2 paths to do instance creates, instance upgrades, etc.

I'm with you on the sudo, but do they really wildcard the paths? That's really dangerous. I was thinking more like identifying 5-6 executables or scripts that need to be able to run as root (read only of course).

All the executables that DBA's need are under the "instance" sub-directory in the DB2 install (or alternate fixpack) directory. I can't think of any executables in that directory that a DBA should not be given authority to run with sudo root.

Understood ... but if sudo permission (via sudoers file) is given for the directory:

dba_account workstation = /usr/local/instance_dir/blah/*

... and the DBA's own that directory as well (common) then they could conceivably put a potentially malicious piece of code in that directory and execute it as root. In addition, if a particular script supports shell escapes, that leaves a pretty big hole.

So, I agree with you that they should be in charge of their own destiny, but I guess the SA in me (not too distant past) gets a little worried at wildcard anything.

What's really ironic is I never saw the requirement to run anything as root to create an instance as a particularly bothersome situation when I was an SA. Now that I (my group actually) doesn't have root access, I feel the pain.

The directory that DBA's need sudo on is not the directory for the instance (which is the home directory of the instance owner), but literally the instance sub-directory of the DB2 binaries.

For example on AIX that would be:

/usr/opt/db2_08_01/instance

I believe that on Linux it is:

/opt/IBM/db2/db2_08_01/instance (or something close to that)

Marcus,

I understand what you are saying. I'm the new guy here; you seem to be knowledgeable and definitely a prolific poster on this forum. I'm trying not to argue with someone who took the time to answer one of my questions. Really. :-) I'm just pointing out why someone reading this may not get a wildcard or why an SA would not want to do it.

A brief glance at those scripts shows that they do trap exits but I have not checked them all. A security conscious SA would be well advised to look at them all, or perhaps even put them in a wrapper.

Aside from installation, are there any other scripts in any other locations that you can think of that need to be run by root?

You can argue with me if you want to. The number of posts I have made is not relevent.

I didn't mean that a wildcard has to be used on that directory, just that the DBA's needs sudo on all the DB2 commands in that directory.

The only commands that I know of that DBA's need sudo on are located in /usr/opt/db2_08_01/instance (different for other OS's).

I'm just trying not to be an annoying new guy is all ... whether that's possible for me is another thing.

Thanks for the information, I'll talk with the SA's about this next week and see what happens.