Tag Info

Hot answers tagged

6

Apache will still serve static files, but it will only serve them once. Perhaps the easiest way is to configure varnish to listen on all IP addresses for port 80, and configure Apache to listen to on localhost:8000 for example. Then you configure varnish to forward all requests it receives to localhost:8000 for Apache to handle. I would go with a varnish ...


4

There is no way to do what you are asking for in DNS. DNS simply resolves a hostname to an IP address there are no 'redirect' features If you want users to only use your app via www.example.com you will have to do it in the app using the rack rewrite tip you linked to.


1

That's intended (and even, some say, desired) behaviour on Passenger's part. It likes to prune unused appserver workers so that the RAM is available for other things if necessary. You can adjust Passenger's behaviour with PassengerMinInstances and/or PassengerPoolIdleTime.


1

From the unicorn docs, It is designed to help Rails 1.x and 2.y users transition to Rack, but it is NOT needed for Rails 3 applications. Rails 3 users are encouraged to use unicorn(1) instead of unicorn_rails(1). Users of Rails 1.x/2.y may also use unicorn(1) instead of unicorn_rails(1). http://unicorn.bogomips.org/unicorn_rails_1.html So, no, you ...


1

Yes, this is rather "do it for me" -- most of what you still need to do is write some shell scripts to automate things in your local environment. For running the rack apps, I use daemontools in combination with allah to make restarting easier, and I use giddyup to do all my git push deployment easier. The rest is all locally-written scripts.


1

Rack processes are the application servers running your site code not Passenger. I'd suspect problems with the recent upgrades and all the usual troubleshooting around that. Here's what a request looks like on your system. user -> nginx -> passenger -> Rack process -> generates page You system will have multiple Rack processes because each is ...


1

rack-1.3.5 is the version number on the current copy, but rack (~> 1.1.0) is the version constraint that's been specified - they call this the "Pessimistic Version Constraint", and it's preventing anything newer than 1.1.x from fulfilling this dependency. You'll need an older version of rack, or, maybe this "1.1 (Release: 1.3)" will work just fine - you ...


1

Assuming you're okay with changing your DNS servers, you can use DNSimple's "URL" DNS type. This will take care of your issue this at the DNS level. It is mentioned in this Heroku article on Avoiding Naked Domains.


1

If you are on heroku the simplest way is a wildcard domain heroku addons:add custom_domains:wildcard This will redirect all subdomains *.example.com, including www to example.com. If you have root access to your name server you must add: www IN A xxx.xxx.xxx.xxx or * IN A xxx.xxx.xxx.xxx for a wildcard where xxx.xxx.xxx.xxx is ...


1

I ran across this problem as well. We were using Bundler and it didn't seem to help. A certain gem was wanting to use Rack 1.1.0 but unicorn wasn't having it. I don't think rvm with gemsets would help because two different gems are demanding two different versions of rack. Ultimately I ended up with a production server running: Rails 2.3.10 Ruby ...


1

DreamHost does not support Rails 3. In the sense that they have not updated some of the necessary gem versions to run a Rails 3 app and you don't really have the ability to allow your own gems to supersede the ones DreamHost has installed. In this case, my test app was not using any conflicting gems (merely displaying the default index.html page), however ...


1

I managed to get the following to work. For your example what you want for directory and symlink structure is this. /var /www /apps /app1 app.rb config.ru /public /foo -> /var/www/apps/app2/public /app2 app.rb config.ru /public Your nginx server block would then look ...



Only top voted, non community-wiki answers of a minimum length are eligible