grails.server.port has no effect anymore in BuildConfig.groovy
should always pass
-Dserver.port=XXXX
Grails version 2.1.1
It is
grails.server.port.http = xxxx
not
grails.server.port = xxxx
But there are something further to be checked:
If you deploy the app upon Unix platforms, all ports below 1024 can only be accessed by root user. Otherwise you will get an error like Error Server failed to start for port 80: Permission denied
The redirect() method uses the grails.serverURL config setting to generate the redirect URL. You may need to remove the setting, particularly from the development and test environments.
Related
Is it possbile to have Rubymine connect to (and restart) an installed/running instance of Puma-dev for the debugging session?
I use Puma-dev to test my Rails app on "Appname".test, yet if I need to debug something in the app and want to use Rubymine's built-in debugger, I can only let it start an additional instance of Puma on Port 3000 (or whatever Port I choose) but not the already running Puma-dev on port 80/443.
Is it at all possible?
This is possible with remote debugging. To configure, you have to make some changes to your app:
Add export RUBY_DEBUG_PORT=1234 to .env or .powenv or any file puma-dev will load an environment variable from. Feel free to use whatever port you'd like, although RubyMine uses 1234 by default.
Add the ruby-debug-ide and debase gems to your project's Gemfile.
Add an initializer to your project to initialize remote debugging, like so:
if Rails.env.development? && ENV['RUBY_DEBUG_PORT']
Debugger.start_server nil, ENV['RUBY_DEBUG_PORT'].to_i
end
Restart puma-dev.
Go to Edit Configurations in RubyMine and add a "Ruby remote debug" config. Name it whatever you'd like. Change the port to the port you set via RUBY_DEBUG_PORT. Set your local and remote root folders to your project root.
Select your newly created configuration and click the Debug button. It should connect to the debugger running in your puma-dev process.
We're using Passenger 4.0.59 behind Apache 2.2 (CentOS 6.latest) with Rails 3.2.
In /etc/httpd/conf/httpd.conf we have:
TraceEnable off
We have one virtual host configured in httpd.conf and a second virtual host configured in /etc/httpd/conf.d/ssl.conf that's configured with Passenger.
I'm using commands of this form to test:
curl -I -X {method} https://{host}/{resource}
...and seeing the following behavior:
When I TRACE a static image over http, i.e. http://host.domain.com/images/foo.png, I get a 405 response (as expected).
When I TRACE the same static image over https, meaning it goes through the virtual host configured with Passenger, I get 405 (as expected).
However, when I TRACE a Rails service in our app, e.g. https://host.domain.com/status.json, I get a 200 response w/ valid data.
I would expect Apache to shut down the request and return a 405 response before it even gets to Passenger/Rails, but that isn't happening.
What am I missing / misunderstanding?
What am I missing / misunderstanding?
TraceEnable off is the correct directive to use, but you may have another TraceEnable directive elsewhere in your configs.
You should check all of your apache config files to be sure there is no other TraceEnable directives.
Since the TraceEnable directive can be used within either the server config or the virtual host config, so you may just want to add it to both.
We have a Ruby v.2.0.0-p247 on Rails v4.0.1 application using pg gem v0.17.0.
The application runs smoothly under Mac OS X Mavericks v10.9 with PostgreSQL Server v9.2.4 installed using HomeBrew but it throws the following exception under Ubuntu v13.04 using PostgreSQL Server 9.1:
PG::UnableToSend: server closed the connection unexpectedly
This probably means the server terminated abnormally before or while processing the request.
The exception occurs after transactional queries (form submission).
I tried the following with database.yml:
Adding reconnect: true
Adding port: 5432
Adding socket: /var/run/postgresq/SOCKET_FILE
And tried the following with PostgreSQL configuration under Ubuntu:
Disabling SSL.
Changing TCP keepalives parameters to pump timeout.
Changing log level to DEBUG and search for possible errors on PostgreSQL Server.
Also tried:
Downgrade to pg gem v0.16.0.
Update all Ubuntu 13.04 packages to latest versions.
What could possible be wrong?
UPDATES:
12/03/2013: Some suggested checking firewall settings. ufw status said that ufw is disabled.
12/08/2013: After trying out with a vanilla Rails app and a lot of mangling with the current application, the problem is originating from rails4/activerecord-session_store gem. Line 47 in lib/active_record/session_store/session.rb is the culprit.
This basically happens when you use an old version of launchy , and as per this issue on launchy's git repo quoting #infertux
In the rare case when exec fails to run the command - typically when the file cannot be opened raising Errno::ENOENT - Launchy would raise an exception but not showing any output
You can check your Gemfile.lock to see if you're using a version of launchy below 2.4.1, and I doubt that you're using letter_opener Gem in your development environment which depends on launchy so updating letter_opener to 1.2.0 will update launchy to a version above 2.4.0 mostly 2.4.2 which has this issue fixed
All credit goes to #infertux
It would really help if you provided your database.yml file
The default connection method is a unix domain socket, not to be confused with a TCP/IP socket. The unix domain socket connection method is used by default.
You should check that the unix user that you are trying to run rails under has sufficient permissions to access the domain socket (typically at /var/run/postgresql/.s.PGSQL.5432)
Try typing the following as your rails user:
psql
If you get a database connection error then its likely a permissions problem if postgres is actually running.
You can check your /etc/postgresql.conf file and have postgres configure the group and permissions on the socket when it starts:
unix_socket_directory = '/var/run/postgresql' # dont worry if yours is different
#unix_socket_group = '' # default is usually ok
#unix_socket_permissions = 0777 # uncomment this if needed
Another option is to add the user to the group that has write access to the socket, vs allowing all users on the machine access with the 0777 permissions setting above. You may want to create a postres_users group for this purpose if the default Ubuntu groups provide insufficient granularity for your needs.
It looks to me like there's confusion about the connection method. PostgreSQL supports the two methods:
Socket
TCP/IP
These are completely, utterly different. :-)
In your question, you show a socket setting, but mention TCP. I suggest to focus on each of these two ways of connecting in isolation and see which produces results. I.e., create two version branches pg-socket and pg-tcpip just to make things clear. Then, clean up your config file and attempt to connect via both methods.
Often, a socket connection is easier because you just need to know the pathname of the socket "file". No fireware settings are necessary (because no TCP/IP networking is involved.)
Update your question after doing this and tell us how each of the two methods did for you.
Have you set keepalives as specified here http://www.postgresql.org/docs/9.2/static/libpq-connect.html#LIBPQ-PARAMKEYWORDS similar issue was solved with it at: https://bitbucket.org/ged/ruby-pg/issue/170/pg-unabletosend-connection-timed-out
I have a grails 2.2.1 app with mail plugin 1.0.1.
Mail delivery via Gmail smtp server works fine when I run the app locally (grails dev run-app), but fails on the production server (which is on the Jelastic cloud platform), which I deploy as a war file.
Config.groovy:
// Mail
grails {
mail {
host = "smtp.gmail.com"
port = 465
username = "aut********#gmail.com" // *** = just blacked out
password = "sun1******" // *** = just blacked out
props = ["mail.smtp.auth":"true",
"mail.smtp.starttls.required": "false",
"mail.smtp.socketFactory.port":"465",
"mail.smtp.socketFactory.class":"javax.net.ssl.SSLSocketFactory",
"mail.smtp.socketFactory.fallback":"false"]
}
}
But I only have one mail plugin configuration, and therefore assume that the config applies for both development and production environment.
In fact, when I unzip the war file and check the class (in my case: Config$_run_closure2_closure8_closure13.class) via Decompiler, I can see the correct config values in there:
Enlarged: http://i.troll.ws/638ef33d.png
Error message:
Caused by: org.springframework.mail.MailAuthenticationException: Authentication failed; nested exception is javax.mail.AuthenticationFailedException: 535-5.7.1 Username and Password not accepted. Learn more at
535 5.7.1 http://support.google.com/mail/bin/answer.py?answer=14257 d47sm23030880eem.9 - gsmtp
at grails.plugin.mail.MailMessageBuilder.sendMessage(MailMessageBuilder.groovy:104)
at grails.plugin.mail.MailService.sendMail(MailService.groovy:41)
at MailGrailsPlugin$_configureSendMail_closure6.doCall(MailGrailsPlugin.groovy:170)
at com.oritrack.core.ApiController.register(ApiController.groovy:212)
... 5 more
Caused by: javax.mail.AuthenticationFailedException: 535-5.7.1 Username and Password not accepted. Learn more at
535 5.7.1 http://support.google.com/mail/bin/answer.py?answer=14257 d47sm23030880eem.9 - gsmtp
at com.sun.mail.smtp.SMTPTransport$Authenticator.authenticate(SMTPTransport.java:648)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:583)
at javax.mail.Service.connect(Service.java:291)
... 9 more
It is so weird that the authentication fails; so it's at least trying to connect to the right server; and the username/password in the Config.groovy is the only set of mail plugin config that I have in there. If it runs locally, it gotta run elsewhere.
When something works in development and not in production the usual culprit (from my experience) is dependencies. Check your WAR for multiple version of the same jar e.g. java-mail-1.0.jar and java-mail-1.2.jar. Don't limit your search to java-mail.jar, that was just an example.
If you find multiple versions of one jar, try removing one and deploying your war and if it works... huzzah!
To find what plugin is bringing in the jar use "grails dependency-report". Once you find out what is bringing in the jar you can remove it by doing something like this in BuildConfig.groovy using the excludes syntax.
dependencies {
compile("org.apache.shiro:shiro-quartz:1.1.0") {
excludes("quartz")
}
runtime('org.codehaus.groovy.modules.http-builder:http-builder:0.5.0') {
excludes 'xalan'
excludes 'xml-apis'
excludes 'groovy'
}
}
I have solved some very strange errors like this, one of them including http authentication that was failing due to multiple http-client jars.
I am trying out TorqueBox and having issues with my deployment descriptor. I'm using 2.0-beta2 with jruby-1.6.5. When I deploy to using the torquebox deploy command, the application gets deployed within the application server; however, it is always at the root context (/) instead of the context I am specifying within my config. Here is my config/torquebox.rb:
TorqueBox.configure do |cfg|
cfg.environment do
RACK_ENV "qa"
end
cfg.web do |web|
web.host "localhost"
web.context "/my_application"
end
cfg.ruby do |ruby|
ruby.version "1.9"
end
end
I tried it with and without having the host defined as well, and nothing changed. Its interesting because I know that its reading my config as I see the following within the run log:
14:53:00,497 INFO [org.torquebox.core] (MSC service thread 1-2) evaling: "/Users/ejlevin1/Documents/Workspace/my_application/config/torquebox.rb"
However, I feel like the line within the log a few lines down is showing it isn't honoring my context:
14:53:01,499 INFO [org.torquebox.core.runtime] (Thread-95) Creating ruby runtime (ruby_version: RUBY1_9, compile_mode: JIT, app: my_application, context: web)
Does anyone know what I am doing wrong? I tried deploying 2 applications to see if the server only honored this in the case of multiple applications running; however, that just gave me an error that seemed to be because they were both mounting off of root (/).
I think what's happening is your "external" descriptor is overriding your "internal" one. Your internal one is what you have above. But the 'torquebox deploy' command generates an external descriptor that tries to deploy your app at the root by default. Try running 'torquebox deploy /path/to/your/app --context-path=/my_application'