Hi Dave,
Thank you for your comments. They've given me some material to
contemplate! My comments below.
Thank you,
Clay
On Thu, 1 Apr 2010, Dave Miner wrote:
7115 - Custom wanboot.conf files are ignored in AI servers with multiple
NIC cards
The primary problem in 7115 (making client-specific configuration independent
of the network it's attached to) is being addressed in the image management
work. I have a modified wanboot-cgi that implements it which you should
probably use in your work.
Can you explain the operation of wanboot.cgi after this fix? I don't see
any plan of design in bug 7115 to give an idea how wanboot would be
modified. I cited this bug as it struck me as referencing the subnet
locating behavior of wanboot.cgi of which some may be unfamiliar. But, I'm
happy to not have to fix it. ;)
Areas of impact:
---------------
* DHCP
Unable to automatically determine the router for an
arbitrary interface for initial DHCP setup (i.e. installadm -i and
-c options will be unsupported on a multihomed system):
SPARC:
Will provide an AI macro for each subnet
with differentiated BootFile location to provide the
correct IP for that subnet.
X86:
Will provide an AI macro for each service with a BootFile
location, however, it will be desired that an
administrator configure the BootSvrA location on a
per-subnet basis (i.e. in the network macro or some other
macro which is included for the clients' use)
(We will provide a template of Solaris DHCP commands as we do now,
however, IP addresses will need to be filled in by the admin as
it doesn't makes sense for us to become a multi-subnet DHCP
manager)
This seems to fall short of your first requirement ("must be automatic"). I'm
not clear why we'd fill in the correct IP in the SPARC case and not x86,
though.
My apologies for the ambiguity here; I think we'd be able to provide the
same material in each architecture's case. We would not to my knowledge be
able to provide the router generally in a multihomed environment,
however, to set up the DHCP server as we do now for a single-homed system.
For SPARC:
We could provide subnet specific macro with a RootPath entry
pointing to the machine's correct IP for that subnet, which a DHCP
administrator could reference in their network macro.
For X86:
We could provide subnet specific macros with a BootSvrA record correctly
point to the machine's correct IP for that subnet, which a DHCP
administrator could reference in their network macro.
However, for either architecture, we could not provide a client's full
compliment of DHCP options necessary (unless we want to require a
knowledgable name service -- one with MAC and IP addresses).
Also, as you're the DHCP dude, Ethan and I were talking and having
automatic macro creation may bring in bug 4566 "delete-client and service
should remove service specific data from DHCP table." as if we're creating
these macros automatically, we should likely remove them when we remove
support for an interface.
* GRUB
Will extend the install_media and install_svc_address fallback
mechanisms in slim_source's
usr/src/cmd/auto-install/svc/manifest-locator as delivered by GRUB
to flag for using dhcpinfo(1) instead to locate which machine
provided the boot server via DHCP and use that IP address.
Alternatives:
Ideas which were thrown out to resolve providing the correct
install_media and install_svc_address IPs:
a. One TFTP server per subnet so that each one gets proper GRUB
menus for the network and all menus are written for that
subnet only
(Requires providing a TFTP server such as TFTPy[2] which has a
configurable bind address)
b. One TFTP server for all possible bind addresses, as we
have now, but then require subnet specific BootFile DHCP
macros which reference explicit GRUB menus
(Requires an n*m duplication of GRUB menus where n is clients and
services and m is machine interfaces -- or a TFTP server to on
the fly generate the GRUB menus)
We are likely to replace the boot arguments implementation in
manifest-locator with one based on receiving these parameters as part of a
wanbootfs from the server on x86, though I haven't had time to prototype that
yet. How would that affect your thinking here (I suspect it then collapses
into the below)?
I don't see this being a big issue. However, we would have to design this
solution to be possible from the microroot and before we have loaded the
zlib's. Further, the same issue of having wanboot.cgi insert an
appropriate root_server would be necessary.
* Wanboot
Wanboot in its wanboot.conf provides a root_server value which has
an IP address in it. The best option would be to modify ON's
usr/src/common/net/wanboot/bootconf.c valid_root_server() function
to populate a variable substitution similar to GRUB's handling of
variables (e.g. kernel$ and $ISADIR) for providing a subnet
specific IP to clients.
There are choices here which don't have a clear winner:
1) We can do hop detection or some other metric to try and
return the closest interface to the client
2) We can simply return a subnet local interface if not
returning a default interface.
(Both of these proposals require wanboot.cgi to know what
interfaces are serving AI data which is talked about in
the UI section.)
---------
The cases, as an admin. sees them are:
1. They want install service to be on one subnet
2. They want install service to be on some subnets
3. They want install service to be on all subnets
All three use cases would be supportable under this proposal. I would like
to
by default do option 3 and then publish how to prune back (to achieve
option 1
or 2) as a blog entry or blueprint opposed to a full UI knob in installadm
due
I presume you meant to say "in the product documentation"...
Yes, product documentation would be a good place. It would also be
possible to implement a UI knob for this as a phase 2 follow to the
initial implementation.
to the likely rarity of necessity for the larger AI using population*.
*I see demanding multiple subnets to be towards the 20% of all AI users,
and especially demanding option 1 or 2 being in the 20% of that 20% (or
~5% of all AI users).
This proposal envisions multiple subnet management to be a server wide
issue
and not something at the service granularity.
UI Impact:
---------
By default, providing for use case option 3 (all subnets are configured at
create-service/create-client invocations) would cause little UI impact.
However, to allow one to achieve use cases 1 and 2 would have some SMF
impact.
The SMF service would need to provide a way for masking out or explicitly
adding in interfaces. This way an administrator can choose to ensure that a
particular interface will always be excluded from providing installs (or
exposing AI webserver data - such as manifests - on a particular
interface);
conversely, an administrator could set an SMF property to make the
interfaces
property group a set of interfaces to only provide service on excluding all
others ever configured on the system.
If the interfaces a machine provides change, through a svcadm refresh and
restart of the install-server service, the new interfaces could be brought
online and old ones pruned. (Further, if desired, a hook to NWAM's
interface
bring-up and tear-down events could automate this reconfiguration.) This
would
control which interfaces are provided on a by-server basis opposed to a
by-service basis.
Would it make more sense to advise use of IPfilter or tcp wrappers (or
possibly even provide configuration of such) rather than inventing an
AI-specific set of controls for this?
I'm not sure that we'd want to use tcp wrappers for this as it's a
configuration setting and not a security setting which I'd associate with
tcp wrappers. Also, for configuration, we need to determine what
interfaces we're configured for, which would require us to poll the tcp
wrappers configuration (and I'm not sure how we'd be refreshed)?
If we did use tcp wrappers, it seems it'd be a bit of a ball of wax. As
would it be expected that our mDNS, TFTP, HTTP and DHCP server would all
follow our settings or would the admin have to modify setting for each
individually on top of configuring their host.allow or host.deny?
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
