我有一个构建Maven项目的Jenkins服务器。当Jenkins构建此项目时,$WORKSPACE
下的所有构建工件都具有文件权限jenkins:jenkins
。
在 post step 中,这些构建工件将被复制到/srv/myproject/
,Tomcat实例将从此处为构建的工件提供服务。 /srv/myproject/
归tomcat7/tomcat7
所有。
此帖子步骤失败,Jenkins报告Failed to copy $WORKSPACE/somefile to /srv/myproject/somefile due to java.io.FileNotFoundException /srv/myproject/somefile (Permission denied)
- Linux用户jenkins
不允许修改Linux用户tomcat7
拥有的文件。
如何更改Jenkins的所有权'制作文物?我正在寻找能够考虑安全性的解决方案,例如:给予jenkins
sudoer权限似乎并不明智。此外,将srv/myproject/**
的所有权更改为jenkins:jenkins
更像是一种解决方法。
答案 0 :(得分:2)
您可以考虑为这两个用户创建一个组,我们称之为ftp
。
您可以将/srv/myproject/
文件夹的所有权更改为ftp
群组:
sudo chown -R :ftp /srv/myproject
将用户jenkins
和tomcat7
添加到ftp
群组:
sudo usermod -a -G ftp jenkins
sudo usermod -a -G ftp tomcat7
现在,用户jenkins
和tomcat7
都应该能够访问/srv/myproject
。
答案 1 :(得分:1)
也许您应该尝试归档(zip,rar等)所有必需的文件,并将所有权保留在具有完全权限的文件中(例如,拥有777权限的archive.zip文件),所以当你这样做的时候取消归档,您将获得文件的正确所有权。
答案 2 :(得分:1)
将文件部署到服务中并不是Jenkins的用途。如果这对您来说是最佳解决方案,那么您应该将部署脚本作为tomcat用户运行;也就是说,在Jenkins shell脚本中使用“sudo”或等效文件。
您应该考虑更好的解决方案。
答案 3 :(得分:0)
如果必须以本地操作完成复制,则使用已在评论中描述的linux用户/组/ ACL。
如果可以不进行本地复制,则可以为tomcat用户启用ssh访问,并使用sftp / rsync上传工件并设置正确的规则。性能损失不会太大,但您将能够删除本地环境锁定,并且能够在将来上传到任何环境中。