Hi Glenn.
Thanks for your comments.
On 04/28/09 08:26, Glenn Lagasse wrote:
> Hey Jack,
>
> * Jack Schwartz (Jack.A.Schwartz at Sun.COM) wrote:
>
>> Hi everyone.
>>
>> I'm working on bug ID:
>> 8346 AI should work with NWAM
>>
>> At issue is the script which installadm create-service runs to check
>> network configuration of the system being set up. It purposely fails
>> installadm when NWAM is enabled.
>>
>> This is marked as a blocker because systems on which installadm
>> successfully worked previously now fail to run installadm. At least two
>> people have hit this regression. The fix I suggest below is simple, low
>> risk and high impact.
>>
>> 8346 is a direct result of 6252, which enforces that NWAM be turned
>> off. The reasoning behind this: part of NWAM's purpose is to grab an IP
>> address from an external source (DHCP) when it configures the network;
>> this address could change from boot to boot. The AI server should have
>> a consistent IP address so that the AI clients can find it.
>>
>> The fix appears to be incorrect and too strict, because the presence of
>> NWAM doesn't imply a non-static address. There are ways of configuring
>> NWAM which can force a static IP address, so disabling NWAM is
>> incorrect. Furthermore, if NWAM gets the address from DHCP, it
>> is possible to configure the DHCPserver to dish up the same address
>> repeatedly.
>>
>> As long as the system has a hostname which is mapped to an active,
>> non-loopback IP address, installadm should work. While the address
>> should be consistent and well known so the clients can find it, it
>> really doesn't matter if NWAM is running or not. (The additional checks
>> made for setting up the AI server as the DHCP server are orthogonal to
>> these checks.)
>>
>> Since the NWAM configuration on OpenSolaris out of the box won't work, I
>> propose to leave the NWAM checks in, but change them to warnings instead
>> of failures. Something like this:
>>
>> if svc:/network/physical:nwam is not disabled {
>> print "Warning: NWAM is not disabled. Please insure that the IP
>> address for `hostname` is static."
>> } else if svc:/network/physical:default is disabled {
>> print "Error: No networking SMF service is enabled."
>> valid = "False"
>> }
>>
>
> What about checking the /etc/nwam/llp file for the interface to see if
> it's set to dhcp or static? I realize that's not a real interface but
> unless NWAM has some other method for determining how the interface is
> configured I don't know what else you could check. This might be
> something we could ask the NWAM team for.
>
I gyrated on this last Friday before posting my solution. The reasons
why I decided not to go this route were:
1) As you say, /etc/nwam/llp is not a real interface. It is unstable,
and is expected to change this summer.
2) The issue isn't really about NWAM, not even "static IP addresses",
but about an IP address which is consistent across reboots. NWAM was
being used as a barometer that a consistent IP address was set up, but
was the wrong thing to check.
In the end, we cannot tell whether a system's IP address is consistent
on reboot or not. Suppose a system gets its IP address via DHCP. If
the DHCP server is set up to dish out the same IP address to the same
system, we're OK. If it isn't, the address won't be consistent. There
isn't an easy way to check this.
So, the best we can do is to validate that the /usr/bin/hostname maps to
an IP address. We can presume that if NWAM is enabled, the address is
not as likely to be static, but we don't know that (and as you point
out, it can be static). So we print a cautionary message to have the
user verify the static-status of the IP address, but allow installadm to
run.
The final code does a little more than the above. It now does more
complete checks: the other error cases are for no network and for both
network/physical SMF services being enabled (that is, being set up to be
allowed to run). These cases are more straightforward.
> The warning is ok as far as it goes, but for inexperienced admins I
> don't know that they'll have any idea what it means or is telling them
> to do.
>
> The other thing that this check doesn't take into account is you can
> have network/physical enabled but still be getting an address via DHCP.
> So what exactly is the purpose of this check? If it's to determine that
> the system has a 'static' address, I don't think we can ever fully
> verify that (as you said, you can configure a DHCP server to hand out
> static addresses which we have no way of verifying for starters). At
> which point, I think we're left with just making sure that 'networking'
> is up and then trust that they've read the docs and understand that a
> static address (in whatever form) is necessary.
>
Yup. That's basically what we're doing now with this change.
Thanks,
Jack
> Cheers,
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090428/7a50ba33/attachment.html>
