This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
I am using openssh to run software builds on a Windows 2003 system. After a recent update of cygwin my builds started failing. In both cases it appears that the Windows Registry is not as fully populated for the ssh user as it was in previous versions of cygwin/openssh. Any help in guiding my analysis of this issue would be greatly appreciated. Note that in all tested cases, we are using ssh with explicit passwords, no public-private key authentication is done at all. The environment is in a domain and the build it done under a domain user. When the problem started to occur I found the information about updating the sshd user to a domain user with the required privileges but that did not change the behavior. Note also that between the old and new systems the output of the "c:/windows/system32/whoami /all" command is the same for the user running under ssh. The previous version of cygwin we had been running was installed from a relatively up-to-date version as of February 2009 and we installed the new version that failed in February 2010. The difference in the openssh versions is between 5.1p1-10 and 5.3p1-1 (although I also just tried 5.4p1-1 and it still exhibits the same problems). The cygwin package version changed from 1.5.25-15 to 1.7.1-1. I noticed two effects of the change with regard to the Windows Registry: 1. The HKCU Registry tree is very sparsely populated relative to previous versions of cygwin (details on this below). The first thing I noticed about this effect was that the HKCU\Network key didn't exist at all even though I had persistent drive mappings. 2. When I'm ssh'ed in there is no longer an entry HKU\S-1-5-... for the SID under which I am logged in (according to the output of "c:/windows/system32/whoami /all") Problem 1 leads to "net use" not displaying any remembered drive mappings. In the past I used the output of this to do script explicit "net use z: \\share..." commands to reconnect the drives. This is a little annoying, but can be worked around by explicitly calling "net use" to map the drives. As mentioned below there are likely to be other problems from this because the HKCU tree is so sparsely populated relative to previous version of cywin, but that this point that claim is unsubstantiated. Problem 2, however, seems related to the fact that the Windows "SignTool.exe" command now fails when we run it in an ssh environment. I used the sysinternals "Process Monitor" tool to analyze this and it appears that a likely place that SignTool gets into trouble is the attempt to open HKU/<SID> for the current user and, as mentioned above, this fails since the entry does not exist. One workaround for this problem is to remote desktop into this system while you have a ssh session running. The remote desktop session populates the remaining parts of the Windows Registry and these are immediate available to the pre-existing ssh session. So just by rdesktop'ing in after the fact, my build worked. Of course that's not a very good solution since I'm using ssh to do the build so I don't have to rdesktop (more specifically that I can script the build to be triggered from my Ubuntu system). I also did a comparison of the output of "reg query HKCU /s" between the ssh environment and a remote desktop environment and there is quite a large piece of the HKCU registry that's missing relative to the remote desktop environment. This is also true in older versions of cygwin (in particular in versions where we were able to build successfully) however the difference between the ssh environments HKCU tree and remote desktop's is considerably less in the older version (more specifically, I ran diffstat on these and the difference on the working system was about 100 lines vs around 10,000 lines of differences on the failing system). So the question I have is whether some change in the last year or so was intended to greatly limit the establishment of the Windows Registry environment for users connecting via ssh. If so, is there anything we can configure to try to get this to behave the way it did previously. Although, more fundamentally, I'm looking for anything that can help me understand this situation better as I might be looking at the wrong things and asking the wrong questions. In particular, there might be a more fundamental reason for the lack of population of the Windows Registry. Perhaps a crisper question to start with would be whether anyone running a current version of cygwin sees their SID listed with the "reg query hku" command run under ssh (ensuring that you are not also rdesktop'ed into the same box at that time). If this is populated for you I'd be interested in any details of your environment that might indicate a way I can make this work in my environment. My guess is that if HKU\<SID> is populated perhaps the HKCU tree would be similarly well-populated, but that's just a hope at this point. Thanks in advance for any additional info you can give me or any suggestions on how I can more fully diagnose the issue, Eric Berge
Attachment:
cygcheck.out
Description: Binary data
-- 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |