natebsi (AT) gmail (DOT) com wrote:
Any question of 'nosuid' options when the file system was mounted?

Most of the suggestions have been pretty much spot on, but if you were
running ON-Monitor as user informix, it should have worked almost
regardless.

Older versions of ON-Monitor were suid root. It shouldn't be necessary,
and could be dangerous (for example, if you do a shell escape, is the
shell running as root or informix or the user who runs ON-Monitor), but
you might try it cautiously to see if that resolves the problem.

If there are other instances in directories under /dbms, then it is
unlikely to be a problem with 'nosuid' options.


--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler (AT) earthlink (DOT) net, jleffler (AT) us (DOT) ibm.com
Guardian of DBD::Informix v2007.0226 -- http://dbi.perl.org/

On Jul 26, 9:28 pm, Jonathan Leffler <jleff... (AT) earthlink (DOT) net> wrote:
Thanks for the reply Jonathan.

Here is all of the file systems on this box (from /etc/fstab):

INFORMIX:asp27[calcotest] /etc$ cat fstab
/dev/vg00/lvol3 / vxfs delaylog 0 1
/dev/vg00/lvol1 /stand hfs defaults 0 1
/dev/vg00/lvol4 /tmp vxfs delaylog 0 2
/dev/vg00/lvol5 /home vxfs delaylog 0 2
/dev/vg00/lvol6 /opt vxfs delaylog 0 2
/dev/vg00/lvol7 /usr vxfs delaylog 0 2
/dev/vg00/lvol8 /var vxfs delaylog 0 2
/dev/vg00/lv_swap2 swap swap pri=2 0 0
/dev/vg00/lv_swap3 swap swap pri=3 0 0
/dev/vg00/lv_swap4 swap swap pri=4 0 0
/dev/vg01/asprsp_fs /asprsp vxfs rw,suid,largefiles,delaylog,datainlog
0 2
/dev/vg01/dbms_fs /dbms vxfs rw,suid,largefiles,delaylog,datainlog 0 2
/dev/vg01/alum_fs /asp/alum vxfs rw,suid,largefiles,delaylog,datainlog
0 2
/dev/vg01/alumtest_fs /asp/alumtest vxfs
rw,suid,largefiles,delaylog,datainlog 0
2
/dev/vg01/calco_fs /asp/calco vxfs
rw,suid,largefiles,delaylog,datainlog 0 2
/dev/vg01/calcotest_fs /asp/calcotest vxfs
rw,suid,largefiles,delaylog,datainlog
0 2
/dev/vg01/workarea_fs /workarea vxfs
rw,suid,largefiles,delaylog,datainlog 0 2
/dev/vg01/fms_fs /asp/fms vxfs rw,suid,nolargefiles,delaylog,datainlog
0 2
/dev/vg01/fmstest_fs /asp/fmstest vxfs
rw,suid,largefiles,delaylog,datainlog 0 2
/dev/vg01/calcoqa_fs /asp/calcoqa vxfs
rw,suid,largefiles,delaylog,datainlog 0 2
/dev/vg01/dbms_calcotest /dbms/calcotest vxfs
rw,suid,largefiles,delaylog,datain
log 0 2


The last entry was the file system I created tonight to see if it
would solve the problem. I usually choose pretty much default options
when creating a file system in HP (except for always allowing large
files). I'm wasn't quite clear if you were suggesting to try nosuid or
not, but I went ahead and changed /dbms/calcotest to be nosuid:

asp27:/etc # grep nosuid /etc/fstab
/dev/vg01/dbms_calcotest /dbms/calcotest vxfs
delaylog,nodatainlog,largefiles,rw,nosuid 0 2

But it doesn't help. Same error. Note that I get a warning message
now, but I guess that is expected:

INFORMIX:asp27[calcotest] $ onmonitor
/dbms/calcotest/informix/bin/onmonitor: Setuid execution not allowed

-Nate

I suggest re running the install script

That will reset the permissions on everything

On Jul 27, 7:50 am, scottishpoet <drybur... (AT) yahoo (DOT) com> wrote:
Thanks, but I've done a clean install several times now.

On Jul 26, 9:56 pm, nate... (AT) gmail (DOT) com wrote:
Sorry - I was trying to suggest that if you had the nosuid option set,
then it could cause problems -- and, as you demonstrated, it does
cause a small problem. However, if you are running as informix, it is
pretty much immaterial.

Redo the mount permitting suid programs.

Are these journalled file systems? I don't see how or why that would
matter...

You showed the contents of /etc/vfstab -- but the output of running
'mount' might reveal something. That is, on most systems, running the
mount command with no options produces a list of the mounted files
systems, along with the corresponding options. On my machine, it
lists 103 file systems (!), most of them Clearcase VOBs.


Very odd. From what I remember of the thread, you've been going
through the correct motions - checking the right things, changing
them.

Have you checked for ACLs? If there was some weird ACL-based
permission (or prohibition) on the file? But you have to be trying
pretty hard to run across that sort of issue.

Desparation measures: have you tried running ON-Monitor under the HP
equivalent of truss or strace -- a system call monitor that logs
everything. You'd send the output to a file. On Solaris, "truss -o
onmonitor.truss onmonitor" would do the trick. When the program
fails, we'd be able to see the system call(s) that failed and
triggered the error message -- probably an open(), maybe a creat().
And you'd see the file name. And this might give us a surprise - we
may have been looking at completely the wrong file. Or it might tell
us nothing.

-=JL=-

On Jul 27, 10:05 am, nate... (AT) gmail (DOT) com wrote:
Well, perhaps the error message is wrong or misleading. What you
could try and do is if you have the HP utility tusc (if you don't have
it I believe it's downloadable from HP), you could start up onmonitor,
then run tusc against the pid (I believe you can do that as it's like
the solaris truss facility). Then attempt to make the onconfig
modification, get the error and look at the end tusc file and look for
failed opens or stats or something and check to see if maybe the file
that's really failing on is the onconfig or if it's really
$INFORMIXDIR/etc, or if it some completely different file and the
error message is not reporting it correctly.

Before I answer anyones questions, a little more info:

I downloaded FC5 and HC6 last night. Doing a clean install, FC5 has no
problems with onmonitor. Using HC6, onmonitor has problems, but a
slightly different error:

Operating system error: 9.
Press Return to continue.

Operating system error: 9.
WARNING: Cannot write to $INFORMIXDIR/etc.


That error matches http://www-1.ibm.com/support/entdocv...UpdateReferer=

Which since you need a login to see that, it says this:

IC51682: ONMONITOR RETURNS AN ERROR -9 AND "CANNOT WRITE TO
$INFORMIXDIR/ETC" WHEN INITIALIZING SHARED MEMORY

APAR status
OPEN

Error description
When trying to initialize shared memory with onmonitor the
following error occurs:
Operating system error: 9.
Press Return to continue.
Pressing continue produces:
Operating system error: 9.
WARNING: Cannot write to $INFORMIXDIR/etc
Local fix
Problem summary
************************************************** **************
USERS AFFECTED:
All Users
************************************************** **************
PROBLEM DESCRIPTION:
Onmonitor returns "Operating system error: 9" while trying to
initialize shared memory.
************************************************** **************
RECOMMENDATION:
Upgrade to 10.00.xC6 when available
************************************************** **************
Problem conclusion
Problem was first fixed in IDS 10.00.xC6
Temporary fix
Comments
APAR information
APAR number IC51682
Reported component name IBM IDS
Reported component ID 5724L2300
Reported release A10
Status OPEN
PE NoPE
HIPER NoHIPER
Special Attention NoSpecatt
Submitted date 2007-01-26
Closed date
Last modified date 2007-04-25

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:



So, if I'm reading that correctly, the problem was fixed in xC6, which
doesn't make sense, since thats what I'm using. Or am I reading that
wrong? The APAR is open which is confusing.

On Jul 27, 8:52 am, nate... (AT) gmail (DOT) com wrote:
I spoke with Informix. This is indeed broken in xC6. It may be fixed
in the latest "pit drop"(sp? not familiar with that term, but he said
it was like a service pack) or in FC7.

Basically, there is an API used only by onmonitor and only for
accessing/modifying the onconfig. He said that everything else should
work fine, which has been our experience so far.

Thanks for all the replies and helpful advice, as usual! I'd be lost
without some you...

-Nate

natebsi (AT) gmail (DOT) com wrote:
A PID is a post-interim drop, also redundantly called a PID-drop.

It will have a version number such as 10.00.xC5P1 (where I think the
letter is indeed P, but there is some capital letter used, followed by a
number - and the letter is not X which would be a patch release -
one-off for a specific customer.).

A PID has a collection of fixes and some minimal level of QA, and the
changes are expected to be rolled into the next interim (eg 10.00.xC6
for a 10.00.xC5P1). PIDs are generated quite frequently - like about
every month.



--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler (AT) earthlink (DOT) net, jleffler (AT) us (DOT) ibm.com
Guardian of DBD::Informix v2007.0226 -- http://dbi.perl.org/

Jonathan Leffler wrote:
10.00.FC6W5 is the latest PID
10.00.FC6X1 is a patch port
10.00.FC6 is a vanilla interim

10.00.FC6W5X1 is a specific patch port on top of a PID
10.00.FC6W5D2 is a diagnostic