Ignite-UX Reference (March 2010, B3921-90005)

instl_bootd(1M) instl_bootd(1M)
client to which it is allocated. Once field 2 is set, the entry cannot be allocated to any
other client.
When instl_bootd receives a boot request, it searches instl_boottab for an IP address issued to the
client during a prior boot request. If the search is unsuccessful, instl_bootd searches for the IP
address with the oldest time stamp.
An IP address may be marked with a reserve keyword, which causes instl_bootd to allocate the
address to the client specified in field 2. Once a reserve address is allocated to a client, it cannot be
allocated to a different client unless instl_boottab is manually edited to change the reserved status.
Once an IP address is allocated to a client, instl_bootd updates fields 2 and 3 of instl_boottab. Field
2 identifies the client by its LAN card station address; field 3 indicates the date and time the allocation
occurred.
Since instl_boottab is modified after each boot request and response, the system administrator should move
the file to a temporary location while editing it, and then return it to its permanent location when done. All
boot requests are denied when the file is in its temporary location. The instl_boottab file is automatically
reread after modification.
Multiple instl_bootd processes may share a single instl_boottab file. Appropriate file locking and
retry mechanisms are implemented to ensure that this is possible. Even so, each process must have a
unique network port number (see the -P option).
Anonymous Itanium®-Based Clients
The instl_bootd daemon can support anonymous Itanium®-based clients; however, support is not
enabled by default. To enable support, you need to change the following line in /etc/inetd.conf:
bootps dgram udp wait root /usr/lbin/bootpd bootpd
to:
bootps dgram udp wait root /opt/ignite/lbin/instl_bootd instl_bootd
After modifying /etc/inetd.conf, execute the command inetd -c to force inetd to reread its
configuration file. If there are any running bootpd daemons, they should be killed at this time. Making
this change disables the bootpd daemon; the system will not be able to provide general bootp or DHCP
services. If disabling general bootp or DHCP services on a boot helper or Ignite-UX server causes a
problem for your environment, do not use this method. Note that instl_bootd does not support gen-
eral DHCP requests and should only be used for the initial boot request.
The Ignite-UX Administration Guide contains more information on alternative methods for allowing anony-
mous Itanium®-based client support with Ignite-UX.
International Code Set Support
Ignite-UX uses a variety of system commands to accomplish its functionality. Because the output of many
of these commands is parsed, Ignite-UX ensures that the POSIX locale is normally used by modifying envi-
ronment variables. Help text and some command output not parsed by Ignite-UX will be left in the user’s
specified locale.
WARNINGS
If several clients attempt to boot simultaneously and not enough IP addresses are listed in instl_boottab,
some clients may be denied boot services. From the client perspective, it will appear that the
instl_bootd services are not working. If this happens, check the syslogd(1M) logfile on the server to
verify this condition. Adding more IP addresses to instl_boottab may help avoid this situation.
DEPENDENCIES
HP 9000 systems not supporting BOOTP use rbootd(1M) to provide booting services. rbootd(1M) serves
older HP 9000 systems by translating boot packets into BOOTP and forwarding them to the
instl_bootd server.
If you use the /var/adm/inetd.sec file to restrict usage of the server, the instl_boots services
must allow the IP address 0.0.0.0 or clients will not be able to boot using this daemon.
3