Issue using NFS directories as environments in Puppet 4

[PK]

Hi All,

I seem to be running into an issue when I try to use environments in my test Puppet 4 setup. I am in the process of migrating from Puppet 3 to Puppet 4.

puppetserver version: 2.7.2
puppet agent: 4.8.1
Server is running CentOS Linux release 7.3.1611

If I create local directories /etc/puppetlabs/code/environments/{dev,production} and populate it with all my Puppet related files, everything works fine. However, if I copy the same files over to a NFS share mounted at a different location and then create a symlink from /etc/puppetlabs/code/environments/dev to that new location, puppet agent doesn't like it and errors out.

[root] pwd
/etc/puppetlabs/code/environments
[root]# ll
lrwxrwxrwx 1 root root 23 Jan  2 14:21 dev -> /ln/systems/puppet4/dev

Errors on the client while running puppet agent -t:
Error: Could not retrieve catalog from remote server: Find /puppet/v3/catalog/hostname.com?environment=dev&facts_format=pson&facts=%257B%2522name%... resulted in 404 with the message: {"message":"Not Found: Could not find environment 'dev'","issue_kind":"RUNTIME_ERROR"}

Puppetserver errors:
2017-01-02 14:26:12,505 INFO  [qtp1908253991-68] [puppetserver] Puppet Not Found: Could not find environment 'dev'

This same setup (symlink to a NFS share) works perfectly fine with our current Puppet 3.7.5

I also tried mounting the NFS share directly at /etc/puppetlabs/code/environments, but that doesn't work either.

Has someone seen this before? Am I missing something?

Thanks!
PK

[Rob Nelson]

Does this happen if you use a symlink to a local file system location? dev -> /tmp/dev for example?

--


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 puppet-users...@googlegroups.com.


To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/01451c04-cbb4-418a-a138-8a0b4ffa581b%40googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

--

Rob Nelson

[Trevor Vaughan]

Do you have SELinux enabled?

Also, do you have 'all_squash' enabled on your NFS directories?

Trevor

--

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 puppet-users+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/01451c04-cbb4-418a-a138-8a0b4ffa581b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Trevor Vaughan
Vice President, Onyx Point, Inc

(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --

[PK]

Rob,

No. Symlink to a local file system works fine.

Tried it with:
dev -> /tmp/dev
dev2 -> /etc/puppetlabs/code/environments/devorig

Trevor,

SELinux is disabled and the puppet master server has full superuser access to the NetApp volume/directory. The client cannot see those NFS directories because I haven't exported them to the client, but that shouldn't matter as the Puppet server has complete root access to the files/directories.

Thanks!

[Trevor Vaughan]

The Puppet *server* should be running as 'puppet' or 'pe-puppet', not 'root'.

Can you double check that this isn't the root of your issue?

Trevor

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/17558bfa-0ead-4f28-b836-c846f289fdd8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[PK]

Yes, the puppet server was running as user "puppet", but that hint helped me recollect an old issue we had, which eventually helped me resolve this symlink to NFS share issue.

A few months ago, we started using extended groups option on our NetApp (cluster mode). With this option enabled, local users could no longer access NFS volumes on the Netapp. I had completely forgotten about this since we had moved all our local users to LDAP. For our current production puppet server (3.7.5) I did have the puppet user in LDAP, but for the new Puppet 4 server that I setup, I created a local puppet user with a different UID/GID. Since the local user took preference over LDAP, it could not access the NFS directory as user 'puppet'. Changing the local puppet user's UID/GID back to match the LDAP uid/gid fixed the issue.

Thanks a lot for the help!

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/17558bfa-0ead-4f28-b836-c846f289fdd8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.