I''m using puppet 0.25.5 and just discovered two file resource bugs. I
suspect the bugs did not exist in 0.24 because the code were using that
triggers them has been the same for a long time and while it is possible we
did not notice the problem earlier, it seems unlikely as it has been
triggering failures in our automated system tests since around the time we
upgraded.
Anyway, here''s the bug. In our site.pp, we have
File {
mode => 400,
}
These two resources
file { "/mnt/www":
ensure => directory,
mode => 755,
}
file { "/var/www":
require => File["/mnt/www"],
ensure => "/mnt/www",
}
result in /mnt/www being created as mode 400. My guess is that /mnt/www is
being created with mode 755 as requested, then /var/www is being created as
a symlink to /mnt/www and then (because 400 is the default mode for all file
resources) it is being chmod''ed to mode 400, which chmod''s the
referenced
directory. Since the file resource is creating a symlink the correct
behavior would be to call lchmod()... except Linux has no lchmod(), all
symlinks in Linux are effectively mode 777. So puppet should in fact not
call chmod() on symlinks at all on Linux. Two other things I''ve
observed:
* Putting mode => 755 into the second file resource fixes the problem; this
must make puppet call chmod(755) on the symlink, which "changes" the
directory to its current value.
* /mnt/www''s mode is fixed on the second puppet run; the
File["/mnt/www"]
notices the mode is wrong and fixes it, and I guess the
File["/var/www"]
symlink resource does not try to change the mode on symlinks.
In a somewhat related issue, we also have this code:
file { "/usr/src/php":
ensure => directory,
}
This results in /usr/src/php being created as mode 400. One could argue this
is not a bug since 400 is the default mode. However on its second run puppet
changes the mode on this dir to 500. So either the initial mode or the later
change is clearly a bug. :-)
I haven''t tried to track down these behaviors in puppet''s
source and do not
know if they are fixed in 0.26.
Thanks,
Barry
--
Barry Jaspan
Senior Architect | Acquia <http://acquia.com>
barry.jaspan@acquia.com | (c) 617.905.2208 | (w) 978.296.5231
"Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
> file { "/usr/src/php": > ensure => directory, > } > > This results in /usr/src/php being created as mode 400. One could argue > this is not a bug since 400 is the default mode. However on its second > run puppet changes the mode on this dir to 500. So either the initial > mode or the later change is clearly a bug. :-)This is a feature. Puppet assumes +x when a directory gets +r. This is helpful for setting modes recursively for both dirs and files. The other thing looks fishy, though. I noticed the effect in conjuction with bind-mounts (i.e. setting mode on a mount point), but accepted it as a fact in that case. Changing modes of symlink targets at the time of symlink creation may be somehow intended, but it sure is counter-intuitive. I call possible bug. Regards, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Feb 2, 2011 at 3:21 AM, Felix Frank <felix.frank@alumni.tu-berlin.de> wrote:> > file { "/usr/src/php": > > ensure => directory, > > } > > > > This results in /usr/src/php being created as mode 400. One could argue > > this is not a bug since 400 is the default mode. However on its second > > run puppet changes the mode on this dir to 500. So either the initial > > mode or the later change is clearly a bug. :-) > > This is a feature. Puppet assumes +x when a directory gets +r. This is > helpful for setting modes recursively for both dirs and files. >Then shouldn''t it do that when it creates it, instead of requiring two runs to get to the end state?> The other thing looks fishy, though. I noticed the effect in conjuction > with bind-mounts (i.e. setting mode on a mount point), but accepted it > as a fact in that case. Changing modes of symlink targets at the time of > symlink creation may be somehow intended, but it sure is > counter-intuitive. I call possible bug. > > Regards, > Felix > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Did you ever files these bugs in the tracker? On Feb 1, 2011, at 7:35 PM, Barry Jaspan wrote:> I''m using puppet 0.25.5 and just discovered two file resource bugs. I suspect the bugs did not exist in 0.24 because the code were using that triggers them has been the same for a long time and while it is possible we did not notice the problem earlier, it seems unlikely as it has been triggering failures in our automated system tests since around the time we upgraded. > > Anyway, here''s the bug. In our site.pp, we have > > File { > mode => 400, > } > > These two resources > > file { "/mnt/www": > ensure => directory, > mode => 755, > } > file { "/var/www": > require => File["/mnt/www"], > ensure => "/mnt/www", > } > > result in /mnt/www being created as mode 400. My guess is that /mnt/www is being created with mode 755 as requested, then /var/www is being created as a symlink to /mnt/www and then (because 400 is the default mode for all file resources) it is being chmod''ed to mode 400, which chmod''s the referenced directory. Since the file resource is creating a symlink the correct behavior would be to call lchmod()... except Linux has no lchmod(), all symlinks in Linux are effectively mode 777. So puppet should in fact not call chmod() on symlinks at all on Linux. Two other things I''ve observed: > > * Putting mode => 755 into the second file resource fixes the problem; this must make puppet call chmod(755) on the symlink, which "changes" the directory to its current value. > * /mnt/www''s mode is fixed on the second puppet run; the File["/mnt/www"] notices the mode is wrong and fixes it, and I guess the File["/var/www"] symlink resource does not try to change the mode on symlinks. > > In a somewhat related issue, we also have this code: > > file { "/usr/src/php": > ensure => directory, > } > > This results in /usr/src/php being created as mode 400. One could argue this is not a bug since 400 is the default mode. However on its second run puppet changes the mode on this dir to 500. So either the initial mode or the later change is clearly a bug. :-) > > I haven''t tried to track down these behaviors in puppet''s source and do not know if they are fixed in 0.26. > > Thanks, > > Barry > > -- > Barry Jaspan > Senior Architect | Acquia > barry.jaspan@acquia.com | (c) 617.905.2208 | (w) 978.296.5231 > > "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com" > > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.