As I described back in this article, I was getting segfault errors from eAccelerator.

I’m experiencing it on another, similarly-equipped GoDaddy VPS server. Same software versions, even, for Apache, PHP, eAccelerator, and OS, although this is not a old CMS Made Simple install.

Still, no good solutions out there, as far as I can google.

Here’s the clues I have found:

• The syntax function fun_name ($arg = array (blah)) is fatal.
• The order in which PHP extensions are loaded might matter.
• There are issues with files that get included or required multiple times via different paths.
• Software versions are just Too Old.

This is teh suckage.

Next thing I’ll try, when I have the time, is to upgrade the VPS to Fedora Core 6, and see if pushing those version numbers up a bit helps.

So, I’m working on an old RoR application, and was having a hard time getting it to work on my newer development machine.

The error dump was not at all clear:

C:\project\foo_bar_baz_quux>rake migrate --trace
(in C:/project/foo_bar_baz_quux)
** Invoke migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute migrate
rake aborted!
wrong number of arguments (1 for 0)
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/vendor/mysq
l.rb:551:in `initialize'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/vendor/mysq
l.rb:551:in `new'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/vendor/mysq
l.rb:551:in `scramble41'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/vendor/mysq
l.rb:141:in `real_connect'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/mysql_adapter.rb:316:in `connect'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/mysql_adapter.rb:87:in `initialize'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/mysql_adapter.rb:37:in `new'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/mysql_adapter.rb:37:in `mysql_connection'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/abstract/connection_specification.rb:145:in `send'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/abstract/connection_specification.rb:145:in `connection_without_query_c
ache='
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/query_cache
.rb:54:in `connection='
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/abstract/connection_specification.rb:106:in `retrieve_connection'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/abstract/connection_specification.rb:20:in `connection'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/migration.r
b:178:in `migrate'
c:/ruby/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/tasks/databases.rake:3
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `call'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `each'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `synchronize'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `each'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7
c:/ruby/bin/rake.bat:20:in `load'
c:/ruby/bin/rake.bat:20


I went through a lot of work to use older versions of Rails, etc, but none of it worked. I didn’t find much out
there that helped, either, until I finally happened across this page.

Turns out it’s one of those pernicious password / old style password hash issues with MySQL. Simplest solution for now: use no database password on the dev box.

Here’s a weird one. There was the need to extract the contents of all Javascript <script> … </script> tags from an html page, using Javascript in an Ajax-y environment^*. I tried using a similar regular expression to the one published by Matt Mecham, but found that IE threw an error. IE didn’t like the [^] construct.

So, since I knew that the pages that this would need to process would be standard strings with nothing odd in them, I substituted [^\0]. Works in Firefox and IE. I don’t know if it breaks under different encodings, though.

The other problems was conceptual — I didn’t remember that regex.exec() only gives you the first match in the resultant array (but gives you your submatches); I confused it with the behavior of string.match() which doesn’t give you your submatches. *sigh*

So the code looks like this:

var reg = new RegExp("<script[^>]*>([^\\0]*?)<\\/script>","ig");
while( (m2 = reg.exec(http.responseText))  != null )
    {
        for( i = 1; i < m2.length; i++ )
        {
           alert(i + '('+m2[i].length+')' + m2[i]);
           // do other stuff
        }
    }

(Please note that WordPress seems insistent on munging that code. Spacing, in particular, might be corrupted.)

(* note that use of the passive voice. To protect the innocent, we won’t say who/why it was needed.)

OK. I’m a bonehead. The link I provided to my backup script tarball was broken. The link is fixed.

But wait! A new version of the scripts will be posted in a few days. It’s got some bug fixes and some new features. With it, the little birds really do sing more cheerfully, and the colors really will be brighter.

(As an aside … I don’t know why none of the people who clicked on the broken link bothered to send me an email or leave a comment to tell me there was a problem. Could that all have been robot traffic?)

[Update — fixed the link!]

Automated Backups are a good thing. Automated Backups make the little birds sing, the rainbows shine, and little fauns gambol about in beautiful green forests. When computers are backed up, the butterflies flutter, the flowers bloom, and the fruit from the trees taste just a little sweeter. But when computers are not backed up, the universe becomes angry.

An angry universe is not a good thing. An angry universe makes little birds cry. An angry universe makes Cthulhu come and visit.

So. Automated backups. I’m partial to rdiff-backup because it allows me to not only back up data, but keep previous versions available. Backing up nightly doesn’t help if you accidentally overwrite the contents of a file with something, and don’t notice for a day or two. But with rdiff-backup, you can restore the version before the error.

Unfortunately, rdiff-backup really is designed for server-to-server backups, where each end of the transaction has shell access. Enter duplicity, a related project. It’s more designed for storing backups on servers that you don’t control and/or don’t trust. It allows encryption of your backup sets, as well as supporting a wider variety of protocols (ftp, scp, s3, etc.)

So with a combination of these two scripts, you can backup pretty much any POSIX-ish server to pretty much anything that you can ftp or ssh into. Still, it’d be nice if you could:

• Check that the backups completed successfully, and get email confirming that success or warning on a failure.
• Configure up all of your various backups by a simple text file, rather than remembering the different command-line formats.
• Create groups of options that can be applied to backup tasks.
• Issue commands on the backup source and destinations before and/or after the backup (good for dumping databases into a flat file, for example, and then deleting it after it’s backed up).
• Get email confirmation on completion of backups.
• Have some tools to simplify the securing of the backup process.

For these reasons, I put together this backup script, which is basically a Ruby wrapper for rdiff-backup and duplicity. It’s almost entirely configured via two human-readable yaml files.

It’s flexible, reasonably simple to use, and comes without any guarantees whatsoever. Feel free to use it yourself!

DISCLAIMER: it’s as-is. Not to be used in place of a certified Cthulhu-deterrent. Use at your own risk. To quote the duplicity page: “[it] is not stable yet. It is thought to have a few bugs, but will work for normal usage, and should continue to work fine until you depend on it for your business or to protect important personal data.” — that goes for me too, only double.