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. > 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
