----- "sudhir kumar" <smalikphy@xxxxxxxxx> wrote: > Thats great Michael !! > > On Wed, Jul 15, 2009 at 8:56 PM, Michael Goldish<mgoldish@xxxxxxxxxx> > wrote: > > > > ----- "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. > So does it export the full environment of cmd.exe ? I meant can we > run > all the commands here as we can do in a direct cmd.exe in a windows > system? Yes, but some commands need special care: GUI commands should be executed with cmd /c (e.g. cmd /c calc) and some interactive commands are not fully interactive (like ftp.exe). See comments below (in the original message). > >> > - 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 > I can give a quick testing on some of the datacentres if I can get the > binaries. > > >> > 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). > Yes please. > May be in future the binaries can be hosted somewhere and we can add > the steps files to do an automatic install of the ssh server on the > windows guests ? I'll try sending you a binary in a few minutes. > >> > 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. > That too if it can be implemented in the same shell server will be > good in comparison to relying on multiple tools/utilities. I think it should be rather easy to implement, but until it's implemented we can certainly use -cdrom. Currently there are no Windows tests that involve sending or receiving files, and -cdrom is very easy to use in Windows because it normally maps to D:\ (except when there are multiple hard drives). -cdrom is also safer and quicker to use than sending files because it avoids possible permission problems that need to be fixed with Windows' cacls (a shell command). So we should probably send/receive files only when we have no other choice, or in tests dedicated to sending and receiving stuff. > >> > - 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 > > _______________________________________________ > > Autotest mailing list > > Autotest@xxxxxxxxxxxxxxx > > http://test.kernel.org/cgi-bin/mailman/listinfo/autotest > > > > thanks again for starting on this particular problem !!! > > -- > Sudhir Kumar > -- > 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
