couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Joseph Davis (JIRA)" <>
Subject [jira] Commented: (COUCHDB-1086) Changing bind address in futon does record the new address correctly in config files
Date Thu, 10 Mar 2011 01:06:00 GMT


Paul Joseph Davis commented on COUCHDB-1086:

Couch will always write to the last confit file spacified. There's no code that treats local.ini
any differently than any other config file, it's merely convention. I'd close this outright
as won't fix but I'll wait and see if anyone has a good idea on how to do this differently.
For instance there were previous suggestions on writing back to the last file where the setting
was specified, or by specifying the file to write to on the command line. Well I may have
just thought of that last one. Anyway, yeah, not a bug but maybe there's an enhancement here.

> Changing bind address in futon does record the new address correctly in config files
> ------------------------------------------------------------------------------------
>                 Key: COUCHDB-1086
>                 URL:
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Futon
>    Affects Versions: 1.0.2
>         Environment: Ubuntu 10.04
>            Reporter: Michael Wiederhold
>            Priority: Critical
> 1) I install couchdb and change the bind address in default.ini to so I can access
couch remotely.
> 2) In futon I change the bind address to and then refresh the web page an the
web ui disappears.
> 3) I go back into the config file default.ini and the bind address is still
> 4) I then go into local.ini and there is nothing except for comments.
> 5) I restart the server and it binds to and I cannot see futon.
> The issue is that when changing the bind address in futon, futon puts the new address
in the config file with the highest priority which is in this case the geocouch config file,
but the proper place to put the new bind address is in local.ini.
> I marked this as critical because I can see it affecting a decent amount of users. Should
be a quick fix.

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message