NPM node_modules and Something Completely Different

‹prev | My Chain | next›

A more than slightly frustrating day fiddling with zlib brings me back to node.js land only to find:

➜  ~  npm ls
/home/cstrom
(empty)

Oh, come on! All of my NPM installed modules are kaput?!

Let's re-install the SPDY node.js package:

➜  node git:(master) npm install spdy

> zlibcontext@1.0.7 install /home/cstrom/repos/node/node_modules/spdy/node_modules/zlibcontext
> ./configure && make

Setting srcdir to                        : /home/cstrom/repos/node/node_modules/spdy/node_modules/zlibcontext 
Setting blddir to                        : /home/cstrom/repos/node/node_modules/spdy/node_modules/zlibcontext/build 
Checking for program g++ or c++          : /usr/bin/g++ 
Checking for program cpp                 : /usr/bin/cpp 
Checking for program ar                  : /usr/bin/ar 
Checking for program ranlib              : /usr/bin/ranlib 
Checking for g++                         : ok  
Checking for node path                   : not found 
Checking for node prefix                 : ok /home/cstrom/local/node-v0.5.0-pre 
Checking for library z                   : yes 
'configure' finished successfully (0.209s)
node-waf build
Waf: Entering directory `/home/cstrom/repos/node/node_modules/spdy/node_modules/zlibcontext/build'
[1/2] cxx: src/node_zlib.cc -> build/default/src/node_zlib_1.o
[2/2] cxx_link: build/default/src/node_zlib_1.o -> build/default/zlib_bindings.node
Waf: Leaving directory `/home/cstrom/repos/node/node_modules/spdy/node_modules/zlibcontext/build'
'build' finished successfully (0.519s)
zlibcontext@1.0.7 ./node_modules/spdy/node_modules/zlibcontext
spdy@0.0.1 ./node_modules/spdy

Hrm... What is the deal with the node path not being found? Whatever it is, I am guessing it has something to do with the modules being installed into the current working directory.

After some digging, it turns out that my supposition is wrong. Npm now installs into the current working directory by default. I have been stuck in rvm / ruby land for such a long time that I did not notice the change. The "Checking for node path" message is coming from the zlibcontext configure script (more precisely, node-waf's configuration) and can be safely ignored.

The first thing I need to do is delete all of the node_modules directories that I have created all over the place. I remove a half dozen at various places (apparently this has been confusing me for some time now). With that, I re-run npm install with the --global option:

➜  ~  npm install -g zlibcontext

> zlibcontext@1.0.7 install /home/cstrom/local/node-v0.5.0-pre/lib/node_modules/zlibcontext
> ./configure && make

Setting srcdir to                        : /home/cstrom/local/node-v0.5.0-pre/lib/node_modules/zlibcontext 
Setting blddir to                        : /home/cstrom/local/node-v0.5.0-pre/lib/node_modules/zlibcontext/build 
Checking for program g++ or c++          : /usr/bin/g++ 
Checking for program cpp                 : /usr/bin/cpp 
Checking for program ar                  : /usr/bin/ar 
Checking for program ranlib              : /usr/bin/ranlib 
Checking for g++                         : ok  
Checking for node path                   : not found 
Checking for node prefix                 : ok /home/cstrom/local/node-v0.5.0-pre 
Checking for library z                   : yes 
'configure' finished successfully (0.202s)
node-waf build
Waf: Entering directory `/home/cstrom/local/node-v0.5.0-pre/lib/node_modules/zlibcontext/build'
[1/2] cxx: src/node_zlib.cc -> build/default/src/node_zlib_1.o
[2/2] cxx_link: build/default/src/node_zlib_1.o -> build/default/zlib_bindings.node
Waf: Leaving directory `/home/cstrom/local/node-v0.5.0-pre/lib/node_modules/zlibcontext/build'
'build' finished successfully (0.521s)
zlibcontext@1.0.7 /home/cstrom/local/node-v0.5.0-pre/lib/node_modules/zlibcontext

Ahhh... much better. Now zlibcontext is installed where I can get to it no matter the directory in which I am currently working.

Update: And this was wrong. Subsequent npm ls or attempts to require the packages reveal that this is not how npm 1.x works. Global install is for executable binaries only. Requiring / npm ls (without -g) will not work.

So minor mystery solved, but I am a bit sick of this zlib stuff at this point. So I do a quick inspection of the TLS negotiation of the SSL session involved in SPDY. In a Wireshark capture, there are 2 SSL related packets, the client hello and the server hello:



Of note in there are the cipher suites supported by the client (36 in all are supported by Chrome):



My beloved DES-CBC3-SHA is not in the first 10 shown on the screen capture. In fact it is the last on the list which leads me to believe that my Wireshark / SSL days are going to soon run out.

The only other interesting thing that I note in the request is the server name:



I am not quite certain why the server cares what the client thinks the server name is. Interesting.

As for the server response, I see that my favorite cipher suite is the one being served up by my local SPDY server:



Also of note is the apparently too-new-for-Wireshark TLS extension that performs Next Protocol Negotiation:



The SPDY server needs to respond that it can serve up HTTP/1.1 and HTTP/1.0 in addition to SPDY. For older browsers that do not support SPDY, they will ignore this and proceed to make HTTP requests as normal.

The only other bit of information that is of some interest in there is the certificate itself:



Nothing too surprising, but I am amused by the "International Widget Pty Lmtd" as the organization name. It is a nice default value from openssl.

I will call it a day at this point. I will make one more run at zlibcontext tomorrow -- armed with my newfound NPM knowledge.


Day #24