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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
