It can't be simply enabled due to root privileges requirement to bind on 1-1024 range. You'll be need special init script that doest that hack. And after that, if there is no collision, you can switch it to 80 or 443. -- ,,,^..^,,,
On Wed, Nov 18, 2015 at 10:41 PM, Martin Broerse <[email protected]> wrote: > I think for the small intranet tools we build it would be nice if port 80 > could be enabled next to 5984. Perhaps something for 2.0 ? > > - Martin > > On Wed, Nov 18, 2015 at 8:27 PM, Alexander Shorin <[email protected]> wrote: > >> Don't think it's very bad, but it requires to make few more actions to >> make it work and eventually resolve port conflicts if you'll >> eventually need in balancer, rate limiter or else proxy in front of >> CouchDB on the same host. >> -- >> ,,,^..^,,, >> >> >> On Tue, Nov 17, 2015 at 7:21 AM, Johs Ensby <[email protected]> wrote: >> > Thanks Alexander, >> > I am far from a linux geek, so I gave in to redirection with Nginx in >> front. >> > But I would love to see a full step by step recepie for running CouchDB >> on port 80 on a server with no other systems than Ubuntu installed. >> > - A couch server as a minimalistic environment that was extremely simple >> to manage for new developers. >> > >> > I think it is a good idea in terms fo making CouchDB the center of >> attention for a big crowd, not the little supporting role in the corner. >> > But is it technially a bad idea? >> > >> > Johs >> > >> >> On 17. nov. 2015, at 01.56, Alexander Shorin <[email protected]> wrote: >> >> >> >> On Sun, Nov 15, 2015 at 10:01 AM, Johs Ensby <[email protected]> wrote: >> >>> Anyone with a better approach to this than this? >> >>> >> >>> $ sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT >> --to 5984 >> >> >> >> Technically, you need to modify your init script to let it start >> >> couchdb as root and then via chuid get it back running via couchdb >> >> user, but I didn't try this way. >> >> >> >>> I also tried an approach with Nginx forwarding everything to >> localhost:5984 with the new rewrite function. >> >>> The problem here was that the IP adress of the request object got lost >> on its way, so the new rewrite function would report >> >>> peer to be 127.0.0.1 >> >> >> >> If your setup proxying right, then you'll have the following >> >> directives in your conifg: >> >> >> >> proxy_set_header X-Real-IP $remote_addr; >> >> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; >> >> proxy_set_header X-Forwarded-Proto $scheme; >> >> >> >> And then you can get peer IP address or real requested protocol via >> >> these headers. General logic of headers processing is to look for X-* >> >> headers first and then fallback to standard solutions. >> >> >> >> -- >> >> ,,,^..^,,, >> > >>
