observing / haproxy Goto Github PK

It currently just dies, hard when it receives a response that it did not expect. For example if you do

haproxy.disable('foo', '\n\rn\ evil chars')

It will receive an error response from the server. Which it cannot detect.

you know the drill

do you plan to do also add backend and add frontend methods?

Summary of fixes, for tests to run correctly...

• extend haproxy npm module dependencies to include mocha + chai + sinon-chai
• package.json is incorrect + find should change from 'test' to 'node_modules'
• package.json is incorrectly placed, so ln -s node_modules/haproxy/package.json . is required.

Seems like entire test suite may have evolved organically + requires to be run inside a pristine build environment (where npm has never been installed + no npm modules have been installed), so entire test flow can be fixed.

Detailed list of problems + resolutions.

1. npm install haproxy --save - produces this error message...

npm ERR! not a package /tmp/npm-29229-1Lj84CuY/1432732957086-0.35323801008053124/tmp.tgz

fix: unsure

workaround: cd / && npm --prefix=$(pwd) install haproxy --save

2. mocha isn't defined as a dependency.

fix: define mocha as dependency, along with which + dsv + mkdirp

workaround: npm install mocha --save

3. npm test - first breakage.

net8-rmt# npm test
npm ERR! Error: ENOENT, open '/buildstacks/work/haproxy-1.5.12/package.json'
npm ERR! If you need help, you may report this entire log,
npm ERR! including the npm and node versions, at:
npm ERR! http://github.com/npm/npm/issues

npm ERR! System Linux 3.19.0-18-generic
npm ERR! command "/usr/bin/nodejs" "/usr/bin/npm" "test"
npm ERR! cwd /buildstacks/work/haproxy-1.5.12
npm ERR! node -v v0.10.25
npm ERR! npm -v 1.4.21
npm ERR! path /buildstacks/work/haproxy-1.5.12/package.json
npm ERR! code ENOENT
npm ERR! errno 34
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR! /buildstacks/work/haproxy-1.5.12/npm-debug.log
npm ERR! not ok code 0

Failed because package.json is the wrong place.

workaround: ln -s node_modules/haproxy/package.json .

4. npm test - 2nd breakage

net8-rmt# npm test

[email protected] test /buildstacks/work/haproxy-1.5.12
NODE_ENV=testing ./node_modules/.bin/mocha $(find test -name '*.test.js')

find: `test': No such file or directory

/buildstacks/work/haproxy-1.5.12/node_modules/mocha/lib/utils.js:591
if (!files.length) throw new Error("cannot resolve path (or pattern) '"
^
Error: cannot resolve path (or pattern) 'test'
at Object.lookupFiles (/buildstacks/work/haproxy-1.5.12/node_modules/mocha/lib/utils.js:591:32)
at runAgain (/buildstacks/work/haproxy-1.5.12/node_modules/mocha/bin/_mocha:320:30)
at Array.forEach (native)
at Object. (/buildstacks/work/haproxy-1.5.12/node_modules/mocha/bin/_mocha:319:6)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
at node.js:902:3
npm ERR! Test failed. See above for more details.
npm WARN This failure might be due to the use of legacy binary "node"
npm WARN For further explanations, please read
/usr/share/doc/nodejs/README.Debian

npm ERR! not ok code 0

There is no 'test' directory. Maybe this should be 'node_modules'.

5. npm test - 3rd breakage

net8-rmt# npm test

[email protected] test /buildstacks/work/haproxy-1.5.12
NODE_ENV=testing ./node_modules/.bin/mocha $(find node_modules -name '*.test.js')

module.js:340
throw err;
^
Error: Cannot find module 'chai'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Suite. (/buildstacks/work/haproxy-1.5.12/node_modules/haproxy/test/haproxy.test.js:7:14)
at context.describe.context.context (/buildstacks/work/haproxy-1.5.12/node_modules/mocha/lib/interfaces/bdd.js:49:10)
at Object. (/buildstacks/work/haproxy-1.5.12/node_modules/haproxy/test/haproxy.test.js:1:63)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at /buildstacks/work/haproxy-1.5.12/node_modules/mocha/lib/mocha.js:192:27
at Array.forEach (native)
at Mocha.loadFiles (/buildstacks/work/haproxy-1.5.12/node_modules/mocha/lib/mocha.js:189:14)
at Mocha.run (/buildstacks/work/haproxy-1.5.12/node_modules/mocha/lib/mocha.js:422:31)
at Object. (/buildstacks/work/haproxy-1.5.12/node_modules/mocha/bin/_mocha:398:16)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
at node.js:902:3
npm ERR! Test failed. See above for more details.
npm WARN This failure might be due to the use of legacy binary "node"
npm WARN For further explanations, please read
/usr/share/doc/nodejs/README.Debian

npm ERR! not ok code 0

Now chai is missing.

fix/workaround: change 'test' to 'node_modules' in package_json

fix: define chai as a dependency

workaround: npm install chai --save

6. npm test - 4th breakage

Dependency sinon-chai missing.

fix: define sinon-chai as a dependency

workaround: npm install sinon-chai --save

Some of the orchestrator code uses really odd ps | grep magic to find the pid of running processes and checking for running processes. This can all be simplefied by just using pgrep haproxy which just returns a list of all process id's

Hi,

We would like to report a potential security vulnerability.
The bug is introduced because the package-exported method fails to sanitize its opts.prefix parameter and lets it flow into a sensitive command execution API.

Here is the proof of concept.

const lib = require('haproxy');

var opts = {
 prefix: 'touch rce', 
 which: ' '
}
var a = new lib(opts)
a.orchestrator.run(['haproxy'], () => {})// a file named rce will be created

Please consider fixing it. thanks!

Generating a load via - ab -t 30 -n 1000000 -c 5 - produces unexpected results on a multi-core machine.

Setting nbproc 1, works as expected - one CPU pegs near 100%.

Setting nbproc 2, works as expected - two CPUs peg near 100%.

After this, raising nbproc to higher values works unexpectedly - only two CPUs peg, never more.

Maybe this is by design + the docs seem to indicate nbproc 4 should peg four CPUs.

Looking at ps, the correct number of processes startup as expected. It just appears only two of these processes are used.

We should be able to parse streamingly parse the logfile that HAProxy outputs so we can create a stream of useful information from it.

the reload method docs state that it will

Hot reload the configuration with the minimal amount of downtime

(as long as you don't use the hard option).

After looking at the actual command

var cmd = 'haproxy -D -f %s -p %s -sf %s';

it looks like it's using the -sf option which should cause a reload with zero downtime / traffic disruption.

If this correct can we/you/me update the docs (I'm happy to make a PR) as the difference is quite important.

Since this project seems abandoned, please see haproxy-sdk and haproxy-api

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

Have you thought about or are you aware of any efforts to configure haproxy or a subset of its features using JSON?