Thinking back to the original PSON bug, the workaround back then was to use
YAML serialization. I did notice that that could make clients crash though,
I think the 0.25.5 were the afflicted ones.
You may want to give it shot though, anyway. The YAML encoder seems to be
less picky where
On 11/19/2010 10:56 AM, Chris May wrote:
Thinking back to the original PSON bug, the workaround back then was
to use YAML serialization. I did notice that that could make clients
crash though, I think the 0.25.5 were the afflicted ones.
You may want to give it shot though,
On Fri, Nov 19, 2010 at 11:01 AM, Felix Frank
felix.fr...@alumni.tu-berlin.de wrote:
On 11/19/2010 10:56 AM, Chris May wrote:
Thinking back to the original PSON bug, the workaround back then was
to use YAML serialization. I did notice that that could make clients
crash
On 11.11.2010 11:06, Chris wrote:
In the general case, even completely legitimate (and common) Latin-1
text files can cause Puppet problems because some Latin-1 bytes are
not valid UTF-8. In my opinion, the content parameter of a file
resource should be able to handle these cases.
I think
In the general case, even completely legitimate (and common) Latin-1
text files can cause Puppet problems because some Latin-1 bytes are
not valid UTF-8. In my opinion, the content parameter of a file
resource should be able to handle these cases.
I think you should file a bug then.
Hi Thomas
On Nov 10, 12:44 pm, Thomas Bendler thomas.bend...@cimt.de wrote:
Hi Chris,
2010/11/10 Chris chrisma...@gmail.com
[...]
file{/path/to/foo.key: source=puppet:///keys/foo.key} , because
any valid puppet client could access foo.key.
[...]
you are not sticked to the puppet
On Nov 10, 2010, at 6:52 AM, Chris wrote:
Hi Thomas
On Nov 10, 12:44 pm, Thomas Bendler thomas.bend...@cimt.de wrote:
Hi Chris,
2010/11/10 Chris chrisma...@gmail.com
[...]
file{/path/to/foo.key: source=puppet:///keys/foo.key} , because
any valid puppet client could access foo.key.
Hi Chris,
2010/11/10 Chris chrisma...@gmail.com
[...]
Yes, except that approach suffers from the same administrative
problems as using puppet:/// and auth.conf. HTTPS certs aren't
specific to hosts. If I have 20 servers all requiring foo.key (because
they all have the foo-application class
got the point, thought that you need one specific key on each server. So
that should be even simpler, use file with content and put the key in the
content field:
$myKey = -BEGIN RSA PRIVATE
KEY-\nMIICXgIBAAKBgQDTqkVS4/iwKx8LngXQrEShlfSRtcSyOB1IjC5AIGUAJvapq9lz\n...
file {
2010/11/10 Richard Crowley r...@rcrowley.org
[...]
This works perfectly for PEM-formatted keys because they're ASCII,
which is a subset of UTF-8. Binary keys are not (usually) valid UTF-8
and thus can't be crammed into a catalog without some encoding.
And why don't you convert the key to a
On Wed, Nov 10, 2010 at 10:39 AM, Thomas Bendler thomas.bend...@cimt.de wrote:
2010/11/10 Richard Crowley r...@rcrowley.org
[...]
This works perfectly for PEM-formatted keys because they're ASCII,
which is a subset of UTF-8. Binary keys are not (usually) valid UTF-8
and thus can't be
On Nov 10, 2010, at 11:48 AM, Richard Crowley wrote:
On Wed, Nov 10, 2010 at 10:39 AM, Thomas Bendler thomas.bend...@cimt.de
wrote:
2010/11/10 Richard Crowley r...@rcrowley.org
[...]
This works perfectly for PEM-formatted keys because they're ASCII,
which is a subset of UTF-8. Binary
On Wed, Nov 10, 2010 at 6:26 PM, Richard Crowley r...@rcrowley.org wrote:
got the point, thought that you need one specific key on each server. So
that should be even simpler, use file with content and put the key in the
content field:
$myKey = -BEGIN RSA PRIVATE
13 matches
Mail list logo
