Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 979A8D14E for ; Wed, 12 Dec 2012 01:03:10 +0000 (UTC) Received: (qmail 56170 invoked by uid 500); 12 Dec 2012 01:03:09 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 56137 invoked by uid 500); 12 Dec 2012 01:03:09 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 56129 invoked by uid 99); 12 Dec 2012 01:03:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Dec 2012 01:03:08 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=NORMAL_HTTP_TO_IP,RCVD_IN_DNSWL_LOW,SPF_PASS,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of nestor.urquiza@gmail.com designates 209.85.220.52 as permitted sender) Received: from [209.85.220.52] (HELO mail-pa0-f52.google.com) (209.85.220.52) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Dec 2012 01:03:03 +0000 Received: by mail-pa0-f52.google.com with SMTP id fb1so88267pad.11 for ; Tue, 11 Dec 2012 17:02:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Ks6qbz7AkHbjVKDROW/7WofAQts2t8Mudh0xz4zUQbI=; b=ZHCDqbWEOJ3UvfdF35j3hmrTEsf/04pBGQQcCLHjkj3EP/qXa95Ti8TkpBD7Hj0All C6x6fOd3mn8Tn3KH38SKucyeudPWmhT4XEjJ31xinmeG4xm79qRTj+54SIO5jkcxpXT4 Vtxhpvm4S4imWxpVEKXtur7AJi2c6JutUVhEk+D0edwEFH9kOtsn9u3uX0mW3xNOl+ka 0x5DTWL6YJ6qaI9h1Tbjyo3g27pWhL6OTVR/qjZfPnkglFbzd3Fvcz8/W6MyiIQACrYU LZHPsmmYuP7zfoNFmhYlFbI+tB0cGtyEh6u/e/Luzfog9CDYoWxdhOdZeCxdm2ChaM9v zYiA== MIME-Version: 1.0 Received: by 10.68.241.103 with SMTP id wh7mr38003170pbc.153.1355274163310; Tue, 11 Dec 2012 17:02:43 -0800 (PST) Received: by 10.66.191.41 with HTTP; Tue, 11 Dec 2012 17:02:43 -0800 (PST) In-Reply-To: References: <9F256A04-37E0-46F8-A015-B4EC489D5993@vpro.nl> <0DA78DE9-4C66-4364-92C6-1A80FD38F50E@apache.org> Date: Tue, 11 Dec 2012 20:02:43 -0500 Message-ID: Subject: Re: Disable default unsecure plain HTTP 5984 From: Nestor Urquiza To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org Adam, Thank you very much. Too much bash recently so I completely miss the fact I was using the wrong comment syntax. Cheers, -Nestor On Tue, Dec 11, 2012 at 3:04 PM, Adam Kocoloski wrote: > I think that may be the wrong syntax for .ini file comments. Can you try a leading ";" instead? > > Adam > > On Dec 11, 2012, at 3:02 PM, Nestor Urquiza wrote: > >> This is an old thread but the issue is back in version 1.2.0 >> >> Commenting out the suggested line from default.ini ... >> [daemons] >> #httpd={couch_httpd, start_link, []} >> >> ... does not stop couchdb from listening in the unsecure plain HTTP 5984: >> dev@udesktop2:~$ sudo /etc/init.d/couchdb restart >> * Restarting database server couchdb >> >> >> >> [ >> OK ] >> dev@udesktop2:~$ curl -X GET http://localhost:5984 >> {"couchdb":"Welcome","version":"1.2.0"} >> dev@udesktop2:~$ curl -k -X GET https://localhost:6984 >> {"couchdb":"Welcome","version":"1.2.0"} >> dev@udesktop2:~$ >> >> Any ideas other than using iptables? >> >> On Fri, Oct 21, 2011 at 11:59 AM, Jan Lehnardt wrote: >>> >>> On Oct 21, 2011, at 15:21 , Dave Cottlehuber wrote: >>> >>>> On 21 October 2011 15:16, Nestor Urquiza wrote: >>>>> That was it: I did the change in default,ini and that did the trick. >>>>> Thanks! >>>>> -Nestor >>>>> >>>>> On Fri, Oct 21, 2011 at 8:53 AM, Benoit Chesneau wrote: >>>>>> On Fri, Oct 21, 2011 at 2:37 PM, Nestor Urquiza >>>>>> wrote: >>>>>>> Thanks for the fast responses. >>>>>>> >>>>>>> Here is what I have in daemons section: >>>>>>> [daemons] >>>>>>> ; enable SSL support by uncommenting the following line and supply the >>>>>>> PEM's below. >>>>>>> ; the default ssl port CouchDB listens on is 6984 >>>>>>> httpsd = {couch_httpd, start_link, [https]} >>>>>>> >>>>>>> Still I get the below: >>>>>>> $ ./utils/run >>>>>>> Apache CouchDB 1.1.1a1186848 (LogLevel=info) is starting. >>>>>>> [info] [<0.97.0>] Attempting to start replication >>>>>>> `d30383157f3a29c1356051d04c7a5ed8+continuous+create_target` (document >>>>>>> `by_clientId`). >>>>>>> Apache CouchDB has started. Time to relax. >>>>>>> [info] [<0.31.0>] Apache CouchDB has started on http://127.0.0.1:5984/ >>>>>>> [info] [<0.31.0>] Apache CouchDB has started on https://127.0.0.1:6984/ >>>>>>> >>>>>>> Not sure what I am missing. >>>>>>> Best, >>>>>>> -Nestor >>>>>>> >>>>>>> >>>>>>> On Fri, Oct 21, 2011 at 7:32 AM, Robert Newson wrote: >>>>>>>> Fairly sure you can do as Benoit suggests. It was certainly my >>>>>>>> intention to allow one or other or both, and that was the case when I >>>>>>>> did the original work. >>>>>>>> >>>>>>>> B. >>>>>>>> >>>>>>>> On 21 October 2011 12:24, Benoit Chesneau wrote: >>>>>>>>> On Fri, Oct 21, 2011 at 12:56 PM, Nils Breunese wrote: >>>>>>>>>> Nestor Urquiza wrote: >>>>>>>>>> >>>>>>>>>>> Is it possible to leave just SSL (6984) listening? I have enabled SSL >>>>>>>>>>> but requests are still accepted via plain HTTP 5984. >>>>>>>>>> >>>>>>>>>> I don't know if CouchDB has a configuration setting that lets you disable HTTP, but I guess you could use a firewall to block access to the HTTP port? >>>>>>>>>> >>>>>>>>>> Nils. >>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>> VPRO www.vpro.nl >>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>> You can probably comment the httpd line in [daemons] and only use the https one. >>>>>>>>> >>>>>>>>> - benoit >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> did you comment the line in default.ini? >>>>>> >>>>>> - benoit >>>>>> >>>>> >>>> >>>> Is there a sensible way to do this in local.ini to avoid advising >>>> users to fiddle with default.ini, which gets over-written each >>>> release? >>> >>> Good catch, currently not. >>> >>> Cheers >>> Jan >>> -- >>> >