Commit e021c50c authored by David Hankins's avatar David Hankins
Browse files

README changes pursuant to rt15988.

parent 1d3bfb17
......@@ -85,14 +85,10 @@ you would type ``nroff -man common/dhcp-options.5 |more'', assuming
your current working directory is the top level directory of the ISC
DHCP Distribution.
If you do not have the nroff command, you can type ``more catpage''
where catpage is the filename of the catted man page. Catted man
pages names are the name of the manual page followed by ".cat"
followed by 5 or 8, as with unformatted manual pages.
Please note that until you install the manual pages, the pathnames of
files to which they refer will not be correct for your operating
system.
Please note that the pathnames of files to which our manpages refer
will not be correct for your operating system until after you iterate
'make install' (so if you're reading a manpage out of the source
directory, it may not have up-to-date information).
RELEASE STATUS
......@@ -142,10 +138,8 @@ information. On Digital Unix, type ``man pfilt''.
To build the DHCP Distribution, unpack the compressed tar file using
the tar utility and the gzip command - type something like:
zcat dhcp-3.1-HEAD.tar.gz |tar xvf -
On BSD/OS, you have to type gzcat, not zcat, and you may run into
similar problems on other operating systems.
gunzip dhcp-3.1-HEAD.tar.gz
tar xvf dhcp-3.1-HEAD.tar
CONFIGURING IT
......@@ -243,54 +237,18 @@ network interface. There are also two potential compilation/runtime
problems for Linux 2.1/2.2: the "SO_ATTACH_FILTER undeclared" problem
and the "protocol not configured" problem.
LINUX: SO_ATTACH_FILTER UNDECLARED
In addition, there is a minor issue that we will mention here because
this release is so close on the heels of the Linux 2.2 release: there
is a symlink in /usr/include that points at the linux asm headers. It
appears to be not uncommon that this link won't be updated correctly,
in which case you'll get the following error when you try to build:
lpf.c: In function `if_register_receive':
lpf.c:152: `SO_ATTACH_FILTER' undeclared (first use this function)
lpf.c:152: (Each undeclared identifier is reported only once
lpf.c:152: for each function it appears in.)
The line numbers may be different, of course. If you see this
header, your linux asm header link is probably bad, and you should
make sure it's pointing to correct linux source directory.
LINUX: PROTOCOL NOT CONFIGURED
One additional Linux 2.1/2.2 issue: if you get the following message,
it's because your kernel doesn't have the linux packetfilter or raw
packet socket configured:
If you get the following message, it's because your kernel doesn't
have the linux packetfilter or raw packet socket configured:
Make sure CONFIG_PACKET (Packet socket) and CONFIG_FILTER (Socket
Filtering) are enabled in your kernel configuration
If this happens, you need to configure your Linux kernel to support
Socket Filtering and the Packet socket. You can do this by typing
``make config'', ``make menuconfig'' or ``make xconfig'', and then
enabling the Packet socket and Socket Filtering options that you'll
see displayed on the menu or in the questionnaire. You can also edit
your linux kernel .config file directly: set CONFIG_FILTER=y and
CONFIG_PACKET=y. If you do this, make sure you run ``make oldconfig''
afterwards, so that the changes you've made are propogated to the
kernel header files. After you've reconfigured, you need to type
``make'' to build a new Linux kernel, and then install it in the
appropriate place (probably /linux). Make sure to save a copy of your
old /linux.
If the preceding paragraph made no sense to you, ask your Linux
vendor/guru for help - please don't ask us.
If you set CONFIG_PACKET=m or CONFIG_FILTER=m, then you must tell the
kernel module loader to load the appropriate modules. If this doesn't
make sense to you, don't use CONFIG_whatever=m - use CONFIG_whatever=y.
Don't ask for help with this on the DHCP mailing list - it's a Linux
kernel issue. This is probably not a problem with the most recent
Linux 2.2.x kernels.
Socket Filtering and the Packet socket, or to select a kernel provided
by your Linux distribution that has these enabled (virtually all modern
ones do by default).
LINUX: BROADCAST
......@@ -397,11 +355,8 @@ Apparently this works because of an interaction between SCO's support
for network classes and the weird netmask. The 10.* network is just a
dummy that can generally be assumed to be safe. Don't ask why this
works. Just try it. If it works for you, great. SCO has added
support for doing DHCP in a more sensible way, but I have not had the
time or cause to implement them. If you are interested in this, and
are able to hack your way out of a wet paper back without assistance,
we'd appreciate it if you'd give it a try, but don't expect too much
support from us (sorry!).
support for doing DHCP in a more sensible way, and it will appear in
a future feature release.
HP-UX
......@@ -504,34 +459,26 @@ for AIX would be welcome.
The Internet Systems Consortium DHCP server is developed and distributed
by ISC in the public trust, thanks to the generous donations of its
sponsors. ISC now also fofers commercial quality support contracts for
sponsors. ISC now also offers commercial quality support contracts for
ISC DHCP, more information about ISC Support Contracts can be found at
the following URL:
http://www.isc.org/ops/support/
http://www.isc.org/sw/support/
No donators, as yet, have asked for their dollars to be spent providing
free support to all who ask. Please understand that we may not respond
to support inquiries unless you have a support contract. ISC will
continue its practice of always responding to critical items that effect
the entire community.
Please understand that we may not respond to support inquiries unless
you have a support contract. ISC will continue its practice of always
responding to critical items that effect the entire community, and
responding to all other requests for support upon ISC's mailing lists
on a best-effort basis.
However, ISC DHCP has attracted a fairly sizable following on the
Internet, which means that there are a lot of knowledgable users who
may be able to help you if you get stuck. These people generally read
the dhcp-server@isc.org mailing list.
If you are going to use dhcpd, you should probably subscribe to the
dhcp-server or dhcp-announce mailing lists. If you will be using
dhclient, you should subscribe to the dhcp-client mailing list.
may be able to help you if you get stuck. These people generally
read the dhcp-users@isc.org mailing list. Be sure to provide as much
detail in your query as possible.
If you need help, you should ask on the dhcp-server or dhcp-client
mailing list - whichever is appropriate to your application. Support
requests for the ISC DHCP client should go to dhcp-client@isc.org.
Support requests for the DHCP server should go to dhcp-server@isc.org.
If you are having trouble with a combination of the client and server,
send the request to dhcp-server@isc.org. Please do not cross-post to
both lists under any circumstances.
If you are going to use ISC DHCP, you should probably subscribe to
the dhcp-users or dhcp-announce mailing lists.
WHERE TO SEND FEATURE REQUESTS: We like to hear your feedback. We may
not respond to it all the time, but we do read it. If ISC DHCP doesn't
......@@ -545,88 +492,34 @@ software, you are asking for help. Your bug report is helpful to us,
but fundamentally you are making a support request, so please use the
addresses described in the previous paragraphs. If you are _sure_ that
your problem is a bug, and not user error, or if your bug report
includes a patch, you can send it to dhcp-bugs@isc.org without
subscribing. This e-mail address goes into a bug tracking system, so
you don't need to check periodically to see if we still remember the
bug - if you haven't been notified that the bug has been closed, we
still consider it a bug, and still have it in the system.
includes a patch, you can send it to our ticketing system at
dhcp-bugs@isc.org. If you have not received a notice that the ticket
has been resolved, then we're still working on it.
PLEASE DO NOT REPORT BUGS IN OLD SOFTWARE RELEASES! Fetch the latest
release and see if the bug is still in that version of the software,
and if it's not, _then_ report it. It's okay to report bugs in the
latest patchlevel of a major version that's not the most recent major
version, though - for example, if you're running 3.0.2, you don't have
to upgrade to a 3.0.3rc (release candidate) or even a 3.1.x release
before you can report bugs.
PLEASE DO NOT REPORT BUGS IF YOU ARE RUNNING A VERSION OF THE ISC
DHCP DISTRIBUTION THAT YOU DIDN'T GET FROM THE ISC! Free operating
system distributions are notorious for including outdated versions of
software, and also versions of software that were not compiled on your
particular version of the operating system. These versions
frequently do not work. Getting a source distribution from the ISC
and installing it frequently *does* work. Please try this *before*
asking for help.
PLEASE READ THIS README FILE CAREFULLY BEFORE REPORTING BUGS,
PARTICULARLY THE SECTION BELOW ON WHAT TO INCLUDE IN A BUG REPORT OR
HELP REQUEST.
PLEASE DO NOT SEND REQUESTS FOR SUPPORT DIRECTLY TO THE ENGINEERS WHO
WORK ON THE ISC DHCP DISTRIBUTION! *PARTICULARLY*, DO NOT SEND MAIL
TO THE ENGINEERS BECAUSE YOU AREN'T SURE TO WHOM YOU SHOULD SEND MAIL
- if you aren't sure, *ask* on the dhcp-server@isc.org or
dhcp-client@isc.org mailing list.
The number of people using the DHCP Distribution is sufficiently large
that if we take interrupts every time any one of those people runs
into trouble, we will never get any more coding done. If you send a
support request directly to any ISC or Nominum engineer, we will
forward it to the mailing list, or possibly ignore it, depending on
how much stress we are under at the time.
Please do not Cc: us on mail you send to these lists - we read both
mailing lists, so this just means we get two copies!
If your question can only be answered by one of the engineers, send it
to the appropriate public mailing list anyway - we will answer it
there. When we have time.
Please do not think "Oh, I don't want to bother the whole mailing list
with this question." If you are too embarrassed to ask publically,
get a support contract.
If you are concerned about bothering everybody on the list, that's
great, but that's what the list is there for. When you send mail to
one of the engineers, you are taking resources away from everybody on
the mailing list *anyway* - they just don't know it.
We're not writing this because we don't respect you - we really do
want to help you, and we appreciate your bug reports and comments.
But please use the mechanisms we have in place to provide you with
help, because otherwise you are almost certainly depriving someone
else of our help.
PLEASE DO NOT CALL US ON THE PHONE FOR HELP! Answering the phone
takes a lot more of our time and attention than answering email. If
you do call us on the phone, we will tell you to send email to the
mailing list or buy a support contract, so please don't waste your
time or ours. If you have a support contract, please use the support
channel mentioned in the support contract - otherwise you probably
won't get timely support unless you happen to ask an interesting
question and we happen to have some time to kill, because we can't
tell you're a support customer if you send mail to the public mailing
lists.
and if it's not, _then_ report it. ISC release versions always have
three numbers, for example: 1.2.3. The 'major release' is 1 here,
the 'minor release' is 2, and the 'maintenance release' is 3. ISC
will accept bug reports against the most recent two major.minor
releases: for example, 1.0.0 and 0.9.0, but not 0.8.* or prior.
PLEASE take a moment to determine where the ISC DHCP distribution
that you're using came from. ISC DHCP is sometimes heavily modified
by integrators in various operating systems - it's not that we
feel that our software is perfect and incapable of having bugs, but
rather that it is very frustrating to find out after many days trying
to help someone that the sources you're looking at aren't what they're
running. When in doubt, please retrieve the source distribution from
ISC's web page and install it.
HOW TO REPORT BUGS OR REQUEST HELP
When you report bugs or ask for help, please provide us complete
information. A list of information we need follows. Please read it
carefully, and put all the information you can into your initial bug
report, so that we don't have to ask you any questions in order to
figure out your problem. If you need handholding support, please
consider contacting a commercial provider of the ISC DHCP
Distribution.
report. This will save us a great deal of time and more informative
bug reports are more likely to get handled more quickly overall.
1. The specific operating system name and version of the
machine on which the DHCP server or client is running.
......@@ -643,14 +536,16 @@ Distribution.
may be hard for you to figure it out, so don't go crazy
trying.
4. The specific version of the DHCP distribution you're
running, for example "2.0b1pl19", not "2.0".
running, as reported by dhcpd -t.
5. Please explain the problem carefully, thinking through what
you're saying to ensure that you don't assume we know
something about your situation that we don't know.
6. Include your dhcpd.conf and dhcpd.leases file if they're not
huge (if they are huge, we may need them anyway, but don't
send them until you're asked). Huge means more than 100
kilobytes each.
6. Include your dhcpd.conf and dhcpd.leases file as MIME attachments
if they're not over 100 kilobytes in size each. If they are
this large, please make them available to us eg via a hidden
http:// URL or FTP site. If you're not comfortable releasing
this information due to sensitive contents, you may encrypt
the file to our release signing key, available on our website.
7. Include a log of your server or client running until it
encounters the problem - for example, if you are having
trouble getting some client to get an address, restart the
......@@ -671,21 +566,6 @@ Distribution.
This assumes that it's the dhcp server you're debugging, and
that the core file is in dhcpd.core.
9. If you know that the problem is an actual bug, and you can
reproduce the bug, you can skip steps 6 through 8 and instead
capture a trace file using the -tf flag (see the man page for
details). If you do this, and there is anything in your
dhcp configuration that you are not willing to make public,
please send the trace file to dhcp-bugs@isc.org and NOT to
dhcp-server@isc.org, because the tracefile contains your entire
dhcp configuration.
PLEASE DO NOT send queries about non-isc clients to the dhcp-client
mailing list. If you're asking about them on an ISC mailing list,
it's probably because you're using the ISC DHCP server, so ask there.
If you are having problems with a client whose executable is called
dhcpcd, this is _not_ the ISC DHCP client, and we probably can't help
you with it.
Please see http://www.isc.org/sw/dhcp/ for details on how to subscribe
to the ISC DHCP mailing lists.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment