Up until now I've been using script/runner to forward bouncebacks to eblast-bounceback#mydomain.com and eblast-bounceback#dev.mydomain.com. However it is no longer working in Rails 4.0. I also can't seem to find a good resource online to illustrate how to do it. I usually get directed to the 'whenever' gem - but that's for cron jobs, not for 'piping to programs'.
So this is essentially what I'm currently doing, but is failing:
|/home/user/rails/dev.www/script/rails runner 'EBlast.receive(STDIN.read)' -e development
How do I get this to work? I'm not on Rails 4.1, I'm on 4.0. FWIW I do not have bin/rails. The above command yields "no such file or directory".
There were actually a few things I needed to do.
The email eblast-bounce#dev.mydomain.com was considered 'unroutable'. At first I figured it was because there wasn't any MX records for the subdomain, so I added one. But then I still got the error. I had manually updated the aliases file in /etc/valiases to pipe to the program using a symlinked directory (because I was deploying with Capistrano, and the directory ends up changing after every deploy). Turns out symlinks don't work for some reason when it comes to exim routing (/home/me/rails_deployments/dev.www/current/bin/rails fails). Maybe I'm wrong about the symlinks thing but the problem went away when I used the solution below.
This problem however was solved when I eventually came to another problem (/usr/bin/env: ruby: No such file or directory). I'm using RVM to manage rubies/gems, and apparently the email forwarder didn't know what ruby was. This leads to the final solution:
(when in cPanel, "pipe to program" assumes the user home directory (/home/me/))
.rvm/wrappers/ruby-2.1.0#website/ruby /home/me/rails_deployments/dev.www/current/bin/rails runner 'EBlast.receive(STDIN.read)' -e development
Where ruby-2.1.0 is my current ruby version, and #website is the gemset used by the EBlast.receive code base.
EDIT: Spoke too soon, the command has its own set of problems...(gemfile not present). This is ludicrous.
Related
I inherited a Rails application and am having quite a difficult time generating a model. Running 'rails generate model Account' pauses for a moment, but then returns me to the command prompt without the output I would normally expect from a successful operation.
Environment info:
-Rails 4.2.5
-Ruby 2.3.0p, loaded via RVM
I've spent hours trying to debug this myself and have found a few interesting things:
1.) Generating a controller works as expected, only models seem broken
2.) If I create a new Rails project I can generate models as expected
3.) I've verified that spring is not running, using "spring stop"
4.) A similar problem is mentioned in this thread by a user with my same environment. I verified I'm in the proper dir, and also tried running "bundle update" as suggested by a user, but that didn't resolve the problem.
A few other resources allude to this being a problem with RVM, but rolling back to older versions of Ruby haven't made a difference.
Any idea what I'm doing wrong here?
Try the following commands:
bundle config --delete bin
rake rails:update:bin
Was able to reach out to one of the previous developers and learned that I'm dealing with JSONClient models and that's why it isn't working for me. D'oh!
Trying to run a project that was provided by a client.
I have the correct versions of Ruby, Gems, Rails, Bundler, Homebrew etc installed.
When I run rails server I get the following error in terminal.
.rvm/gems/ruby-2.2.2/gems/airbrake-ruby-1.0.4/lib/airbrake-ruby.rb:288:in `call_notifier': the 'default' notifier isn't configured (Airbrake::Error)
After much time spent on Google I couldn't find a fix on this.
Here is a screenshot of the whole terminal error message which I get the feeling these other lines could be related.
It looks like a previous developer may have hardcoded a commit hook in the application, pointing to a file in their local .git folder (and which you don't have).
I'd recommend either asking the developer to provide the missing file, create a dummy file in the same place, or removing that line.
I'm not a RoR programmer myself, but a good client of ours has sent a project their previous web team built and I need to get it up and running on their server.
The server uses cPanel and Ruby on Rails is already installed. I've created a project via the cPanel wizard and located the file tree via SSH.
Using SSH, I've tried to replace this file tree with the project I've been sent, but when I hit 'run' in cPanel, the application doesn't actually start (although the success message would indicate that it has).
If I leave the original cPanel-created application in place, I can run/stop no problem and the web interface at :12001 opens up just fine.
I assume there are either conflicts with RoR versions that I need to resolve, or there's simply more to it than just replacing the file tree? Again I'm not a RoR programmer and I'm having a hard time finding a migration guide that tells me anything other than "set up in cPanel and replace the files".
I'd very much appreciate either some genuinely useful links to RoR application setup/migration guides (ideally for cPanel) or a step-by-step answer please.
First, forget Cpanel for now. Try in one environment where you can control everything.
Try to know better the rails version used and the associated gem19s or plugin if from 2.x days. The ruby version is important too, only then you can start defining a plan.
I'm afraid you won't get a step-by-step answer, but I'm sure you can be pointed in the right direction by providing the requested information.
Simple questions: Do you have a Gemfile file at the top at your project? Do you have any plugins (stuff in vendor/plugins)?
Update:
With the Gemfile provided here are the required steps:
Install ruby (if you haven't install it using rvm. The version 1.9.3-x should be the safest.
Install rubygems
Install bundler
Go the project dir and run bundle install
run rake db:migrate (assure you have the database setup acording to config/database.yml
run rails s and check the logs and see if the server is up.
If after installing bundler, you don't have the bundle command in your path, you need to add this your .bash_profile:
PATH=$PATH:$HOME/.local/bin:$HOME/bin
export PATH
I've inherited a small Rails project from a new client and unfortunately the previous developer(s) left essentially no information other than the Rails app instance running in production. (No source repository, no documentation, just the login to the production server.)
Inspecting the server shows Rails version 2.3.8 installed (confirmed by the version number in "config/environment.rb") but when I try to run "ruby script/console" (or "server") on my local dev environment I get (essentially fatal) error messages originating from files in "vendor/rails/railties" and searching the internet for "railties" shows a lot of Rails 3 documentation.
I'm guessing that a previous developer/maintainer crossed the Rails 2/3 streams somehow. Should I be ok to just delete the entire "vendor/rails" directory or am I missing something?
What kind of error are you getting? Do you know that your local environment is the same as production? Do other Rails 2.3.8 projects run fine on your machine?
Now, I think it should be fine to remove vendor/rails with the exception being that if the previous developer monkeypatched something in Rails, but directly in the vendor/rails directory. Then, you might have a problem.
This approach might be a bit tedious, but I might go as follows:
Clone 2.3.8 somewhere else on my machine.
Check it in to some form of version control.
Copy your version of 2.3.8 from the project into the newly cloned directory.
Diff it.
This should show you if the previous developer made any changes, both significant and insignificant, to Rails.
Good luck, because this doesn't sound very fun :(
Here's what I've determined:
Delta indexing works fine in development
Delta indexing does not work when I push to the production server, and no action is logged in searchd.log
I'm running Phusion Passenger, and, as recommended in the basic troubleshooting guide, have confirmed that:
www-data has permission to run indexing rake tasks (ran them from command line manually)
the path to indexer and searchd are correct (/usr/local/bin)
there are no errors in production.log
What on earth could I possibly be missing? I'm running Ruby Enterprise 1.8.6, Rails 2.3.4, Sphinx 0.9.8.1, and Thinking Sphinx 1.2.11.
Thanks!
Last night as I slept it hit me. Unsurprisingly, it was a stupid issue involving bad configuration, though I am rather surprised that it produced the results it did. I guess I don't know much about Thinking Sphinx internals.
Recently I migrated servers. sphinx.yml looked like this:
production:
bin_path: '/usr/local/bin'
host: mysql.mysite.com
On the new server, MySQL was just a local service, but I had forgotten to remove that line. Interestingly, manual rake reindexing still worked just fine. I'm intrigued that Thinking Sphinx didn't throw an error when trying to reload the deltas, since mysql.mysite.com no longer exists, even though that was clearly the source of the issue.
Thanks for all your help, and sorry to have brought up such a silly problem.
Are there any clues in Apache/Nginx's error log?
Here's the next troubleshooting step I would take. Open up the file for the delta indexing strategy you are using (presumably lib/thinking_sphinx/deltas/default_delta.rb). Find the line where it actually generates the indexing command. In mine (v1.1.6) it's line 20:
output = `#{config.bin_path}indexer --config #{config.config_file} #{rotate} #{delta_index_name model}`
Change that so you can log the command itself, and maybe log the output as well:
command = `#{config.bin_path}indexer --config #{config.config_file} #{rotate} #{delta_index_name model}`
RAILS_DEFAULT_LOGGER.info(command)
output = `#{command}`
RAILS_DEFAULT_LOGGER.info(output)
Deploy that to production and tail the log while modifying a delta-indexed model. Hopefully that will actually show you the problem. Of course maybe the problem is elsewhere in the code and you won't even get to this point, but this is where I would start.
I was having this problem and found the "bin_path" solution mentioned above. When it didn't seem to work, it took me a while to realize that I'd pasted in the example code for "production" when I was testing on "stagiing" environment. Problem solved!
This was after making sure that the rake tasks that config, index, and start sphinx are all running as the same user as your passenger instance. If you log into the server as root to run these tasks, they will work in the console but not via passenger.
I had the same problem. Works on the command line, not inthe app.
Turns out that we still had a slave database that we were using for the indexing, but the slave wasn't getting updated.
As above, same issues were faced our side on two machine. The first one we had an issue with mysql which showed in apache2 log. Only seemed to affect local OSX machine..
Second time when we deployed to Ubuntu server, we had same issue. Rails c production was fine, no errors, bla bla bla.
Ended up being a permissions problem. Couldn't figure this out as there were no problems starting, although I guess I was doing so as root.
Using capistrano and passenger, we did this:
Create a passenger user and added to www-data group
Changed user in deploy.rb to be passenger
Manually changed all the /current files to be owned by above
Logged in as passenger user.
Ran rake ts:rebuild RAILS_ENV="production"
Worked a treat for us...
Good luck