J'essaie d'installer une application Rails et chaque fois que j'utilise bundle
, elle échoue sans Sudo
. Ma situation actuelle est que tout fonctionne tant que vous utilisez Sudo
pour tout, y compris Rails. Je ne pense pas que c'est correct.
Par exemple:
$ bundle update
Updating git://github.com/refinery/refinerycms.git
Fetching gem metadata from https://rubygems.org/.......
Fetching gem metadata from https://rubygems.org/..
Resolving dependencies...
Enter your password to install the bundled RubyGems to your system:
Using rake (10.0.4)
Using i18n (0.6.1)
Using multi_json (1.7.2)
Using rack-cache (1.2)
Using rack-test (0.6.2)
Installing hike (1.2.2)
Errno::EACCES: Permission denied - /usr/local/rvm/gems/Ruby-1.9.3-p194/build_info/hike-1.2.2.info
An error occurred while installing hike (1.2.2), and Bundler cannot continue.
Make sure that `gem install hike -v '1.2.2'` succeeds before bundling.
Mais alors je fais ce que ça dit et ça marche:
$ gem install hike -v '1.2.2'
Successfully installed hike-1.2.2
Parsing documentation for hike-1.2.2
Installing ri documentation for hike-1.2.2
Done installing documentation for hike after 0 seconds
1 gem installed
Ce modèle se répète encore et encore pour différentes gemmes. Je ne comprends pas. Pourquoi cela arrive-t-il? Si j'utilise Sudo
bundle se mettra à jour sans cette erreur. Mais la situation actuelle est que j'ai besoin de Sudo
pour tout, y compris rake...
ou Rails server
, etc. Quelque chose ne va pas.
Détails supplémentaires: je suis sur OSX 10.8.3 ...
$ Ruby -v
Ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-darwin11.4.0]
$ gem -v
2.0.3
$ rvm -v
rvm 1.19.6 (stable) by Wayne E. Seguin <[email protected]>, Michal Papis <[email protected]> [https://rvm.io/]
$ which Ruby
/usr/local/rvm/rubies/Ruby-1.9.3-p194/bin/Ruby
$ which gem
/usr/local/rvm/rubies/Ruby-1.9.3-p194/bin/gem
$ which rvm
/usr/local/rvm/bin/rvm
Mettre à jour
Il peut être informatif que je puisse exécuter Sudo bundle install
sans erreur. Ensuite, immédiatement après bundle install
, une erreur semblable à celle décrite ci-dessus échoue. Pourquoi est-ce?
Update2
/usr/local/rvm[master]$ ls -l
total 56
-rw-rw-r-- 1 root rvm 566 May 4 12:59 LICENCE
-rw-rw-r-- 1 root rvm 8929 May 4 12:59 README
-rw-rw-r-- 1 root rvm 7 May 4 12:59 RELEASE
-rw-rw-r-- 1 root rvm 7 May 4 12:59 VERSION
drwxrwsr-x 3 root rvm 102 May 4 01:34 archives
drwxrwsr-x 35 root rvm 1190 May 4 12:59 bin
drwxrwsr-x 11 root rvm 374 May 4 12:59 config
drwxrwsr-x 6 root rvm 204 Jan 10 19:55 contrib
drwxrwsr-x 5 root rvm 170 Jan 10 19:55 environments
drwxrwsr-x 3 root rvm 102 Jan 10 19:55 examples
drwxrwsr-x 5 root rvm 170 Jan 10 19:52 gems
drwxrwxr-x 6 ESL rvm 204 May 4 12:59 gemsets
drwxrwsr-x 92 root rvm 3128 May 4 01:34 help
drwxrwsr-x 11 root rvm 374 May 4 01:34 hooks
-rw-rw-r-- 1 root rvm 11 May 4 12:59 installed.at
drwxrwsr-x 4 root rvm 136 Jan 10 19:54 lib
drwxrwsr-x 5 root rvm 170 May 4 12:55 log
drwxrwsr-x 2 root rvm 68 Jan 10 19:52 man
drwxrwsr-x 9 root rvm 306 Jan 10 19:52 patches
drwxrwxr-x 4 ESL rvm 136 May 4 12:59 patchsets
drwxrwsr-x 4 root rvm 136 Jan 10 19:55 rubies
drwxrwsr-x 64 root rvm 2176 May 4 01:34 scripts
drwxrwsr-x 3 root rvm 102 May 4 01:34 src
drwxrwsr-x 2 root rvm 68 Jan 10 19:52 tmp
drwxrwsr-x 8 root rvm 272 May 4 12:59 user
drwxrwsr-x 4 root rvm 136 Jan 10 19:52 usr
drwxrwsr-x 5 root rvm 170 Jan 10 19:55 wrappers
Vous pouvez héberger des pierres précieuses dans votre dossier de départ de l'utilisateur, qui ne nécessite pas d'autorisations root:
bundle install --path ~/.gem
Pour éviter de transmettre ce paramètre manuellement, ajoutez export GEM_HOME=$HOME/.gem
à votre .bash_profile
- ceci résout le problème Sudo sur Mac OS et d'autres systèmes * nix. Vous devrez peut-être aussi avoir accès aux gems qui fournissent des exécutables (tels que bundler), alors ajoutez ceci aussi:
PATH=$PATH:$HOME/.gem/bin
ou dans certains cas:
PATH=$PATH:$HOME/.gem/Ruby/<version>/bin
ref: https://stackoverflow.com/a/5862327/322020
UPD: Mais gardez à l’esprit que si vous commencez à utiliser rbenv, le fait que cette variable d’environnement soit identique risque de poser des problèmes lors de l’utilisation de versions trop différentes de Ruby. Il est donc préférable de définir unset GEM_HOME
ou d'ajouter une version personnalisée à chaque démarrage de -ed Ruby.
Votre répertoire de gem RVM doit appartenir au groupe rvm
. Ainsi, au lieu de changer de propriétaire, il peut être judicieux d’ajouter simplement l’utilisateur au groupe rvm
:
# $(whoami) evaluates to your username
# You may want to change this to a different username depending on your config
# but $(whoami) is a passable default
usermod -a -G rvm $(whoami)
Cela est dû à la façon dont vous avez installé Ruby.
Franchement, cela fonctionne * très bien * si le Sudo ne vous dérange pas. À la fin de la journée, il ne reste que votre ordinateur portable ... Pas un serveur fonctionnant dans une banque.
Si vous y tenez, chown dossiers GEM au besoin.
J'ai eu ce qui s'est passé aujourd'hui. Il s’agit peut-être d’une situation unique, mais j’avais copié une arborescence de sources Rails d’un système sur lequel RVM était installé globalement (à l’échelle du système dans /usr/local/rvm
) sur un système qui venait d’être installé par utilisateur (~/.rvm
).
J'essayais de faire bundle install
et d'obtenir le message "Votre compte d'utilisateur n'est pas autorisé à installer sur le système Rubygems." Erreur. Après avoir beaucoup fouillé, j'ai remarqué qu'il y avait un lien symbolique dans mon répertoire ~/.rvm
:
~/.rvm/gems/Ruby-2.1.1/cache -> /usr/local/rvm/gems/cache
En supprimant ce lien symbolique, bundle install
fonctionna sans Sudo
.
J'ai eu le même problème et découvert que Bundler, avant d'installer de nouvelles gems, vérifie s'il dispose des droits en écriture pour tous les fichiers trouvés. $ GEM_HOME/build_info. Dans mon cas, ce n'était pas le cas, car même si l'utilisateur qui exécutait le bundle était dans le groupe d'utilisateurs 'rvm' et que ce groupe possédait tous ces fichiers, il n'était pas autorisé à en écrire certains.
Cela est dû au fait que j'ai installé certaines des pierres précieuses sous root, qui ont umask 0022 (tous les fichiers créés par root, ne peuvent pas être écrites par groupe) au lieu d’umask 0002 que d’autres ont et que attend rvm.
Si vous utilisez RVM, alors faites ces deux étapes et vous serez en or
Assurez-vous que votre utilisateur appartient au groupe RVM
Sudo usermod -a -G rvm myUserName
Assurez-vous que build_info est accessible en écriture pour tous les utilisateurs du groupe RVM.
Sudo chmod 664 $GEM_HOME/build_info/*