121–130 of 233 posts
Excuse me, but what the fuck? Looks like the line responsible checks if the npm binary is run as sudo and then uses the UID and GID of the invoking user when chowning the directory. [ https://github.com/npm/npm/blob/latest/lib/utils/correct-mkd... ] I feel like screaming, who thought this was a good idea? If I invoke something as sudo, why does anyone think it should try to detect that and do anything about it? I wan…
Earlier quoted context omitted.
`sudo npm install -g` is one of several examples of the normalization of deviance rife in the NodeJS community. Most command-line utilities distributed through NPM recommend running as root (implicitly—because they all suggest installing it as a global package). Here's[1] Microsoft's instructions to install the TypeScript compiler, for example. NPM's awfulness notwithstanding, it's trivial to write a shell script to…
If I run npm without -g, it complains about missing files, and fills my home directory with node_modules junk and a package-lock.json I have to "commit"? Why do I want to commit it, and where? I'm sure you are now going to tell me there is an easy way to fix that too, and I'd be happy if there was, but for me I just want to use npm to install a program or two.
I don't think you're introducing new information. When I wrote my original comment, it was intended to fully acknowledge that this is what's at play. And rereading it, seems like it does that well enough, but I might be wrong.
But in any case, I'll run it with sudo then, is absolutely the wrong thing to do, regardless of the bad choices on NPM's part—on par with I just want to use my online banking, so I'll click through this certificate error, or I just want to take some notes, so I'll grant this mobile app the full permissions it's asking for.
There's a reason I used the phrase "normalization of deviance". It's a phrase that came out of post mortem investigations into simple process failures at NASA that led to proper (catastrophic, life-ending) failures, and an urge to find an answer to the question, "how in the world did we get here?"
Earlier quoted context omitted.
Uhh. Does semver actually say anything about bugs ?! o_0
I'm pretty sure you don't release pre-release versions without -pre or -beta or -rc tags in the end.
> A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version.
Note that it says "MAY" and not "MUST", so it's optional.
Earlier quoted context omitted.
Running npm as root is _super dangerous_ - full stop. npm install can run a large amount of arbitrary code downloaded from the internet via postinstall script hooks. Its absolutely banana-pants crazy to run `npm install` as a root user in any circumstance.
If it runs untrusted code from the Internet, surely it doesn't matter much if you do it as root for most practical purposes? It could still run that spam relay, botnet software, exfiltrate your secrets and install that keylogger.
Earlier quoted context omitted.
This response annoys me, because it's essentially victim-blaming. Yes, ideally you have some automation and staging in your server setup. We're grown-ups. We understand this. But it ignores many other dangerous possibilities here. Not everyone is blessed with working in a mature, well-funded environment full of experts. Maybe we're talking about a new or small organisation that simply doesn't have the resources and/o…
I think there is a big difference here. I am responding to a reply that wanted remove any responsibility from running such non-since as npm on a productions server -- note I did not reply to "crap I hosed my stuff". But lets take a closer look at your comments. > Not everyone is blessed with working in a mature, well-funded environment full of experts. Maybe we're talking about a new or small organisation that simply…
It's all very well saying "know your trade", but the reality is that most organisations aren't running state-of-the-art orchestration tools. Heck, not so many years ago, many of these modern tools didn't even exist yet, and they've had plenty of problems of their own that make keeping up with the bleeding edge dangerous in itself.
So, while it might not be ideal compared with modern management tools, I think it's neither unusual nor unreasonable in many real world environments for someone to expect to deploy a standard set of packages on a production server using the normal deployment tools and a controlled configuration file, and expect it to work without destroying that world.
Speaking of funding, that affects everything in an environment like a bootstrapped startup or a small non-profit, even things like whether you can afford physically separate machines to run each level of testing/staging/whatever, or whether you can afford to hire someone who understands the recent generation of tools that deploy a snapshot in one form or another instead. It's totally unrealistic to expect this sort of organisation to have mature, state-of-the-art configuration management and deployment systems in place from day one.
Hopefully even in the early stages you would still have some sort of staging set up, and I think you misread my comment there; I was in no way advocating not having staging servers. I was only observing that even if you take out staging catastrophically rather than production, it can still be a pain to set everything back up, just less of a pain than losing production while you're doing it.
Again, I am okay with a developers system being nuked, at least it was not production!
You're OK with a developer's entire workstation being taken out, at best losing everything they've done since last night's backup and then probably taking another half-day to restore from backups if everything goes smoothly?
I'm not OK with that, and somehow I doubt most developers would be either.
If you have 100 servers then you should have the resources to handle setting up testing environments to ensure your production rolls out. You should also not update 100 servers at the same time.
Right, but how many organisations have 100 production servers? If you've reached that scale, you're already probably in some sort of 1% group, and obviously you might have far more resources available to deploy management infrastructure around those servers.
Anybody in this industry of deploying software to servers needs to stand-up to these ideas that these good practices are too costly.
That philosophy might be something you can afford once you're no longer operating in small/early mode, if you get that far. But while you're still worrying about say getting from MVP to ramen profitability in your startup, everything is too costly, and you never have the luxury of doing the ideal thing everywhere right now. Hoping for basic staging isn't out of the question. Hoping for a full-time ops person to deploy the best-in-class orchestration tools that came out last week because you can't trust running apt to install security updates on your production Debian servers without destroying them is probably beyond your wildest dreams.
It's not that I disagree with you on the ideal situation. I just see that an ideal is what it is. Many, many organisations will not have the luxury of doing everything ideally, because they lack the time, people, budget, knowledge or omnipotence to do it all at once. That's the nature of running businesses. It's not unreasonable to expect that when you have to prioritise, the risk of your basic package management tools nuking your entire system should be negligible, and I still think it's unfair to criticise the victims of such a spectacular screw-up until you've walked a mile in their shoes and seen what they would have had to give up somewhere else to get that extra level of protection against something that obviously should never have happened.
Excuse me, but what the fuck? Looks like the line responsible checks if the npm binary is run as sudo and then uses the UID and GID of the invoking user when chowning the directory. [ https://github.com/npm/npm/blob/latest/lib/utils/correct-mkd... ] I feel like screaming, who thought this was a good idea? If I invoke something as sudo, why does anyone think it should try to detect that and do anything about it? I wan…
Why is such code even necessary??
I just can't feel sorry for folks when I see comments like this one: > This destroyed 3 production server after a single deploy! I do think that the developers have a duty to do some testing of their software before putting out releases/updates. However, users also have a duty to perform sufficient testing before they push new versions to their production environments. In my opinion, it's kinda like losing data becau…
What you say is 100% true, but I would go one step further and not have npm installed on any production server. And it's not specific to npm, I would do the same with gem, pip, cpan, etc. Not to mention curl http://ex.io/install.sh | sudo bash. Call me old school, but personally, I would avoid installing anything from language specific package managers. I would instead either build an rpm/deb package for every depend…
Earlier quoted context omitted.
"everything you would expect of a Facebook-engineered library" So it collects your personal information, even when not using it, and uses it for profit?
At the risk of troll-engaging: there's a huge difference between using an independently-auditable, multiple-contributing-entity, open-source library that happens to have been originated by a social network's engineering team, and using the identity-tracking public APIs of a closed social network. And both can be useful in certain situations. Be wary, but don't close oneself off to good technology just because it's as…
> don't close oneself off to good technology just because it's associated with technology you disapprove of
I disagree, if you think Facebook is evil, don't use their libraries. Using them gives Facebook positive publicity and good will.