Mailing List Archive

Problems with conserver "pid" and "quit" commands
Hi,

I found three problems with conserver.
1) "console -P" displays in incorrect PID. The attached patch fixes
this.
2) "console -q" doesn't stop conserver when you're on a "trusted
connection". When you're authenticated it does work. The attached
PID uses for "trusted" the same call as for "authenticated".
3) When you give the "console -q" command and you're on a "trusted
connection", console will ask for the "root" password. However
conserver never verifies this password and accepts anything. I'm
not sure what would be the appropriate way to fix this. In fact
when you are running as root and trusted it would be nice if
console wouldn't ask for a password at all, so that it is easier to
use "console -q" from a script. What do others think?

The attached patch fixes problem 1 and 2 (based on the 7.1.4-beta,
which works fine by the way). Can someone apply these to the source?

Cheers.
--
-- Han Pilmeyer, email: han@uto.dec.com
-- Compaq Tru64 UNIX engineering / Customer Care Consulting Group
-- Answers are the easy part, questions raise the doubt -JB
Problems with conserver "pid" and "quit" commands [ In reply to ]
On Tue, Jan 15, 2002 at 02:01:25PM +0100, Han Pilmeyer wrote:
> Hi,
>
> I found three problems with conserver.
> 1) "console -P" displays in incorrect PID. The attached patch fixes
> this.
> 2) "console -q" doesn't stop conserver when you're on a "trusted
> connection". When you're authenticated it does work. The attached
> PID uses for "trusted" the same call as for "authenticated".

how embarrassing. i've integrated the patches for these above.
they'll be in the next release (7.1.4).

> 3) When you give the "console -q" command and you're on a "trusted
> connection", console will ask for the "root" password. However
> conserver never verifies this password and accepts anything. I'm
> not sure what would be the appropriate way to fix this. In fact
> when you are running as root and trusted it would be nice if
> console wouldn't ask for a password at all, so that it is easier to
> use "console -q" from a script. What do others think?

this one is kinda tricky. in the simple case, there would be one
conserver host and when you asked it to shut down it would prompt for a
password only if necessary. the difficulty case is when you have
multiple conserver hosts in a distributed setup. if you put the burden
on the server to ask for a password (and you weren't coming in from a
trusted host) you'd get N password prompts. with the current code, you
only get asked once. but, that too could be an issue...if your
conserver hosts have different root passwords, only those with the same
password would shut down.

so, what's the right answer? i'm not sure. i was thinking that a '-n'
(picking a random letter) flag or something on the client side might be
useful. if you run with '-n', no password queries are done - it just
uses an empty string. that way, you could do a 'console -q -n' and it
wouldn't hang waiting for input. in a similar way, connecting to a
console via 'console -n <console>' would assume an empty password (if
it needed one). hmmm...maybe '-E' for "empty password".

any opinions out there?

Bryan