When using the moin.fcg (appropriately adjusted for the installation)
from version 1.9.6, the fastcgi process fails to start correctly.
The failing process logs the following on start:-
WSGIServer: missing FastCGI param REQUEST_METHOD required by WSGI!
WSGIServer: missing FastCGI param SERVER_NAME required by WSGI!
WSGIServer: missing FastCGI param SERVER_PORT required by WSGI!
WSGIServer: missing FastCGI param SERVER_PROTOCOL required by WSGI!
Any idea why it doesn't work?
I can't help much with fastcgi stuff as I personally just use apache2/mod-wsgi (doing WSGI directly is much simpler), but the error you get is rather clear: wsgi needs that stuff noted in the log output. Maybe you need to configure your server to provide that.
BTW: this is in no way moin specific, so you maybe should rather ask how to make any WSGI application work with your server and fastcgi (moin uses flup as adapter).
If you find out that something provided in the moin download archive is wrong or could be improved, please contact us.
Related
I have a Ruby on Rails application that runs under puma v4.3.8. It currently allows a number of weaker TLS ciphers. The application has a config/puma.rb file. I've tried to use ssl_cipher_filter to enforce stronger ciphers.
From what I can see the puma code evals the contents of the config file, which seems ripe for exploitation but that's another discussion. I know I'm editing the correct file because if I put a coding error in it the application fails to start.
I've tried a number of approaches in the puma.rb to set the ssl_cipher_filter and ssl_cipher_list but none of them have had the desired affect, here's a few of those attempts:
ssl_bind('0.0.0.0','443', {ssl_cipher_filter: "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA"})
and
#options[:ssl_cipher_filter]="AES#STRENGTH"
and
#options[:ssl_cipher_list]="TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA"
I am using nmap to check which ciphers are supported using the following command
nmap --script ssl-enum-ciphers -p 443 myapp.mydomain.com
I've yet to see any change in the list of ciphers accepted.
Can anyone help me put the correct configuration in place to limit the ciphers offered by puma?
This worked for me, adding this option on puma.rb configuration file:
ssl_cipher_filter: '!aNULL:AES+SHA'
Is is mentioned on https://github.com/puma/puma#controlling-ssl-cipher-suites
I'm trying to deploying a Rails website via passenger+nginx. However, I got the error below when I try to visit the webpage.
These are the possible causes:
There may be a syntax error in the application's code. Please check for such errors and fix them.
A required library may not installed. Please install all libraries that this application requires.
The application may not be properly configured. Please check whether all configuration files are written correctly, fix any incorrect configurations, and restart this application.
A service that the application relies on (such as the database server or the Ferret search engine server) may not have been started. Please start that service.
Further information about the error may have been written to the application's log file. Please check it in order to analyse the problem.
Error message:
**Could not find activesupport-3.2.9 in any of the sources (Bundler::GemNotFound)**
Exception class:
PhusionPassenger::UnknownError
I ran bundle install in the website' folder and see all of the gems are installed successfully including activesupport-3.2.9, then I ran rails server, I'm able to visit the webiste via 3000 port. This should prove there's no critical bug of this website code.
Here is what I added to nginx.conf file:
server {
listen 80;
server_name localhost "";
root /var/www/mysite/public;
passenger_enabled on;
}
I don't know what more I should check to solve this. Your help will be greatly appreciated!
I think you probably need to configure passenger.conf to point to the same ruby version that you are using to run your bundler - try running the passenger config utility:
passenger-config --ruby-command
See: https://stackoverflow.com/a/17088686/1578861
I am using rails(2.3.10)/passenger(2.2.15)/nginx(0.7.67) , when i run my application, it give me "502 Bad Gateway" and without any production log, my conf file is :
1 server {
2 listen 80;
3 server_name www.why.bz;
4 root /usr/local/apps/why/pro/public;
5 access_log /usr/local/apps/why/pro/log/access.log;
6 passenger_enabled on;
7 }
who can give me some tips, thanks!
I've done Rails deployments full-time for the last couple of years, so hopefully I can help. You've probably figured this problem out by now, but here are some questions to think about for next time:
Since this is a Ruby on Rails application, can you tell where the error is coming from: Nginx or Rails itself? That sounds more like a Nginx issue, but it would be good to know. A quicky peek into the Rails production.log or Nginx's error_log should elucidate this info.
How are you connecting to the application: web browser or command line? Is the IP and hostname set correctly (try the Linux "dig" command to verify)? Are you trying to hit http://localhost:80 ?
There are error log commands that nginx takes that could be configured to help you debug the issue (much like the access_log line): http://wiki.nginx.org/CoreModule#error_log
Lastly, verify the permissions that are set on your web files: The nginx web server needs to be able to access them. At least "read" permissions are needed.
Good luck,
Harmon
change it to
listen 443;
it could be as simple as that.
It could be that your secret key base is missing for the required stage.
One thing that I sometimes forget, especially if I don't start with a staging environment and then add it later, is to add the following to my secrets.yml file:
staging:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
This is telling Rails to get the secret_key_base value from the environment variable, SECRET_KEY_BASE. You must specify this variable by placing this in your nginx configuration:
passenger_env_var SECRET_KEY_BASE yoursupersecretkeybase;
If you don't have a SECRET_KEY_BASE, you can generate one with:
bundle exec rake secret
Let's say I have the following entry in my grails URLMappings.groovy:
"/actionName/param1"(controller:'myController', action:'myAction')
When I call an URL where param1 includes + as a special character, the URL is encoded correctly to /actionName/my%2Bparam for example, both in my local and in my server environment.
In my local environment - also using "prod" as the environment parameter - this is correctly resolved to my+param in the controller. However in my "real" production environment (Amazon Web Service EC2 instance), the URL is resolved to "my param" which is wrong.
I have no idea what the reason for this could be. Both environments use TomCat, and as stated above I'm even using the prod environment settings in my local environment so it can't be a differing configuration between development and production.
Does anybody have an idea where I could dig deeper to identify the problem?
Is the EC2 instance running Apache in front of Tomcat? I've had issues before with params being decoded twice, once by Apache and then again by Tomcat. From memory, I think I adjusted the configuration of the ProxyPass directive in Apache to correct it.
EDIT:
I found the following instructions I'd left with the source code for my app :)
Apache httpd.conf additions
AllowEncodedSlashes On
ProxyTimeout 3600
We also upgraded apache 2.2.12+ to fix HEAD > GET rewrite bug using a startup shell script.
I also added 'nocanon' option to ProxyPass directive to stop auto decoding by mod_proxy in /etc/httpd/conf.d/cluster.conf
I think I had to do this on the server as you can't modify this using the GUI. I also have a note that says it causes they query string to be encoded. Perhaps I had to add an extra decode in my app to handle this (sorry can't remember for sure!)
Tomcat startup parameters
-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true
-Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true
I think this was to get tomcat to handle slashes correctly
cheers
Lee
That's a known bug that has been introduced in Groovy 1.3.4 or few build versions before. It has been fixed in current version 1.3.5.
this is correctly resolved to my+param
in the controller
No, the expected resolution is "my param" (with a space).
As that works at the Amazon host, you'd upgrade Grails to 1.3.5, locally.
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?