Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

puppi init without root user gives permission denied error #4

Open
trunet opened this Issue · 5 comments

2 participants

@trunet

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

@alvagante
Owner

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 alvagante closed this
@alvagante
Owner

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

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.

@alvagante
Owner

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

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

@alvagante alvagante reopened this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.