Resolved about who should start Progress DB and services?

Hello,

I know this may be a basic question. I have a third party company who installed my Progress system (Red Hat Linux), an application based on 4GL, etc. I received some basic training on how to start the database and stuff (I mean apps server services). My background is mainly Oracle, so I can only have some assumptions on how things work. The problem is I can't sometimes get an exact answer from my third party, that's why I would like you to help me a bit.

We use a script setup to start the database and services. I also wrote (over the course of a few weeks) a script that monitors the part that have to be running. This is what I need and check - for clarity just some snippets...:

Code:
# Check if Admin Server is running
proadsv -q
proutil package -C holder

# Name server running?
nsman -i NS1 -q

# ASBMAN broker check...
asbman -i AccordLive -q

This is the code that starts the datebase:
Code:
#*** Remove comments as required
 proutil package -C holder 1>/dev/null
 retcode=$?                                       # this saves the return code
 case $retcode in
        14) echo "The database is in maintenance mode and will not start."
            echo "If this is unexpected call BCP Support on 0161 355 3002"
            exit;;
        0) proserve package -pf broker.pf         # Serve the database
            probiw package                         # Enterprise Progress
            proapw package                         # Enterprise Progress
            proapw package                         # Enterprise Progress
            proserve package -pf sqlbroker.pf      # SQL - Unixware problem
            prowdog package                        # Enterprise Progress
         sleep 5                                # Pause 5 seconds
         asbman -i AccordLive -stop 1>/dev/null # App server
#         wtbman -i wsbroker1 -stop 1>/dev/null  # Web server
         sleep 5                                # Pause 5 seconds
         asbman -i AccordLive -start            # App server
#         wtbman -i wsbroker1 -start             # Web server;;
 esac

Normally the start script is supposed to be executed from the ROOT account (the WHO in the subject). However I once received some vague information that some of the services should not be started as ROOT, but database admin. The UNIX account for that is called "bcp", I can (and usually do) start the database as that user, but then I get another confused message that one service has to run as ROOT.

Can anyone shed some light on this subject?

I believe the DB and software was installed as "bcp", but I am not sure. I was not involved (sadly) in the installation process, as I would have seen it.

I would appreciate your thoughts on what approach you all have?

Thanks,
Richard
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
OpenEdge requires you to install it as root, but beyond that, using the root account is not a *Progress* requirement. As a general rule, it is a best practice not to use the root account to run application software. Root is all-powerful. In theory, if someone compromises your application's security (or Progress' security) then they can take over the box. Whereas if the database and application processes run in the context of a user account, an account takeover can only do whatever that account has privileges to do.

I can't advise you on how to run your vendor's software. But the user that can start the database depends on the file permissions. If the database files were owned and updateable only by root then only root would be able to start it. But if they are updateable by your bcp user then I think it's preferable to have that user start the database, rather than root.
 
Thanks for the answer, I understand there are no specific Openedge Progress requirement as to who should run the software, it's all up to the one who installs it. Then it is actually up to my vendor to tell me what processes have to run as ROOT or not.

Cheers
Richard
 

TomBascom

Curmudgeon
and why. If they tell you something needs to be run as root they ought to be able to explain why.

Chances are good that they won't be able to give you an explanation better than "because we said so".

In truth laziness about file permissions is what it usually boils down to.

For instance.... someone once ran something as root (probably because that was a bad habit they learned in the dim past) and a file that the application needs got created with root as the owner then all of a sudden non-root users start to run into permissions problems accessing that file. This becomes enshrined in folklore as "the application must run as root".
 
Speaking about permissions (and bad habits) have a look at the perms on the DB:
Code:
-rw-rw-rw-    1 root     root       782522297 Feb  7 14:05 package.lg
-rw-rw-rw-    1 root     root      5431623680 Feb  7 14:05 package_7.d1
-rw-rw-rw-    1 root     root     21185429504 Feb  7 14:05 package_8.d1
-rw-rw-rw-    1 root     root        19402695 Feb  7 14:05 backup020.63
-rw-rw-rw-    1 root     root      1901723648 Feb  7 14:05 package.b1
-rw-rw-rw-    1 root     root      5381816320 Feb  7 14:05 package_9.d1
[my-name]@SomeServer pack]$ ls -ld .
drwxrwxrwx 24 root root 36864 Feb  7 14:04 .

Beggars belief, but any comments from me on changing this are met with dead silence.

Richard
 
Last edited:

cj_brandt

Active Member
you could tell them that those permissions don't meet your company's security standards.

Usually saying something about their setup fails our company's security audit is the best motivation I have with vendors.
 

TomBascom

Curmudgeon
Well "backup020.63" tells me that someone is *running* as root (or has a cron job running as root). So it isn't just that root did the install and then went away.

Once upon a time... at a very large corporation running a very mission critical system... they were having a lot of problems with reliability. Many mysterious db crashes etc. For quite some time my colleagues and I had been trying to convince The Powers to please STOP using "kill -9" as the solution every time a user called the help desk to complain that their session was "hung". But the "cowboy" mentality was strong and belief in black magic far easier than implementing common sense.

One day I happened to walk by a printer... On that printer was a list of user ids and passwords. Including root.

I went back to our "war room" and presented this to the person in charge of our little team. He decided that he had had enough... so he had us change said root password (I won't reveal who actually executed the command). Shortly thereafter we got a puzzled call (because all problems were our problems...) asking if we had any idea why root couldn't login. Our leader answered "yes". After some amusing probing he eventually refused to reveal the new root password, basically telling them that they did not have a need to have that kind of access. This was a bit of a problem since none of the sysadmins happened to be logged in. (We all worked for the same company - so we weren't messing around with a *customer* - merely taking care of internal issues.) Local escalation was attempted with no success. Escalation continued up a few levels (big company HQ was elsewhere) and eventually we got a very high mucky muck on the line wanting to know what was going on and why we were being such dickheads.

Recall that we are in a "war room" and that some pretty high profile stuff had been going on for a while - so we're not exactly a rogue gang of anarchists that need to be put down...

A conversation ensued about security, proper change control, and the sorts of things that needed to be happening if the problem that we were tasked to be solving was ever going to be resolved. Commitment to not hand the root password out like candy on every printer was obtained. Along with a few other concessions -- like maybe they won't just "kill -9" every user whenever there is the slightest problem.

We did actually start to improve things after that and eventually got the whole mess (and it was a huge mess) squared away. It took a lot more and there were additional exciting moments (the customer CIO might have thrown a few chairs) but the "root password incident" is something that I fondly remember from those days.

Anyhow -- you don't need to be root to run a Progress application. And if someone thinks that they do need root they probably aren't competent to be running your systems.
 

RealHeavyDude

Well-Known Member
Exactly. Rogue system admins are the worst nightmare of every serious dba. Only use root privileges when they are absolutely necessary.

We run our whole backend on Sun Solaris SPARC under a project user which does not even have interactive login capabilities on the operating system. Only dedicated dba accounts have to privileges to elevate themselves to assume that project user's identity to be allowed to executed selected scripts. Apart from performance ( which is another story ) we never had any stability or security issues.
 
Top