builders: use the buildlet for Windows builds

[bradfitz]

This bug is about moving the Windows builders to GCE per the document
http://golang.org/s/builderplan

The plan is roughly:

1) prepare a Windows disk image (partially automated, partially manually?) to a point
where it has a compiler and a minimal Go program ("gobuildstrap") set to run
on boot.

2) snapshot the disk image of 1). basically never change it.

3) When we want to do a Windows build, the Coordinator will programmatically create a
new Windows VM instance and set some instance metadata:

     * buildstrap-url-program
     * random-instance-key

The gobuildstrap program upon boot will fetch the URL specified by the
"buildstrap-url-program" instance attribute and run it. This is the unit we
can update easily over time, without preparing a whole new Windows system image. It will
be a static Windows Go binary we cross-compile from Linux or Mac.

That second binary ("gowinbuilder") then does a single build (or possibly
more, upon success) and shuts down the VM.  The "random-instance-key"
attribute will be set by the Coordinator to a random string and used as auth for the
HTTP handlers server exposed by the gowinbuilder.  The HTTP methods are things like
"POST /do-a-build" with the body of the POST being a compressed tarball of the
$GOROOT.  The Coordinator will just stream that over the network to it.  The response to
the POST can be the live stream of the stdout/stderr build output. The exit status can
be in HTTP Trailers.

[alexbrainman]

Comment 1:

Brad, I am happy to help any way I can. Just let me know.
Alex

[bradfitz]

Comment 2:

Alex, couple questions:
1) How do I make a Windows program start on boot and run as a daemon?
2) How do I run all.bat with exec/Command? Do I pass it to cmd.exe or something? Or just
directly?
3) Does the Go build work if nobody is logged in to the console? Does it run as
Administrator then?

[bradfitz]

Comment 3:

Notes:
The GCE Internet security policy is so restrictive that browsing the web is useless.  We
want to download Winstrap and MinGW, etc.  Winstrap does all that:
http://storage.googleapis.com/winstrap/
The Windows GCE instance has "bitsadmin" available. Click the shell icon (Powershell) on
the start bar and paste (right click in Microsoft's Remote Desktop Client):
bitsadmin /transfer mydownloadjob  /download /priority normal
http://storage.googleapis.com/winstrap/winstrap-20140711.exe
c:\users\windows-test\Desktop\winstrap.exe
 
Then double-click winstrap.exe on the desktop.

[bradfitz]

Comment 4:

Owner changed to ---.

[bradfitz]

Comment 5:

Nevermind my question 2) in Comment #2.
I see winstrap just runs exec.Command(filepath.Join(goroot(), "src", "make.bat"))

[bradfitz]

Comment 6:

Labels changed: added builder.

[kardianos]

Comment 7:

RE #2.1: To run something at boot and run as a daemon is what windows calls a service.
You could either find a shim program that launches an exec from it, or to write it
yourself, use Alex's http://code.google.com/p/winsvc/ (or mine
bitbucket.org/kardianos/service which now uses Alex's package).
RE #2.3: A windows service can be run with different permissions and as different users.
If you have it run as your administrator user, it would probably work fine, though it
may work fine as the default system user if the FS ACLs are set correctly.

[alexbrainman]

Comment 8:

> ... 1) How do I make a Windows program start on boot and run as a daemon?
Like Daniel said in #7 these are called windows services. But we don't want to run like
that, service have completely different environment (security and other parameters). I
am certain our builder will have multiple problems in that environment.
I think we want to do what we do now - run builder as desktop program. We should login
as administrator and start builder program on login. We can configure windows to login
as administrator automatically (I have never done it, but I am sure it is easy enough -
I can ask my admin friends or google). As to starting builder on login, it is just a
matter of creating short-cut to the program in "Startup" menu.
2) How do I run all.bat with exec/Command? Do I pass it to cmd.exe or something? Or just
directly?
Our current builder just calls all.bat, I believe.
3) Does the Go build work if nobody is logged in to the console? Does it run as
Administrator then?
Or current builder runs inside user session, with Administrator as user logged in.
I see you have builders running on GCE manually already. This is a good start. Hopefully
we can do everything you have plans for. I don't see why we cannot.
Alex

[Grovespaz]

Comment 9:

For autologin do this in the registry (using regedit or anything else you like):
Go to HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon
Set these keys:
AutoAdminLogon = "1"
DefaultUserName = Administrator
DefaultPassword = PasswordOfTheAdministrator
Of course replacing the username and password with your own.
For making sure an application or bat file starts upon logon, navigate to:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Create a new entry witha ny name you'd like. As the value, set the full path to the
executable or .bat file you want to run.
If you want I can automate this into a script, should it be useful.

[bradfitz]

Comment 10:

Govert, Alex, thanks! This is good stuff to know. I think I'll be able to do automate it
now.

Labels changed: added g-windows, removed os-windows.

[bradfitz]

Comment 11:

Labels changed: added os-windows, removed g-windows.

[bradfitz]

Comment 12:

New question: what should we do for an ssh server on Windows?
Could we use Go's ssh server package with cmd.exe as a child process somehow? Or is
there another ssh server we should use?
RDP isn't a great answer. We want a common interface (ssh) to all builders.

[alexbrainman]

Comment 13:

>  what should we do for an ssh server on Windows?
>
> Could we use Go's ssh server package with cmd.exe as a child process somehow? Or is
there another ssh server we should use?
I am not aware of any particular ssh server for Windows. But I am sure there are many
available. Windows used to come (maybe still does) with built-in telnet server itself.
Or we can, probably, build our own out of Go’s ssh server package. But what are you
going to do once connected to that remote cmd.exe? I fear you won’t be able to do
much. Windows command line tools are pathetic as far as I am aware. You will be able to
build Go programs, maybe run gdb, but nothing else. What are you planning to do once
connected?
> RDP isn't a great answer.
RDP will allow you to do anything you want. It is the only way commonly supported by
Microsoft. RDP will work in pretty much any situation.
> We want a common interface (ssh) to all builders.
Fair enough. But, like I said earlier, it might work in a particular scenario, but not
for a general purpose access.
Alex

[bradfitz]

Comment 14:

RDP is easy and we can provide it. But what I want is for us to have a general tool,
like:
$ go tool debug --builder=windows-amd64 --hg=71b41b413359
$ go tool debug --builder=windows-amd64 --cl=134560043
.. which will then prepare that environment + patches and ssh you into it automatically,
with no knowledge of passwords or IP address or ssh public keys.
So if we're going to have that work for all the Unix builders, I also want an equivalent
for Windows, even if it's an anemic CLI environment.
Perhaps we also have:
$ go tool debug --rpd ...
which brings up an RDP viewer at that environment. But I'd like to think about how we do
ssh if possible.

[alexbrainman]

Comment 15:

If you just want our builder to execute specific commands on request, than sure it can
be done. It is just good old tcp client / server. If you want to use ssh for that, that
should be fine too. But I am not sure if there are ready to use tools for that. So
perhaps just use Go ssh server package.
Alex

[alexbrainman]

Comment 16:

Maybe "Chrome Remote Desktop" is a good solution, if RDP client is an issue on Linux and
Mac.
Alex

[Grovespaz]

Comment 17:

There's quite a lot of SSH servers for Windows:
https://en.wikipedia.org/wiki/Comparison_of_SSH_servers#Platform , not all of them free
though.
I've used OpenSSH for Windows once years ago (not on the Wiki list,
http://sshwindows.sourceforge.net/) but I don't know if it's still up to snuff.
A quick google search leads to this:
http://serverfault.com/questions/8411/what-is-a-good-ssh-server-to-use-on-windows which
might help you.

[minux]

Comment 18:

I used to use openssh on windows, and it worked fine
(just a little troublesome to set up, iirc)

[bradfitz]

Started instructions in https://go-review.googlesource.com/2269

[bradfitz]

Added a "stage0" command in https://go-review.googlesource.com/#/c/2268/ to bake into the Windows VM which downloads the real buildlet at boot. Other OSes do this with a couple lines of shell, but I don't know BAT or PowerShell, so Go it is.

[bradfitz]

This is now done & running at https://build.golang.org/

Final changes are in https://go-review.googlesource.com/4132