Unable to attach to shared memory

After booting my SCO OpenServer 5.0.6 with IDS 7.30, all is well as long as you are "root". However, if you log in as "informix" you get the following message in onmonitor attempting any command. If you perform a total SHUTDOWN of IDS from "root" and start it under "informix", then all works as designed and "root" can do stuff too! BTW, shared memory has the same owners and groups if started by user informix but different IDs. Client connections work fine as well as ontape. onstat get the "permission denied" stuff, too! Does anyone have a clue why this peculiar behavior exists and what is the prescribed cure? ONMONITOR messages: ------------------- Unable to attach to shared memory. Permission denied IPCS messages: -------------- IPC status from /dev/kmem as of Mon Feb 5 16:18:43 2001 T ID KEY MODE OWNER GROUP Shared Memory: m 0 0x52564801 --rw-rw---- root informix m 1 0x52564802 --rw-rw---- root informix m 2 0x52564803 --rw-rw-rw- root informix m 3 0x52564804 --rw-rw-rw- root informix m 4 0x000018e5 --rw-rw-rw- root sys m 5 0x000029f9 --rw------- root root Sent via Deja.com http://www.deja.com/

jayachtee@my-deja.com wrote in message <95n63m$iki$1@nnrp1.deja.com>... >After booting my SCO OpenServer 5.0.6 with IDS 7.30, all is well as >long as you are "root". However, if you log in as "informix" you get >the following message in onmonitor attempting any command. If you >perform a total SHUTDOWN of IDS from "root" and start it >under "informix", then all works as designed and "root" can do stuff >too! BTW, shared memory has the same owners and groups if started by >user informix but different IDs. Client connections work fine as well >as ontape. onstat get the "permission denied" stuff, too! > >Does anyone have a clue why this peculiar behavior exists and what is >the prescribed cure? My guess is that someone has made a mess of the permissions or ownerships or accounts somewhere. Here are the rules from the top: user accounts. Correct these (where necessary) in scoadmin so as to ensure consistency of the underlying O/S files. Depending on the security level you've picked for the O/S, it may be impossible to merely edit /etc/passwd and /etc/group. These days, that's frowned upon anyway. root account must have uid number of 0 and ideally gid number of 0 too. I've seen some machines with gid=3 (ie some type of sys group) but I don't like that and normally change it - but don't change that if you have strong security levels. We don't want the Trusted Computer Base to shut itself down! No other user should have these numbers (especially 0) as their numbers! I've seen some over-excited novice administrators give themselves effective root perimssions under a different name, but that's begging for trouble. Used to do it meself once - the shame, the shame!-) If you have to correct any nonsense with the root account, reboot the machine. user group informix must exist and must have it's own private gid number not shared with any other group. user account informix must exist, must have it's own private uid number not shared with any other user. I recently visited a customer, and someone there had got the bright idea to remove the informix account. Nice. "why is *this thing* happening?" came the plaintive cry... The informix account's group number must be the informix group number. Informix should not be in any auxiliary groups. User account informix must be the only user in the informix group. If you put any other user into informix group, you risk them being able to casually perform some actions which can compromise the integrity or functioning of the engines. Hokay, so that's the rules on accounts taken care of. About file permissions of the informix products: Some of the files in the informix directory must have specific ownerships and permissions. If someone has been messing around with chown, chgrp or chmod then you will be in trouble. Careless use of tar or cpio can also make a mockery of file permissions and ownerships. Here's a ksh ritual to ensure your product file permissions are correct: "login as root" "stop the engines" cd $INFORMIXDIR ls -lsaR > /tmp/before.lst grep -hv '^#' etc/*files | while read file uid gid mode junk; do [[ -a "$file" ]] || continue chown $uid:$gid $file chmod $mode $file done ls -lsaR > /tmp/after.lst diff /tmp/before.lst /tmp/after.lst If any differences pop out, then indeed the permissions were screwed up, but now they isn't. Finally, about the chunks attached to the engine: all raw space and/or cooked files must have owner and group of informix:informix and the permissions must be 660 - the number of the beast's dog. Permissions of any symbolic links used are irrelevant - it's only the permissions of the chunks they point to that count. Oh, I suppose I should add: if you have your symbolic links in a subdirectory in a specific place, it's probably a good idea that informix:informix can read and explore the directories! So apply this same rule to any directories holding symbolic links. chown informix:informix all-your-chunk-names chmod 660 all-your-chunk-names For the directories holding the symbolic links, you may relax them a bit by: chmod a+rx directory-names which at least allows ordinary people to have a quick look into the directories. And then, Gentlemen, start your engines... Gentle Ladies too please. One more tip with SCO, and maybe any other O/S that supports the concept of an immutable login ID - if you are starting the engine with a script in /etc/rc2.d, the engine may be started with a luid of -1. This is bayd, M'kay? It causes problems. Start the engine with this line: cd $INFORMIXDIR # bonus hint - no explanation su -c informix oninit The su command sets the luid prior to executing the command on behalf of the named user. __END__ Andrew Hamm Technical Consultant Sanderson Australia Pty Ltd e-mail: <mailto:ahamm@sanderson.net.au> web: <http://www.sanderson.net.au>; -- "Having fun is half the fun" - Guru Adrian No matter what happens, somebody will find a way to take it way too seriously - Micheal Tod (wishes he said this)

Thanks for all the input... I check everything! This server got a complete physical. Of course, all file permissions were correct (suid and all), all chunks were owned properly. However, ONE thing did escape my first attempts at find the problem. A simple KAIOON=1; export KAIOON in the "informix" users profile that was not in the startup scripts profile! One this situation was remedied, all works as advertised! In article <95n63m$iki$1@nnrp1.deja.com>, jayachtee@my-deja.com wrote: > After booting my SCO OpenServer 5.0.6 with IDS 7.30, all is well as > long as you are "root". However, if you log in as "informix" you get > the following message in onmonitor attempting any command. If you > perform a total SHUTDOWN of IDS from "root" and start it > under "informix", then all works as designed and "root" can do stuff > too! BTW, shared memory has the same owners and groups if started by > user informix but different IDs. Client connections work fine as well > as ontape. onstat get the "permission denied" stuff, too! > > Does anyone have a clue why this peculiar behavior exists and what is > the prescribed cure? > > ONMONITOR messages: > ------------------- > Unable to attach to shared memory. > Permission denied > > IPCS messages: > -------------- > IPC status from /dev/kmem as of Mon Feb 5 16:18:43 2001 > T ID KEY MODE OWNER GROUP > Shared Memory: > m 0 0x52564801 --rw-rw---- root informix > m 1 0x52564802 --rw-rw---- root informix > m 2 0x52564803 --rw-rw-rw- root informix > m 3 0x52564804 --rw-rw-rw- root informix > m 4 0x000018e5 --rw-rw-rw- root sys > m 5 0x000029f9 --rw------- root root > > Sent via Deja.com > http://www.deja.com/ > Sent via Deja.com http://www.deja.com/

jayachtee@my-deja.com wrote in message <95pqef$sn2$1@nnrp1.deja.com>... >Thanks for all the input... I check everything! This server got a >complete physical. Of course, all file permissions were correct (suid >and all), all chunks were owned properly. However, ONE thing did >escape my first attempts at find the problem. A simple KAIOON=1; >export KAIOON in the "informix" users profile that was not in the >startup scripts profile! One this situation was remedied, all works as >advertised! > Oh yeah - and if you are using KAIO, check KAIOON because the release notes say ..... D'OH! seems like informix has a problem with the utilities understanding the engine if KAIOON is not set appropriately when KAIO is used. Why is this so?

It does all seem so PRIMATIVE! I guess that is just the nature of the beast... Maybe I should refrain from reading TOO much in the future. Hacking is much more rewarding when you get to the peak of K2! In article <3a8080bc$1@news.iprimus.com.au>, "Andrew Hamm" <ahamm@sanderson.net.au> wrote: > jayachtee@my-deja.com wrote in message <95pqef$sn2 $1@nnrp1.deja.com>... > >Thanks for all the input... I check everything! This server got a > >complete physical. Of course, all file permissions were correct (suid > >and all), all chunks were owned properly. However, ONE thing did > >escape my first attempts at find the problem. A simple KAIOON=1; > >export KAIOON in the "informix" users profile that was not in the > >startup scripts profile! One this situation was remedied, all works as > >advertised! > > > > Oh yeah - and if you are using KAIO, check KAIOON because the release notes > say ..... > > D'OH! > > seems like informix has a problem with the utilities understanding the > engine if KAIOON is not set appropriately when KAIO is used. > > Why is this so? > > Sent via Deja.com http://www.deja.com/