Idée très chouette. Je ne veux pas l'ajouter à mon dépôt nvm car c'est un peu invasif, mais ce n'est pas difficile pour quelqu'un qui veut personnaliser son environnement.

En général, je me contente de rechercher le fichier nvm.sh en tant que root après avoir exécuté "sudo su" ou modifié le fichier .bashrc de root. Je veux plus qu'un simple nœud lorsque j'exécute sudo et de cette façon, j'obtiens tout dans le dossier $NVM_BIN.

Vous avez raison, cela pourrait être un peu invasif et ne devrait probablement pas être actif dans la version, mais peut-être simplement le publier ici ou quelque part dans les futurs documents, afin que les gens puissent le trouver facilement.
Ou peut-être qu'il serait préférable de l'avoir dans le script, mais commenté, et les personnes qui en ont besoin, le décommenteraient simplement - juste une pensée.

Il m'a fallu un peu de temps pour comprendre cela, donc cela pourrait probablement faire gagner du temps aux autres.

La modification du bashrc de la racine n'était pas une option pour mon cas, car nous avions une configuration avec plusieurs utilisateurs, chacun avec son propre nœud/nvm, et voulions permettre une exécution rapide via sudo (sudo node app_name), si nécessaire.
L'inclusion de nvm.sh ou du ou des chemins dans le fichier .bashrc de la racine ne permettrait qu'une seule configuration de s'exécuter via sudo.

C'est fantastique, j'ai fait les changements et cela fonctionne comme un charme.

Et si je voulais faire quelque chose comme sudo ENV1=val1 ENV2=val2 node server.js ?

Je suis capable de le faire avec d'autres outils (je me souviens que je n'ai jamais eu de problème avec cela), mais dans mon environnement nvm-ized, j'obtiens sudo: node: command not found .

Toute aide serait très appréciée!

Est-ce que "nvm install" a besoin de sudo pour s'exécuter sans erreur ?

@zakdances non, nvm installe le nœud dans un dossier local à l'intérieur de votre clone git du référentiel nvm. À moins que votre utilisateur n'ait pas accès en écriture à votre propre clone, cela devrait fonctionner correctement sans sudo. En fait, l'utilisation de sudo peut casser des choses car elle crée des fichiers en tant qu'utilisateur root.

Hm, je viens de tomber sur celui-ci en essayant d'installer grunt globalement.

Comme @mpotra l'a suggéré, j'ai également dû npm comme ceci :
alias node='$NVM_BIN/node'
alias npm='$NVM_BIN/npm'

Cela signifie donc qu'aucun package de nœud destiné à une disponibilité mondiale ne peut être installé lors de l'utilisation de nvm par défaut, n'est-ce pas ? Cela devrait faire en sorte que certains utilisateurs aient ce scénario, j'imagine.

Que diriez-vous d'inventer un mode nvm spécial pour que les alias ne soient activés que lorsque les utilisateurs entrent explicitement dans ce mode ?
Lorsqu'ils quittent à nouveau le mode, les alias peuvent être désactivés.

Cela semble assez courant pour être ajouté au fichier readme.

Oui, avoir besoin de sudo sur les systèmes *nix est très courant.

À titre de suggestion, vous pouvez essayer une solution similaire à ce que fait le gestionnaire de versions ruby http://rvm.io/integration/sudo

On vient de me dire dans la liste de diffusion git que vous ne devriez utiliser que très rarement sudo. Mais je le vois tout le temps. Trop d'avis là-dessus.

L'utilisation de sudo pour installer le nœud est parfaitement raisonnable et courante. L'exécution du nœud lui-même en tant que root est désapprouvée. Malheureusement, nvm rend cela très difficile.

Si quelqu'un cherche un moyen simple d'installer nvm dans le monde : https://github.com/xtuple/nvm

Il n'est pas nécessaire d'installer node avec sudo une fois que vous avez donné au répertoire nvm les bonnes autorisations.
Par example:
créez un groupe d'utilisateurs appelé nvm , ajoutez tous les utilisateurs qui doivent utiliser nvm à ce groupe et modifiez les autorisations de votre répertoire nvm en groupe accessible en écriture : chmod 2775 /usr/local/nvm (le premier chiffre (2) est le setgid bit, expliqué ici , qui garantit que le groupe à exécuter dans ce répertoire reste le même)

+1 pour la solution nvmsudo proposée par @treehau5

+1 pour le point @koenpunt sur l'accès du groupe.

L'utilisation de sudo pour installer le nœud est parfaitement raisonnable

Je ne suis pas sûr d'être d'accord avec "raisonnable"... plutôt "endémique".

et commun.

Avec ça, je suis d'accord.

Mais je le vois tout le temps. Trop d'avis là-dessus.

Je ne suis pas d'accord avec son utilisation ; mais, à chacun le sien.

Mon cas d'utilisation est de pouvoir facilement mettre à niveau mes services à l'échelle du système, s'exécutant sur nodejs, dans le cas de versions de correctifs/de sécurité, et pour que ceux-ci soient compatibles avec Travis-CI, qui utilise nvm . En plus d'utiliser sudo comment installer nvm dans le PATH global à cette fin ? Ou existe-t-il un meilleur outil pour cela?

Je suppose que le vrai problème est la prise en charge du gestionnaire de packages généralement merdique dont node.js bénéficie de la plupart des fournisseurs de systèmes d'exploitation.

Je suppose que le vrai problème est la prise en charge du gestionnaire de packages généralement merdique dont node.js bénéficie de la plupart des fournisseurs de systèmes d'exploitation.

Eh bien, pour être juste, toutes les autres langues doivent faire face à ces mêmes gestionnaires de paquets de système d'exploitation merdiques. En fait, certains sont assez bons, mais le problème est l'entretien. Parfois, vous voulez 0.11.11 mais bonne chance pour trouver un responsable de package de système d'exploitation qui peut (ou va) suivre ce rythme.

En plus d'utiliser sudo, comment installer nvm dans le PATH global à cette fin ? Ou existe-t-il un meilleur outil pour cela?

Peut-être que quelqu'un d'autre peut intervenir... Je n'ai pas de bonne réponse parce que je ne tends pas vers ce flux de travail particulier.

Aujourd'hui, j'utilise docker (c'est-à-dire le conteneur LXC)... avant que docker n'existe, j'utilisais des machines virtuelles.

Avec docker, nvm n'est pas vraiment nécessaire. Vous venez de faire tourner un conteneur avec la version exacte qui vous intéresse.

J'ai tendance à utiliser nvm sur ma machine de développement, installé via homebrew et installer des nœuds dans mon répertoire utilisateur local; où sudo n'est jamais nécessaire.

Définir ceci dans ~/.profile fonctionné pour moi :

alias sudo='sudo env PATH=$PATH:$NVM_BIN'

Cela fait partie de l'installation de nvm dans vagrant :

Vagrantfile

config.vm.provision :shell, path: "vagrant/nodejs.sh", privileged: false

vagabond/nodejs.sh

sudo su vagrant -c "wget -qO- https://raw.githubusercontent.com/creationix/nvm/v0.26.1/install.sh | bash"

echo "
source /home/vagrant/.nvm/nvm.sh
alias sudo='sudo env PATH=\$PATH:\$NVM_BIN'
" >> /home/vagrant/.profile

export NVM_DIR="/home/vagrant/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"

nvm install stable
nvm alias default stable

Maintenant, je peux faire sudo node|npm|pm2|whatever .

Merci @gagle , c'était la meilleure solution que j'ai trouvée.

J'aime la solution pointée sur ce stackoverflow donnée par Digital Ocean . Il résout le problème sudo et facilite la mise à jour des versions root en cas de besoin.

Vous ne devriez pas avoir besoin de sudo pour quoi que ce soit. Utilisez authbind si vous avez besoin d'écouter les nœuds sur les ports privilégiés.

@gagle pour une raison quelconque, NVM_BIN n'est pas défini au moment où ~/.profile est en cours d'exécution.
EDIT : corrigé en déplaçant

alias sudo='sudo env PATH=$PATH:$NVM_BIN'

vers ~/.bashrc après l'exécution de nvm.sh

Je crois que le but de nvm était de faciliter la commutation/l'utilisation de nœuds et d'éviter ce genre de manigances consistant à éditer manuellement certains fichiers pour certains utilisateurs et à marcher dans le sens inverse des aiguilles d'une montre pendant une pleine lune.

À tort ou à raison, de nombreux outils/modules de nœuds NÉCESSITENT d'être installés dans le monde.

Pouvons-nous avoir une option d'installation globale lors de l'installation de nvm ?
Si vous êtes préoccupé par les saveurs des systèmes d'exploitation, vous pouvez avoir un dossier avec des modules spécifiques pour chaque système d'exploitation/saveur. Certains peuvent ne pas être pris en charge. C'est bien, les gens peuvent contribuer aux modules.

@mightypenguin nvm n'est pas destiné à être utilisé sur plusieurs comptes d'utilisateurs. Chaque utilisateur doit avoir son propre $NVM_DIR .

Donc, même si j'écrivais le code pour rendre cela proprement possible, vous n'envisageriez pas de retirer mes modifications ?

@mightypenguin, je serais heureux d'y jeter un coup d'œil, mais je suis très sceptique, cela pourrait être tout à fait possible en raison de tous les problèmes d'autorisations dans les répertoires de nœuds gérés par nvm.

@tetreault vous ne devriez jamais utiliser sudo pour les ports privilégiés ; https://thomashunter.name/blog/using-authbind-with-node-js/ est une approche beaucoup plus sûre.

Je crois que npm run exécute les choses en tant que personne, et il est incapable de sudo (pour des raisons de sécurité).

sur un système basé sur debian (ou ubuntu) en plus de définir l'alias comme @mpotra a dit que vous devrez peut-être exécuter
sudo ln -s "$(which node)" /usr/local/bin/node pour que npm fonctionne en mode sudo

authbind est génial et tout, mais qu'en est-il des choses comme raw-socket ? J'utilise net-ping qui extrait raw-socket qui ne peut fonctionner qu'en tant que root. Est-ce que libcap fonctionnerait pour contourner le bloc de mode utilisateur « haxor crafty packet injection » ?

"ne peut fonctionner qu'en tant que root" semble être une raison pour ne pas utiliser un logiciel, à savoir.

homme 7 brut

Il semble donc que la définition de CAP_NET_RAW pour l'exécutable du nœud ouvrira juste un trou assez grand pour que raw-socket fonctionne sans root, peut-être, mais je suis sceptique (non testé car je l'exécute en tant que root parce que je ne suis pas paranoïaque ).

sudo setcap cap_net_raw+eip $(eval readlink -f `which node`)

"Microsoft" est aussi une raison pour ne pas utiliser un logiciel, mais beaucoup de pauvres l'utilisent, car ils n'ont pas le choix. J'adorerais aller réparer le logiciel de tout le monde, mais parfois, vous avez juste besoin de root pour résoudre les maux de tête et le faire fonctionner MAINTENANT et dans TOUS LES CAS, c'est garanti.

Et s'il est tout simplement plus simple de l'exécuter en tant que root et que j'en accepte les ramifications, cela devrait être trivial. Peut-être même une méthode prise en charge pour supprimer les privilèges (comme le fait Apache httpd ?) afin que l'ensemble du processus n'ait pas à s'exécuter en tant que root (juste le thread de socket). Et de toute façon, cette applet ne peut littéralement pas être exploitée / jamais entendu parler d'un problème d'escalade de privilèges avec Node.js / pourquoi être si paranoïaque alors que c'est clairement inutile ? La meilleure pratique n'est pas la seule pratique et elle n'est jamais la meilleure pour tous les cas d'utilisation... comme sur une VM où vous avez la racine et ne pouvez rien faire, gg hacker bruh.

Quoi qu'il en soit, le fonctionnement de npm dépasse le cadre de ce référentiel.

Si vous voulez que nvm fonctionne pour un utilisateur root, alors cet utilisateur root doit avoir sa propre installation de nvm .

sur un système basé sur debian (ou ubuntu) en plus de définir l'alias comme @mpotra a dit que vous devrez peut-être exécuter
sudo ln -s "$(which node)" /usr/local/bin/node pour que npm fonctionne en mode sudo

sudo ln -s "$(which node)" /usr/local/bin/node
les sorties
ln: failed to create symbolic link '/usr/local/bin/node': File exists

Je voulais exécuter un ancien SDK. Ce sdk devrait utiliser l'ancien nœud v6.
La commande suivante n'a pas fonctionné pour moi :

sudo somesdk

Command 'node' not found

Comme suggéré, je suis passé à sudo :

sudo -s

Ensuite, j'ai lu nvm.sh pour l'utilisateur actuel (par exemple someuser ):

source /home/someuser/.nvm/nvm.sh

Après cela, j'ai nvm pour sudo (pour la session en cours, ce qui me suffit)

root<strong i="21">@domain</strong>:~# nvm

Node Version Manager (v0.35.2)

Voici une solution de contournement ad hoc que vous pouvez utiliser pour exécuter temporairement des commandes :

$ sudo PATH=$PATH bash -c "node ..."

Par exemple:

$ sudo PATH=$PATH bash -c "which node npm pnpm"
/home/alex/.nvm/versions/node/v13.10.1/bin/node
/home/alex/.nvm/versions/node/v13.10.1/bin/npm
/home/alex/.nvm/versions/node/v13.10.1/bin/pnpm