A friends of mine have a shared hosting with many sites hosted. There is ruby on rails, php, xslt/xml sites using mysql or postgress. Today one of the xslt sites displays this error:
Passenger error #2
An error occurred while trying to access '..../config/environment.rb': Cannot stat '..../config/environment.rb': Permission denied (13)
Apache doesn't have read permissions to that file. Please fix the relevant file permissions.
This is, as I Know, a ruby error (*.rb), but there is no ruby app here! And no any config/ catalogue.
The error log says:
(13)Permission denied: /home/..../.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable
The .htaccess file in the htdocs directory is present and have 777 permission for now.
I haven't any idea what does it mean.
I experienced the same problem, Passenger error #2, suddenly and without correlation to any configuration change on my part. I did not add Ruby. I contacted host monster tech support, their level 2 support was baffled.
Confirming that Jaap Haagmans' solution; overriding PassengerEnabled with no from the .htaccess located in public_html works. Thank you kindly Mr.Haagmans.
I think the configuration of either your apache or nginx state that passenger is enabled. Check for a "passenger_enabled on" on nginx or "PassengerEnabled on" on apache in your webserver configuration file. Then disable it on top level or in the virtual host that runs a php website.
You could instead try to put "PassengerEnabled on" in a .htaccess file in the public_html folder (or equivalent, e.g. httpdocs). Also, make sure the .htaccess file is readable (e.g. 644 permissions in Linux), as that's what the error in your error log is saying.
Looks like there are some leaks in the web host's configuration. Passenger (which is like a mod_rails apache extension) is looking to load a particular Rails app's configuration, presumably not yours. If you're doing something important (like an e-commerce site) I'd run far away from the hosting company. Otherwise you'll have to get this resolved through them.
Related
After developing in Rails on a virtual Linux machine, I just recently installed Windows Subsystem for Linux. Before the Christmas weekend, it was working just fine, but as of this morning, when I try and start up my rails server, it gives me the following complaint:
Could not load database configuration. No such file - ["config/database.yml"]
Of course, when I go into my config folder, database.yml is there - just like it was last week. So I'm confused why it can't find the file now when it absolutely could find it before. Is this some sort of WSL quirk that makes the file hard to find for some reason?
This is most likely guesswork, but I assume that there is a permission issue. If config/database.yml has insufficient ownership or read-levels, it may not be found by your Rails application.
For further diagnose, I recommend posting the output of:
# Get permission details for your config
ls -laZ config/database.yml
And maybe some details of which user is starting the Rails application (effectively which user owns the Ruby process).
I am trying to configure Rails production server with Apache 2.2, Passenger 4.0.59 and XSendFile 0.12. Application is deployed via Capistrano.
Deployed application produces (maybe large) PDF to #{Rails.root}/tmp and serves this file using send_file.
The problem is that Capistrano uses symlinks to point to currently deployed version of application. XSendFile on the other hand dereferences symlinks and refuses to serve a file if its real location is outside document root even if it is allowed by XSendFilePath. Apache's error.log states:
(20023)The given path was above the root path: xsendfile: unable to find file: /resolved/path/to/file.pdf
Everything works well when I set PassengerAppRoot and XSendFilePath to the real location of current version of application, without symlinks on the path. But it's OK until next deploy, which requires apache reconfiguration. Not very useful.
How should I configure Capistrano deploy and XSendFile parameters to make it work together?
I tried solutions with ln -nFs described in Capistrano & X-Sendfile and in mod_xsendfile with symbolic links but none works.
I finally managed to make it work. A few tips for the ones who will have problems with XSendFile
I set XSendFilePath to user's $HOME, there are no symlinks on the path to $HOME, so it works. I can accept this from functional and security point of view, but it is obviously a workaround.
Be aware that XSendFilePath is sensitive to paths containing multiple slashes /like//this. I am using apache macros and while concatenatingXSendFilePath parameter from a few macro parameters I put some obsolete slashes. This caused XSendFile to refuse to send files.
Good luck!
I'm new to RoR.
I was able to install Rails and host it in Webrick (Sample App with "Welcome" controller) in my windows.
Now i have a Unix Weblogic Server along with a dedicated domian.
After exporting the .WAR file using Warbler, i accessed the Oracle Admin Console from where i deployed the .WAR file in the dedicated domain. I did all this for the Sample app with only the Welcome controller in it.
But even after deploying the WAR file, on accessing the Domain along with the Port Number (:9002) i ended up with 404 file not found error On looking at the server logs,there wasn't any records relating to any error. The Application must have been deployed properly. I assume that i must have missed out on some basic configurations in the routes.rb or similar files before deploying. Can anyone Guess what are all the possibilities and if possible can anyone help me by pointing to any tuts that cover the Steps to be carried out for configuration before deployment. do i need to install both JRuby and Rails inside the server before depolyment?
I can't really guess with Eror 404 only.
You can try mapping your rails app rack config to a different base_uri.
All you need to do is wrap the existing 'run' command in a map block
try doing this in your rails 'config.ru' file:
map '/mydepartment' do
run Myapp::Application
end
Now when you 'rails server' the app should be at localhost:3000/mydepartment .
Not sure if this will give you the desired outcome, but worth a try.
One more thing you also add this to your config/environments/production.rb and config/environments/development.rb (if on production mode):
config.action_controller.asset_path = proc { |path| "/abc#{path}" }
otherwise when you call your helpers such as stylesheet_link_tag in your views, they will generate links without the "/abc".
Also, find some guides you may refer for good support.
JRubyOnRailsOnBEAWeblogic.
Use JRuby with JMX for Oracle WebLogic Server 11g
Let me know if it is not resolved.
I'm been working on a rails 3.1 app with one other dev.
I've just pulled some of his recent changes, using git. And am now getting a 403 on any page I try to visit.
You don't have permission to access / on this server.
I'm running the site locally through passenger.
Oddly, when I start the app using rails' internal server. I can visit the site at http://0.0.0.0:3000
Looking at the changes in this recent pull, the only files have changed are some javascripts, some html the application.rb, routes.rb and a rake file.
How do I debug this, I'm a bit lost on where to start?
EDIT:
If I roll back to an earlier version the site works, through passenger. Which leads me to believe the problem is within the rails app, rather than an Apache error. Or it could be a permissions thing, can git change file permissions in this way?
IMHO this is a configuration error in Apache or wrong directory layouts. Make sure that the passenger_base_uri still points to the public folder inside your rails project and that there are no hidden .htaccess files which block access. Also verify that your sym-links are correct (if there are any). Also check your Apache error log.
Start by launching your console to see if rails and your app can be loaded.
In your application root directory type :
rails console
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?