Posted on Tue Jan 19 22:23:00 UTC 2010
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”
Posted in Linux, Quid Pro Quo
|
Tags iscsi
|
0 comments
Posted on Thu Dec 20 01:42:00 UTC 2007
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.
Posted in News, Quid Pro Quo
|
Tags ruby gems
|
11 comments
Posted on Mon Aug 07 20:06:00 UTC 2006
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!
Posted in Quid Pro Quo, Rails
|
Tags rails, spam, typo, upgrade
|
11 comments
Posted on Fri May 19 02:47:00 UTC 2006
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.
Posted in Quid Pro Quo, Rails
|
Tags environment, rails, ruby
|
0 comments
Posted on Thu Apr 13 16:58:00 UTC 2006
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.
Posted in Quid Pro Quo
|
Tags firefox, kubuntu
|
0 comments
Posted on Mon Apr 03 18:42:00 UTC 2006
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!
Posted in Quid Pro Quo
|
Tags css
|
1 comment
Posted on Tue Mar 28 14:03:00 UTC 2006
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 “/home/psq/blog.nanorails.com/current/public/dispatch.fcgi”
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’:
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’
from /usr/local/lib/site_ruby/1.8/rubygems.rb:162:in `activate’
from /usr/local/lib/site_ruby/1.8/rubygems.rb:161:in `each’
from /usr/local/lib/site_ruby/1.8/rubygems.rb:161:in `activate’
from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:23:in `require’
from ./../config/boot.rb:14
from ./../config/environment.rb:8:in `require’
from ./../config/environment.rb:8
from ./dispatch.fcgi:21:in `require’
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!
Posted in Quid Pro Quo, Rails
|
Tags capistrano, hosting, rails
|
6 comments
Posted on Sat Mar 25 13:56:00 UTC 2006
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 “rm -rf …
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.
Posted in Quid Pro Quo, Rails
|
Tags capistrano
|
3 comments
Posted on Sun Mar 12 03:55:00 UTC 2006
Given a fixture contacts.yml which contains:
patrick:
id: 1
name: patrick
email: patrick@tes.com
pre 1.0 solutions:
@contacts[“patrick”] #using hash
@patrick #using variable
solution 1:
contacts(:patrick) #using accessor
solution 2:
@loaded_fixtures[“contacts”][“patrick”] #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).
Posted in Quid Pro Quo, Rails
|
Tags rails, testing
|
1 comment
Posted on Sat Mar 11 07:06:00 UTC 2006
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"> </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.
Posted in html/css, Quid Pro Quo
|
Tags html
|
12 comments
Posted on Thu Mar 09 18:13:00 UTC 2006
Well, version 0.1 was shortlived. There was a critical difference between running with WEBrick and running in production environment with fastcgi.
The value of env[“REQUEST_URI”] did not contain “http://host”. So I found a quick solution and we’ll see if there is a better solution tomorrow.
Current solution consists of replacing
@article_url = request.env[“REQUEST_URI”]
with
@article_url = ‘http://’+request.env[“HTTP_HOST”]+
request.env[“REQUEST_URI”]
if @article_url.eql?(@article_url.gsub(/http:/,”).gsub(/HTTP:/,”))
You live and learn…
bookmarkit-0.2.zip and
bookmarkit-0.2.tgz
Posted in News, Quid Pro Quo, Rails
|
Tags bookmarkit, plugin, rails, typo
|
20 comments
Posted on Thu Mar 09 15:47:00 UTC 2006
I realize this is somewhat off topic here, but it wasn’t obvious to me, and it took quite a few google searches to come up a hints, so I thought someone might benefit from this.
I had what I thought was a pretty simple problem. I have a site that is currenlty protected by a password. You know, something like:
AuthType Basic
AuthName “Allow Specific Users”
AuthLDAPURL ldap://localhost:389/dc=domain,dc=com?uid?sub?(objectClass=*)
require valid-user
to protect the whole site. Now, I also needed a subdirectory to be accessible without a password.
That’s easy, I thought, I probably just need to create a or a .htaccess with AuthType None or something. Not so fast! After quite a while, I was starting to think that the only solution was going to be to set the root public, and protect all the sub directories but one.
But in fact the solution is very simple:
just create a .htaccess file and include:
Allow from all
Satisfy Any
And that’s it! Turns out Satisfy Any will let people in if either the require or the Allow matches.
Posted in Quid Pro Quo
|
Tags apache, authorization
|
8 comments
Posted on Sun Mar 05 17:53:00 UTC 2006
Running script/console provides the delightful answer:
/usr/local/lib/ruby/1.8/irb/completion.rb:10:in `require’:
no such file to load – readline (LoadError)
Turns out that Kubuntu doesn’t have the curses libraries.
Here’s the begining of a solution
apt-get install libncurses5-dev libreadline5-dev (Ubuntu/Debian)
Then recompile the readline extension and go from there.
cd ext/readline
ruby extconf.rb
make
sudo make install
Read more
Posted in Linux, Quid Pro Quo, Rails
|
Tags console, debugging, readline
|
10 comments
Posted on Sat Mar 04 15:46:00 UTC 2006
I did setup this blog (using the most excellent typo if you need to ask). The next step was to setup switchtower, and you guessed it, it almost worked. Here’s why.
Followed the directions to get it going and was ready to type my first command:
rake –trace remote_exec ACTION=setup
yeah, that would be too easy if it worked, wouldn’t it. Instead of the expected output, I get the very impolite:
** Invoke remote_exec (first_time)
** Execute remote_exec
rake aborted!
uninitialized constant SwitchTower
…/activesupport-1.2.5/lib/active_support/
dependencies.rb:200:in `const_missing’
I mean, I did not mean to be rude, so why is it doing this?
Sorry I can’t give credit to where credit is due (shame on me for not putting the info down at the time. Now that this is site is up and running, I can capture the next problem blow by blow as it happens). If you know who should get the credit, drop me a note. Anyway, here’s the solution.
in lib/taks/switchtower.rake replace
begin
require 'rubygems'
rescue LoadError
# no rubygems to load, so we fail silently
end
options = actions.last.is_a?(Hash) ? actions.pop : {}
to:
begin
require 'rubygems'
rescue LoadError
# no rubygems to load, so we fail silently
end
require 'switchtower/cli'
options = actions.last.is_a?(Hash) ? actions.pop : {}
Incidentally, I did setup typo directly from svn to get the tagging extension builtin. And to use SwitchTower, I then commited this into my own subversion repository. This might get interesting the day I want to upgrade. We’ll keep this story for an other day.
Posted in Quid Pro Quo
|
Tags capistrano, error, rails
|
0 comments
Posted on Sat Mar 04 15:36:00 UTC 2006
Here’s an other thing that is not supposed to happen, but invariably does.
Playing aroung with Unit Testing in Rails (you are using them, right?), one test fails with:
Exception `ActiveRecord::StatementInvalid’ at
…/active_record/connection_adapters/mysql_adapter.rb:185
- Mysql::Error: Warning: Some non-transactional changed
tables couldn’t be rolled back: ROLLBACK
Turns out that on my OS (debian), the default mysql database table type is MyISAM and it does not support ROLLBACK, try InnoDB instead.
March 12, 2006 update:
In case this is not possible, or too much problem, there is an other solution (albeit slower).
In test/test_helper.rb, change:
self.use_transactional_fixtures = true
to
self.use_transactional_fixtures = false
this way, the testing framework won’t use rollback but drop and recreate the tables each time (which explains why this is slower).
Posted in Quid Pro Quo
|
Tags error, rails, testing
|
2 comments
