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. Sometimes it''s even worst, the
directory is
created but only the local Administrator can access the directory, neither
local system nor anyone else.
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?
Regards Thomas
--
Linux ... enjoy the ride!
--
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 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.
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+unsubscribe@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.
Hi Josh, 2013/3/20 Josh Cooper <josh@puppetlabs.com>> S-1-5-18thanks for the clarification, I wasn''t aware that the SIDs are always the same as stated in http://support.microsoft.com/kb/243330. What''s about everyone or user, will everyone or user get read-only access when I change the mode to 0775? Multiple groups can''t be specified inside the file type, can they? The reference documentation ( http://docs.puppetlabs.com/references/3.1.latest/type.html#file) isn''t really clear about this topics ... at least from my point of view ;). Regards Thomas -- Linux ... enjoy the ride! -- 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 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.
Hi Thomas, On Wed, Mar 20, 2013 at 3:31 AM, Thomas Bendler <thomas.bendler@gmail.com>wrote:> Hi Josh, > > 2013/3/20 Josh Cooper <josh@puppetlabs.com> > >> S-1-5-18 > > > thanks for the clarification, I wasn''t aware that the SIDs are always the > same as stated in http://support.microsoft.com/kb/243330. >Many accounts have fixed SIDs, though some have a unique per-domain component: SID: S-1-5-21-domain-500 Name: Administrator where the domain part is unique. For example, you can display your SID as: C:\>whoami /user What''s about everyone or user, will everyone or user get read-only access> when I change the mode to 0775? >Puppet maps the ''other'' POSIX class to the Everyone SID (''S-1-1-0''). In most recent versions of Windows, this is all accounts except anonymous logon: http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2general/thread/3816efc7-255f-4f01-a71d-f27be627e439/> Multiple groups can''t be specified inside the file type, can they? The > reference documentation ( > http://docs.puppetlabs.com/references/3.1.latest/type.html#file) isn''t > really clear about this topics ... at least from my point of view ;). >Puppet''s file type only supports a single group account, but on Windows that group can contain multiple nested groups and work as expected. There is a ticket filed to support native NTFS ACLs, which would give you fine-grain permissions, such as the ability to list multiple groups, deny/allow, etc. See https://projects.puppetlabs.com/issues/13249 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+unsubscribe@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.