error contextify@0.1.15 install: `node-gyp rebuild`

[ren-kun]

Hello, I get this error when trying to install log.io coffee.

11533 error argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "-g" "log.io" "--user" "ubuntu" 11534 error node v7.2.1 11535 error npm v4.0.3 11536 error code ELIFECYCLE 11537 error contextify@0.1.15 install: node-gyp rebuild 11537 error Exit status 1 11538 error Failed at the contextify@0.1.15 install script 'node-gyp rebuild'. 11538 error Make sure you have the latest version of node.js and npm installed. 11538 error If you do, this is most likely a problem with the contextify package, 11538 error not with npm itself. 11538 error Tell the author that this fails on your system: 11538 error node-gyp rebuild 11538 error You can get information on how to open an issue for this project with: 11538 error npm bugs contextify 11538 error Or if that isn't available, you can get their info via: 11538 error npm owner ls contextify 11538 error There is likely additional logging output above.

[ren-kun]

https://dl.dropboxusercontent.com/u/74122999/npm-debug.log

[HansHammel]

jep, this is not stable i am working on an improved version...

[ren-kun]

Ok thanks!

ETA if possible?

[HansHammel]

No priority, sorry. I am incorportating this abandoned project in my distributed cluster logging framework at some time in 2017. It's part of a huge project to compete with mesos/marathon & co. and it is very likely to use a still maintained alternative.

[ren-kun]

What can I do now then? I need something like log.io . Any good recommendations?

[jfcabral]

@ren-kun Perhaps:

• rtail - https://github.com/kilianc/rtail - http://rtail.org
• gwsocket - https://github.com/allinurl/gwsocket - http://gwsocket.io

[HansHammel]

@jfcabral Nice projects, but none of them are up o date/ still maintained or work on windows :-( gwsocket relies un unix sockets with no winsocket fallback and rail & forks dont pass their tests on windows even after some patching & tweeking...

[ren-kun]

Oh dear... Hans you said you were working on a similar project right? Sometime 1st quarter of 2017 perhaps?

I am running this off an Ubuntu OS 14.04.

I looked at gwsocket, but my aim is to stream it to a website available to the internet and of course with a password/user accounts

[HansHammel]

To be honest, this is a fairly simple task. Hands off any udp/multicast solution. Choose a transport library like TLS/TCP, HTTPS/HTTP(/REST) or WS/WSS or even a pub/sub capable DB or Socket.IO. Then abuse any AdminUI or a Twitter/Reddit-Client around and tailor it to your needs. And your half Way there - for a single, standalone, one-man logging solution! But, if you plan to submit multiple logs, search/ filter and aggregate multiple formats, etc. this is an ambiguous task. And, most of this features are also absent in log.io. That is why I do not want to accept the matter at the moment. You will need to benchmark the fastest possible transport and protocol, maybe implement connection pooling, rework some libraries to use streaming, eventually implement a different transport for a local network relay, that has to be written, which does the job of persisting, filtering and streaming to the internet; perhaps a transactional and/or queueing system. You will definitely need a server side query language and an according api, etc. So maybe I come up with a solution at the end of 2017. This has no priority for me, it will be developed alongside a auto configuration server and remote management and deploy system. A task that shares most of the requirements of a logging system. For the profesionals: Incorporate a Cisco/whatever api to controll the network's Quality of Service, to ensure your logs let you know about any DoS-Attacks,...

Update: BTW, search for logstash alternatives, you will find things like fluentd, logstash, e.g. in combination with kafka or kibana and elasticsearch etc. (e.g. ELK-Stack - Elasticsearch, Logstash und Kibana), still most popular solutions are graylog and nagios. It is not recommanded to gather logs at application level, there are system daemons for that. They are suposed to be less intrusive and perform better - I personally disagree with a lot of these "best practices"...

[ren-kun]

Ah ok,

Thanks for the reply

[ren-kun]

@HansHammel

Any progress or updates?

[HansHammel]

Nope

[sascha1337]

when update