Configuring Windows 2000 for Etherboot
Paul Whittaker (Paul.Whittaker@iname.com)
Director,
Cloud Network Technologies Pty Ltd, Australia
Last Update: 19 Apr 2003
Index
Windows 2000 Server provides a full featured DHCP server that is quite
capable of supporting Etherboot-based thin clients. This document explains
how.
The DHCP servers provided with Windows 2000 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 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.
One thing that Windows 2000 DHCP 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. If you
need to do this, 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.
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.
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 April 2003, LTSP 3.0 still used dhclient 2.0pl5, which will not work
properly with Windows DHCP. I have 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 it 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 thin client solutions based on UNIX 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 fixed mapping between MAC (hardware) address and IP address. A
fixed mapping may be required for accounting or security reasons (eg. billing,
monitoring, or firewall access controls). A permanent IP address (either by
fixed mapping or permanent lease) is also required if the client cannot
adequately reconfigure itself to a new IP address on the fly - difficult to do
on a thin client, which is critically network dependent and likely to have
established connections even when not actively in use.
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 thin 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.
- 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. You could do this at either
the global or scope level. If you are using the DHCP level for non-Etherboot
purposes, it's probably a better idea to do this 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 thin client is
NFS-based.
**Must use UNIX filename conventions (forward
slashes). The drive prefix (c: or whatever) is implied by the setup of the
TFTP/NFS server(s) and must be omitted.
- For each Etherboot thin client you must 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, 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 default in the absence of user-provided browser server
information.
Windows 2000 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. Unfortunately 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 it wants. Sigh.
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.
Personally I suggest that you use a better-behaved third party TFTP server
instead. 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) filesystems. 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 thin client uses the devfs Linux kernel capability
(as most now do), 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. Unfortunately I know of only one NFS server implementation for
Windows that supports symbolic links, and it is not free: Microsoft Windows Services For
UNIX (SFU), at a cost of approximately US$150. I don't know of any Windows
NFS servers that support block/character special files.
I therefore recommend that where possible you avoid NFS-based thin client
solutions (such as LTSP) if you must serve
them from a Windows platform. Use a self-booting solution (CDROM or flash disk)
or a solution that only requires TFTP (such as DIET-PC or Netstation) instead. If
you do want to use NFS, here's how to do it using Windows SFU 2.0:
- 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 2.0. 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. Do not install SFU to a directory that contains a space in
the pathname (such as C:\Program Files\SFU) or it will not work!
- Select Services for UNIX Administration from the menu. Select
Server for NFS and then the User Mapping tab. Enter "localhost"
in the text box.
- Select User Name Mapping, and then the Configuration tab.
Click the PCNFS radio button, and enter the local pathnames of the
passwd and group files your transferred earlier, e.g.
c:\ltsroot\etc\passwd etc. Don't be alarmed by the term "PCNFS", it
really just means flat files, as opposed to NIS. Now click Apply (at
top right).
-
Select the Maps tab, and click the Advanced maps radio
button. 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/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, and then add an
explicit Root permission 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.
- Before copying files from your development platform, check and correct
permissions on the files you are about to copy. SFU 2.0 NFS server doesn't
interpret some permission combinations properly, because of the way it maps
permissions onto NTFS. SFU approximately equates the implicit NTFS owner with
the UNIX "user" permission set, explicit group permissions (not including the
Everyone group) with the "group" permission set, and explicit
Everyone permissions with the "other" permission set. In some cases SFU
uses explicit denials to ensure no access, which has some odd side effects
because the denials take precedence over the allows, e.g. 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.
- 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 -).
Windows Services for UNIX 3.0 is now available. Microsoft claims to have made
significant improvements to the NFS server in 3.0, particularly with regard to
performance and UNIX-to-NTFS permission mapping. I have not used SFU 3.0 and do
not know whether the above instructions are still applicable to this version, or
how many of the 2.0 limitations still exist.