Message-ID: <493E1E35.2020407@cwilson.fastmail.fm>
Date: Tue, 09 Dec 2008 02:28:53 -0500
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.18) Gecko/20081105 Thunderbird/2.0.0.18 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Cygwin Mailing List <cygwin AT cygwin DOT com>
Subject: Re: ssh-host-config problem on windows 2003, please help.
References: <582532 DOT 8302 DOT qm AT web53310 DOT mail DOT re2 DOT yahoo DOT com> <20081208151350 DOT GY12905 AT calimero DOT vinschen DOT de>
In-Reply-To: <20081208151350.GY12905@calimero.vinschen.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Corinna Vinschen wrote:
> This (untested) patch to the service helper script
> /usr/share/csih/cygwin-service-installation-helper.sh
> should fix that problem.
> 
> 
> Index: cygwin-service-installation-helper.sh
> ===================================================================
> RCS file: /sourceware/projects/cygwin-apps-home/cvsfiles/csih/cygwin-service-installation-helper.sh,v
> retrieving revision 1.15
> diff -u -p -r1.15 cygwin-service-installation-helper.sh
> --- cygwin-service-installation-helper.sh	22 Aug 2008 03:56:43 -0000	1.15
> +++ cygwin-service-installation-helper.sh	8 Dec 2008 15:10:36 -0000
> @@ -2277,7 +2277,7 @@ csih_select_privileged_username()
>        echo ""
>        csih_inform "This script plans to use '${username}'."
>        csih_inform "'${username}' will only be used by registered services."
> -      if csih_request "Do you want to use a different name?"
> +      if ! csih_request "Do you want to use this account name for running this service?"
>        then
>          csih_get_value "Enter the new user name:"
>          username="${csih_value}"

As I've pointed out before, this breaks csih clients that are run as
part of postinstall.  Now, I had thought that there were more of those
in the past, than the paltry example below.

inetutils postinstall:

export IU_CONFIG_AUTO_ANSWER_NO=1
/usr/bin/iu-config
export SYSLOGD_CONFIG_AUTO_ANSWER_NO=1
/usr/bin/syslogd-config

You /REALLY/ don't want the postinstall script to run with
AUTO_ANSWER=yes.  Hence, the sense of the question is set up so that no
user input is ever required when AUTO_ANSWER=no.

However, no such guarantee is made when AUTO_ANSWER=yes.

I don't see how to accomodate both requirements, so that --yes "does the
right thing" and --no "does the right thing" for a question phrased
identically.  Perhaps that question, specifically, should be handled
specially? (Pseudo-code):

if auto_answer=yes
  if ! csih_request "Do you want to use this account name for running
this service"
    # since auto-answer=yes, we never get here, but we "ask" the
    # question anyway so that it gets printed out using the 'question'
    # colorization
    :
  ...
elif auto_answer=no
  if csih_request "Do you want to use a different name?"
    # since auto-answer=no, we never get here, but we "ask" the
    # question anyway so that it gets printed out using the 'question'
    # colorization
  ...
else
  if csih_request "Do you want to use a different name?"
    csih_get_value "Enter the new user name:"
    username="${csih_value}"
  ...
...

But that would just confuse someone who came at this "cold": look at the
manual transcript of a foo-install session, and then said, OK, I want to
automate this. Should I use --yes, or --no?  With the pseudo-code above,
the answer (as far as the manual transcript would indicate) would be
--yes, except I think I want --no for "Do you want to use a different
name?" (e.g. I want the default prived user).

Okay. So, suppose we modify the pseudo-code and word the non-auto-answer
question like the auto-answer=yes case.  Then, somebody looking at a
manual transcript might ask: I want to run this script "safely" so that
things are set up, but no services are actually installed and no new
user accounts are created. Should I use --yes, or --no?  Under this
modified pseudocode, the answer would be --no, except I think I want
--yes (e.g. I want the default prived user) for "Do you want to use this
account name for running this service"

Anybody have a better idea, that works for both "automated" cases yet
doesn't confuse the heck out of somebody trying to figure out which of
--yes or --no to use when implementing their own automation?

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/