Capistrano + mince + nginx avec l'utilisateur pas autorisé à sudo howto?

Question

J'ai un scénario comme celui-ci que je veux utiliser Capistrano pour déployer mon application Ruby on Rails:

1. L'application Web est sur un cluster mince avec le fichier de configuration stockées dans/etc/mince. aussi un script d'initialisation est dans /etc/init.d/thin, donc il démarre automatiquement chaque fois que mon serveur a besoin d'un redémarrage
2. De même nginx est exécuté de la même manière (en tant que démon de script init)
3. Pour être sûr Si quelqu'un a piraté mon serveur web, je ne veux pas qu'ils fassent quelque chose de trop horrible, donc l'internaute n'est pas autorisé à sudo.
4. mince et nginx les deux pistes que le webuser de faire respecter cette sécurité

Maintenant, quand je dois faire le déploiement, je besoin des fichiers à installer dans/home/webuser/railsapps/helloworld, et je besoin du script de démarrage redémarrer mon mince après. Je souhaite conserver tous les fichiers appartenant à l'utilisateur web, de sorte que l'utilisateur principal du script cap s'exécute en tant qu'utilisateur web. Maintenant, le problème survient lorsque je veux redémarrer le démon thin parce que webuser ne peut pas sudo.

Je pense qu'il est possible d'invoquer deux sessions distinctes - webuser pour le déploiement de fichiers, puis un sudoer spécial pour redémarrer le démon. Quelqu'un peut-il me donner un exemple de script à ce sujet?

Answer 1

Cela pourrait ne pas être ce que vous voulez, mais vous pouvez réellement faire quelque chose comme ceci dans votre fichier sudoers:

someuser ALL=NOPASSWD: /etc/init.d/apache2 

qui permet d'exécuter UnUtilisateur /etc/init.d/apache2

Si vous essayer de faire quelque chose d'autre:

$ sudo ls 
[sudo] password for someuser: 
Sorry, user someuser is not allowed to execute '/bin/ls' as root on ... 

Answer 2

une alternative à cela serait en cours d'exécution nginx en tant qu'utilisateur normal, dire sur le port 8080, puis en utilisant iptables pour rediriger les requêtes du port 80 vers le port 8080, de m Emory

iptables -A PREROUTING -t tcp -m tcp -p 80 -j DNAT --dport 8080

Enverra tous les paquets destinés au port 80 vers le port 8080, qui peuvent être liés en tant qu'utilisateur normal. Pourquoi ne pas utiliser sudo pour la routine de déploiement, puis chown -R sur le RAILS_ROOT?

Answer 3

Vous pouvez indiquer à Capistrano de modifier la propriété avant d'aliaser la version en cours.

Answer 4

Si vous exécutez Thin en tant qu'utilisateur web, l'utilisateur web ne peut-il pas terminer le processus? Vous pouvez redémarrer Thin à nouveau sans le démon, tant que vous passez tout le serveur dans/etc/thin, ça devrait aller. Le démon, autant que je le comprends, est juste un moyen pratique de contourner le lancement manuel d'un programme au démarrage.

La seule fois où vous vous déconnecterez, c'est quand vous devez éditer le contenu de/etc/thin. En supposant que vous utilisez des alias pour les bits thin.yml de votre utilisateur web, cela ne se produira que si vous voulez ajouter/supprimer un programme. Lorsque cela se produit, il peut être utile d'ajouter/de supprimer manuellement l'alias.

Tout ceci suppose que l'utilisateur web peut terminer le processus Thin pour commencer. Je ne sais pas autrement. La dernière fois, c'était un problème pour moi quand je n'avais pas le moyen d'exécuter l'application sur ma machine locale parce que son implémentation était à peu près liée à la disposition du serveur.Chaque fois que je modifiais quelque chose, je devais l'envoyer à SVN, passer les onglets dans le terminal à un shell ssh, le retirer de SVN, passer d'un autre ssh à un autre et redémarrer le démon pour voir si je l'avais cassé. Il m'a descendu, alors j'ai installé Thin localement, j'ai obtenu l'application pour lire les fichiers de configuration, et maintenant je n'ai plus qu'à télécharger une fois tous les quelques jours.

Answer 5

viens de remarquer que vous ne permettez pas à l'utilisateur de bien :-) sudo cette réponse va aider les autres:

Un peu plus tard le parti, mais je viens de faire ceci:

namespace :deploy do 
    desc "Start the Thin processes" 
    task :start do 
     run "cd #{current_path} && bundle exec sudo thin start -C /etc/thin/dankit.yml" 
    end 

    desc "Stop the Thin processes" 
    task :stop do 
     run "cd #{current_path} && bundle exec sudo thin stop -C /etc/thin/dankit.yml" 
    end 

    desc "Restart the Thin processes" 
    task :restart do 
     run "cd #{current_path} && bundle exec sudo thin restart -C /etc/thin/dankit.yml" 
    end 

end 

Ajout de sudo aux travaux bundle exec sudo thin start.