Newlines not respected in encrypted databags


#1

Hi all -

Seemingly out of the blue, after not specifying the distribution now during
the bootstrap, an encrypted databag who’s contents is placed in a file no
longer has it’s “\n”'s respected.

Is there some change I missed/overlooked?

Again - in the encrypted databag, I have:

“foo \n”,
“bar \n”

and I want that spat into a file with each of those values on a separate
line, but when this runs, I wind up with one huge line.

Any suggestions?


#2

On Wednesday, January 2, 2013 at 2:02 PM, Maven User wrote:

Hi all -

Seemingly out of the blue, after not specifying the distribution now during the bootstrap, an encrypted databag who’s contents is placed in a file no longer has it’s “\n”'s respected.

Is there some change I missed/overlooked?

Again - in the encrypted databag, I have:

“foo \n”,
“bar \n”

and I want that spat into a file with each of those values on a separate line, but when this runs, I wind up with one huge line.

Any suggestions?
Sounds like it’s possibly related to this?
http://tickets.opscode.com/browse/CHEF-3393


Daniel DeLeo


#3

Hmmm- more history…

Previously, we were specifying the distribution we wanted to use
(ubuntu12.04-gems), but the moneta issue broke this for us, so via this
mailing list, we solved this by upgrading my cookbooks and taking out the
distribution flag to the bootstrap command.

If I specify the bootstrapping version, will that also solve this?

Help me figure out what I’ve changed that would all of a sudden be causing
this pain :frowning:

On Wed, Jan 2, 2013 at 5:17 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, January 2, 2013 at 2:02 PM, Maven User wrote:

Hi all -

Seemingly out of the blue, after not specifying the distribution now
during the bootstrap, an encrypted databag who’s contents is placed in a
file no longer has it’s “\n”'s respected.

Is there some change I missed/overlooked?

Again - in the encrypted databag, I have:

“foo \n”,
“bar \n”

and I want that spat into a file with each of those values on a separate
line, but when this runs, I wind up with one huge line.

Any suggestions?

Sounds like it’s possibly related to this?
http://tickets.opscode.com/browse/CHEF-3393


Daniel DeLeo


#4

I tried to specify the version of chef to install in the bootstrap command
(10.16.4) and that didn’t solve the issue either.

Daniel - the bug you mention - do I have to upgrade my client from
10.12.0 to 11.X to get this all working again?

On Wed, Jan 2, 2013 at 5:24 PM, Maven User maven.2.user@gmail.com wrote:

Hmmm- more history…

Previously, we were specifying the distribution we wanted to use
(ubuntu12.04-gems), but the moneta issue broke this for us, so via this
mailing list, we solved this by upgrading my cookbooks and taking out the
distribution flag to the bootstrap command.

If I specify the bootstrapping version, will that also solve this?

Help me figure out what I’ve changed that would all of a sudden be causing
this pain :frowning:

On Wed, Jan 2, 2013 at 5:17 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, January 2, 2013 at 2:02 PM, Maven User wrote:

Hi all -

Seemingly out of the blue, after not specifying the distribution now
during the bootstrap, an encrypted databag who’s contents is placed in a
file no longer has it’s “\n”'s respected.

Is there some change I missed/overlooked?

Again - in the encrypted databag, I have:

“foo \n”,
“bar \n”

and I want that spat into a file with each of those values on a separate
line, but when this runs, I wind up with one huge line.

Any suggestions?

Sounds like it’s possibly related to this?
http://tickets.opscode.com/browse/CHEF-3393


Daniel DeLeo


#5

I’ve also just noticed that the machine running the bootstrap is 10.12.0 -
does this matter when you’re specifying the bootstrap version explicitly?

On Wed, Jan 2, 2013 at 5:38 PM, Maven User maven.2.user@gmail.com wrote:

I tried to specify the version of chef to install in the bootstrap command
(10.16.4) and that didn’t solve the issue either.

Daniel - the bug you mention - do I have to upgrade my client from
10.12.0 to 11.X to get this all working again?

On Wed, Jan 2, 2013 at 5:24 PM, Maven User maven.2.user@gmail.com wrote:

Hmmm- more history…

Previously, we were specifying the distribution we wanted to use
(ubuntu12.04-gems), but the moneta issue broke this for us, so via this
mailing list, we solved this by upgrading my cookbooks and taking out the
distribution flag to the bootstrap command.

If I specify the bootstrapping version, will that also solve this?

Help me figure out what I’ve changed that would all of a sudden be
causing this pain :frowning:

On Wed, Jan 2, 2013 at 5:17 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, January 2, 2013 at 2:02 PM, Maven User wrote:

Hi all -

Seemingly out of the blue, after not specifying the distribution now
during the bootstrap, an encrypted databag who’s contents is placed in a
file no longer has it’s “\n”'s respected.

Is there some change I missed/overlooked?

Again - in the encrypted databag, I have:

“foo \n”,
“bar \n”

and I want that spat into a file with each of those values on a separate
line, but when this runs, I wind up with one huge line.

Any suggestions?

Sounds like it’s possibly related to this?
http://tickets.opscode.com/browse/CHEF-3393


Daniel DeLeo


#6

On Wednesday, January 2, 2013 at 2:38 PM, Maven User wrote:

I tried to specify the version of chef to install in the bootstrap command (10.16.4) and that didn’t solve the issue either.

Daniel - the bug you mention - do I have to upgrade my client from 10.12.0 to 11.X to get this all working again?

On Wed, Jan 2, 2013 at 5:24 PM, Maven User <maven.2.user@gmail.com (mailto:maven.2.user@gmail.com)> wrote:

Hmmm- more history…

Previously, we were specifying the distribution we wanted to use (ubuntu12.04-gems), but the moneta issue broke this for us, so via this mailing list, we solved this by upgrading my cookbooks and taking out the distribution flag to the bootstrap command.

If I specify the bootstrapping version, will that also solve this?

Help me figure out what I’ve changed that would all of a sudden be causing this pain :frowning:

Assuming the bug I referenced is your problem, then the core of the issue is that you’re creating encrypted data bags on ruby 1.8-1.9.2 and reading them on ruby 1.9.3. You can work around the issue by adding this code to your chef/config.rb or in the cookbook that reads the encrypted data bag item:

YAML::ENGINE.yamler = ‘syck’ if RUBY_VERSION > ‘1.9’

A longer discussion of the format change in encrypted data bag items, the implications of the change, and compatibility is here:

http://wiki.opscode.com/display/chef/Breaking+Changes+in+Chef+11#BreakingChangesinChef11-EncryptedDataBagItemFormatChange

Since Chef 11 client is not released as an alpha yet, I’d recommend using the workaround for now.

Daniel DeLeo


#7

The place where I’d have to add that is on the machine I’m bootstrapping,
no?

I still don’t understand clearly what changed - I mean - this was working
not that long ago…

On Wed, Jan 2, 2013 at 6:11 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, January 2, 2013 at 2:38 PM, Maven User wrote:

I tried to specify the version of chef to install in the bootstrap command
(10.16.4) and that didn’t solve the issue either.

Daniel - the bug you mention - do I have to upgrade my client from
10.12.0 to 11.X to get this all working again?

On Wed, Jan 2, 2013 at 5:24 PM, Maven User maven.2.user@gmail.com wrote:

Hmmm- more history…

Previously, we were specifying the distribution we wanted to use
(ubuntu12.04-gems), but the moneta issue broke this for us, so via this
mailing list, we solved this by upgrading my cookbooks and taking out the
distribution flag to the bootstrap command.

If I specify the bootstrapping version, will that also solve this?

Help me figure out what I’ve changed that would all of a sudden be causing
this pain :frowning:

Assuming the bug I referenced is your problem, then the core of the issue
is that you’re creating encrypted data bags on ruby 1.8-1.9.2 and reading
them on ruby 1.9.3. You can work around the issue by adding this code to
your chef/config.rb or in the cookbook that reads the encrypted data bag
item:

YAML::ENGINE.yamler = ‘syck’ if RUBY_VERSION > ‘1.9’

A longer discussion of the format change in encrypted data bag items, the
implications of the change, and compatibility is here:

http://wiki.opscode.com/display/chef/Breaking+Changes+in+Chef+11#BreakingChangesinChef11-EncryptedDataBagItemFormatChange

Since Chef 11 client is not released as an alpha yet, I’d recommend using
the workaround for now.

Daniel DeLeo


#8

(and thank you so much - I’m pretty much wedged until I get this sorted…)

On Wed, Jan 2, 2013 at 6:14 PM, Maven User maven.2.user@gmail.com wrote:

The place where I’d have to add that is on the machine I’m bootstrapping,
no?

I still don’t understand clearly what changed - I mean - this was working
not that long ago…

On Wed, Jan 2, 2013 at 6:11 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, January 2, 2013 at 2:38 PM, Maven User wrote:

I tried to specify the version of chef to install in the bootstrap
command (10.16.4) and that didn’t solve the issue either.

Daniel - the bug you mention - do I have to upgrade my client from
10.12.0 to 11.X to get this all working again?

On Wed, Jan 2, 2013 at 5:24 PM, Maven User maven.2.user@gmail.comwrote:

Hmmm- more history…

Previously, we were specifying the distribution we wanted to use
(ubuntu12.04-gems), but the moneta issue broke this for us, so via this
mailing list, we solved this by upgrading my cookbooks and taking out the
distribution flag to the bootstrap command.

If I specify the bootstrapping version, will that also solve this?

Help me figure out what I’ve changed that would all of a sudden be
causing this pain :frowning:

Assuming the bug I referenced is your problem, then the core of the issue
is that you’re creating encrypted data bags on ruby 1.8-1.9.2 and reading
them on ruby 1.9.3. You can work around the issue by adding this code to
your chef/config.rb or in the cookbook that reads the encrypted data bag
item:

YAML::ENGINE.yamler = ‘syck’ if RUBY_VERSION > ‘1.9’

A longer discussion of the format change in encrypted data bag items, the
implications of the change, and compatibility is here:

http://wiki.opscode.com/display/chef/Breaking+Changes+in+Chef+11#BreakingChangesinChef11-EncryptedDataBagItemFormatChange

Since Chef 11 client is not released as an alpha yet, I’d recommend using
the workaround for now.

Daniel DeLeo


#9

Is the inverse also true? I can see that locally, I’m running 1.9.3 - but
I’m not sure what is getting used during bootstrapping… Waiting to get
this particular vm back to a failed state so I can see…

On Wed, Jan 2, 2013 at 6:11 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, January 2, 2013 at 2:38 PM, Maven User wrote:

I tried to specify the version of chef to install in the bootstrap command
(10.16.4) and that didn’t solve the issue either.

Daniel - the bug you mention - do I have to upgrade my client from
10.12.0 to 11.X to get this all working again?

On Wed, Jan 2, 2013 at 5:24 PM, Maven User maven.2.user@gmail.com wrote:

Hmmm- more history…

Previously, we were specifying the distribution we wanted to use
(ubuntu12.04-gems), but the moneta issue broke this for us, so via this
mailing list, we solved this by upgrading my cookbooks and taking out the
distribution flag to the bootstrap command.

If I specify the bootstrapping version, will that also solve this?

Help me figure out what I’ve changed that would all of a sudden be causing
this pain :frowning:

Assuming the bug I referenced is your problem, then the core of the issue
is that you’re creating encrypted data bags on ruby 1.8-1.9.2 and reading
them on ruby 1.9.3. You can work around the issue by adding this code to
your chef/config.rb or in the cookbook that reads the encrypted data bag
item:

YAML::ENGINE.yamler = ‘syck’ if RUBY_VERSION > ‘1.9’

A longer discussion of the format change in encrypted data bag items, the
implications of the change, and compatibility is here:

http://wiki.opscode.com/display/chef/Breaking+Changes+in+Chef+11#BreakingChangesinChef11-EncryptedDataBagItemFormatChange

Since Chef 11 client is not released as an alpha yet, I’d recommend using
the workaround for now.

Daniel DeLeo


#10

Hmmm - does this apply to ONLY encrypted databags? I tried it with a
normal one and the same problem exists…

On Wed, Jan 2, 2013 at 6:11 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, January 2, 2013 at 2:38 PM, Maven User wrote:

I tried to specify the version of chef to install in the bootstrap command
(10.16.4) and that didn’t solve the issue either.

Daniel - the bug you mention - do I have to upgrade my client from
10.12.0 to 11.X to get this all working again?

On Wed, Jan 2, 2013 at 5:24 PM, Maven User maven.2.user@gmail.com wrote:

Hmmm- more history…

Previously, we were specifying the distribution we wanted to use
(ubuntu12.04-gems), but the moneta issue broke this for us, so via this
mailing list, we solved this by upgrading my cookbooks and taking out the
distribution flag to the bootstrap command.

If I specify the bootstrapping version, will that also solve this?

Help me figure out what I’ve changed that would all of a sudden be causing
this pain :frowning:

Assuming the bug I referenced is your problem, then the core of the issue
is that you’re creating encrypted data bags on ruby 1.8-1.9.2 and reading
them on ruby 1.9.3. You can work around the issue by adding this code to
your chef/config.rb or in the cookbook that reads the encrypted data bag
item:

YAML::ENGINE.yamler = ‘syck’ if RUBY_VERSION > ‘1.9’

A longer discussion of the format change in encrypted data bag items, the
implications of the change, and compatibility is here:

http://wiki.opscode.com/display/chef/Breaking+Changes+in+Chef+11#BreakingChangesinChef11-EncryptedDataBagItemFormatChange

Since Chef 11 client is not released as an alpha yet, I’d recommend using
the workaround for now.

Daniel DeLeo


#11

Also - should this line:

YAML::ENGINE.yamler = ‘syck’ if RUBY_VERSION > ‘1.9’

be:

YAML::ENGINE.yamler = ‘syck’ if RUBY_VERSION > ‘1.9.2’

based on your comment (and the bug):

…on ruby 1.8-1.9.2 and reading them on ruby 1.9.3…

???

On Wed, Jan 2, 2013 at 6:11 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, January 2, 2013 at 2:38 PM, Maven User wrote:

I tried to specify the version of chef to install in the bootstrap command
(10.16.4) and that didn’t solve the issue either.

Daniel - the bug you mention - do I have to upgrade my client from
10.12.0 to 11.X to get this all working again?

On Wed, Jan 2, 2013 at 5:24 PM, Maven User maven.2.user@gmail.com wrote:

Hmmm- more history…

Previously, we were specifying the distribution we wanted to use
(ubuntu12.04-gems), but the moneta issue broke this for us, so via this
mailing list, we solved this by upgrading my cookbooks and taking out the
distribution flag to the bootstrap command.

If I specify the bootstrapping version, will that also solve this?

Help me figure out what I’ve changed that would all of a sudden be causing
this pain :frowning:

Assuming the bug I referenced is your problem, then the core of the issue
is that you’re creating encrypted data bags on ruby 1.8-1.9.2 and reading
them on ruby 1.9.3. You can work around the issue by adding this code to
your chef/config.rb or in the cookbook that reads the encrypted data bag
item:

YAML::ENGINE.yamler = ‘syck’ if RUBY_VERSION > ‘1.9’

A longer discussion of the format change in encrypted data bag items, the
implications of the change, and compatibility is here:

http://wiki.opscode.com/display/chef/Breaking+Changes+in+Chef+11#BreakingChangesinChef11-EncryptedDataBagItemFormatChange

Since Chef 11 client is not released as an alpha yet, I’d recommend using
the workaround for now.

Daniel DeLeo