[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]

Problems with conserver "pid" and "quit" commands

Bryan Stansell bryan@conserver.com
Thu, 17 Jan 2002 00:16:15 -0800

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?