Printing issue in HP-UX

[Shibin_2]

I have an HP-UX Superdome server running with HP-UX 11iv2. One partition, which is primary SAP host, having printing issue. Whenever, user complaint can't print from SAP, we found the permission of outputq changed to sapsys ( see below, with old one for record ).

root@hpv01:(root)> ll /var/spool/lp/*q
-rw-r----- 1 lp sapsys 470404 Nov 27 19:30 /var/spool/lp/origoutputq
-rw-r----- 1 lp lp 56772 Jan 3 13:30 /var/spool/lp/outputq


We raised few cases with HPRC, but they too helpless as there is no logs available, who, what and how it changed.

Any help, appreciated. This is production server.

[Kapil Jha]

the very first thing which come to me is to see if there is any setgid?

BR,
Kapil+

[Shibin_2]

There is no setgid. All permission levels are correct.

[Hakki Aydin Ucar]

seems not easy way to track how this change occured.
I recommend you to try HIDS (=Host intrusion detection systems) It might be useful to keep track of why this files' group changed.

[Shibin_2]

Is there any other option, other than HIDS ? I am afraid to install this, because it is customer's primary production server.

[Hakki Aydin Ucar]

Did you check the history files to find at least, anyone did it manually ?

[Shibin_2]

There is nothing in the history file. I have checked this as well.

[Dennis Handly]

You could turn on auditing.
But that seems expensive for something that happened back in Nov.

[Alzhy]

/var/spool/lp/outputq should be lp:sys owned and should have 644 (rw-r--r-- permissions).

Try changing perms to that to address our printing issues instead of trying to uncover the culprit (although it is possible a humn effected that change)

[Dennis Handly]

>Alzhy: /var/spool/lp/outputq should be lp:sys owned and should have 644 (rw-r--r-- permissions).

Hmm. On one of my systems it has my GID there and the same permissions as Shibin's.

>although it is possible a human effected that change

Most likely. ;-)
Though in my case, all I could have done is print a file.

[Shibin_2]

Thanks to all

@ Dennis, that was just an example. It is still happening, even yesterday night too changed. I need to check, whether any auditing is on or not.

@ Alzhy. Permission is correct. As I mentioned earlier, there was a case opened with HP Response Center, escalated several time, but nothing came out to identify, how it changed, who changed etc.

Surprisingly, none of the history file have clue. I am thinking to write some script to sniff, whenever anybody issues chown command, to capture. Let me see, how can I make it.

Is there any ideas ?

[INH]

Hello Shibin,

file permission should be 644 and change the ownership to lp:lp as in below example.

-rw-r--r-- 1 lp lp 20916 Feb 9 2006 /var/spool/lp/outputq

Give a try .. good luck

Regards,
INH

[Shibin_2]

Thanks INH. Let's see, how it goes :)

[Steve Post]

Perhaps I have not looked at your problem enough...but. Could there be a standard lp process that does this? I see this file is some type of database that updates when a print job happens. Maybe it updates the ownership along with the time? It looks like it is part of printing. I see the group ownership of the file should normally be "lp". Perhaps there is a chown command buried somewhere that makes sure the ownership of this outputq is "properly" set?

If it is not in a script, perhaps it is buried in a C compiled binary of something that works with lp, like a menu option in SAM.

[Shibin_2]

Thanks Steve. Some good thoughts. I am not yet figured out, how I can find it out the permission change.

Audit is not on in this system. I am afraid to turn it on.

As of today, permission looks ok. I will update, whenever I see any changes.

[Dennis Handly]

>how I can find it out the permission change.
>Audit is not on in this system.

Only though auditing. Or possibly using tusc to trace lpsched.

[INH]

Shibin,
Give a try for this when that chnage happening. Probably you may increase time if unsure about permission chnage time

Try and capture ps -efHx listing
$export UNIX95=1
$while true; do ps â efHx > /tmp/ps.`date -u +%d%h%m%H%M` ; sleep 60 ; done

HTH

Regards,
INH

[Shibin_2]

Let me monitor for one or two weeks, then will update.

[Steve Post]

I highly doubt this is it. It won't hurt to check. Look in the files in /etc/lp/interface. I know I have had to update these files now and then to shang-hai a print job, modify it, then send it out to a different application.

I'm only saying to run one command and forget about it:

grep -ilE "chown|chgrp" /etc/lp/interface/*

[Shibin_2]

Hi all,

We have print queue replication script running from our print server to all production / dev / test servers on Saturday and Sunday. Last Saturday, outputq permission (group) changed to sapsys after the replication. We changed it back to lp but on sunday, there was no issue after replication. So, it is like intermittent issue.

I will have to look at the script now. But it is surprising, only one host having issue and rest are ok.

@ Dennis, I think there is no tusc in the system. How to get it and how to use this ?

[Dennis Handly]

>We have print queue replication script ... outputq permission (group) changed to sapsys after the replication.

That sounds exactly like the broken script.

>there is no tusc in the system. How to get it and how to use this?

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/tusc-8.0/

If you just want to log every syscall:
tusc -fp -ea -o tusc.out command-or-PID

You could just give it the PID of cron(1m) sometime before the script fires off.

If you don't want to log massive amounts of info, you can limit it to execv, exit, open, chown, chgrp syscalls. See the man page.