Re: informix ownership
Maria Wilson wrote:
>
> Good day all!
> I was hoping to open up some discussion on the topic of root or
> informix "owning" the database instance. I was recently troubleshooting
> another Informix db server when I noticed that all the oninit processes
> and even the raw partitions were owned and grouped by root instead of
> informix. Would anyone care to share their experiences/opinions about
> this? We have alot of DBA/SA people here - so I seem to see alot of
> this. Comments?
The ownership of the running oninit processes should be root if the
engine is started from the system startup and informix if started by
user informix from the command line. It really does not matter much
in general except that on different platforms there may be a
requirement for the owner to be root in order for processor affinity,
core dumping, NOAGE, etc to function properly. Since oninit is an SUID
program it's real and effective userid may differ if not started as
root which will cause problems core dumping and changing process status
such as aging and affinity on certain systems.
DATABASE CHUNK FILES SHOULD ALWAYS BE OWNED BY USER INFORMIX GROUP
INFORMIX AND PERMISSIONS 660! ALWAYS! PERIOD. On certain platforms,
DG/UX among them, the volume managers create device files for logical
devices on the fly at boot time so that the permissions of these files
is reset to root root 666 on reboot. In this case the rc startup
script for Informix, which must run after the volume manager script and
the filesystems are mounted, should modify the permissions on all
active database chunk files before starting the engine. This can be
done with a manually maintained chunk list or using the following loop:
for fil in `$INFORMIXDIR/bin/oncheck -pr|awk '/Chunk path/{print $3;}'`
do
echo "Fixing permissions for $fil"
chown informix $fil
chgrp informix $fil
chmod 660 $fil
done
This will work for all versions of online (substituting tbcheck for 5.x)
except for 5.06 which fails if you have an empty chunk slot in the
chunk table page from having deleted a chunk.
Art S. Kagel