>> 2010/10/16 Igor GaliÄ <i.galic@xxxxxxxxxxxxxx>: Hi, Igor. Thank you for the fast response. Your post inspired a whole night of experimentation. :))) >> One of the best advises I've read in Ivan RistiÄ's Apache Security >> is to start with an empty configuration file. Oddly enough, I didn't think of starting with a plain .conf file because I feared I will mess everything up. But actually starting on a blank slate is the best thing I could possibly do to understand how Apache works. Thanks a lot for that suggestion! >> VirtualHosts are a core functionality. Redirects, strangely, are not >> They can be found in mod_alias After testing a lot of scenarios, I realized that in order to start Apache as a service it only needs one line of code so that it can listen on an assigned IP address(es) and port: Listen 127.0.0.1:80 Of course, in order for the server to find files it needs the mod_dir, and, for the browser to display pages properly, mod_mime must be enabled also. Therefore the bare minimum to serve a web page with Apache becomes: Listen 127.0.0.1:80 LoadModule dir_module modules/mod_dir.so LoadModule mime_module modules/mod_mime.so Now, this configuration will only serve a particular file if it is explicitly requested in the URL. In other words, the server so configured will not return a web page if only a directory is requested by the client (e.g. localhost/) -- it will need localhost/index.htm to yield a result. To serve a file when a directory is requested, the DocumentRoot and the DirectoryIndex must be set. Although it doesn't seem to be a problem, I also like to add the ServerRoot to avoid any potential problems with logging or loading modules. And the superminimalist httpd.conf becomes: ServerRoot "E:/apache" Listen 127.0.0.1:80 LoadModule dir_module modules/mod_dir.so LoadModule mime_module modules/mod_mime.so DocumentRoot "E:/" DirectoryIndex index.htm So far so good. With this configuration I can serve pages locally via the loopback IP address, even if my network adapter is disabled (i.e. there is no other IP address for Apache to bind to other than 127.0.0.1.) The thing that really baffles me though, is the ServerName directive and here is the problem. If I configure my Windows HOSTS file to resolve the domains "localhost", "site", and "test" all to the loopback address 127.0.0.1, Apache identifies itself with the hostname the client requested in the URL and NOT the one specified in the ServerName directive?! For example, even if I specify "localhost" as the ServerName: Listen 127.0.0.1:80 ServerName localhost:80 but I also have two other domains (site, test) resolving to the IP address Apache is listening on, the server will NOT identify itself to the client as "localhost" every time a domain is resolved to 127.0.0.1, but as whatever hostname the client requested. If the client types "localhost/page1/", the server will serve pages as "localhost/..."; if the client requests site/page1/, the server will identify itself as "site". In that case the ServerName directive is effectively not working. See, at this stage I am expecting that if I have defined "localhost" as the ServerName in configuration, Apache should redirect all hostnames tied to the same IP back to localhost, thus avoiding duplicate content and confusion. In a real-world scenario, where my server is on a Web host, should I decide to link multiple domains (e.g. www.domain.com, domain.com, my.domain.com) to the provider-assigned IP address, Apache will not redirect users to the main server domain (say, domain.com), even if I specify it with a ServerName directive like this: Listen (provider-assigned IP):80 ServerName domain.com:80 Is this how ServerName is supposed to work? What purpose does it serve as a main configuration directive if it doesn't redirect requests to what it defines? I am asking for more explanation about ServerName because I don't see a way for an administrator to redirect clients via ServerName to the main server domain, unless a VirtualHost is used. The reasons are: a) ServerAlias can't be used outside of a <VirtualHost> directive, thus no other domain names can be redirected to the main domain b) the ServerName directive is rendered useless if not accompanied by a ServerAlias in a VirtualHost clause, since it doesn't redirect clients requesting different domains but identical IP to the main domain address, as described in the preceding paragraphs. In conclusion, if I want to run one server only under multiple domain names, I can't do that unless I add a VirtualHost with a ServerAlias. I also think that, based on my experiments, the ServerName directive better belongs to VirtualHosts and NOT to the main server config. I would like you to comment on this issue so that I can confirm this statement. :) > Rather than placing directives in IfModule, I prefer to > put a LoadModule line there, like so: > > Â<IfModule !dir_module> > Â ÂLoadModule modules/mod_dir.so > Â</IfModule> > >> Â Â DirectoryIndex index.htm >> </IfModule> Can you please explain the reasoning behind this syntax? > First off I'd like to point you to my > http://blag.esotericsystems.at/2010/04/simple-small-secure/ > and Mark's (linked) attempt at this. > > It makes a great deal of sense to specify global policies, so > your VirtualHosts don't have to repeat so much. I checked all the examples. I know I have a lot to learn, but can you please define what "sane global policies" mean to you, given you are running a production server, serving static content only? > Finally, because you're not touching those values, the MPM parameters > ( http://httpd.apache.org/docs/current/mpm.html ) > will be set to default values which probably will not really apply > to your environment later > > But.. first things first.. baby steps, I say. Baby steps. > >> Thank you! > > bye, > i > > -- > Igor GaliÄ > Igor, you mean there are platform-specific options that need to be configured? Thank you, sir! --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|