HP-UX

Hi,
I need to use SAM on HP-UX 11.11.
SAM was working fully but now when I try to view the "Configurable Parameters" SAM comes back with an empty window.
I think it may be related to some security rules I implemented but cannot be sure (mainly permissions tightening).
I have checked /usr/conf/master.d/* and all files have the recommended permissions etc and also these permissions match those on another HP-UX machine where this feature of SAM is still working.

The security changes were applied as rules so I can't possible back track woth any great effectiveness.

HP won't support due to security changes.

Any ideas.....??
Am I even on the right track thinking it may be the permissions changes???
Is SAM not able to read some file that lists the configurable parameters????
In real trouble with this one as its a live machine.

I also have HPUX 11i systems. When you say you implemented "security changes that can't be back tracked". What do you mean by that???

First, I would go back and undo whatever you did. If you changed the permissions on the master.d/* files, change them back. When I look on my box I see that all the files are read only except for one file. It is called "krm". This file is 644. All the rest should be 444. Also, it is owned by root:sys all the others are owned by bin:bin. Hope this helps.

root:/usr/conf/master.d
# ll
total 308
-r--r--r-- 1 bin bin 4263 Nov 5 1999 SCentIf
-r--r--r-- 1 bin bin 4187 Mar 8 2002 autofs
-r--r--r-- 1 bin bin 3878 Jun 14 2001 btlan6
-r--r--r-- 1 bin bin 19314 Jun 26 2001 core-hpux
-r--r--r-- 1 bin bin 3808 Jan 11 1999 corelan
-r--r--r-- 1 bin bin 1878 Oct 24 1997 dlkm
-r--r--r-- 1 bin bin 4028 Dec 19 2001 evp
-r--r--r-- 1 bin bin 3504 Sep 21 1998 fcgsc
-r--r--r-- 1 bin bin 5828 Jun 15 2001 fcms
-r--r--r-- 1 bin bin 1043 Jun 1 2000 fs-tune
-r--r--r-- 1 bin bin 719 Dec 1 2001 func0
-r--r--r-- 1 bin bin 4317 Feb 9 2002 gvid
-rw-r--r-- 1 root sys 951 Aug 29 2000 krm
-r--r--r-- 1 bin bin 4094 Jul 20 2001 lan
-r--r--r-- 1 bin bin 3768 Dec 12 2001 lan100bt-core
-r--r--r-- 1 bin bin 4310 Oct 24 1997 lvm
-r--r--r-- 1 bin bin 3682 Dec 12 2001 maclan
-r--r--r-- 1 bin bin 4576 Apr 9 2002 net
-r--r--r-- 1 bin bin 4596 Mar 8 2002 nfs
-r--r--r-- 1 bin bin 3991 Oct 24 1997 nms
-r--r--r-- 1 bin bin 490 Jun 22 1999 pmon
-r--r--r-- 1 bin bin 4002 Nov 7 1997 proc-resrc-mgr
-r--r--r-- 1 bin bin 491 Dec 17 2001 scsi-disk
-r--r--r-- 1 bin bin 1332 Dec 7 2001 scsi-tune
-r--r--r-- 1 bin bin 4309 Jun 14 2001 side
-r--r--r-- 1 bin bin 4321 Mar 13 2000 sioflop
-r--r--r-- 1 bin bin 4275 Oct 24 1997 spt
-r--r--r-- 1 bin bin 6489 Oct 24 1997 streams
-r--r--r-- 1 bin bin 4609 Oct 24 1997 streams-telnet
-r--r--r-- 1 bin bin 4749 Oct 24 1997 streams-tio
-r--r--r-- 1 bin bin 4226 Nov 4 1999 superio
-r--r--r-- 1 bin bin 349 Sep 27 2000 sysvipc-tune
-r--r--r-- 1 bin bin 3164 May 9 2001 td
-r--r--r-- 1 bin bin 4726 Oct 5 2001 usb
-r--r--r-- 1 bin bin 260 Jun 22 1999 vm-tune
-r--r--r-- 1 bin bin 4954 May 24 2001 vxfs


If you can't do that, you at least can use "kmtune" to modify parms. You should be able to modify any kernel parm with it.

BTW, I can't think of settings that would prevent root from seeing its own kernel parms???


It would help if you gave us some idea of what you changed.

SAM executes a number of commands on the kernel (/stand/vmunix) to produce the output for the "Configurable Parameters" window. One of these steps may be failing on your server.

The best way to see what SAM is doing is to execute /usr/sam/bin/samlog_viewer -l C /var/sam/log/samlog. This will open a window which extracts the commands executed by SAM. Scroll to the bottom to see what it was doing when it attempted to list the "configurable Parameters" and hopefully it will give you clue as to where it is failing.

SAM does run a number of executables such as kmadmin, kmsystem, kmtune and get_sysfile - some of these on temporary files it creates. One of these may be failing, or it may be failing to generate a temporary file.

Hi,
thanks a million for taking the time to reply.
If you don't mind, I'll answer you both in the one post.

The reason I am so vague on what changed on the machine is that the changes were applied by an in-house (I think) security package comprising of executables and some scripts. I think they generally do "finds" for files with group write permissions etc. or files executable by users other than the owner and then removes these permissions. It is very harsh and is not advanced enough that it produces a list of changed files or anything helpful like that!
This is why I don't even know where to start regarding going back.

Thanks though ...I was able to use kmtune to alter shmmax which was my underlying. It seems to have done it dynamically, without a need for a reboot.

All the permissions on the files in /usr/conf/master.d are as you listed 'Kelam_Magnus'. Thanks for that.

'saabir', thanks for the samlog tip. I was able to run the commands in the log one by one and found that when I run kmtune it complained that it could not open /stand/.kmsystune_lock
I created this as an empty file and I was then able to run kmtune.
SAM still displays no configurable parameters but I feel I am getting somewhere now!!

kmtune only changed your system file. Not your kernel. You need to rebuild your kernel for the change to take effect. That may not be possible since you made some random unknown changes to your system. I would re-install HP-UX. Then I would not run that "security package" again.

First, let me say that you can use kmtune with the -r option to reset them to the default value. Try this for all configurable parameters or any other kernel parms that may be changed and then apply these changes. Maybe that will help. You may have to reset all parms to the default and then restore from your OLD kernel that was in use before these problems started.

kmtune(1M)
NAME
kmtune - query, set, or reset system parameter

-r name
Reset the value of a system parameter to the default.


Now, let me say that I agree with Perderabo. Regrettably, you may need to reinstall or if possible, have your "security group " remove the patches, if that is even possible.

As an Admin, this really upsets me. I have a real problem with anyone installing patches on my box that aren't thoroughly tested on a similar test box.

For them to install untested or at least undetermined patches is a very serious problem for me. Even though it seems to be a small problem to some, if that had happened at my company, someone would be reprimanded for this type of action. In reality, this may be a much more serious problem because it might cause you to have to incur downtime to repair damage caused by another group. I don't know what sway you have, but I would let someone know that I am very displeased with the possible consequences of this security patch.

They may see this as a small problem, but I hope you will let them know the gravity and the principle of this issue, installing patches without having tested them or not knowing what the impact of same is or how to fall back and remove them.

Please keep us informed on what your resolution is for this.

Sorry for delay in replying.
Finally got this sorted.
It was the patch level on SAM!!!
We had to remove some patches.
Also, manner in which security rules are enforced on us is being reviewed.
Thanks for all the help.