John,
thank you for pointing me in the right direction. The problem was that each
time I made changes to hiera.yaml file I'll restart the master with service
puppetmaster restart.
Well apparently the master was not really restarting even though it was
saying it was. So it was going into this strange state where sometimes
puppet agent -tv would find the file and sometimes it would not.
So after each change I had to go and kill the process because using service
puppetmaster restart/stop did not really kill the process. I tried this on
Centos instead of Debian Wheezy and did not have this problem.
On Wednesday, January 8, 2014 9:38:12 AM UTC-6, jcbollinger wrote:
>
>
>
> On Tuesday, January 7, 2014 11:39:14 AM UTC-6, kai wrote:
>>
>> What version of Puppet are you running?
>>> *3.4.1 for both master and agent*
>>> As what user is the master running? (Typically an unprivileged user
>>> named 'puppet'.)
>>> *The master is running as user puppet*
>>> As what user are you running the agent in your tests?
>>> *I am running the agent and the apply commands on the master as the root
>>> user*
>>> As what user are you running "puppet apply" in your tests?
>>> *root*
>>> What are the ownership and permissions of /etc/puppet/data/
>>> loc.example.com/production/Debian/wheezy.yaml and all the directories
>>> in the path to it? Do any of those have extended ACLs set on them?
>>> *The permissions of the directory and the yaml file are root:root. No
>>> ALC's. I chown-ed then to puppet:puppet with the same result.*
>>> Are you running SELinux in enforcing mode? If so, then do you see
>>> relevant AVC messages in the system log?
>>> *This is a Debian Wheezy, so no selinux or apparmor on it.*
>>>
>>>
>
> The point here was that the master need to be able to access and read
> those hiera data files that exist, and indeed to determine which do exist.
> That does not necessarily require user 'puppet' to own the file and
> directories, but it does require 'puppet' to have read permission on the
> file itself and both read and traverse permission on ALL directories in the
> path to the file.
>
>
>
>> The bellow works fine with this:
>>
>> $ puppet apply --debug --environment=production -e '$test =
>> hiera('ssh_service_config') notify { $::test: }'
>> Debug: hiera(): Hiera YAML backend starting
>> Debug: hiera(): Looking up ssh_service_config in YAML backend
>> Debug: hiera(): Looking for data source defaults
>> Debug: hiera(): Looking for data source puppetmaster.iad3.example.com
>> Debug: hiera(): Cannot find datafile
>> /etc/puppet/data/puppetmaster.iad3.example.com.yaml, skipping
>> Debug: hiera(): Looking for data source production/Debian/wheezy
>> *Debug: hiera(): Found ssh_service_config in production/Debian/wheezy*
>>
>> but not with
>>
>> $ pupept agent -tv
>> *Error: Could not retrieve catalog from remote server: Error 400 on
>> SERVER: Could not find data item ssh_package_name in any Hiera data file
>> and no default supplied at
>> /srv/puppet/environments/production/modules/ssh/manifests/install.pp:2 on
>> node puppetmaster.iad3.example.com <http://puppetmaster.iad3.example.com>*
>>
>>
>
> So far I don't think you have presented the master's logs for the failure
> case. Those might be illuminating. Do first restart the master with debug
> logging enabled to gather the most information.
>
> You could also put Notify resources or notice() calls in your manifests on
> the master to verify that the fact values the agent presents to the master
> are the same as the ones used by "puppet apply".
>
> Overall, I see only two reasonable possibilities:
>
> 1. the master is looking for a different data file than "puppet apply"
> reads, or no file at all, or
> 2. the master is prevented from reading the specified file, and
> perhaps from even testing for its existence.
>
> The former would suggest a configuration issue, whereas the latter would
> be some kind of access control issue. I am so far disinclined to think
> that there is a Puppet bug in play here.
>
>
> John
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/eb3183cc-b71b-4151-89eb-28ff1fcf2ba6%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
