Configuring Windows 2000/2003 for Etherboot
Paul Whittaker (Paul.Whittaker@iname.com)
Director, Cloud Network Technologies Pty Ltd, Australia
Last Update: 7 Nov 2004
Index
Windows 2000 Server and Windows 2003 Server provide a full featured DHCP
server that is quite capable of supporting Etherboot-based diskless/thin
clients. This document explains how.
The DHCP servers provided with Windows 2000/2003 Server and Windows NT 4.0
Server are functionally equivalent except for some back-end storage differences
related to Active Directory. There are substantial interface differences,
however - the Windows 2000/2003 DHCP manager interface is much improved and far
more intuitive. This document therefore applies generally to Windows NT4 also,
but the instructions provided here usually cannot be applied literally to the
NT4 interface - you must search for the analogous actions under NT4.
It should also be noted that the version of DHCP server provided with early
distributions of NT 4.0 (circa Service Pack 3) is badly broken - you must apply
a recent service pack before it will work with Etherboot.
One thing that Windows DHCP server is not capable of is conditional
selection of option values based on vendor class identifiers at run-time.
It therefore cannot be used to perform a two-step PXE/Etherboot bootstrap.
However, recent versions of Etherboot provide some PXE workarounds (PXE_IMAGE,
ZPXE_SUFFIX_STRIP) that ought to make the old two-step method unnecessary. If
for some reason you need to use the old method, I am told that Weird Solutions' DHCP
Turbo can do it; for a free solution you could use the Internet Software Consortium version 3 DHCP
server under Cygwin.
Unfortunately, some DHCP client implementations cannot properly decode
Windows DHCP server responses. In particular, this is a problem with dhclient
2.0, and (last time I checked) the DHCP IP autoconfiguration feature of the
Linux kernel.
As at October 2004, LTSP 3.0 still used dhclient 2.0pl5, which will not work
properly with Windows DHCP. Early releases of LTSP 4.0 also used dhclient
2.0pl5, but it now looks as though 4.0 has changed, or will be changing, to
dhcpcd 1.3.x. In 2003 I constructed working replacement initrds for both network and pcmcia booting based on ltsp_initrd_kit-3.0.5 using dhcpcd 1.3.22-pl3
instead of dhclient, and submitted them to the LTSP maintainer. For your
convenience I have made available a one-off network
boot image featuring the alternate initrd. I do not intend to update
this.
In addition to basic environment information (client IP address, subnet
mask, default gateway), open source solutions based on Linux and Etherboot
typically require that the DHCP server:
- Provide the client with a (TFTP) boot server address and a boot file name,
and in the case of NFS-based thin clients such as LTSP, NFS root server and path information also.
- Provide the client with its hostname. Variations in hardware capability
are typically categorised by hostname in configuration files (for
administrative convenience). Hostnames are also useful for reporting purposes
(syslog etc).
- Provide the client with DNS domain name and DNS server information.
- Provide the client with Etherboot-specific options 128 and 129 (possibly
also 130), which can be used to pass arguments to the Linux kernel.
- Provide a permanent IP address (either by fixed mapping or permanent lease),
usually needed because the diskless Linux device is unable to adequately
reconfigure itself to a new IP address on-the-fly due to in-use network
connections. A fixed mapping between MAC (hardware) address and IP address may
also be required for other reasons to do with accounting or security (for
example, limiting availability of a boot image to known MAC addresses).
This is not the way DHCP is normally used in the Windows universe.
Typically the client provides a hostname in its DHCP request and the server
issues it with a temporary IP address, which the server then associates with
that hostname for the duration of the lease. This is usually not achievable
for diskless clients because the client typically has no permanent storage and
therefore no way to store a hostname. Windows DHCP can nevertheless be
configured to do what we want.
- Start the DHCP manager by selecting the DHCP option from the
Admin Tools submenu of the Programs menu.
- If you have not already done so, authorise your DHCP server. This is
necessary to allow your DHCP server to update Active Directory (specifically
for dynamic DNS). Select the server hostname and then Authorize from
the Actions menu.
- If you have not already done so, create a scope (New Scope.. in the
Actions menu). You'll need to specify a start and end address, subnet
mask, and any exclusions (excluding your server IP address is probably a good
idea!). Otherwise, default values should be OK. You can defer configuring
scope options and activating the scope for now, we'll deal with that later.
If you want to prevent your DHCP server from serving unknown clients, you
should exclude the entire IP address range of the scope, such that only clients
with reservations can be granted an IP address (see below).
- Select the server name and then select Set Predefined Options..
from the right-hand mouse button menu. Click Add.. to add two new
entries to DHCP Standard Options set:
- Add an option called Etherboot ID with code 128; use data type
Byte and check the array box.
- Add an option called Etherboot Params with code 129 and data type
String.
- We now want to preset the contents of the new Etherboot ID option to
a special value that cues Etherboot to make use of the 129 and 130 options, if
present. To do this, select the Etherboot ID option and click on
Edit Array... Select the Hexidecimal radio button and add the hex
digits 0x0, 0x68, 0x74, 0x45, 0xe4 (you must include the 0x prefixes) in that
order. Do not delete the 0x0 value that is already present. The final display
should read "e4 45 74 68 00 00" when done.
- Now we need to configure some basic options. Each option may be configured
at global, scope, or reservation level; the choice depends upon how many scopes
you are serving, which scopes contain non-Etherboot clients, and whether or
not the option is scope-specific (ie. subnet-specific), Etherboot-specific, or
client-specific. Typically it is convenient to configure most options at scope
level. Click on Scope Options and then select Configure Options
from the right-hand mouse button menu. Select the checkboxes corresponding to
the desired options and set values appropriately. Minimally you will need the
following:
| Option No | Option Name | Example Value |
|---|
| 6 | DNS Servers | 10.0.0.4 |
| 15 | DNS Domain Name | cloud.com.au |
| 17* | Root Path |
10.0.0.4:/ltsroot** |
| 66 | Boot Server Host Name | nimbus |
| 67 | Bootfile Name | /tftpboot/bootimg** |
| 128 | Etherboot ID | e4 45 74 68 00 00 |
*Only needed if client is NFS-based.
**Must use UNIX filename conventions (forward slashes). The
drive prefix (c: or whatever) is implicit, its value depending upon the
configuration of the TFTP/NFS server(s), and must be omitted.
- For each Etherboot client you can now add a reservation. Within the
scope, click Reservations and then select New Reservation.. from
the right-hand mouse button menu. Important fields are IP address and
MAC address; the Reservation name is just a label (you can use
the hostname if you like), and Both is a safe default for Supported
types. Enter the MAC address as a simple 12-digit hexidecimal string
(lower case OK) - no colon or period separators. Click Add, and
Close when finished adding reservations.
- Expand the reservations group, then for each reservation select the
reservation and then Configure Options.. from the right-hand mouse
button menu. One or both of the following options may be needed:
| Option No | Option Name | Example Value |
|---|
| 12 | Host Name | cumulonimbus |
| 129 | Etherboot Params | NIC=ne IO=0x320 |
It isn't strictly necessary to have DNS entries for all of your Etherboot
client reservations, but it is generally a good idea to do so. At the very
least you should ensure that A and PTR records exist for your server name for
the interface relevant to your Etherboot scope. Role-specific aliases (CNAMEs)
for your server may also be useful.
If you are using Citrix Metaframe XP / Presentation Server, you should also
add a CNAME alias "ica" for the host providing your ICA XML browser service.
The Citrix ICA Client uses this as a hardcoded fallback in the absence of
explicit browser server information.
Windows 2000/2003 provides a TFTP server that can be used to serve Etherboot
images as part of the Remote Installation Services package. Although it is not
intended to be used outside of a RIS context, it is possible to do so with some
difficulty.
Normally it is not possible to install the TFTP server in isolation - you
must install the entire RIS service, which will subsequently complain
incessantly about being left unconfigured until you feed it the Windows 2000
Professional CDs that it wants. However, Morgan Simonsen (mds at tiscali dot
no) and Stefan Kanthak (skanthak at nexgo dot de) have devised ways around
this. Morgan's solution is available from http://www.simonsen.bz/Download/TFTPDaemon_v1.1.zip. Stefan has written a
tftpd.inf file that you can use to install the TFTP server from the Windows CD
- download this file, then simply right click on this file and select
Install. Robert Ardill (robert dot ardill at saugov dot sa dot gov dot
au) has provided an updated version which works with
Windows 2K3.
To use Windows 2000 TFTP server, you must tweak the registry to tell the
server which directory to use as the TFTP root. The value needed is:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tftpd\parameters\Directory
If you have not yet configured RIS, some of the rightmost keys in this path
will be missing and you will have to create them. The string value is simply
a Windows pathname of your choice, eg. C:\Tftpboot or whatever.
Having set this, you need only use the Windows Control Panel to configure the
TFTP service to start automatically.
For NT 4.0 you will need to find a third party TFTP server. If you need a
server which supports the "tsize" option (eg. for PXELinux), try tftpd32. Otherwise, I recommend TFTP
Server 1.2 for NT by Bud Millwood (Millwood Data A.B., Sweden), a shareware
product at an entry price of US$40. This is the best well-behaved no-frills NT
service I have found so far. This is a defunct product which is no longer
widely available, having been superceded by Weird Solutions' TFTP Turbo, so I've made
a copy available here. Millwood TFTP
Server runs as a service under both Windows NT4 and Windows 2000, and keeps
working indefinitely without a license.
There are no good NFS server implementations for Windows platforms. NFS
implements traditional UNIX file ownerships and permissions, which don't map
well to FAT (which has no notion of permissions) or NTFS (which has more
advanced ownership and permission capabilities). Windows also has no notion of
a symbolic link or a block/character special file. Consequently the best that
one can hope to achieve is a clumsy emulation of a UNIX-like filesystem.
If your NFS-based diskless client uses the devfs pseudo-filesystem
(2.4/2.6), or sets up /dev in a ramdisk via udev (2.6), then you can
sidestep the requirement for block/character special files in your NFS root.
However, the requirement for symbolic links is not so easy to dodge. A free
Microsoft product known as Microsoft Windows Services For UNIX (SFU) includes an NFS server for
Windows that supports symbolic links, but I don't know of any Windows NFS
servers that support block/character special files.
If you have a requirement to serve diskless/thin clients from a Windows
platform, I urge you to consider a self-booting solution (CDROM or flash disk)
or a solution that only requires TFTP (such as DIET-PC, Thinstation or PXES) rather than NFS-based solutions such
as LTSP. If you do want to use NFS/LTSP,
here's how to do it using Microsoft SFU:
- Create a directory to serve as your NFS root directory, eg.
c:\ltsroot, and a subdirectory named "etc" within this directory.
You must use an NTFS filesystem.
- Using a Windows TFTP or FTP client program (e.g. tftp.exe or
ftp.exe), transfer the /etc/passwd and /etc/group
files from the thin client root filesystem on your development box into the
newly created etc directory. If you are using LTSP, you will find
these files in /opt/ltsp/i386/etc.
- Install Windows Services for UNIX 3.5. SFU provides a wide range of
services; the only components of interest to us in this instance are Server
for NFS, User Name Mapping and Server for NFS Authentication.
If you are using an older version of SFU, beware: it may not work with an
installation path that contains spaces (such as C:\Program Files\SFU).
For SFU 3.5, you will be asked some up-front questions during the install. You
should select Change the default behaviour to case sensitive, and opt
for a Local Unix Name Mapping Server using Password and Group
Files (unless you also want to install the NIS server, and your thin
clients are cabaple of using NIS, in which case NIS is also an acceptable
option; in this case, ensure that you add the relevant NIS options to DHCP
also). When prompted for the location of the UNIX password and group files,
enter the locations of the /etc/passwd and /etc/group files
that you transferred earlier (eg. c:\ltsroot\etc\passwd).
- After install, select Services for UNIX Administration from the
menu. If you are using an old version of SFU which didn't prompt for UNM
options during the install, select Server for NFS and then the
User Mapping tab and then enter "localhost" in the text box. No
extra Server for NFS configuration is required for SFU 3.5.
- Select User Name Mapping, and then the Configuration tab.
If you have an old version of SFU which didn't prompt for passwd and
group file locations during the install, Click the PCNFS radio
button and enter these now. Don't be alarmed by the term "PCNFS", it really
just means flat files, as opposed to NIS; this wording was corrected in later
versions of SFU. Now click Apply (at top right).
Select the Maps tab, and click the Advanced maps radio
button if there is one. We must now create advanced maps for both passwd and
group. Click on Show User/Group Maps to edit, then click
List Windows Users/Groups and List UNIX Users/Groups to expand
the lists. You should select Set Primary for each mapping you create.
Suggested mappings for LTSP are as follows:
| Type | Windows Name | UNIX Name |
|---|
| passwd | YOURDOMAIN/Administrator | root |
| passwd | YOURDOMAIN/Guest | nobody |
| passwd | YOURDOMAIN/krbtgt | bin |
| group | YOURDOMAIN/Domain Admins | root |
| group | YOURDOMAIN/Domain Guests | nobody |
- Click Apply (at top) and close the Services for UNIX
Administration snap-in.
- To activate NFS sharing, start Windows NT Explorer from the menu,
right click on on the NFS root directory you created earlier, select
Sharing... and then select the NFS Sharing tab in the window
which appears. Use the Permissions button to set sharing to
Read-Only for the default group ALL_MACHINES (also enable root
access, if you have that as a separate option), and then add an explicit
Read-Write permission with root privileges (a single option in SFU 2.0, or a
combination of options in 3.5) for the development box from which you will be
transferring your thin client root filesystem.
- Recursively change onwership of the NFS root directory to the Windows user
which you mapped to "root" above. Under NT4, you can't do this - although NTFS
will support it, NT4 only gives you the option to "Take Ownership", not to
assign it to an arbitrary user, and the implied owner is the
Administrators group, not the Administrator user. As a
workaround, you will have to recursively assign Full Control privileges
to the Everyone group for the time being (copying files from UNIX using
tar will correct this later).
- Set the following ACLs on the NFS root directory and all subdirectories
recursively, replacing any existing ACLs: Full Control for
Administrator, and Read and Execute for Administrators,
Everyone and ANONYMOUS LOGON (not necessary if it is included
in Everyone, which is the case for W2K and earlier, but not XP/W2K3).
This is equivalent to root:root rwxr-xr-x. Broadly speaking, SFU equates the
NTFS owner and any corresponding ACL with the UNIX "user" permission set, the
Everyone ACL with the "other" permission set, and any other ACL with the
"group" permission set. In SFU 3.5, ANONYMOUS LOGON is associated with
the anonymous NFS user (the UID to which all unresolvable UIDs are mapped).
Note that, while historically it was the case, the anonymous NFS user is
generally no longer associated with nobody. Due to overuse of this
identity by other UNIX services, most UNIX distributions now have a separate
identity for this purpose (nfsnobody et al).
-
There are some additional version-specific considerations:
- SFU 2.0
- Before copying files from your development platform, check and correct
permissions on the files you are about to copy. SFU 2.0 doesn't interpret some
permission combinations properly, because of the way it maps permissions onto
NTFS. In some cases SFU 2.0 uses explicit denials to ensure no access, which
has some odd side effects, because the denials take precedence over the allows.
For example, you must ensure that all files are readable by group and other,
because Administrator is a member of Everyone and Everyone
would be denied access. Don't use --x in any column, it isn't
understood. Directories must be owner-writable or else you won't be able to
read them. In general, it's safest to stick to rwxr-xr-x,
rw-r--r-- and r--r--r-- only.
- SFU 3.0
- I have not tested SFU 3.0, and do not know its peculiarities. I expect
that its behaviour is similar to that of 3.5.
- SFU 3.5
- SFU 3.5 is more tolerant of odd UNIX permissions, but much stricter in
its mapping to Windows identities. You must enable the Allow anonymous
access option in the NFS sharing tab (the default -2 values are OK),
or else NFS clients will hang when trying to perform any NFS operation.
ANONYMOUS LOGON access may need to be explicitly granted as stated
above, and you also need to bypass traverse checking for ANONYMOUS LOGON
in XP or W2K3 (see the SFU help - Getting Started section, How To
subsection). Oddly - from the UNIX perspective - you cannot create files as
a UNIX UID that maps to a disabled Windows account; it will get mapped to the
anonymous user instead. This means that you will either have to enable the
Guest account (typically disabled by default), or create an alternate
Windows account for nobody to map to.
- On your development platform, mount the NFS root directory from your
Windows server (use forward slashes instead of backslashes and omit the drive
letter prefix), and transfer files using a method that preserves ownership and
permissions (e.g. tar cf - . | tar xCf /mnt -).