puppi init without root user gives permission denied error #4

Open
trunet opened this Issue Nov 30, 2011 · 5 comments

Comments

Projects
None yet
2 participants

trunet commented Nov 30, 2011

Definition on a host:
include puppi
puppi::project::war { "me-tag":
source => "http://1.2.3.4/deploy/me-tag.war",
deploy_root => "/opt/tomcat-me/webapps",
user => "tomcat",
init_script => "tomcat-me",
disable_services => "apache-kaizen",
enable => "true",
}

[root@abcdltda16 log]# puppi init me-tag
abcdltda16 Init: 40-me-tag-Deploy_Files [ OK ]
/etc/puppi/scripts/functions: line 154: /tmp/puppi/me-tag/config: Permission denied
/etc/puppi/scripts/functions: line 155: /tmp/puppi/me-tag/config: Permission denied
/etc/puppi/scripts/functions: line 156: /tmp/puppi/me-tag/config: Permission denied

REPORT FOR PUPPI - STATUS OK
Summary of operations is: /var/log/puppi/me-tag/20111130-110851/summary
Details are in: /var/log/puppi/me-tag/20111130-110851/
Temporary workdir has been: /tmp/puppi/me-tag/ (Will be rewritten at the next puppi run)
Runtime config file is: /tmp/puppi/me-tag/config
Files have been archived in: /var/lib/puppi/archive/me-tag/20111130-110851

Owner

alvagante commented Nov 30, 2011

puppi init is for special purposes.
To deploy a war (also the first time) write:
puppi deploy me-tag

(Reopen the ticket if this doesn't solve your error)

alvagante closed this Nov 30, 2011

Owner

alvagante commented Nov 30, 2011

Oh, btw, THAT'S STILL A BUG (on the init procedure when user => is not root), but as said, you have not to use puppi init (and when you use init you've to define a init_source ).
Probably have to make this more clear on the documentation.

trunet commented Nov 30, 2011

I already did this before(running deploy directly) and it worked.

I didn't understand the init function before so I think you've to add something on documentation.

Also, the easiest way to resolve this is to equal $puppi::params::configfile_owner to $user I think.

Owner

alvagante commented Nov 30, 2011

Yes, better docs on this is definitively reccommended.

I can't change $puppi::params::configfile_owner because you may have different users for different puppi defines on the same server... a quick work around would be a 777 but it would be a (local) security issue (the file is recreated on each puppet run, but on a fixed location and a race condition could exploit it).
I should review better where the runtime config file is written with commands that might be run by custom users.

Anyway, thanks for the report, and have fun with puppi.

trunet commented Nov 30, 2011

no problem, as this is a confirmed bug isn't better to leave this issue opened?

alvagante reopened this Nov 30, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment