部署war文件时设置unix权限的更好方法

发布于 2024-08-28 21:51:20 字数 221 浏览 7 评论 0原文

我们有一个供应商应用程序,我们可以在其中下载他们的更新并部署一个 war 文件。我们正在运行 oracle 应用程序服务器 9i 的 unix 应用程序服务器上部署 war 文件。我相信当我们部署 war 文件时,我们会删除以前的安装,然后部署新的 war 文件。当我们部署war文件时,有时我们必须手动设置类和其他文件的unix文件权限。我们这样做是为了让所有 UNIX 用户 ID 都可以运行他们需要的进程。有更好的方法吗?

We have a vendor application where we download their updates and deploy a war file. We are deploying the war file on a unix application server running oracle application server 9i. I believe when we deploy the war file, we remove the previous install and then deploy the new war file. When we deploy the war file, sometimes we have to manually set the unix file permissions for the class and other files. We do this so all the unix user ids can run the processes they need. Is there a better way to do this?

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

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

发布评论

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

评论(3

倾城泪 2024-09-04 21:51:20

只是一些提示:
无法在 war/jar 中设置文件权限。

权限取决于 oracleas 用户的 umask。改变它并且
你就准备好了。

有什么办法可以让战争顺利进行吗?

Just a few HINTs:
There is no way to set file permissions within a war/jar.

The permissions depend on the oracleas user's umask. Change that and
you'll be all set.

Is there a way you can keep the war packaged?

如梦亦如幻 2024-09-04 21:51:20

我对 OAS 不太了解...但我假设从 war 文件解压出来的文件将由运行 OAS 的用户拥有和访问。这不正确吗?您能否更多地解释一下实际发生的情况或为什么这是一个问题?

根据您在下面的补充评论...

听起来您的安全模型根本不太正确:您将 OAS 及其数据与 dba 组关联,但 OAS(及其数据)的某些依赖项并不在该组中。我有一些建议:

  1. 为 OAS 及其依赖项创建一个新组,并评估 dba 组中的哪些用户也需要位于该组中。如果需要,请将 OAS 用户也保留在 dba 组中。
  2. 使用脚本部署 war 文件,该脚本等待部署完成并为您更改权限。
  3. 修复你的依赖关系。听起来好像 war 文件中的某些类应该部署在其他地方(应用程序上下文之外)并在那里引用。然后,他们可以拥有新的更合适的组,您可以将批处理用户和 OAS 用户添加到该组中。

I don't know much about OAS... but I'd presume the files unpacked from the war file would be owned and accessed by the user as which OAS is running. Is that not correct? Can you explain a bit more about what is actually happening or why this is a problem?

Following your additional comments below...

It sounds like your security model is simply not quite right: you associate OAS and its data with the dba group, but some dependencies of OAS (and its data) are not in that group. I have a few suggestions:

  1. Create a new group for OAS and its dependencies, and assess which users in the dba group also need to be in that group. If required, keep the OAS user in the dba group too.
  2. Deploy the war file using a script which waits for deployment to be complete and changes the permissions for you.
  3. Fix your dependencies. It sort of sounds like some of the classes in the war file should rather be deployed elsewhere - outside the application context - and referenced there. They can then have the new more appropriate group, to which you would add your batch process user and the OAS user.
审判长 2024-09-04 21:51:20

根据您对 Steven 的回答的评论,对于部署 war 文件的用户,将 umask 设置为 000 怎么样? (这将是 oracleas,umask 变量通常在该用户的 .profile 中设置。)umask(现在可能设置为 027)屏蔽文件权限,000 不会屏蔽任何内容,从而导致其他人的权限。

Based on your comment to Steven's answer, how about setting umask to 000 for the user that deploys the war file? (This would be oracleas, the umask variable is often set in the .profile of that user.) The umask (which is now probably set to 027) masks out file permissions, 000 does not mask out anything, resulting in permissions for others.

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