[Puppet Users] Re: SMBFS Share in Finder Sidebar?
I tried *many* different invocations of the mount module from w/i my
manifest to no avail.
However, I got it working by writing an Applescript one-liner:
tell application "Finder" to open location "smb://[USER]:[PASSWORD]@[SMB
HOST]/[SMB SHARE]"
The Mac node downloads this script, executes it, et voila(!) an SMBFS share
that you can find in the Finder Sidebar. These are my manifest mods:
file { '/usr/local/sbin/mac_mount_[SHARENAME].scpt': ensure => file, source
=> 'puppet:///modules/mac/mac_mount_[SHARENAME].scpt', owner => 'root',
group => 'wheel', mode => '0755', } exec {'Mount smbfs share': command =>
'/usr/bin/osascript /usr/local/sbin/mac_mount_[SHARENAME].scpt', }
Hope that helps someone in need.
Cheers,
Marshall
On Monday, November 27, 2017 at 1:31:22 PM UTC-8, mta...@lygos.com wrote:
>
> Hi,
>
> I have created an SMB share that I can manually mount through Finder -> Go
> -> Connect to Server.
> It shows up under /Volumes in the Finder Sidebar correctly. The OS
> usefully sets the mount point owned by
> me and under the group 'staff' with mount point permissions 0755.
>
> Using the mount module I can mount this same share, but I am unable to
> mount it under /Volumes, or get
> it to be in group 'staff' instead of 'wheel', or to show up in the Finder
> Sidebar. Here is my mount invocation:
>
>file { '/Users/Shared/mnt':
> ensure => 'directory',
>}
>mount {'/Users/Shared/mnt':
>name => '/Users/Shared/mnt',
>device => '//[USER]:[PASSWORD]@[SMB HOST]/[SMB SHARE]',
>atboot => 'true',
>options => '-d=755',
>ensure => 'mounted',
>fstype => 'smbfs',
>require => File['/Users/Shared/mnt'],
>notify => Exec['fix_mount_perms'],
>}
>exec { 'fix_mount_perms':
>command => '/bin/chmod 0755 /Users/Shared/mnt &&
> /usr/bin/chgrp staff /Users/Shared/mnt',
>refreshonly => true
>}
>
> I'd love to know the correct mount methodology that simulates what my Mac
> (10.13.1) is doing natively.
>
> Thanks!
>
> Marshall
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/b1170955-af65-4874-935e-91f456852cdd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] hiera can't find facts to read hierarchy files?
Hi,
I'm quite confused about how I could have created this problem. I have a
module we'll call it "test" which has been using Hiera v5 module data for
the last couple of releases...this works great on either puppet 4 or 5...as
expected.
Last week added a feature, which involved adding 1 new manifest file (which
creates concat::fragment resources), 2 parameters to a hiera data file, and
adding 2 concat file resources, each named by one of those parameters, to
an existing manifest file (existing.pp below). Fairly simple and straight
forward change. The parser passes the syntax checks for everything
involved in the change.
I have tested on both puppet 4 and 5 using a pair of centos7 vms, both
produce the same result.
# puppet apply -e "include test"
Warning: Unknown variable: 'test::dconf_default_config'. at
/etc/puppetlabs/code/environments/production/modules/test/manifests/existing.pp:186:12
Error: Evaluation Error: Missing title. The title expression resulted in
undef at
/etc/puppetlabs/code/environments/production/modules/test/manifests/existing.pp:186:12
on node localhost.localdomain
This parameter is the filename of the concat resource mentioned above.
Running a puppet lookup (on either v4 or v5) produces this output for the
module data section:
Module "test" Data Provider (hiera configuration version 5)
Using configuration
"/etc/puppetlabs/code/environments/production/modules/test/hiera.yaml"
Hierarchy entry "Full Version"
Path
"/etc/puppetlabs/code/environments/production/modules/test/data/-.yaml"
Original path: "%{facts.os.name}-%{facts.os.release.full}.yaml"
Path not found
Hierarchy entry "Major Version"
Path
"/etc/puppetlabs/code/environments/production/modules/test/data/-.yaml"
Original path: "%{facts.os.name}-%{facts.os.release.major}.yaml"
Path not found
Hierarchy entry "Distribution Name"
Path
"/etc/puppetlabs/code/environments/production/modules/test/data/.yaml"
Original path: "%{facts.os.name}.yaml"
Path not found
Hierarchy entry "Operating System Family + Major Version"
Path
"/etc/puppetlabs/code/environments/production/modules/test/data/-.yaml"
Original path: "%{facts.os.family}-%{facts.os.release.major}.yaml"
Path not found
Hierarchy entry "Operating System Family"
Path
"/etc/puppetlabs/code/environments/production/modules/test/data/.yaml"
Original path: "%{facts.os.family}.yaml"
Path not found
Hierarchy entry "common"
Path
"/etc/puppetlabs/code/environments/production/modules/test/data/common.yaml"
Original path: "common.yaml"
No such key: "test::dconf_default_config"
See how all the Hierarchy Paths have bad file names? This leads me to
think that somehow Hiera has lost the ability to parse facts in my feature
branch of this module. If I check the master branch out for the "test"
module then Hiera produces the correct datafile names.
How can that be?
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/dc488b41-8df1-403c-a932-2a956e38112f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
