----- "Appache Lion" <apachel...@gmail.com> wrote: > >> 2010/10/16 Igor Galić <i.ga...@brainsware.org>: > > 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?
In the server context, it sets the fall-back servername. The fallback servername without ServerName specified is the machine's Hostname. > 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. There's a number of reasons to all of this. First off: http://httpd.apache.org/docs/current/mod/core.html#usecanonicalname This determines how httpd will deal internally with being called names ;) *Where* you can place a directive is documented right in the directive's description: http://httpd.apache.org/docs/current/mod/core.html#serveralias Now, the reason why with NO vhosts Apache answers to *everything* is basically the same that with vhosts configuration your first vhost is the so-called default vhost. When no Name matches, this will be fallen back to. > 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. :) I like explicitly name the server.. something silly, so that when you land on the default vhost, you know what you're dealing with. I also like to make the default vhost an invalid one, returning only a 403 NameVirtualHost *:80 <VirtualHost *:80> <Location /> deny from all </Location> </VirtualHOst> # valid vhosts <VirtualHost *:80> </VirtualHOst> Finally: A vhost doesn't always need a ServerAlias.. so.. yeah. > > 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? When you know what you're doing, you know why you're loading a module. You don't *accidently* load it and then accidently use it's functionality. But if I have a number of configuration files, which all *could* use a module, but these files for themselves don't know if it's loaded, I put the loading in <IfModule> so I don't get a warning. > > > 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? Don't allow access to / -- of any kind.. unless you have good reason. Lax the restrictions on the place where you keep your DocumentRoots to the policies you feel can be or think must be laxed. So, something like this: <Directory /> Deny from all # Allow symlinks, but nothing else, performance vs security.. Options FollowSymlinks # .htaccess? No thanks. AllowOverride None </Directory> <Directory /web/*/htdocs/> Allow from all Options +MultiViews # still no .htaccess AllowOverride None </Directory> > > 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? Yes, there are a number of things which are true for some platforms but not for others Acceptfilter is platform specific: http://httpd.apache.org/docs/current/mod/core.html#acceptfilter AcceptMutex, and pretty much *all* MPM functionality: http://httpd.apache.org/docs/current/mod/mpm_common.html#acceptmutex is platform specific, in your case: http://httpd.apache.org/docs/current/mod/mpm_winnt.html EnableSendfile won't work on Windows, and so on.. Actually, EnableSendfile won't work anywhere consistently, so it's been set to default to off in 2.3.8.. > Thank you, sir! You're perfectly welcome. I appreciate your dedication. -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ --------------------------------------------------------------------- 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-unsubscr...@httpd.apache.org " from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
