On 03/30/10 11:21 PM, [email protected] wrote:
Hi all,
I've been thinking over the approach to take for supporting a multihomed
AI server, as now, one faces the bugs below. Please let me know by
Wednesday April 7th, 2010 if you see any issues.
Thank you,
Clay
Problem:
--------
Today, the OpenSolaris Automated Installer makes many assumptions which
prevent widespread or simple use of a server running multihomed.
Bugs:
6182 - installadm tools doesn't support install servers which have
mutiple subnets
6922 - installadm create-service should have option to specify ip address
passed to dhcp config
7115 - Custom wanboot.conf files are ignored in AI servers with multiple
NIC cards
7148 - installadm should give correct dhcp macro for the subnet being
configured on the server
7149 - installadm should allow user to choose which subnets to use
Requirements:
-------------
There are a number of desires for multihomed support in the Automated
Installer, however, the requirements picked are based on perceived
technical capabilities and customer site needs:
* The solution must be automatic
* The solution must support one to all subnets served by the server
* The solution must not depend on routing between subnets (i.e. subnets
are otherwise isolated)
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):
I don't understand why this issue is specific for a multihomed server.
In general, either the DHCP server is explicitly configured with the
default router options to return, or it has to infer/guess them from the
kernel routing table on the DHCP server. In the former case, the
configuration would have to be per interface. Are you concerned about
the latter case?
On a single-homed server how do you infer/guess the router?
I can see using something functionally equivalent to
netstat -rn -f inet | grep UG
and looking at the gateway field, or
route get default
Such a technique can be extended to handle multiple interfaces. If the
DHCP server is configured with source-based routing (See the recent
putback to onnv - 4173841 Packet goes out with source IP address of
another interface) then the above becomes
netstat -rn -f inet | grep UG | grep $ifname
and looking at the gateway field, or
route get default -ifp $ifname
If it isn't configured to do source-based routing then you'd need to
resolve the gateway address (e.g., using the equivalent of route get) to
find the interface.
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)
Is there a use case where the system will not be statically configured
(but configured with DHCP) where the admin doesn't want to specify the
interface. In such a case wouldn't the admin just want to say "this MAC
address (or client ID)" and have that apply to all interfaces on the
DHCP server?
* mDNS
Will have a separate mDNS responder listening on each interface to
respond with the correct IP address to advertise for the AI
webserver and interface.
Possible solutions for this are to use the PyZeroConf[1] library
or writing a Python CTypes bridge to libdns_sd.so.
I think IPS will use pybonjour, thus it makes sense to look at it as well.
Erik
* 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.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
