You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@ibm.net> on 2000/06/21 14:44:25 UTC
confused about new ServerName logic
I thought I understood what was going on, but I guess not... I'm
getting messages about needing ServerName even when gethostname() and
gethostbyname() work. (Also, I'm not crazy about the phrasing of the
messages, but probably nobody will like my changes :) )
Can somebody explain why the patch below isn't appropriate? It only
complains about no ServerName if we can't properly determine the
hostname. It doesn't complain if we *can* determine the hostname.
Thanks!
Index: src/main/util.c
===================================================================
RCS file: /cvs/apache/apache-2.0/src/main/util.c,v
retrieving revision 1.58
diff -u -r1.58 util.c
--- util.c 2000/06/20 19:30:32 1.58
+++ util.c 2000/06/21 12:41:41
@@ -1905,15 +1905,16 @@
}
}
- if (!server_hostname)
+ if (!server_hostname) {
server_hostname = ap_pstrdup(a, "127.0.0.1");
- ap_log_error(APLOG_MARK, APLOG_ALERT | APLOG_NOERRNO, 0,
- NULL, "%s: Missing ServerName directive in httpd.conf.",
- ap_server_argv0);
- ap_log_error(APLOG_MARK, APLOG_ALERT | APLOG_NOERRNO, 0,
- NULL, "%s: assumed ServerName of %s",
- ap_server_argv0, server_hostname);
+ ap_log_error(APLOG_MARK, APLOG_ALERT | APLOG_NOERRNO, 0,
+ NULL, "%s: A ServerName directive is missing from httpd.conf.",
+ ap_server_argv0);
+ ap_log_error(APLOG_MARK, APLOG_ALERT | APLOG_NOERRNO, 0,
+ NULL, "%s: ServerName has been set to %s.",
+ ap_server_argv0, server_hostname);
+ }
return server_hostname;
}
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: confused about new ServerName logic
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Jeff Trawick wrote:
>
> My current thought...
>
> I think it is fine to write a log message whenever we determine the
> server name. It should be informational (and only to the log) if
> for all we know it is a reasonable configuration; it should be an
> alert or error message (and to the terminal) if we use 127.0.0.1.
+1, except make it no more severe than a warning. Anything more
and we're basically claiming the server won't work right -- which
isn't correct. It's working right, just not in all the situations
the user probably expects. But maybe he *does* expect it, so
don't tell him he's done something wrong, just that we're making
a possibly-invalid assumption.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
RE: confused about new ServerName logic
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
I don't disagree, but let's tear apart the code in 1.3.13...
#ifdef BEOS /* BeOS returns zero as an error for gethostname */
if (gethostname(str, sizeof(str) - 1) == 0) {
#else
if (gethostname(str, sizeof(str) - 1) != 0) {
#endif /* BeOS */
ap_log_error(APLOG_MARK, APLOG_WARNING, NULL,
"%s: gethostname() failed to detemine ServerName\n",
ap_server_argv0);
server_hostname = ap_pstrdup(a, "127.0.0.1");
}
else
{
str[sizeof(str) - 1] = '\0';
if ((!(p = gethostbyname(str)))
|| (!(server_hostname = find_fqdn(a, p)))) {
/* Recovery - return the default servername by IP: */
// Right here we gracefully recover if there isn't a single 'undotted'
// name to be found. I would be equally happy accepting an 'undotted'
// name if we have one, but failing that... here's our 'real' IP string:
if (!str && p->h_addr_list[0]) {
ap_snprintf(str, sizeof(str), "%pA", p->h_addr_list[0]);
server_hostname = ap_pstrdup(a, str);
}
}
}
// Massive bummer... gethostname+gethostbyname got us nowhere at all.
// But this way we don't fail to start the server...
if (!server_hostname)
server_hostname = ap_pstrdup(a, "127.0.0.1");
// Here's the error... now we need the server_rec as an argument if anything
// is going to land in the log:
ap_log_error(APLOG_MARK, APLOG_ALERT|APLOG_NOERRNO, NULL,
"%s: Missing ServerName directive, assumed host name %s\n",
ap_server_argv0, server_hostname);
Somehow, some way they get a ServerName. Best if it's fully qualified.
Somewhat acceptable if we have an ip string. I suppose even a local,
undotted name would be preferable to a private ip address. But failing
all that, they get 127.0.0.1 - so...
On the logic level, what do you want to change? Add the server_rec and log
it in the right place? Forewarned... this happens pretty early, and there
may be no logs yet. There will be logs once (at least under Win32) the conf
is reparsed ín the child. Since it died before, rather than continuing, Win32
showed no log entries and the service wouldn't start.
Bill
> -----Original Message-----
> From: Jeff Trawick [mailto:trawick@ibm.net]
> Sent: Wednesday, June 21, 2000 9:17 PM
> To: new-httpd@apache.org
> Subject: Re: confused about new ServerName logic
>
>
> > From: "William A. Rowe, Jr." <wr...@lnd.com>
> > Date: Wed, 21 Jun 2000 14:50:54 -0500
> >
> > Accepted...
>
> Actually, I'm not happy with the original patch I posted. I don't
> like the way the code is in CVS now, but you convinced me to shift
> some towards your view.
>
> What I really don't like:
>
> error message on terminal for what I would consider a reasonable
> configuration (no ServerName, but gethostname(), gethostbyname(),
> and find_fqdn() all succeed)
>
> My current thought...
>
> I think it is fine to write a log message whenever we determine the
> server name. It should be informational (and only to the log) if
> for all we know it is a reasonable configuration; it should be an
> alert or error message (and to the terminal) if we use 127.0.0.1.
>
> > Recognize that the patch does not report the assumption of any
> > other numeric IP as the ServerName, which was the the original
> > reason my original patch was voted down.
>
> In what case do we assume a numeric IP other than 127.0.0.1?
>
> Thanks,
>
> Jeff
>
> --
> Jeff Trawick | trawick@ibm.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>
Re: confused about new ServerName logic
Posted by Jeff Trawick <tr...@ibm.net>.
> From: "William A. Rowe, Jr." <wr...@lnd.com>
> Date: Wed, 21 Jun 2000 14:50:54 -0500
>
> Accepted...
Actually, I'm not happy with the original patch I posted. I don't
like the way the code is in CVS now, but you convinced me to shift
some towards your view.
What I really don't like:
error message on terminal for what I would consider a reasonable
configuration (no ServerName, but gethostname(), gethostbyname(),
and find_fqdn() all succeed)
My current thought...
I think it is fine to write a log message whenever we determine the
server name. It should be informational (and only to the log) if
for all we know it is a reasonable configuration; it should be an
alert or error message (and to the terminal) if we use 127.0.0.1.
> Recognize that the patch does not report the assumption of any
> other numeric IP as the ServerName, which was the the original
> reason my original patch was voted down.
In what case do we assume a numeric IP other than 127.0.0.1?
Thanks,
Jeff
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
RE: confused about new ServerName logic
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
Accepted...
Apply your patch, limiting error messages to the assumption of
ServerName 127.0.0.1 only, and we will see where bugs.apache.org
sits in a few months before 2.0 rolls out the door.
Recognize that the patch does not report the assumption of any
other numeric IP as the ServerName, which was the the original
reason my original patch was voted down.
Bill
Re: confused about new ServerName logic
Posted by David Reid <dr...@jetnet.co.uk>.
I'm with Jeff on this one. Convince me otherwise.
david
> >
> > > > Your {} block is entirely wrong. You will only display
> > > messages if we
> > > > 'assume' a localhost ip? What about the fool with 15 dns
> > > aliases who
> > > > can't understand why their server responds with the name
> > > pigsfeet.ugh,
> > > > and can't seem to change it (no idea why...)
> > >
> > > I don't think it is so nice to issue an error message on the console
> > > for a situation we do not know to be in error and which has been
> > > happily accepted by Apache with no complaints for a long period of
> > > time. If we have to assume 127.0.0.1, yes that is a configuration
> > > almost definitely in error and it should be an error message on the
> > > console like you have it. If gethostname() and gethostbyname()
> > > worked, however, then I don't think we should complain so loudly. An
> > > info or warning message in the log should suffice. I would *guess*
> > > that there are great numbers of existing apache installations with no
> > > ServerName but a valid DNS setup and hence no problems.
> >
> > Ok... issue one, this patch was already accepted into 1.3.13, and 2.0
> > is a new beast, so we don't have to follow the 'it worked this way
> > before' arguments if we are improving the product. But on to the
> > Q...
>
> Strictly speaking, there is no 1.3.13, only 1.3.13-dev, so it is fair
> to say that it didn't work this way before.
>
> Perhaps I'm the only one that feels this way, but on several of my
> machines I have no ServerName and I see no reason to add it and I
> don't think I need an error message on the terminal that won't go away
> until I add it. I could accept it as an informational message in the
> log, but an error message tells me I need to go do something now, and
> I don't think that is appropriate in my case.
>
> What about an error message on the terminal if gethostname() fails or
> gethostbyname() fails or find_fqdn() fails, and either no message or
> an informational message in the log otherwise?
>
> > We document in httpd.conf that they should fill this in. Providing a
> > warning that they haven't isn't bad, IMHO.
>
> I don't interpret the prose in http.conf as saying that users "should"
> fill this in. The documentation of the ServerName directive and
> linked documentation on DNS issues is stronger, but I think it is
> mostly a description of the conditions in which you should set it.
>
> Have fun,
>
> --
> Jeff Trawick | trawick@ibm.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>
Re: confused about new ServerName logic
Posted by Jeff Trawick <tr...@ibm.net>.
> From: "William A. Rowe, Jr." <wr...@lnd.com>
> Date: Wed, 21 Jun 2000 13:16:57 -0500
>
> > > Your {} block is entirely wrong. You will only display
> > messages if we
> > > 'assume' a localhost ip? What about the fool with 15 dns
> > aliases who
> > > can't understand why their server responds with the name
> > pigsfeet.ugh,
> > > and can't seem to change it (no idea why...)
> >
> > I don't think it is so nice to issue an error message on the console
> > for a situation we do not know to be in error and which has been
> > happily accepted by Apache with no complaints for a long period of
> > time. If we have to assume 127.0.0.1, yes that is a configuration
> > almost definitely in error and it should be an error message on the
> > console like you have it. If gethostname() and gethostbyname()
> > worked, however, then I don't think we should complain so loudly. An
> > info or warning message in the log should suffice. I would *guess*
> > that there are great numbers of existing apache installations with no
> > ServerName but a valid DNS setup and hence no problems.
>
> Ok... issue one, this patch was already accepted into 1.3.13, and 2.0
> is a new beast, so we don't have to follow the 'it worked this way
> before' arguments if we are improving the product. But on to the
> Q...
Strictly speaking, there is no 1.3.13, only 1.3.13-dev, so it is fair
to say that it didn't work this way before.
Perhaps I'm the only one that feels this way, but on several of my
machines I have no ServerName and I see no reason to add it and I
don't think I need an error message on the terminal that won't go away
until I add it. I could accept it as an informational message in the
log, but an error message tells me I need to go do something now, and
I don't think that is appropriate in my case.
What about an error message on the terminal if gethostname() fails or
gethostbyname() fails or find_fqdn() fails, and either no message or
an informational message in the log otherwise?
> We document in httpd.conf that they should fill this in. Providing a
> warning that they haven't isn't bad, IMHO.
I don't interpret the prose in http.conf as saying that users "should"
fill this in. The documentation of the ServerName directive and
linked documentation on DNS issues is stronger, but I think it is
mostly a description of the conditions in which you should set it.
Have fun,
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
RE: confused about new ServerName logic
Posted by Charles Cutler <ch...@ruadh.com>.
this user has left, please remove from your lists
___________________________________________
Charles Cutler
Ruadh Ltd
Tel - 00 44 (0)1334 654300
charles@ruadh.com
http://www.ruadh.com
-----Original Message-----
From: William A. Rowe, Jr. [mailto:wrowe@lnd.com]
Sent: 21 June 2000 20:53
To: new-httpd@apache.org
Subject: RE: confused about new ServerName logic
> From: Rodent of Unusual Size [mailto:Ken.Coar@Golux.Com]
> Sent: Wednesday, June 21, 2000 2:47 PM
>
> If 1.3.13-dev is now spitting out an '[error]' message when
> successfully using an httpd.conf file that worked for 1.3.12,
> then I veto that behaviour change right now. I always set
> ServerName so I didn't notice this. An '[info]' message to
> the log only *might* be permissible.
I've accepted Jeff's patch, so no messages except for 127.0.0.1
RE: confused about new ServerName logic
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Rodent of Unusual Size [mailto:Ken.Coar@Golux.Com]
> Sent: Wednesday, June 21, 2000 2:47 PM
>
> If 1.3.13-dev is now spitting out an '[error]' message when
> successfully using an httpd.conf file that worked for 1.3.12,
> then I veto that behaviour change right now. I always set
> ServerName so I didn't notice this. An '[info]' message to
> the log only *might* be permissible.
I've accepted Jeff's patch, so no messages except for 127.0.0.1
Re: confused about new ServerName logic
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"William A. Rowe, Jr." wrote:
>
> > I don't think it is so nice to issue an error message on the console
> > for a situation we do not know to be in error and which has been
> > happily accepted by Apache with no complaints for a long period of
> > time.
>
> Ok... issue one, this patch was already accepted into 1.3.13, and 2.0
> is a new beast, so we don't have to follow the 'it worked this way
> before' arguments if we are improving the product. But on to the Q...
If 1.3.13-dev is now spitting out an '[error]' message when
successfully using an httpd.conf file that worked for 1.3.12,
then I veto that behaviour change right now. I always set
ServerName so I didn't notice this. An '[info]' message to
the log only *might* be permissible.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
RE: confused about new ServerName logic
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Jeff Trawick [mailto:trawick@ibm.net]
> Sent: Wednesday, June 21, 2000 11:53 AM
>
> I thought the existing text was awkward and suggested a new one
The first message certainly can use massaging, yea. The second
one as well, as long as we don't imply we 'set' something that
was never really changed in httpd.conf.
> but the main thing I wanted to understand is the condition when
> we printed such text.
Fair enough, let's continue.
> > Your {} block is entirely wrong. You will only display
> messages if we
> > 'assume' a localhost ip? What about the fool with 15 dns
> aliases who
> > can't understand why their server responds with the name
> pigsfeet.ugh,
> > and can't seem to change it (no idea why...)
>
> I don't think it is so nice to issue an error message on the console
> for a situation we do not know to be in error and which has been
> happily accepted by Apache with no complaints for a long period of
> time. If we have to assume 127.0.0.1, yes that is a configuration
> almost definitely in error and it should be an error message on the
> console like you have it. If gethostname() and gethostbyname()
> worked, however, then I don't think we should complain so loudly. An
> info or warning message in the log should suffice. I would *guess*
> that there are great numbers of existing apache installations with no
> ServerName but a valid DNS setup and hence no problems.
Ok... issue one, this patch was already accepted into 1.3.13, and 2.0
is a new beast, so we don't have to follow the 'it worked this way
before' arguments if we are improving the product. But on to the Q...
The fdqn function is called if the user doesn't specify ServerName.
Now, the patch gave them a message telling them what we uncovered.
That could be, in order...
* A dotted name. Not necessarily the 'right' name, but a dotted name.
* An IP address in dot notation. Most likely a good one, but not a name.
* The system loopback IP in dot notation, 127.0.0.1
If we had an undotted name (local intranet, perhaps), then all is lost
for the user. They aught to know that their site isn't called pigsfeet
(dot nothing), but is called 10.15.15.1. Not very nice of us, but then
again, we wouldn't want to name the server pigsfeet if they are also
pigsfeet.com now, would we?
Without touching more than the single function, we could only detect
conditions one and two as a unit, not by case, for the message. Therefore
we print the name in any case, and the user can ignore, add or even
(gasp!) correct the ServerName, as appropriate.
We document in httpd.conf that they should fill this in. Providing a
warning that they haven't isn't bad, IMHO.
Bill
Re: confused about new ServerName logic
Posted by Jeff Trawick <tr...@ibm.net>.
> From: "William A. Rowe, Jr." <wr...@lnd.com>
> Date: Wed, 21 Jun 2000 10:25:30 -0500
>
> > From: Jeff Trawick [mailto:trawick@ibm.net]
> > Sent: Wednesday, June 21, 2000 7:44 AM
> >
> > I thought I understood what was going on, but I guess not... I'm
> > getting messages about needing ServerName even when gethostname() and
> > gethostbyname() work. (Also, I'm not crazy about the phrasing of the
> > messages, but probably nobody will like my changes :) )
> >
> > Can somebody explain why the patch below isn't appropriate? It only
> > complains about no ServerName if we can't properly determine the
> > hostname. It doesn't complain if we *can* determine the hostname.
>
> You are looking at patching day old source... this fix didn't
> exist...
I don't understand...
> you are welcome to change the first message, but I didn't like your change
> to the second (decent comprimize?) I would rather say we are 'assuming',
> and if they read 'your' first message, they will know why. 'your' second
> message implies we updated the thing in the file (a no no). The message
> (mine or yours) is rather untested in any case, in the sense of 'will they
> get this?'
I'd rather not quibble about the text... I thought the existing text
was awkward and suggested a new one, but the main thing I wanted to
understand is the condition when we printed such text.
> Your {} block is entirely wrong. You will only display messages if we
> 'assume' a localhost ip? What about the fool with 15 dns aliases who
> can't understand why their server responds with the name pigsfeet.ugh,
> and can't seem to change it (no idea why...)
I don't think it is so nice to issue an error message on the console
for a situation we do not know to be in error and which has been
happily accepted by Apache with no complaints for a long period of
time. If we have to assume 127.0.0.1, yes that is a configuration
almost definitely in error and it should be an error message on the
console like you have it. If gethostname() and gethostbyname()
worked, however, then I don't think we should complain so loudly. An
info or warning message in the log should suffice. I would *guess*
that there are great numbers of existing apache installations with no
ServerName but a valid DNS setup and hence no problems.
Thanks,
Jeff
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
RE: confused about new ServerName logic
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Jeff Trawick [mailto:trawick@ibm.net]
> Sent: Wednesday, June 21, 2000 7:44 AM
>
> I thought I understood what was going on, but I guess not... I'm
> getting messages about needing ServerName even when gethostname() and
> gethostbyname() work. (Also, I'm not crazy about the phrasing of the
> messages, but probably nobody will like my changes :) )
>
> Can somebody explain why the patch below isn't appropriate? It only
> complains about no ServerName if we can't properly determine the
> hostname. It doesn't complain if we *can* determine the hostname.
You are looking at patching day old source... this fix didn't exist...
you are welcome to change the first message, but I didn't like your change
to the second (decent comprimize?) I would rather say we are 'assuming',
and if they read 'your' first message, they will know why. 'your' second
message implies we updated the thing in the file (a no no). The message
(mine or yours) is rather untested in any case, in the sense of 'will they
get this?'
Your {} block is entirely wrong. You will only display messages if we
'assume' a localhost ip? What about the fool with 15 dns aliases who
can't understand why their server responds with the name pigsfeet.ugh,
and can't seem to change it (no idea why...)
Better leave that message in -any- case a ServerName had to be assigned.
The whole point is, the user is responsible to set it. We simply want
Apache to try and work till they learn what it is, where it is, how to
edit it, and perhaps what a text editor is :)
Bill
If you change the wording, be my guest, but you must update
apache-1.3/src/main/util.c as well, since we want them in sync on the
next release, please!
> Index: src/main/util.c
> ===================================================================
> RCS file: /cvs/apache/apache-2.0/src/main/util.c,v
> retrieving revision 1.58
> diff -u -r1.58 util.c
> --- util.c 2000/06/20 19:30:32 1.58
> +++ util.c 2000/06/21 12:41:41
> @@ -1905,15 +1905,16 @@
> }
> }
>
> - if (!server_hostname)
> + if (!server_hostname) {
> server_hostname = ap_pstrdup(a, "127.0.0.1");
>
> - ap_log_error(APLOG_MARK, APLOG_ALERT | APLOG_NOERRNO, 0,
> - NULL, "%s: Missing ServerName directive in
> httpd.conf.",
> - ap_server_argv0);
> - ap_log_error(APLOG_MARK, APLOG_ALERT | APLOG_NOERRNO, 0,
> - NULL, "%s: assumed ServerName of %s",
> - ap_server_argv0, server_hostname);
> + ap_log_error(APLOG_MARK, APLOG_ALERT | APLOG_NOERRNO, 0,
> + NULL, "%s: A ServerName directive is
> missing from httpd.conf.",
> + ap_server_argv0);
> + ap_log_error(APLOG_MARK, APLOG_ALERT | APLOG_NOERRNO, 0,
> + NULL, "%s: ServerName has been set to %s.",
> + ap_server_argv0, server_hostname);
> + }
>
> return server_hostname;
> }
>
>
> --
> Jeff Trawick | trawick@ibm.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>