> Am 09.02.2018 um 16:12 schrieb Daniel <[email protected]>:
>
> 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 [email protected]
...
<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 <[email protected]>:
>>
>>
>>> Am 09.02.2018 um 13:25 schrieb Yann Ylavic <[email protected]>:
>>>
>>> On Fri, Feb 9, 2018 at 12:04 PM, Stefan Eissing
>>> <[email protected]> wrote:
>>>>
>>>>
>>>>> Am 06.02.2018 um 08:13 schrieb William A Rowe Jr <[email protected]>:
>>>>>
>>>>> 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
