Darren Reed wrote:
Peter Memishian wrote:
> > We're adding new functionality and with that addition we should add
> some observability into what happens. Just because we haven't done
> this in the past doesn't mean we shouldn't do it now. My feelings on
> log messages being...inadequate...are from seeing how log messages
> and the information in them is regarded within Sun and that this view
> could limit people's access to and use of this information. Command
> line options that return information appear to be much better regarded.
> > I've never gone looking on Solaris to see what DHCP assigned
parameters
> I've been given in the past, but I have wanted to do this with
Windows (and
> not been able to find the information.) On other platforms, the DHCP
> agent/client software does log all the information received that it
applies
> to the local system (IP#, default router, DNS server(s)). I'll file
an RFE
> to at least put a stake in the ground to indicate that it is useful
- > 6460198.
Retrieving this information is what dhcpinfo(1) is all about. In fact,
on Solaris, the DHCP client does not set information like the DNS
servers;
that is all done through scripts using dhcpinfo.
And when dhcpinfo doesn't work because someone has taken the
DHCP server offline (temporarily)?
I see Jim has already responded attempting to dispel your apparent
misunderstanding of how dhcpinfo works. You might want to study the
architecture a bit.
Does dhcpinfo tell you today what your settings were yesterday
with a reboot or two inbetween?
No, but having it do so is not necessarily wise; see below.
When everything works, sure, you don't need to know what anything
was - it is when something isn't quite working right that extra info
is available.
I've sat in Sun offices where everything has been fine except for the
DHCP server and seen sales people come in and be unable to do
anything because their PC's can't configure when they plug in.
Not only that but because there is no record of what settings they
have been given in the past, there's no clue about what they could
be using "now" in order to keep working. In situations like these
I use snoop to start guessing what IP# I could be using, review
lastlog entries of systems I log into for some safer ideas but I'm
still up the creek when it comes to DNS/NIS information. Nothing
is wrong with the network except for the DHCP server. I've also
been in hotels where the same problem occurs.
In short, there are real world benefits to be gained by recording
this information. I can understand that people who've never been
"stranded" in situations like this may not understand this but
please don't dismiss this as "there's no need to log this stuff".
There most certainly is a very tangible operational benefit to it.
Do you always assume that the people who've been responsible for
maintaining a technology for years have never had to debug any of these
situations?
Having dhcpinfo provide access to stale offer data is an invitation for
mis-use of that data - just because you were offered an address last
week, yesterday, or even five minutes ago does not mean it is possible
for you to use that address safely *now* - that's why it's called DHCP,
not BOOTP. I'm not at all in favor of retaining that data in dhcpagent
based on these use cases.
The general problem you outline of unreliable service in a site is
surely something that needs to be solved, but not by users hacking
around and using random addresses they don't have rights to, because the
quality of service will spiral ever downward. For such sites, they're
better served by not running DHCP at all, and us providing Link-local
address support, along with ad-hoc service discovery. And guess what?
We actually have companion projects to NWAM which will be doing just that.
Dave
_______________________________________________
networking-discuss mailing list
[email protected]
