> Am 09.02.2018 um 16:12 schrieb Daniel <dferra...@gmail.com>: > > I'm getting lost. > > What would VirtualServer tag mean exactly? > > Thanks in advance and apologies for my slowness :)
The intention of VirtualServer is to solve common properties for a range of VirtualHosts. It's a level between the global settings and individual vhosts. Think of it as having several sets of (nowadays) global configurations for a number of vhosts. Examples: 1. Serving the same resources over http: and https: <VirtualServer example1> ServerName example.org ServerAlias www.example.org DocumentRoot /srv/www/virtual/example.org/htdocs <Location /bla> ... </Location> <VirtualHost *.80> </VirtualHost> <VirtualHost *.443> SSLEngine on ... </VirtualHost> </VirtualServer> 2. Having common settings for a customer <VirtualServer customer2> ServerAdmin ad...@customer2.com ... <VirtualHost *:443> ServerName www1.customer2.com ... </VirtualHost> <VirtualHost *:443> ServerName www2.customer2.com ... </VirtualHost> </VirtualServer> This all could instead be simulated with clever use of Include or Macros. But the inheritance by a VirtualServer is better to read and understand, and so, I argue, easier to get "right" and maintain. Also, we could add directives that enforce limits on what the vhosts can do. Imagine a hoster giving a customers the possibilities to define their vhosts themselves. They all get included in a VirtualServer that limits where DocumentRoots can point to, which directives are available etc. Hope this explains the gist of this. -Stefan > 2018-02-09 13:42 GMT+01:00 Stefan Eissing <stefan.eiss...@greenbytes.de>: >> >> >>> Am 09.02.2018 um 13:25 schrieb Yann Ylavic <ylavic....@gmail.com>: >>> >>> On Fri, Feb 9, 2018 at 12:04 PM, Stefan Eissing >>> <stefan.eiss...@greenbytes.de> wrote: >>>> >>>> >>>>> Am 06.02.2018 um 08:13 schrieb William A Rowe Jr <wr...@rowe-clan.net>: >>>>> >>>>> Forgive the top-post, Gmail app sucks. >>>>> >>>>> Thanks for taking the time for tl;dr - it sums up the current situation >>>>> really well. >>>>> >>>>> I pointed out some months ago that the matching foo in vhosts is weak, >>>>> since we have a 1:1 ip:port relationship. We determined that can change >>>>> in the next iteration to compare a list we already keep. It seems also >>>>> evident that a vhost could have more than one ServerName as long as we >>>>> track the canonical name that the request presented. >>>>> >>>>> Considering your cases, I'm wondering if the simplest thing is to promote >>>>> <VirtualHost > to a preprocessed, but fully nestable context on trunk? >>>> >>>> That is one possible way to address this. However, since VirtualHost >>>> requires at least one address, this would be confusing: >>>> >>>> <VirtualHost *:NNN> >>>> ServerName example.org >>>> <VirtualHost *:80> >>>> </VirtualHost> >>>> <VirtualHost *:443> >>>> </VirtualHost> >>>> </VirtualHost> >>>> >>>> What would NNN be or what would it mean? Would it also be inherited by the >>>> nested vhosts? This is confusing. >>> >>> The <VirualHost> directive could be relaxed to also take no arg. >>> Since at least one is required by now, it wouldn't break anything. >>> >>>> >>>> From usability point of view, it is superior to introduce a new "section" >>>> that can keep common locations and other settings for sharing. The >>>> implementation is more painful, though. Unsurprisingly, I think of >>>> something like this: >>>> >>>> <ManagedDomain example.org> >>>> <VirtualHost *:80> >>>> </VirtualHost> >>>> <VirtualHost *:443> >>>> </VirtualHost> >>>> </ManagedDomain> >>>> >>>> Implementation-wise: >>>> * an MD is basically a server_rec plus additional props >>>> * server_rec gets 2 new members "server_rec *child, *sibling" to keep >>>> contained vhosts >>>> * server_rec->next contains only leaf server_recs -> base_server->next >>>> contains all VirtualHosts as before >>>> * leaf server_rec->child is NULL >>>> * no nesting of MDs foreseen, disabled, no nesting of VirtualHost >>>> >>>> - VirtualHosts server_rec* can be walked as before and all vhost functions >>>> see no change. >>>> - Modules should see no change either >>>> - The MD and VirtualHost hierarchy can be traversed by new code starting >>>> from base server. >>>> >>>> What do you think? >>> >>> I like these semantics. >>> >>> But I'd prefer <VirtualHost> as root, <ManagedDomain ...> is too >>> "domain" centric IMHO (all the inner vhosts are necessarily bound to a >>> domain). >>> With <VirtualHost "some.domain"> or <VirtualHost> + ServerName + >>> WhatEverMakesSenseForAllInners we could achieve the same and more >>> (including a common <ManagedDomain> why not), while individual inner >>> vhosts can have their own domain (if grouping is based on something >>> else). >>> So I find root <VirtualHost> more generic as a container, we could >>> want another name too (Service, Container, ...). >> >> Now, there is a nice naming debate in the makings... ;-) >> >> I appreciate that you like the concept. I agree that groupings that do >> not have a common DNS make sense too and should be possible (first thing >> comes to mind is a grouping by customers). >> >> Since we are in "VirtualHost" land anyway, I can agree to >> >> <VirtualServer "name"> >> >> (I like admin supplied unique names - they are useful.:) >> >> -Stefan >> >> > > > > -- > Daniel Ferradal > IT Specialist > > email dferradal at gmail.com > linkedin es.linkedin.com/in/danielferradal