Weblog

On Rails sessions

Like everything else in Rails, sessions are pretty easy to use. Unfortunately, the default session configuration isn’t particular well suited for a shared host.

You see, by default CGI::Session::PStore (the default session store in Rails) will use the operating system’s temp dir, which on nix-like systems means /tmp. Which is fine, the /tmp dir well suited for small, temporary files that will get cleaned out, which is also why the /tmp partition is traditionally being kept small (it’s actually quite big here at TextDrive compared to traditions).

But here’s the problem, Rails loves to create new session files, one particular case where you’ll end up with an abnormal number of “useless” sessions is RSS/Atom feeds. See, most feedreaders just request a new session every time they hit a feed, let’s say your users are nice and only refreshes their readers once every hour, that’s 24 new sessions per day per user. Let’s say you have a 100 users loyally refreshing their feeds every hour, every day; that’s 2400 new sessions. If you suddenly get popular and get a whooping 250 loyal visitors a day, then that’s 6000 new sessions. And that’s only for the feedreaders, your normal visitors will create a good amount of new sessions as well (even though browsers are a bit smarter about being able to “reuse” a previously created session, thanks to cookies).
Now all that activity will end up with a decent amount of session files, which is fine. The problem is that your site is hosted on a shared server, where you’ll have plenty of neighbors doing the same thing, and /tmp will quickly end up looking like this:


ls -l /tmp/ | grep -c ruby
79962

That’s eighty-thousand ruby sessions, let’s say all those users are nice and don’t keep anything big in their sessions, so they’re about four kilobytes each, that’s still about 320 megabytes worth of session files. Enough to fill up most /tmp partitions based on traditional partition schemes. And that is bad, since things like MySQL stores its socket file in there.

OK, enough 3rd grade mathematics. Luckily Rails has alternatives, CGI::Session::PStore allows you to set an alternative “tmpdir” by sending it the ‘tmpdir’ option key, within Rails you could do it like this, in your environment.rb:
ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS.update(:tmpdir => File.join(RAILS_ROOT, '/tmp'))
which would set it to /path/to/your/railsapp/tmp, very easy and unobtrusive to the real /tmp partition.

That’s one way, even better would be to use ActiveRecordStore to store the sessions in your database. Not only does it not involve files on the filesystem, it’ll also make your application faster. Just look and uncomment this line in your environment.rb:
config.action_controller.session_store = :active_record_store
and run rake create_sessions_table to create the sessions table.

Once upon a time Scott Barron wrote this little thing called Session Container Performance in Ruby on Rails, and if you look at the graphs you’ll see how performance is slowly degrading over time using the default PStore, while staying constant using ActiveRecordStore. Scott wrote that thing late 2004, so the numbers may or may not be the same, but the very same principles and conclusions still apply.

·:· Posted 23 January 2006, 10:11 by Johan Sørensen to Upon our Recommendation  |  Got sessions? [4]

Mickael's ww2panorama.org

I can’t stop looking at Mickael Therer’s ww2panorama.org.

It’s a series of beautiful, fullscreen qtvr panoramas of several WW2 European landmarks. I find myself exploring each one and the clarity and crispness of each makes me feel like I’m actually there.

Beautiful and quite haunting. Go take a look.

·:· Posted 13 May 2005, 05:51 by Jason Hoffman to TextDriven  |  Comment [3]

Weak Passwords: Scourge of Shared Hosting

Please consider your fellow servermates and avoid the use of weak passwords.

What Not To Do

Strong passwords are great. Cryptographically secure passwords are even cooler and highly encouraged. That said, under no circumstances should anyone be using something like “jason/jason” or “damelon/damelon” as their login/password combination.

Dictionary attacks have been monitored on these servers from the very early days and are considered “constant” today. Expect that if you are using a weak password for your account to be compromised by these attacks. This escalates the possibility that other users will be affected by your oversight. This is a very bad thing.

Choosing Good Passwords

Information about how to choose good passwords can be found in many places. A good summary can be found at the Australian Computer Emergency Response Team’s site here.

Choice Selections

“It has often been said that ‘good fences make good neighbors.’ On a Unix system, many users also say that “I don’t care who reads my files, so I don’t need a good password.’ Regrettably, leaving an account vulnerable to attack is not the same thing as leaving files unprotected. In the latter case, all that is at risk is the data contained in the unprotected files, while in the former, the whole system is at risk.”—Klein, 1991

“I remember seeing a great phrase on the Mexican Hackers Emergency Response Team page, which went something like ‘Passwords are like underwear: don’t share them, hide them under your keyboard, or hang them from your monitor. Above all, change them frequently’”—SecurityFocus

Thanks, Terrell

References

[1] AusCERT. Choosing Good Passwords. (2001) http://www.auscert.org.au/render.html?it=2260

[2] Klein, Daniel V. (1991) Foiling the Cracker; A Survey of, and Improvements to Unix Password Security. Proceedings of the 14th DoE Computer Security Group. May 1991. http://www.klein.com/dvk/publications/

[3] SecurityFocus. (2001) Password Crackers – Ensuring the Security of Your Password. http://www.securityfocus.com/infocus/1192

[4] Smith, Richard E. (2002) The Strong Password Dilemma. http://www.smat.us/sanity/pwdilemma.html

·:· Posted 7 May 2005, 05:04 by Terrell Russell to Upon our Recommendation  |  

My Projects are fine, it's my Life that's been the mess

My Projects are fine, it’s my Life that’s been the mess.

I love Basecamp and have been a paying member since February of 2004 (we used it to organize Textbox and TextDrive) but would find myself occasionally frustrated with it because there was something missing. It didn’t help with what was my most important project: me me me me. I even went so far as to open a “Jason” project once, but it felt too sterile, too organized perhaps, not fluid enough, too much like “work”.

I wanted something …

  • flexible but complete,
  • predictable but surprising (in it that I would think hey can I do X with it … YES! ),
  • “bloggish” (but textpattern kinda bloggish: topical not forced-date-based-what-I-am-having-for-lunch-today) with a restrained freedom about it,
  • that could email me and I could email it (sorry, email is still the #1 thing for me)

I want a “page” that I can give a name, say what it’s about, make lists on it, make notes on it, throw files up on it, share it with only some people or the entire world and when I share it, I want it to be “smart” and aware of what I’m doing and what the other people are doing.

I could go on-and-on for quite a bit more, but you’re going to have to take my word for it: I found it and more, so run don’t walk to backpackit.com and get yourself an account.

Here at TextDrive, a backpackit account is a fringe benefit, everyone has one on the company dime. Combined with basecamp, it’s what makes this place run.

And don’t be a cheapwad, get yourself a paid account today. I’ve spent more on coffee and beer (2 triple espressos + 2 pints) in a single day than what I spend ($19) a month on BackpackIt.

·:· Posted 3 May 2005, 16:42 by Jason Hoffman to Upon our Recommendation  |  Comment [1]

HELP, my site is down! Thanks. (or, How to Write a Ticket)

What’s in a ticket?

Well, often when responding to support requests submitted by clients, I wonder the same thing. We regularly see something like the following:

Subject: HELP, my site is down!
Body:Thanks.

And that’s it.

Seriously.

We would like to be able to help everyone in the most expedient and comprehensive manner we can, and receiving a ticket like the above adds literally 3-4 minutes to our workflow, looking up the details. That may not seem like much, but multiply that by 80-90 tickets per day, and you’ll appreciate the gravity of the situation. We hope that with a little coaching, doing our job and getting your problems resolved quickly and efficiently will become easier for everyone involved.

So what can help us help you better? Well, in a word, details. Details, details, details. Take for example our illustration from above. If I were to live in a perfect world, here’s what that support request would look like:

Subject: HELP, http://ryanschwartz.net/ is down!
Body: Hello TextDrivers. This is Ryan Schwartz. The site http://ryanschwartz.net/, hosted on one.textdrive.com seems to be down at the moment – could you please take a look? My username is ryan, so you don’t need to look it up. Thanks.

Now, if you submit a ticket via the ticket system’s web interface , then there are fields already in place for your username and the server you’re hosted on. If you know these values, please enter them – it will even set a cookie (if you allow those evil little things) and remember what you entered, so that the next time, you won’t have to type them in again.

Another example where details help us help you are problems with specific scripts or files under your account. Asking for us to take a look at “my cgi script that isn’t working”, or to “please enable WebDAV for my domain” are quite hard for us to do without knowing the /path/to/your/cgi/script, or the /path/to/your/domain.tld. If you don’t know the exact path, that’s OK! Give as much information as you can, and we’ll work out the rest.

The point is, the more detail you provide us with, the better we can do our jobs getting you the support that you need. Be as verbose as you feel is necessary, and we promise to meet you in the middle.

·:· Posted 7 April 2005, 04:05 by Ryan Schwartz to Upon our Recommendation  |  Feedback? [2]

Previously