Hi Dave,
It occurred to me, I've got another follow-up question:
Below you propose the following file layout, however, will there be
changes to the required DHCP data? For example, I believe we currently
only provide a BootFile for SPARC like:
"http://172.20.24.78:5555/cgi-bin/wanboot-cgi";.
So, how do we proceed to set up a service to be served to a client? Am I
missing anything other than, a create-client type setup (provide the AI
server the MAC address and create a <client id> file), a network
deliniation, or will those remain the sole discrimination methods of
wanboot? If so, presumably <file> is a fixed file name (if I understand
the Image Management Proposal correctly, system.conf)?
Thank you,
Clay
The prototype searches for wanboot.conf in the order:
NB_NETBOOT_ROOT/<network>/<client id>/<file>
NB_NETBOOT_ROOT/<client id>/<file>
NB_NETBOOT_ROOT/<network>/<file>
NB_NETBOOT_ROOT/<file>
(NB_NETBOOT_ROOT = /etc/netboot)
The existing code omits the second search above.
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.
Why would we supply RootPath? All we need is BootFile.
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).
Client-specific ptions outside of BootFile and BootSrvA (in the x86 case)
shouldn't be necessary, so I'm not sure what the complement of DHCP options
you're referring to above would be. Can you please be specific?
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.
I believe that the changes we are making in the image management project
allow us to resolve this problem, as clients will only get AI-specific
options from a client macro. Can you provide an example of what you're
concerned about?
* 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.
The wanbootfs is deliverable prior to loading/mounting anything beyond the
root archive.
* 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)?
Automatic refreshing the service by tools that change such a configuration
seems like an answer, though it's not clear why that would be necessary.
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?
The DHCP server already has controls for confining it to specific interfaces,
as does Apache (at least indirectly via Listen addresses). in.tftpd is
controllable via the bind_addr property on the service. Or you can use
IPfilter or tcp wrappers to cover all of them at a lower level with a common
mechanism and single configuration form. That seems a bit better.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
