Jack Schwartz wrote:
> Hi everyone.
>
> Last week discussion ensued about the need for the text-mode DDU to have
> a way of configuring the network, for the cases where the DDU needs to
> read a repo or otherwise fetch a driver. The system would be coming up
> with NWAM enabled, but if the net doesn't have DHCP the network still
> won't be reachable. In this case, a (guided but) manual configuration
> of the network is needed. The text-mode DDU would guide the user
> through this configuration.
>
> We agreed that there should be a "network setup" library which is shared
> between the installer and DDU, so that there is consistency in the
> network setup screens. I think implementation can be as two functions:
> one function is for querying whether the network is up; the other is to
> configure the network if it is not up. The DDU China team will need to
> know how to call these functions.
>
> The query function can take an argument of what to look for and return
> True or False depending on whether that argument is pingable. It would
> be up to the DDU to strip all but the system name from an ftp address or
> other URL, and pass that system name to the query function. If in the
> course of DDU use, multiple URLs are referenced (perhaps a repo first,
> then an ftp URL), multiple network queries can be made.
>
> boolean tm_query_net("URL") # The "tm" is text-mode
>
> The configuration function (assumed written in Python) would display
> screens to take configuration information (static IP, netmask, hostname,
> gateway). These configuration items would be read from the system
> dynamically using ifconfig, svcadm and other commands, and the screens
> would be initialized with their information. After info entry, the
> network would then be set up and tested. The function would throw an
> exception on error.
>
> tm_net_config()
>
> When the DDU needs to make a network query, it could call the query
> function first to verify the remote entity is reachable. If the network
> entity is not reachable, the configuration function would be called.
> The configuration function is a black box as far as its callers are
> concerned. If for some reason the installer needs arguments passed in
> or returned, the DDU can accommodate.
>
> Does this sound reasonable? Have I left anything out? I welcome
> comments, in particular from the Text-mode installer team and the DDU
> China team. Please respond by Weds lunchtime.
>
I think this is trying to over-verify. Whether a particular URL is
reachable is in many cases orthogonal to whether "networking" is
configured. All the networking configuration done on a client manages
to do is tell the system how to transmit IP packets to the local link or
a first-hop router; beyond that, it's at the mercy of the network and
the ultimate end-point. As such, all applications that are accessing
the network must be prepared to encounter failures to reach the
destination at any time, and must *not* assume that a failure to reach a
particular destination means that the entire network configuration is
invalid.
I would suggest there is a simple query here to test whether the network
is configured, and it's not at all dependent on a particular URL. The
specification of the configuration performed in tm_net_config() (not
clear that an exception is the only correct return here) needs to
include DNS, since URL's will normally include names that require IP
address resolution.
Dave
