Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Network Configuration Tasks
The addition of directly-connected and remote shared subnet support in Sun Ray Server Software 2.0 allows DTUs to be deployed virtually anywhere on the enterprise intranet, subject only to the provision of DHCP service and a sufficient quality of service between the DTU and the Sun Ray server.
The following sections explain how to configure a network to support these deployment scenarios:
a directly-connected dedicated interconnect
a directly-connected shared subnet
a remote shared subnet
FIGURE 2 shows the overall topology and the configuration tasks discussed in this section.4
)
FIGURE 2 Sun
Ray Network Topology
Preparing for Deployment
Before deploying a DTU onto any subnet, the administrator must answer three questions:
From which DHCP server will DTUs on this subnet get their basic IP networking parameters?
From which DHCP server will DTUs on this subnet get additional configuration parameters to support features such as firmware download?
How will DTUs on this subnet locate their Sun Ray server?
The answers to these questions determine what configuration steps will let DTUs placed on this subnet initialize themselves and offer Sun Ray sessions to users.
The following sections present examples of DTU deployment on the directly-connected dedicated interconnect A, the directly-connected shared subnet B, and the remote shared subnets C and D shown in FIGURE 2.
Deployment on a Directly-Connected Dedicated Interconnect
Subnet A in FIGURE 2 is a directly-connected dedicated interconnect. Its subnet will use IP addresses in the range 192.168.128.0/24. The Sun Ray server named helios is attached to the interconnect through its qfe2 network interface, which will be assigned the IP address 192.168.128.3.
In an interconnect scenario, the DHCP service on the Sun Ray server always provides both basic networking parameters and additional configuration parameters to the DTU. The answers to the three pre-deployment questions are:
From which DHCP server will DTUs on this subnet get their basic IP networking parameters?
From which DHCP server will DTUs on this subnet get additional configuration parameters to support features such as firmware download?
How will DTUs on this subnet locate their Sun Ray server?
On a directly-connected dedicated interconnect, basic networking parameters are always supplied by the DHCP service on the Sun Ray server.
On a directly-connected dedicated interconnect, additional configuration parameters are always supplied by the DHCP service on the Sun Ray server.
On a directly-connected dedicated interconnect, the DTU is always notified of the location of the Sun Ray server through an additional configuration parameter supplied in Step 2.
Directly-Connected Dedicated Interconnect: Example
This is an example of DHCP service for the directly-connected dedicated interconnect A shown in FIGURE 2.
Configure the Sun Ray server to provide both basic and additional parameters to the interconnect.
Restart Sun Ray services on the Sun Ray server.
Use the utadm -a ifname command to configure DHCP service for DTUs on an interconnect. In this example, the interconnect is attached through interface qfe2, so the appropriate command is:
# /opt/SUNWut/sbin/utadm -a qfe2
### Configuring /etc/nsswitch.conf
### Configuring Service information for Sun Ray
### Disabling Routing
### configuring qfe2 interface at subnet 192.168.128.0
Selected values for interface "qfe2"
host address: 192.168.128.1
net mask: 255.255.255.0
net address: 192.168.128.0
host name: helios-qfe2
net name: SunRay-qfe2
first unit address: 192.168.128.16
last unit address: 192.168.128.240
auth server: 192.168.128.1
firmware server: 192.168.128.1
router: 192.168.128.1
alternate servers:
Accept as is? ([Y]/N): n
new host address: [192.168.128.1] 192.168.128.3
new netmask: [255.255.255.0]
new host name: [helios-qfe2]
Do you want to offer IP addresses for this interface? ([Y]/N):
new first Sun Ray address: [192.168.128.16]
number of Sun Ray addresses to allocate: [239]
new auth server: [192.168.128.3]
new firmware server: [192.168.128.3]
new router: [192.168.128.3]
Specify alternate server list? (Y/[N]):
Selected values for interface "qfe2"
host address: 192.168.128.3
net mask: 255.255.255.0
net address: 192.168.128.0
host name: helios-qfe2
net name: SunRay-qfe2
first unit address: 192.168.128.16
last unit address: 192.168.128.254
auth server: 192.168.128.3
firmware server: 1 192.168.128.3
router: 192.168.128.3
alternate servers:
Accept as is? ([Y]/N):
### successfully set up "/etc/hostname.qfe2" file
### successfully set up "/etc/inet/hosts" file
### successfully set up "/etc/inet/netmasks" file
### successfully set up "/etc/inet/networks" file
### finished install of "qfe2" interface
### Building network tables - this will take a few minutes
### Configuring firmware version for Sun Ray
All the units served by "helios" on the 192.168.128.0
network interface, running firmware other than version
"2.0_37.b,REV=2002.12.19.07.46" will be upgraded at their
next power-on.
### Configuring Sun Ray Logging Functions
DHCP is not currently running, should I start it? ([Y]/N):
### started DHCP daemon
#
In this example, the default values initially suggested by utadm were not appropriate. (Specifically, the suggested value for the server's IP address on the interconnect was not the desired value.) The administrator replied n to the first Accept as is? prompt and was given the opportunity to provide alternative values for the various parameters.
Once the utadm command has completed, issue a utrestart command to fully activate Sun Ray services on the newly-defined interconnect:
# /opt/SUNWut/sbin/utrestart Resetting servers... messages will be logged to /var/opt/SUNWut/log/ messages.
Deployment on a Directly-Connected Shared Subnet
Subnet B in FIGURE 2 is a directly-connected shared subnet that uses IP addresses in the range 130.146.59.0/24. The Sun Ray server helios is attached to the interconnect through its hme0 network interface, which has been assigned the IP address 130.146.59.5. The answers to the three pre-deployment questions are:
From which DHCP server will DTUs on this subnet get their basic IP networking parameters?
From which DHCP server will DTUs on this subnet get additional configuration parameters to support features such as firmware download?
How will DTUs on this subnet locate their Sun Ray server?
In a shared subnet scenario, you must choose whether a DHCP service on the Sun Ray server or some external DHCP service will provide the DTU with basic network parameters. If the enterprise already has a DHCP infrastructure that covers this subnet, it probably supplies basic network parameters. If no such infrastructure exists, configure the Sun Ray server to provide basic network parameters.
The administrator must choose whether to supply additional configuration parameters to the DTU and, if so, whether to use a DHCP service on the Sun Ray server or some external DHCP service for this purpose. On a directly connected shared subnet, it is possible to deploy DTUs without providing additional parameters at all, but since this deprives the DTU of a number of features, including the ability to download new firmware, it is generally undesirable.
Administrators of an already established DHCP infrastructure may be unable or unwilling to reconfigure that infrastructure to provide additional Sun Ray configuration parameters, so it is usually more convenient to have the Sun Ray server provide these parameters. Even when the established infrastructure is capable of delivering the additional parameters, it may be desirable to have the Sun Ray server provide them. This enables SRSS commands to be used to manage the values of the additional configuration parameters when those values need to be changed in response to software upgrades or patch installations on the Sun Ray server. For instance, a patch that delivers new DTU firmware could automatically update the firmware version string that is delivered to the DTU. However, if the firmware version parameter is supplied by some external DHCP service, an administrator must manually edit the firmware version parameter string in the external DHCP configuration rules to reflect the new firmware version delivered by the patch. This activity is time-consuming and error-prone, as well as unnecessary.
Use one of the optional additional configuration parameters to report the location of the Sun Ray server to the DTU. If additional configuration parameters are not supplied to the DTU at all, the DTU has no indication of the location of any Sun Ray server. In these circumstances, the DTU attempts to discover the location of a Sun Ray server by using a broadcast-based mechanism. However, the DTUs broadcast packets propagate only on the local subnet, so, in the case of a remote subnet, the broadcast cannot reach the Sun Ray server, and contact cannot be established.
The following examples illustrate two configurations of the directly connected shared subnet. In the first example, the Sun Ray server delivers both basic networking parameters and additional parameters. In the second example, an external DHCP service supplies basic networking parameters, and no additional parameters are provided to the DTU, which must establish contact with the Sun Ray server through its local subnet broadcast discovery mechanism.
The most likely case, where an external DHCP service provides basic networking parameter and the Sun Ray server provides additional parameters, is illustrated by an example in "Deployment on a Remote Subnet."
Directly-Connected Shared Subnet: Example 1
In this example, the answers to the three pre-deployment questions are:
From which DHCP server will DTUs on this subnet get their basic IP networking parameters?
From which DHCP server will DTUs on this subnet get additional configuration parameters to support features such as firmware download?
How will DTUs on this subnet locate their Sun Ray server?
From the Sun Ray server.
From the Sun Ray server.
The DTUs will be informed of the location of the Sun Ray server through an additional configuration parameter delivered in Step 2.
Configure the Sun Ray server to provide both basic and additional parameters to the shared subnet.
Restart Sun Ray services on the Sun Ray server.
DHCP service for DTUs on a shared subnet is configured through the utadm -A subnet command. In this example, the shared subnet has network number 130.146.59.0, so the appropriate command is utadm -A 130.146.59.0:
# /opt/SUNWut/sbin/utadm -A 130.146.59.0 Selected values for subnetwork "130.146.59.0" net mask: 255.255.255.0 no IP addresses offered auth server: 130.146.59.5 firmware server: 130.146.59.5 router: 130.146.59.1 alternate servers: Accept as is? ([Y]/N): n netmask: 255.255.255.0 (cannot be changed - system defined netmask) Do you want to offer IP addresses for this subnet? (Y/[N]): y new first Sun Ray address: [130.146.59.4] 130.146.59.200 number of Sun Ray addresses to allocate: [55] 20 new auth server: [130.146.59.5] new firmware server: [130.146.59.5] new router: [130.146.59.1] Specify alternate server list? (Y/[N]): Selected values for subnetwork "130.146.59.0" net mask: 255.255.255.0 first unit address: 130.146.59.200 last unit address: 130.146.59.219 auth server: 130.146.59.5 firmware server: 130.146.59.5 router: 130.146.59.1 alternate servers: Accept as is? ([Y]/N): ### Building network tables - this will take a few minutes ### Configuring firmware version for Sun Ray All the units served by "helios" on the 130.146.59.0 network interface, running firmware other than version "2.0_37.b,REV=2002.12.19.07.46" will be upgraded at their next power-on. ### Configuring Sun Ray Logging Functions ### stopped DHCP daemon ### started DHCP daemon #
The default values initially suggested by utadm were not appropriate. Specifically, this server would not have offered any IP addresses on the 130.146.59.0 subnet because utadm assumes that basic networking parameters, including IP addresses, are provided by some external DHCP service when the DTU is located on a shared subnet. In this example, however, the Sun Ray server is required to provide IP addresses, so the administrator replied n to the first Accept as is? prompt and was given the opportunity to provide alternative values for the various parameters. Twenty IP addresses, starting at 130.146.59.200, were made available for allocation to DHCP clients on this subnet.
Once the utadm command has completed, issue a utrestart command to fully activate Sun Ray services on the shared subnet:
# /opt/SUNWut/sbin/utrestart Resetting servers... messages will be logged to /var/opt/SUNWut/log/messages.
Directly-Connected Shared Subnet: Example 2
In this example, the answers to the three pre-deployment questions are:
From which DHCP server will DTUs on this subnet get their basic IP networking parameters?
How will DTUs on this subnet locate their Sun Ray server?
From an external DHCP service.
From which DHCP server will DTUs on this subnet get additional configuration parameters to support features such as firmware download?
The DTUs will not be supplied with additional parameters.
By using the local subnet broadcast discovery mechanism.
In this example, the Sun Ray server does not participate in DTU initialization at all. Why, then, are configuration steps required on the Sun Ray server? The Sun Ray server responds by default only to DTUs located on directly connected dedicated interconnects. It responds to DTUs on shared subnets only if the utadm -L on command has been executed. Running the utadm -A subnet command to activate DHCP on the Sun Ray server for a shared subnet, as in this example, implicitly executes utadm -L on. If utadm -A subnet has not been run, the administrator must run utadm -L on manually to allow the server to offer sessions to DTUs on the shared subnet.
Configure the external DHCP service.
If the external DHCP service does not have its own direct connection to this subnet, the administrator must configure a DHCP Relay Agent to deliver DHCP traffic on this subnet to the external DHCP service. The most likely location for such a Relay Agent would be on a router in this subnet, in this case the router named r22-59 in FIGURE 2. For a brief introduction to this topic refer to "DHCP Relay Agent" on page 4.
An existing external DHCP service may need to have its IP address allocation for this subnet increased in order to support the new DTUs. (This applies whenever additional DHCP clients are placed on a subnet.) It might also be desirable to reduce the lease time of addresses on this subnet so that addresses become eligible for reuse quickly.
Configure the Sun Ray server to accept DTU connections from shared subnets.
Restart Sun Ray services on the Sun Ray server.
Determining how to configure the external DHCP infrastructure to provide basic networking parameters to the DTUs on this subnet is beyond the scope of this document. Bear in mind:
Run utadm -L on:
# /opt/SUNWut/sbin/utadm -L on ### Turning on Sun Ray LAN connection NOTE: utrestart must be run before LAN connections will be allowed
Once the utadm command has completed, issue a utrestart command to fully activate Sun Ray services on the shared subnet:
# /opt/SUNWut/sbin/utrestart Resetting servers... messages will be logged to /var/opt/SUNWut/log/messages.
Deployment on a Remote Subnet
Subnets C and D in FIGURE 2 are remote shared subnets.
Subnet C uses IP addresses in the range 130.146.22.0/24. Subnet D uses IP addresses in the range 130.146.71.0/24. The Sun Ray server named helios has no direct attachment to either of these subnets; it is this characteristic that defines them as remote. The answers to the three pre-deployment questions are:
From which DHCP server will DTUs on this subnet get their basic IP networking parameters?
From which DHCP server will DTUs on this subnet get additional configuration parameters to support features such as firmware download?
How will DTUs on this subnet locate their Sun Ray server?
In a shared subnet scenario, the administrator must choose whether a DHCP service on the Sun Ray server or some external DHCP service will provide the DTU with basic network parameters.
If the enterprise already has a DHCP infrastructure that covers this subnet, it probably supplies basic network parameters. If no such infrastructure exists, configure the Sun Ray server to provide basic network parameters.
The administrator must choose whether additional configuration parameters will be supplied to the DTU, and if so whether they will be supplied by a DHCP service on the Sun Ray server or by some external DHCP service.
Administrators of an established DHCP infrastructure may be unable or unwilling to reconfigure it to provide additional Sun Ray configuration parameters, so it is usually more convenient to have the Sun Ray server provide them.
Even when the established infrastructure is capable of delivering the additional parameters, it may be desirable to have the Sun Ray server provide them. This enables you to use Sun Ray Server Software commands to manage the values of the additional configuration parameters, when those values need to be changed in response to software upgrades or patch installations on the Sun Ray server. For instance, a patch that delivers new DTU firmware could automatically update the firmware version string delivered to the DTU. However, if the firmware version parameter is supplied by some external DHCP service, an administrator must manually edit the firmware version parameter string in the external DHCP configuration rules to reflect the new firmware version delivered by the patch. This kind of activity is time-consuming and error-prone as well as unnecessary.
Use one of the optional additional configuration parameters to report the location of the Sun Ray server to the DTU. If additional configuration parameters are not supplied to the DTU at all, the DTU cannot locate a Sun Ray server, so it tries to discover the location of a Sun Ray server by using a broadcast-based mechanism. However, the DTUs broadcast packets propagate only on the local subnet; they cannot reach a Sun Ray server located on a remote subnet, and cannot establish contact.
The next two examples illustrate representative remote shared subnet configurations. In the first example, an external DHCP service provides basic networking parameters, and the Sun Ray server provides additional parameters. This is by far the most likely configuration for a Sun Ray deployment in an enterprise that has an established DHCP infrastructure.
In the second example, basic networking parameters and a bare minimum of additional parameters—just enough to enable the DTU to contact a Sun Ray server—are supplied by an external DHCP. In this case, it is the DHCP service in a Cisco router. This scenario is less than ideal.
No firmware parameters are delivered to the DTU, so it cannot download new firmware. The administrator must make some other arrangement to provide the DTU with new firmware, for instance, by rotating it off this subnet periodically onto an interconnect or onto some other shared subnet where a full set of additional configuration parameters is offered.
NOTE
For examples of shared subnet deployments in which both basic networking parameters and additional parameters are delivered by the Sun Ray server and basic networking parameters are supplied by an external DHCP service (with no additional DTU parameters provided), see "Directly-Connected Shared Subnet" on page 6.
Remote Shared Subnet: Example 1
In this example, in which DTUs are deployed on subnet C in FIGURE 2, the answers to the three pre-deployment questions are:
From which DHCP server will DTUs on this subnet get their basic IP networking parameters?
From which DHCP server will DTUs on this subnet get additional configuration parameters to support features such as firmware download?
How will DTUs on this subnet locate their Sun Ray server?
From an external DHCP service.
From the Sun Ray server.
The DTUs will be informed of the location of the Sun Ray server through an additional configuration parameter delivered in Step 2.
Use the utadm -A subnet command as follows to configure DHCP service for DTUs on a shared subnet.
Configure the External DHCP Service.
If the external DHCP service does not have its own direct connection to this subnet, the administrator must configure a DHCP Relay Agent to deliver DHCP traffic on this subnet to the external DHCP service. The most likely location for such a Relay Agent would be on a router in this subnet, in this case the router named r22-59 in FIGURE 2. For a brief introduction to this topic refer to "DHCP Relay Agent" on page 4.
An existing external DHCP service may need to have its IP address allocation increased for this subnet to support the new DTUs. (This applies whenever additional DHCP clients are placed on a subnet.) It might also be desirable to reduce the lease time of addresses on this subnet so that addresses become eligible for re-use quickly.
Arrange to Deliver DHCP Traffic to the Sun Ray Server.
The external DHCP service (so that the DTU can obtain basic networking parameters)
The DHCP service on the Sun Ray server (so that the DTU can obtain additional parameters)
Configure the Sun Ray server to provide additional parameters to the shared subnet.
Restart Sun Ray services on the Sun Ray server.
Determining how to configure the external DHCP infrastructure to provide basic networking parameters to the DTUs on this subnet is beyond the scope of this document. Bear in mind:
Because the Sun Ray server does not have its own direct connection to this subnet, the administrator must configure a DHCP Relay Agent to deliver the subnet's DHCP traffic to the Sun Ray server. The most likely location for such a Relay Agent would be on a router in this subnet, in this case the router named r22-59 in FIGURE 2. For a brief introduction to this topic refer to "DHCP Relay Agent" on page 4.
If r22-59 is running the Cisco IOS, the ip helper-address command can be used to activate its DHCP Relay Agent to relay DHCP broadcasts from its 10/100 Ethernet port number 4 to the Sun Ray server at 130.146.59.5.
r22-59> interface fastethernet 4 r22-59> ip helper-address 130.146.59.5 r22-59>
If the external DHCP service also lacks a connection to this subnet, configure a DHCP Relay Agent to forward requests from the DTU to:
The Cisco IOS ip helper-address command accepts multiple relay destination addresses, so if, for instance, the external DHCP service could be contacted at 130.146.59.2 on subnet B in FIGURE 2, the appropriate sequence would be:
r22-59> interface fastethernet 4 r22-59> ip helper-address 130.146.59.2 130.146.59.5 r22-59>
NOTE
Details of the IOS interaction vary according to the specific release of IOS, the model of the router, and the hardware installed in the router.
Use the utadm -A subnet command to configure DHCP service for DTUs on a shared subnet. In this example, the shared subnet has network number 130.146.22.0, so the appropriate command is utadm -A 130.146.22.0.
# /opt/SUNWut/sbin/utadm -A 130.146.22.0 Selected values for subnetwork "130.146.22.0" net mask: 255.255.255.0 no IP addresses offered auth server: 130.146.59.5 firmware server: 130.146.59.5 router: 130.146.22.1 alternate servers: Accept as is? ([Y]/N): n new netmask:[255.255.255.0] Do you want to offer IP addresses for this subnet? (Y/[N]): new auth server:[130.146.59.5] new firmware server:[130.146.59.5] new router: [130.146.22.1] 130.146.22.6 Specify alternate server list? (Y/[N]): Selected values for subnetwork "130.146.59.0" net mask: 255.255.255.0 no IP addresses offered auth server: 130.146.59.5 firmware server: 130.146.59.5 router: 130.146.22.6 alternate servers: Accept as is? ([Y]/N): ### Building network tables - this will take a few minutes ### Configuring firmware version for Sun Ray All the units served by "helios" on the 130.146.22.0 network interface, running firmware other than version "2.0_37.b,REV=2002.12.19.07.46" will be upgraded at their next power-on. ### Configuring Sun Ray Logging Functions ### stopped DHCP daemon ### started DHCP daemon #
In this example, the default values initially suggested by utadm were not appropriate. Specifically, the default router address to be used by DTUs on this subnet was not correct because utadm guesses that the address of the default router for any shared subnet will have a host part equal to 1. This was a great guess for the directly-connected subnet B in FIGURE 2, but it is not correct for subnet C.
The appropriate router address for DTUs on this subnet is 130.146.22.6 (port 4 of router r22-59), so the administrator replied n to the first Accept as is? prompt and was given the opportunity to provide alternative values for the various parameters.
Once the utadm command has completed, issue a utrestart command to fully activate Sun Ray services on the shared subnet:
# /opt/SUNWut/sbin/utrestart Resetting servers... messages will be logged to /var/opt/SUNWut/log/messages.
Remote Shared Subnet: Example 2
In this example, deploying DTUs on subnet D in FIGURE 2, the answers to the three pre-deployment questions are:
From which DHCP server will DTUs on this subnet get their basic IP networking parameters?
From which DHCP server will DTUs on this subnet get additional configuration parameters to support features such as firmware download?
How will DTUs on this subnet locate their Sun Ray server?
From an external DHCP service.
The DTUs will not be supplied with the additional parameters required to support firmware download or to activate other advanced DTU features.
The external DHCP service will supply a single additional parameter to inform the DTU of the location of a Sun Ray server.
In this example, the Sun Ray server does not participate in DTU initialization at all. Why, then, are configuration steps required on the Sun Ray server? The Sun Ray server responds by default only to DTUs located on directly connected dedicated interconnects. It responds to DTUs on shared subnets only if the utadm -L on command has been executed. Running the utadm -A subnet command to activate DHCP on the Sun Ray server for a shared subnet, as in this example, implicitly executes utadm -L on. If utadm -A subnet has not been run, the administrator must run utadm -L on manually to allow the server to offer sessions to DTUs on the shared subnet.
Configure the External DHCP Service.
Configure the Sun Ray server to accept DTU connections from shared subnets by running utadm -L on.
Restart Sun Ray services on the Sun Ray server.
AltAuth and AuthSrvr indicate the IP addresses of Sun Ray servers. Addresses in the AltAuth list are tried in order until a connection is established. Current firmware ignores AuthSrvr if AltAuth is provided, but it is good practice always to specify AuthSrvr for the benefit of old (pre Sun Ray Server Software 1.3) firmware, which does not understand the AltAuth option. If neither of these options is supplied, the DTU tries to locate a Sun Ray server by sending broadcasts on the local subnet. If the DTU contains firmware at Sun Ray Server Software 2.0 patch level 114880-01 or greater, it resorts to trying to contact a Sun Ray server at the address supplied in the option of the X Window Display Manager if that option has been provided.
NewTVer and FWSrvr must both be provided in order for the DTU to attempt a firmware download. NewTVer contains the name of the firmware version that the DTU should use. If this name does not match the name of the firmware version that the DTU is actually running, the DTU tries to download the desired firmware from a TFTP server at the address given by FWSrvr.
LogHost must be specified in order for the DTU to report messages through the syslog protocol. Reporting thresholds for major DTU subsystems are controlled by the LogKern, LogNet, LogUSB, LogVid, and LogAppl options.
Determining how to configure the external DHCP infrastructure to provide basic networking parameters to the DTUs on this subnet is beyond the scope of this document. However, for this example, assume that DHCP service is provided by Cisco IOS-based router r22-71 in FIGURE 2, attached to the 130.146.71.0 subnet through its 10/100 Ethernet port 3. This router can be configured to provide basic networking parameters and the location of a Sun Ray server as follows:
r22-71> interface fastethernet 3 r22-71> ip dhcp excluded-address 130.146.71.1 130.146.71.15 r22-71> ip dhcp pool CLIENT r22-71/dhcp> import all r22-71/dhcp> network 130.146.71.0 255.255.255.0 r22-71/dhcp> default-router 130.146.71.4 r22-71/dhcp> option 49 ip 130.146.59.5 r22-71/dhcp> lease 0 2 r22-71/dhcp> ^Z r22-71>
NOTE
Details of the IOS interaction vary according to the specific release of IOS, the model of router and the hardware installed in the router.
DHCP option 49, the standard option of the X Window Display Manager, identifies 130.146.59.5 as the address of a Sun Ray server. In the absence of AltAuth and Auth-Srvr vendor-specific options, the DTU tries to find a Sun Ray server by broadcasting on the local subnet. If the broadcasts evoke no response, the DTU uses the address supplied in t option of the X Window Display Manager—provided that the DTU contains firmware at Sun Ray Server Software 2.0 patch level 114880-01 or greater.
NOTE
This is an unorthodox use of the option of the X Window Display Manager, but in a remote subnet deployment where vendor-specific options can not be delivered, it may be the only way of putting a DTU in touch with a server.
# /opt/SUNWut/sbin/utadm -L on ### Turning on Sun Ray LAN connection NOTE: utrestart must be run before LAN connections will be allowed #
Once the utadm command has completed, issue a utrestart command to fully activate Sun Ray services on the shared subnet:
# /opt/SUNWut/sbin/utrestart Resetting servers... messages will be logged to /var/opt/SUNWut/log/ messages. #
TABLE 2 lists the vendor-specific DHCP options that Sun Ray defines and uses.
TABLE 2 Vendor-specific DHCP Options
|
Parameter Name |
Client Class |
Option Code |
Data Type |
Optional/ Mandatory |
Granularity |
Max Count |
Comments |
|
AltAuth |
SUNW.NewT.SUNW |
35 |
IP |
Optional |
1 |
0 |
List of Sun Ray server IP addresses |
|
AuthSrvr |
SUNW.NewT.SUNW |
21 |
IP |
Mandatory |
1 |
1 |
Single Sun Ray server IP addresses |
|
AuthPort |
SUNW.NewT.SUNW |
22 |
NUMBER |
Optional |
2 |
1 |
Sun Ray server port |
|
NewTVer |
SUNW.NewT.SUNW |
23 |
ASCII |
Optional |
1 |
0 |
Desired firmware version |
|
FWSrvr |
SUNW.NewT.SUNW |
31 |
IP |
Optional |
1 |
1 |
Firmware TFTP server IP address |
|
BarrierLevel |
SUNW.NewT.SUNW |
36 |
NUMBER |
Mandatory |
4 |
1 |
Firmware Download: barrier level |
|
LogHost |
SUNW.NewT.SUNW |
24 |
IP |
Optional |
1 |
1 |
Syslog server IP address |
|
LogKern |
SUNW.NewT.SUNW |
25 |
NUMBER |
Optional |
1 |
1 |
Log level for kernel |
|
LogNet |
SUNW.NewT.SUNW |
26 |
NUMBER |
Optional |
1 |
1 |
Log level for network |
|
LogUSB |
SUNW.NewT.SUNW |
27 |
NUMBER |
Optional |
1 |
1 |
Log level for USB |
|
LogVid |
SUNW.NewT.SUNW |
28 |
NUMBER |
Optional |
1 |
1 |
Log level for video |
|
LogAppl |
SUNW.NewT.SUNW |
28 |
NUMBER |
Optional |
1 |
1 |
Sun Rat server interface name |
|
Intf |
SUNW.NewT.SUN |
29 |
ASCII |
Optional |
1 |
0 |
Sun Ray server interface name |
|
NewTBW |
|
30 |
NUMBER |
Optional |
4 |
1 |
Bandwidth cap |
|
NewTDispIndx |
SUNW.NewT.SUNW |
32 |
NUMBER |
Optional |
4 |
1 |
Obsolete. Do not use. |
|
NewTFlags |
SUNW.NewT.SUNW |
34 |
NUMBER |
Optional |
4 |
1 |
Obsolete. Do not use. |
The DTU can perform its basic functions even if none of these options are delivered during initialization, but some advanced DTU features do not become active unless certain options are delivered to the DTU. In particular:
NOTE
The message formats, contents, and thresholds are intended for use only by service personnel and are not documented intentionally.
The DHCP Client Class name for all Sun Ray vendor-specific options is SUNW.NewT.SUNW. The DTU cites this name in DHCP requests so that the server can respond with the appropriate set of vendor-specific options. This mechanism guarantees that the DTU is not given vendor options defined for some other type of equipment and that other equipment is not given options that are meaningful only to the DTU.