On Tuesday, March 19, 2013, Thomas Bendler wrote:
> Hi @all,
>
> I've started to extend some classes I wrote with support for Windows.
> Unfortunately I got stucked with the ACLs. The plan is (as I thougth) quite
> simple, I would like to create a central directory (i.e. c:\managed) and I
> would like to put some additional files and directories underneath this
> directory (i.e. a repository, a project directory and some programs). The
> idea is to have everything related to Puppet in one place. So far, so good,
> creating the resources is not a big deal but when it comes to ACLs it
> become complicated (at least for me). I've wrote a param class with
> something like this inside:
>
> # Operating system definitions
> case $::osfamily {
> redhat: {
> $osUser = 'root'
> $osGroup = 'root'
> $osFilePermissions = '0644'
> $osDirectoryPermissions = '0755'
> }
> windows: {
> $osUser = 'Administrator'
> $osGroup = 'Administrators'
> $osFilePermissions = '0660'
> $osDirectoryPermissions = '0770'
> }
> }
>
> In the common class I have for Windows something like this:
>
> # Create central manged directory
> file {
> "c:\managed":
> ensure => directory,
> mode => "${common::params::osDirectoryPermissions}",
> owner => "${common::params::osUser}",
> group => "${common::params::osGroup}";
> }
>
> Now I ran into the first problem, we have english Windows systems as well
> as german Windows systems where the administrator group is Administrators
> (english) and Administratoren (german). So on german systems, the group is
> invalid and all depending stuff is not working because the central
> directory isn't available.
>
Specify the owner and/or group as a SID, e.g. S-1-5-32-544. See also
http://support.microsoft.com/kb/243330
If this isn't documented on the file type reference, please file a ticket,
as it should be.
> Sometimes it's even worst, the directory is created but only the local
> Administrator can access the directory, neither local system nor anyone
> else.
>
If LocalSystem (S-1-5-18) is not explicitly specified as the owner or
group, then that account will not have permission to access the resource.
For example, owner => Administrator, group => Administrators, although
seemingly reasonable, can lead to the behavior you describe. Instead, you
are better off doing something like owner => LocalSystem, group =>
Administrators (using the appropriate SIDs).
Really puppet should always ensure LocalSystem has Full Control, which it
effectively does (since it can always take ownership). But thats a two step
operation, unlike POSIX where root can always access. There is a ticket
filed on this already (to ensure puppet never removes LocalSystem access)
I was thinking about two approaches to solve the problem, first, create
> something base on exec with mkdir if directory does not exist and a script
> setting the correct ACLs (with inheritance) or second, create a local
> puppet group and assign the correct groups to it (what could result in
> manual actions because of the language settings). Any ideas how to deal
> with that situation or even better, does someone have already working
> solutions dealing with that kind of problem?
>
HTH,
Josh
--
Josh Cooper
Developer, Puppet Labs
--
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
