Update services for non-global, exclusive-IP DHCP zone

Review Request #289 — Created Dec. 7, 2016 and updated

seeemef@mac.com
illumos-gate
2875, 7650, 8587, 8689, 8690, 8691
general

8691 net-routing-setup does a match for "current=enabled" against the ipv[46]-routing "persistent" field

net-routing-setup does a check to determine "Are we routing dynamically?", but the nawk prog prints field $2 (persistent=enabled|disabled) and tries to match "current=enabled".

2875 local zones should not enforce "smf_netstrategy==none" regardless of reality

Historical issue regarding ngz and netstrategy

7650 Update net-svc to work for an exclusive-IP, DHCP non-global zone

For a DHCP global zone, net-svc (svc:/network/service:default) creates/updates resolv.conf to incorporate DHCP DNSserv and DNSdmain parameter values and updates nsswitch.conf to ensure dns is set as an active database for hosts/ipnodes.

net-svc does nothing for an exclusive-IP, DHCP, non-global zone; but it could do easily the equivalent. Moreover, net-svc only tries once to fetch DNSserv and DNSdmain from dhcpagent (dhcpinfo), which generally works for a global zone. For fast-booting non-global zones, there needs to be a few seconds allowance.

8689 Update identity-node to work for an exclusive-IP, DHCP, non-global zone

For a DHCP global zone, identity-node (svc:/system/identity:node) will use DHCP Hostname if returned. As with 7650, identity-node does nothing for an exclusive-IP, DHCP, non-global zone; but it could do easily the equivalent. One particular difference is that the previously-existing, non-global zone fallback to uname -n after /etc/nodename must be preserved for DHCP-handling as well.

8690 Update net-routing-setup to work for an exclusive-IP, DHCP, non-global zone

For a DHCP global zone, net-routing-setup (svc:/network/routing-setup:default) will use DHCP Router if defined as a signal to disable routeadm/default-ipv4-routing. net-routing-setup does nothing for an exclusive-IP, DHCP, non-global zone; but it could do easily the same.

8587 svc:/network/routing/route:default usually is not needed nowadays

net-routing-setup uses defined "defrouters" as a signal to disable routing. Default, static routes from /etc/inet/static_routes should also be included in this signal. (net-routing-setup reads /etc/inet/static_routes as the last step in its handling, so this is not a major change to the script.)

Global zone

  • affirmed that DHCP Hostname was used if defined for DHCP address (as before)
  • affirmed that resolv.conf was created/revised and nsswitch.conf was revised for a DHCP address (as before)
  • affirmed that DHCP IPv4 address (with DHCP Router defined) resulted in disabled routeadm/default-ipv4-routing (as before)
  • affirmed that static IPv4 address with default, static route resulted in disabled routeadm/default-ipv4-routing (new)

Non-global zone

  • affirmed that first boot (no addresses) has routeadm/default-ipv4-routing enabled (as before)
  • after creating DHCP address and rebooting:
    1) affirmed that defined DHCP Router resulted in disabled routeadm/default-ipv4-routing (new)
    2) affirmed that DHCP Hostname was used if defined for DHCP address (new)
    3) affirmed that resolv.conf was created/revised and nsswitch.conf was revised (new)
  • For testing 8691: removed address and rebooted to see routeadm/default-ipv4-routing enabled. Added a debug statement to net-routing-setup to affirm the expected assignment: dynamic_routing="true".
Loading file attachments...

  • 0
  • 0
  • 0
  • 1
  • 1
Description From Last Updated
hans
  1. 
      
  2. usr/src/cmd/svc/shell/smf_include.sh (Diff revision 1)
     
     
     
     
     
     

    If you remove this there is no need to introduce smf_zone_netstrategy at all.

    1. Hans, that is an explicit and documented behavior of smf_netstrategy. The function is called is many more places, so it's unwise to change its explicit and documented behavior for this case's purpose with all other callers explicitly affected too.

  3. 
      
jelmd
  1. 
      
  2. usr/src/cmd/svc/milestone/net-svc (Diff revision 1)
     
     

    Is it really necessary to spawn a sub shell/fork+exec for such a simple thing?

    Because the system shell is now ksh93, IMHO {1..6} is a better choice than the seq call (even bash supports this to produce sequences).

    1. Ah ok, Jens. In my mind, /bin/sh was Bourne. Thank you kindly for the correction.

  3. usr/src/cmd/svc/milestone/net-svc (Diff revision 1)
     
     

    why explicitly /bin/sleep? Wouldn't be a simple sleep better, so that the shell is able to use its builtin if available and thus avoid fork storms?

    Also the test for < 6 is for my taste not really needed/kind of redundant (if something goes wrong, waiting an add. sec doesn't really hurt) ...

    1. Ah ok. In my mind, /bin/sh was Bourne. Thanks for the correction. I'll revise.

      Regarding the sleep, my taste is that leaving an extra second is redundant and remiss.

  4. usr/src/cmd/svc/shell/smf_include.sh (Diff revision 1)
     
     

    Why not export VAR=value? Would be less bloat, make the script more readable ...

    see also http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#export

    1. It's actually more reliable to copy/paste rather than refactor. The bloat is inconsequential, and actually it works against readability when you have varying styles in a library.

  5. usr/src/cmd/svc/shell/smf_include.sh (Diff revision 1)
     
     

    same as above

  6. 
      
seeemef@mac.com
seeemef@mac.com
seeemef@mac.com
seeemef@mac.com
seeemef@mac.com
seeemef@mac.com
ptribble
  1. Why introduce smf_netstrategy2?

    Please just fix smf_netstrategy.

    1. I don't think you can prove that no illumos user with some custom SMF service would be impacted by the redefinition of that public function. I can prove though that it would have broken identity-node if smf_netstrategy were redefined that way.

    2. This is deeply internal code, not only can I not see anyone doing so, but it would be unwise and fragile to depend on it.

      The current smf_netstrategy behaviour is plain wrong; it dates back to before exclusive-ip stacks were introduced.

      (I believe Oracle Solaris fixed this in both S10 and S11 so that smf_netstrategy returns valid answers for an exclusive-stack zone.)

  2. 
      
ptribble
  1. In net-routing-setup, you've added a check for static_routes.

    First - should the /etc/svc/volatile stuff have happened before that first check?

    Second - would it be easier to simply move the entire static_routes handling (both the /etc/svc/volatile movement and the actual setting of routes) from the end of the file to before the section with the netstat in it? That way you don't need to add the separate check for static_routes (and you can just rely on the netstat check to see if a default route has been added).

  2. 
      
seeemef@mac.com
Review request changed
Loading...