I'm running Rails 3.0 with a custom Devise authentication strategy that makes an SSL call using Curb. I get an "Curl::Err::HostResolutionError (Couldn't resolve host name)" error. Works fine manually from the command line.
The production environment is Apache running Passenger standalone with rvm 1.9.2#rails3, because the main Passenger is running ruby 1.8.7 and rails 2.3.4. I don't get this error with the my other app running the earlier versions of ruby and rails. Same code, but the difference seems to be Devise.
I've read elsewhere that this might have something to do with DNS and Apache, but I can't for the life of me figure this out and I'm really grasping at straws here. Any ideas would be greatly appreciated! Thanks in advance!
The issue actually turned out to be related to user permissions. When I ssh in with my user account and start Passenger standalone, no problem. When I start it remotely from Capistrano with the deploy user I get the error.
Related
I'm trying to get my homework done in Ruby on Rails, but I have already faced dozens of problems because of my lack of UBUNTU (16.04.1) knowledge.
I have installed all the required gems and other clients like MySQL2, Apache2 and Puma. Puma is running, I have two standard tables in MySQL, but there is some issue with my Apache2 connection. I can access localhost:3000 (it says: Yay! You are on rails now!), but I just cannot reach my custom URL-s, that are located in the 'hosts' file.
Could any of you help me with getting started? I could blow my top because I have a lot of work to do and I cannot get through the basic steps of installing the environment...
Thanks in advance!
As we (finally) port our apps away from Ruby 1.8.7, I am trying to set up Phusion Passenger and Apache, with RVM, to serve apps using both Ruby 1.87/Rails 2.3.x and Ruby 1.9.3/Rails 3.2.x. This is all on my development machine; in production we us separate VMs to serve the two different platforms--but needless to say, that would be inconvenient in development.
The Good: I've got Passenger 3.0.7 installed using Ruby 1.8.7 (and RVM), and 1.8.7/Rails 2.3.x apps work great as they have in the past (the only thing changed from my past setup is having (re)installed Passenger via RVM).
The Bad: I also have installed Passenger 4.0.20 as a gem using Ruby 1.9.3 (and RVM), and if I configure Apache to use them, it is able to serve up a 1.9.3/Rails 3.2.x app just fine. But Passenger can't serve the Ruby 1.8.7/Rails 2.3.x app.
Another developer here has essentially the same setup working but we are unable to see any clear differences between her installation and mine. But her success tells me it is possible.
The Ugly: When I try to run the 1.8.7/2.3.x app with Passenger 4.0.20, Passenger logs a bunch of output to the Apache error.log, including these lines:
[ 2013-10-22 13:12:30.1770 21240/7fe89ad0e700 Pool2/SmartSpawner.h:301 ]: Preloader for /home/username/workspace/app started on PID 21284, listening on unix:/tmp/passenger.1.0.21232/generation-0/backends/preloader.21284
[ 2013-10-22 13:12:30.2547 21240/7fe89ac8c700 Pool2/Implementation.cpp:1274 ]: [App 21284 stderr] [ 2013-10-22 13:12:30.2547 21385/0x7f9bf1fd0b80(Worker 1) request_handler/thread_handler.rb:197 ]: *** Passenger RequestHandler warning: someone tried to connect with an invalid connect password.
It's the last bit (scroll to the right!) that seems the most bizarre.
Some online searching reveals that Passenger supports some sort of 'connect password' but we are using no such thing. There are few Passenger-related references to 'someone tried to connect with an invalid connect password' outside of the Passenger source code.
I actually have solved this problem, but due to the dearth of references on the web, and my failure to find any mention of the 'invalid connect password' error here on SO, I am posting this to help the next person. I haven't included lots of other log snippets, configuration file contents and the like, because I have already mentioned all the relevant information.
If you think you know the answer, here's your chance to get some more 'reputation'. Otherwise, I'll post my answer in a couple days.
Phusion Passenger author here. The connect password is a security mechanism in Phusion Passenger to prevent unauthorized processes on the local system to connect to the spawned application processes. The connect password is only known to the HelperAgent, the app process and admin tools like passenger-status.
I'm not sure what went wrong in your case. I'd like to analyze your problem more deeply. Could set PassengerLogLevel to 3, trigger the problem, and post the contents of your Apache error log file to the community discussion forum?
I found my answer in a passing remark on the Passenger forum.
Quoting my question, here is the real problem: "I also have installed Passenger 4.0.20 as a gem using Ruby 1.9.3 (and RVM)..."
I was able to solve it by re-installing Passenger 4.0.20 as a gem using Ruby 1.8.7 (and RVM). With this configuration, Passenger is able to serve up both Ruby 1.8.7 and Ruby 1.9.3 applications.
I have read that in addition to its mainly-native code, Passenger uses a bit of Ruby internally, interpreted by whatever version of Ruby it was installed with. Apparently (and wonderfully) this Ruby code is compatible with Rubies as ancient as 1.8.7. Equally wonderful, it will serve up applications with whatever Ruby their PassengerRuby directives specify... but apparently this isn't the case if Passenger is installed using a newer Ruby than the one needed by the application.
Big thanks to the Passenger and RVM teams, and also to Maximilian Herold for solving my mystery.
weird issue. I have passenger installed on an Apache 2 server, and trying to get a Rails application running. First time deploying a rails application, so not really sure what's going on.
Passenger gives me this error:
But the problem is that 1.9.2-p136 isn't even installed on my system. I removed all ruby versions and completely reinstalled ruby with 1.9.3-p448. (I also have 2.0.0 but I default to 1.9.3)
Not seeing how passenger is even recognizing that I am running a build of ruby that doesnt exist on my system.
I'm hoping this is my last obstacle to getting this started. I have dealt with about every issue that I could have trying to get this damn rails app up. I'll tell you, they make up for how easy it is to develop with by making it impossible to deploy.
Thanks all!
1.9.2 is probably the system ruby (or was, at some point). Now, how in the heck Passenger is running on that while simultaneously using gems from an rvm install of 1.9.3...
Anyway, check your Passenger config. Make sure the PassengerDefaultRuby (if present) and PassengerRuby directives are pointing to the correct version; Passenger often gets confused by varying PATHs, and this is especially true with rvm where you may be running a different version in your user shell session than system tools will find on their own.
There's a reason people like solutions like Unicorn, Puma, and Rainbows. ;) Passenger, once you get it compiled and configured, is pretty much fire and forget, but getting to that point can be painful.
I've get an action in my Rails 3 app that I'm pw-protecting with authenticate_or_request_with_http_basic. Working fine on my development machine but it's not prompting for the http_basic user/password on the production server.
The entire production app runs over https/SSL on nginx.
Where do I look to resolve this? Does http basic auth not work over SSL? Or is there an nginx setting I need to look at?
TIA
Not sure if this related to Rails 3.
I just recently had problems running Mongrel 1.1.5 and Rails 2.3.8
Apparently, there is a bug in this set up where our production machine does not prompt for the user name and password (but works locally, because we are using web-brick).
In the mongrel.log we keep getting this error:
Error calling Dispatcher.dispatch #split' called for nil
:NilClass>
/usr/local/rvm/gems/ruby-1.8.7-p174/gems/actionpack-2.3.8/lib/action_controller/cgi_process.rb:52:indispatch_cgi'
/usr/local/rvm/gems/ruby-1.8.7-p174/gems/actionpack-2.3.8/lib/action_controller/dispatcher.rb:101:in `dispatch_cgi'
...
Found the monkey patch needed to fix this Mongrel 1.1.5 and Rails 2.3.8 and it worked for me.
The german site that lead to the solution: http://railssprech.de/ with 2 links for 2.3.8 and 2.3.9.
Here is the 2.3.8 version: http://www.pcoder.net/error-calling-dispatcher-dispatch/#axzz1RknBQso2
The patch explains why this error was occurring. Check the Rails 3 CGIHandler.dispatch_cgi method and see if it the same bug. You may need to extract the Rails 3 out and monkey patch it.
Hope this helps.
BTW: Mongrel 1.1.5 and Rails 2.3.5 works!
if i use ./script/server my app runs fine but when i try to it it through passenger on apache it gives me
Missing the Rails 2.3.5 gem.
if i vendorize rails it seems that it finds it but then it fails for missing gems even though they are in vendor/gems.
ideally, i would not want to vendorize rails or gems for such a reason, but would expect that it picks up gems from my default home location ~/.gems
Sounds like it could be a permissions error or just the fact that passenger isn't running as the user where the gems are installed. Take a look at The user guide and user switching.
See my answer to a similar question "Passenger does not recognize locally installed gem, works with packed gems".