ssh-host-config produces Win32 error 1057 on systems with non-ASCII computer names

ssh-host-config produces Win32 error 1057 on systems with non-ASCII computer names

[Johan Ehnberg]

Dears,

I am running a fresh install of the latest stable cygwin on a fresh 
install of vanilla Windows 7 64-bit Finnish, with computer name 
"Käyttäjä-PC". When I run 'ssh-host-config -y' the service installation 
phase fails on the Finnish equivalent of "cygrunsrv: Error installing a 
service: CreateService:  Win32 error 1057: The account name is invalid 
or does not exist, or the password is invalid for the account name 
specified."

Changing the computer name to just "PC", rebooting and retrying works 
around the problem. Localized output from Windows in cygwin with 
non-ASCII characters still looks awful by default though :)

Running 'ssh-host-config -y -d' succeeds in installing the service with 
warnings, and as cyg_server is not taking over incoming privsep logins 
it still does not work. A wild guess is that the non-ASCII computer name 
somehow affects the user creation or granting privileges.

As a side note, non-ASCII user names work well and are not affected by 
this. As long as proper code pages are consistently used, non-ASCII user 
names are a challenge to be handled primarily between different systems 
consoles and file formats.

I thought I'd throw this out there as could not find earlier messages 
about this. At least someone googling can find the workaround. Non-ASCII 
host/computer names are often not well handled elsewhere anyway, so 
there are more reasons than this to avoid them.

Best regards,
Johan Ehnberg

-- 
Johan Ehnberg

johan@ehnberg.net
+254708263146
+358503209688
http://ehnberg.net/johan.html

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

Re: ssh-host-config produces Win32 error 1057 on systems with non-ASCII computer names

[Corinna Vinschen]

On Mar  6 12:26, Johan Ehnberg wrote:
> Dears,
> 
> I am running a fresh install of the latest stable cygwin on a fresh
> install of vanilla Windows 7 64-bit Finnish, with computer name
> "Käyttäjä-PC". When I run 'ssh-host-config -y' the service
> installation phase fails on the Finnish equivalent of "cygrunsrv:
> Error installing a service: CreateService:  Win32 error 1057: The
> account name is invalid or does not exist, or the password is
> invalid for the account name specified."
> 
> Changing the computer name to just "PC", rebooting and retrying
> works around the problem. Localized output from Windows in cygwin
> with non-ASCII characters still looks awful by default though :)
> 
> Running 'ssh-host-config -y -d' succeeds in installing the service
> with warnings, and as cyg_server is not taking over incoming privsep
> logins it still does not work. A wild guess is that the non-ASCII
> computer name somehow affects the user creation or granting
> privileges.
> 
> As a side note, non-ASCII user names work well and are not affected
> by this. As long as proper code pages are consistently used,
> non-ASCII user names are a challenge to be handled primarily between
> different systems consoles and file formats.
> 
> I thought I'd throw this out there as could not find earlier
> messages about this. At least someone googling can find the
> workaround. Non-ASCII host/computer names are often not well handled
> elsewhere anyway, so there are more reasons than this to avoid them.

This is the fault of the cygrunsrv tool, which still uses the
ANSI variants of the Win32 API.  The default codeset under Cygwin
is UTF-8, but that doesn't match your Windows ANSI codepage 1252,
so that's what probably goes wrong.

Cygrunsrv has to be changed to use the UNICODE variants of the
Windows Service API to get that working.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

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

Re: ssh-host-config produces Win32 error 1057 on systems with non-ASCII computer names

[Johan Ehnberg]

On 2013-03-06 12:39, Corinna Vinschen wrote:
> On Mar  6 12:26, Johan Ehnberg wrote:
>> Dears,
>>
>> I am running a fresh install of the latest stable cygwin on a fresh
>> install of vanilla Windows 7 64-bit Finnish, with computer name
>> "Käyttäjä-PC". When I run 'ssh-host-config -y' the service
>> installation phase fails on the Finnish equivalent of "cygrunsrv:
>> Error installing a service: CreateService:  Win32 error 1057: The
>> account name is invalid or does not exist, or the password is
>> invalid for the account name specified."
>>
>> Changing the computer name to just "PC", rebooting and retrying
>> works around the problem. Localized output from Windows in cygwin
>> with non-ASCII characters still looks awful by default though :)
>>
>> Running 'ssh-host-config -y -d' succeeds in installing the service
>> with warnings, and as cyg_server is not taking over incoming privsep
>> logins it still does not work. A wild guess is that the non-ASCII
>> computer name somehow affects the user creation or granting
>> privileges.
>>
>> As a side note, non-ASCII user names work well and are not affected
>> by this. As long as proper code pages are consistently used,
>> non-ASCII user names are a challenge to be handled primarily between
>> different systems consoles and file formats.
>>
>> I thought I'd throw this out there as could not find earlier
>> messages about this. At least someone googling can find the
>> workaround. Non-ASCII host/computer names are often not well handled
>> elsewhere anyway, so there are more reasons than this to avoid them.
>
> This is the fault of the cygrunsrv tool, which still uses the
> ANSI variants of the Win32 API.  The default codeset under Cygwin
> is UTF-8, but that doesn't match your Windows ANSI codepage 1252,
> so that's what probably goes wrong.
>
> Cygrunsrv has to be changed to use the UNICODE variants of the
> Windows Service API to get that working.
>
>
> Corinna
>

Thank you for the prompt answer, it seems to be just on the spot.

For future reference, the default codepage for this Windows variant, as 
reported by chcp, is 850. Using codepage 1252 works mostly, but will 
garble up cmd with some characters and may cause trouble in batch 
scripts with non-ASCII characters. Interestingly, Notepad does not 
support codepage 850 but uses codepage 1252 on the same system. This can 
fool the user and mess up scripts after edits.

On the other hand, I have understood that Windows is also known for not 
running Unicode batch scripts properly - changing cygrunsrv alone may 
not yet solve this for automated batch script installations?

Johan

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

Re: ssh-host-config produces Win32 error 1057 on systems with non-ASCII computer names

[Corinna Vinschen]

On Mar  6 13:11, Johan Ehnberg wrote:
> On 2013-03-06 12:39, Corinna Vinschen wrote:
> >This is the fault of the cygrunsrv tool, which still uses the
> >ANSI variants of the Win32 API.  The default codeset under Cygwin
> >is UTF-8, but that doesn't match your Windows ANSI codepage 1252,
> >so that's what probably goes wrong.
> >
> >Cygrunsrv has to be changed to use the UNICODE variants of the
> >Windows Service API to get that working.
> 
> Thank you for the prompt answer, it seems to be just on the spot.
> 
> For future reference, the default codepage for this Windows variant,
> as reported by chcp, is 850.

Hang on.  This is the default OEM codepage, not the default ANSI
codepage.  The OEM codepage is what CMD uses, the ANSI codepage is what
Explorer and other GUI tools and especially the Win32 ANSI API uses by
default.

> Using codepage 1252 works mostly, but
> will garble up cmd with some characters and may cause trouble in
> batch scripts with non-ASCII characters.

What you can try is this:  Start mintty, open the Options dialog,
and set your Locale to the POSIX "fi_FI" and the charcter set to
"CP1252".  Store the result, close mintty and start it again.
Now your Cygwin tools will use the same codeset as the Windows ANSI
API.  Now try ssh-host-config again.  In theory, that should work.

> Interestingly, Notepad does
> not support codepage 850 but uses codepage 1252 on the same system.
> This can fool the user and mess up scripts after edits.
> 
> On the other hand, I have understood that Windows is also known for
> not running Unicode batch scripts properly - changing cygrunsrv
> alone may not yet solve this for automated batch script
> installations?

Yes it will.  Cygwin tools use the Cygwin codeset as defined by
the $LANG environment variable.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

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

Re: ssh-host-config produces Win32 error 1057 on systems with non-ASCII computer names

[Johan Ehnberg]

On 2013-03-06 13:25, Corinna Vinschen wrote:
> On Mar  6 13:11, Johan Ehnberg wrote:
>> On 2013-03-06 12:39, Corinna Vinschen wrote:
>>> This is the fault of the cygrunsrv tool, which still uses the
>>> ANSI variants of the Win32 API.  The default codeset under Cygwin
>>> is UTF-8, but that doesn't match your Windows ANSI codepage 1252,
>>> so that's what probably goes wrong.
>>>
>>> Cygrunsrv has to be changed to use the UNICODE variants of the
>>> Windows Service API to get that working.
>>
>> Thank you for the prompt answer, it seems to be just on the spot.
>>
>> For future reference, the default codepage for this Windows variant,
>> as reported by chcp, is 850.
>
> Hang on.  This is the default OEM codepage, not the default ANSI
> codepage.  The OEM codepage is what CMD uses, the ANSI codepage is what
> Explorer and other GUI tools and especially the Win32 ANSI API uses by
> default.
>
>> Using codepage 1252 works mostly, but
>> will garble up cmd with some characters and may cause trouble in
>> batch scripts with non-ASCII characters.
>
> What you can try is this:  Start mintty, open the Options dialog,
> and set your Locale to the POSIX "fi_FI" and the charcter set to
> "CP1252".  Store the result, close mintty and start it again.
> Now your Cygwin tools will use the same codeset as the Windows ANSI
> API.  Now try ssh-host-config again.  In theory, that should work.
>
>> Interestingly, Notepad does
>> not support codepage 850 but uses codepage 1252 on the same system.
>> This can fool the user and mess up scripts after edits.
>>
>> On the other hand, I have understood that Windows is also known for
>> not running Unicode batch scripts properly - changing cygrunsrv
>> alone may not yet solve this for automated batch script
>> installations?
>
> Yes it will.  Cygwin tools use the Cygwin codeset as defined by
> the $LANG environment variable.
>
>
> Corinna
>

Thank you for the correction. As you probably noticed, my perspective on 
this is purely scripting and automation i.e. neiter me nor the users 
should need to work within the cygwin environment. As such, I am 
primarily concerned with whatever codepage CMD uses by default and 
actually the scripts I use set the codepage to 850 even if it has been 
changed, so as not to brake the commands but potentially at the cost of 
garbled output messages.

When Windows uses something else elsewhere, I can only adjust to that as 
far as scripting allows. In other words, changing the mintty environment 
won't help in this use case. Unless of course it can be done via command 
line both for the mintty environment and for CMD running the script. 
When I researched into that earlier, it did not seem possible, but it 
would add value for secondary uses of the cygwin environment.

In a perfect (utopistic) world, everyone would quickly settle on 
something like UTF-8 and we could all spend our time on the actual task 
at hand :)

Anyway I am trailing off from the original issue of ssh-host-config and 
Win32 situation out of the box. I am grateful for the ideas and 
knowledge that you shared!

Best regards,
Johan

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