tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: MVP for a DHCP server



>> None of this is to say that that's what you're saying, nor what you
>> mean.  But "we don't support this; even if it's what you want, we
>> think it isn't what you need" in the documentation is liable to come
>> across that way.
> Ah we finally get to what you need :)

Heh.  You don't know what I need - heck, *I* don't know what I need.
(Well, actually, at the moment, I don't need DHCP at all, since I'm not
doing anything calling for it.  More precisely, nobody, including me,
knows what I'll have a use case for tomorrow, or next week, or
whenever.)

> I'll quote what you said again.

>> PXE proper, no.  But (a) that was just one example of an
>> unconfigurable DHCP client and even with just PXE, (b) how would you
>> address different machines needing different kernels?

> You need to be able to identify which kernel to send to a PXE client
> to boot.

For that desire, yes.

You need some kind of machine identifier, something distinctive to the
machine; consider upthread (paragraph-length-line damage repaired
manually)

	Szenario 1: A piece of hardware configured as a desktop machine
	is going to become a kiosk machine.

This could easily call for a different kernel (possibly even a kernel
for a completely different OS).

> Vendor class identifier is sent by PXE clients - could that be keyed
> off to pick a kernel?

Maybe.  How machine-unique is it?  "Vendor class" sounds to me more
like "manufacturer" (or "set of manufacturers", actually) than
"machine-unique".  Consider the above use case, for which you want to
move one machine, potentially one of a set of more or less identical
machines, to a completely different configuration.

> Even if not, there could be a new PXE plugin to detect some magic in
> the VCI option, examine the hlen, hytpe and chaddr of the bootp
> message and add some options based on some config.

Examine hlen/htype/chaddr?  That sounds like "MAC address" with a
little bit of generality added, in which case, yes, that sounds like
what I'd want.

> I think that people are too fixated on static config == static
> address and that's really not the case.

Well, of the four cases ({static,dynamic} {config,address}), I can
easily see use cases for each, so, yeah, I'd agree with you.  Well,
depending on what "config" covers there.

> The absolute dream goal for me is that either the client OR the DNS
> server is the source of truth for hostname <-> ip address mapping.

I would expect the DNS server to be; that's DNS's major job.  But how
is that relevant?  I don't see hostnames as being important here; I
thought we were talking about machine<->config (especially networking
config) mapping.  Hostname can be part of config, but usually only a
relatively small part.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index