----- "Lucas Meneghel Rodrigues" <lmr@xxxxxxxxxx> wrote: > On Wed, Jul 8, 2009 at 4:46 AM, Michael Goldish<mgoldish@xxxxxxxxxx> > wrote: > > I'm resending the message because it probably got filtered out due > to the > > attached setup.bat file. > > > > The contents of setup.bat were: > > > > copy D:\rss.exe C:\ > > > > net user Administrator /active:yes > > net user Administrator 1q2w3eP > > netsh firewall set opmode disable > > > > reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /v > "Remote Shell Server" /d "C:\rss.exe 22" /t REG_SZ /f > > reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon" > /v "AutoAdminLogon" /d "1" /t REG_SZ /f > > reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon" > /v "DefaultUserName" /d "Administrator" /t REG_SZ /f > > reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon" > /v "DefaultPassword" /d "1q2w3eP" /t REG_SZ /f > > > > ----- Original Message ----- > > > > Hi, > > > > In an attempt to solve the SSH problems we have with Windows, I > wrote a little > > remote shell utility to replace the OpenSSH server we're currently > using with > > Win(2000|XP|2003) and the builtin Telnet server we're using with > Win2008. > > It also works with Vista, for which we currently have no other > solution. > > This is a very welcome addition to our test tools, for sure. > > > > > Features: > > - Listens on a requested port (22 by default). > > - Provides clients with a cmd.exe shell. > > - Multiple clients can connect simultaneously. > > - Uses no authentication whatsoever. > > - Uses standard API calls that should work on all modern Windows > variants. > > - Displays an informative message box if any API call fails. > > - Automatically closes all processes started by a client when it > disconnects. > > - Allows clients to run GUI programs (see comment below). > > - Starts minimized by default so it doesn't interfere with step file > tests. > > - Reports all activity in a text box. > > - The code is short (450 lines including comments). > > I definitely like that :) > > > > > Tested and verified to work on WinXP 32, 2003 32, Vista 32 and 64, > 2008 32. > > I haven't tested it on other Windows versions but it should work > (should be > > interesting to test it on Windows 7). > > > > The source code is attached. I used MinGW (with Code::Blocks) to > compile it > > under WinXP. Link it with ws2_32.lib. If anyone wants the binary > please let > > me know and I'll send it somehow (I don't know if I'm supposed to > send > > binaries to the list). > > > > > > Problems: > > - cmd.exe echoes back the command line sent to it. This means > commands are > > echoed twice: first by the local terminal and then by the remote > cmd.exe. > > So if you send "ver\r\n" to the server you get: > > "ver\r\nver\r\nMicrosoft Windows [Version ...]\r\nC:\\>" > > In order for it to work with Autotest we'll have to make some > modifications > > to kvm_utils.kvm_spawn (which should be replaced by kvm_subprocess > anyway) -- > > specifically disable the local terminal echo, and not assume that > the command > > line is echoed exactly once (it may not be echoed at all by Linux > guests). > > > > - The server does not send or receive files. For now we can > transfer files > > into Windows guests using ISOs (-cdrom). If it turns out to be > necessary, file > > send/receive support can be implemented into the shell server, or we > can use an > > open source Windows FTP server or find some other solution. > > Yes, a remote copy utility would be good, in order to keep > consistency. > > > - Running GUI apps: Vista and 2008 seem to run GUI apps just fine > from a remote > > shell, but in older Windows versions you must use cmd /c > > (e.g. "cmd /c notepad"). > > > To be compatible with all Windows versions, Windows GUI tests should > probably > > always use cmd /c to run GUI apps. There's no need to use it for > console > > commands (e.g. dir). > > > Note that when using cmd /c the command returns only when the GUI > app exits. > > Without cmd /c the command returns immediately. > > > > - Some interactive console programs don't behave nicely when their > output is > > redirected (to a remote client in this case). One example is the > builtin > > ftp.exe. If you want to use it, you should do so without waiting > for > > interactive output from the program, which means you should just > send the FTP > > commands one by one and hope everything works, and finally send a > 'quit' > > command to get back to cmd.exe. > > > > > > Installation on guests: > > The following should be done as a superuser: > > - Copy the program to the guest (C:\ should be fine). > > - Disable the firewall. > > - Enable the Administrator account. > > - Make Windows logon automatically using the Administrator account. > > - Make the server program run automatically on startup. > > > > I'm attaching a setup.bat file that does the above. > > setup.bat and rss.exe should be packaged together in an ISO and sent > to the > > guest with -cdrom. Note that setup.bat assumes that rss.exe is in > D:\. > > This will not be true if we run the guest with multiple hard drives, > so we'll > > have to do something about that. > > > > > > Please send me comments if you have any. If you think this isn't a > proper > > solution, or if you can suggest a better one, please let me know. > > So far we have your utility, STAF (sugested by Yaniv) and *possibly* > qarsh. I am going to mail the qarsh authors asking for questions. I've considered STAF, which I know Yaniv likes very much, but it isn't interactive (as far as I know) so if we use it we'll end up with two very different methods of talking to guests (interactive with Linux and non-interactive with Windows) and we'll have to maintain two separate APIs. STAF also has to be setup on the host and guest (there's some permission related configuration to do). After giving the qarsh code a quick look I got the impression that some of it is very unix specific, and even if it makes sense to port it, the resulting code will be much longer than 450 lines, more difficult to maintain, and possibly less reliable. When a boot test fails we'd like to be able to put the blame on KVM with a high degree of certainty. If we use complex utilities we may not know for sure that they work flawlessly. In any case, we should see the author's reply and then make an informed decision. Note that writing a homemade solution was a last resort for me -- I spent as much time looking for a reliable existing program as I did writing this utility. > > Lucas: if we commit this, where should it go? Under tests/kvm/src > maybe? > > No, src is more commonly used as a build directory rather than a > directory that stores packages that are going to be uncompressed and > build. Perhaps deps would be a good name for such applications, since > once they get in we'll start depending on them. > > Sorry for the delay answering, Michael. > > Lucas > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
