On Dec 29 11:30, Ken Brown wrote: > On 12/29/2014 9:07 AM, Ilya Dogolazky wrote: > > Hi Ken! > > > > I followed your advise: > > 1) Reinstalled windows again > > 2) Started setup_x86-64.exe from cygwin web site > > 3) Changed two things in the package list: > > a) Changed version of package cygwin to 1.7.34.003 > > b) Marked package "ssh" to be installed > > 4) After installation started terminal (icon right click -> run as admin) > > 5) Typed "ssh-host-config -y" > > 6) Copied the output and attached to this e-mail > > > > The same problem as before: > > System error 1376 has occurred. > > The specified local group does not exist. > > Adding user 'cyg_server' to local group 'root' failed! > > > > :-( > > > > By the way, very first message is quite funny: "it seems your account does > > not > > have these privileges". According to windows UI my account (the only one on > > this > > fresh installed machine) is an administrative one. > > > $ ssh-host-config -y > > > > *** Warning: Running this script typically requires administrator > > privileges! > > *** Warning: However, it seems your account does not have these privileges. > > *** Warning: Here's the list of groups in your user token: > > > > None > > root > > Users > > This output comes from the following code, starting at line 619: > > # Make sure the user is running in an administrative context > admin=$(/usr/bin/id -G | /usr/bin/grep -Eq '\<544\>' && echo yes || echo no)
You shouldn't discuss stuff like that when I'm on vacation :) The aforementioned message is a result of a change in how the function underlying `id' works. For a start, the "root" group is created and added to the default /etc/group file by the base-cygwin package. I don't remember why we did that in the first place, but given that /etc/group goes away, so will the faked "root" group. The next base-cygwin package will not generate /etc/passwd or /etc/group file anymore anyway. Assuming you have a "root" group in /etc/group (usually if you never regenerated /etc/group), then `id' under 1.7.33 and earlier prints *both* gids, 0 and 544. Starting with 1.7.34 it only prints the first group matching the S-1-5-32-544 SID, which is "0" with the default /etc/group. The old getgroups iterated through the groups from /etc/groups, and then checked for each group if its SID is available in the user's token. This behaviour only makes sense if there is a self-contained list of groups in memory. But the new code doesn't read all of /etc/group, or, worse, all groups from the Windows account DB. So the new, more logical behaviour is to iterate over the groups in the user's token and then checking for (or generating) a group entry for the SID. So, in contrast to the old code, the new code only generates a single group entry per SID. I hope we can get over that without having to tweak the ssh-host-config script to explicitely check for a 0 gid... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpDFVdIBTxz9.pgp
Description: PGP signature
