Serious problem with Jetadmin

[Scott D. Allen]

the lp user had it's group changed to another (non-lp) group, 101.

now, in jetadmin, i get this when i try to create a new queue. please let me know if it's because of the change in the lp gid.

!! Cannot shut down the spooler with lpshut !!
Having tried for 5 times. Please shut down the spooler from
the command line, then re-run this configuration.

I tried shutting down the spooler with lpshut from the command line and it works fine, but the jetadmin still won't add the queue. Please advise.

--Scott

[James R. Ferguson]

Scott:

Change the group of the 'lp' user back to the lp group. This should resolve your problem.

...JRF...

[Scott D. Allen]

Jim,

Thanks. However, I'm using Visibility on my system and the Visibility technical people are telling me that I need to have lp GID equal to the visibility GID. Here lies the problem.

Is it acceptable to change the lp GID? I've never done it, but they (Visibility) are assuring me that it's very standard.

--Scott

[Eileen Millen]

maybe if you change the group id back, you will be able to shutdown the print scheduler.

[James R. Ferguson]

Scott:

I am not familar with 'Visibility', but, how about making the 'visibilty' user's group 'lp'? Or, include the 'visibility' user in the 'lp' group?

...JRF...

[Scott D. Allen]

I tried including lp in the visibility group, but the tech at Visibility said that "he's never heard of such a thing". Funny, considering he's heard of changing the lp user's GID to something BESIDES lp, which I have never heard of. Regardless. I'm sort of stuck with that option. I was able to restart the scheduler by killing it manually and it seems to be working fine now.

Open issues: what does everyone think of this idea? Changing the lp GID to something BESIDES lp? I don't like it, but I'm sort of stuck.

--Scott

[Bill Hassell]

It's important to understand that a group ID (or user ID) is simply a number that's assigned to files, directories, etc. The name lp is not special, nor is the default number assigned to lp. Now true, administrative user ID's are typically less than 100, but other than that, the choice is nothing special.

What *IS* special is the connection all the lp components require in order to work together. The best way to break a subsystem is to 'adjust' HP-UX ownership and/or permissions of subsystems like the spooler. If Visibility must be connected to the spooler ID's, simply install the product as lp. Now HP-UX does not have a login setup for lp so it's probably a good idea to add a shell and $HOME so you can login as lp.

This is actually a good general idea as most sysadmins administer lp logged in as root. Most of the time, this works OK but occasionally, ownership may be messed up due to root's characteristics.

If Visibility is already installed, simply change the group (and user if needed) ownership of the Visibility files.

[Scott D. Allen]

Bill,
Agreed on "what *IS* special...". Everything has been installed for quite some time and working fine. However, visibility JUST noticed that the lp and visib GID's not being equal because of some minor problem, as they often do. They suggested the change and we performed it, to find a whole bunch of other problems (like lpr being un-executable by lp with the new GID). I'm able to fix these problems as they come along, but I'm afraid that it's going to get ugly and I want to be as proactive as possible and fix this in a very ABSOLUTE sense.
Third-party applications stink!
--Scott