Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

$server_git_repo = true with default $server_git_repo_path fails on 'Permission denied' #699

Open
westbywest opened this issue May 10, 2019 · 1 comment
Labels

Comments

@westbywest
Copy link
Contributor

westbywest commented May 10, 2019

Enabling the $server_git_repo for the default path throws this error under CentOS 7 with agent v5.5:

Notice: /Stage[main]/Puppet::Server::Config/Git::Repo[puppet_repo]/Exec[git_repo_for_puppet_repo]/returns: fatal: cannot mkdir /opt/puppetlabs/puppet/cache/puppet.git: Permission denied
Error: '/usr/bin/git init  --bare /opt/puppetlabs/puppet/cache/puppet.git' returned 128 instead of one of [0]
Error: /Stage[main]/Puppet::Server::Config/Git::Repo[puppet_repo]/Exec[git_repo_for_puppet_repo]/returns: change from 'notrun' to ['0'] failed: '/usr/bin/git init  --bare /opt/puppetlabs/puppet/cache/puppet.git' returned 128 instead of one of [0] (corrective)

Appears to be due to $vardir being set to explicit root ownership, yet the git repo resource owned by $user:$group by default, i.e by puppet:puppet:
https://github.com/theforeman/puppet-puppet/blob/master/manifests/server/config.pp#L241

One could set $server_git_repo_user and $server_git_repo_group explicitly to root, but that seems suboptimal.

@westbywest westbywest changed the title $server_git_repo = true with default $server_git_repo_path failes on 'Permission denied' $server_git_repo = true with default $server_git_repo_path fails on 'Permission denied' May 10, 2019
@westbywest
Copy link
Contributor Author

Follow-up to failure described above is that subsequent runs of puppet agent, with $server_git_repo_user and $server_git_repo_group set to root, are consistently chown-ing /opt/puppetlabs/puppet/cache and then bouncing puppetserver. This is with server v5.3.8.

Notice: /Stage[main]/Puppet::Server::Config/File[/opt/puppetlabs/puppet/cache]/owner: owner changed 'puppet' to 'root' (corrective)
Notice: /Stage[main]/Puppet::Server::Config/File[/opt/puppetlabs/puppet/cache]/group: group changed 'puppet' to 'root' (corrective)
Info: Class[Puppet::Server::Config]: Scheduling refresh of Class[Puppet::Server::Service]
Info: Class[Puppet::Server::Service]: Scheduling refresh of Service[puppetserver]

This resource appears to collide destructively with what puppetserver wants:
https://github.com/theforeman/puppet-puppet/blob/master/manifests/server/config.pp#L241

file { $::puppet::vardir:
  ensure => directory,
  owner  => 'root',
  group  => 'root',
}

My work-around was to override the resource attributes in my calling class:

if $::puppet::server_git_repo {
  File<| title == $::puppet::vardir |> {
    owner => $::puppet::server_user,
    group => $::puppet::server_group
  }
}

@ekohl ekohl added the Bug label May 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants