Hi Dave,
Thank you for continuing to discuss these ideas with me, my
questions in-line.
Thank you,
Clay
[snip...]
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.
I see this as not changing my logic as create-service would simply stash
the per-service and per-client wanboot.conf files in:
NB_NETBOOT_ROOT/<file> or NB_NETBOOT_ROOT/<client id>/<file>.
Unfortunately, this flattens the hierarchy a bit which I think runs
counter to the desires of the Image Management proposal? Perhaps there's a
way to reconcile this?
[snip...]
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.
I'd be happy to simply supply BootFile but RootPath is what's currently
necessary in the wanboot.conf to my understanding. If we can supply
simply BootFile and have no reference to an IP address that'd be ideal.
However, how would we specify the port for the wanboot webserver? (Is
there a documentation reference I should be looking at? I haven't found
anything appropriate yet.)
[snip...]
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?
I was thinking of DNSserv, DNSdmain, and router, not AI specific options.
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?
I'm concerned with the per-subnet BootSvrA record which we would want to
generate and remove as interfaces are added and removed. Not necessarily
client specific though as 4566 was.
[snip...]
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.
Cool, then this should work well.
[snip...]
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.
I think this would be necessary for proper mDNS broadcasting and DHCP
macro availability.
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.
Interesting on this, I think for limiting the DHCP, tftpd and Apache
services tcpwrappers might work well then. I would still see mDNS as
needing to query for what it advertises though.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
