Rails 3.2 Pipeline d’actifs avec Thin et Apache, ne trouvant pas d’actifs

Ma question est similaire à celle de ce pipeline de Rails 3.2 Asset avec des erreurs Passager Endless sauf que lorsque j’essaie d’aller réellement à

 

Je reçois un 404. Voici ce que je ne comprends pas. Il cherche dans / assets /, mais quand je regarde le code qui a été déployé, les actifs sont uniquement dans / public / assets, ce qui est en fait un lien symbolique vers / var / www / myapp / shared / assets. Alors, qu’est-ce qui est responsable dans le monde de dire à l’application que regarder dans / assets va produire des résultats corrects?

J’utilise Rails 3.2.0, ruby-1.9.3-p125, déployant sur Ubuntu, Apache et Thin.

Je devrais préciser: mes ressources sont effectivement déployées sur le serveur. Tout fonctionne parfaitement jusqu’à ce qu’ils aient besoin d’être servis, auquel cas production.log me dit qu’ils les recherchent dans /assets/application-eed7996ee9017637f923133371ab3e92.css, dont les 404.

Pour chaque demande mon thin.log dit

 cache: [GET /] miss 

et production.log dit

 ActionController::RoutingError (No route matches [GET] "/assets/application-abecf2e096af9ee80697fd49e79a55e7.js"): 

MISE À JOUR @Brandan merci pour l’aide. Mes actifs sont en effet dans RAILS_ROOT/public/assets . Je mets ceci dans mon fichier Apache vhost:

 DocumentRoot /var/rails/myappname/current/public RewriteEngine On XSendFile On XSendFilePath /var/rails/myappname #not even sure if this line is needed  Header unset ETag FileETag None ExpiresActive On ExpiresDefault "access plus 1 year"  

Mes parameters RAILS_ROOT / config / environnements / production.rb :

 config.cache_classes = true config.consider_all_requests_local = false config.action_controller.perform_caching = true config.serve_static_assets = false config.assets.compress = true config.assets.comstack = false config.assets.digest = true config.action_dispatch.x_sendfile_header = "X-Sendfile" # for apache 

J’ai ce problème depuis des jours maintenant. Je pensais que c’était un problème avec capistrano ou la version ruby ​​mais je suis sûr que ce sont aussi des permissions associées.

Ma configuration était à peu près la même que la vôtre bien que j’utilise également Unicorn.

Voici ce que j’ai fait pour sortinger:

  1. Supprimez temporairement la section suivante car je pense que cela posait problème avec le dépannage:

       Header unset ETag FileETag None ExpiresActive On ExpiresDefault "access plus 1 year"  

Peut-être que tout cela fonctionnera et ensuite l’append. Je ne pense pas que ce soit la cause des problèmes, cependant, lorsque vous diagnostiquez des choses comme ça, il est préférable d’enlever autant que possible pour trouver le coupable.

  1. Exécutez un chown -R xxx.xxx (remplacez xxx par votre utilisateur ou utilisateur Web) dans le répertoire public. Dès que je l’ai fait, le css est réapparu.

  2. (Ce que j’ai fait mais peut-être pas essentiel) Vous pouvez également installer localement sans cap. juste au cas où il y aurait un problème avec elle. Cela a aussi fonctionné pour moi.

  3. Complètement wipeout tmp / cache et public / * juste au cas où.

  4. Redémarrez votre serveur Apache plusieurs fois.

Vous pouvez voir un résumé de ma conf. ici

Supprimez les lignes suivantes de votre configuration Apache.

 ProxyPass / balancer://thinservers/ ProxyPassReverse / balancer://thinservers/ 

La réponse venait de In Rails, devrais-je activer serve_static_assets? .

En règle générale, vos actifs ne doivent exister que dans /public/assets pour une application déployée.

Apache doit être configuré pour que son DocumentRoot soit votre RAILS_ROOT/public . Ensuite, il servira http://example.com/assets/whatever.css partir de RAILS_ROOT/public/assets/whatever.css , et ne RAILS_ROOT/public/assets/whatever.css jamais par Rails pour les actifs statiques.

Avez-vous redémarré votre application depuis que vous avez précompilé vos actifs? Parfois, Rails attend une version compilée plus ancienne / plus récente de vos actifs que celle actuellement déployée.

Essayez de supprimer les directives ProxyPass et ProxyPassReverse de votre configuration apache / thin. L’indicateur P de votre règle de réécriture exécute déjà la passe de proxy souhaitée.

Voir http://httpd.apache.org/docs/2.0/mod/mod_proxy.html pour plus d’informations.

Passanger connaît son application RoR car il existe un fichier config.ru.

La même erreur que vous signalez me est arrivée à cause de fausses permissions. Apache n’a pas été en mesure de servir les fichiers à l’intérieur des fichiers, mais a pu envoyer les fichiers sur des fichiers public/

Dans mon cas, j’utilise capistrano, donc les assets étaient un lien symbolique vers shared/public/assets .

ce que j’ai fait était:

 chmod -R o+x shared/ 

Les permissions x sont nécessaires pour répertorier et accéder aux répertoires. Après ça a fonctionné. Vous devez vous assurer que les assets ont + x pour les autres