Quid Pro Quo

There are 16 posts filed in Quid Pro Quo (this is page 1 of 2).

Multiple targets with iscisitarget (ubuntu 9.04)

After trying for a (long) while to have multiple targets defined on the same host, and having my initiator to see both, the solution what in fact simple: Use different values for the LUN!

Here’s a snippet of /etc/ietd.conf

Target iqn.2010-01.com.test:storage.disk1.sys1.000
        Lun 0 Path=/media/usb/test0.img,Type=fileio,IOMode=rw
Target iqn.2010-01. com.test:storage.disk1.sys1.001
        Lun 1 Path=/home/psq/test1.img,Type=fileio,IOMode=rw

Then don’t forget to restart: “service iscsitarget restart”

Ruby Gem 1.0 is out

RubyGem 1.0 is out.

Yeah!

Which means that if you see

undefined method `require_gem' for main:Object (NoMethodError)

You’ll need to replace require_gem by just gem.

For example, unless you have the very latest version of ruby-debug (0.9.3), you’ll see the above error. In that case, though, updating your gem is simpler.

Upgraded to Typo 4.0

Well, the upgrade to Typo 4.0 didn’t go so well. No data loss though, so everything’s cool.

At least most pages seem to be functional, so this is not so bad. Combined with having custom sidebar plugins that no longer work, the fact that the merge between the new code and my old one did not quite go as planned, it was not a too pleasant (most of it my own fault I guess).

Anyway, it is getting really late and I’ll finish the rest of the migration tomorrow.

If you tried to access the site while this was going on and you were inconvenienced, pleas accept my most sincere apologies!

If you notice anything weird, please send me a mail at psq _at_ nanorails _dot_ com.

Update, about 20h later, some sleep…: It seems that everything is back up, I migrated my custom plugins to typo 4.0 (about removing 1 file, removing half of the code linked to configuration and adding a few lines) and it seems that everything has been working smoothly :)

And the best of all of that: no more trackback spam! Well, not that it went away, it caught about 25 since last night, but they don’t get published anymore. Just for that, it was all worth it. Thank you everyone in the typo team!

Update 2: Well rails 1.1.5 came out, and it was not enough, so rails 1.1.6 came out and seems to be strong enough to fill in the security issues

And in the process, I also upgraded to Typo 4.0.2

That last upgrade went very smoothly!

However, I’ve had a few annoying cases of nanoRAILS hanging and not responding for hours on hand till I killed the processes. I don’t know yet at this point whether it is due to the new version of rails, the new version of typo, or pehaps some settings that changes on dreamhost. In any case, I’ve installed my own version of ruby and the full set of gems, so we’ll see if that helps!

Arghhhhh! The path to ruby lib is wrong!

nanoRAILS was down for the past 12h because of a setup change on my host on DreamHost.

Suddenly, the link /usr/local/lib/ruby was changed to point to an incorrect location, so instead of having the ruby libraries under /usr/local/lib/ruby/1.8, they would effectively be under /usr/local/lib/ruby/ruby/1.8 :(

Suffice it to say that things don’t work too well after that.

Running dispatch.fgci by hand revealed that “require pathname” fails. Hmmm, that’s not supposed to happen! That when I realized the above mentioned link had been changed just a few hours before.

After tinkering some more, and trying a few options, I managed to put a kludge together till the link is put back in the right place.

In the public directory, I created a myruby script:

#!/bin/bash
export RUBYLIB=/usr/local/lib/ruby/ruby/1.8/:/usr/local/lib/ruby/ruby/1.8/i386-linux/
/usr/bin/ruby $*

Make sure that script is executable (chmod +x myruby)

then in dispatch.fcgi, I replaced the first line with:

#!/usr/bin/env [PATH TO YOUR RAILS APP]/public/myruby

Of course, this will likely break once the link is restored to its correct value.

You’ve got to love using a shared host!

Update: ruby setup is back to normal now. At least I learned something in the process.
Everyone that was inconvenienced by this outage, please accept my apologies.

Firefox 1.5.0.2 login problem

Firefox 1.5.0.2 is out and promises to fix quite a few stability issues. Yeahhh!

I just upgraded tonight on some of of my computers. The upgrade went smoothly. None of the extensions I’m using broke. Except that on Kubuntu, I could not login to the dreamhost panel. I kept getting sent back to the login screen while it worked without a hitch from windows.

Deleting the cookie for dreamhost did the trick.

Could be related to some changes in the way the cookie is encrypted, that the site is accessed via https, but it still doesn’t explain why it worked on windows. Although there is the possibility I never connected from that machine before and therefore did not have a cookie.

Forcing an horizontal scrollbar on a element

The root cause of the problem turned out that to be that some lines within <pre><code> where too long, and on a browser like firefox, it was overflowing on the right, not too appealing, but not such a big deal. But on Internal explorer, it ended moving the main <div>. Ouch!

I thought the solution would just be to add an

overflow: scroll;

to the <pre> element. Hmmm, not quite. Let’s try the <code> element. Hmmm, neither! Works great with firefox though.

After much research, I found the solution on Site Surgeon and I’m grateful!

The key I was missing is to force the width to almost 100%:

width: 99.5%; /* force IE to display the scrollbars */
overflow: scroll; /* Create horizontal and vertical scrollbars. */

An other interesting nugget is to treat the <code> element as a block to be able to set a vertical margin and vertical padding.

For those of you that use Explorer, please accept my apologies. And thank you for reporting the problem!

Freeze all your ruby gems on a shared host

Things started to go downlhill when I had to check back on a previous article I had written about (Allowing full access to a sub directory in Apache Server) and my server would just hang!
Well, not a problem, let’s just try to hit the refresh key, hmmm, nothing. Ok, for good measure, let’s hit the button, just to be sure. Hmmm, still nothing.
Ok, let’s check out the logs, started from the apache logs. 

[Tue Mar 28 21:04:31 2006] [error] [client 66.249.66.226] FastCGI: incomplete headers
(0 bytes) received from server &#8220;/home/psq/blog.nanorails.com/current/public/dispatch.fcgi&#8221;

Ok, yep, something’s wrong. Next, let’s hit the production.log. Nothing useful.

Next, a trick I learned before (aren’t you glad it is not your first time troubleshooting FastCGI?). Let’s call public/dispatch.fcgi directly:

/usr/local/lib/site_ruby/1.8/rubygems.rb:194:in `report_activate_error&#8217;:
    RubyGem version error: activerecord(1.13.2 not = 1.14.0) (Gem::LoadError)
    from /usr/local/lib/site_ruby/1.8/rubygems.rb:136:in `activate&#8217;
    from /usr/local/lib/site_ruby/1.8/rubygems.rb:162:in `activate&#8217;
    from /usr/local/lib/site_ruby/1.8/rubygems.rb:161:in `each&#8217;
    from /usr/local/lib/site_ruby/1.8/rubygems.rb:161:in `activate&#8217;
    from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:23:in `require&#8217;
    from ./../config/boot.rb:14
    from ./../config/environment.rb:8:in `require&#8217;
    from ./../config/environment.rb:8
    from ./dispatch.fcgi:21:in `require&#8217;
    from ./dispatch.fcgi:21

Ah ha! Bingo. What does it all mean, though?

It has been hard to miss that Rails 1.1 is not officially out. Yeahh!!! I wonder whether Dreamhost (aff) has maybe, just maybe, decided to upgrade.

gem list|grep rails

Ah ha! again. Yes, rails is is now 1.0 and 1.1. So I futz a little bit to try to freeze the gems manually, to not avail :(. So I go home, and fortunately, thanks to Capistrano, I have a full copy on my home machine! After doing a little reading, I figure the solution has to be:

rake freeze_gems

So first things first, I get home, rush to my machine, run the magic command, then run what was going to solve all the recent woes:

cap deploy -q

and hit the refresh button…
Duh! Still doesn’t work. Major Bummer!

Next step is to get a copy of all my gems (for typo):

 cd vendor/rails
 gem unpack activerecord
 gem unpack activesupport
 gem unpack actionpack
 gem unpack actionmailer
 gem unpack actionwebservice
 mv activerecord-1.13.2/ rails/
 mv actionmailer-1.1.5/ actionmailer
 mv actionpack-1.11.2/ actionpack
 mv actionwebservice-1.0.0/ actionwebservice
 mv activerecord-1.13.2/ activerecord
 mv activesupport-1.2.5/ activesupport

Your versions may vary depending on your install.

Then, committed everything, and redeployed.

and Ta Da! everything’s now back to normal! Phew…

The moral of the story, it that wasn’t clear already is:

Do not rely on the gems installed on your shared host!
Make sure your freeze all your gems

And I can worry on my own time to upgrade to rails 1.1 in my production environmment.

Update about 2 hours later:
Assuming you can run rake (which I couldn’t because of some broken dependency), an other method to lock down to rails 1.0 is to use:
rake freeze_edgeREVISION=3303

this assumes that’s you are using rails directly from svn already.

Update about 18h later:
An other solution is to lock down the versions of the gems you use in environment.rb using what suggested on Ruby On Rails Wiki. Thank you, Miles Barr for the tip!

Avoiding the SUDO police with Capistrano

Turns out that by default, Capistrano is using sudo to delete everything (can I stop for a second and say that, for once, this is a bad default! At least on a shared hosted environment).

So anyway, I take a look at capistrano/recipes/standard.rb in my gems directory, and finds that there are the following 2 lines (conveniently placed at the beginning of the file):

set :use_sudo, true
set(:run_method) { use_sudo ? :sudo : :run }

Not a problem, let’s try to set :use_sudo to false in my confi/deploy.rb

set :use_sudo, false

Just to be sure, let’s do a dry run and check out what are the commands issued in this case to check that sudo is not called:

cap -P cleanup

Uh Ho again!

*** no old releases to clean up

:( oops. not only are my old releases not gone, but now I can’t rerun the script. Forutunately, the previous call to Capistrano had a log and I was able to log in to my host and run that massive rm -rf by hand.

Now, I was able to deploy an other release, and check whether setting :use_sudo works or not.

* executing &#8220;rm -rf &#8230;

It works! Phew!

And now I can rest assured that the SUDO police won’t take me away :)

Note: turns out “cap -P cleanup” is not too useful because it needs to get the list of what’s available on the server.

Fixture variables not created

Given a fixture contacts.yml which contains:

patrick:
id: 1
name: patrick
email: patrick@tes.com

pre 1.0 solutions:

@contacts[&#8220;patrick&#8221;]  #using hash
@patrick              #using variable

solution 1: 

contacts(:patrick)    #using accessor

solution 2:

@loaded_fixtures[&#8220;contacts&#8221;][&#8220;patrick&#8221;] #direct access (not recommended)

solution 3:

Edit the test/test_helper.rb and set 

  self.use_instantiated_fixtures  = true

this way the fixture variables are created like they used to.

You can get more details from the man himself (Mike Clark’s Weblog).

footerStickAlt revisited

Here’s the html used here

<html>
<body>
  <div id="wrapper">
    <div id="blog-header">
    </div>
    <div id="main-wrapper">
      <div id="sidebar">
      </div>
      <div id="main-content">
      </div>
    </div>
    <div id="main-bottom-space">&nbsp</div>
  </div>
  <div id="footer">
  </div>
</body>
</html>

and the css used here:

body {
/* force footer to stick at bottom */
height: 100%;
}

/* avoid trampling on the footer by reserving some space (IE) */
#main-bottom-space {
height: 26px;
clear: both;
}

#wrapper {
position: relative;
/* force footer to stick at bottom */
height: 100%;
}

#main-wrapper {
position: relative;
}

#main-content {
float: left;
}

#sidebar {
float: right;
}

#footer {
clear: both;
/* stick at bottom */
height: 26px;
position: relative;
margin-top: -26px;
}

The key difference is to add the #main-bottom-space <div> element.