Wiki Navigation

Windows XP in Emulab

Microsoft Windows XP is now supported as one of the operating system types for experiment nodes in Emulab, in addition to FreeBSD and Linux. Windows 2000 is not supported.

NOTE: This page describes using an existing "managed" Windows XP image in an Emulab testbed, and making user-customized versions which contain additional software and configuration changes. If you are a testbed administrator who wants to make a new Windows XP image from scratch, you will have a copy of the Emulab sources, and should consult the file testbed/tmcd/cygwinxp/xpimage-notes.txt for details.

As much as possible, we have left Windows XP "stock". Some Windows services are shut down: Messenger, SSDP Discovery Service, Universal Plug and Play Device Host, and Remote Registry. Other setting changes are described under Network config and Routing below.

Before booting the node at swap-in time, Emulab loads a fresh image of Windows XP onto the experiment nodes in parallel, using our frisbee service. Emulab software automatically configures each Windows XP node, providing the expected experiment user environment including: user accounts and Emulab SSH keys; remote home, project, and shared directories; and network connections.

The Cygwin GNU environment is provided, including Bash and TCSH shells, the C/C++, Perl and Python programming languages, and several editors including Emacs, vim, nano and ed.

All of the Emulab experiment automation and monitoring services have been ported to run on Windows/Cygwin. Sometimes the Emulab documentation shows explicit command paths, such as /usr/testbed/bin/emulab-sync. Cygwin handles both Unix and Windows-style command paths, as described below .

The Emulab web interface manages a separate Windows password in the user profile, as well as making login connections to the experiment nodes. Remote Desktop Protocol service supports Windows Desktop logins from the user's workstation screen to the experiment node. SSH and Serial Console command-line connections are also supported.

Windows XP installations are more hardware dependent than Linux or FreeBSD. At present, this Windows XP image runs on most of the Emulab pc node types, including pc600, pc850, pc3000 and pc3000w (wifi) nodes.

Differences from FreeBSD and Linux in Emulab

The biggest difference of course, is that this is Windows (!), with Cygwin layered on top, and Emulab management services added. In particular, this is Windows XP (NT 5.1), with various levels of service packs and updates (see below.)

File Sharing

The second-biggest difference is that shared directories are provided not by the NFS (Network File System) protocol, but instead by the SMB (Server Message Block) protocol, otherwise known as Windows File Sharing.

The "Client for Microsoft Networks" software contacts the SMB server, in this case Samba running on the file server known as Fs (an alias for Users.) The SMB protocol authenticates using a plain-text user name and password, encrypted as they go across the network. (These Windows Shares are then accessed by UNC paths under Cygwin mounts, described below.)

In Windows GUI programs, you can just type the UNC path into the Address bar or a file-open dialog with backslashes, e.g. \\fs\share or \\fs\<username>. User and project shares are marked "not browsable", so just \\fs shows only share.

If you want to serve files from one of your experiment nodes to others, see the section on The netbt command .

Windows Passwords

A separate Windows password is kept for use only with experiment nodes running Windows. It is presented behind-the-scenes to rdesktop for RDP logins by our Web interface under Unix, and for the Samba mount of shared directories like your home directory under an ssh login, so you don't have to type it in those cases. You will have to type it each time if you use the Microsoft RDC (Remote Desktop Connector) client program from a Windows machine.

The default Windows password is randomly generated. It's easy to change it to something easier to remember.

To see or edit your Windows password, log in to Emulab, and click Manage User Profile and then Edit Profile under User Options. You will see Windows Password fields in addition to the regular Emulab Password fields.

When you change your Windows password, you will also have to re-type it as a check. The new Windows password should propagate to the Samba server on Fs instantly, so you can swap in an experiment and log in to its Windows nodes with the new password.

If you have already swapped-in experiment nodes and change your Windows password, the account information including passwords will be updated at the next Emulab watchdog daemon isalive interval. This should be in 3 to 6 minutes.

Experiment setup for Windows nodes

All you have to do is put a line specifying a WINXP OS image in your experiment .ns file, like this:

    tb-set-node-os $node WINXP-UPDATE

The Emulab Windows XP images are no longer specific to a particular hardware type. (See the Change Log for more information.) You may explicitly specify the hardware type to run on if you wish, for example:

    tb-set-hardware $node pc3000

See the note below on using the tb-set-node-failure-action command for experiments with a large number of Windows nodes. This can save a swap-in with a large number of Windows nodes, or prevent a single node boot failure on a swapmod from swapping-out the whole experiment.

If you use these commands: tb-set-node-startcmd, tb-set-node-tarfiles, or tb-set-node-rpms you should read the sections on Permissions and Windows GUI programs below.

Currently available Windows XP images are:

WINXP-UPDATE - The most recent Windows XP-SP2+. This is usually what you want. It is updated periodically from Windows Update, typically after a Microsoft "Patch Tuesday", the second Tuesday of each month. All critical and security fixes are installed, up through the date we pull the image file. (See the date created field on the individual WINXP Image ID's ). Note: The Windows Firewall is disabled by default (as it will inform you repeatedly!)
WINXP-SP2 - Windows XP-SP2. This has the original SP2 on it, with no Windows Update modifications beyond that. (SP2 includes SP1.)
WINXP-SP1 - Windows XP-SP1a. This is intended for software (in)security work, and has only the updated version of SP1 (a.k.a. SP1a) installed.
WINXP-SP0 - Windows XP, from the original 2001 MSDN CD, with the Emulab client-side management code ported to it. This is intended for software (in)security work, and has no service packs at all.
WINXP-BASE[-SP1,-SP2][-cygwn][-3000,-pc3000] - Raw Windows XP images from the original 2001 MSDN CD, some with service packs and Cygwin. There is no Emulab client-side management code to set up and operate the node. This is only useful for building special custom images completely from scratch. Note: These base images are hardware-dependent, and will run only on the pc850 (and possibly the pc600) without a suffix, and on the pc3000 with the -3000 or -pc3000 suffix.

Network config

Some default Windows networking features are disabled. NetBT (NetBios over TCP) (NetbiosOptions=2 ) and DNS auto-registration (DisableDynamicUpdate=1 ) are disabled to allow network idle detection by the slothd service. TCP/IP address autoconfiguration is disabled (IPAutoconfigurationEnabled=0 ) so that unswitched interfaces like the sixth NICs on the pc3000's don't get bogus Microsoft class B network 169.254.0.0 addresses assigned.

The Emulab pc850 node type has five network interfaces, and the pc3000 has six. However, the Windows ipconfig /all command only shows the configuration information for the enabled network interfaces. There will always be one enabled control net interface on the 155.98.36 network. The others are disabled if not used in your experiment. (See file /var/emulab/boot/ipconfig-cache for a full listing from boot time, including the interfaces that were later disabled.)

If you specified links or LANs in your experiment network topology, other interfaces will be enabled, with an IP address, subnet mask, and gateway that you can specify in the NS file. Notice that the Windows names of the interfaces start with Local Area Connection and have a number appended. You can't count on what this number is, since it depends on the order the NIC's are probed as Windows boots.

NOTE: Often, we have seen ipconfig report an ip address and mask of 0.0.0.0, while the TCP/IP properties dialog boxes and the netsh command show the proper values. Our startup scripts disable and re-enable the network interface in an attempt to reset this. Sometimes it doesn't work, and another reboot is done in an attempt to get the network up.

Routing

Full-blown router nodes can not run Windows, i.e. rtproto Session is not supported. However, basic routing between connected network components of your experiment topology works. The Windows command to see the routing tables is route print. The IPEnableRouter=1 registry key is set on multi-homed hosts in the experiment network, before they are rebooted to change the hostname.

rtproto Static is supported in all recent WINXP images, but not in WINXP-02-16 (2005) or before.

rtproto Static-old or rtproto Manual will work in any image.

There is more information on routing in the Routing Section of the Emulab Tutorial.

Firewalls

Emulab.net is outside the University of Utah firewall, with only a minimal outer firewall , to allow free network experimentation. Even though we have closed most low-numbered ports, your Windows XP experiment nodes are still exposed to the wider Internet on higher port numbers.

If your experiment does not require that full freedom, consider adding a control net firewall node statement to your experiment ns file. This allows you to control the security level of your connection to the Internet by a style keyword, for example:

    set fw [new Firewall $ns]
    $fw set-type ipfw2-vlan
    $fw set-style basic

NOTE: There are some problems which make swapping-in Windows nodes behind a control-net firewall take longer than they should, or fail.

DHCP packets aren't passed until the firewall node is loaded with FreeBSD and started up. The OS image loading process starts with a FreeBSD PXE-loader that requires DHCP information. To minimize the impact of this, we hold rebooting the experiment nodes into the PXE-loader until the firewall is up.
During the Frisbee OS image loading process, all of the image data passes through the control-net firewall. This can be a bottleneck: if it is allocated to a pc600 node; if you are loading several different Windows images in the experiment; or if there are multicast congestion problems in the Cisco router. Windows nodes are more subject to all of these issues, only because the Windows images are larger. After 10 minutes in the reloading state, Emulab gives up and reboots the node to try again, even if Frisbee is working hard and nearly done. We could extend the time-out when the nodes are behind a control-net firwall, or change to accept some slowdown as long as the image load is making progress rather than using a fixed time-out.

The Windows Firewall software is installed in WINXP-SP2 and WINXP-UPDATE images, but disabled with the netsh firewall set opmode DISABLE command, to allow RDP and SSH access to Windows nodes. There is an XP display bug related to this: sometimes the "Security Center" that shows at RDP login indicates that the Windows Firewall is turned on. Clicking through to the firewall settings shows that it is really off.

Windows nodes boot twice

Notice that Windows reboots an extra time after being loaded onto a node during swap-in. It has to reboot after changing the node name to set up the network stack properly. Be patient, Windows XP doesn't boot quickly.

With hardware-independent (Sysprep'ed) images, the first boot is actually running Mini-Setup as well, setting up device drivers and so on.

It's best not to log in to the nodes until the experiment is fully swapped-in. (You may be able to log in briefly between the first two reboots; if you see the wrong pcXXX name, you'll know that a reboot is imminent.) You can know that the swap-in process is finished by any of these methods:

Waiting until you get the "experiment swapped in" email from Emulab.
Checking the node status on the experiment status page in Emulab. (You have to refresh the page to see node status change.)
Watching the realtime swap-in log to monitor its progress.

NOTE: Sometimes Windows XP fails to do the second reboot. One reason is transient race conditions in the Windows startup, for example in the network stack when there are multiple network interface devices being initialized at the same time. We make a strong effort to recover from this, but if the recovery code fails, by default it results in a swap-in or swapmod failure.

At boot time If you're having swap-in problems and rc.bootsetup doesn't finish sending ISUP to Emulab within 10 minutes, the node will be rebooted. After a couple of reboot cycles without a ISUP, Emulab gives up on the node.

You can cause these boot-time problems to be nonfatal by adding this line to your ns file for each Windows node:

 tb-set-node-failure-action $node "nonfatal"

(where $node is replaced with the node variable, of course.)

Emulab will still complain if it doesn't get the ISUP signal at the end of rc.bootsetup, but the swap-in or swapmod will proceed and allow you to figure out what's happening. Then you will probably have to manually reboot the failed Windows node to make it available to your experiment.

If you try to login to a node after swap-in to diagnose the problem and your Windows password isn't honored, use this command on Ops to remotely reboot the node:

 node_reboot pcxxx

If you are able to log in but your remote home directory isn't mounted, this is another symptom of a partial set-up. You have the additional option of executing this command on the node itself:

 /sbin/reboot

This gives Windows another chance to get it right.

Login connections to Windows

You can manually start up the SSH or RDP client programs to connect and log in to nodes in your experiment, or use the console command on Ops. You will have to type your Windows Password when logging in, except for SSH when you have ssh-agent keys loaded.

Or you can set up your browser to automatically connect in one click from the Emulab web interface and pop up a connection window. Once you start swapping in an experiment, the Emulab Experiment Information page contains a table of the physical node ID and logical node name, status, and connection buttons. The captions at the top of the button columns link to pages explaining how to set up up mime-types in your browser to make the buttons work, from FreeBSD, Linux, and Windows workstations:

SSH (setup) - The SSH connection button gives a Bash or TCSH shell, as usual. Your Emulab ssh keys are installed on the node in a /sshkeys subdirectory.
Console (setup) - The serial console is supported for Cygwin shell logins using the agetty and sysvinit packages. This is the only way in when network connections are closed down! You can also monitor the Frisbee loading and booting of the Windows image on the console.
RDP (setup) - The RDP button starts up a Remote Desktop Protocol connection, giving a Windows Desktop login from the user's workstation screen to the experiment node.
- The rdesktop client software is used from Linux and Unix client workstations.
- A Microsoft RDC (Remote Desktop Connector) client program is included in Windows XP, and may be installed onto other versions of Windows as well. It has the cute feature that you can make it full-screen without (too much) confusion, since it hangs a little tab at the top of the screen to switch back. Unfortunately, we have no way to present your Emulab Windows password to RDC, so you'll have to type it on each login.

NOTE: If you import dot-files into Emulab that replace the system execution search path rather than add to it, you will have a problem running Windows system commands in shells. Fix this by adding /cygdrive/c/WINDOWS/system32 and /cygdrive/c/WINDOWS to your $PATH in ~/.cshrc and either ~/.bash_profile or ~/.profile. Don't worry about your home directory dot-files being shared among Windows, FreeBSD, and Linux nodes; non-existent directories in the $PATH are ignored by shells.

When new Emulab user accounts are created, the default CSH and Bash dotfiles are copied from the FreeBSD /usr/share/skel. They replace the whole $PATH rather than add to it. Then we append an Emulab-specific part that takes care of the path, conditionally adding the Windows directories on Cygwin.

NOTE: The Windows ping program has completely different option args from the Linux and FreeBSD ones, and they differ widely from each other. There is a ping package in Cygwin that is a port of the 4.3bsd ping. Its options are close to a common subset of the Linux and FreeBSD options, so it will be included in future WINXP images:

 ping [ -dfqrv ] host [ packetsize [count [ preload]]]

You can load it yourself now using Cygwin Setup .

NOTE: There are no Cygwin ports of some other useful networking commands, such as traceroute and ifconfig -a. The Windows system equivalents are tracert and ipconfig /all.

RDP details

Here are some fine points and hints for RDP logins to remote Windows desktops:

Microsoft allows only one desktop login at a time to Windows XP, although this is the same Citrix Hydra technology that supports many concurrent logins to Terminal Server or Server 2003. The Fast User Switching option to XP is turned on, so a second RDP connection disconnects a previous one rather than killing it. Similarly, just closing your RDP client window disconnects your Windows Login session rather than killing it. You can reconnect later on without losing anything. SSH doesn't count as a desktop, so you can ssh in and use this command: qwinsta (Query WINdows STAtion) to show existing winstation sessions and their session ID's, and this one to reset (kill) a session by ID: rwinsta
We rename My Computer to show the PCxxx physical node name, but it doesn't appear on the Windows XP desktop by default. The XP user interface incorporates My Computer into the upper-right quadrant of the Start menu by default, and removes it from the desktop. You can go back to the "classic" user interface of Windows 2000, including showing My Computer. Right-click on the background of the Taskbar which contains the Start button at the left, and choose "Properties". Select the "Start Menu" tab, click the "Classic Start menu" radio-button, and click "OK". Alternatively, you can force My Computer to appear on your XP desktop by right-clicking on the desktop background and choosing "Properties". Select the "Desktop" tab and click "Customize Desktop..." to get the "Desktop Items" dialog. Turn on the My Computer checkbox, then click "OK" twice.
There are several Desktop icons (i.e. "shortcuts") installed by default in the XP images: Computer Management, Bash and TCSH shells, and NtEmacs?. You will notice two flavors of Bash and TCSH icons on the desktop, labeled rxvt and Cygwin.
- The rxvt shells run in windows with X-like cut-and-paste mouse clicks:
  - Left-click starts a selection,
  - Right-click extends it, and
  - middle-click pastes. These are the ones to use if you're connecting from an X workstation.
- NOTE: The default colors used in Bash and rxvt don't work well in 4-bit color mode under RDP. Make sure you update your rdp-mime.pl to get the rdesktop -a 16 argument for 16-bit color. Or, you can over-ride the rxvt defaults by putting lines in your ~/.Xdefaults file like this:
  rxvt*background: steelblue
- The Cygwin shells run in a Windows Terminal window, just as the Windows cmd.exe does. These are the ones to use if you're connecting from a Windows workstation. Quick-edit mode is on by default, so you can cut-and-paste freely between your local workstation desktop and your remote RDP desktops. In a Windows Terminal window on your RDP remote desktop, the quick-edit cut-and-paste mouse clicks are:
  - Left-drag the mouse to mark a rectangle of text, highlighting it.
  - Type Enter or right-click the mouse when text is highlighted, to copy the selected text to the clipboard. (Escape cancels the selection without copying it.)
  - Right-click the mouse with nothing selected to paste the contents of the clipboard.
On the first login by a user, Windows creates the user's Windows profile directory under C:\Documents and Settings, and creates the registry key (folder) for persistent settings for that user. We arrange that early in the user's login process, a user HOME environment variable value is set in the user's registry. Otherwise Emacs wouldn't know how to find your .emacs setup file in your remotely mounted home directory. User "root" is special, and has a local home directory under /home. /home is a Cygwin symbolic link to C:\Documents and Settings.
The Windows XP Start menu has no Shutdown button under RDP. Instead, it is labeled Disconnect and only closes the RDP client window, leaving the login session and the node running. If you simply close the window, or the RDP client network connection is lost, you are also disconnected rather than logged out. When you reconnect, it comes right back, just as it was. To restart the computer, run /sbin/reboot, or use the "Shut Down" menu of Task Manager. One way to start Task Manager is to right-click on the background of the Taskbar at the bottom of the screen and select "Task Manager".

The `netbt` command

The NetBT (Netbios over TCP) protocol is used to announce shared directories (folders) from one Windows machine to others. (See the Name and Session services in http://en.wikipedia.org/wiki/Netbios.)

The SMB (Server Message Block) protocol is used to actually serve files. (See http://en.wikipedia.org/wiki/Server_Message_Block.)

In Emulab, we normally disable NetBT on experiment nodes, because it chatters and messes up slothd network idle detection, and is not needed for the usual SMB mounts of /users, /proj, and /share dirs, which are served from a Samba service on fs.

However, NetBT does have to be enabled on the experiment nodes if you want to make Windows file shares between them. The netbt script sets the registry keys on the Windows network interface objects. Run it on the server nodes (the ones containing directories which you want to share) and reboot them afterwards to activate. There is an optional -r argument to reboot the node.

    Usage: netbt [-r] off|on

If you use netbt to turn on NetBT, it persists across reboots.

No reboot is necessary if you use Network Connections in the Control Panel to turn on NetBT. It takes effect immediately, but is turned off at reboot unless you do netbt on afterward as well.

Right-click Local Area Connection (or the name of another connection, if appropriate), click Properties, click Internet Protocol (TCP/IP), and then click the Properties button.
On the Internet Protocol (TCP/IP) Properties page, click the Advanced button, and click the WINS tab.
Select Enable or Disable NetBIOS over TCP/IP.

ipconfig /all reports "NetBIOS over Tcpip . . . : Disabled" on interfaces where NetBT is disabled, and says nothing where NetBT is enabled.

To start sharing a directory, on the node, use the net share command, or turn on network sharing on the Sharing tab of the Properties of a directory (folder.)

On XP-SP2 or above, when you first do this, the "Network sharing and security" subdialog says:

      As a security measure, Windows has disabled remote access to this
      computer.  However, you can enable remote access and safely share files by
      running the _Network_Setup_Wizard_.
      _If_you_understand_the_security_risks_but_want_to_share_
      _files_without_running_the_wizard,_click_here._"

Skip the wizard and click the latter ("I understand") link. Then click "Just enable file sharing", and "OK".
Then you finally get the click-box to "Share this folder on the network".

The machine names for UNC paths sharing are the same as in shell prompts: pcXXX, where XXX is the machine number. These will show up in My Network Places / Entire Network / Microsoft Windows Network / Emulab once you have used them.

IP numbers can also be used in UNC paths, giving you a way to share files across experiment network links rather than the control network.

There is an Emulab-generated LMHOSTS file, to provide the usual node aliases within an experiment, but it is currently ignored even though "Enable LMHOSTS lookup" is turned on in the TCP/IP WINS settings. Try nbtstat -c and nbtstat -R to experiment with this. (See the Microsoft doc for nbtstat.

Making custom Windows OS images

Making custom Windows images is similar to doing it on the other Emulab operating systems, except that you must do a little more work to run the prepare script as user root since there are no su or sudo commands on Windows. This is optional on the other OS types, but on Windows, proper TCP/IP network setup depends on prepare being run.

Log in to the node where you want to save a custom image. Give the shell command to change the root password. Pick a password string you can remember, typing it twice as prompted:
```
         % passwd root
         Enter the new password (minimum of 5, maximum of 8 characters).
         Please use a combination of upper and lower case letters and numbers.
         New password:
         Re-enter new password:
```
This works because you are part of the Windows Administrators group. Otherwise you would have to already know the root password to change it. NOTE: If you change the root password and reboot Windows before running prepare below, the root password will not match the definitions of the Emulab Windows services (daemons) that run as root, so they will not start up.
Log out all sessions by users other than root, because prepare will be unable to remove their login profile directories if they are logged in. (See QWINSTA.)
Log in to the node as user root through the Console or SSH, using the password you set above, then run the prepare command. (It will print "Must be root to run this script!" and do nothing if not run as root.)
```
         /usr/local/etc/emulab/prepare
```
If run without option arguments, prepare will ask for the root password you want to use in your new image, prompting twice as the passwd command did above. It needs this to redefine the Emulab Windows services (daemons) that run as root. It doesn't need to be the same as the root password you logged in with, since it sets the root password to be sure. The Administrator password is changed as well, since the Sysprep option needs that (below.)
- You can give the -p option to specify the root password on the command line:
```
    	   /usr/local/etc/emulab/prepare -p myRootPwd
```
- The -n option says not to change the passwords at all, and the Emulab Windows services are not redefined.
```
    	   /usr/local/etc/emulab/prepare -n
```
- The -s option is used to make hardware-independent images using the Windows Sysprep deploy tool. If you use it with the -n option instead of giving a password, it assumes that you separately blank the Administrator password, or edit your Administrator password into the [GuiUnattended]AdminPassword entry of the sysprep.inf file.
```
    	   /usr/local/etc/emulab/prepare -s -p myRootPwd
```
  NOTE: This must be done from a login on the serial console, because Sysprep shuts down the network. prepare -s refuses to run from an SSH or RDP login.
  NOTE: Currently, hardware-independent images must be made on a pc850, and will then run on the pc600, pc3000, and pc3000w as well. There is an unresolved boot-time problem going the other direction, from the pc3000 to a pc850 or pc600.
  Windows normally casts some aspects of the NT image into concrete at the first boot after installation, including the specific boot disk driver to be used by the NT loader (IDE, SCSI, or SATA.) Sysprep is used by PC hardware manufacturers as they make XP installation disks with their own drivers installed. The Sysprep option to run an unattended Mini-Setup at first boot instead of the normal "Out Of the Box Experience" is used in some large corporate roll-outs. We do both. The Emulab /share/windows/sysprep directory contains several versions of the XP deploy tools matched to the XP service pack level, appropriate device driver directories, and a draft sysprep.inf file to direct the automated install process. Mini-setup needs to reboot after setting up device drivers. XP also needs to reboot after changing the host name. We combine the two by using a `Cmdlines.txt` script to run rc.firstboot -mini to set the host name at the end of Mini-Setup. Thus we only pay the extra time to set up device drivers and so on from scratch, about two minutes, rather than adding a third hardware and XP reboot cycle. NOTE: as you create your Image Descriptor, set the reboot wait-time to 360 rather than 240 so that swap-ins don't time out.
Then log out and create your custom image.
NOTE: Windows XP is too big to fit in the partitioning scheme used by FreeBSD and Linux, so it's necessary when making a Windows custom image to specify Partition 1, and click Whole Disk Image.
When you're testing your custom image, it's a good idea to set the tb-set-node-failure-action to "nonfatal" in the ns file so you get a chance to examine an image that hasn't completed the set-up process. See the note below for other useful ideas.

Cygwin

Cygwin is GNU + Cygnus + Windows , providing Linux-like functionality at the API, command-line, and package installation levels.

Cygwin documentation

Cygwin is well documented. Here are some links to get you started:

Cygwin packages

A number of optional Cygwin packages are installed in the image due to our building and running the Emulab client software, plus some editors for convenience. These packages are currently agetty, bison, cvs, cygrunsrv, ed, file, flex, gcc, gdb, inetutils, make, minires-devel, more, nano, openssh, openssl-devel, patch, perl, perl-libwin32, psmisc, python, rpm, rsync, shutdown, sysvinit, tcsh, vim, wget, and zip.

The Cygwin command cygcheck -c lists the packages that are installed, and their current version number and status. Package-specific notes and/or documentation for installed packages are in /usr{,/share}/doc/Cygwin/*.README and /usr/share/doc/*/README files. The Cygwin package site lists the available pre-compiled packages and provides a search engine.

If you want to install more Cygwin pre-compiled packages, run the graphical installer:

    C:/Software/Cygwin/setup.exe

The Cygwin command cygcheck -l ''package-name'' lists the contents of an installed package, which may help you to make a tarfile or rpm from a package you have installed. You can then cause it to be installed automatically by Emulab into all of the nodes of your experiment. See the [Tutorial#TARBALLS Tutorial] for more information about installing RPM's and tarballs.

Watch out for post-install scripts in:

    /etc/postinstall/''package-name''.sh{,.done}

Many packages not in the Cygwin package site have also been ported to Cygwin already. Download the sources to an experiment node and try

    ./configure
    make
    make install

as usual.

SMB mounts and Samba

User home directories and other shared directories are served by fs, another alias for Ops/Users, via the SMB protocol (Server Message Block, also known as Windows File Sharing) with the Windows Client connecting to the Samba server.

UNC paths with leading double-slashes and a server name, e.g. //fs, are used to access the SMB Shares under Cygwin. Emulab then uses the Cygwin mount command to make them appear on the usual Unix paths for the Emulab shared directories: /users/<username>, /proj/<pid>, /group/<pid>/<gid>, and /share.

The Cygwin mount command lists what you could access on the Samba server, with the UNC path in the first column. Unix file permissions may further limit your access on the Samba server. Log in to Ops to investigate.

/share/windows contains Windows software. See /share/windows/README.bin for descriptions of binary packages available for installation.

Windows limitation: There is only one protection mask for everything in a whole mount/share under SMB. It's set in the "share properties" on the server (Samba config file in this case) so chmod will do you no good across SMB.

Cygwin limitation: There is a hard-coded limit of 30 mount points in Cygwin. Cygwin uses 4 of them, and Emulab uses another 3 or 4. So some of your /users mounts will fail on Windows startup if you have more than 23 or 24 members in your project, unless they are grouped into smaller subgroups.

Cygwin arcana

File paths Cygwin accepts either flavor of slashes in paths, Unix/POSIX-style forward-slashes, or Windows-style back-slashes. In Unix shell commands, backslashes need to be quoted. Single-quotes work best. Doubling each backslash also works. This must also be done inside double-quotes. Examples: '\single\quoted', "\\double\\quoted", \\un\\quoted. (The difference between double and single quotes is that $variable references and back-quoted command execution are expanded in double-quotes.) When you invoke Windows (as opposed to Cygwin) commands, for example net use, they will know nothing about Unix-style paths in their arguments. The cygpath utility is an aid to converting paths between the Unix and Windows conventions. cygpath -w converts its arguments to Windows format, and cygpath -u converts its arguments to Unix format, e.g.
```
  	 $ cygpath -w /cygdrive/c/WINDOWS
  	 c:\WINDOWS
  	 $ cygpath -u 'c:\WINDOWS'
  	 /cygdrive/c/WINDOWS
```
Mount points Cygwin mount points are shown by the mount and df commands. Note that there is a hard-coded limit of 30 mount points in Cygwin. Attempts to use the Cygwin mount command after that will fail. See the discussion of mount points and UNC //machine paths to SMB shares above . Another special case is the Unix root, "/". It's mounted to C:\cygwin in the Windows filesystem.
Drive letter mounts Cygwin knows about drive letter prefixes like C:Â , which are equivalent to /cygdrive/<drive-letter>Â . However, /cygdrive, like /dev, isn't a real directory, so you can't ls it. Some Windows software requires drive-letter mounts to be created for its use. You can use the Windows net use command to associate drive letters with UNC paths to SMB shares, e.g.
```
  net use W: '\\fs\share\windows'
```
You can use the Windows subst command to associate drive letters with local paths, e.g.
```
  subst T: 'C:\Temp'
```
Filename completion in Cygwin shells with <Tab> doesn't work following a drive-letter prefix, but it works normally after a /cygdrive/ prefix. Also, filename completion is case-sensitive, although the underlying Windows is case-insensitive, so a filename in the wrong case is still opened properly.
NTSEC Cygwin is running in NTSEC (NT Security) mode, so /etc/passwd and /etc/group contain Windows SID's as user and group ID's. Your Windows UID is the computer SID with a user number appended, something like S-1-5-21-2000478354-436374069-1060284298-1334. Cygwin commands, such as id, ls -ln, and chown/chgrp, use the numeric suffix as the uid, e.g. 1334. This is different from your normal Emulab Unix user ID number, and the Samba server takes care of the difference. The id command reports your user id and group memberships. Note that all users are in group None on XP. Contrary to the name, this is a group that contains all users. It was named Everybody on Windows 2000, which was a better name.
setuid There is no direct equivalent of the Unix setuid programs under Windows, and hence no su or sudo commands. The Windows equivalent to running a Unix command as root is membership in the Windows Administrators group. Emulab project members who have either local_root or group_root privileges are put in group wheel, another alias for Administrators. Project members with user privileges are not members of the wheel group. You can ssh a command to the node as the target user, as long as you arrange for the proper authentication. For C/C++ code, there is a setuid() function in the Cygwin library, which "impersonates" the user if proper setup is done first.
root There is not normally a Windows account named root. root on XP is just another user who is a member of the Administrators group, see below. We create a root account as part of the Emulab setup to own installed software, and to run services and Unix scripts that check that they're running with root privileges. You can log in as root via RDP, ssh, or the serial console if you change the root password as described in the custom Windows OS images section. The root user does not have any Samba privileges to access Samba shared mounts, including the /proj, /groups, and /users.
Administrators group All users are members of the Windows Administrators group. (The Emulab non-local-root user property is not implemented on Windows.) Membership in the Windows Administrators group is very different from being root on Unix, and is also different from being logged in as Administrator. Administrators group membership on Windows only means you can set the ownership, group, and permissions on any file using the Cygwin chown, chgrp, chmod, or their Windows equivalents. Until you have done that, you can be completely locked out by read, write, or execute/open permissions of the directory or files. Another subtlety is that the group called None on XP is what used to be named Everybody on Windows 2000. All users are automatically in group None, so in practice setting group None permissions is no different from setting public access permissions.
Permissions Cygwin does a pretty good job of mapping Unix user-group-other file permissions to Windows NT security ACLs. On Windows, unlike Unix, file and directory permissions can lock out root, Administrator, or SYSTEM user access. Many Unix scripts don't bother with permissions if they're running as root, and hence need modification to run on Cygwin. This creates a potential problem with the tb-set-node-tarfiles and tb-set-node-rpms commands. The tb-set-node-tarfiles page says "Notes: 1. ... the files are installed as root". So you can easily install files that your login doesn't have permission to access. The solution is to chmod the files before making the tarball or rpm file to grant appropriate access permissions.
Executables Cygwin tries to treat .exe files the same as executable files without the .exe suffix, but with execute permissions turned on. (See the Cygwin Users Guide .) This breaks down in Makefile actions and scripts, where rm, ls -l, and install commands may need an explicit .exe added.
Windows GUI programs You cannot run Windows GUI (Graphical User Interface) programs under ssh, on the serial console, or by tb-set-node-startcmd. There is no user login graphics context until you log in via RDP. However, you can use a startcmd to set a Windows registry key that causes a GUI program to be run automatically for all users when they log in to the node via RDP, if that's what you want. The program can be one that is installed by tb-set-node-tarfiles. You can pick any regkey name you want and put it in the Run registry folder. It's good not to step on the ones already there, so choose a name specific to your program. Put the following in your startcmd script:
```
         regtool -s set /HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Run/mypgm 'C:\mypgm\mypgm.exe'
```
(where mypgm is the name of your program, of course.) Notice that the value string is single-quoted with C: and backslashes. Windows interprets this regkey, and wants its flavor of file path.

NtEmacs

We don't include the Cygwin X server in our XP images to keep the bulk and complexity down. So NtEmacs 21.3 is provided instead of the Cygwin X Emacs. NtEmacs "frames" are windows on the Windows Desktop, e.g. ^X-5-2 makes another one.

The /usr/local/bin/emacs executable is a symlink to /cygdrive/c/emacs-21.3/bin/runemacs.exe, which starts up an Emacs on the desktop. This only works under RDP, since SSH logins have a null desktop.

There is also a /usr/local/bin/emacs-exe executable, a symlink to /cygdrive/c/emacs-21.3/bin/emacs.exe, which is only useful as an Emacs compiler. It could be used to run Emacs in an SSH or Serial Console login window with the -nw (no windows) flag, except that it exits with emacs: standard input is not a tty. Another thing not to try is running emacs-exe -nw in a Bash or TCSH shell on the RDP desktop. It crashed Windows XP when I tried it.

Can drag-and-drop files from Windows Explorer to NtEmacs windows.
cygwin-mount.el in c:/emacs-21.3/site-lisp/ makes Cygwin mounts visible within NtEmacs. It doesn't do Cygwin symlinks yet.
Options - See ~root/.emacs
- mouse-wheel-mode
- CUA-mode option ( ^C copy / ^X cut on selection, ^V paste, ^Z undo).
- Ctrl and Alt key mappings, etc.

Microsoft .Net Runtime

We have not included the Microsoft .NET Framework runtime in the standard WINXP images in an attempt to keep the image size down. If you need it, it's easy to install.

The installer for the Microsoft Framework Version 1.1 Redistributable Package is downloaded to /share/windows/dotnetfx.exe. Run it to download the runtime, agreeing to the EULA. It takes a few minutes, and uses 104 meg of disk.

If you want to develop .NET code as well as run it, you will need to install the .NET Framework SDK Version 1.1 .

Change Log

2006-11-16 Emulab client-side update

Updated the Emulab software to the latest versions, including:
- Linktest: efficiency improvements and fix for intermittent one-way loss bug.
- Event system improvements.
Additional minor stuff
- Increased C: drive space from 4 gig to 8 gig.
- Windows Update through the 11/14/2006 Patch Tuesday, on the UPDATE image only. Not installing IE 7.0 yet.

2006-07-28

Updated the Cygwin and Emulab software to the latest versions, including:
- A new version of the Emulab Linktest program. It does a better job of finishing-up, so the last packet (number 401) tends to make it through rather than getting dropped all the time. Windows still has more episodes of significant packet loss than either FreeBSD or Linux.
- Bug-fixes in the workarounds for Windows network-setup flakiness. Setup is now pretty reliable, but Linktest level 4 (bandwith test) reveals that Windows XP can't keep up with a 100 mb/s LAN link; 85mb/s is about the best it'll do.
- Added the netbt script to enable serving Windows file shares from an experiment node, see The `netbt` command .
- The OpenSSH package is now version openssh-4.3p2-4 .
- Added the Cygwin "netcat" package for the nc program. There's no man page, but see /usr/share/doc/netcat/README.

2006-04-04

Switch to hardware-independent images, using the Microsoft Sysprep/Mini-Setup programs [1] [2] [4] [5] via the "prepare -s" option. It is no longer necessary to specify the hardware type with an image suffix, although you may want to do so to control the allocation of physical nodes to your experiment. The unsuffixed WINXP-{SP[012],UPDATE} images will now run on the pc3000 and pc3000w (WiFi) nodes, in addition to the pc850 and pc600. For compatibility with existing experiments, the image names with -pc3000 suffixes will still work, but they are just symlinks to the unsuffixed images. Notes:
- Currently, hardware-independent images must be made on a pc850, and will then run on the pc600, pc3000, and pc3000w as well. There is an unresolved boot-time problem going the other direction, from the pc3000 to a pc850 or pc600.
- The WINXP-SP0 image is almost pure from the 2001 XP CD, but has a 2002 SP1a pci.sys . This is needed to boot on the pc3000's which have a newer PCI chipset.
- These images work on the __pc3000w (WiFi) nodes. There are drivers for the NetGear WAG311 WiFi cards installed, but no Emulab support to set up wireless networking under Windows XP yet.
- None of these images will boot on the pc2000 nodes. It's probably a boot disk driver error under Mini-Setup for the ATA100 IDE controller.
- There is a problem with TCP/IP that affects only SP0 or SP1 images running on the pc600's. (This may be due to the older versions of Sysprep/Mini-Setup for SP0 and SP1.) Due to this, the pc600 bit is turned off for the hardware-independent WINXP-SP0 and -SP1 images. Details: Outgoing connections work fine, so the node sets up under Emulab correctly. Incoming ssh connections time-out, although RDP works fine. Netstat shows the ssh socket 22 listening, but no connection attempts are logged by sshd in /var/log/messages. Packet capture shows that TCP SYN packets are being received, but the SYN-ACK handshake never goes out, so it's a lower-level problem.
Also fix an account creation bug and add more workarounds for Windows boot-time and network-setup flakiness. It seems that adding Sysprep to the mix has also improved the reliability of TCP/IP stack setup, probably because it tears down all of the internal network interface data structures and recreates them. This adds about two minutes to the Windows setup time, which seems worth-while.

2006-02-14

The -UPDATE images include the most recent round of Microsoft patches, plugging both known WMF holes and many others. The -SP* images of course don't have the WMF holes plugged, but that's no different from before.
When making custom Windows images, the prepare script now requires you to set your own root password.
Within the Emulab code, these images restore linktest to working condition.
The other changes are intended to make Windows booting and setup more reliable. One is that sshd is turned off during rc.bootsetup, since it would sometimes go into a loop, eating the CPU and preventing setup from finishing before timing out. Unless you're logging in as root, it won't do you much good to try to log in before accounts are set up anyway... In case of trouble, log in via RDP or the serial console, and say "net start sshd" in a shell.
There is a random problem where one of the network interfaces disappears from ipconfig due to a race condition within Windows startup. rc.cygwin/rc.ifconfig now work harder at resetting the interfaces, and reboot as a last resort if that fails. It seems that fixing one interface can make the problem move to another one though. Unless you use all four available experimental-network interfaces in an experiment topology, this should fix the problem.

2005-11-22

Enable linktest, including ltmap fetching, misc fixes, (c)rude and iperf.
Add hacks in watchdog, slothd, and idlemon for clock setback.
Back-rev OpenSSH to 4.1 in an attempt to cure sshd boot-time busy-looping.
Add rxvt shell windows for X-like mousing.

2005-10-28

Race condition tweaks to rc.cygwin, add rc.firstboot to EmulabStartup service.
Cleanup tweaks to prepare and liblocsetup.pm .
Add Cygwin ping package.

2005-9-29

Cygwin updated, including OpenSSH 4.2p1-1 .
Serial console now works, with agetty and sysvinit providing a login shell.
network settings: DNS interface registration and TCP/IP autoconfiguration disabled, disabled unused experimental net interfaces, IPEnableRouter enabled on multihomed experimental nodes.
slothd: RDP idlemon for RDP keyboard and mouse events, load-avg correction on pc3000's.
program-agent: commands forked on experiment nodes now see Samba directories.

2005-8-22

Everything created behind control-net firewalls to avoid contamination.
Patched sshd to support public-key login with Samba shares, and slothd.
Emulab program-agent, syncserver and slothd idle detection all work now.
NetBT (NetBios over TCP) is disabled to allow network idle detection by slothd.
Cygwin syslog now goes into /var/log/messages rather than Event Log.
Some Windows services are shut down: Messenger, SSDP Discovery Service, Universal Plug and Play Device Host, and Remote Registry.
Image creation time now put in /etc/motd.

Future Work

There are still some things undone:

Automate production of Windows XP images for Emulab.
Dynamic routing support for rtproto Session?
Support for setting up WiFi networking under Windows XP?

Download in other formats:

Plain Text