Re: The Case for Managed Domains

[Stefan Eissing]

Am 09.02.2018 um 21:21 schrieb Roy T. Fielding :

>> On Feb 9, 2018, at 12:06 PM, Stefan Eissing  
>> wrote:
>>> Am 09.02.2018 um 16:12 schrieb Daniel :
>>> 
>>> 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.
> 
> Hmm, I think reuse of that VS name is confusing.  How about
> HostSet, HostGroup, GroupHost, or ServerGroup?

You may know by now that I truly enjoy naming discussions here...;-) All those 
names are fine with me (except GroupHost).

> FWIW, I think it is terribly poor practice to serve the same resources
> via both https and http.  Setting an auto-redirect would make more sense.

Agreed, in general. There is the case of a server migration where temporarily 
both serve the same. Or, you serve a tls terminator on another port.

-Stefan
> 
> Roy
> 

Re: The Case for Managed Domains

[Roy T. Fielding]

> On Feb 9, 2018, at 12:06 PM, Stefan Eissing  
> wrote:
>> Am 09.02.2018 um 16:12 schrieb Daniel :
>> 
>> 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.

Hmm, I think reuse of that VS name is confusing.  How about
HostSet, HostGroup, GroupHost, or ServerGroup?

FWIW, I think it is terribly poor practice to serve the same resources
via both https and http.  Setting an auto-redirect would make more sense.

Roy

Re: The Case for Managed Domains

[Stefan Eissing]

> Am 09.02.2018 um 16:12 schrieb Daniel :
> 
> 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:


  ServerName example.org
  ServerAlias www.example.org
  DocumentRoot /srv/www/virtual/example.org/htdocs
  
...
  
  
  
  
  
SSLEngine on
...
  


2. Having common settings for a customer


  ServerAdmin ad...@customer2.com
  ...
  
ServerName www1.customer2.com
...
  
  
ServerName www2.customer2.com
...
  



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 :
>> 
>> 
>>> Am 09.02.2018 um 13:25 schrieb Yann Ylavic :
>>> 
>>> On Fri, Feb 9, 2018 at 12:04 PM, Stefan Eissing
>>>  wrote:
 
 
> Am 06.02.2018 um 08:13 schrieb William A Rowe Jr :
> 
> 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 
>  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:
 
 
  ServerName example.org
  
  
  
  
 
 
 What would NNN be or what would it mean? Would it also be inherited by the 
 nested vhosts? This is confusing.
>>> 
>>> The  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:
 
 
  
  
  
  
 
 
 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  as root,  is too
>>> "domain" centric IMHO (all the inner vhosts are necessarily bound to a
>>> domain).
>>> With  or  + ServerName +
>>> WhatEverMakesSenseForAllInners we could achieve the same and more
>>> (including a common  why not), while individual inner
>>> vhosts can have their own domain (if grouping is based on something
>>> else).
>>> So I find root  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
>> 
>> 
>> 
>> (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

Re: The Case for Managed Domains

[Daniel]

I'm getting lost.

What would VirtualServer tag mean exactly?

Thanks in advance and apologies for my slowness :)

2018-02-09 13:42 GMT+01:00 Stefan Eissing :
>
>
>> Am 09.02.2018 um 13:25 schrieb Yann Ylavic :
>>
>> On Fri, Feb 9, 2018 at 12:04 PM, Stefan Eissing
>>  wrote:
>>>
>>>
 Am 06.02.2018 um 08:13 schrieb William A Rowe Jr :

 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 
  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:
>>>
>>> 
>>>   ServerName example.org
>>>   
>>>   
>>>   
>>>   
>>> 
>>>
>>> What would NNN be or what would it mean? Would it also be inherited by the 
>>> nested vhosts? This is confusing.
>>
>> The  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:
>>>
>>> 
>>>   
>>>   
>>>   
>>>   
>>> 
>>>
>>> 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  as root,  is too
>> "domain" centric IMHO (all the inner vhosts are necessarily bound to a
>> domain).
>> With  or  + ServerName +
>> WhatEverMakesSenseForAllInners we could achieve the same and more
>> (including a common  why not), while individual inner
>> vhosts can have their own domain (if grouping is based on something
>> else).
>> So I find root  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
>
> 
>
> (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

Re: The Case for Managed Domains

[Stefan Eissing]

> Am 09.02.2018 um 13:25 schrieb Yann Ylavic :
> 
> On Fri, Feb 9, 2018 at 12:04 PM, Stefan Eissing
>  wrote:
>> 
>> 
>>> Am 06.02.2018 um 08:13 schrieb William A Rowe Jr :
>>> 
>>> 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 
>>>  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:
>> 
>> 
>>   ServerName example.org
>>   
>>   
>>   
>>   
>> 
>> 
>> What would NNN be or what would it mean? Would it also be inherited by the 
>> nested vhosts? This is confusing.
> 
> The  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:
>> 
>> 
>>   
>>   
>>   
>>   
>> 
>> 
>> 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  as root,  is too
> "domain" centric IMHO (all the inner vhosts are necessarily bound to a
> domain).
> With  or  + ServerName +
> WhatEverMakesSenseForAllInners we could achieve the same and more
> (including a common  why not), while individual inner
> vhosts can have their own domain (if grouping is based on something
> else).
> So I find root  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 



(I like admin supplied unique names - they are useful.:)

-Stefan

Re: The Case for Managed Domains

[Stefan Eissing]

> Am 09.02.2018 um 13:28 schrieb Eric Covener :
> 
>> That is one possible way to address this. However, since VirtualHost 
>> requires at least one address, this would be confusing:
>> 
>> 
>>   ServerName example.org
>>   
>>   
>>   
>>   
>> 
>> 
>> What would NNN be or what would it mean? Would it also be inherited by the 
>> nested vhosts? This is confusing.
> 
> I would prefer we just make  or  *:443> work a little better.
> But in the hypothetical nested example, the address could be omitted,
> use *:*, or use *:80 *:443.  I don't like the churn for mods with
> nesting though, since they have server config merge callbacks that
> might be subtly wrong.
> 
>> 
>> 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:
>> 
>> 
>>   
>>   
>>   
>>   
>> 
>> 
>> 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
> 
> Are directives valid in VH implicitly valid in MD and using server
> config merging?  Or are normal directives not anticipated in that
> scope?
> It seems like more for users and module authors to worry about.
> 
>> 
>> - 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 would personally rather see no additional nesting and a replacement
> or extension for  syntax and mapping, along with a way
> forward (by convention) to make directives behave a little better in
> , but most of my users/users are a very low # of VH'es
> so it's not really something I am focused on / tuned into.

My experiment in trunk with a


  SSLEngine *:443


worked. But SSLEngine might not be the  only directive where you 
need some extra "magic" to make it apply to the desired vhost variation.

For clarity, I am now more in favour of nesting vhosts/domains/whatever,
since this makes it more clear when which config applies. Our server
config merging between base and vhosts is well understood and this
would just extend the mechanism.

-Stefan

Re: The Case for Managed Domains

[Eric Covener]

On Fri, Feb 9, 2018 at 7:25 AM, Yann Ylavic  wrote:
> On Fri, Feb 9, 2018 at 12:04 PM, Stefan Eissing
>  wrote:
>>
>>
>>> Am 06.02.2018 um 08:13 schrieb William A Rowe Jr :
>>>
>>> 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 
>>>  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:
>>
>> 
>>ServerName example.org
>>
>>
>>
>>
>> 
>>
>> What would NNN be or what would it mean? Would it also be inherited by the 
>> nested vhosts? This is confusing.
>
> The  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:
>>
>> 
>>
>>
>>
>>
>> 
>>
>> 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  as root,  is too
> "domain" centric IMHO (all the inner vhosts are necessarily bound to a
> domain).
> With  or  + ServerName +
> WhatEverMakesSenseForAllInners we could achieve the same and more
> (including a common  why not), while individual inner
> vhosts can have their own domain (if grouping is based on something
> else).
> So I find root  more generic as a container, we could
> want another name too (Service, Container, ...).

There is infrequently used special handling today for e.g.
 that trumps some of the typical NVH handling
if memory serves.

Maybe that could be shored up or even preferred if it helps.  That
still leaves having inner directives that might want to be
port-specific, I just don't know how common enough that is to not
handle it one at a time with logic (SSL) or expressions/if.

I have colleagues that work on a CERN-based legacy server that allows
many directives to take a Host header argument, but it has no config
sections at all.

Perhaps we could provide a simplified  that took list of hosts
instead of nesting VH'es or similar sections?  But it still has the
problem of per-dir directives only.

-- 
Eric Covener
cove...@gmail.com

Re: The Case for Managed Domains

[Eric Covener]

> That is one possible way to address this. However, since VirtualHost requires 
> at least one address, this would be confusing:
>
> 
>ServerName example.org
>
>
>
>
> 
>
> What would NNN be or what would it mean? Would it also be inherited by the 
> nested vhosts? This is confusing.

I would prefer we just make  or  work a little better.
But in the hypothetical nested example, the address could be omitted,
use *:*, or use *:80 *:443.  I don't like the churn for mods with
nesting though, since they have server config merge callbacks that
might be subtly wrong.

>
> 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:
>
> 
>
>
>
>
> 
>
> 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

Are directives valid in VH implicitly valid in MD and using server
config merging?  Or are normal directives not anticipated in that
scope?
It seems like more for users and module authors to worry about.

>
> - 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 would personally rather see no additional nesting and a replacement
or extension for  syntax and mapping, along with a way
forward (by convention) to make directives behave a little better in
, but most of my users/users are a very low # of VH'es
so it's not really something I am focused on / tuned into.

Re: The Case for Managed Domains

[Yann Ylavic]

On Fri, Feb 9, 2018 at 12:04 PM, Stefan Eissing
 wrote:
>
>
>> Am 06.02.2018 um 08:13 schrieb William A Rowe Jr :
>>
>> 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 
>>  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:
>
> 
>ServerName example.org
>
>
>
>
> 
>
> What would NNN be or what would it mean? Would it also be inherited by the 
> nested vhosts? This is confusing.

The  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:
>
> 
>
>
>
>
> 
>
> 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  as root,  is too
"domain" centric IMHO (all the inner vhosts are necessarily bound to a
domain).
With  or  + ServerName +
WhatEverMakesSenseForAllInners we could achieve the same and more
(including a common  why not), while individual inner
vhosts can have their own domain (if grouping is based on something
else).
So I find root  more generic as a container, we could
want another name too (Service, Container, ...).

Re: The Case for Managed Domains

[Stefan Eissing]

> Am 06.02.2018 um 08:13 schrieb William A Rowe Jr :
> 
> 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 
>  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:


   ServerName example.org
   
   
   
   


What would NNN be or what would it mean? Would it also be inherited by the 
nested vhosts? This is confusing.

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:


   
   
   
   


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?

-Stefan

> One, two, three deep VirtualHost server scopes would provide sharing of 
> config choices between hosts. Because some of these would be Management 
> Scopes, as you suggest, using TAKE_01 would allow an umbrella scope to not 
> actually be attached to an interface at all, but just serve, as the global 
> context does, for inheritance only hosts.
> 
> Simplest example would be a well scoped http:// interface with a nested 
> https:// interface, adding some protected ssl-only content mapping and tls 
> config. That would not diminish the outer http:// vhost mapping.
> 
> Similar examples would be a wild card SSL cert config with a number of 
> specific content hosts nested within that, sharing the same tls config.
> 
> What this doesn't solve is a many:many mapping. I haven't come up with a good 
> answer to that puzzle without resorting to includes and macros, etc.
> 
> 
> 
> On Feb 4, 2018 05:51, "Stefan Eissing"  wrote:
> 
> When thinking about adding ACME support to Apache, I felt that the server 
> lacked
> the concept of something "above" VirtualHosts. Something that keeps common
> properties that some VirtualHosts have in common.

Re: The Case for Managed Domains

[William A Rowe Jr]

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
 to a preprocessed, but fully nestable context on trunk?

One, two, three deep VirtualHost server scopes would provide sharing of
config choices between hosts. Because some of these would be Management
Scopes, as you suggest, using TAKE_01 would allow an umbrella scope to not
actually be attached to an interface at all, but just serve, as the global
context does, for inheritance only hosts.

Simplest example would be a well scoped http:// interface with a nested
https:// interface, adding some protected ssl-only content mapping and tls
config. That would not diminish the outer http:// vhost mapping.

Similar examples would be a wild card SSL cert config with a number of
specific content hosts nested within that, sharing the same tls config.

What this doesn't solve is a many:many mapping. I haven't come up with a
good answer to that puzzle without resorting to includes and macros, etc.



On Feb 4, 2018 05:51, "Stefan Eissing"  wrote:


When thinking about adding ACME support to Apache, I felt that the server
lacked
the concept of something "above" VirtualHosts. Something that keeps common
properties that some VirtualHosts have in common.

Re: The Case for Managed Domains

[William A Rowe Jr]

On Sun, Feb 4, 2018 at 7:47 PM, Eric Covener  wrote:
> On Sun, Feb 4, 2018 at 8:43 PM, Luca Toscano  wrote:
>> I am a bit ignorant about mod_bmx so I'd need to ask some follow up
>> questions: how is it going to solve Stefan's points? As a far as I can see
>> it is a very nice architecture to query metrics and process them via
>> plugins, so I'd be super glad to see it integrated to power up our status
>> page but I don't see how it could help in abstracting properties across
>> vhosts for example. Can anybody give me more info?
>
> FWIW I don't see the relationship either.

I don't see bmx serving the managed domain structure proposed in top post.

But the proposal could certainly alter the structure of bmx itself. The feature
I think Steffen refers to is mod_bmx_vhost, which collects traffic and activity
counts on a per-vhost basis.

In looking at the proposed model, if several vhosts reflected the same basic
unit of web services, I can see it evolving to count and sum the activity
across this management unit, as opposed to each individual vhost.

Re: The Case for Managed Domains

[Steffen]

I was triggered by IO stats he was mentioned:

For example,settings and locations for access logging would be nice to have. IO 
Stats
as well.

> Op 5 feb. 2018 om 02:47 heeft Eric Covener  het volgende 
> geschreven:
> 
>> On Sun, Feb 4, 2018 at 8:43 PM, Luca Toscano  wrote:
>> I am a bit ignorant about mod_bmx so I'd need to ask some follow up
>> questions: how is it going to solve Stefan's points? As a far as I can see
>> it is a very nice architecture to query metrics and process them via
>> plugins, so I'd be super glad to see it integrated to power up our status
>> page but I don't see how it could help in abstracting properties across
>> vhosts for example. Can anybody give me more info?
> 
> FWIW I don't see the relationship either.

Re: The Case for Managed Domains

[Eric Covener]

On Sun, Feb 4, 2018 at 8:43 PM, Luca Toscano  wrote:
> I am a bit ignorant about mod_bmx so I'd need to ask some follow up
> questions: how is it going to solve Stefan's points? As a far as I can see
> it is a very nice architecture to query metrics and process them via
> plugins, so I'd be super glad to see it integrated to power up our status
> page but I don't see how it could help in abstracting properties across
> vhosts for example. Can anybody give me more info?

FWIW I don't see the relationship either.

Re: The Case for Managed Domains

[Luca Toscano]

I am a bit ignorant about mod_bmx so I'd need to ask some follow up
questions: how is it going to solve Stefan's points? As a far as I can see
it is a very nice architecture to query metrics and process them via
plugins, so I'd be super glad to see it integrated to power up our status
page but I don't see how it could help in abstracting properties across
vhosts for example. Can anybody give me more info?

Thanks!

Luca

2018-02-04 15:57 GMT+01:00 Jim Jagielski :

> +1
>
>
> On Feb 4, 2018, at 7:35 AM, Steffen  wrote:
>
> There is already Basic Management eXtensions for Apache : mod_bmx is
> handling vhosts.
>
> https://github.com/hyperic/mod_bmx/
>
> Using it on windows with mrtg and mod_watch to create nice graphs per
> vhost.
>
> An issue is that it is not collecting incoming traffic, Bill(William Rowe)
> is looking for a fix.
>
> I am +1 to adopt mod_bmx and use it as a framework and maybe some of
> Stefan proposals we can fit in.
>
> When I recall Bill did already propose to adopt some time ago.
>
>
> Op 4 feb. 2018 om 12:51 heeft Stefan Eissing 
> het volgende geschreven:
>
> (Apart from my direct comments in my previous reply in the ServerUID
> discussion,
> I offer a little essay about my motivation in this topic for the
> interested, as it
> is related to the mod_md design I did. It is long. Please feel free to
> ignore it.)
>
>
> When thinking about adding ACME support to Apache, I felt that the server
> lacked
> the concept of something "above" VirtualHosts. Something that keeps common
> properties that some VirtualHosts have in common.
>
>
> The Occasional Admin
> 
> My example was the Apache instance I myself had kept on running over the
> years,
> that has a very limited set of DNS domains it manages. What I had always
> disliked
> is when I ended up copy configuration directives between different
> VirtualHosts.
>
> I say "ended up", because there are other options like macros or includes,
> but
> for an occasional site admin like myself, those do not work that well. If
> I go
> in to fix something, it will work best with some local changes to the
> VirtualHost
> that I'd like to change/fix. Editing includes/macros is dangerous as I
> have no
> good feeling if this will break other VirtualHosts that also include/use
> this,
> but I have forgotten about that dependency. I only edit the server every
> few
> months or so.
>
> Then I use Ubuntu, which already comes with several includes. But editing
> those is worse, since I am never certain if edits get replaced on update or
> if updates get ignored due to my edits. I could find this all out, but the
> time I am willing to spend on this is limited.
>
> I consider myself a very average httpd admin.
>
>
> The Arrival of SSL
> --
> This all started when SSL was not really a topic for small sites like mine.
> There was 1 VirtualHost for every DNS name served (plus some aliases).
> Changes
> almost always affected only once vhost at a time.
>
> When https: became relevant (and certificates affordable) things got more
> complicated. It doubled the number of VirtualHosts as most of the sites
> needed
> be be available via http: and https: for the same resources (some
> resources only
> to be available on https:).
>
> Since it took some effort to get a certificate, I got few certs with
> several
> alt-names. This meant the same SSL configurations copy between
> vhosts.
> Again, yes, Includes to the rescue. Did some of them, never was happy.
>
> Now, a VirtualHost in my server no longer was the DNS domain. Instead a DNS
> domain was made of several vhosts and, if I did it correctly, the common
> parts were shared and the other parts stayed separated. It worked, but it
> did not feel very natural.
>
> See: as the admin, I do not look at resources for VirtualHosts. I *have*
> different sets of resources and need them to be served in the right way.
> A vhost is just a vessel to do that. And the vessel no longer could contain
> a complete set of resources. I needed to split it over several vessels.
>
>
> Managed Domains
> ---
> This was the motivation to design something that aggregates the common
> things
> for several VirtualHosts into something new. The name I came up with for
> that is a "Managed Domain".
>
> "Domain" as it is mainly identified by a DNS name. "Managed" because the
> server should offer some nice defaults on how to serve it and take care
> about things.
> aspects like
>
> Obviously it was made to care about the domain's certificate. Another
> thing is that you can specify that resources in this domain require being
> served via https: only.
>
> There are other things that would fit well into this concept. For example,
> settings and locations for access logging would be nice to have. IO Stats
> as well.
>
> Locations would be really useful.
>
>
> Alternative
> ---
> Instead of enhancing Managed Domains, one 

Re: The Case for Managed Domains

[Jim Jagielski]

+1

> On Feb 4, 2018, at 7:35 AM, Steffen  wrote:
> 
> There is already Basic Management eXtensions for Apache : mod_bmx is handling 
> vhosts. 
> 
> https://github.com/hyperic/mod_bmx/ 
> 
> Using it on windows with mrtg and mod_watch to create nice graphs per vhost. 
> 
> An issue is that it is not collecting incoming traffic, Bill(William Rowe) is 
> looking for a fix. 
> 
> I am +1 to adopt mod_bmx and use it as a framework and maybe some of Stefan 
> proposals we can fit in. 
> 
> When I recall Bill did already propose to adopt some time ago. 
> 
> 
> Op 4 feb. 2018 om 12:51 heeft Stefan Eissing  > het volgende geschreven:
> 
>> (Apart from my direct comments in my previous reply in the ServerUID 
>> discussion, 
>> I offer a little essay about my motivation in this topic for the interested, 
>> as it
>> is related to the mod_md design I did. It is long. Please feel free to 
>> ignore it.)
>> 
>> 
>> When thinking about adding ACME support to Apache, I felt that the server 
>> lacked
>> the concept of something "above" VirtualHosts. Something that keeps common 
>> properties that some VirtualHosts have in common.
>> 
>> 
>> The Occasional Admin
>> 
>> My example was the Apache instance I myself had kept on running over the 
>> years,
>> that has a very limited set of DNS domains it manages. What I had always 
>> disliked
>> is when I ended up copy configuration directives between different
>> VirtualHosts. 
>> 
>> I say "ended up", because there are other options like macros or includes, 
>> but
>> for an occasional site admin like myself, those do not work that well. If I 
>> go
>> in to fix something, it will work best with some local changes to the 
>> VirtualHost
>> that I'd like to change/fix. Editing includes/macros is dangerous as I have 
>> no
>> good feeling if this will break other VirtualHosts that also include/use 
>> this, 
>> but I have forgotten about that dependency. I only edit the server every few
>> months or so.
>> 
>> Then I use Ubuntu, which already comes with several includes. But editing
>> those is worse, since I am never certain if edits get replaced on update or
>> if updates get ignored due to my edits. I could find this all out, but the
>> time I am willing to spend on this is limited.
>> 
>> I consider myself a very average httpd admin.
>> 
>> 
>> The Arrival of SSL
>> --
>> This all started when SSL was not really a topic for small sites like mine.
>> There was 1 VirtualHost for every DNS name served (plus some aliases). 
>> Changes
>> almost always affected only once vhost at a time.
>> 
>> When https: became relevant (and certificates affordable) things got more
>> complicated. It doubled the number of VirtualHosts as most of the sites 
>> needed
>> be be available via http: and https: for the same resources (some resources 
>> only
>> to be available on https:).
>> 
>> Since it took some effort to get a certificate, I got few certs with several 
>> alt-names. This meant the same SSL configurations copy between vhosts.
>> Again, yes, Includes to the rescue. Did some of them, never was happy.
>> 
>> Now, a VirtualHost in my server no longer was the DNS domain. Instead a DNS
>> domain was made of several vhosts and, if I did it correctly, the common
>> parts were shared and the other parts stayed separated. It worked, but it
>> did not feel very natural.
>> 
>> See: as the admin, I do not look at resources for VirtualHosts. I *have*
>> different sets of resources and need them to be served in the right way.
>> A vhost is just a vessel to do that. And the vessel no longer could contain
>> a complete set of resources. I needed to split it over several vessels.
>> 
>> 
>> Managed Domains
>> ---
>> This was the motivation to design something that aggregates the common things
>> for several VirtualHosts into something new. The name I came up with for 
>> that is a "Managed Domain". 
>> 
>> "Domain" as it is mainly identified by a DNS name. "Managed" because the
>> server should offer some nice defaults on how to serve it and take care 
>> about things.
>> aspects like 
>> 
>> Obviously it was made to care about the domain's certificate. Another
>> thing is that you can specify that resources in this domain require being
>> served via https: only.
>> 
>> There are other things that would fit well into this concept. For example,
>> settings and locations for access logging would be nice to have. IO Stats
>> as well.
>> 
>> Locations would be really useful.
>> 
>> 
>> Alternative
>> ---
>> Instead of enhancing Managed Domains, one could also go about extending
>> VirtualHosts to allow better management of common resource sets. My patch
>> to allow address lists in SSLEngine goes in that direction. The drawback
>> is that when one overloads existing directives with "special sauce", it
>> has 

Re: The Case for Managed Domains

[Steffen]

There is already Basic Management eXtensions for Apache : mod_bmx is handling 
vhosts. 

https://github.com/hyperic/mod_bmx/

Using it on windows with mrtg and mod_watch to create nice graphs per vhost. 

An issue is that it is not collecting incoming traffic, Bill(William Rowe) is 
looking for a fix. 

I am +1 to adopt mod_bmx and use it as a framework and maybe some of Stefan 
proposals we can fit in. 

When I recall Bill did already propose to adopt some time ago. 


> Op 4 feb. 2018 om 12:51 heeft Stefan Eissing  
> het volgende geschreven:
> 
> (Apart from my direct comments in my previous reply in the ServerUID 
> discussion, 
> I offer a little essay about my motivation in this topic for the interested, 
> as it
> is related to the mod_md design I did. It is long. Please feel free to ignore 
> it.)
> 
> 
> When thinking about adding ACME support to Apache, I felt that the server 
> lacked
> the concept of something "above" VirtualHosts. Something that keeps common 
> properties that some VirtualHosts have in common.
> 
> 
> The Occasional Admin
> 
> My example was the Apache instance I myself had kept on running over the 
> years,
> that has a very limited set of DNS domains it manages. What I had always 
> disliked
> is when I ended up copy configuration directives between different
> VirtualHosts. 
> 
> I say "ended up", because there are other options like macros or includes, but
> for an occasional site admin like myself, those do not work that well. If I go
> in to fix something, it will work best with some local changes to the 
> VirtualHost
> that I'd like to change/fix. Editing includes/macros is dangerous as I have no
> good feeling if this will break other VirtualHosts that also include/use 
> this, 
> but I have forgotten about that dependency. I only edit the server every few
> months or so.
> 
> Then I use Ubuntu, which already comes with several includes. But editing
> those is worse, since I am never certain if edits get replaced on update or
> if updates get ignored due to my edits. I could find this all out, but the
> time I am willing to spend on this is limited.
> 
> I consider myself a very average httpd admin.
> 
> 
> The Arrival of SSL
> --
> This all started when SSL was not really a topic for small sites like mine.
> There was 1 VirtualHost for every DNS name served (plus some aliases). Changes
> almost always affected only once vhost at a time.
> 
> When https: became relevant (and certificates affordable) things got more
> complicated. It doubled the number of VirtualHosts as most of the sites needed
> be be available via http: and https: for the same resources (some resources 
> only
> to be available on https:).
> 
> Since it took some effort to get a certificate, I got few certs with several 
> alt-names. This meant the same SSL configurations copy between vhosts.
> Again, yes, Includes to the rescue. Did some of them, never was happy.
> 
> Now, a VirtualHost in my server no longer was the DNS domain. Instead a DNS
> domain was made of several vhosts and, if I did it correctly, the common
> parts were shared and the other parts stayed separated. It worked, but it
> did not feel very natural.
> 
> See: as the admin, I do not look at resources for VirtualHosts. I *have*
> different sets of resources and need them to be served in the right way.
> A vhost is just a vessel to do that. And the vessel no longer could contain
> a complete set of resources. I needed to split it over several vessels.
> 
> 
> Managed Domains
> ---
> This was the motivation to design something that aggregates the common things
> for several VirtualHosts into something new. The name I came up with for 
> that is a "Managed Domain". 
> 
> "Domain" as it is mainly identified by a DNS name. "Managed" because the
> server should offer some nice defaults on how to serve it and take care 
> about things.
> aspects like 
> 
> Obviously it was made to care about the domain's certificate. Another
> thing is that you can specify that resources in this domain require being
> served via https: only.
> 
> There are other things that would fit well into this concept. For example,
> settings and locations for access logging would be nice to have. IO Stats
> as well.
> 
> Locations would be really useful.
> 
> 
> Alternative
> ---
> Instead of enhancing Managed Domains, one could also go about extending
> VirtualHosts to allow better management of common resource sets. My patch
> to allow address lists in SSLEngine goes in that direction. The drawback
> is that when one overloads existing directives with "special sauce", it
> has limits and can be easily confusing.
> 
> 
> Conclusion
> --
> I hope to have made the case for a concept "above" vhosts. If that is
> an extension of what mod_md currently offers or needs to be reshaped
> is not that important. I merely argue that we need such a thing and
> current config concepts