Jira (PUP-10108) 'everyday' schedule does not run every day
Title: Message Title
Per Cederqvist created an issue
Puppet / PUP-10108
'everyday' schedule does not run every day
Issue Type:
Bug
Affects Versions:
PUP 6.10.1
Assignee:
Unassigned
Created:
2019/10/23 2:07 AM
Priority:
Normal
Reporter:
Per Cederqvist
Puppet Version: 6.10.1 Puppet Server Version: 6.10.1 OS Name/Version: Debian 8 (client) and Debian 9 (server) Following the example on https://puppet.com/docs/puppet/latest/types/schedule.html I have the following code (where I have adjusted the range by adding one hour, to avoid issues when daylight savings time start and end):
schedule { 'everyday':
period => daily,
range => '3 - 5',
}
Jira (PUP-9023) unable to find
Title: Message Title Per Cederqvist commented on PUP-9023 Re: unable to find I can only speak for myself, but I disabled i18n for four reasons: I don't need it. I don't want it, as searching for an error message is much more likely to yield results if the error message is in English than in Swedish. (This is how I found this issue and PUP-9010.) Also, I'm the only one in my team that is a native Swedish speaker. The others speak German, Polish, Spanish and (I think) Mandarin. The only language all of us can understand is English. Translations are often crappy. I don't know how good the Puppet translations are, but given how crappy many other translations are I'd rather stick with the original English. I read about it causing performance issues, so I disabled it while upgrading just to be on the safe side. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit
Jira (PUP-3879) Packages pushed
Title: Message Title Per Cederqvist commented on PUP-3879 Re: Packages pushed ...or maybe the packages were pushed. I have a few nodes that automatically installed puppet 3.7.4 during the night, but some other nodes cannot do it now: # apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: puppet puppet-common 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 1 669 kB of archives. After this operation, 22,5 kB of additional disk space will be used. Do you want to continue [Y/n]?
Jira (PUP-3879) Packages pushed
Title: Message Title Per Cederqvist commented on PUP-3879 Re: Packages pushed As can be seen on PUP-3867, the Debian wheezy packages were apparently not pushed. Add Comment This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-3477) Improved Cipher settings only used by fresh installations
Title: Message Title Per Cederqvist commented on an issue Re: Improved Cipher settings only used by fresh installations Here is my proposal for how to fix this. Always install the file, even if it has been modified. Add a comment similar to this to the start of the file: This file will be overwritten on each upgrade. If you need to make modifications, copy this file to some other name and enable that site instead of this site. The postinst script currently enables the puppetmaster site. That is fine, but should only be done on the first install, not on upgrades. The above would make lead to safer default installations in the future, while allowing admins to modify the site definitions in a way that survives upgrades. Naturally, you need to warn in the release notes that the upgrade that includes this change will overwrite the site file. Add Comment Puppet / PUP-3477 Improved Cipher settings only used by fresh installations As a long-time Puppet user, I have a fairly bad /etc/apache2/sites-available/puppetmaster file. It accepts SSLv3, which we all know is a very bad idea (SSLv3 POODLE -- I need not say more, I guess). The /usr/share/puppetmaster-passenger/apache2.site.conf.tmpl file installed on my Puppet master seems to be a lot more secure. They way that these files...
Jira (PUP-3477) Improved Cipher settings only used by fresh installations
Title: Message Title Per Cederqvist created an issue Puppet / PUP-3477 Improved Cipher settings only used by fresh installations Issue Type: Bug Affects Versions: PUP 3.7.1 Assignee: Unassigned Created: 16/Oct/14 2:35 AM Priority: Normal Reporter: Per Cederqvist As a long-time Puppet user, I have a fairly bad /etc/apache2/sites-available/puppetmaster file. It accepts SSLv3, which we all know is a very bad idea (SSLv3 POODLE – I need not say more, I guess). The /usr/share/puppetmaster-passenger/apache2.site.conf.tmpl file installed on my Puppet master seems to be a lot more secure. They way that these files are handled on Debian makes it needlessly hard to get the improvements into production, though. I think it would be better if /etc/apache2/sites-available/puppetmaster were re-created from apache2.site.conf.tmpl each time Puppet was upgraded. That way my installation would be kept secure when you fix new issues in the future. I understand that you may not want to make such changes because the user may have edited the file in sites-available. But at least as long as it hasn't been touched by the user, it should be upgraded. Failing that, it would be nicer if the installation created a file (say /usr/share/puppetmaster-passenger/apache2.site.conf) with all the edits that the postinst script does, so that it is easier for an admin to just copy that file to sites-available if he wants to get the new cipher settings. The release notes for Puppet 3.7.0 should also have explained what an
Jira (PUP-3190) each no longer supported in Puppet 3.7.0
Title: Message Title
Per Cederqvist commented on an issue
Re: each no longer supported in Puppet 3.7.0
I applied the proposed patch on top of my installed Debian package, and now Puppet seems to work again! A big thank you!
In case anybody else has this issue, here is what I did on a Debian system:
cd
wget https://github.com/zaphod42/puppet/commit/0447ea0271966703c246e945a5d9e1d6c6d7e5b0.patch
cd /usr/lib/ruby/vendor_ruby
patch -p2 ~/0447ea0271966703c246e945a5d9e1d6c6d7e5b0.patch
The changes to the three files in lib/puppet/pops/loader applied cleanly. The changes in spec/unit could not find any file to patch, presumably because the unit tests are not included in the Debian package; I just skipped those files.
After restarting apache2 (I'm running the puppetmaster under Passenger) everything started working.
Add Comment
Puppet / PUP-3190
each no longer supported in Puppet 3.7.0
After upgrading to Puppet 3.7.0, the puppetmaster no longer recognizes the each keyword. It prints this in the log: {noformat} Sep 5 19:22:56 minicfg2 puppet-master[11897]: each() is only available when parser/evaluator future is in effect on node buildhost1.lysator.liu.se {noformat} The /etc/puppet/puppet.conf on the puppetmaster host looks ...
Jira (PUP-3194) String concatenation no longer works with future parser
Title: Message Title
Per Cederqvist commented on an issue
Re: String concatenation no longer works with future parser
Unless I'm mistaken, this should only work in a new scope. You cannot change the value of a variable in Puppet, only create new variables.
Note that the example you refer to uses an inner class to create the new variable. An if statement does not create a new scope, unless I'm mistaken.
I do think the error message is a bit confusing, though.
Add Comment
Puppet / PUP-3194
String concatenation no longer works with future parser
The follow code does not work: {code} $prefix = else $some_path = /path/to/something if $prefix != undef { $some_path += _${prefix} } {code} It returns with the error: Evaluation Error: The value '/path/to/something' cannot be converted to Numeric. Following the documentation at https://docs.puppetlabs.com/puppet/latest/reference/lan...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group
Jira (PUP-3190) each no longer supported in Puppet 3.7.0
Title: Message Title
Per Cederqvist commented on an issue
Re: each no longer supported in Puppet 3.7.0
Is there any workaround or fix I can apply to get my environment up-and-running again?
Add Comment
Puppet / PUP-3190
each no longer supported in Puppet 3.7.0
After upgrading to Puppet 3.7.0, the puppetmaster no longer recognizes the each keyword. It prints this in the log: {noformat} Sep 5 19:22:56 minicfg2 puppet-master[11897]: each() is only available when parser/evaluator future is in effect on node buildhost1.lysator.liu.se {noformat} The /etc/puppet/puppet.conf on the puppetmaster host looks ...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-3190) each no longer supported in Puppet 3.7.0
Title: Message Title Per Cederqvist created an issue Puppet / PUP-3190 each no longer supported in Puppet 3.7.0 Issue Type: Bug Affects Versions: 3.7.0 Assignee: Unassigned Created: 05/Sep/14 12:32 PM Environment: Debian 7.6 and Ubuntu 12.04. Labels: future-parser Priority: Normal Reporter: Per Cederqvist After upgrading to Puppet 3.7.0, the puppetmaster no longer recognizes the each keyword. It prints this in the log: Sep 5 19:22:56 minicfg2 puppet-master[11897]: each() is only available when parser/evaluator future is in effect on node buildhost1.lysator.liu.se The /etc/puppet/puppet.conf on the puppetmaster host looks like this: [main] logdir = /var/log/puppet vardir =
Jira (PUP-2482) Add support for Debian multiarch package installation
Title: Message Title
Per Cederqvist created an issue
Puppet / PUP-2482
Add support for Debian multiarch package installation
Issue Type:
New Feature
Affects Versions:
3.5.1
Assignee:
Kylo Ginsberg
Components:
Types and Providers
Created:
06/May/14 5:26 AM
Priority:
Normal
Reporter:
Per Cederqvist
With Debian 7 (Debian wheezy), Debian introduced multiarch. If you are running on a 64-bit system, you can install 32-bit libraries as well. Using Puppet, you could install the 32-bit version of zlib1g with Puppet code like this:
if $::lsbdistcodename == 'wheezy' {
exec { '/usr/bin/dpkg --add-architecture i386':
unless = '/bin/grep -q i386 /var/lib/dpkg/arch',
}
package { 'zlib1g:i386':
ensure = installed,
}
}
This works, but it would be nice to have native support for multiarch in Puppet. (The code has at least two problems: it does not ensure that the architecture is added before it attempts to install the package, and you must run apt-get update between adding the arch and installing the package.)
I don't know exactly what I want, but maybe something like this:
Jira (PUP-2160) Undocumented hash lookup change in Puppet 3.5.0
Title: Message Title Per Cederqvist updated an issue Puppet / PUP-2160 Undocumented hash lookup change in Puppet 3.5.0 I attach a better testcase that more closely matches my real issue. My code initially tested for an empty string or default, and puppet changed behavior in version 3.5.0 with the future parser. As far as I am concerned, the only thing you have to do to close this ticket is to document on http://docs.puppetlabs.com/puppet/latest/reference/lang_datatypes.html#hashes that indexing a has with a key that isn't present gives you the special value undef. (This talk of nil here and in PUP-480 confuses me. Will the Puppet language have a nil value as well as an undef value? Or are you just talking about the nil value used in the internal Ruby code? The attached code sample also tests for nil, but that code path is never triggered.) This is what I see when I run the attached code. If I had tested for undef instead of the empty string I would not have had a problem. $ puppet --version 3.4.3 $ puppet apply --parser future hash.pp Notice: Scope(Class[main]): Blank or default: blank Notice: Scope(Class[main]): undef or default: undef Notice: Scope(Class[main]): false or default: default Notice: Scope(Class[main]): blank, undef, false or default: blank Notice: Scope(Class[main]): nil or default: default $ puppet apply hash.pp Notice: Scope(Class[main]): Blank or default: blank Notice: Scope(Class[main]): undef or default: undef Notice: Scope(Class[main]): false or default: default Notice: Scope(Class[main]): blank, undef, false or default: blank Notice: Scope(Class[main]): nil or default: default $ puppet --version 3.5.0 $ puppet apply --parser future hash.pp Notice: Scope(Class[main]): Blank or default: default Notice: Scope(Class[main]): undef or default: undef Notice: Scope(Class[main]): false or default: default Notice: Scope(Class[main]): blank, undef, false or default: undef Notice: Scope(Class[main]): nil or default: default $ puppet apply hash.pp Notice: Scope(Class[main]): Blank or default: blank Notice: Scope(Class[main]): undef or default: undef Notice: Scope(Class[main]): false or default: default Notice: Scope(Class[main]): blank, undef, false or default: blank Notice: Scope(Class[main]): nil or default: default Change By: Per Cederqvist Attachment: hash.pp
Jira (PUP-2160) Undocumented hash lookup change in Puppet 3.5.0
Title: Message Title
Per Cederqvist commented on an issue
Re: Undocumented hash lookup change in Puppet 3.5.0
Thank you for your explanation. I think I understand more now, and it certainly makes sense not to document things that might change.
But.
I propose that a sentence similar to this is added to http://docs.puppetlabs.com/puppet/latest/reference/lang_datatypes.html#indexing-1:
If you index a hash with a key that isn't present in the hash, the special value undef is returned.
This addition should be uncontroversial, as it documents the current behaviour in Puppet 3.5.0, and if I understand you correctly there are no plans to change this particular behaviour.
If I had written my code so that it checked for undef instead of checking for the empty string, it would have worked in both Puppet 3.4.3 and 3.5.0, with both the future and the current parser.
Add Comment
Puppet / PUP-2160
Undocumented hash lookup change in Puppet 3.5.0
Consider this code: {noformat} $h = { k1 = value } $v = $h[k2] {noformat} Puppet 3.5.0 sets $v to undef. Earlier versions set $v to the empty string, I believe. (Possibly that isn't true. Possibly it is instead some comparison changes that bites me.) What happens when you look up a non-existing key in a hash should be documented on htt...
Jira (PUP-2183) Octal and hexadecimal numbers are not documented
Title: Message Title Per Cederqvist created an issue Puppet / PUP-2183 Octal and hexadecimal numbers are not documented Issue Type: Improvement Assignee: Unassigned Created: 08/Apr/14 1:31 PM Priority: Trivial Reporter: Per Cederqvist http://docs.puppetlabs.com/puppet/latest/reference/lang_datatypes.html#numbers does not say that numbers can be octal or hexadecimal. http://docs.puppetlabs.com/puppet/latest/reference/lang_expressions.html#backus-naur-form mentions that a literal can be an hex-integer or octal-integer, but does not specify how you write them. Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
Jira (PUP-2156) file provider silent behaviour change for mode
Title: Message Title
Per Cederqvist commented on an issue
Re: file provider silent behaviour change for mode
One thought here that Andy Parker brought up is the distinction between the mode (octal) 777, and the mode 0777, since the first does not change the higher order bits, but the second does.
I cannot reproduce the above claim:
$ puppet apply -e 'file { /tmp/x: ensure = file, mode = 1777 }'; ls -l /tmp/x
[...]
Notice: /Stage[main]/Main/File[/tmp/x]/ensure: created
[...]
-rwxrwxrwt 1 ceder ceder 0 2014-04-08 22:14 /tmp/x
$ puppet apply -e 'file { /tmp/x: ensure = file, mode = 777 }'; ls -l /tmp/x
[...]
Notice: /Stage[main]/Main/File[/tmp/x]/mode: mode changed '1777' to '0777'
[...]
-rwxrwxrwx 1 ceder ceder 0 2014-04-08 22:14 /tmp/x
As I expected, mode 777 will change the high-order bits. I've tested the above example with both Puppet 3.4.3 and 3.5.0, with both --parser future and the traditional parser, and all four combinations produce the same result.
Requiring the mode argument to be a string in Puppet 4 seems like a very good idea to me. It should probably be an error if a numeric string is anything but 4 or 5 characters long. It isn't obvious to me if 01777 should be written 1777 or 01777; I think it might make sense to accept both forms.
Add Comment
Puppet / PUP-2156
file provider silent behaviour change for mode
The type reference for file in Puppet 0.25.5 said: {noformat} file { '/some/dir': mode = 644, recurse = true, } {noformat} Ref: http://docs.puppetlabs.com/references/0.25.5/type.html#file I believe that there are
Jira (PUP-2156) file provider silent behaviour change for mode
Title: Message Title Per Cederqvist commented on an issue Re: file provider silent behaviour change for mode I can't seem to let go about this issue. Sorry if I keep nagging, but I got a new idea over the weekend. There should be a deprecation warning if a non-string mode variable is used. This should be added well in advance of Puppet 4. Here is a list of test cases and whether I think the should produce a deprecation warning when using the default parser: format deprecated? 777 yes 0777 probably '777' or 777 probably '0777' or 0777 no 4711 yes 04711 probably
Jira (PUP-2160) Undocumented hash lookup change in Puppet 3.5.0
Title: Message Title
Per Cederqvist commented on an issue
Re: Undocumented hash lookup change in Puppet 3.5.0
Yes, I was using the future parser. (And that implies the future evaluator, in 3.5.0, does it not?)
The change is arguably a good one. I just wish the documentation would be improved so that it states what happens (and that, if you are using the default parser, the semanitcs will change in Puppet 4.)
Add Comment
Puppet / PUP-2160
Undocumented hash lookup change in Puppet 3.5.0
Consider this code: {noformat} $h = { k1 = value } $v = $h[k2] {noformat} Puppet 3.5.0 sets $v to undef. Earlier versions set $v to the empty string, I believe. (Possibly that isn't true. Possibly it is instead some comparison changes that bites me.) What happens when you look up a non-existing key in a hash should be documented on htt...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post
Jira (PUP-2156) file provider silent behaviour change for mode
Title: Message Title
Per Cederqvist created an issue
Puppet / PUP-2156
file provider silent behaviour change for mode
Issue Type:
Bug
Affects Versions:
3.5.0
Assignee:
Kylo Ginsberg
Components:
Types and Providers
Created:
04/Apr/14 5:51 AM
Priority:
Major
Reporter:
Per Cederqvist
The type reference for file in Puppet 0.25.5 said:
file { '/some/dir':
mode = 644,
recurse = true,
}
Ref: http://docs.puppetlabs.com/references/0.25.5/type.html#file
I believe that there are many Puppet manifests out there that still writes file mode as 3-digit numbers and expect them to be interpreted as octal.
Starting with Puppet 3.5.0, this would set the mode to 1204 instead of the intended 0644. The mode 755 becomes 1363 – which means that the file is world writable.
I know that for a long time the documentation says that the mode should be specified as a four-digit octal value. But it doesn't say that it has to be a string. Specifying 4711 used to make a file setuid; starting in Puppet 3.5.0 is produces the nonsensical error message The file mode specification is invalid:
Jira (PUP-2158) Directory Environments breaks many classic Config File Environments
Title: Message Title Per Cederqvist created an issue Puppet / PUP-2158 Directory Environments breaks many classic Config File Environments Issue Type: Bug Affects Versions: 3.5.0 Assignee: Unassigned Created: 04/Apr/14 6:02 AM Priority: Normal Reporter: Per Cederqvist If you use the script in the classic blog post http://puppetlabs.com/blog/git-workflow-and-puppet-environments you have Config File Environments located at /etc/puppet/environments. Unfortunately, Puppet 3.5.0 will treat them as Directory Environments. If you have a modulepath such as this: modulepath=/etc/puppet/environments/$environment/modules:/etc/puppet/environmentss/$environment/services:/etc/puppet/environments/$environment/forge it will not be used. You have to move your environments someplace else. It is a pity that Puppet 3.5.0 reused the proposed location from that blog post. The transition would have been less painful if another location had been used. Failing that, it would have been less painful if the resolution order had been Config File Enviroment - DIrectory Environment - global environment. At the very least, this should be mentioned in the release note and on http://docs.puppetlabs.com/puppet/3.5/reference/environments.html. It was a bit hard to find the resultion order deep down in
Jira (PUP-2159) import is silently ignored using the future parser
Title: Message Title Per Cederqvist created an issue Puppet / PUP-2159 import is silently ignored using the future parser Issue Type: Bug Affects Versions: 3.5.0 Assignee: Unassigned Created: 04/Apr/14 6:09 AM Priority: Normal Reporter: Per Cederqvist The import statement, when used like below, is silently ignored if you are using the future parser. import nodes PUP-490 says: i.e. future parser/evaluator will not issue deprecation, and will instead interpret import as if it is a function call (leading to unknown function error since there is no such function). But that error message is only produced if you add parenthesis: import(nodes) The original form is silently ignored, with no diagnostics. (Combined with PUP-2158 this made it a bit hard to track down why nothing happened when I had changed stuff in my manifests.) The
Jira (PUP-2160) Undocumented hash lookup change in Puppet 3.5.0
Title: Message Title
Per Cederqvist created an issue
Puppet / PUP-2160
Undocumented hash lookup change in Puppet 3.5.0
Issue Type:
Bug
Affects Versions:
3.5.0
Assignee:
Unassigned
Created:
04/Apr/14 6:20 AM
Priority:
Normal
Reporter:
Per Cederqvist
Consider this code:
$h = { k1 = value }
$v = $h[k2]
Puppet 3.5.0 sets $v to undef. Earlier versions set $v to the empty string, I believe. (Possibly that isn't true. Possibly it is instead some comparison changes that bites me.)
What happens when you look up a non-existing key in a hash should be documented on http://docs.puppetlabs.com/puppet/latest/reference/lang_datatypes.html#hashes.
If I'm correct, and this was a change in behavior in Puppet 3.5.0, it should be mentioned in the release note.
Add Comment
Jira (PUP-2156) file provider silent behaviour change for mode
Title: Message Title
Per Cederqvist commented on an issue
Re: file provider silent behaviour change for mode
Yes, I can confirm that this was with the future parser.
Add Comment
Puppet / PUP-2156
file provider silent behaviour change for mode
The type reference for file in Puppet 0.25.5 said: {noformat} file { '/some/dir': mode = 644, recurse = true, } {noformat} Ref: http://docs.puppetlabs.com/references/0.25.5/type.html#file I believe that there are many Puppet manifests out there that still writes file mode as 3-digit numbers and expect them to be interpreted as octal. ...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-2156) file provider silent behaviour change for mode
Title: Message Title Per Cederqvist commented on an issue Re: file provider silent behaviour change for mode Isn't that a bit premature, though? 1. The reference documentation for the mode attribute of the file type on http://docs.puppetlabs.com/references/latest/type.html#file-attribute-mode should clearly state that numeric arguments should be supplied as strings. Suggested wording (insert this as a new paragraph immediately before the Symbolic modes paragraph): Numeric modes should be specified as a qouted string of four digits. When supplied in this form, they will always be interpreted as octal digits. So to set a file as set-uid, with read-write-execute permissions for the owner and only execute permission for group and other, supply mode = '4711'. While it traditionally has worked to use an unquoed string, such as 664, future versions of Puppet will interpret that word as a decimal number and actually set the permission to 1230. This already happens if you use the future parser in Puppet 3.5.0. Or maybe you should supply a five-digit string '04711' in that case? If so, a lot of places in the documentation need updating... 2. The style guide on http://docs.puppetlabs.com/guides/style_guide.html#file-modes should either explicitly state that the mode should be four-digit even if the first digit is non-zero, or say that it should be a four-or-five-digit string with a leading zero. 3. The release note for 3.5.0 should warn about this change. Suggested wording, to be inserted before the It also has some new tricks paragraph under the Future Parser is Faster and Better heading: There is one important semantic change in this release. If you specify a numeric file mode, and don't quote it, and the mode does not have a leading zero, the future parser will treat it as a decimal number, and the end result will probably not be what you wanted. As the a href="" /> guide/a has been saying for a long time, you should always set the file mode as a string containing four digits, such as mode = 0664. 4. http://docs.puppetlabs.com/puppet/latest/reference/experiments_future.html#numbers-are-validated-if-entered-without-quotes should maybe mention this side-effect. Or otherwise, the warning at the top of that page should be even stronger and state that you might get unexpected results unless you strictly follow the style guide. Add Comment
Jira (PUP-2156) file provider silent behaviour change for mode
Title: Message Title
Per Cederqvist commented on an issue
Re: file provider silent behaviour change for mode
More documentation issues:
5. http://docs.puppetlabs.com/puppet/latest/reference/lang_visual_index.html shows a non-string mode in the ntp.conf example. (It does have a leading 0, though).
6. I cannot find a definition of what a numeric literal can consist of in the Puppet 3.5 Reference Manual! http://docs.puppetlabs.com/puppet/latest/reference/lang_expressions.html#backus-naur-form says it can be an integer, octal-integer, et c, but I cannot find the definition of octal-integer. Similarly, I cannot find a definition of how a string constant is written. Am I missing a chapter?
Add Comment
Puppet / PUP-2156
file provider silent behaviour change for mode
The type reference for file in Puppet 0.25.5 said: {noformat} file { '/some/dir': mode = 644, recurse = true, } {noformat} Ref: http://docs.puppetlabs.com/references/0.25.5/type.html#file I believe that there are many Puppet manifests out there that still writes file mode as 3-digit numbers and expect them to be interpreted as octal. ...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
