vlad 部署者 - 使用不同的用户进行部署?

发布于 2024-09-10 08:29:31 字数 457 浏览 6 评论 0原文

我们使用 vlad 部署程序将 Rails 应用程序部署到生产和测试服务器。我们所有的服务器都是Ubuntu服务器。

我们遇到了与 Linux 权限相关的问题。

Vlad 使用 ssh 将文件放在任何服务器上,无论是生产服务器还是测试服务器。我的公司有几个人,每个人在每台服务器上都有不同的帐户。

另一方面,我们的 Apache 服务器的配置方式是使用网站目录的“所有者”来读取该目录上的文件。

结果,进行第一次部署的用户成为该站点的“所有者”;其他用户无法进行部署 - Apache 将无法读取修改后的文件,因为所有者已更改。

通常这不是什么大问题,但现在假期即将来临,我们希望尽可能干净地解决这个问题 - 例如,我们希望避免共享密码/ssh 密钥。

理想情况下,我需要一个 vlad 任务来对已部署文件的权限执行某些操作,以便其他用户可以完全修改它们。我对 UNIX 命令了解不够,无法做到这一点。

We're using vlad the deployer for deploying rails apps to production and test servers. All our servers are Ubuntu servers.

We have a problem related with linux permissions.

Vlad uses ssh to put files on any server, be it production or test. My company has several people, and each one has a different account on each server.

On the other hand, the way our Apache server is configured, it uses the "owner" of a website directory for reading files on that directory.

As a result, the user that makes the first deployment becomes the "owner" of the site; other users can't make deployments - Apache will not be able to read the modified files, since the owner has changed.

Normally this isn't much of an issue, but now holidays are approaching and we'd like to solve this as cleanly as possible - for example, we'd like to avoid sharing passwords/ssh keys.

Ideally I would need one vlad task that does something to the permissions of the deployed files so they could be completely modified by other users. I don't know enough about unix commands in order to do this.

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

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

发布评论

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

评论(3

千笙结 2024-09-17 08:29:31

我会用组权限来做到这一点。

让 Web 根目录为 /var/www/your-app/current

/var/www/your-app/ 应该是所有进行部署的人员所属的组可写的组。

设置部署脚本,以便它们写入名为 /var/www/your-app/>timestamp< 的目录其中时间戳是当前时间戳。

/var/www/your-app/current 是一个符号链接,当您成功地将所有文件复制到新目录时,您将更新符号链接的目标,以便它指向您创建的目录。

这样每个人都可以部署,并且可以看到谁部署了哪个版本。

这也使得部署变得原子化,因此如果您在部署过程中失去网络连接,也不会造成任何破坏。

由于您不会删除旧目录,因此如果您设法引入一些错误,则可以轻松回滚到“最后的好”状态。

I would do it with group permissions.

have the web root be /var/www/your-app/current

/var/www/your-app/ should be group writable by the group that all persons doing deploys belong to.

set up the deploy scripts so that they write to a directory called /var/www/your-app/>timestamp< where timestamp is the current timestamp.

/var/www/your-app/current is a symlink, and when you have sucessfully copied all files to the new directory you update the target of the symlink, so that it points to the directory you created.

This way everyone can deploy, and you can see who deployed what version.

This also makes the deploy atomic, so nothing will break if you lose your network connection in the middle of the deploy.

Since you won't delete the old catalogs, you can easy do a rollback to a "last good" state, if you manage to introduce some bug.

赢得她心 2024-09-17 08:29:31

为什么不让所有文件公开可读?在每个用户的 ~/.bashrc 中放入

umask o=r

http://en.wikipedia 行。 org/wiki/Umask

顺便说一句,我从来没有听说过这样的 Apache 选项;你是说当 Apache 从 /home/USER 读取文件时,它以 USER 的 UID 运行,而不是“nobody”或“apache”?这听起来很奇怪。

Why don't you make all the files publicly readable? In the ~/.bashrc of each user put the line

umask o=r

http://en.wikipedia.org/wiki/Umask

BTW I have never heard of such an Apache option; are you saying when Apache reads a file from /home/USER it runs with the UID of USER, instead of "nobody" or "apache"? That sounds wonky.

伴我老 2024-09-17 08:29:31

我已经和它斗争了几个月了,我只找到了几种方法:

  • 对部署到服务器的所有用户使用单个共享帐户(嘘!)
  • 使用不同的帐户,但进行 chown在执行与帐户相关的任务(例如 svn 更新)之前,访问公共用户帐户(www-data、rails 或类似帐户)。这可能有效,但我还没有测试过。
  • 使用访问控制列表。有人向我暗示这可能是正确的解决方案。但是,我没有知识或时间来使其正常工作。

目前,我们只是继续每个项目使用一个用户,并在需要时手动更改所有内容。虽然有点痛苦,但确实有效。

I've been fighting with it for a couple months now and I've only found a couple ways to do it:

  • Use a single shared account for all the users deploying to the server (boo!)
  • Use different accounts, but make a chown to a common user account (www-data, rails, or similar) before performing account-dependant tasks (such as the svn update). This might work, but I haven't tested it.
  • Use access control lists. Someone has hinted at me that this might be the right solution. However, I don't have the knowledge or time to make this work properly.

For now, we are just continuing using one single user per project, and chowning everything manually when needed. It's a bit of a pain, but it works.

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