You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Benoit Chesneau <bc...@gmail.com> on 2010/09/25 19:46:31 UTC
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
data info shouldn't be in run . anyway too late now. Could have been
waiting a little more ...
Sent from my nexus one.
On Sep 25, 2010 7:38 PM, <fd...@apache.org> wrote:
Author: fdmanana
Date: Sat Sep 25 17:37:57 2010
New Revision: 1001283
URL: http://svn.apache.org/viewvc?rev=1001283&view=rev
Log:
COUCHDB-393 related: moving couch.uri to a better place by default.
Modified:
couchdb/trunk/etc/couchdb/Makefile.am
couchdb/trunk/etc/couchdb/default.ini.tpl.in
Modified: couchdb/trunk/etc/couchdb/Makefile.am
URL:
http://svn.apache.org/viewvc/couchdb/trunk/etc/couchdb/Makefile.am?rev=1001283&r1=1001282&r2=1001283&view=diff
==============================================================================
--- couchdb/trunk/etc/couchdb/Makefile.am (original)
+++ couchdb/trunk/etc/couchdb/Makefile.am Sat Sep 25 17:37:57 2010
@@ -32,6 +32,7 @@ default.ini: default.ini.tpl
-e "s|%localbuilddatadir%|../share/couchdb|g" \
-e "s|%localstatelibdir%|../var/lib/couchdb|g" \
-e "s|%localstatelogdir%|../var/log/couchdb|g" \
+ -e "s|%localstaterundir%|../var/run/couchdb|g" \
-e "s|%couchprivlibdir%|../lib/couch-$(version)/priv/lib|g" \
-e "s|%couchjs_command_name%|couchjs.exe|g" \
< $< > $@
@@ -43,6 +44,7 @@ default.ini: default.ini.tpl
-e "s|%localbuilddatadir%|$(localdatadir)|g" \
-e "s|%localstatelibdir%|$(localstatelibdir)|g" \
-e "s|%localstatelogdir%|$(localstatelogdir)|g" \
+ -e "s|%localstaterundir%|$(localstaterundir)|g" \
-e "s|%couchprivlibdir%|$(couchprivlibdir)|g" \
-e "s|%couchjs_command_name%|$(couchjs_command_name)|g" \
< $< > $@
@@ -55,6 +57,7 @@ default_dev.ini: default.ini.tpl
-e "s|%localbuilddatadir%|$(abs_top_builddir)/share|g" \
-e "s|%localstatelibdir%|$(abs_top_builddir)/tmp/lib|g" \
-e "s|%localstatelogdir%|$(abs_top_builddir)/tmp/log|g" \
+ -e "s|%localstaterundir%|$(abs_top_builddir)/tmp/run|g" \
-e "s|%couchprivlibdir%|$(devcouchprivlibdir)|g" \
-e "s|%couchjs_command_name%|$(couchjs_dev_command_name)|g" \
< $< > $@
Modified: couchdb/trunk/etc/couchdb/default.ini.tpl.in
URL:
http://svn.apache.org/viewvc/couchdb/trunk/etc/couchdb/default.ini.tpl.in?rev=1001283&r1=1001282&r2=1001283&view=diff
==============================================================================
--- couchdb/trunk/etc/couchdb/default.ini.tpl.in (original)
+++ couchdb/trunk/etc/couchdb/default.ini.tpl.in Sat Sep 25 17:37:57 2010
@@ -11,7 +11,7 @@ max_attachment_chunk_size = 4294967296 ;
os_process_timeout = 5000 ; 5 seconds. for view and external servers.
max_dbs_open = 100
delayed_commits = true ; set this to false to ensure an fsync before 201
Created is returned
-uri_file = %localstatelibdir%/couch.uri
+uri_file = %localstaterundir%/couch.uri
[httpd]
port = 5984
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb:
Makefile.am default.ini.tpl.in
Posted by Gordon Stratton <go...@gmail.com>.
Noah Slater wrote:
> Just wondering how a client would use them. If there are three bind addresses, how do you know which one to use? I'm not sure I understand the use case here. Not that I don't think clients need to know how to speak to the running CouchDB, just that I don't understand the circumstances around it well enough.
Would this use case make more sense?
http://192.0.2.1:5984
http://[2001:db8:dead:beef::1]:5984
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Paul Davis <pa...@gmail.com>.
On Tue, Sep 28, 2010 at 12:51 AM, Chris Anderson <jc...@apache.org> wrote:
> On Mon, Sep 27, 2010 at 6:59 PM, Noah Slater <ns...@apache.org> wrote:
>>
>> On 28 Sep 2010, at 02:18, Paul Davis wrote:
>>
>>> Multiple public interfaces and binding ssl to a subset? What does it
>>> matter why so much as "not obviously unpossible". In the land of "not
>>> obviously unpossible" as long as we don't have different semantics on
>>> what's served to any given port, then an idea of "the right one" is
>>> rather unimportant and fairly client specific, ie, "the only public
>>> interface I have access to."
>>
>>
>> I'm not sure I see where the confusion is.
>>
>> I am not suggesting this feature is badly thought out.
>>
>> I'm just trying to clarify how it will work.
>>
>> There are four possibilities.
>>
>> A file with a single HTTP URL in it:
>>
>>> http://192.168.0.10:80/
>>
>> A file with a single HTTPS URL in it:
>>
>>> http://192.168.0.20:443/
>>
>> A file with a HTTP and HTTPS URL in it:
>>
>>> http://192.168.0.10:80/
>>> http://192.168.0.20:443/
>>
>> A file with multiple URLs for each protocol in it:
>>
>>> http://192.168.0.10:80/
>>> http://192.168.0.11:80/
>>> http://192.168.0.12:80/
>>> http://192.168.0.20:443/
>>> http://192.168.0.21:443/
>>
>> The first three are okay and I see no problem with them.
>>
>> For the last one, it boils down to the following two question:
>>
>> * Do the port 80 URLs *always* point to the same thing?
>> * Do the port 443 URLs *always* point to the same thing?
>>
>
> I guess I assumed they would always be the same. more realistically I
> see the file could have these contents:
>
> http://192.168.0.10:80/
> http://192.168.0.10:5984/
> https://192.168.0.10:443/
> https://192.168.0.10:8889/
>
> Does that make more sense? I think the protocol needs to be specified
> because what if you want to run https on a non 443 port?
>
>> If the answer is yes to both of those questions, and WILL be yes forever, then I see no problem with adopting this format. If the answer is no, or might be no, then I suspect we need to rethink it. If they could point to different things, and we have no way of indicating what they point to, that would render the file almost useless. I know my question might come across as utterly stupid, but I want to make sure that whatever format we choose is going to be future proof.
>
>
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>
More specifically, the URL scheme needs to reflect the protocol. Once
that exists I think we've exhausted our duty because we can tell
clients "these are the endpoints" and they'll figure out which ones
are reachable and compatible.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Chris Anderson <jc...@apache.org>.
On Mon, Sep 27, 2010 at 6:59 PM, Noah Slater <ns...@apache.org> wrote:
>
> On 28 Sep 2010, at 02:18, Paul Davis wrote:
>
>> Multiple public interfaces and binding ssl to a subset? What does it
>> matter why so much as "not obviously unpossible". In the land of "not
>> obviously unpossible" as long as we don't have different semantics on
>> what's served to any given port, then an idea of "the right one" is
>> rather unimportant and fairly client specific, ie, "the only public
>> interface I have access to."
>
>
> I'm not sure I see where the confusion is.
>
> I am not suggesting this feature is badly thought out.
>
> I'm just trying to clarify how it will work.
>
> There are four possibilities.
>
> A file with a single HTTP URL in it:
>
>> http://192.168.0.10:80/
>
> A file with a single HTTPS URL in it:
>
>> http://192.168.0.20:443/
>
> A file with a HTTP and HTTPS URL in it:
>
>> http://192.168.0.10:80/
>> http://192.168.0.20:443/
>
> A file with multiple URLs for each protocol in it:
>
>> http://192.168.0.10:80/
>> http://192.168.0.11:80/
>> http://192.168.0.12:80/
>> http://192.168.0.20:443/
>> http://192.168.0.21:443/
>
> The first three are okay and I see no problem with them.
>
> For the last one, it boils down to the following two question:
>
> * Do the port 80 URLs *always* point to the same thing?
> * Do the port 443 URLs *always* point to the same thing?
>
I guess I assumed they would always be the same. more realistically I
see the file could have these contents:
http://192.168.0.10:80/
http://192.168.0.10:5984/
https://192.168.0.10:443/
https://192.168.0.10:8889/
Does that make more sense? I think the protocol needs to be specified
because what if you want to run https on a non 443 port?
> If the answer is yes to both of those questions, and WILL be yes forever, then I see no problem with adopting this format. If the answer is no, or might be no, then I suspect we need to rethink it. If they could point to different things, and we have no way of indicating what they point to, that would render the file almost useless. I know my question might come across as utterly stupid, but I want to make sure that whatever format we choose is going to be future proof.
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Noah Slater <ns...@apache.org>.
On 28 Sep 2010, at 02:18, Paul Davis wrote:
> Multiple public interfaces and binding ssl to a subset? What does it
> matter why so much as "not obviously unpossible". In the land of "not
> obviously unpossible" as long as we don't have different semantics on
> what's served to any given port, then an idea of "the right one" is
> rather unimportant and fairly client specific, ie, "the only public
> interface I have access to."
I'm not sure I see where the confusion is.
I am not suggesting this feature is badly thought out.
I'm just trying to clarify how it will work.
There are four possibilities.
A file with a single HTTP URL in it:
> http://192.168.0.10:80/
A file with a single HTTPS URL in it:
> http://192.168.0.20:443/
A file with a HTTP and HTTPS URL in it:
> http://192.168.0.10:80/
> http://192.168.0.20:443/
A file with multiple URLs for each protocol in it:
> http://192.168.0.10:80/
> http://192.168.0.11:80/
> http://192.168.0.12:80/
> http://192.168.0.20:443/
> http://192.168.0.21:443/
The first three are okay and I see no problem with them.
For the last one, it boils down to the following two question:
* Do the port 80 URLs *always* point to the same thing?
* Do the port 443 URLs *always* point to the same thing?
If the answer is yes to both of those questions, and WILL be yes forever, then I see no problem with adopting this format. If the answer is no, or might be no, then I suspect we need to rethink it. If they could point to different things, and we have no way of indicating what they point to, that would render the file almost useless. I know my question might come across as utterly stupid, but I want to make sure that whatever format we choose is going to be future proof.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Sep 27, 2010 at 8:33 PM, Noah Slater <ns...@apache.org> wrote:
>
> On 28 Sep 2010, at 00:50, Chris Anderson wrote:
>
>> On Mon, Sep 27, 2010 at 3:55 PM, Noah Slater <ns...@apache.org> wrote:
>>>
>>> On 27 Sep 2010, at 23:08, Chris Anderson wrote:
>>>
>>>> Hmm I don't see why multiple bind addresses matter.
>>>
>>> Just wondering how a client would use them. If there are three bind addresses, how do you know which one to use? I'm not sure I understand the use case here. Not that I don't think clients need to know how to speak to the running CouchDB, just that I don't understand the circumstances around it well enough.
>>
>> you might want to bind to :80 and :5984, for obvious reasons. now
>> people do that with a proxy, but you could do it with Couch, too.
>
> I get that. :)
>
> Just wondering what the circumstance will be around having two non-SSL ports open on the same CouchDB instance. Will this EVER happen? If so, how would you figure out which line in the file was the correct one?
Multiple public interfaces and binding ssl to a subset? What does it
matter why so much as "not obviously unpossible". In the land of "not
obviously unpossible" as long as we don't have different semantics on
what's served to any given port, then an idea of "the right one" is
rather unimportant and fairly client specific, ie, "the only public
interface I have access to."
Paul
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Noah Slater <ns...@apache.org>.
On 28 Sep 2010, at 00:50, Chris Anderson wrote:
> On Mon, Sep 27, 2010 at 3:55 PM, Noah Slater <ns...@apache.org> wrote:
>>
>> On 27 Sep 2010, at 23:08, Chris Anderson wrote:
>>
>>> Hmm I don't see why multiple bind addresses matter.
>>
>> Just wondering how a client would use them. If there are three bind addresses, how do you know which one to use? I'm not sure I understand the use case here. Not that I don't think clients need to know how to speak to the running CouchDB, just that I don't understand the circumstances around it well enough.
>
> you might want to bind to :80 and :5984, for obvious reasons. now
> people do that with a proxy, but you could do it with Couch, too.
I get that. :)
Just wondering what the circumstance will be around having two non-SSL ports open on the same CouchDB instance. Will this EVER happen? If so, how would you figure out which line in the file was the correct one?
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Chris Anderson <jc...@apache.org>.
On Mon, Sep 27, 2010 at 3:55 PM, Noah Slater <ns...@apache.org> wrote:
>
> On 27 Sep 2010, at 23:08, Chris Anderson wrote:
>
>> Hmm I don't see why multiple bind addresses matter.
>
> Just wondering how a client would use them. If there are three bind addresses, how do you know which one to use? I'm not sure I understand the use case here. Not that I don't think clients need to know how to speak to the running CouchDB, just that I don't understand the circumstances around it well enough.
>
>
you might want to bind to :80 and :5984, for obvious reasons. now
people do that with a proxy, but you could do it with Couch, too.
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Noah Slater <ns...@apache.org>.
On 27 Sep 2010, at 23:08, Chris Anderson wrote:
> Hmm I don't see why multiple bind addresses matter.
Just wondering how a client would use them. If there are three bind addresses, how do you know which one to use? I'm not sure I understand the use case here. Not that I don't think clients need to know how to speak to the running CouchDB, just that I don't understand the circumstances around it well enough.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Paul Davis <pa...@gmail.com>.
> Hmm I don't see why multiple bind addresses matter. We'd just have 3
> http urls in the file. Or maybe I'm being "daft". This is starting to
> feel like IRC.
>
[18:10] <Monty> My and now it might belong to jan____ since its mostly
just a HARD SPOT)
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Robert Newson <ro...@gmail.com>.
I think, at most, it's one http and one https line per file, though
now I think on it, what use case would there be for dynamic port
assignment for https anyway?
B.
On Mon, Sep 27, 2010 at 11:08 PM, Chris Anderson <jc...@apache.org> wrote:
> On Mon, Sep 27, 2010 at 3:06 PM, Noah Slater <ns...@apache.org> wrote:
>>
>> On 27 Sep 2010, at 23:02, Chris Anderson wrote:
>>
>>> the https:// urls are SSL, and the http:// urls are regular
>>>
>>> Does that answer the question?
>>
>> Nope. :)
>>
>> My reading of your comment was that at some point, we might want to support multiple bind addresses per protocol. So you might have three HTTP URLs. Is that the case? Do we need to worry about it for the future?
>
> Hmm I don't see why multiple bind addresses matter. We'd just have 3
> http urls in the file. Or maybe I'm being "daft". This is starting to
> feel like IRC.
>
> Chris
>
>
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Chris Anderson <jc...@apache.org>.
On Mon, Sep 27, 2010 at 3:06 PM, Noah Slater <ns...@apache.org> wrote:
>
> On 27 Sep 2010, at 23:02, Chris Anderson wrote:
>
>> the https:// urls are SSL, and the http:// urls are regular
>>
>> Does that answer the question?
>
> Nope. :)
>
> My reading of your comment was that at some point, we might want to support multiple bind addresses per protocol. So you might have three HTTP URLs. Is that the case? Do we need to worry about it for the future?
Hmm I don't see why multiple bind addresses matter. We'd just have 3
http urls in the file. Or maybe I'm being "daft". This is starting to
feel like IRC.
Chris
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Noah Slater <ns...@apache.org>.
On 27 Sep 2010, at 23:02, Chris Anderson wrote:
> the https:// urls are SSL, and the http:// urls are regular
>
> Does that answer the question?
Nope. :)
My reading of your comment was that at some point, we might want to support multiple bind addresses per protocol. So you might have three HTTP URLs. Is that the case? Do we need to worry about it for the future?
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Chris Anderson <jc...@apache.org>.
On Mon, Sep 27, 2010 at 3:01 PM, Noah Slater <ns...@apache.org> wrote:
>
> On 27 Sep 2010, at 22:53, Chris Anderson wrote:
>
>> we need to specify the protocol in the file, as you could potentially
>> have a single couchdb server listening on multiple ports with multiple
>> protocols. (or even on a non-standard port, like https on 8888 or
>> something)
>>
>> so the file could have multiple lines corresponding the the addresses
>> the server is listening on.
>>
>> does that make sense?
>
> Yes, but how do you know which matches up to what?
>
the https:// urls are SSL, and the http:// urls are regular
Does that answer the question?
Chris
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Noah Slater <ns...@apache.org>.
On 27 Sep 2010, at 22:53, Chris Anderson wrote:
> we need to specify the protocol in the file, as you could potentially
> have a single couchdb server listening on multiple ports with multiple
> protocols. (or even on a non-standard port, like https on 8888 or
> something)
>
> so the file could have multiple lines corresponding the the addresses
> the server is listening on.
>
> does that make sense?
Yes, but how do you know which matches up to what?
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Robert Newson <ro...@gmail.com>.
I didn't figure out to do it but when ssl is enabled the file should
probably contain two lines.
On Mon, Sep 27, 2010 at 10:53 PM, Chris Anderson <jc...@apache.org> wrote:
> On Mon, Sep 27, 2010 at 1:58 PM, Noah Slater <ns...@apache.org> wrote:
>>
>> On 26 Sep 2010, at 00:18, Chris Anderson wrote:
>>
>>> On Sat, Sep 25, 2010 at 11:00 AM, Filipe David Manana
>>> <fd...@apache.org> wrote:
>>>> On Sat, Sep 25, 2010 at 6:46 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>>> data info shouldn't be in run . anyway too late now. Could have been
>>>>> waiting a little more ...
>>>>
>>>> We (me, Paul, Chris, Noah, Robert Newson) were all agreeing on
>>>> var/run/couchdb instead of var/lib/couchdb that I rushed into
>>>> committing it to trunk.
>>>> Sorry, should have waited for more opinions yes, I'll revert if needed.
>>>>
>>>>>
>>>
>>> I see the http URL as being much more like a PID file than a database
>>> file. Is there something I'm missing?
>>
>> It is fine as it is:
>>
>> http://www.pathname.com/fhs/2.2/fhs-5.13.html
>>
>> We should rethink the filename though. My original suggestion was to call it "couch.addr" and only include the network address and port number. But we can't do this until we have a separate port number for SSL connections - because you wouldn't be able to tell what the protocol was from this file. Not sure that's a huge issue though. Feedback welcome.
>>
>>
>
> we need to specify the protocol in the file, as you could potentially
> have a single couchdb server listening on multiple ports with multiple
> protocols. (or even on a non-standard port, like https on 8888 or
> something)
>
> so the file could have multiple lines corresponding the the addresses
> the server is listening on.
>
> does that make sense?
>
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Sep 28, 2010 at 5:10 PM, Paul Davis <pa...@gmail.com> wrote:
>
> It occurs to me that perhaps its time that we define a set of "roles"
> or "scenarios" for CouchDB deployment. Like those things where they
> used "In the case of Sally" shorthand to define a whole bunch of
> assumptions. For instance, we've got server, cluster, mobile, desktop,
> and ISS computers. Now we just need to define constraints for each
> one.
>
> Or something...
>
Collect all scenario on the wiki would make sense anyway. It would
allow us to anticipate some problem/need too .
- benoit
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Paul Davis <pa...@gmail.com>.
On Tue, Sep 28, 2010 at 3:10 AM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Mon, Sep 27, 2010 at 11:53 PM, Chris Anderson <jc...@apache.org> wrote:
>
>>
>> we need to specify the protocol in the file, as you could potentially
>> have a single couchdb server listening on multiple ports with multiple
>> protocols. (or even on a non-standard port, like https on 8888 or
>> something)
>>
>> so the file could have multiple lines corresponding the the addresses
>> the server is listening on.
>>
>> does that make sense?
>>
>>
>
> Well this file is here to allow a local application to speak with
> couchdb more easily than looking all the pid and associate port on
> them. What currently does desktopcouch btw. I don't see to have the
> point to have multiple url here just one for the localhost.
>
IMO, either we dump all places CouchDB is listening or none at all. I
don't see it being very easy to figure out from our end, which ip/port
a user will want without dumping them all. As you point out, generally
this is for configurations where they're trying to hit couch locally
so in practice it will most likely only have a single line (when its
used) anyway.
> About ssl + non ssl, well I'm currently asking myself if it's good to
> have have same server sending the same data encrypted or not. My logic
> fails here.
>
I see your point, but I don't think this is something we should
enforce at the server level. At the most, perhaps having a startup
message that indicates that there are two adapters with different
encryption levels or some such.
> About /var/run vs /var/lib, that just sometimes you gave different
> privileges on this folders, giving the possibility to read one or not.
> This is not only a question of giving a "state". I'm actually thinking
> that we may want to have this info in /tmp path where we save
> generally such info. Dbus does this, mysql does this for the socket
> (by default) ... /tmp is available for everyone. While /var/run is
> working for root apps, it doesn't for apps launched per users. At
> first I thought that lib folder was good since the couchdb user have
> access to it. But /tmp may be more appropriate so I could do such
> scenario :
>
> 1. Launch couchdb as benoitc user
> 2. Let my guest know the port by loocking in /tmp/benoitc-couchdb.url
>
I think the issue here is that the CouchDB roles are getting confused.
Benoit is correct that most of the time that people use this
particular feature, it will be for things like desktopcouch. As such,
we need to make sure that they can use this feature easily. For
instance, the path to this file needs to be configurable so that it
can be placed anywhere the desktopcouch people see fit.
OTOH, the default CouchDB role is to be a server. So, by default it
should act like a server. According to FHS guidelines, temporary files
that reflect the state of running daemon (which may or may not be
valid for the next instance of the daemon) are supposed to be placed
in /var/run/.
> What do you think about it?
>
> benoit
>
> ps. sorry for late answer, was difficult to find time during jsconf for this.
>
It occurs to me that perhaps its time that we define a set of "roles"
or "scenarios" for CouchDB deployment. Like those things where they
used "In the case of Sally" shorthand to define a whole bunch of
assumptions. For instance, we've got server, cluster, mobile, desktop,
and ISS computers. Now we just need to define constraints for each
one.
Or something...
Paul Davis
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Noah Slater <ns...@apache.org>.
On 29 Sep 2010, at 13:54, Benoit Chesneau wrote:
>> Each CouchDB instance should be configured to use a separate directory:
>>
>> /srv/username1/var/run/couchdb
>> /srv/username2/var/run/couchdb
>> /srv/username3/var/run/couchdb
>
> /srv is a linux thing. Please don't assume every system use the same rules.
Actually, it's an FHS thing. I was only using it as an example.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Wed, Sep 29, 2010 at 2:05 PM, Noah Slater <ns...@apache.org> wrote:
>
> On 28 Sep 2010, at 18:28, Benoit Chesneau wrote:
>
>> On Tue, Sep 28, 2010 at 6:49 PM, Noah Slater <ns...@apache.org> wrote:
>>>
>>> On 28 Sep 2010, at 08:10, Benoit Chesneau wrote:
>>>
>>>> About /var/run vs /var/lib, that just sometimes you gave different
>>>> privileges on this folders, giving the possibility to read one or not.
>>>> This is not only a question of giving a "state". I'm actually thinking
>>>> that we may want to have this info in /tmp path where we save
>>>> generally such info. Dbus does this, mysql does this for the socket
>>>> (by default) ... /tmp is available for everyone. While /var/run is
>>>> working for root apps, it doesn't for apps launched per users.
>>>
>>> When you install CouchDB, you should configure the /var/run/couchdb directory to be world readable and group/user writable. This keeps it secure, while allowing process to read from it. I believe this is documented in the README. I don't think the location of world writable sockets is related.
>>
>> You expect here there will be one couchdb. But you could have a
>> couchdb per user. Then you need to distinct each users. You could of
>> course put all these users in /var/run, but this isn't something
>> possible on all systems. You don't want /var/run world readable for
>> some obvious security reason.
>
> Each CouchDB instance should be configured to use a separate directory:
>
> /srv/username1/var/run/couchdb
> /srv/username2/var/run/couchdb
> /srv/username3/var/run/couchdb
>
>
/srv is a linux thing. Please don't assume every system use the same rules.
- benoît
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Noah Slater <ns...@apache.org>.
On 28 Sep 2010, at 18:28, Benoit Chesneau wrote:
> On Tue, Sep 28, 2010 at 6:49 PM, Noah Slater <ns...@apache.org> wrote:
>>
>> On 28 Sep 2010, at 08:10, Benoit Chesneau wrote:
>>
>>> About /var/run vs /var/lib, that just sometimes you gave different
>>> privileges on this folders, giving the possibility to read one or not.
>>> This is not only a question of giving a "state". I'm actually thinking
>>> that we may want to have this info in /tmp path where we save
>>> generally such info. Dbus does this, mysql does this for the socket
>>> (by default) ... /tmp is available for everyone. While /var/run is
>>> working for root apps, it doesn't for apps launched per users.
>>
>> When you install CouchDB, you should configure the /var/run/couchdb directory to be world readable and group/user writable. This keeps it secure, while allowing process to read from it. I believe this is documented in the README. I don't think the location of world writable sockets is related.
>
> You expect here there will be one couchdb. But you could have a
> couchdb per user. Then you need to distinct each users. You could of
> course put all these users in /var/run, but this isn't something
> possible on all systems. You don't want /var/run world readable for
> some obvious security reason.
Each CouchDB instance should be configured to use a separate directory:
/srv/username1/var/run/couchdb
/srv/username2/var/run/couchdb
/srv/username3/var/run/couchdb
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Sep 28, 2010 at 6:49 PM, Noah Slater <ns...@apache.org> wrote:
>
> On 28 Sep 2010, at 08:10, Benoit Chesneau wrote:
>
>> About /var/run vs /var/lib, that just sometimes you gave different
>> privileges on this folders, giving the possibility to read one or not.
>> This is not only a question of giving a "state". I'm actually thinking
>> that we may want to have this info in /tmp path where we save
>> generally such info. Dbus does this, mysql does this for the socket
>> (by default) ... /tmp is available for everyone. While /var/run is
>> working for root apps, it doesn't for apps launched per users.
>
> When you install CouchDB, you should configure the /var/run/couchdb directory to be world readable and group/user writable. This keeps it secure, while allowing process to read from it. I believe this is documented in the README. I don't think the location of world writable sockets is related.
You expect here there will be one couchdb. But you could have a
couchdb per user. Then you need to distinct each users. You could of
course put all these users in /var/run, but this isn't something
possible on all systems. You don't want /var/run world readable for
some obvious security reason.
- benoit
- benoit
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Noah Slater <ns...@apache.org>.
On 28 Sep 2010, at 08:10, Benoit Chesneau wrote:
> About /var/run vs /var/lib, that just sometimes you gave different
> privileges on this folders, giving the possibility to read one or not.
> This is not only a question of giving a "state". I'm actually thinking
> that we may want to have this info in /tmp path where we save
> generally such info. Dbus does this, mysql does this for the socket
> (by default) ... /tmp is available for everyone. While /var/run is
> working for root apps, it doesn't for apps launched per users.
When you install CouchDB, you should configure the /var/run/couchdb directory to be world readable and group/user writable. This keeps it secure, while allowing process to read from it. I believe this is documented in the README. I don't think the location of world writable sockets is related.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Sep 28, 2010 at 7:19 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 28.09.2010, at 09:10, Benoit Chesneau <bc...@gmail.com> wrote:
>
>> ps. sorry for late answer, was difficult to find time during jsconf for this.
>
> Sorry :D
>
bah don't, I've now something really interesting to code :)
- benoit
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Sep 28, 2010 at 9:21 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> If we run real
if we were running .
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Sep 28, 2010 at 9:55 PM, Paul Davis <pa...@gmail.com> wrote:
> On Tue, Sep 28, 2010 at 3:49 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>> On Tue, Sep 28, 2010 at 9:41 PM, Paul Davis <pa...@gmail.com> wrote:
>>
>>>
>>> What if the client doesn't have access to the arbitrarily chosen
>>> address? There's no way that CouchDB can guess at all the possible
>>> network configurations to try and make that choice. Even if a random
>>> address works 99% of the time, why make a decision to break things for
>>> the 1%? Even if we list multiple address the client is free to just
>>> try the first one and have it work 99% of the time.
>> indeed.
>> So let' let the client doing the choice itself. I think that's indeed
>> case where there will be more than one will be rare. Put all urls on
>> different lines may be more "unix".
>>
>
> I'm confused, are you agreeing that we need all the address on the
> file system now?
If we have a real usecase for it yes. I don't think we need that. Just
having a local ip would be enough. ip associated to localhost or local
network.
My question is more, is there any use case where we would have more
than one ip with a random port ? If not in which case the app couldn't
read the ini ?
>>>
>
> Still confused. The basic premise of a vhost is to demultiplex
> incoming requests (that share a single transport) and forward them to
> separate resources. Ie, forwarding vhosts to different databases. If
> each vhost had its own ip:port pair, they wouldn't be vhosts, just
> hosts. And further, I don't think I'd be in favor of such a feature as
> the technical debt seems a tad high for the benefit.
>
so I said "if we were" . Just described my idea. I've no opinion on
such thing, just contemplated it sometimes ago.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Paul Davis <pa...@gmail.com>.
On Tue, Sep 28, 2010 at 3:49 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Tue, Sep 28, 2010 at 9:41 PM, Paul Davis <pa...@gmail.com> wrote:
>
>>
>> What if the client doesn't have access to the arbitrarily chosen
>> address? There's no way that CouchDB can guess at all the possible
>> network configurations to try and make that choice. Even if a random
>> address works 99% of the time, why make a decision to break things for
>> the 1%? Even if we list multiple address the client is free to just
>> try the first one and have it work 99% of the time.
> indeed.
> So let' let the client doing the choice itself. I think that's indeed
> case where there will be more than one will be rare. Put all urls on
> different lines may be more "unix".
>
I'm confused, are you agreeing that we need all the address on the
file system now?
>>
>> I'm not sure what you mean by virtual hosting and different data or
>> what problems that might introduce.
>>
> was thinking to a vhost systeme àla apache
>
> [vhost]
> port = 5984
> bind_address = 127.0.0.1
> database_dir = /usr/local/var/lib/couchdb
> view_index_dir = /usr/local/var/lib/couchdb
> uri_file = /usr/local/var/lib/couchdb/couch.uri
>
> etc . one section per vhost. Just a thought.
>
> - benoit
>
Still confused. The basic premise of a vhost is to demultiplex
incoming requests (that share a single transport) and forward them to
separate resources. Ie, forwarding vhosts to different databases. If
each vhost had its own ip:port pair, they wouldn't be vhosts, just
hosts. And further, I don't think I'd be in favor of such a feature as
the technical debt seems a tad high for the benefit.
HTH,
Paul Davis
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Sep 28, 2010 at 9:41 PM, Paul Davis <pa...@gmail.com> wrote:
>
> What if the client doesn't have access to the arbitrarily chosen
> address? There's no way that CouchDB can guess at all the possible
> network configurations to try and make that choice. Even if a random
> address works 99% of the time, why make a decision to break things for
> the 1%? Even if we list multiple address the client is free to just
> try the first one and have it work 99% of the time.
indeed.
So let' let the client doing the choice itself. I think that's indeed
case where there will be more than one will be rare. Put all urls on
different lines may be more "unix".
>
> I'm not sure what you mean by virtual hosting and different data or
> what problems that might introduce.
>
was thinking to a vhost systeme àla apache
[vhost]
port = 5984
bind_address = 127.0.0.1
database_dir = /usr/local/var/lib/couchdb
view_index_dir = /usr/local/var/lib/couchdb
uri_file = /usr/local/var/lib/couchdb/couch.uri
etc . one section per vhost. Just a thought.
- benoit
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Paul Davis <pa...@gmail.com>.
On Tue, Sep 28, 2010 at 3:21 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Tue, Sep 28, 2010 at 9:08 PM, Paul Davis <pa...@gmail.com> wrote:
>> On Tue, Sep 28, 2010 at 2:59 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>> On Tue, Sep 28, 2010 at 7:26 PM, Filipe David Manana
>>> <fd...@apache.org> wrote:
>>>> Looks like I started an avalanche.
>>>>
>>>> Why not 2 files, like:
>>>>
>>>> var/run/couchdb/couch.http
>>>> var/run/couchdb/couch.https
>>>>
>>>> each one would be a CSV (or tab separated, or new line, or whatever)
>>>> list of host:port elements.
>>>> ?
>>>>
>>>
>>> About this issue, what is the usecase of having all urls on fs ?
>>> Couldn't just have one for open and let app see in /_config ?
>>>
>>> - benoit
>>>
>>
>> And which one do we put on the file system?
> The first one, apps won't care, we only run one couchdb with same data
> on it. If we run real virtual hosting with different data, the pb
> would be different
>
>
>>
>> Also, in real life, I doubt most people will ever have more than two
>> entries in this file. Right now, its not even possible to have more
>> than two.
>
> and for above reason, we don't really need to care. Only one ip is enough.
>
What if the client doesn't have access to the arbitrarily chosen
address? There's no way that CouchDB can guess at all the possible
network configurations to try and make that choice. Even if a random
address works 99% of the time, why make a decision to break things for
the 1%? Even if we list multiple address the client is free to just
try the first one and have it work 99% of the time.
I'm not sure what you mean by virtual hosting and different data or
what problems that might introduce.
HTH,
Paul Davis
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Sep 28, 2010 at 9:08 PM, Paul Davis <pa...@gmail.com> wrote:
> On Tue, Sep 28, 2010 at 2:59 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>> On Tue, Sep 28, 2010 at 7:26 PM, Filipe David Manana
>> <fd...@apache.org> wrote:
>>> Looks like I started an avalanche.
>>>
>>> Why not 2 files, like:
>>>
>>> var/run/couchdb/couch.http
>>> var/run/couchdb/couch.https
>>>
>>> each one would be a CSV (or tab separated, or new line, or whatever)
>>> list of host:port elements.
>>> ?
>>>
>>
>> About this issue, what is the usecase of having all urls on fs ?
>> Couldn't just have one for open and let app see in /_config ?
>>
>> - benoit
>>
>
> And which one do we put on the file system?
The first one, apps won't care, we only run one couchdb with same data
on it. If we run real virtual hosting with different data, the pb
would be different
>
> Also, in real life, I doubt most people will ever have more than two
> entries in this file. Right now, its not even possible to have more
> than two.
and for above reason, we don't really need to care. Only one ip is enough.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Paul Davis <pa...@gmail.com>.
On Tue, Sep 28, 2010 at 2:59 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Tue, Sep 28, 2010 at 7:26 PM, Filipe David Manana
> <fd...@apache.org> wrote:
>> Looks like I started an avalanche.
>>
>> Why not 2 files, like:
>>
>> var/run/couchdb/couch.http
>> var/run/couchdb/couch.https
>>
>> each one would be a CSV (or tab separated, or new line, or whatever)
>> list of host:port elements.
>> ?
>>
>
> About this issue, what is the usecase of having all urls on fs ?
> Couldn't just have one for open and let app see in /_config ?
>
> - benoit
>
And which one do we put on the file system? Its not possible to know
which url a client will need to access, only the client will be aware
of the network configuration at their specific site. Since CouchDB
can't decide, it needs to provide clients with the information
necessary for making the decision.
Also, in real life, I doubt most people will ever have more than two
entries in this file. Right now, its not even possible to have more
than two.
HTH,
Paul Davis
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Sep 28, 2010 at 7:26 PM, Filipe David Manana
<fd...@apache.org> wrote:
> Looks like I started an avalanche.
>
> Why not 2 files, like:
>
> var/run/couchdb/couch.http
> var/run/couchdb/couch.https
>
> each one would be a CSV (or tab separated, or new line, or whatever)
> list of host:port elements.
> ?
>
About this issue, what is the usecase of having all urls on fs ?
Couldn't just have one for open and let app see in /_config ?
- benoit
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Oct 3, 2010 at 6:59 PM, Paul Davis <pa...@gmail.com> wrote:
> I think what Noah is saying is that ./configure doesn't have the
> ability to set *any* paths,
It's technically feasible.
I think you can still provide
> good defaults by distributing packages with modified configuration
> files.
Indeed I can patch ini file on distribution to provide my defaults,
like I already said. But I disagree here. I really think that
./configure options should depends on common packaging usage rather
than something written in the stone because "that could be done in
the ini file" (Like db dir, view dir, log dir, run dir. Why not just
having prefix in configure ?) .
Anyway, this thread felt in a loop. So introducing a break waiting
more packagers/deployers feedback. Maybe opening a feedback ticket
about it would help?
- benoit
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Paul Davis <pa...@gmail.com>.
On Sun, Oct 3, 2010 at 10:17 AM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Sunday, October 3, 2010, Noah Slater <ns...@apache.org> wrote:
>>
>> On 3 Oct 2010, at 00:20, Benoit Chesneau wrote:
>>
>>> Let me try again. I know I can set the /var/run directory. That's not
>>> what I want. I want to be able to set separately this path. I don't
>>> see any reason against it. Why not having this possibility ?
>>
>> Same reason we don't let configure set the location of any other specific file. You can set it from the INI configuration. I don't understand the use case that makes this advantageous.
>
> I want to be abble to provide good defaults in packages I distribute.
> Distributing!= Configuring, not the same persons, not the sale
> business.I don't think my usecase is so isolated. Think for example
> about people embedding their couchdb but still want to set this path
> in a common place, without allowing configuration. With current way i
> can't do it without previously patch the ini file. for me this path is
> like setting a socket path. This is setting something that could be
> use by external applications. So something that need in my opinion
> some grunlarity in packaging.
>
> Now rather than discussing , I think we need a vote on this.
>
> -benoit
>
I think what Noah is saying is that ./configure doesn't have the
ability to set *any* paths, so what makes this particular file more
special than every other path specified in the ini files? I'd have to
agree with Noah that I don't see a reason to make this particular file
path specifiable at ./configure time. I think you can still provide
good defaults by distributing packages with modified configuration
files.
HTH,
Paul Davis
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sunday, October 3, 2010, Noah Slater <ns...@apache.org> wrote:
>
> On 3 Oct 2010, at 00:20, Benoit Chesneau wrote:
>
>> Let me try again. I know I can set the /var/run directory. That's not
>> what I want. I want to be able to set separately this path. I don't
>> see any reason against it. Why not having this possibility ?
>
> Same reason we don't let configure set the location of any other specific file. You can set it from the INI configuration. I don't understand the use case that makes this advantageous.
I want to be abble to provide good defaults in packages I distribute.
Distributing!= Configuring, not the same persons, not the sale
business.I don't think my usecase is so isolated. Think for example
about people embedding their couchdb but still want to set this path
in a common place, without allowing configuration. With current way i
can't do it without previously patch the ini file. for me this path is
like setting a socket path. This is setting something that could be
use by external applications. So something that need in my opinion
some grunlarity in packaging.
Now rather than discussing , I think we need a vote on this.
-benoit
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Noah Slater <ns...@apache.org>.
On 3 Oct 2010, at 00:20, Benoit Chesneau wrote:
> Let me try again. I know I can set the /var/run directory. That's not
> what I want. I want to be able to set separately this path. I don't
> see any reason against it. Why not having this possibility ?
Same reason we don't let configure set the location of any other specific file. You can set it from the INI configuration. I don't understand the use case that makes this advantageous.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sat, Oct 2, 2010 at 6:28 PM, Noah Slater <ns...@apache.org> wrote:
>
> On 2 Oct 2010, at 10:57, Benoit Chesneau wrote:
>
>> ./configure --with-url-file=/somepath with default to
>> ${prefix}/var/run/couch.url
>>
>> so we can configure the position we want when packaging. That was my
>> idea. It would ease some deployement, rather than patching the ini
>> file each time we need it.
>
> You should be able to do this by configuring the var/run directory with configure.
Let me try again. I know I can set the /var/run directory. That's not
what I want. I want to be able to set separately this path. I don't
see any reason against it. Why not having this possibility ?
- benoît
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Noah Slater <ns...@apache.org>.
On 2 Oct 2010, at 10:57, Benoit Chesneau wrote:
> ./configure --with-url-file=/somepath with default to
> ${prefix}/var/run/couch.url
>
> so we can configure the position we want when packaging. That was my
> idea. It would ease some deployement, rather than patching the ini
> file each time we need it.
You should be able to do this by configuring the var/run directory with configure.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Sep 30, 2010 at 2:57 PM, Noah Slater <ns...@apache.org> wrote:
>
> On 29 Sep 2010, at 18:56, Benoit Chesneau wrote:
>
>> On Wednesday, September 29, 2010, Noah Slater <ns...@apache.org> wrote:
>>>
>>> On 29 Sep 2010, at 13:59, Benoit Chesneau wrote:
>>>
>>>> On Wed, Sep 29, 2010 at 2:16 PM, Noah Slater <ns...@apache.org> wrote:
>>>>>
>>>>> How about:
>>>>>
>>>>> - No command line options, and no daemon options.
>>>>>
>>>> -1
>
> [...]
>
>> i didn't speak about command line but configuration option.
>
> Hmm?
>
>
./configure --with-url-file=/somepath with default to
${prefix}/var/run/couch.url
so we can configure the position we want when packaging. That was my
idea. It would ease some deployement, rather than patching the ini
file each time we need it.
- benoit
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Noah Slater <ns...@apache.org>.
On 29 Sep 2010, at 18:56, Benoit Chesneau wrote:
> On Wednesday, September 29, 2010, Noah Slater <ns...@apache.org> wrote:
>>
>> On 29 Sep 2010, at 13:59, Benoit Chesneau wrote:
>>
>>> On Wed, Sep 29, 2010 at 2:16 PM, Noah Slater <ns...@apache.org> wrote:
>>>>
>>>> How about:
>>>>
>>>> - No command line options, and no daemon options.
>>>>
>>> -1
[...]
> i didn't speak about command line but configuration option.
Hmm?
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Wednesday, September 29, 2010, Noah Slater <ns...@apache.org> wrote:
>
> On 29 Sep 2010, at 13:59, Benoit Chesneau wrote:
>
>> On Wed, Sep 29, 2010 at 2:16 PM, Noah Slater <ns...@apache.org> wrote:
>>>
>>> On 28 Sep 2010, at 19:07, Paul Davis wrote:
>>>
>>>> It already is a config option:
>>>>
>>>> [couchdb]
>>>> uri_file = %localstaterundir%/couch.uri
>>>
>>> This seals the deal for me.
>>
>> I don't say we should, but changing a configuration file isn't the
>> same as a command line option we could use in a deployment script.
>> Something like it is generally possible in most program distribution
>> around. This is for me like changing pidfile path or socket path on
>> other programs.
>>
>>>
>>> How about:
>>>
>>> - No command line options, and no daemon options.
>>>
>> -1
>
> Say you've installed a CouchDB into some path, and you're running it in a situation where there are many CouchDB instances, or things are configurable regularly. You're already using a custom INI file for each CouchDB, and you already have the ability to customise the URL file from there.
>
> So three questions:
>
> - Why would you need to change the configuration so regularly?
>
> - Why can't you use the INI file?
>
> - Why does the same argument not apply to every other option in the INI file?
>
> As far as I see it, the command line options control how the process is started, not what it's configuration is once it has started. In my mind, it is important to keep this separation of concerns intact.
>
>
i didn't speak about command line but configuration option.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Noah Slater <ns...@apache.org>.
On 29 Sep 2010, at 13:59, Benoit Chesneau wrote:
> On Wed, Sep 29, 2010 at 2:16 PM, Noah Slater <ns...@apache.org> wrote:
>>
>> On 28 Sep 2010, at 19:07, Paul Davis wrote:
>>
>>> It already is a config option:
>>>
>>> [couchdb]
>>> uri_file = %localstaterundir%/couch.uri
>>
>> This seals the deal for me.
>
> I don't say we should, but changing a configuration file isn't the
> same as a command line option we could use in a deployment script.
> Something like it is generally possible in most program distribution
> around. This is for me like changing pidfile path or socket path on
> other programs.
>
>>
>> How about:
>>
>> - No command line options, and no daemon options.
>>
> -1
Say you've installed a CouchDB into some path, and you're running it in a situation where there are many CouchDB instances, or things are configurable regularly. You're already using a custom INI file for each CouchDB, and you already have the ability to customise the URL file from there.
So three questions:
- Why would you need to change the configuration so regularly?
- Why can't you use the INI file?
- Why does the same argument not apply to every other option in the INI file?
As far as I see it, the command line options control how the process is started, not what it's configuration is once it has started. In my mind, it is important to keep this separation of concerns intact.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Wed, Sep 29, 2010 at 2:16 PM, Noah Slater <ns...@apache.org> wrote:
>
> On 28 Sep 2010, at 19:07, Paul Davis wrote:
>
>> It already is a config option:
>>
>> [couchdb]
>> uri_file = %localstaterundir%/couch.uri
>
> This seals the deal for me.
I don't say we should, but changing a configuration file isn't the
same as a command line option we could use in a deployment script.
Something like it is generally possible in most program distribution
around. This is for me like changing pidfile path or socket path on
other programs.
>
> How about:
>
> - No command line options, and no daemon options.
>
-1
> - The above config option should suffice.
+1
>
> - We should probably use URL instead of URI, but that's a minor issue.
0
>
> - The format of the file should be a single URL per line.
+1
>
> - The file will never have more than two entries in it.
0.
>
> - If we ever need to offer named VHOST capabilities, we can use multiple files.
>
+1
> - Something like "name.url" would do, for each VHOST.
>
0
> - That should maintain backward compatibility.
+1.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Noah Slater <ns...@apache.org>.
On 28 Sep 2010, at 19:07, Paul Davis wrote:
> It already is a config option:
>
> [couchdb]
> uri_file = %localstaterundir%/couch.uri
This seals the deal for me.
How about:
- No command line options, and no daemon options.
- The above config option should suffice.
- We should probably use URL instead of URI, but that's a minor issue.
- The format of the file should be a single URL per line.
- The file will never have more than two entries in it.
- If we ever need to offer named VHOST capabilities, we can use multiple files.
- Something like "name.url" would do, for each VHOST.
- That should maintain backward compatibility.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Paul Davis <pa...@gmail.com>.
On Tue, Sep 28, 2010 at 1:52 PM, Randall Leeds <ra...@gmail.com> wrote:
> On Tue, Sep 28, 2010 at 19:42, Benoit Chesneau <bc...@gmail.com> wrote:
>> On Tue, Sep 28, 2010 at 7:39 PM, Filipe David Manana
>> <fd...@apache.org> wrote:
>>
>>>
>>> I was thinking the .uri file was going into a directory within the
>>> users' home directory for the desktopcouch case.
>>> My mistake then.
>
> I think we should make this a config option and be done with it.
> Someone mentioned this already.
>
It already is a config option:
[couchdb]
uri_file = %localstaterundir%/couch.uri
> If I'm to pick up on what Paul said about "scenarios" I would have to
> say that, from what I see, it appears as though the "default" install
> scenario from the source tarball is "server daemon". In that case,
> /var/run should be the default and a switch (maybe even command line
> to make it *super* easy to change [don't hurt me, Noah]), could allow
> to put the file elsewhere.
>
> -Randall
>
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Randall Leeds <ra...@gmail.com>.
On Tue, Sep 28, 2010 at 19:42, Benoit Chesneau <bc...@gmail.com> wrote:
> On Tue, Sep 28, 2010 at 7:39 PM, Filipe David Manana
> <fd...@apache.org> wrote:
>
>>
>> I was thinking the .uri file was going into a directory within the
>> users' home directory for the desktopcouch case.
>> My mistake then.
I think we should make this a config option and be done with it.
Someone mentioned this already.
If I'm to pick up on what Paul said about "scenarios" I would have to
say that, from what I see, it appears as though the "default" install
scenario from the source tarball is "server daemon". In that case,
/var/run should be the default and a switch (maybe even command line
to make it *super* easy to change [don't hurt me, Noah]), could allow
to put the file elsewhere.
-Randall
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Paul Davis <pa...@gmail.com>.
On Tue, Sep 28, 2010 at 2:52 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Tue, Sep 28, 2010 at 8:10 PM, Paul Davis <pa...@gmail.com> wrote:
>
>>>
>>> My answer was more about the csv etc :) what ip i choose to listen and why ?
> This is indeed another issue.
>
>>
>> I think we're starting to talk about orthogonal issues. If you mean a
>> couchdb installed in the home directory, in say, ~/couchdb/, then they
>> would've had to do something like ./configure --prefix=~/couchdb/
>> which would make the default couch.uri path
>> ~/couchdb/var/run/couch.uri. Prefixes don't go away based on where its
>> installed.
>>
>
> Did I say that? But you're right , that's just actually we can't set
> it at compilation differently from the place we put the pid. *Maybe*
> we could have a --with-uri option at compilation ?
>
>
> - benoît
>
We don't currently set any file specific paths in the configure step
to my knowledge, and I don't think this is a good place to start. The
things we do set are based on semantics, ie, localstatelibdir,
localstaterundir, localstatelogdir. Semantically speaking, the
localstaterundir is the best place for couch.uri as outlined
previously.
HTH,
Paul Davis
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Sep 28, 2010 at 8:10 PM, Paul Davis <pa...@gmail.com> wrote:
>>
>> My answer was more about the csv etc :) what ip i choose to listen and why ?
This is indeed another issue.
>
> I think we're starting to talk about orthogonal issues. If you mean a
> couchdb installed in the home directory, in say, ~/couchdb/, then they
> would've had to do something like ./configure --prefix=~/couchdb/
> which would make the default couch.uri path
> ~/couchdb/var/run/couch.uri. Prefixes don't go away based on where its
> installed.
>
Did I say that? But you're right , that's just actually we can't set
it at compilation differently from the place we put the pid. *Maybe*
we could have a --with-uri option at compilation ?
- benoît
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Paul Davis <pa...@gmail.com>.
On Tue, Sep 28, 2010 at 1:42 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Tue, Sep 28, 2010 at 7:39 PM, Filipe David Manana
> <fd...@apache.org> wrote:
>
>>
>> I was thinking the .uri file was going into a directory within the
>> users' home directory for the desktopcouch case.
>> My mistake then.
>>
> It is if couchdb is installed locally in the home. (though it may be a
> security pb if this file is world readable depending of the company
> policy.
>
> My answer was more about the csv etc :) what ip i choose to listen and why ?
>
> - benoît
>
I think we're starting to talk about orthogonal issues. If you mean a
couchdb installed in the home directory, in say, ~/couchdb/, then they
would've had to do something like ./configure --prefix=~/couchdb/
which would make the default couch.uri path
~/couchdb/var/run/couch.uri. Prefixes don't go away based on where its
installed.
If instead you mean the desktopcouch case that just has a custom
configuration, then they have the ability to set the path of the URI
file to their liking which is all that's needed.
If instead you meant something else, its still configurable so it can
be put where ever the user wants.
HTH,
Paul Davis
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Sep 28, 2010 at 7:39 PM, Filipe David Manana
<fd...@apache.org> wrote:
>
> I was thinking the .uri file was going into a directory within the
> users' home directory for the desktopcouch case.
> My mistake then.
>
It is if couchdb is installed locally in the home. (though it may be a
security pb if this file is world readable depending of the company
policy.
My answer was more about the csv etc :) what ip i choose to listen and why ?
- benoît
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Filipe David Manana <fd...@apache.org>.
On Tue, Sep 28, 2010 at 6:31 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Tue, Sep 28, 2010 at 7:26 PM, Filipe David Manana
> <fd...@apache.org> wrote:
>> Looks like I started an avalanche.
>>
>> Why not 2 files, like:
>>
>> var/run/couchdb/couch.http
>> var/run/couchdb/couch.https
>>
>> each one would be a CSV (or tab separated, or new line, or whatever)
>> list of host:port elements.
>> ?
>>
> and how the app would decide what to choose? At least in a "desktopcouch" case ?
>
I was thinking the .uri file was going into a directory within the
users' home directory for the desktopcouch case.
My mistake then.
--
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Sep 28, 2010 at 7:26 PM, Filipe David Manana
<fd...@apache.org> wrote:
> Looks like I started an avalanche.
>
> Why not 2 files, like:
>
> var/run/couchdb/couch.http
> var/run/couchdb/couch.https
>
> each one would be a CSV (or tab separated, or new line, or whatever)
> list of host:port elements.
> ?
>
and how the app would decide what to choose? At least in a "desktopcouch" case ?
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Filipe David Manana <fd...@apache.org>.
Looks like I started an avalanche.
Why not 2 files, like:
var/run/couchdb/couch.http
var/run/couchdb/couch.https
each one would be a CSV (or tab separated, or new line, or whatever)
list of host:port elements.
?
On Tue, Sep 28, 2010 at 6:19 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 28.09.2010, at 09:10, Benoit Chesneau <bc...@gmail.com> wrote:
>
>> ps. sorry for late answer, was difficult to find time during jsconf for this.
>
> Sorry :D
>
> Jan
> --
>
>
--
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Jan Lehnardt <ja...@apache.org>.
On 28.09.2010, at 09:10, Benoit Chesneau <bc...@gmail.com> wrote:
> ps. sorry for late answer, was difficult to find time during jsconf for this.
Sorry :D
Jan
--
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Sep 27, 2010 at 11:53 PM, Chris Anderson <jc...@apache.org> wrote:
>
> we need to specify the protocol in the file, as you could potentially
> have a single couchdb server listening on multiple ports with multiple
> protocols. (or even on a non-standard port, like https on 8888 or
> something)
>
> so the file could have multiple lines corresponding the the addresses
> the server is listening on.
>
> does that make sense?
>
>
Well this file is here to allow a local application to speak with
couchdb more easily than looking all the pid and associate port on
them. What currently does desktopcouch btw. I don't see to have the
point to have multiple url here just one for the localhost.
About ssl + non ssl, well I'm currently asking myself if it's good to
have have same server sending the same data encrypted or not. My logic
fails here.
About /var/run vs /var/lib, that just sometimes you gave different
privileges on this folders, giving the possibility to read one or not.
This is not only a question of giving a "state". I'm actually thinking
that we may want to have this info in /tmp path where we save
generally such info. Dbus does this, mysql does this for the socket
(by default) ... /tmp is available for everyone. While /var/run is
working for root apps, it doesn't for apps launched per users. At
first I thought that lib folder was good since the couchdb user have
access to it. But /tmp may be more appropriate so I could do such
scenario :
1. Launch couchdb as benoitc user
2. Let my guest know the port by loocking in /tmp/benoitc-couchdb.url
What do you think about it?
benoit
ps. sorry for late answer, was difficult to find time during jsconf for this.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Chris Anderson <jc...@apache.org>.
On Mon, Sep 27, 2010 at 1:58 PM, Noah Slater <ns...@apache.org> wrote:
>
> On 26 Sep 2010, at 00:18, Chris Anderson wrote:
>
>> On Sat, Sep 25, 2010 at 11:00 AM, Filipe David Manana
>> <fd...@apache.org> wrote:
>>> On Sat, Sep 25, 2010 at 6:46 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>> data info shouldn't be in run . anyway too late now. Could have been
>>>> waiting a little more ...
>>>
>>> We (me, Paul, Chris, Noah, Robert Newson) were all agreeing on
>>> var/run/couchdb instead of var/lib/couchdb that I rushed into
>>> committing it to trunk.
>>> Sorry, should have waited for more opinions yes, I'll revert if needed.
>>>
>>>>
>>
>> I see the http URL as being much more like a PID file than a database
>> file. Is there something I'm missing?
>
> It is fine as it is:
>
> http://www.pathname.com/fhs/2.2/fhs-5.13.html
>
> We should rethink the filename though. My original suggestion was to call it "couch.addr" and only include the network address and port number. But we can't do this until we have a separate port number for SSL connections - because you wouldn't be able to tell what the protocol was from this file. Not sure that's a huge issue though. Feedback welcome.
>
>
we need to specify the protocol in the file, as you could potentially
have a single couchdb server listening on multiple ports with multiple
protocols. (or even on a non-standard port, like https on 8888 or
something)
so the file could have multiple lines corresponding the the addresses
the server is listening on.
does that make sense?
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Noah Slater <ns...@apache.org>.
On 26 Sep 2010, at 00:18, Chris Anderson wrote:
> On Sat, Sep 25, 2010 at 11:00 AM, Filipe David Manana
> <fd...@apache.org> wrote:
>> On Sat, Sep 25, 2010 at 6:46 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>> data info shouldn't be in run . anyway too late now. Could have been
>>> waiting a little more ...
>>
>> We (me, Paul, Chris, Noah, Robert Newson) were all agreeing on
>> var/run/couchdb instead of var/lib/couchdb that I rushed into
>> committing it to trunk.
>> Sorry, should have waited for more opinions yes, I'll revert if needed.
>>
>>>
>
> I see the http URL as being much more like a PID file than a database
> file. Is there something I'm missing?
It is fine as it is:
http://www.pathname.com/fhs/2.2/fhs-5.13.html
We should rethink the filename though. My original suggestion was to call it "couch.addr" and only include the network address and port number. But we can't do this until we have a separate port number for SSL connections - because you wouldn't be able to tell what the protocol was from this file. Not sure that's a huge issue though. Feedback welcome.
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Chris Anderson <jc...@apache.org>.
On Sat, Sep 25, 2010 at 11:00 AM, Filipe David Manana
<fd...@apache.org> wrote:
> On Sat, Sep 25, 2010 at 6:46 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>> data info shouldn't be in run . anyway too late now. Could have been
>> waiting a little more ...
>
> We (me, Paul, Chris, Noah, Robert Newson) were all agreeing on
> var/run/couchdb instead of var/lib/couchdb that I rushed into
> committing it to trunk.
> Sorry, should have waited for more opinions yes, I'll revert if needed.
>
>>
I see the http URL as being much more like a PID file than a database
file. Is there something I'm missing?
Chris
>> Sent from my nexus one.
>>
>> On Sep 25, 2010 7:38 PM, <fd...@apache.org> wrote:
>> Author: fdmanana
>> Date: Sat Sep 25 17:37:57 2010
>> New Revision: 1001283
>>
>> URL: http://svn.apache.org/viewvc?rev=1001283&view=rev
>> Log:
>> COUCHDB-393 related: moving couch.uri to a better place by default.
>>
>> Modified:
>> couchdb/trunk/etc/couchdb/Makefile.am
>> couchdb/trunk/etc/couchdb/default.ini.tpl.in
>>
>> Modified: couchdb/trunk/etc/couchdb/Makefile.am
>> URL:
>> http://svn.apache.org/viewvc/couchdb/trunk/etc/couchdb/Makefile.am?rev=1001283&r1=1001282&r2=1001283&view=diff
>> ==============================================================================
>> --- couchdb/trunk/etc/couchdb/Makefile.am (original)
>> +++ couchdb/trunk/etc/couchdb/Makefile.am Sat Sep 25 17:37:57 2010
>> @@ -32,6 +32,7 @@ default.ini: default.ini.tpl
>> -e "s|%localbuilddatadir%|../share/couchdb|g" \
>> -e "s|%localstatelibdir%|../var/lib/couchdb|g" \
>> -e "s|%localstatelogdir%|../var/log/couchdb|g" \
>> + -e "s|%localstaterundir%|../var/run/couchdb|g" \
>> -e "s|%couchprivlibdir%|../lib/couch-$(version)/priv/lib|g" \
>> -e "s|%couchjs_command_name%|couchjs.exe|g" \
>> < $< > $@
>> @@ -43,6 +44,7 @@ default.ini: default.ini.tpl
>> -e "s|%localbuilddatadir%|$(localdatadir)|g" \
>> -e "s|%localstatelibdir%|$(localstatelibdir)|g" \
>> -e "s|%localstatelogdir%|$(localstatelogdir)|g" \
>> + -e "s|%localstaterundir%|$(localstaterundir)|g" \
>> -e "s|%couchprivlibdir%|$(couchprivlibdir)|g" \
>> -e "s|%couchjs_command_name%|$(couchjs_command_name)|g" \
>> < $< > $@
>> @@ -55,6 +57,7 @@ default_dev.ini: default.ini.tpl
>> -e "s|%localbuilddatadir%|$(abs_top_builddir)/share|g" \
>> -e "s|%localstatelibdir%|$(abs_top_builddir)/tmp/lib|g" \
>> -e "s|%localstatelogdir%|$(abs_top_builddir)/tmp/log|g" \
>> + -e "s|%localstaterundir%|$(abs_top_builddir)/tmp/run|g" \
>> -e "s|%couchprivlibdir%|$(devcouchprivlibdir)|g" \
>> -e "s|%couchjs_command_name%|$(couchjs_dev_command_name)|g" \
>> < $< > $@
>>
>> Modified: couchdb/trunk/etc/couchdb/default.ini.tpl.in
>> URL:
>> http://svn.apache.org/viewvc/couchdb/trunk/etc/couchdb/default.ini.tpl.in?rev=1001283&r1=1001282&r2=1001283&view=diff
>> ==============================================================================
>> --- couchdb/trunk/etc/couchdb/default.ini.tpl.in (original)
>> +++ couchdb/trunk/etc/couchdb/default.ini.tpl.in Sat Sep 25 17:37:57 2010
>> @@ -11,7 +11,7 @@ max_attachment_chunk_size = 4294967296 ;
>> os_process_timeout = 5000 ; 5 seconds. for view and external servers.
>> max_dbs_open = 100
>> delayed_commits = true ; set this to false to ensure an fsync before 201
>> Created is returned
>> -uri_file = %localstatelibdir%/couch.uri
>> +uri_file = %localstaterundir%/couch.uri
>>
>> [httpd]
>> port = 5984
>>
>
>
>
> --
> Filipe David Manana,
> fdmanana@gmail.com, fdmanana@apache.org
>
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."
>
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Posted by Filipe David Manana <fd...@apache.org>.
On Sat, Sep 25, 2010 at 6:46 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> data info shouldn't be in run . anyway too late now. Could have been
> waiting a little more ...
We (me, Paul, Chris, Noah, Robert Newson) were all agreeing on
var/run/couchdb instead of var/lib/couchdb that I rushed into
committing it to trunk.
Sorry, should have waited for more opinions yes, I'll revert if needed.
>
> Sent from my nexus one.
>
> On Sep 25, 2010 7:38 PM, <fd...@apache.org> wrote:
> Author: fdmanana
> Date: Sat Sep 25 17:37:57 2010
> New Revision: 1001283
>
> URL: http://svn.apache.org/viewvc?rev=1001283&view=rev
> Log:
> COUCHDB-393 related: moving couch.uri to a better place by default.
>
> Modified:
> couchdb/trunk/etc/couchdb/Makefile.am
> couchdb/trunk/etc/couchdb/default.ini.tpl.in
>
> Modified: couchdb/trunk/etc/couchdb/Makefile.am
> URL:
> http://svn.apache.org/viewvc/couchdb/trunk/etc/couchdb/Makefile.am?rev=1001283&r1=1001282&r2=1001283&view=diff
> ==============================================================================
> --- couchdb/trunk/etc/couchdb/Makefile.am (original)
> +++ couchdb/trunk/etc/couchdb/Makefile.am Sat Sep 25 17:37:57 2010
> @@ -32,6 +32,7 @@ default.ini: default.ini.tpl
> -e "s|%localbuilddatadir%|../share/couchdb|g" \
> -e "s|%localstatelibdir%|../var/lib/couchdb|g" \
> -e "s|%localstatelogdir%|../var/log/couchdb|g" \
> + -e "s|%localstaterundir%|../var/run/couchdb|g" \
> -e "s|%couchprivlibdir%|../lib/couch-$(version)/priv/lib|g" \
> -e "s|%couchjs_command_name%|couchjs.exe|g" \
> < $< > $@
> @@ -43,6 +44,7 @@ default.ini: default.ini.tpl
> -e "s|%localbuilddatadir%|$(localdatadir)|g" \
> -e "s|%localstatelibdir%|$(localstatelibdir)|g" \
> -e "s|%localstatelogdir%|$(localstatelogdir)|g" \
> + -e "s|%localstaterundir%|$(localstaterundir)|g" \
> -e "s|%couchprivlibdir%|$(couchprivlibdir)|g" \
> -e "s|%couchjs_command_name%|$(couchjs_command_name)|g" \
> < $< > $@
> @@ -55,6 +57,7 @@ default_dev.ini: default.ini.tpl
> -e "s|%localbuilddatadir%|$(abs_top_builddir)/share|g" \
> -e "s|%localstatelibdir%|$(abs_top_builddir)/tmp/lib|g" \
> -e "s|%localstatelogdir%|$(abs_top_builddir)/tmp/log|g" \
> + -e "s|%localstaterundir%|$(abs_top_builddir)/tmp/run|g" \
> -e "s|%couchprivlibdir%|$(devcouchprivlibdir)|g" \
> -e "s|%couchjs_command_name%|$(couchjs_dev_command_name)|g" \
> < $< > $@
>
> Modified: couchdb/trunk/etc/couchdb/default.ini.tpl.in
> URL:
> http://svn.apache.org/viewvc/couchdb/trunk/etc/couchdb/default.ini.tpl.in?rev=1001283&r1=1001282&r2=1001283&view=diff
> ==============================================================================
> --- couchdb/trunk/etc/couchdb/default.ini.tpl.in (original)
> +++ couchdb/trunk/etc/couchdb/default.ini.tpl.in Sat Sep 25 17:37:57 2010
> @@ -11,7 +11,7 @@ max_attachment_chunk_size = 4294967296 ;
> os_process_timeout = 5000 ; 5 seconds. for view and external servers.
> max_dbs_open = 100
> delayed_commits = true ; set this to false to ensure an fsync before 201
> Created is returned
> -uri_file = %localstatelibdir%/couch.uri
> +uri_file = %localstaterundir%/couch.uri
>
> [httpd]
> port = 5984
>
--
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."