[oi-dev] Bug in smf_netstrategy ?
Peter Tribble
peter.tribble at gmail.com
Fri Nov 29 20:07:00 UTC 2013
On Fri, Nov 29, 2013 at 4:47 PM, Jim Klimov <jimklimov at cos.ru> wrote:
> The smf_netstrategy() routine by design bails out if executed in a
> local zone /lib/svc/share/smf_include.sh:
>
> # smf_netstrategy
> # -> (_INIT_NET_IF, _INIT_NET_STRATEGY)
> #
> # Sets _INIT_NET_IF to the name for the network-booted
> # interface if we are booting from the network. _INIT_NET_STRATEGY is
> # assigned the value of the current network configuration strategy.
> # Valid values for _INIT_NET_STRATEGY are "none", "dhcp", and "rarp".
> #
> # The network boot strategy for a zone is always "none".
> #
> smf_netstrategy () {
> if smf_is_nonglobalzone; then
> _INIT_NET_STRATEGY="none" export _INIT_NET_STRATEGY
> return 0
> fi
> ...
>
Note that this is about network *boot*. This is how networking gets
configured before the system is running, potentially before /usr
is even mounted, etc. In normal circumstances once you've got a
system booted, you hand over to something like nwam which
manages the whole process. Zones always start having a fully
functioning OS already in place, so quite a bit of the boot logic
can be skipped for them.
(I'm not saying that it works, just that that's how I understand
the logic.)
> As I poster earlier in the Wiki and on the list, this presents a
> problem for some auto-configuration of local zones which boot with
> DHCP and might get configuration parameters from DHCP options,
> such as the hostname and DNS config - but these paths in their
> SMF methods are cut off by checking with this routine.
>
And there's an example - DNS config is dynamic. If you disconnect
from one network and connect to another, then the config changes.
Even connected to the same network, it might change over time.
It's not just a one-time boot process.
> Can someone shed a some light on why this check is done so, and
> if it really needs to remain in place?
>
> In particular, it is possible to test if we are in a zone and
> test its IP stack type (shared or exclusive), and bail out of
> this test only in case of a shared-stack local zone. Is it an
> acceptable solutions, or are some things know/expected to break?
>
>
>
> My earlier posts on this matter:
>
> https://www.illumos.org/issues/2875
>
> http://openindiana.org/pipermail/openindiana-discuss/2012-June/008315.html
> http://openindiana.org/pipermail/openindiana-discuss/2012-June/008317.html
> http://openindiana.org/pipermail/openindiana-discuss/2012-June/008319.html
>
> http://wiki.openindiana.org/oi/Using+host-only+networking+
> to+get+from+build+zones+and+test+VMs+to+the+Internet
>
> Thanks,
> //Jim Klimov
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
>
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20131129/d6fa404d/attachment-0005.html>
More information about the oi-dev
mailing list