Well I setup a VM of Ubuntu 9.04 and guess what: the Parallels Tools don’t work. People have been asking for them since April, and now it turns out, Parallels 5 is in beta, where, naturally, the Tools will install. How much do you want to be that you’ll have to plunk down another $50 for that?

Guess what Parallels: forget you. I’m done. I wanted to support the underdog, and even if the performance of the VM is good, this business of not updating your products isn’t worth it.

Anyone out there trying to decide whether to go with Parallels or VMWare Fusion: go with Fusion!

Boo Parallels.

Update: A few days after I wrote this (Aug. 29, 2009) Parallels released an update (4.0.3846) where Parallels Tools can be installed on Jaunty. Sorry guys, rolling that out more than four months after Jaunty was released is too little too late.

That is, according to the PCI DSS. I read the PCI DSS Summary of Changes. It’s pretty much business as usual until you get to 5.1. That’s where you find this little gem:

Clarified requirement applies to all operating systems types commonly affected by malicious software, if applicable anti-virus technology exists.

Okay, sounds good.

Besides use of the term “anti-virus software,” changed the term “virus” to “malicious software.”

Good call, no doubt someone has tried to wriggle out of compliance using that excuse.

Deleted note stating “Systems commonly affected by viruses typically do not include UNIX-based operating systems or mainframes.”

WTF?!?!?!? Is this some kind of twisted April Fool’s prank.
::Channelling Brian Regan::

“Hey, come here; look what I put for Section Five. Did you see? I just did it as a joke but it’s going out like that. It’s already on the website. I don’t know what to do.”
“Just let it go I guess. There’s nothing you can do now.”

Raise your hand if you’ve ever seen a Unix box infected with a virus. Yeah, me neither.

It doesn’t take much imagination to figure out where this comes from. There’s a lot of big money that doesn’t like Unix boxes getting a free pass for pretty much all of Section 5 of the DSS.

To unravel this “mystery” let’s start by figuring out who *loses* money by Unix not needing anti-malware… Yeah it’s Microsoft. You have to think they’ve been shoving money in the pocket’s of PCI over this. After all, if businesses realize that they can save money by switching to Linux, especially in the current economic climate, they’re gonna do it. And what business wouldn’t, switching to Linux saves you the outrageous anti-malware fees and the exorbitant Windows license fees.

Now, besides Microsoft, who stands to benefit from this? Of course the answer is the anti-malware venders: Symantec, McAfee, TrendMicro, Sophos, AVG (formerly Grisoft), Kaspersky (I’m not going to dignify them with links). If you want some good laughs go read what these guys have to say about Unix viruses.

McAfee, circa 2006:

Macintosh platform vulnerability discovery rates have increased by 228 percent in the past three years alone…

Translation: Your baby is dead!
To their credit, they did follow that up with:

…from 45 found in 2003 to 143 in 2005

Holy hell! Please McAfee, take my money, just protect me!

Sophos, February 13th, 2008, says of the Linux/Rst-B virus:

Analysis of malware in Sophos’s Linux honeypots have shown almost 70 percent of the infections are due to this six-year-old malicious program.

Translation: Your baby is dead!
Holy hell! Nooooo! Not the honeypots! Those things highly secure! It takes mad 733t skillz to pwn a honeypot! Lots of critical thinking going on there.
In that same press release, I liked this:

“…we hope that Linux users who aren’t running security will at least run this tool to find out if they are infected with this granny virus.”

Ha ha, “granny virus,” awesome. And are you “running security” on your Linux box? What exactly does that mean? No matter, I wrote my own Linux/Rst-B scanner, check it:

#!/usr/local/bin/bash
echo "Scanning for Linux/Rst-B virus..."
sleep(5)
echo "No virus detected!"

To Sophos’ credit the did put this in:

Hackers typically gain control via weak SSH password or some other vulnerability.

But that’s it. The rest of the time it’s “Linux viruses are taking over! Give us lots of money, and we’ll protect you!”

Here’s the only place where you can argue Unix anti-malware makes sense: email and file servers. Let those servers be good Samaritans and catch the Windows viruses before they are spread around. It’s a waste anywhere else.

That being said, one could argue running anti-malware on a Unix box does more harm than good. It’s more than the obvious sucking up resources. My biggest problem is running anti-malware on a box adds one more attack vector an attacker has. Historically, there have been many instances where anti-malware software has made people more vulnerable, my favorite being this one.

Finally, I want to add that viruses are already becoming passe. Okay maybe not for Windows, but certainly Unix. Just look at the pwn2own contest. Yeah, the Mac fell in like two minutes, but it had *nothing* to do with a virus, or any kind of malware that’s going to be detected. And that’s the point. Linux, OS X, and other Unix OSes are not going to be taken by traditional malware. Any attacker worth his salt is gonna do it through the web browser. Email: lame. Open ports: too much work. SSH: maybe. Web browser: booyah!

The web browser is the ultimate vector, because you as a user, are giving some portion of control of your computer to a remote machine. Just look at the recent OS X viruses, they change your system network settings so your traffic goes to the bad guys site. Oh snap!

At any rate, PCI removing the statement that Unix systems are not commonly affected by malware has no basis in reality and exists *soley* to make big, slow, outdated, technology companies more money.

That’s bad enough in and of itself. But what makes it worse is the fact that PCI auditors are just an army of box ticking robots. Seriously. Trying to reason with one is an exercise in futility.

Now the worst part: There’s nothing we can do about it. PCI can come up with any bull shit, cockamamie rule they feel like, and you have comply or you’re out of business. Rant off.

P.S. – To any box ticking robots that read this, get off your Huffy and write to me. I’m not an auditor, what’s your side of the story.

“It was just another day at the office, until suddenly…” I wanted to run Warehouse. It turns out that things get (just) slightly hairy when you need to use the native bindings for a library, in this case Subversion/SWIG.

I ran rake warehouse:bootstrap without incident, but as soon as I submitted the ‘install’ form, it died. This is what I found in the log:

ActionView::TemplateError (/opt/ruby-enterprise/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/active_support/dependencies.rb:478:in `const_missing': uninitialized constant Repository::Svn) on line #23 of repositories/index.html.erb:
20:

21:     <%= link_to h(repo.name), hosted_url(repo, :admin) %>
22:     <%= repo.path %>
23:   <% if repo.sync? %>
24:   <% unless repo.sync_progress == 100 %>
25:
26:


    /srv/rails/entp-warehouse-78376218f92e6bdf8b72993d9caa384e5d4a5c66/vendor/plugins/expiring_attr_reader/lib/expiring_attr_reader.rb:32:in `silo'
    /srv/rails/entp-warehouse-78376218f92e6bdf8b72993d9caa384e5d4a5c66/app/models/repository.rb:137:in `retrieve_silo'
    (eval):1:in `silo'
    /srv/rails/entp-warehouse-78376218f92e6bdf8b72993d9caa384e5d4a5c66/app/models/repository.rb:100:in `eval'
    /srv/rails/entp-warehouse-78376218f92e6bdf8b72993d9caa384e5d4a5c66/vendor/plugins/expiring_attr_reader/lib/expiring_attr_reader.rb:32:in `silo'
    /srv/rails/entp-warehouse-78376218f92e6bdf8b72993d9caa384e5d4a5c66/app/models/repository.rb:100:in `sync?'
    /srv/rails/entp-warehouse-78376218f92e6bdf8b72993d9caa384e5d4a5c66/app/views/repositories/index.html.erb:23:in `_run_erb_47app47views47repositories47index46html46erb'
    /srv/rails/entp-warehouse-78376218f92e6bdf8b72993d9caa384e5d4a5c66/app/views/repositories/index.html.erb:19:in `each'
    /srv/rails/entp-warehouse-78376218f92e6bdf8b72993d9caa384e5d4a5c66/app/views/repositories/index.html.erb:19:in `_run_erb_47app47views47repositories47index46html46erb'
...

Naturally I had installed the bindings using sudo apt-get install libsvn-ruby1.8 so they were available to the default Ruby (located in /usr/lib/ruby), but not Ruby Enterprise Edition (located in /opt/ruby-enterprise), which the application runs on.

My solution was to simply symlink the Subversion bindings into Ruby Enterprise Edition. A quick look in the libsvn-ruby package (sudo dpkg -L libsvn-ruby1.8) shows us what we’re dealing with:

...
/usr/lib/ruby/1.8/i486-linux
/usr/lib/ruby/1.8/i486-linux/svn
/usr/lib/ruby/1.8/i486-linux/svn/ext
/usr/lib/ruby/1.8/i486-linux/svn/ext/core.so
/usr/lib/ruby/1.8/i486-linux/svn/ext/client.so
/usr/lib/ruby/1.8/i486-linux/svn/ext/delta.so
/usr/lib/ruby/1.8/i486-linux/svn/ext/fs.so
/usr/lib/ruby/1.8/i486-linux/svn/ext/ra.so
/usr/lib/ruby/1.8/i486-linux/svn/ext/repos.so
/usr/lib/ruby/1.8/i486-linux/svn/ext/wc.so
/usr/lib/ruby/1.8/svn
/usr/lib/ruby/1.8/svn/client.rb
/usr/lib/ruby/1.8/svn/core.rb
/usr/lib/ruby/1.8/svn/delta.rb
/usr/lib/ruby/1.8/svn/error.rb
/usr/lib/ruby/1.8/svn/fs.rb
/usr/lib/ruby/1.8/svn/info.rb
/usr/lib/ruby/1.8/svn/ra.rb
/usr/lib/ruby/1.8/svn/repos.rb
/usr/lib/ruby/1.8/svn/util.rb
/usr/lib/ruby/1.8/svn/wc.rb
...

The key directories are: /usr/lib/ruby/1.8/i486-linux/svn and /usr/lib/ruby/1.8/svn. So we’ll make them available to /opt/ruby-enterprise like so:

cd /opt/ruby-enterprise/lib/ruby/1.8
sudo ln -s /usr/lib/ruby/1.8/svn
cd /opt/ruby-enterprise/lib/ruby/site_ruby/1.8/i686-linux
sudo ln -s /usr/lib/ruby/1.8/i486-linux/svn

After that, just restart Apache (apache2ctl restart), and it should be working. Note, a simple touch tmp/restart.txt won’t work, because that doesn’t reload the libraries. You actually need the /opt/ruby-enterprise/ruby process to restart.

Theoretically this same approach should work for any native bindings you need to be available to Ruby Enterprise Edition.

alternatives --install /usr/bin/java java /usr/lib/jvm/jdk1.6.0_04/bin/java 99

In this case I used the self extracting file (not the RPM) from Sun, and moved the directory to /usr/lib/jvm/jdk1.6.0_04.

Update:
To finish it off, you need to do this:

alternatives --config java

There are 2 programs which provide 'java'.

  Selection    Command
-----------------------------------------------
*+ 1           /usr/lib/jvm/jre-1.4.2-gcj/bin/java
   2           /usr/lib/jvm/jdk1.6.0_04/bin/java

Enter to keep the current selection[+], or type selection number: 2
[root@localhost jvm]# java -version
java version "1.6.0_04"
Java(TM) SE Runtime Environment (build 1.6.0_04-b12)
Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing)

Sometimes SELinux will prevent something from launching (e.g. Eclipse), and you’ll have to run a command like:

chcon -t textrel_shlib_t /usr/lib/jvm/jdk1.6.0_04/jre/lib/i386/clientlibjvm.so

Enter the Bash Launcher Loop:

#!/bin/bash

# maximum number of attempts to launch
max_launches=2
# maximum number of launches allowed in $reset seconds
runaway_max=8
# minimum
min_seconds=1
# number of seconds to let process run before reset
reset_seconds=10

# number of attempts to launch
launch_attempts_count=0
start_time=`date +%s`

while true; do

  echo "Executing ($launch_attempts_count)..."
#  sleep 1

  # increment the number of launch attempts
  launch_attempts_count=$(($launch_attempts_count+1))
  # get the number of seconds since the start time...
  time=$((`date +%s`-$start_time))
  # if we launched more than $max_launches in less than $min_seconds, then
  # for some reason the process can't start, so exit
  if [ $launch_attempts_count -gt $max_launches -a $time -lt $min_seconds ]; then
    echo "Too many launches!"
    exit 1
  fi
  # If we haven't exceeded the threshold for failed starts, but
  # the process isn't running long enough to reset the counters,
  # we can guess there's a problem that keeps causing the process
  # to crash, so we should probably give up for now
  if [ $launch_attempts_count -gt $runaway_max ]; then
    echo "Process keeps crashing"
    exit 1
  fi
  # If the process has been running for more than $max_seconds, then
  # we're going to assume it was working properly, so reset the counters.
  # Normally, $max_seconds would be set to something like 3600 (1 hour).
  if [ $time -gt $reset_seconds ]; then
    launch_attempts_count=0
    start_time=`date +%s`
  fi

done

The script above will stop trying to launch the process if:

• if there are more than 2 launch attempts in 1 second (printing “Too many launches!)
• if there are more than 8 launch attempts in 10 seconds (printing “Process keeps crashing!)

If the process is relaunched less than 8 times in 10 seconds, the $start_time and $launch_attempts_count will be reset, thus starting over.

To see this in action just run the script like it is, and the output will be:

Executing (0)...
Executing (1)...
Executing (2)...
Too many launches!

Now uncomment line 19 (# sleep 1), and the output will be:

Executing (0)...
Executing (1)...
Executing (2)...
Executing (3)...
Executing (4)...
Executing (5)...
Executing (6)...
Executing (7)...
Executing (8)...
Process keeps crashing

Finally, change line 19 from sleep 1 to sleep 2, and the output will be:

Executing (0)...
Executing (1)...
Executing (2)...
Executing (3)...
Executing (4)...
Executing (5)...
Executing (0)...
Executing (1)...
Executing (2)...
Executing (3)...
Executing (4)...
Executing (5)...
Executing (0)...

And so on, until you hit ctrl+c.

Obviously those values are just for demo purposes. Better production values would be:

max_launches=2
runaway_max=2
min_seconds=1
reset_seconds=3600

This tells the script to exit if there are more than two launch attempts in one second or more than two in one hour, otherwise it will just keep running.

You’re supposed to have the best user interface in the world. But I found a fatal flaw. There’s no way to get windows back on the main screen.* For me it was Parallels Desktop Snapshot Manager; I used it one time when I had a second monitor hooked up.

Why is this not directed at Parallels themselves? I understand that in a perfect world all software would “do the right thing,” in this case, figure out if it’s drawing windows off screen, and remedy the situation. I’m guessing this is what Apple’s software does, since their software doesn’t seem to suffer from this problem. But we don’t live in a perfect world, so Apple you should give me a way to deal with this. GNOME allows me to manipulate windows with keyboard shortcuts? I’ll bet Win-blows will let me do it. Why can’t Aqua?

[end-rant]

* – Actually there is a way: go in and delete the plist file(s) for the application in question, but that is entirely too complicated for most users, and just plain sucks.

 * Starting web server (apache2)...
Syntax error on line 141 of /etc/apache2/apache2.conf:
Invalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration

After a bit of Googling, I found this bug in Ubuntu. The lame part is it’s not been fixed, and probably won’t be since the focus is on Gutsy…

Anywho, it suggested loading mod_authz_host, like so:

sudo a2enmod authz_host

But when I tried to start Apache again, I got this:

 * Starting web server (apache2)...
Syntax error on line 145 of /etc/apache2/apache2.conf:
Invalid command 'TypesConfig', perhaps misspelled or defined by a module not included in the server configuration

Grrr… Another Google search led me to this useful page, which told me the missing module here is mod_mime. Load that like so:

sudo a2enmod mime

And you should see:

 * Starting web server (apache2)...        [ OK ]

First, I installed the MySQL “Server”, “Client”, and “Headers and Libraries” binaries. Next, after Ruby and RubyGems were installed, I did this:

sudo gem install mysql --  --with-mysql-include=/usr/include/mysql --with-mysql-lib=/usr/lib/mysql

Voila!

find . -name "*.rb" -exec sed 's/oldstring/newstring' {} \;

find . -name "*.yml" | xargs perl -pi~ -e 's/oldstring/newstring/g;'

Essentially they do the same thing, the first uses sed, the second uses Perl. Watch out what you’re doing with these! If you use find . -type f in a directory managed by Subversion, prepare for some headaches.