running wintest issues

[Andrew Bartlett]

On Wed, 2011-10-05 at 09:52 -0400, Sean Dague wrote:
> On 10/05/2011 03:56 AM, Andrew Bartlett wrote:
> > On Wed, 2011-10-05 at 17:49 +1100, tridge at samba.org wrote:
> >> Hi Sean,
> >>
> >>   >  It appears to just hang, waiting for something to happen. I'll do
> >>   >  another run today to get more details.
> >>
> >> you may want to look in the c:\windows\debug directory and see if
> >> dcpromo gives any useful output there
> >>
> >>   >  I'm wondering if long term it would make more sense to put a little
> >>   >  python xml-rpc daemon in the windows guests to send the command stream
> >>   >  in, instead of using the telnet / expect interface.
> >>
> >> I quite like the telnet approach, because it works on all windows
> >> versions without having to worry about additional packages. We were
> >> trying to keep the windows install very simple, and I think it's
> >> better that we keep that simplicity if possible.
> >
> > The key word here is 'works'.  It certainly is the most sensitive/flaky
> > part of wintest, and the more we can do to get that step automated (can
> > use other tools to get administrator into the right groups and telnet
> > started before we start telnet?) the better off we will be.
> 
> Works is a very relative term, it only seems to work in *very* specific 
> windows configurations. I've had the telnet approach fail in 2 ways 
> during setup that I didn't expect.
> 
> 1) In Windows 7 Professional, it only works if you enable the disabled 
> built in Administrator account and give it a password. Any other user 
> that is in Administrators group (including the user you are prompted to 
> create on install) is not allowed to log in via telnet (that was about 2 
> days worth of discovery).

Can you see if it is possible to do this via a script before telnet is
used, so that it 'just works'?

> 2) It only works in Windows 2008 if you've not changed the Shell to 
> power shell (and only use cmd.exe). That took a bit to discover.

Could we start a cmd sub-shell as the first telnet command to work
around this?

> It is also sensitive to telnet settings on the client. If those have 
> been changed because of working with other systems that needed different 
> line modes, it may no longer work.

Can these be forced on the command line?

> The point being that it's very fiddly to a lot of the environment that 
> isn't checked for. This fiddliness I'm sure contributes to it not being 
> run regularly by many folks.
> 
> If we want to stay with the telnet based approach, there at least needs 
> to be *a lot* of extra environment checks to ensure the systems are 
> ready to be tested, as they need to be in a very specific state before 
> the tests can be run and mean anything.

I think automation and checking is the right approach.  I agree it's
flaky - I think we should try and run as many of the explicit and
implicit preparation commands via Samba's RPC client if possible, and
see if that helps the reliability and the environment dependence. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org