How to uninstall Passenger (mod_rails) from nginx? - ruby-on-rails

I've a running nginx and Ubuntu 8.09 site running a rails app -- but we are not making use of Peassenger anymore and it seems to take up a lot of memory.
I google around and there's tons of info on how to install Passenger, but I didn't find any on uninstalling.

IF your only concern is the memory usage, removing the Passenger lines from the webserver config file will cause it to no longer be loaded.
If you want to completely remove it from your system, them you'll have to uninstall the gem too, assuming that's how you initially got it.
A tip for the future: I generally keep lots of tiny config files, one for each module that I'm using, so that it's easy to find, edit, and eventually, remove them. This is not the general case, though.
edit: hum, apparently Passenger compiles a new nginx with support for it, so it's not as simple as removing a module. Well, in that case I'd recommend you wipe your current nginx binary and compile a new one without mod_rails. Notice there may still be lines in the existing config file to be removed.

Edit your httpd.conf and remove the lines you once added to install mod_rails.
If you don't remember, look at the installation tutorials and undo the steps in reverse order.

Related

Can't Load Rails Server Even Could not find pg-0.17.1 in any of the sources

pretty new to all this and ran into a real ditch. I had ruby 2.0.0p353 running with rails 4.1+, everything was setup with homebrew, xcode, git,heroku etc.... I'm on OSX 10.9.4
then came time to try out S3 and install the aws-sdk gem. I was unable to install the nokogiri gem after scouring stackoverflow for days to no avail. I then came across this article online that suggested to update rails and ruby versions. In my attempt to upgrade my ruby version to the latest, I followed the instructions given here as follows:
in terminal and in my app folder:
/usr/local/opt/ruby/bin
export PATH="/usr/local/opt/ruby/bin:$PATH"
source ~/.bash_profile
gem update --system
..I subsequently tried bundle update / installs as well... and receive this error shown on pastebin: http://pastebin.com/Q64j0LwD
Now, things are completely messed up as I am unable to even run a rails server. Getting this error Could not find pg-0.17.1 in any of the sources
I currently have Ruby 2.1.2p95 installed. I don't know what else is installed during this trial and error probably several versions of many things unfortunately. Any advice would be great.
: Could not find pg-0.17.1 in any of the sources
Try postgresapp and use documentation for install and configure postgresql server.
The easiest way to get started with PostgreSQL on the Mac
You're clearly new to rails coding. I made a lot of mistakes when I started. I still make a lot of mistakes, but they're more complex mistakes now, mostly ;)
I'd start by using "RailsInstaller". Excellent way to get all the pieces... except Postgres. As suggested by someone with a name consisting of a lot of non-ASCII characters, PostgresApp is incredibly useful to get a more up to date Postgres without messing with compiling stuff outside the project.
You probably should use "rvm" or "rbenv" to manage your rubies. I've tried both, and I favour rvm. rbenv is recommended, but I spent an awkward half day trying to disentangle the consequence of typing "bundle exec rails new app", before I decided to go back to rvm. rvm works more naturally for me, at the expense of creating gemsets for each project. Which, personally, I like. I want to isolate each thing I add to an OS, so I can work on multiple projects with less contamination, and without having to create a VM for each project.
Contamination is, I think the problem with Nokogiri. Everyone tells you to go install brew or Macports or build it all for yourself from scratch. When you do, you get lots of stuff installed. And that stuff affects the compilation process. I'm about 80% certain that I can't compile Nokogiri with system libraries because other projects have dropped include files that rename iconv_open to libiconv_open - which isn't in the native library. I have Nokogiri compiling now, but only as a result of using GNU iconv, and using the arcane "bundle config" to set up a build time dependency for nokogiri alone to use the /opt/local/include version of iconv. That was time consuming.
So, some advice that I haven't taken for myself yet. Clean out the brew/ports stuff. I suspect that you can run anything you need to, in locally installed project directories, rather than interfering with the OS. Unless you really need something that doesn't ship with a Mac, like an up to date ruby (solved by rbenv/rvm)
Look into Heroku. Low cost way to get started with publishing your small apps.
Make sure you have GitHub and BitBucket accounts. Personally I contribute to projects on GitHub, but my private stuff is on BitBucket - pricing models.
Git looks mad. But git is wonderful. Learn to branch. Lots. Learn to merge. Learn to tag, and learn how to push and pull from an upstream repo. These words may mean nothing to you now, but they will save your sanity. You'll use git to push your projects to Heroku. Just freaking amazing. Learn how to have a staging branch and a live branch, and push each to a different Heroku instance, so you can be testing user acceptance on a public facing server, without contaminating dev or live versions. Git/Heroku. Joyful.
Watch out for several things that bit me... Ruby gets lots of patches. They are meaningful. I spent days trying to work out why a piece of ruby code failed, only to discover it worked in a different patch level. Watch for the updates and apply them - except for 'bundle update'. Don't do 'bundle update' until you are old and wise.
Gem versions - that also bit me. Got a project that worked. Then it didn't, with no code changes at all... except that I'd updated my gems. A later version of a gem upset the code. So...
Bundler is your other friend. Lock down the versions of gems that you need for a project. Don't use "bundle update" unless you are prepared for strange things to happen. Make nice Gemfiles.
You probably need to get to grips with TDD and preferably BDD.
So next thing you need is to get the Qt library installed, and use "gem 'capybara-webkit'" and Cucumber with Rspec-Rails to help you write tests that the browser will execute. Butt saver central, if you start changing gem versions. At least you know when the tests stopped working, and can use git to revert to a known working chunk. More importantly, it saves, eventually, a lot of tedious checking around when something unexpectedly stops working.
Also... make sure that your development group of gems (in Gemfile) includes "better_errors" and "binding_of_caller". A REPL in the browser pane when your code fails, is wonderful.
If you want to just throw some stuff together, e.g. office admin projects that you don't want to spend a load of time refining the UI on, but just build something that works. Try 'hobo'. I find it very useful for rapidly building something. Faster to code it than to spec it or draw it. Seriously. And it is all over-rideable, though I've never turned any Hobo code into something for high scaled usage...
Welcome to the amazing world of developing in Rails, on a Mac. It's a rapidly evolving hoot. Hope that helps. :)

do I have to restart apache after updating ruby in order to make passenger restart?

I need to update ruby in the system. It is a minor update and I'll do that by installing a new ruby RPM that has a new patch on it.
My question is, do I have to restart apache after updating ruby in the system? Or is it another way to make passenger reload ruby?
I've tried running a page that outputs the RUBY_VERSION, RUBY_RELEASE_DATE, RUBY_PATCHLEVEL in order to check that, but it does not work for me because the update is a new patch in the RPM, not in ruby itself, so that those constants are the same for the old and new version.
thanks
No, you don't need to restart the whole Apache.
You need to restart your application though.
Passenger has an easy way to tell the application to restart : create a restart.txt file in the tmp directory inside your application.
The application will be restarted the next time a request is made to it.
So you might want to automatically request your application after deploying to force the restart.
I am pretty sure that, at least in passenger 3, you do need to restart apache.
After installing the new ruby, you need to re-install the passenger apache module, linked to your new ruby, (passenger-install-apache2-module), then you need to take the apache config lines that it shows you after installation, and edit your apache config file to include them (replacing the old lines pointing to your old ruby), then you need to restart apache.
Now, it's possible there's a different way to do this without restarting apache for Passenger 4 (still not official final release, but in RC). Passenger 4 has some features for a passenger running multiple rubies simultaneously that might end up allowing this sort of thing too; I'm not sure, I haven't looked into it much. But I think with Passenger 3 (the existing stable Passenger, that most are probably still using), you've got to do as above.
You can restart a specific app running under passenger with a restart.txt like Damien MATHIEU says in a different answer. But to change the version of ruby that passenger is running under and starting apps under -- I'm pretty sure you need to restart apache (after first reinstalling the apache passenger modules, and changing the passenger apache config)

Rails 3.1 application deployment tutorial

I'm looking for a good deployment tutorial for a Rails 3.1.1 application on a server. And by good I actually mean complete. The reason I'm posting this question is that although there are tons of tutorials out there on the web (google, blogs, books, other stackoverflow questions etc...) all of them seem to focus either on a problem with the deployment process or make some assumptions about the deployment environment that do not match with what I need.
I realize that deploying a Rails app on a server requieres a variety of different programs and tools that need to be configured and somehow I always get stuck on apparently "little" things that make me very frustrated.
So, let's begin from the start. What I have now is a server that I can access through SSH and a domain name, let's call it www.example.com. The server runs a fresh Ubuntu 10.04 x64 and has just a user installed, namely root (through root I access the server with SSH).
Note! There is no Apache, Ruby, PHP, MySQL, cPanel or any other panel installed, just the bare minimum that comes with a fresh installation.
Also the web server will host a single application and the database will run on the same machine.
From my knowledge the process of deploying a Rails application follows the following scenarios:
Installing Ruby
I already did this by using RVM using the Multi-User install process (simply because I have just the root user and it does it automatically). This seems to work fine aftewards but I do have some questions:
Would it make more sense to install Ruby directly and not through RVM (I'm thinking maybe in terms of efficiency - also RVM does a little bit of magic behind the scences modifying some bash_profile files in ways that I don't understand and this somehow seems invasive...)?
Would it make more sense to install as a separate user through RVM (can there any safety problems arise)?
Necessary gems
Now that Ruby is installed what would be the best initial set of gems to install along side it?
I installed just bundler, so that once I upload my application on the server I can run a bundle install command which will install in turn the required app gems.
Question - Should I install the rails gem before hand? Are there any other gems that need to be installed?
Web server
This is where it gets tricky for me. I'm trying to use apache and mod-passenger for deployment (they seem to be the most popular). So I installed the apache web server and the passenger gem and all the related dependencies (libraries mentioned by passenger).
Now, the problems arise. First thing is user related. How does Apache run? I mean under each user? If I installed it and (re)started it using the root user, will it permanently run under the root user? Is this a bad thing? If yes, should I create another user? If yes, how? In what groups should I put the new user in, what rights should he have (namely what folders should he have access to). How to start the apache in this case (under root, under that user, add a line somewhere in the configuration file, etc.)
Website configuration
Where to put the website configuration stuff? Is it OK to put it into apache.conf, or should I create a new file in sites-available? Or should I simply reuse the default file that is already present there? If a new user has been created at the previous step, what rights should he have in relation to the config files?
Also... where to eventually put the rails application? In what folder would it be best? Somewhere under home? Maybe under /var/www? I want to know how would this affect the rights of the apache process serving the app? (Generally I have problems while serving an app, it complains that it doesn't have rights on a specific folder. Also, using the new asset pipelines - which I don't fully understand - asset files are being created and they seem not to inherit the parent folder rights...)
Database
As database I'm using MySQL and installing it is pretty straightforward. The question that I have here is again user related. Should I use a special user for the database? How does MySQL actually manage users (are they internal, or are they the Linux users or ...?). Should the database user be the same as the "web user" from above? Or should it be a different one?
Assets
Here I get really lost. I really have troubles making the assets pipeline works. I've checked the railscasts episode and also the rails website tutorial and I do seem to theoretically understand the thing, yet I have problems in practice.
So the questions here would be - what commands should I run to precompile the assets? (Trying to run rake assets:precompile). Is it ok? What should I change in the production.rb file? How do the assets generated work in relation with the webuser or database users created above? I am personally getting a problem in this step namely the log files say that some css files are not accessible (for example I have jqplot library installed under the vendor/assets folder and its files cannot be accessed - should I add a manifest file here somehow?).
It would be really great if someone could point me towards a nice article, or resource that explains all this stuff. The main area which I'm having problems in is how does Apache, Passenger, Ruby, Rails and MySQL interact with a Linux user. How to properly set up the permissions for the Rails app folder? How does the assets pipeline affect this user permission stuff?
Thank you
Here's my way of deploying Rails:
Installing Ruby
I would not use RVM because it's very tricky to get it running properly in combination with stuff like cron jobs. Doable (with wrappers for example), but a bit of a hassle. If you don't need other Ruby versions on that machine, just install it from source yourself.
Gems
Just let Bundler work its magic. Remember to install with the flags --without test development --deployment. I wouldn't do that up front though. Just make sure you have bundler.
Web server
Using Passenger (with either Apache or Nginx) is a fine and easy choice. When you install Apache from apt, it will run in a special user.
Apache is configured correctly automatically on Ubuntu. It will start on reboot.
Website configuration
All configuration be in /etc/apache2. Place your virtual host configuration in /etc/apache2/sites-available and use a2ensite to enable it.
Put your app in /var/www, since that is the default location in Ubuntu. I usually make a deploy user.
Make sure that user can access your application by assigning your app to the www-data group.
Database
MySQL has its own user system. Log in as root user and create a new user with SQL: GRANT ALL ON 'application_production'.* TO 'deploy' IDENTIFIED BY 'some password';
Assets
Assets should be generated as the user owning the application. You should add any css and javascript files to production.rb. For example:
config.assets.precompile += %w(backend.css)
Conclusion
It helps to use a deploy tool like Capistrano. When you run capify, uncomment the appropriate line in the Capfile to get assets compilation. Here's mine:
ENV['RAILS_ENV'] = 'production'
load 'deploy' if respond_to?(:namespace) # cap2 differentiator
load 'deploy/assets'
load 'config/deploy'
require 'capistrano/ext/multistage'
require "bundler/capistrano"
require 'capistrano_colors'
This is just how I normally install my rails apps. I hope this will get you going. Recently I've written a gem for integrating Chef-solo with Capistrano, called capistrano-chef-solo. It's very alpha and might be a bit too complicated if you're just starting with deployment, but it might help you.

Rails sprocket Error compiling CSS assest - CHOWN issue

I've been breaking my head over this for over 2 days now, and can't seem to figure out where the problem is. This is mostly a problem related to my setup, but if anyone could help me find a solution to this problem, then I'll be his slave for eternity..!
I'm running Snow leopard(host) and VMware fusion running Ubuntu Lucid server (guest OS). Somehow after a lot of head-banging I managed to get my workspace shared from Mac to Ubuntu. So, essentially I've been able to isolate my dev environment on a VM, which makes it easy for the entire dev team to be on the same environment irrespective of their host OS / setting, etc. While, it certainly has made everything easy, I'm stuck with a specific problem occurring due to sprockets (I guess). Every time I make changes to my stylesheets and reload, I get this error:
Error compiling CSS asset
Errno::EPERM: Operation not permitted - /mnt/hgfs/banjarey/tmp/cache/assets/DCF/780/sprockets%2F5f78b3457def1d02bd3fb75d4e0cfb63
/home/coderboy/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-3.1.0/lib/active_support/core_ext/file/atomic.rb:38:in `chown'
The strage thing though is that if I reload the page twice or thrice, the css compiles and everything works alright.
It's a real shame to be reloading the page twice or thrice for every single css change I make. I've played around with memberships and permissions a little bit, but been an amateur I've not ventured deep enough I guess.
Any idea folks ??
I have the same problem. my solution is to modify the File Permission after precompile assets:
#chown apache.root yourapp -R
#chmod 755 yourapp -R
A bit late with this answer, but chmod everytime the app is deploy does not seem to be a good solution. I think the issue is your apache instance and your passenger instance are running as different users. So the solution is to check what user your apache server is running as and set the PassengerDefaultUser,
For example:
PassengerDefaultUser www-data
This worked for me. As Passenger was making files only readable by nobody, weird is that if you just refresh a few times it some how works out, but making sure they are the same user stops this error.
I experienced the same error, but in development!
Solved after clean and recompile assets:
rake assets:clean && rake assets:precompile
Make sure the underlying file system supports the requested operation.
The following commands fixed it for me.
mv public/assets /tmp
ln -s /tmp/assets public/assets

My Rails app is returning HTTP 500 for all its URLs, but nothing shows up in the log file. How can I diagnose the problem?

I have a Rails app that is running on a production server with Apache and Phusion Passenger. The app works fine locally when using Mongrel, but whenever I try to load a URL on the production server, it returns HTTP 500. I know the server is working properly, because I can get the static elements of the application (e.g., JavaScript files, stylesheets, images) just fine. I've also checked the Passenger status and it is loading the app (it must be, since the app's 500 Internal Server Error page is returned, not just the default Apache one). Also, when I load the app via script/console production and do something like app.get("/"), 500 is also returned.
The problem is that there is nothing in the log files to indicate the problem. production.log is empty. The Apache error logs show no problems with Apache, either. I'm stumped as to what's going on and I'm not sure how to diagnose the problem.
I know I may have been a bit vague, but can anyone give a suggestion on what the problem may be? Or at least a way I can go about diagnosing it?
The answer for this specific situation was a problem with my app. One of the model classes used a different database connection than the rest of the app. This database connection was not configured properly. I think the reason why nothing was written to the log files is that Rails bailed out without having any idea what to do.
Since it may be helpful for others to see how I diagnosed this problem, here was my thought process:
The issue couldn't be with Apache: no errors were written into the Apache log files.
The issue probably wasn't with Passenger: Passenger wasn't writing any errors to the Apache log file, and it seemed to be loading my app properly, since passenger-status showed it as loaded and it was display my app's 500 Internal Server Error page (not the default Apache one).
From there I surmised that it must be something broken in my app that happened very early on in the initialization phase, but wasn't something that caused the app to completely bail and throw an exception. I poked around in the Phusion Passenger Google Group, and ultimately stumbled upon this helpful post, which suggested that the error may be a database connectivity issue. Sure enough, removing this misconfigured database and all references to it made the app work!
Have you tried running the app locally using Passenger?
Try running the application locally on Mongrel in Production mode, to make sure that there's no weird issues with that particular environment. If that works, then you know that it's not an issue with your codebase. Since your static components are being served properly, that tells me that Apache is working fine. The only gear in the system left is Passenger. At this point, I would say it's an improperly configured Passenger. You should post up your Passenger config file, and ask the question on ServerFault.
A couple of things to try :
Have you gone though the following from the docs:
6.3.7. My Rails application’s log file is not being written to
There are a couple things that you
should be aware of:
By default, Phusion Passenger runs Rails applications in production
mode, so please be sure to check
production.log instead of
development.log. See RailsEnv for
configuration.
*
By default, Phusion Passenger runs Rails applications as the owner
of environment.rb. So the log file can
only be written to if that user has
write permission to the log file.
Please chmod or chown your log file
accordingly.
See User switching (security) for details.
If you’re using a RedHat-derived Linux
distribution (such as Fedora or
CentOS) then it is possible that
SELinux is interfering. RedHat’s
SELinux policy only allows Apache to
read/write directories that have the
httpd_sys_content_t security context.
Please run the following command to
give your Rails application folder
that context:
Have you checked your vhost or httpf.conf file ? Do you have any logging directives ?
Check the top level apache log file
Try setting PassengerLogLevel to 1 or 2 or 3, as shown here http://www.modrails.com/documentation/Users%20guide.html#_passengerloglevel_lt_integer_gt
Do you have any rack apps installed ?
My suggestion would be to go right back to "Hello World" land and create the smallest possible Ruby example application and upload it to see if there is a problem with Passenger or Ruby on the server.
May be a silly suggestion but I suggest you start by increasing the logging levels on production while you are testing. Do this in config/environments/production.rb and use:
config.log_level = :debug
This should at least get you some sort of backtrace so you can start to find the problem.
If you still get nothing - you may find that you have an issue with something as simple as a missing gem/plugin on your production server. That sort of thing may well manifest as a "500" error and just not be very verbose for you.
Can you run the test suite on your production server?

Resources