Sambal

I have an old stable internal server that’s running CentOS 5.10 which I want to use a staging/development server for modern node.js applications.

The problem is, current prebuilt versions of node.js can’t be installed on CentOS5, since CentOS5 has GNU libc 2.5 and the prebuilt node.js RPMs are only for Fedora/RedHat/CentOS 6, and are linked against libc 2.7.

Fortunately you can still build from source, as follows:

Install Python 2.7 on CentOS5

Node requires Python 2.6 or 2.7 to build; CentOS 5 comes with Python 2.4, and we need to keep that because yum depends on it.
So we first install Python 2.7 as an alternate version of Python:

$ cd ~/code
$ wget https://www.python.org/ftp/python/2.7.6/Python-2.7.6.tgz
$ tar xzf Python-2.7.6.tar.gz
$ cd Python-2.7.6
$ ./configure; make -j
$ sudo make altinstall

It’s very important to do make altinstall and not a regular install, because yum depends on Python 2.4. make altinstall will install Python 2.7 as /usr/local/bin/python2.7

Check out latest stable node source

$ cd ~/github
$ git clone git://github.com/joyent/node.git
$ cd node
$ git checkout 0.10.28
$ PYTHON=python2.7 $PYTHON configure
$ make
$ make test

I had a few failing tests. The very first test fails, and takes many seconds to timeout. This is test-abort-fatal-error.js, which seems to be testing the system’s ability to apply resource limits via ulimit. Another test that fails, near the end, is tls-test-server-verify. This sounds ominous, but since I am not planning to use this server in production, I decided to continue.

$ sudo make install

Test node and npm

$ node --version
v0.10.28
$ node
> console.log('Hello, world');
Hello, world
undefined
> ^D

Then create a directory to test npm

$ mkdir test && cd test
$ npm i --save mocha
$ PYTHON=python2.7 npm i --save inchi

Note the explicit setting of the PYTHON environment variable. When installing an npm module that requires compilation (that executes node-gyp), npm will return an error if it runs with the default system python (2.4), since node-gyp requires at least python 2.7. If you install a lot of compiled packages, or it’s painful to remember to set the environment variable PYTHON every time, you can add export PYTHON=python2.7 to your ~/.bash_profile. It doesn’t seem to bother yum.

Inchi, by the way, is an international chemical identifier; specifically, the npm inchi package is javascript interface to the InChI Trust’s C library for converting between structures and InChI codes. Here I’m using it as an example of an npm module that requires compilation and linking to work.

I also noticed that when node-gyp was building

Known Limitations

There are several limitations to this approach.

1. Test failures making this node 0.10 unsuitable for production

   The ulimit, tls, and flooding tests failed. I would not use this node on a production server that is exposed to DOS attacks.

2. No support for nvm

   On my production server I use nvm to manage the version of node I’m using. Since nvm downloads prebuilt binaries which link against glibc 2.7, this doesn’t work on CentOS 5

3. Must rebuild node to get bugfixes / new versions

   Just like in the 1990s, in order to get the next stable version of node, you need to pull the sources and rebuild. This is much easier now, and can even be automated, but it’s a substantial effort that only makes sense if you have no better alternative.

If I can get the tests to build cleanly, I’d be willing to package this up as an RPM for anyone who’s interested.

EDIT: Here’s another approach, written for node 0.8, but will probably work with 0.10. Note that they use EPEL to find and download an RPM for Python 2.6, and a symbolic link from ~/bin/python to /usr/local/bin/python2.6.

I’m starting a week-long work block today — that is, I’m planning to work from 5AM to 5PM straight every day, like a “normal person”. Danielle has graciously consented to spend one week of her vacation doing everything else that needs to get done.

Since last week we had a “stay-cation” where we went out to all the Edmonton sights and attractions and ate out at fancy restaurants, I have dubbed this my “work-cation” – which is not pronounced “work cat ion”, for the chemists out there. That would just be anion– err, annoying.

Here’s my day 1 setup:

]1 I moved the mac into the guest room for my workcation. That’s ~1L of coffee on the right there, in my homemade skull mug and Contigo travel mug.

And here are the materials I brought along:

]2 Notes, books, flashcards, papers for my 2014 March work-cation.

I was chatting with someone on #node.js who wanted his script to pass a command-line option to node, so that his script was run in a particular node environment. The problem is that under linux you get to pass exactly one argument on the shebang (#!) line. If you use #!/usr/bin/env node, you’ve already used your one argument. When I suggested he use the “-x” hack, we discovered that node didn’t have this hack. So I made a pull request complete with a TL;DR justification for why -x is necessary.

Turns out there’s a tidier hack that doesn’t require any changes to node, which relies on the interaction between bash and node.  Here’s an example, lifted from pm2 and lightly modified for clarity:

#!/bin/sh 
":" //# comment; exec /usr/bin/env node --noharmony "$0" "$@"

console.log('javascript');

Here’s how it works:

1. The #!/bin/sh causes the script to be identified as a shell script, and passed to /bin/sh for execution. /bin/sh reads and executes scripts one line at a time, and we’re taking advantage of that below.

2. The second line, as interpreted by the shell, consists of two commands.

   2a. The first command is ":", which is the quoted version of the rarely-used bash command :, which means “expand arguments and no-op”. The only argument to : is //, which is a valid path. The following # is a bash comment, which is valid until the command separator ;.

   2b. The second command is exec /usr/bin/env node --noharmony "$0" "$@" which executes the node interpreter with the desired arguments and passes argument 0 (this script file) and the rest of the arguments to the bash script ("$@")

3. The exec causes the bash process to be replaced by the node process, so bash does not attempt to process any further lines.

Now we’re running under node, with the desired command line arguments set. Unlike bash, node wants to read and parse the whole file. So let’s see what node sees:

1. The #!/bin/sh line is ignored due to a special one-off in node – when loading a module, the contents of the first line will be ignored from #! up to the first \n.
2. The second line contains a string constant, the quoted string ":", followed by a Javascript comment introduced with //. Automatic semicolon insertion happens so the constant is interpreted as a string in a statement context. Then the comment is parsed, and everything up to the end of the line is ignored by node.

This won’t lint clean. jslint and jshint both complain:

$ jslint test
test:2:1: Expected an assignment or function call and instead saw an expression.
test:2:4: Expected ';' and instead saw 'console'.
$ jshint test
test: line 2, col 1, Missing semicolon.

1 error

But it works right now, as a hack-around for the Linux one-argument shebang problem.

Note that there’s a spot in the line where you can insert a comment (as long as it doesn’t contain anything that bash interprets, notably ;). What to put there? I recommend a link to a web page (such as the one you’re reading now, https://sambal.org/?p=1014) that explains WTF this weird-looking line is all about. For example:

#!/bin/sh 
":" //# https://sambal.org/?p=1014 ; exec /usr/bin/env node --noharmony "$0" "$@"

console.log('javascript');

Happy hacking!

When learning how to do something, it helps to break it down to irreducible subtasks.

As an example, we homeschool our kids; my eldest daughter Kaija is 5th-grade age.  We want her to practice writing simple paragraphs as a stepping stone to essays.  But asking her to just “write a paragraph” can be overwhelming, because in order to “write a paragraph” you have to do all the following subtasks:

1. choose a topic
2. structure your thoughts into coherent sentences
3. write the sentences down
4. proofread and edit
5. make a fair copy

So following the advice of Susan Wise Bauer, we try to create opportunities for her to practice these subtasks in isolation.

Today we did #2, structure your thoughts.  I chose a topic: I said “tell me something about William the Silent.”  Kaija told me what to write and I wrote it down, so:

William the Silent was born in Germany.  He was brought to Spain to learn royal manners.  He was born a Protestant, so the king of Spain was worried he would not be loyal.  In Spain William learned how to be a Catholic.

When William grew up, he was given control of he Netherlands, which still belonged to Spain at that time.  Philip, the King of Spain, wanted to destroy Protestantism in the Netherlands.  William and the Dutch people waged a war for independence.  William became the first king of the Netherlands.

Here’s an analogy that came up this morning.

Liberals (Democrats) are like new CS grads.  They are excited about writing new code (laws) and disdainful of the negative predictions others make based on their hard-earned experience (believe in the perfectibility of people/software).

Conservatives are like grim old maintenance programmers.  They have seen fads and standards come and go, and know that attempting to fix one thing might break something else and make the whole system worse.  Unfortunately this sometimes leads them to defend the indefensible (States’ rights objections to the Civil Rights Act).  They’re often infatuated with process at the expense of outcome (strict constructionism).

Both views offer valuable insights and visible pitfalls.  But where is the party of refactoring?