This is the info I've either been told or figured out while playing around with a couple of Sun Ray DTUs at home. It's possible it might not be 100% accurate, or I may have failed to include some behind-the-scenes operations that are not normally seen by the end-user (me). Hopefully it will still be some help.
The following steps are performed as part of a Sun Ray DTU (desk top unit) boot-up:
- POST
- Firmware verify
- DHCP
- Connect to server
During the DHCP stage the DTU expects all of the regular information (IP address, netmask, gateway, etc.), but in addition to this it needs some vendor-specific information. The vendor-specific tags tell the DTU which IP address to contact to check for new firmware, where the Sun Ray services are running, and which host to use for logging.
On Solaris, the standard utadm, dhcpconfig and dhtadm commands are used to manage the DHCP service. However, if you're trying to do interesting things without Solaris you'll quickly hit problems as it is very unlikely your DHCP server will understand the Sun Ray-specific options.
Linux systems often use the ISC dhcpd, which can be taught about these tags by adding the following to your dhcpd.conf file (from the standard Linux sample dhcpd.conf):
option space SunRay;
option SunRay.AuthSrvr code 21 = ip-address;
option SunRay.AuthSrvr IPADDRESSHERE;
option SunRay.FWSrvr code 31 = ip-address;
option SunRay.FWSrvr IPADDRESSHERE;
option SunRay.NewTVer code 23 = text;
option SunRay.NewTVer "3.0_51,REV=2004.11.10.16.18";
option SunRay.Intf code 33 = text;
option SunRay.Intf "INTERFACENAMEHERE";
option SunRay.LogHost code 24 = ip-address;
option SunRay.LogHost 192.168.1.101;
option SunRay.LogKern code 25 = integer 8;
option SunRay.LogKern 6;
option SunRay.LogNet code 26 = integer 8;
option SunRay.LogNet 6;
option SunRay.LogUSB code 27 = integer 8;
option SunRay.LogUSB 6;
option SunRay.LogVid code 28 = integer 8;
option SunRay.LogVid 6;
option SunRay.LogAppl code 29 = integer 8;
option SunRay.LogAppl 6;
Replace IPADDRESSHERE with the valid IPs of your authentication and firmware servers. INTERFACENAMEHERE should be set to the name of the interface DHCP requests are being accepted on (e.g. eth1). By default these options are not handed out to all clients. A group must be configured to use the specific options. e.g.
group {
vendor-option-space SunRay;
subnet 192.168.1.0 netmask 255.255.255.0 {
authoritative;
option routers 192.168.1.1;
range 192.168.1.50 192.168.1.100;
}
}
By using the above you gain full control over the information passed to your DTU. Using this it is very easy to allow a DTU to sit on a network well away from your Sun Ray and DHCP server... but wait, if simply allowing a DTU to contact a Sun Ray server on a different network is all you are looking to do, you can overload DHCP option 49: "X Window System Display Manager Option", RFC2132.
With ISC dhcpd this is configured by adding:
option x-display-manager IPADDRESSHERE(, IPADDRESSHERE, IPADDRESSHERE);
to the configuration file. Replace IPADDRESSHERE with the IP address of the Sun Ray server.
If, like me, you're using an embedded Linux device (e.g. Linksys WRT54g) to provide your DHCP, the chances are Dnsmasq is handling both DNS and DHCP for you. Add the following to your dnsmasq.conf to replicate the functionality just discussed:
dhcp-option=49,IPADDRESSHERE
If you want to know more, check out Configuring DHCP options 49 and 66 for Sun Ray use (used as a reference), this blog also covers configuring Windows DHCP server to provide option 49.
