macdiggs.com

… and publishing this article using iPhone's WordPress application! Pretty cool huh:)

Sometimes you might want to run a long action on a remote server, like dump a few gigs DB, or rsync a few thousands of files between two not very fast computers.

You want to take next action as soon as that long operation completes but don't want to baby sit your servers.

How about getting email notification to your.. say.. iPhone.. when the action completes? It's pretty easy! Have a look!

mysqldump -u user -p mydatabase && echo "Dump finished!" | mail -s "Wake up!" mike@example.com

Once the command mysqldump finishes executing,  you'll get mail with subject "Wake up!" and body "Dump finished!"

You can chain more commands, of course, by adding && between them ( && executes next chained command only if the previous one completed without errors)

Pretty cool to have such a simple but useful trick under your belt, isn't it? :)

I started getting weird

(eval):2:in `protect_against_forgery?'

error from one of my Rails2-based system today. Mongrels were seg-faulting as well. The problem was quite unexpected as I have not touched the code for a while!

Turned out the problem was with the latest upgrade to ruby 1.8.6 patch level 230 (which is recommended by the Ruby on Rails site). And looks like this was the only system re-deployed (and restarted under new ruby version) since I have upgraded.

Now I'm back to p111, "vulnerable", but at least working version until problems sort themselves out.

Until they do, do not upgrade!

UPDATE:

Looks like the is a patch which addresses vulnerabilities which patch 230 addressed in turn. Check here for details. However, I'll just stick here for a couple of days for a real fix from the Ruby team.

Having something like this

Wouldn't it be cool if you could creating something like this?

All in real-time, in your Ruby on Rails project, using RMagick.

Hold on because I'll show you how. (more…)

I recently faced a problem when I didn't want Rails' timestamp "magic" columns to be updated during update of records in database. I have a site where recently updated pages are displayed on front page, and I use updated_at timestamp to identify the most recently updated ones. However, the system also has a feature to reorder pages, where only the 'position' attribute is updated, and not the actual page content. The reorder operation can't be counted as a real update. However, any saves or update_attribute operations on a model fire up the magic columns update.

However, there's a simple way to permanently turn this feature off. Here's how I implemented it:

ActiveRecord::Base.record_timestamps = false #temporarily turn off magic column updates

@page.update_attribute(:position, pos)

ActiveRecord::Base.record_timestamps = true #turning updates back on

Yes, you can do it very easy and fast if you have Webmin installed on your server.

Go to Servers -> Sendmail Configuration -> Sendmail Options and make sure that SMTP port options parameters are set to:

Name=MTA
Port=587, Name=MSA, M=E

Just like on the screenshot below:

Click "Save and Apply" button and you're done. Now your mail server will accept mail on both 25 and 587 ports.

I have migrated all my Ruby on Rails system from Fedora Core 6 to RedHat 4.5 recently, and everything was fine, except for that the feature of blogging by email was broken (got a phone call today about that).

I use standard sendmail/procmail integration feature to receive mail to a designated address,  and then pipe it into Rails Mailer's receive function.

So, it looks like that in my /etc/mail/virtusertable:

m@example.com        examplemobile

this way all email which is coming to m@example.com address will be forwarded to system user called examplemobile.

In order to process the mail further and pipe it into my Rails script, I have the following setup in my /etc/aliases file :

examplemobile: "|/usr/local/bin/ruby /var/www/html/examplesite/current/script/runner -e production 'Mailman.receive STDIN.read'"

This setup worked perfectly on Fedora, but broke under RedHat. What's the problem? I was getting the following errors in my maillog:

Feb 13 11:45:33 appserv1 sendmail[32000]: m1D2jXJw032000: from=<xxxxxx@c.vodafone.ne.jp>, size=397, class=0, nrcpts=1, msgid=<20080213114719020972.1b6f@0016E68C4270>, proto=SMTP, daemon=MTA, relay=mmrts035p01c.softbank.ne.jp [123.108.236.87]
Feb 13 11:45:33 appserv1 smrsh: uid 8: attempt to use "ruby /var/www/html/examplesite/current/script/runner -e production 'Mailman.receive STDIN.read'" (stat failed)
Feb 13 11:45:33 appserv1 sendmail[32001]: m1D2jXJw032000: to="|/usr/local/bin/ruby /var/www/html/examplesite/current/script/runner -e production 'Mailman.receive STDIN.read'", ctladdr=<m@examplesite.com> (8/0), delay=00:00:00, xdelay=00:00:00, mailer=prog, pri=30623, dsn=5.0.0, stat=Service unavailable

The problem turned out to be in sendmail setup under RedHat was more secure than the one I had in Fedora. Specifically, this has to do with smrsh (or Sendmail Restricted Shell) thingy. More info about it here. Basically, sendmail only allows piping to programs which (or aliases to them) are present in /etc/smrsh directory.

Since I only use ruby to pipe to, I have added a symbolic link to it inside the /etc/smrsh directory:

[mike@appserv1 smrsh]$ pwd
/etc/smrsh
[mike@appserv1 smrsh]$ ls -l
lrwxrwxrwx  1 root root 19 Feb 13 11:50 ruby -> /usr/local/bin/ruby

Everything works as it should now, and our mobile-blogging users are supposedly happy again :)

Though I have moved my latest Rails apps to Rails 2.0, I've been pretty slow moving my deployment recipes from older Capistrano 1.x to the new Capistrano 2.x series.

Capistrano ultimately lacks any documentation which can even remotely be called "complete" or "easy to understand", so it definitely takes much more time that it actually should take, to understand how the bloody thing works. Sure, this of course includes annoying trips into Cap's source code and stuff like that, which is not a great time saver.. End of rant.

Anyways, you can be a lazy folk like myself lately, and just deploy your Rails 2.x compatible app using old Capistrano 1.2 recipes:

cap _1.2.0_ deploy

But the time will come and you'll want to ultimately move the stuff to the latest and greatest. And actually, it's pretty easy to do, _once_ you got the idea what needs to be done.

First, you need to capify your application, using

capify .

command in the top level of your application.

Next, you can replace contents of your old deploy.rb file with the following (or modified the following).

set :application, "your_application"

set :repository, "https://your-repository.com/svn/#{application}/trunk"
set :deploy_to, "/var/www/html/#{application}"

set :mongrel_config, "#{current_path}/config/mongrel_cluster.yml"
set :runner, "mike" #the default user is 'app'
set :deploy_via, :export
set :deploy_via, :remote_cache

set :keep_releases, "3"

role :web, "appserv1"
role :app, "appserv1"
role :db,  "dbserv1", :primary => true

namespace :deploy do

desc "Create symlinks for shared image upload directories"
task :after_update_code do
%w{gallery_items attachments image}.each do |share|
run "rm -rf #{release_path}/public/#{share}"
run "mkdir -p #{shared_path}/system/#{share}"
run "ln -nfs #{shared_path}/system/#{share} #{release_path}/public/#{share}"
end
end

desc "Restarts the pack of mongrels"
task :restart, :roles => :app do
restart_mongrel_cluster
restart_apache
end

desc "Restarts apache web server"
task :restart_apache, :roles => :app do
sudo "/usr/sbin/apachectl graceful"
end

end

desc "Start the mongrels"
task :start_mongrel_cluster, :roles => :app do
sudo "mongrel_rails cluster::start -C #{mongrel_config}"
end

desc "Stop the mongrels"
task :stop_mongrel_cluster, :roles => :app do
sudo "mongrel_rails cluster::stop -C #{mongrel_config}"
end

desc "Restart the mongrels"
task :restart_mongrel_cluster, :roles => :app do
stop_mongrel_cluster
sudo "rm -rf #{current_path}/tmp/pids/mongrel.*.pid"
start_mongrel_cluster
end

This assumes you run your apps on mongrels cluster, and that you wish to restart your apache server after every deployment (somehow, just restarting mongrels just don't work for me sometimes). Also, I use different servers for application and database. Other than that, it should work for you as is.

But of course, don't really believe me, and look thru this config before messing up with your deployment stuff :)

I've been getting a strange "User unknown" error from sendmail today, when everything should have worked fine and even though users did exist. Here's some info on the problem's source and solution.

We have a domain called "talentnavi.biz", and I was asked to add a new subdomain to that domain ("kansai.talentnavi.biz"), and add new email addresses for several users who will be using that domain. I have setup everything properly on the server site by adding users and updating local domains and virtusers lists, however, when I was trying to test the delivery of the messages, I was getting "User unknown" errors and my emails to the newly-created mailboxes were bounced back.

I checked my mail server's logs, but there were of no help at all. After some googling, I found a very nice solution! In order to see how an email to a particular email address gets delivered, you should run the following command as root:

sendmail -d60.5 -d27.2 -bv info@example.com

So, in my case the command and output were as follows:

[root@me-ja mike]# sendmail -d60.5 -d27.2 -bv info@kansai.talentnavi.biz
map_lookup(dequote, mike, %0=mike) => NOT FOUND (0)
map_lookup(host, kansai.talentnavi.biz, %0=kansai.talentnavi.biz) => talentnavi.biz. (0)
map_lookup(dequote, info, %0=info) => NOT FOUND (0)
map_lookup(virtuser, info@talentnavi.biz, %0=info@talentnavi.biz, %1=info) => NOT FOUND (0)
map_lookup(virtuser, @talentnavi.biz, %0=@talentnavi.biz, %1=info) => NOT FOUND (0)
alias(info)
info@kansai.talentnavi.biz… User unknown

So, turns out that I have incorrectly configured my DNS records. They were set up like the following:

talentnavi.biz A 123.123.123.123

talentnavi.biz MX talentnavi.biz

kansai.talentnavi.biz CNAME talentnavi.biz

So, by default, the kansai.talentnavi.biz was aliased to talentnavi.biz, and since I didn't have a separate MX record for kansai.talentnavi.biz, the talentnavi.biz was used for mail delivery.

mike-meja:~ mike$ host -t mx kansai.talentnavi.biz
kansai.talentnavi.biz is an alias for talentnavi.biz.
talentnavi.biz mail is handled by 20 talentnavi.biz.

Therefore, the all email which was sent to "info@kansai.talentnavi.biz", was actually attempted to be delivered to "info@talentnavi.biz", because there was no separate MX record for the kansai. subdomain.

The solution is of course to add :

kansai.talentnavi.biz MX kansai.talentnavi.biz

Record to DNS server, and everything should work fine.

We have finally set up something which might be called a server room, at the company I work at.

We now have 4 servers, two of which are pretty powerful Dell PowerEdge 1900 servers I blogged about some time ago, one is our old server (which is basically just a custom-built stock computer), and one Mac which only serves a simple MySQL and FileMaker databases.

Now, my job for the next severals weeks is to gradually migrate stuff from old server to the new ones, which will become a PITA for sure, but I just hope it won't turn into MAJOR PITA :)