On 03/07/12 10:33, Dave Miner wrote:
On 03/07/12 11:46, Ethan Quach wrote:
On 03/05/12 08:46, Dave Miner wrote:
On 03/05/12 04:44, Darren Kenny wrote:
On 03/03/2012 01:47, Ethan Quach wrote:
On 03/02/12 00:16, Darren Kenny wrote:
On 02/03/2012 06:58, Nirmal Agarwal wrote:
Hi Jesse, Darren
Thanks for the comments.
On 3/2/2012 1:06 AM, Jesse Butler wrote:
On Mar 1, 2012, at 12:47 PM, Darren Kenny wrote:
Hi Nirmal,
Some quick comments:
- The bug synopsis - could it be changed to be what the bug
really is, as
it reads now it suggests it *should* be FQDN, but the fix is
stripping
the domainname.
I agree. It took me a bit to sort out exactly what the bug was
here.
I will fix the bug synopsis.
Thanks.
- I'm not totally sure that we should be stripping the
domainname all the
time. Maybe if the hostname is not qualified in the
criteria, then we
should be stripping the value from the client. But I feel
that if the
criteria was set with a FQDN then it really should be used I
think.
e.g.
Criteria: hostname = mymachine
Should match: mymachine
mymachine.us
mymachine.us.oracle.com
While
Criteria: hostname = mymachine.us
Should match: mymachine.us
mymachine.us.oracle.com
and finally
Criteria: hostname = mymachine.us.oracle.com
Should match: mymachine.us.oracle.com
i.e. if the user specifies a specific value, we should try
to match
it as much as is feasible - more like what the 'host' or
'nslookup'
commands would do here.
What do other people think?
Initially, this was how we thought the bug could be fixed as well,
and I
don't recall the exact reasons why we decided not to do it this
way but
I think it was pretty much for simplicity, and knowing that if we
really
did needed to support domainname, that should just be its own
separate
criteria so that things are more predictable (as far as what gets
returned as the HOSTNAME for a booting install client) and easier for
the user to understand.
We control the client side so it really seemed like a pretty simple
solution for us to just dictate what gets returned. Why deal with
the
variability?
In addition, if/when we ever did support a domainname criteria, that
could actually be useful on its own to map a class of clients in the
same domain to a manifest.
Unfortunately the size of a domain is very much something that could
vary
by customer, even by department or floor within the same company,
possibly
even in the same building.
I would agree that supporting a domainname criteria would be an
alternative
solution, but until that exists, maybe we shouldn't cripple what we
do have
right now?
In the above scenario if I have criteria's for 3 manifest as
below :
Criteria for manifest 'm1' : hostname = mymachine
Criteria for manifest 'm2' : hostname = mymachine.us
Criteria for manifest 'm3' : hostname =
mymachine.us.oracle.com
client hostname is "mymachine.us.oracle" , we should try and match
the
longest string match. So applying the same in the example client
will
get manifest "m3" ?
Is my understanding correct ?
Yes, that would be my expectation.
What happens when there are multiple criteria associated with m1,
m2, or
m3? e.g.
Criteria for manifest 'm1' : hostname = mymachine
mem = 1024 - 8196
Criteria for manifest 'm2' : hostname = mymachine.us
Criteria for manifest 'm3' : hostname = mymachine.us.oracle.com
platform = i386
When more than one manifest matches, we currently go through a
process
of weighting the manifests that match based on which criteria matched
(and I *think* how many criteria matched.) For this case, would 'm1'
and 'm2' be completely ruled out in the first place because of the
longer FQHN match from 'm3' exists, or should 'm1' and 'm2' still in
contention? What if 'm3's other criteria didn't match?
If the name we got from the client was the FQHN, then I think that m3
would
be the only match here - but that will depend on how we implement it.
If we do support weighting, then we could weight the hostname match
depending on the level of match - i.e. FQHN best match, x.us, next
best,
and x the weakest...
I'm definitely not in favor of the fix sent for review, stripping
names is not a good idea as it can lead to incorrect results in
highly-centralized infrastructures that happen to have duplicate
hostnames across different domains. As a result, using
fully-qualified names really should be preferred.
I'm somewhat unconvinced we should do anything at all here. The user
should know what hostname is being supplied to clients, whether it's
the fully-qualified or not, and configure appropriately. What is
wrong with that?
That's pretty much what we're currently telling users they must do,
which I also think could be fine. But I think the bug is more about the
convenience in usage for cases when they don't know upfront if the
client will return a fully-qualified hostname or not, which actually
might become more common when non-admin users have access to set up
profiles/manifests on the server.
To me, part of the issue was that we never precisely defined what the
hostname criteria yields, and the fact that it sometimes returned a fqhn
was a surprise, even to us. So the intent of the fix was to tighten
that up on the client side so that we can document it and users know
exactly what to expect when they use it. E.g. Jumpstart had a pretty
clear definition for it:
http://docs.oracle.com/cd/E18752_01/html/821-1911/jumpstartreference-6.html#indexterm-247
The use case mentioned above (different domain, same hostname) will
indeed require something more if hostname were the preferred criteria
mechanism. The suggestion of having a separate criteria for domain
would be one option, but I agree that properly implementing and defining
the hostname criteria as a fqhn would be another.
I preferred the former because it seemed straight forward, more easily
definable, and had the benefit of a domain criteria that could be
separately usable.
I think it's unnecessary to conflate the possibility of a domainname
criterion to how we define hostname. NIS/NIS+/LDAP domain names are
often completely orthogonal to DNS domains.
OK. I was thinking that a domainname criterion might obviate the need
to define the hostname as a fqhn at all, but that does not appear to be
the case when considering the different name services. (And yes I
agree, a domainname criterion could exist in addition to however we
treat hostname.)
The reference in the JumpStart docs really doesn't turn out to be any
more clear than the current behavior in AI; uname -n in cases where
DHCP was used could result in a hostname that is in fact the FQDN, it
all depends on what the server told it. The significant difference
with AI is that we're not using RARP and Bootparams so the hostname is
more likely to be a complete (as in FQDN) hostname, as opposed to a
partial nickname. That means the user needs to know what their
network is using, and that is something that we can't dictate.
Attempting to dictate non-FQDN names always for this criterion is
contrary to how the DNS namespace really works, and that's the
namespace that's important for hostnames, so I don't support making
them unusable.
OK, we'll approach the bugfix this way then.
-ethan
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
