Re: The Case for Managed Domains
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
> 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
> 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
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: 2.6/3.0 yet again...
+1 This sounds like a good way forward. > Am 09.02.2018 um 14:10 schrieb Jim Jagielski: > > > >> On Feb 9, 2018, at 12:04 AM, William A Rowe Jr wrote: >> >> Since you won't permit 2.6/3.0 to come into existence, we can presume this >> was just a strawman? >> > > That is a false statement. If enough people wanted 2.6/3.0 to come > into existence, it would have. > > All I want is new functionality to be in our end-users hands > in a reasonable time-frame. The *only* way to do that is > via back porting to 2.4.x, due to the amount of time it > will take to release 2.6/3.0. During that time, httpd will further > lag behind, providing ammunition for further FUD and, IMO, > not serving our community well. > > I will make a commitment: as soon as we get 2.4.30 out, assuming > it has PROXY and uwsgi support, I will focus on helping get > 2.6/3.0 out on a fast-track schedule. My plan will be to > have a GM by sometime in May.
2.6/3.0 yet again...
> On Feb 9, 2018, at 12:04 AM, William A Rowe Jrwrote: > > Since you won't permit 2.6/3.0 to come into existence, we can presume this > was just a strawman? > That is a false statement. If enough people wanted 2.6/3.0 to come into existence, it would have. All I want is new functionality to be in our end-users hands in a reasonable time-frame. The *only* way to do that is via back porting to 2.4.x, due to the amount of time it will take to release 2.6/3.0. During that time, httpd will further lag behind, providing ammunition for further FUD and, IMO, not serving our community well. I will make a commitment: as soon as we get 2.4.30 out, assuming it has PROXY and uwsgi support, I will focus on helping get 2.6/3.0 out on a fast-track schedule. My plan will be to have a GM by sometime in May.
Re: The Case for Managed Domains
> 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
> 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
On Fri, Feb 9, 2018 at 7:25 AM, Yann Ylavicwrote: > 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
> 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
On Fri, Feb 9, 2018 at 12:04 PM, Stefan Eissingwrote: > > >> 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
> 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.