If you’ve been following development trends in the past couple of years you have surely heard of Node.js by now. Node.js has been getting all sorts of attention lately, some of it has been positive and some of it has been, shall we say… critical. I think the reason many people seem to love Node.js is because it seems to offer a way for backend/server-side developers and front end developers to potentially work in the same language: the easy to learn, ubiquitous and well understood Javascript.

One of the first things a developer wishes to do when trying Node.js for the first time is to see how easy it might be to create a web server. In fact, many tutorials, documentation pages and blog posts provide instructions on how to code a simple “Hello World” web server to demostrate just how easy it is to create a fast webserver with Node.js. Building on this, one can quickly arrive at a very popular library used for creating web applications: Express.js. I installed it with the use of the fantastic npm tool, a package manager for Node.js (which was recently bundled with the Node.js installation itself). After reading the documentation for a bit, I was quickly able to set up some routes for my webserver to be able to respond to various different types of requests. Express also allows for all sorts of configurability. It is able to integrate with HTML templating tools such as , allows for custom “middleware” to modify or inspect the HTTP request object, logging, and all sorts of other powerful features. I really encourage you to have a look at Express.js. It’s wonderful. Really.

So, fast forward a few weeks and I begin working on a RESTful API and have decided to go with Node.js and Express.js to power the implementation. With Express’s route handling, nothing could be simpler for assigning URLs to functions to implement the API. Since the REST service was going to be dealing with JSON exclusively, I needed a way to easily grab any JSON documents that would be PUT or POSTed to the various URLs that I desired. Express has a mechanism that allows for the extraction of that sort of content from HTTP requests called bodyParser. With the use of bodyParser (an Express.js middleware), the request object will be equipped with a new property called rawBody, which is perfect for obtaining POSTed JSON with minimal hassle.

Unfortunately, in a recent upgrade of Express.js, the rawBody property in the request object was silently removed. I think it’s telling that something as important as this was removed so casually and with very little documentation. Personally, I think it should have waited for a major release or, perhaps, been much better publicized as a “heads up” to the user community. This is the sort of thing I think folks getting serious with Node are going to have to learn to deal with for a while until the project stabilizes in the years ahead.

Needless to say, the loss of rawBody had a catastrophic effect on the implementation I was working on and I quickly reverted the version of the libraries I was using backwards so that rawBody was restored. I resolved to look into it further at a later date.

Here’s how to add rawBody back again if you need it like I did: make your own custom Express.js middleware

     // For Express 3 (won't work with express 2.x)
     var app = express();
     app.use (function(req, res, next) {
         var data = '';
         req.on('data', function(chunk) { 
            data += chunk;
         req.on('end', function() {
             req.rawBody = data;

     // Now your routes from here down
     app.get('/something/:id', something_handler.get_something);

What’s happening is that we have injected a custom middleware function that sets the encoding to UTF-8, then sets up callbacks that accumulate any sent JSON data into the “data” variable. When the request is finished, the contents of “data” are complete and req.rawBody is defined before next() is called, which passes control to any subsequent middleware functions.

The critical thing here is that this code must be added BEFORE your routes are setup. If you use the middleware afterwards, it won’t work properly…

So I must confess, I took the easy way out and installed the Condor resource scheduler via rpm. Seems like the folks that put Condor together at the University of Wisconsin-Madison have in recent years decided to create easy to install packages for Linux users including .deb files for Debian and .rpm files for Red Hat systems. That’s a huge time saver of course, especially if you want to get up and running quickly, or if you are provisioning multiple Condor machines and don’t necessarily want to use a shared filesystem for the installation. Very nice.

So, I downloaded the 64-bit RHEL 5 rpms from the downloads page and installed them on two virtual maachines. One became the Condor “master”, running all the daemons: COLLECTOR, MASTER, NEGOTIATOR, SCHEDD and STARTD. The other VM became a submitter and executor only, running just MASTER, SCHEDD, and STARTD daemons. After having quickly built a Condor pool this way, I listed the files in the rpms to see what else was included, and to my delight, the package builders were kind enough to include the DRMAA libraries as well. For those of you who aren't familiar with DRMAA, it's an API for how to talk to distributed resource schedulers such as Condor, Sun Grid Engine (now Oracle Grid Engine), and others such as LSF and Torque. This was cool because I could easily test if my code was going to run unchanged and submit jobs to my nascent Condor pool.

And… It worked. However, I noticed that I was getting of a lot of debugging related output on my terminal as I ran my code. Tracing backwards, I quickly concluded that the DEBUG messages had to be coming from the compiled shared object code that came with the Condor rpm in libdrmaa.so. Although the DEBUG messages are nice, I don't want to see them in a production environment. Here's how to get rid of them.

The Condor rpm includes the tarball containing the drmaa source code:

$ rpm -q --filesbypkg condor | grep drmaa
condor                    /usr/include/condor/drmaa.h
condor                    /usr/lib64/condor/libcondordrmaa.a
condor                    /usr/lib64/condor/libdrmaa.so
condor                    /usr/src/drmaa/drmaa-1.6.tar.gz

I copied the drmaa .tar.gz file to a working directory and unpacked it. After running ‘configure’ and ‘make’, one should see a newly created header file called config.h. This is the file that gets included by auxDrmma.h when the compiler is called with the -DHAVE_CONFIG_H option. The relevant lines in auxDrmaa.h are:

        #include <config.h>

So, I simply edited the “#define” out of the config.h file that was setting DEBUG. Once I ran “make”, I basically had a new version of the libdrmaa.so file in my current directory. The next step was to overwite the .so that was bundled with the RPM, so I copied my new custom libdrmaa.so to /usr/lib64/condor and created a symbolic link (/usr/lib64/libdrmaa.so.1.0) to point to it. <<Abra Capocus, Hocus Cadabra>>, DEBUG messages gone…

A much better solution would be to alter the .spec file used to create the RPM such that DEBUG messages are suppressed by default and so that the /usr/lib64 symlink is created. This would obviate having to make these changes manually on each machine that needs to use the DRMAA library. That’ll be for another post though. Perhaps by then the Condor developers will put out updated RPMs where these issues are addressed.

So let’s say you want to restrict a bunch of data or pages on your website to users that have agreed to what is commonly referred to as a “Terms of Service” agreement, or ToS. These agreements are typically filled with lots of legalese and in a very small font size. Very few people people read such agreements in their entirety, however, they are an important requirement in many scenarios of information dissemination on the internet. What are some scenarios where this could be important?

  1. Software distribution. You might want to get a user’s agreement that he or she will not redistribute an application your company or organization has created without written approval.
  2. Media and content distribution: Perhaps you publish music, video, online games or articles and blogs online and wish to protect that content with a ToS page.
  3. Forums and chat: You may wish to obtain consent from your users that they will not engage in abusive behavior in your online community.

The possibilities are basically endless and the aforementioned examples are only the most obvious scenarios. However, to make this work (and in many jurisdictions to make it legally enforceable) one should not be able to simply bypass the ToS page and link directly to the URL of the data that is being protected. A naive web administrator might throw up a ToS page as an intermediate navigation stop before arriving at the download area containing links to the data. However, if anyone has a bookmark, or enters the direct URL, or publishes the direct link to the data online, then the data can be easily retrieved without ever agreeing to your organization’s terms. Good luck enforcing your ToS in court if necessary…

For this post, I’m going to assume that you are using the Apache web server. In order to prevent direct linking and access to your content, we somehow have to instruct Apache not to serve it until some condition is satisfied. There are many way of doing this of course. One can write a custom Apache module or handler for the task in a language such as C, or Perl if you are using mod_perl. However, we can also use a very useful module called mod_rewrite to help us out. A nice advantage here is the mod_rewrite is automatically included and enabled by default in many Apache installations. We are going to configure mod_rewrite to check for the existence of a special cookie that our ToS page will set. If you have the cookie (and the correct value in it), Apache will let you have the data. If not, Apache will redirect you to the ToS page. Sounds easy right? Using cookies for this task has some additional benefits:

  1. We can set the cookie to expire whenever we like. Let’s say, 90 days. That way the user doesn’t need to accept the ToS every single time they want access to the data, just every 90 days… One can also make the cookie permanent if that behavior is desired.
  2. All browsers of any consequence support cookies, even the text based browsers and download utilities such as wget, lynx and w3m.

Let us assume that the files we wish to protect all have the same extension: .tgz. In the Unix world, .tgz, or .tar.gz files are very common and are simply compressed archives of data, conceptually similar to .zip for you MS Windows users out there. This is a trivially easy example because we can define a mod_rewrite configuration on the web server as follows:

RewriteEngine on
RewriteCond %{REQUEST_URI} \.tgz$
RewriteCond %{HTTP_COOKIE} !tos=accepted
RewriteRule ^(.*) /terms-of-service.html [R,L]

RewriteLog /var/log/httpd/rewrite.log
RewriteLogLevel 9

The first line simply activates the rewrite engine. The second and third lines apply conditions as to when the RewriteRule on line 4 goes into effect. Both conditions need to be satisfied. The first condition of line 2, is that the resource requested needs to end in .tgz. Please consult the documentation on regular expressions for why we need to escape the “.” with a backslash and what the trailing $ is for.

The second condition states that we must NOT have a cookie called “tos” with the value “accepted” in it. More on how a user acquires the cookie later.

So, with this configuration, if the server receives a request for a .tgz file and the client does not have the required cookie, the RewriteRule will be triggered. Basically, it redirects us to the terms-of-service.html page. The [R,L] flags specify the type of redirect used and ensure that this is the last rule to apply. The page redirected to doesn’t have to be a .html file of course. It could just as easily be a .php, or .jsp file…

You may ask, what if the user disables cookies or clears the cookies every time the browser is exited? Well, in the former, the user will not be able retrieve the data. It’s important that such limitations be discussed openly and up-front. This is an unfortunate consequence of relying on cookies to accomplish such a task. However, cookies have become such an integral part of modern web usage that their use hardly constitutes a radical departure from the norm. One can view a user with cookies disabled as a special case of a user that wishes to implicitly decline your ToS… One can add a note on the ToS page itself describing how cookies are required to be enabled for the authorization mechanism to work. In the case of a user that routinely or automatically flushes cookies away, that user will simply need to agree to the ToS each time they wish to access or download content.

Giving the user the Cookie
Once the server has been configured, to deny (redirect) requests for data that aren’t provided with the cookie, it’s time to consider just how we will grant the cookie to a user that accepts the Terms of Use/Service. Fortunately, this is a task that can be done with JavaScript. If you’re a fan of JQuery like I am, it can be done even more elegantly with the JQuery cookie plugin, found here:


Our page will have two buttons, one to accept and one to deny the ToS. The markup should look something like so:

<form action="#" method="get">
    <input id="accept" type="button" value="Accept" />
    <input id="decline" type="button" value="Decline" />

The exact formatting of the form and inputs may depend on the doctype you’ve selected for your site and pages… Once this is inserted into the appropriate place beneath the text of your conditions, it’s time to wire the buttons up with a bit of JavaScript. We’ll create a new JavaScript file called tos.js:

$(document).ready(function() {
  $("#cancel").click(function () {
  $("#accept").click(function () {
    // Set a cookie to expire in 90 days.
    $.cookie("tos", "accepted", { path: '/', domain: ".example.com", expires: 90 });

This code registers handler functions for when each button is clicked. In the terms-of-service.html file you would simply have to include the JQuery file, the JQuery cookie plugin, and the tos.js file, like so:

  <script type="text/javascript" src="/js/jquery-1.4.1.min.js"></script>
  <script type="text/javascript" src="/js/jquery.cookie.js"></script>
  <script type="text/javascript" src="/js/download_tos.js"></script>

To recap, what we have achieved is a page where if the user has hit the “Accept” button, then he will be issued a cookie that the web server will honor by allowing the download of the content, .tgz files. If the user presses the “Decline” button, the he will be forwarded to a configurable alternate page, in this case the index.html page. One really can’t get around this system by linking or navigating directly to the content. However, a skilled person could craft the cookie manually and post the cookie along with the request without ever having agreed to the ToS. However, to do that the user must examine the JavaScript and go through the trouble of crafting the cookie manually… However, protecting your content from being republished by users even though they agreed to the ToS, well, that’s tough… You might want to ask the RIAA about that.

Battery Cover

Fig 1: Battery Cover

Let me just preface things by stating that I’m not a professional mechanic. However, changing spark plugs and wires is something I believe anyone with even a modicum of ability should be able to do without resorting to paying an exorbitant amount to a dealership. Having said that, the author takes no responsibility in the event the reader disables his or her car. Attempt this work only if, like me, you have steelballsafety, so to speak.

Still with me? Very well. Find a comfortable place to work with your car. You should have a clean area that is free of clutter. The first thing we need to do is disconnect the power if we’re going to be replacing the spark plugs. You knew that the spark plugs produce their sparks because of electrical power fed to them, right? Open the hood. On the passenger side of the car, you’ll see the battery cover as shown in Figure 1. Unclip the 3 fasteners you see at the rear of the cover and you should be able to remove the cover entirely from the car. Set it aside someplace safe and and admire your battery. It should look like something in Figure 2. Using a socket wrench with a 10mm socket attachment, loosen the nut clamping the negative (black) terminal in place. You should then be able to slip the terminal off the battery’s post. It may be a bit difficult to do this because it might not have moved in years (or at all). Have no fear. Muscle it out of there but do be careful not to damage the battery post sticking up out of the battery. Make sure you don’t contact anything metallic with the exposed terminal. What I did to ensure no contact was immediately cover the lead with a plastic bag and tied it around the terminal. Now that you’ve disconnected the battery, your car does not have any electrical power. You’ll need to reset things like the clock once we’re done and perhaps the security code as well.

Fig 2: Battery

Fig 2: The Battery

Fig 3: Engine Cover

Fig 3: Engine Cover

Alright, now let’s have a look at the engine. Toward the front of car and the engine cover, you should see a panel with the Mercedes logo. Grab a hold of that panel. That’s the front engine cover. There are actually two panels connected to each other. We’re removing the front panel first. Grab it and lift up, then pull it forward toward the front of the car. You may need to unscrew the engine oil cap to ensure it comes completely free. Once it’s free, only the rear engineĀ  cover should be in place. The overall picture should look something like what you see in Figure 3, but perhaps a bit cleaner as I had not cleaned the engine in quite some time. Take note of the two clip holders on both sides of the capital “M” of Mercedes on the long gray bar. The front engine cover clips into and out of those holder. Now you’ll notice that there are two large plastic tubes connected to the sides of the remaining engine cover at the front. These are air intakes and need to be disconnected. With gentle twisting motions, disconnect those tubes. Figures 4 & 5 illustrate what the intakes look like after they have been disconnected. After the intakes have been disconnected, grab the front of the remaining rear engine cover by the rectangular tabs pointing to the front of the car and lift it off. The engine cover is held in place via tension with special rubber tipped knobs, so it should just pop off without too much trouble. For now, put the rear engine cover aside where you put your battery cover. We should now have access to the engine as in Figure 6.

Passenger side air intake

Fig 4: Passenger side intake

Driver side intake

Fig 5: Driver side intake

Exposed Engine

Fig 6: Exposed Engine

Now the fun begins. On each side of the engine, you’ll see 3 black square shaped boxes with cables connected to them on the top and bottom. They are each attached to the engine by a Torx #30 screw. These are electrical components that need to be unplugged and detached from the engine. Figures 7 & 8 show these in detail and how they are situated to the rear of the air intakes that we previously disconnected.

Passenger side coils

Fig 7: Passenger side coils

Driver side coils

Fig 8: Driver side coils

Closeup of coils

Fig 9: Closeup of coils

Have a good look at these for a moment, then start unclipping the electrical components from the top of each coil box. Be careful when doing this and don’t apply too much pressure or you might damage the clips. Take your time here. Figures 10 & 11 demonstrate how the clips disengage. I recommend that you do the passenger side first, as it has a bit more room to work in than the driver side. Remove all the clips from the top of the boxes and pay special attention to which clip goes with with which box. We’ll need to restore these in exactly the same order when we’re finished replacing the plugs and wires.

Unclipping the coil connector

Fig 10: Unclipping the Coil Connector

Coil Connector Unclipped

Fig 11: Unclipped Coil Connector

Once all the clips are removed from the 3 passenger side boxes, use your Torx #30 to remove the screws that are holding the boxes to the engine. After each is screw is removed, keep it in a safe place so you don’t lose it. I suggest depositing these small parts and screws into a cup or saucer that you keep nearby. As each screw is removed, you’ll want to remove the two wires that connect to the spark plugs beneath. This is a bit tricky because it will require a bit of strength and dexterity. Man up here now. This wasn’t a job for pansies and you’re not a pansy are you? Good. Get yourself a 17mm spanning wrench to detach and remove the plug wires from the spark plugs that are screwed into the engine. Your local auto parts store has these. Try to get the longest one you can, but it should be 17mm as this is the perfect size for unplugging the spark plug wires from the heads of the plugs. Make no attempt to unplug the wires from the coils, as that is unnecessary. You should only need to do that if you’re replacing the wires as well. DO NOT attempt to unplug the wires by pulling them out by grasping the wires. Yanking on the flexible parts of the wires will almost certainly damage them. If you’re replacing the wires, this is obviously less of a concern, but if you’re retaining them, make sure you use the open end of the 17mm wrench to pry them out by the hard metal collar near the plugs. Use the engine block as a fulcrum and apply firm even pressure until you feel the wire harness pop off. Don’t worry about damaging the engine this way. It’s stronger than a herd of buffalo and you’re unlikely to harm it unless you’re some sort of titan. Figure 12 illustrates the process of extracting the wires with the spanning wrench. Figure 13 shows what the engine looks like after 2 coils have been removed. Figure 14 shows the passenger side coils after they have been completely removed from the engine.

Plug wire extraction

Fig 12: Plug wire extraction

2 coils removed

Fig 13: After 2 coils removed

Now that the coils from the passenger side have been removed, we’re finally able to unscrew the old spark plugs. Personally, this is my favorite part. Get your spark plug socket wrench ready for action. Hopefully, you have one with an articulating ball and socket joint for greater flexibility for greater access, but others should work fine as well. Working from the front of the car to the rear, reach down below the engine with the wrench and insert the socket over the tips of the plugs. It will be difficult to actually see what you’re doing, but you should be able to tell, by feel, when the socket is securely over the plug. Once in place, ratchet the plugs out. You’ll be able to notice when the plug is loose enough to simply slide out. Figure 15 shows what your old spark plugs may look like. After all the old old passenger side plugs are removed, insert and tighten your replacement plugs. Most of the tightening is done with the same socket wrench you used for removal, but once you feel the tightening start, use a torque wrench to finish it off. Set the torque wrench to 25 foot-lbs. When it “clicks”, you’ll know you’ve achieve the proper amount of tightness. Don’t worry about “gapping” the plugs. The plugs for these cars are pre-gapped, so that’s one less thing to worry about. You also don’t need to treat the threads of the plugs with any chemical products. Those are likely to throw off the accuracy of the torque wrench as well. I also recommend that you use Bosch platinum plugs. Mercedes uses Bosch themselves at the factory, so I think you should too. Consult your local auto parts store when making the purchase of the plugs and/or wires.

Removed coils

Fig 14: Passenger side coils removed

Passenger side plugs removed

Fig 15: Passenger plugs removed

Now that the passenger side replacement plugs are in, screw the coils back onto the engine with the Torx #30 and the screws that you carefully saved. Once the 3 coils are back on, in the same precise locations (no musical chairs here), use your hands to insert the ends of the wires over the new plugs. There should be an audible “click” and you should feel it when they’ve been seated properly. Again, apply firm even pressure STRAIGHT onto the plugs until the wires click into place.

Now, the reason I asked you to completely do the passenger side first, is because at this point we can connect the battery again and see if the car turns on and runs properly. If there is something wrong, it’s far easier to isolate the problem because you haven’t touched the driver’s side at all. Isn’t that clever? Hopefully, you won’t have any trouble. Let the car run for a couple minutes. If everything seems fine, take it for a spin around the block. Still OK? Congratulations! Proceed to the driver’s side. If you do have a problem, I think the most likely problem is that 1 or more wires isn’t properly seated onto a plug, or perhaps one was damaged. Work through the problem. If you can’t solve it, do not attempt to go on to the driver’s side. Take it to the shop and explain the problem. It’ll be embarrassing, but you may get some respect for having tried. Again, part of all this is to learn and develop confidence.

If all is well with the car at this point, disconnect the battery again, and repeat the process with the driver’s side. It’s going to be a bit more difficult because there isn’t as much room there. Keep at it. You can do it. When you’ve finished, reconnect everything and see if the car starts and still behaves by running it for a few minutes. Listen to it. It should sound just as it did before. In fact, it may sound better. If you feel or hear any hesitation, or stuttering, you may have a plug firing timing problem. Make sure you’ve connected everything properly. When you’re satisfied, put the engine covers back again and reconnect the battery again. You may have to enter your radio security code. Also, your car may give you a BAS/ESP error message on your dash. This is a side-effect of the loss of electrical power. Turn the wheel all the way to the left (counter-clockwise) and then all the way to the right. That should clear the message and your car’s electrical systems should be restored to normal operation.

That’s it. Happy motoring!