Log in

View Full Version : Editing /etc/hosts leads to 403 Forbidden errors


Korlon
12-12-2003, 10:39 PM
Way off topic here...

I called our application server vendor because some of our testers were having trouble accessing our web application in our testing environment. The solution I was given was to edit the server's /etc/hosts file, removing all but the localhost entry.

This appeared to work, but two of our users are now getting 403 Forbidden errors (one of these was able to connect before I edited the file). Others, including myself, can connect to the application. The two users having trouble now are able to ping the server, but their requests to the web application (which return 403) are not appearing in the application's access log.

I don't know as much about networks as I would like, so I'm looking for any clues as to what could be wrong. Any ideas? Can editing the /etc/hosts file affect users' permissions?

Thanks! :)

Janak Parekh
12-13-2003, 08:36 PM
That's extremely unusual. I've configured a number of webservers and never seen anything like that. I presume it's theoretically possible, but I can't think of the configuration directives one would have to use at this moment.

What I'd do is to look at the webserver's error log (as opposed to the access log) -- it usually is verbose enough for me to debug it. That is, if you are allowed to look at the error log...

--janak

Korlon
12-16-2003, 09:32 PM
Thanks, Janak.

Nothing telling in the error logs, as far as I could see. However, the problem seems to have resolved itself without my help. No idea what was done to address it.

Now if I could convince the rest of the application to fix itself... :?

JvanEkris
12-16-2003, 11:50 PM
just a weird thought, are the file-permissions on /etc/hosts correct ???

Jaap

Korlon
12-17-2003, 02:52 PM
just a weird thought, are the file-permissions on /etc/hosts correct ???

Jaap

As far as I can tell.

As I said before, the problem appears to have gone away. No one is complaining of access problems now. There was a code deployment, which involves restarting the application servers. Maybe that did the trick? The problem originally appeared after a server restart, after all. I just don't know.