Rails 3.1 - 使用 capistrano 部署后的权限

发布于 2024-12-23 00:12:09 字数 1253 浏览 1 评论 0原文

我正在使用 capistrano 将我的应用程序部署到我的新 Rails 3.1 服务器。

当我尝试浏览页面时,出现 Rails 错误。
在查看 error.log 时,我看到的是这样的:

ActionView::Template::Error (Permission denied - /var/www/episodecalendar/production/releases/20111227204950/tmp/cache/55B):
    32:                 </div>
    33:                 <div id="footer">
    34:                   <div id="footer_content">
    35:                     <% cache("footer") do %>
    36:               <%= render :partial => "partials/footer" %>
    37:             <% end %>
    38:             </div>
  app/views/layouts/application.html.erb:35:in `_app_views_layouts_application_html_erb___3483336897212790867_58416560'

显然 /tmp 文件夹中的文件没有“正确”的权限。示例:

root@Ubuntu:/var/www/episodecalendar/staging/current/tmp/cache/assets/C0C/690# ls -la
total 12K
drwxr-xr-x 2 root root 4.0K 2011-12-27 21:33 .
drwxr-xr-x 3 root root 4.0K 2011-12-27 21:33 ..
-rw-r--r-- 1 root root 2.6K 2011-12-27 21:33 sprockets%2F31007441199035e09c0c45c33930cf06

解决该问题的唯一方法是使用 chmod 777 tmp/ -R,然后网站会立即加载。

我可以将 chmod 修复放入 capistrano 配方中,但这似乎是一个丑陋的黑客。
为什么 /tmp 文件夹在部署后没有“正确”权限,如何修复它?

I'm deploying my app to my new Rails 3.1 server with capistrano.

When I'm trying to browse the page, I get a rails error.
While looking in the error.log, this is what I see:

ActionView::Template::Error (Permission denied - /var/www/episodecalendar/production/releases/20111227204950/tmp/cache/55B):
    32:                 </div>
    33:                 <div id="footer">
    34:                   <div id="footer_content">
    35:                     <% cache("footer") do %>
    36:               <%= render :partial => "partials/footer" %>
    37:             <% end %>
    38:             </div>
  app/views/layouts/application.html.erb:35:in `_app_views_layouts_application_html_erb___3483336897212790867_58416560'

Obviously the files in the /tmp folder don't have the "correct" permissions. Example:

root@Ubuntu:/var/www/episodecalendar/staging/current/tmp/cache/assets/C0C/690# ls -la
total 12K
drwxr-xr-x 2 root root 4.0K 2011-12-27 21:33 .
drwxr-xr-x 3 root root 4.0K 2011-12-27 21:33 ..
-rw-r--r-- 1 root root 2.6K 2011-12-27 21:33 sprockets%2F31007441199035e09c0c45c33930cf06

The only way to fix it, is a chmod 777 tmp/ -R, and then the site loads straight away.

I could put the chmod fix in a capistrano recipe, but that seems like an ugly hack.
Why doesn't the /tmp folder have the "correct" permission after a deploy, and how can I fix it?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

稚气少女 2024-12-30 00:12:09

您可能需要考虑确保 /var/www/episodecalendar/staging/ 是由任何需要访问权限来运行 Web 服务器的用户递归地chown'dchown -R user:group /var/www/episodecalendar/staging)。

我建议创建一个单独的 deploy@Ubuntu 用户,以便(与 root 不同)权限问题很快变得明显。

Rather than permitting everyone access to all files and folders within tmp chmod 777 -R tmp/, you may want to consider ensuring that /var/www/episodecalendar/staging/ is recursively chown'd (chown -R user:group /var/www/episodecalendar/staging) by whatever user requires access to run the web server.

I'd recommend creating a separate deploy@Ubuntu user so that (unlike root) permissions issues become apparent quickly.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文