To answer in a more generic way. As a "sys admin" or "operatives", you
are already habit to vhosts or Locations with http servers. This is
the same system here. Nothing new, just a syntax different.
I think also there is 2 views of couchdb in oposition here. One is
about managing couchdb in multi mass hosting other is to see couchdb
as a standalone db that could be used on any device.
Now answering to other questions:
On Thu, Aug 19, 2010 at 4:59 PM, Jason Smith <jhs@couch.io> wrote:
> On Thu, Aug 19, 2010 at 21:27, Benoit Chesneau <bchesneau@gmail.com> wrote:
>
>> Could you explain me how it's impossible compared to previous
>> behaviour ? It doesn't change anything technically. Please post all
>> your concern and a way to reproduce , I will have a look on it. Though
>> here hosting > 50 couch - trunk behingd couchdbproxy works. tested
>> yesterday.
>>
>
> ## The top priority question:
>
> How can proxies managed by the sysadmin or network admin know what to do?
>
> Now, vhost is explicit. Anybody with permission can query /_config/vhosts
> for all couches.
That was the case since Jan added this features. Nothing changed and I
think that couchone is running.
>
> With wildcards, e.g. "*/blog", it is impossible to know all domains which
> the web server handles. When a query for fooapp.foodb.mydomain.tld arrives,
> which couch should handle it?
This feature isn't yet implemented. It only works for domain names.
You don't need to use a wildcard. If you're worried about your users
and the fact they could use this feature, I am thinking this is just
an operative concern. If you don't want that your user set vhosts like
this then you will have to think to a way to do this. I'm not sure
that couchdb should concern about it, especially since you can
whitelist _config. You could also create your own _config handler that
filter entries .
Other simple way. Use your own vhost rewriter :
in ini :
[httpd]
redirect_vhost_handler = {couchone_httpd, vhost_handler}
then
vhost_handler(MochiReq, VhostTarget) ->
Path = MochiReq:get(raw_path),
{"/" ++ TargetPath, _, _} = mochiweb_util:urlsplit_path(VhostTarget),
{Firstpart, _, _} = mochiweb_util:partition(TargetPath, "/"),
%% get target path
Target = case DbName of
<<'_utils" ->
...
_ ->
AppPath = VhostTarget ++ Path
end,
?LOG_DEBUG("Vhost Target: '~p'~n", [Target]),
Headers = mochiweb_headers:enter("x-couchdb-vhost-path", Path,
MochiReq:get(headers)),
% build a new mochiweb request
MochiReq1 = mochiweb_request:new(MochiReq:get(socket),
MochiReq:get(method),
Target,
MochiReq:get(version),
Headers),
% cleanup, It force mochiweb to reparse raw uri.
MochiReq1:cleanup(),
MochiReq1.
done.
>
> CouchDB adoption is growing. The network, system, and programming
> responsibilities are becoming different people. It needs to allow everybody
> to do their job.
>
> ## The medium priority question
>
> I have not decided how I feel about "smart" vhosts.
>
> Is it really wrong with 1,000 vhost entries? For sure, *something* must be
> smart to allow managing 1,000 couchapps, however I am not sure if the vhost
> is the best answer.
>
> One possibility is CouchApp. Currently, CouchApp has no idea about rewrites
> and vhosts, `rewrites.json` is plain old data. Maybe CouchApp is the best
> place to set vhosts and rewrites. The .couchapprc is 3 nested JSON objects!
> Is a good place to say, "when you push to this URL, please also configure
> vhosts so fooapp.foodb.mydomain.tld will go to _rewrite"?
I don't think it could work. You don't want to read all dbs to know if
an host was set.
>
> Another possibility is a dedicated tool to manage CouchDB, perhaps within
> Futon, or perhaps standalone. Besides vhosts, there are many things that are
> becoming difficult to manage.
>
> * Database _security object
> * _config
> * _users (mostly changing passwords but also role management is quite
> basic)
>
> When deploying a CouchApp, these must be synchronized between development
> and production (_users could replicate). In other words, vhost is not the
> only problem when you have 1,000 CouchApps. I think all these problems are
> related: there is no "app management console" yet.
I know at least one but not public yet.
>
> ## The low priority question:
>
> Finally, as a sysadmin, wonder about the $var -> $var syntax. I do not enjoy
> learning another domain-specific language just to get my job done. What does
> '$' mean? Maybe it is like shell variables? But shell variables do not use
> '$ when assigning, only when expanding. What other differences are there?
> What about underscore? Does $foo_bar match anything, or only
> anything+"_bar"? Ultimately, I must look in the documentation to make sure.
>
> There is already a syntax for this included in Erlang: regular expressions.
>
> (.*).(.*).mydomain.tld -> /$2/_design/$1/_rewrite
>
> Finally, I am happy to get new changes, just trying to figure out what is
> best for everybody.
Regexps are complicated, Regexps are slow (especially in erlang). Here
we only do pattern matching. There is no complexity. Host is splitted
between dots ('.') . if between dots you have a $ it is considered as
a variable. wildcard are here as a convenience too. we could likely
use a list but I think users prefers to just set a variable name
rather having to split themselves all the domain names. If so
considered it's fine, we could just use list then.
|