Secure Connection Failed An error occurred during a connection to xyz-abe.com SSL received an unexpected Change Cipher Spec record. (Error code: ssl_error_rx_unexpected_change_cipher)

Currently the package in question is still masked in gentoo, so upgrade as follows:

# echo ‘=dev-libs/openssl-0.9.8h-r1′ >> /etc/portage/package.unmask
# emerge -av openssl

Once done, follow the instruction given by portage to rebuild the packages still using the old versions of OpenSSL.

Thanks David

Rails 2.1 @ Rubyforge
Rails 2.1 @ github

Enjoy!

The changes made by Peter Wagenet were simple and very useful, thanks Pete!

I’ll start working on specs for the project closer to the end of the week, for now my focus is on getting BIND DLZ on Rails ready for its first public appearance.

Now some of us develop fairly intricate systems using Rails. Systems that have long running reports, or systems that connect to other systems to execute commands, or obtain information. Whatever the reason, somethings just can’t complete within 60 seconds, and if your users understands the complexity of the background tasks they’ll quite happily press a button and go make coffee while the server crunches away at the reports.

I head one such project, and had the most interesting issue I just solved. And it involved reading a lot on nginx’s fine print…

Meet proxy_next_upstream, an nginx directive that is very very useful, but a pain in the ass at the same time. Remember the opening example of creating a large report from loads of data? This can easily take longer than 60 seconds to complete. Lets analyze what happens in this case:

nginx sends the request to any one of the mongrels specified in upstream. It will wait for the mongrel to complete and return a response that will be sent back to the client. However, it will not wait forever, it will wait for proxy_read_timeout which defaults to 60 seconds. What happens after 60 seconds. You might be inclined to think that the timeout will be communicated to the client in the form of a nginx error… I did. It appears not.

By default, proxy_next_upstream is set to “error timeout“. Reading the fine print reveals that nginx would retry the request to the next available upstream proxy (a.k.a mongrel), causing it to just lockup again with a fresh request for a new report. This will continue until all your upstream mongrels are busy generating the same massive report before nginx gives up.

This isn’t nginx’s fault, on the contrary I think its an awesome feature. Especially if you reflect back on that massively scalable Rails application you’re building. You can have nginx retry on a 500, 503 or 404 amongst others. So some errors can be hidden from the client, especially if a replication slave goes down briefly or has some lag from the masters and causes a 404 inside an action. Even if monit is busy taking down those resource hungry dogs, you can have nginx retry on behalf of the client without them noticing.

Be cautious, this isn’t exactly the kind of thing you can test in a function/integration test. And never tamper with your production nginx configurations without gunning it on your staging servers first.

Get the code via from here:

git clone git://rubyforge.org/tablelessmodels.git
git clone git://github.com/kennethkalmer/activerecord-tableless-models.git

Leaps like this make sharing code a breeze, and makes one think how far you can still go with git before reaching the limits.

I recently picked up that one of my servers in a Rails cluster had plenty more release directories than its peers, and they were very old. I was baffled, how does this happen when I run “cap deploy:cleanup” religiously after a release has stabilized… I decided to figure out why, and how to dodge it. Who knows how many other release directories are scattered around the network.

It seems that cap gets the directory contents of the “releases” directory from the first server in its internal list. It then uses that directory content to remove stale releases from all servers. This is a sane approach, but things do go wrong and releases will build up over time.

Running the task once for every host seems the quick solution without messing with cap itself.

$ cap deploy:cleanup HOSTS=10.0.0.1

This gives each individual host a fresh start. From here, lather, rinse, repeat.

Later

$ sudo gem install cheat

$ cheat git

$ cheat gitsvn

No need to open a browser, search through delicious or even google.

Hope it helps make git and/or git-svn more digestible.

UPDATE (2008-04-29)

I got beaten to the punch on using cheat, thought I’d just add some more links for your enjoyment

Git and Ruby on RubyInside
Printable Git Cheat Sheet (scarily similar to the Mercurial ones)

Mplayer is a powerful open source media player. Capable of playing a lot of different formats out the box. I installed it using yum from Dag’s repository and it was a snap really. It didn’t take to playing my DivX files, but that was some wierd display error on my test box (still uses a 3Dfx Banshee card).

I then recalled something called XINE and a quick Google revealed that it’s another media player. Took a chance and I saw that Dag had these as well, let yum do the dirty work and of we go.

Two players that can both play DVD’s and a lot of other formats was well. They work well and the quality is great considering my test box is only a 667Mhz box with 256MB memory and a rusty old 3dfx card.

For people looing at plating other formats like RealMedia, get a copy of HelixPlayer from RealMedia. It looks nice, could find a file to test it with though. It comes standard with Fedora Core 3, so just open the package manager and let rip.

On the topic of MP3’s, Flash, JAVA and other missing software, why not visit the The Unofficial Fedora FAQ. The author of this website went to great lengths to help people with the same queries. It’s all unofficial, but it works. It’s helped many FC noobs to get their distro up to speed. And for those still using Core 2 and Core 1, the old FAQ’s are still available on the site, though I doubt their maintained anymore.

If you’re like me and use yum for evey attempt at installing new software, you should most definitely visit Dag Wieers’ website. All the packages you can imagine for Fedora Core and Red Hat Linux. It’s in the true spirit of OSS that Dag releases these packages, asking for attribution and something from his wishlist. This is nothing if you look at the effort going into maintaining the site and over 1400 packages.

Hopefully you now too realise that Fedora Core is as powerfull as any other linux, and has an equal abundance of software available to it’s users as any other linux.

To find out why Red Hat did not put MP3 support in any of the Fedora Core releases, visit mp3licensing.com. It’s all about licensing the software, and they want to keep Fedora Core free. Why do other distros support MP3 playback then? Ask your lawyer.

Have a look at Nikto. From the website:

Nikto is an Open Source (GPL) web server scanner which performs comprehensive tests against web servers for multiple items, including over 3100 potentially dangerous files/CGIs, versions on over 625 servers, and version specific problems on over 230 servers. Scan items and plugins are frequently updated and can be automatically updated (if desired).

In todays world no server is safe, and with exploits now being discovered in more and more websites it doesn’t improve the admin’s odds.