[OpenIndiana-discuss] DHCP auto-configuration for local zones and sysidcfg
Hello all,
I am trying to get automatic networking provisioning for local
zones working, ultimately in order to simplify rapid deployments
of testbeds and per-bug build environments.
In the process I found a few nits, and wondered if I am doing
something wrong or things are according to current design and
that can be revised, perhaps? So, here goes:
1) In the SMF framework, local zones can not use netstrategy=dhcp
by the definition in /lib/svc/share/smf_include.sh:
---
# 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
...
---
This does make sense for shared-IP zones, but for exclusive-IP
ones which can be DHCP clients indeed, this seems wrong (and
further on forbids configuration of DNS resolver (resolv.conf,
nsswitch.conf) from DHCP data via svc:/network/service:default
method script /lib/svc/method/net-svc.
Also, I did some limited testing:
* on SXCE the /sbin/netstrategy returns zfs none none
for both shared and exclusive-IP zones (all with static
IP configuration),
* on OI (oi_151a3) the exclusive-IP zone which is a DHCP
client does return zfs vnic127101 dhcp properly,
* while OI local zones with static IP config also return
zfs none none.
Is there any known rationale for the snippet above from
smf_netstrategy() - or can it be just removed? What are
the possible negative consequences if this check is dropped?
Is there a simple reliable way to check the zone's ip-type,
or why don't we trust /sbin/netstrategy output?
2) In /etc/sysidcfg templates we can set name_service to be
DNS, LDAP, NIS or NONE. Would it be inappropriate to define
a new type and set it to DHCP (and then fetch name-service
info from DHCP)?
3) Some networking clients might want the changes to their
DNS/nsswitch config files from a dynamic wizard, others
might not. The policy might even differ per-local zone.
For example, there is fear of scripts which might
corrupt manually crafted settings for files+dns+ldap
host lookups, etc.
So far I have not seen any configurable switch that would
*request* or *forbid* changes to the /etc/resolv.conf and
/etc/nsswitch.conf files using data from DHCP.
Does such a switch exist?
Is it reasonable to add one (if not)?
As an option, might it make sense to integrate this solution
(an SMF service to combine user-preferred and DHCP-dynamic
resolver options, which can then be enabled or disabled on
a particular zone)?
http://thestaticvoid.com/post/2011/01/11/persistent-search-domains-with-nwam-and-dhcp/
Thanks,
//Jim Klimov
PS: A draft Wiki page is cooking here so far:
http://wiki.illumos.org/display/~jimklimov/Using+host-only+networking+to+get+from+build+zones+and+test+VMs+to+the+Internet
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] DHCP auto-configuration for local zones and sysidcfg
2012-06-07 22:32, Jim Klimov написал:
Hello all,
I am trying to get automatic networking provisioning for local
zones working, ultimately in order to simplify rapid deployments
of testbeds and per-bug build environments.
In the process I found a few nits, and wondered if I am doing
something wrong or things are according to current design and
that can be revised, perhaps? So, here goes:
A few more:
4) If I pre-configure the local zone with /etc/sysidcfg
(created between installation and first boot), and use
network_interface=PRIMARY {dhcp protocol_ipv6=no}
then the interface is first attempting auto-revarp
configuration and sends out RARP packets (not served
by Sun DHCP) and then sends out DHCPREQUESTs as asked.
If I don't provide the /etc/sysidcfg file, RARP is
still attempted, times out and in.rdisc failure is
logged, then the wizard asks for static IP settings.
I wonder if it is possible to either tie in the RARP
replies to Sun DHCP server, or to have the new client
attempt DHCP by default - since it does use RARP?..
(perhaps with a smaller timeout than 300sec waiting
with explicitly requested DHCP setup).
5) Is it possible to make a hands-free installation
(without supplying a /etc/sysidcfg manually) perhaps
distributing all these settings via DHCP (in private
options and/or as an URL to fetch the file via HTTP
or TFTP) - *if* DHCP and/or the DNS resolution setup
would now be also requested by default? ;)
I am thinking towards Sun Ray DTU auto-configuration
with a mix of DHCP and DNS settings for predefined
names (i.e. sunray-server-config.yourdomain.com).
//Jim Klimov
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] DHCP auto-configuration for local zones and sysidcfg
It is nice talking to oneself, we make a smart and interesting couple ;) (I do hope some experts would add to this thread) Apparently, the quick fix in smf_netstrategy which just fully removes the special handling for local zones is a flawed approach. There are other scripts which seemingly expect local zones to have $_INIT_NET_STRATEGY==none so this is a case for more careful revision. In particular, with the workaround in place, it seems that the `zonename` or `uname -n` are no longer consulted to construct the /etc/nodename file (or provide the value on the fly if the file is absent/empty) to ultimately set the hostname, so the zone came up as unknown on at least one test... For details see /lib/svc/method/identity-node :) Adding some code to the dhcp case seems to help (only the first line was originally present): --- # For non-global zones, fall back to the `uname -n` value provided by the # kernel if /etc/nodename does not exist, as is expected on an initial boot. # smf_netstrategy case $_INIT_NET_STRATEGY in dhcp) hostname=`/sbin/dhcpinfo Hostname` if [ -z $hostname ]; then if smf_is_globalzone; then hostname=`/sbin/hostconfig -h -p bootparams` else hostname=`/sbin/zonename` fi fi ;; --- Use of uname -n as proposed by the script's comments seems pointless, but maybe that's because I'm testing after the name unknown has got assigned during zone startup: root@unknown:~# hostname unknown root@unknown:~# zonename build-ss12sun root@unknown:~# uname -n unknown An arguable bonus is to add these lines someplace there: [ ! -z $hostname -a ! -s /etc/nodename ] \ echo $hostname /etc/nodename /usr/bin/chmod 644 /etc/nodename If we discovered a $hostname and the /etc/nodename was empty or nonexistent, seed that file with the name we found. Q: Should this be done at all, and in the identity-node SMF method script in particular? On a side note, I found that `zonename -t` should return the ip-type (shared or exclusive) which can help me make a more educated guess crafting the workaround... Good night, //Jim Klimov ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
