To surf to URL mydomain.com instead of mydomain.com:3000?

My production server is using mongrel_rails on Ubuntu linux.
With Firefox I can reach my production server with the URL:

www.mydomain.com:3000/

but I can’t reach my production server with the URL

www.mydomain.com/

Is there a way to configure mongrel so that I can reach my
production server with the URL www.mydomain.com?

That’s usually done by setting up mod_proxy in Apache to reverse proxy
from Apache to mongrel. I believe that is the typical mongrel production
scenario?

Here’s one page I found on the mongrel wiki (it warns it may be
outdated, but I think it’s still good) leading you through how to do
that.

http://mongrel.rubyforge.org/wiki/Apache

Note that once you’ve turned on mod_proxy in apache, it’s very important
to include the line “ProxyRequests off” in your apache config. We’re
using mod_proxy as a reverse proxy, but by default it’ll be an unsecured
forward proxy too, which is something you definitely don’t want.
“ProxyRequests off” turns this off.

Hope this helps. Some other mongrel experts correct me if I’m wrong,
I’ve been puzzling through this stuff myself.

Jonathan

James T. wrote:

production server with the URL www.mydomain.com?


Jonathan R.
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu

On Mon, Mar 31, 2008 at 10:15 AM, James T. [email protected]
wrote:

production server with the URL www.mydomain.com?
Run it on port 80 instead of port 3000.

Kirk H.

On Mon, Mar 31, 2008 at 10:25 AM, Jonathan R. [email protected]
wrote:

That’s usually done by setting up mod_proxy in Apache to reverse proxy
from Apache to mongrel. I believe that is the typical mongrel production
scenario?

Yes, the typical production architecture is to have some sort of
webserver front end that proxies to a pool of backend processes.

Apache is a common choice, as is nginx (unless you must use Apache,
nginx will often be a better choice). Some people use lighttpd, and a
small but growing group of people are using my project, Swiftiply.

Kirk H.

You probably need root privileges. Try sudo.

Vish

Kirk,
Do you mean run

% mongrel_rails start -d -p 80

I tried that and mongrel won’t start. But mongrel will start with

% mongrel_rails start -d -p 3000

Is there a mongrel configuration file somewhere that is overriding
the port setting?

Jim

Kirk H. wrote:

On Mon, Mar 31, 2008 at 10:15 AM, James T. [email protected]
wrote:

production server with the URL www.mydomain.com?
Run it on port 80 instead of port 3000.

Kirk H.

On Mon, Mar 31, 2008 at 2:31 PM, James T. [email protected]
wrote:

the port setting?
Okay, if it won’t start, then do you get an error?

Odds are that either there is already something running there, or you
are starting mongrel without sufficient permissions. To bind to a port
below 1024, a process has to be running as root.

Kirk H.

I really do still think you’re going down the wrong path running mongrel
directly on 80, instead of sending it through a proxy on your web
server. I think it’s going to cause you headaches in the long run. Do
you have any web server running on that machine? What web server? Is
there any reason you are choosing not to go the route of having apache
(or other specialized) web server be a front end to your mongrel?

Jonathan

Kirk H. wrote:

Kirk H.


Mongrel-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/mongrel-users


Jonathan R.
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu

Jonathan,
At the moment I am only running mongrel, but we are
just beta testing.

  1. What sort of headaches do you foresee just running mongrel? Do
    you mean from a load balancing, high traffic point of view?
  2. I was planning on running nginx as the front end. Do you see any
    issues
    with nginx vs Apache?

Jim

Jonathan R. wrote:

I really do still think you’re going down the wrong path running mongrel
directly on 80, instead of sending it through a proxy on your web
server. I think it’s going to cause you headaches in the long run. Do
you have any web server running on that machine? What web server? Is
there any reason you are choosing not to go the route of having apache
(or other specialized) web server be a front end to your mongrel?

Jonathan

Kirk H. wrote:

Kirk H.


Mongrel-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/mongrel-users


Jonathan R.
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu

I have no experience with nginx, but someone else on this list said it
was common, so that’d probably work.

If you plan to go that route eventually anyway, I’d just do that now,
because what you need to do to get your mongrel to answer on port 80
will change completely in the presence of nginx or apache vs. now with a
bare mongrel. So the work you’re doing now to figure out how to get
mongrel to run bare on 80 seems kind of unproductive.

I don’t honestly have any specifics in mind as far as problems from
running a bare mongrel on port 80 in production. Maybe others on the
list do. Just that that doesn’t seem to be the popular or recommended
way to do it, so you might run into weird problems that others don’t. As
you’ve noticed, one is that you will need to run the mongrel as root,
which is really pretty undesirable. Or come up with some custom solution
to start mongrel as root and attach it to 80 then exec it as another
user. But now you’re creating weird solutions just to get mongrel to run
bare on 80, when if you’re planning on running it under nginx or apache
anyway you won’t ultimately need, so why deal with it unneccesarily?

Jonathan

James T. wrote:


Jonathan R.
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu


Jonathan R.
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu

Kirk,
There wasn’t an error message but I wasn’t running it
as root. Once I ran it as root it worked fine.
Thanks,

Jim

Kirk H. wrote:

On Mon, Mar 31, 2008 at 2:31 PM, James T. [email protected]
wrote:

the port setting?
Okay, if it won’t start, then do you get an error?

Odds are that either there is already something running there, or you
are starting mongrel without sufficient permissions. To bind to a port
below 1024, a process has to be running as root.

Kirk H.

+1 from me for nginx…

The configuration is pretty straighforward and easy to understand.

Here’s the example config from the nginx cookbook.
http://wiki.codemongers.com/NginxRubyonRailsMongrel

It’s got proxying, gzip compression, & sendfile out of the box (very
nice if
you’d had to configure for apache).

  • scott

On Mon, Mar 31, 2008 at 3:15 PM, Jonathan R. [email protected]
wrote:

I have no experience with nginx, but someone else on this list said it
was common, so that’d probably work.

Despite (or perhaps because of) being an Apache user for nigh on a
decade, I’d advocate for looking at something else first, for a
production app. The reason is, quite simply, because there are other
things that are faster and/or easier to use.

Kirk H.

On Mon, Mar 31, 2008 at 3:15 PM, Jonathan R. [email protected]
wrote:

I don’t honestly have any specifics in mind as far as problems from
running a bare mongrel on port 80 in production. Maybe others on the
list do. Just that that doesn’t seem to be the popular or recommended
way to do it, so you might run into weird problems that others don’t. As

There should be any particular problems. Just be aware of the
limitations. It will work fine for simple testing, though.

you’ve noticed, one is that you will need to run the mongrel as root,
which is really pretty undesirable. Or come up with some custom solution
to start mongrel as root and attach it to 80 then exec it as another
user. But now you’re creating weird solutions just to get mongrel to run
bare on 80, when if you’re planning on running it under nginx or apache
anyway you won’t ultimately need, so why deal with it unneccesarily?

Mongrel has support for changing it’s userid/group after starting.
So, no custom solution is necessary.

Kirk H.

Jonathan,
You make a good point about running mongrel as root.
Previously I wasn’t doing that and was using Capistrano
to restart mongrel. So you are right, I had to start
thinking about these mongrel/root issues.
I’ll begin adding a front end, since I need to get
there anyway, sooner is better.
Thanks,

Jim

Jonathan R. wrote:

I have no experience with nginx, but someone else on this list said it
was common, so that’d probably work.

If you plan to go that route eventually anyway, I’d just do that now,
because what you need to do to get your mongrel to answer on port 80
will change completely in the presence of nginx or apache vs. now with a
bare mongrel. So the work you’re doing now to figure out how to get
mongrel to run bare on 80 seems kind of unproductive.

I don’t honestly have any specifics in mind as far as problems from
running a bare mongrel on port 80 in production. Maybe others on the
list do. Just that that doesn’t seem to be the popular or recommended
way to do it, so you might run into weird problems that others don’t. As
you’ve noticed, one is that you will need to run the mongrel as root,
which is really pretty undesirable. Or come up with some custom solution
to start mongrel as root and attach it to 80 then exec it as another
user. But now you’re creating weird solutions just to get mongrel to run
bare on 80, when if you’re planning on running it under nginx or apache
anyway you won’t ultimately need, so why deal with it unneccesarily?

Jonathan

James T. wrote:


Jonathan R.
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu


Jonathan R.
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs