Possible fixes for COOK-1676 (mysql cookbook fails on first run on RHEL6)


#1

apologies, i can get a bit long-winded in my questions…
short version:

should I follow the fix for COOK-517, or the fix for COOK-727?

long version:

on RHEL/CentOS6, the current mysql cookbook installs the mysql server
package (which creates the mysql user and mysql group)
then it tries to create some folders and templates using the mysql
user and mysql group

since ruby caches the group names, this fails, as the group doesn’t yet exist.
This is documented in COOK-1676, and has been occurring for a long
time, just didn’t get a chance to write it up before, but now someone
else did.

I see two ways to fix this, neither have I completely tested, but both
theoretically will work.

In COOK-517, Seth Chisamore fixed the same bug in the users cookbook
by adding the following code:

ruby_block “reset group list” do
block do
Etc.endgrent
end
action :nothing
end

then adding a notifies line to whatever block creates the group.

I just finished completing a mirror fix for the mysql cookbook here:

In COOK-727, Joshua Timberman made a fix for the postgresql cookbook
for the same issue,
but instead of resetting the group list, he manually created the user
and group for postgresql "like the package will"
see here:
https://github.com/lamont-opscode/cookbooks/blob/COOK-716/postgresql/recipes/server_redhat.rb

I could follow Joshua’s way of doing it, but I worry… what happens
if the mysql upstream package changes
? Then it doesn’t create it
"like the package will". Then I’ll be screwed in the middle of the
night when i am rebuilding a failed server.

Thoughts?


#2

I prefer the reset, since I think trusting the upstream makes sense.

Sent from my iPhone

On Oct 9, 2012, at 4:18 PM, “Jesse Campbell” hikeit@gmail.com wrote:

apologies, i can get a bit long-winded in my questions…
short version:

should I follow the fix for COOK-517, or the fix for COOK-727?

long version:

on RHEL/CentOS6, the current mysql cookbook installs the mysql server
package (which creates the mysql user and mysql group)
then it tries to create some folders and templates using the mysql
user and mysql group

since ruby caches the group names, this fails, as the group doesn’t yet exist.
This is documented in COOK-1676, and has been occurring for a long
time, just didn’t get a chance to write it up before, but now someone
else did.

I see two ways to fix this, neither have I completely tested, but both
theoretically will work.

In COOK-517, Seth Chisamore fixed the same bug in the users cookbook
by adding the following code:

ruby_block “reset group list” do
block do
Etc.endgrent
end
action :nothing
end

then adding a notifies line to whatever block creates the group.

I just finished completing a mirror fix for the mysql cookbook here:
https://github.com/jcam/mysql/commit/d57e4055e3ec6fe9f4c5d5a868f552a02e408133

In COOK-727, Joshua Timberman made a fix for the postgresql cookbook
for the same issue,
but instead of resetting the group list, he manually created the user
and group for postgresql "like the package will"
see here:
https://github.com/lamont-opscode/cookbooks/blob/COOK-716/postgresql/recipes/server_redhat.rb

I could follow Joshua’s way of doing it, but I worry… what happens
if the mysql upstream package changes
? Then it doesn’t create it
"like the package will". Then I’ll be screwed in the middle of the
night when i am rebuilding a failed server.

Thoughts?


#3

Both assume quite a bit about the implementation inside the package. If things change in the package, potentially anything could go wrong. Most likely though, the user or group for a service will be changed. That would break both approaches.

There are two advantages to the explicit user/group resources: source installs and resource idempotence. Source installs will need the accounts to be created anyway, so this makes the installation of each more similar. And it’s also more explicit about what resources should exist, instead of ‘resetting’ and depending on resources that are managed under our noses.

That said, the reset is the lightest touch approach, least error prone and most reusable.

YAY BIKE SHED

On 2012-10-09, at 23:17 , Jesse Campbell hikeit@gmail.com wrote:

apologies, i can get a bit long-winded in my questions…
short version:

should I follow the fix for COOK-517, or the fix for COOK-727?

long version:

on RHEL/CentOS6, the current mysql cookbook installs the mysql server
package (which creates the mysql user and mysql group)
then it tries to create some folders and templates using the mysql
user and mysql group

since ruby caches the group names, this fails, as the group doesn’t yet exist.
This is documented in COOK-1676, and has been occurring for a long
time, just didn’t get a chance to write it up before, but now someone
else did.

I see two ways to fix this, neither have I completely tested, but both
theoretically will work.

In COOK-517, Seth Chisamore fixed the same bug in the users cookbook
by adding the following code:

ruby_block “reset group list” do
block do
Etc.endgrent
end
action :nothing
end

then adding a notifies line to whatever block creates the group.

I just finished completing a mirror fix for the mysql cookbook here:
https://github.com/jcam/mysql/commit/d57e4055e3ec6fe9f4c5d5a868f552a02e408133

In COOK-727, Joshua Timberman made a fix for the postgresql cookbook
for the same issue,
but instead of resetting the group list, he manually created the user
and group for postgresql "like the package will"
see here:
https://github.com/lamont-opscode/cookbooks/blob/COOK-716/postgresql/recipes/server_redhat.rb

I could follow Joshua’s way of doing it, but I worry… what happens
if the mysql upstream package changes
? Then it doesn’t create it
"like the package will". Then I’ll be screwed in the middle of the
night when i am rebuilding a failed server.

Thoughts?


#4

Configuration management, in this era, is all about trusting that the things you are calling are going to do the “right thing”, where “right thing” is defined by a different policy based on the choice of operating system you made in the beginning. If it’s going to behave differently, you hope that you were on the list of folks paying attention to the change in policy. :slight_smile:

Best,
Adam

On Oct 9, 2012, at 4:37 PM, Joseph Anthony Pasquale Holsten wrote:

Both assume quite a bit about the implementation inside the package. If things change in the package, potentially anything could go wrong. Most likely though, the user or group for a service will be changed. That would break both approaches.

There are two advantages to the explicit user/group resources: source installs and resource idempotence. Source installs will need the accounts to be created anyway, so this makes the installation of each more similar. And it’s also more explicit about what resources should exist, instead of ‘resetting’ and depending on resources that are managed under our noses.

That said, the reset is the lightest touch approach, least error prone and most reusable.

YAY BIKE SHED

On 2012-10-09, at 23:17 , Jesse Campbell hikeit@gmail.com wrote:

apologies, i can get a bit long-winded in my questions…
short version:

should I follow the fix for COOK-517, or the fix for COOK-727?

long version:

on RHEL/CentOS6, the current mysql cookbook installs the mysql server
package (which creates the mysql user and mysql group)
then it tries to create some folders and templates using the mysql
user and mysql group

since ruby caches the group names, this fails, as the group doesn’t yet exist.
This is documented in COOK-1676, and has been occurring for a long
time, just didn’t get a chance to write it up before, but now someone
else did.

I see two ways to fix this, neither have I completely tested, but both
theoretically will work.

In COOK-517, Seth Chisamore fixed the same bug in the users cookbook
by adding the following code:

ruby_block “reset group list” do
block do
Etc.endgrent
end
action :nothing
end

then adding a notifies line to whatever block creates the group.

I just finished completing a mirror fix for the mysql cookbook here:
https://github.com/jcam/mysql/commit/d57e4055e3ec6fe9f4c5d5a868f552a02e408133

In COOK-727, Joshua Timberman made a fix for the postgresql cookbook
for the same issue,
but instead of resetting the group list, he manually created the user
and group for postgresql "like the package will"
see here:
https://github.com/lamont-opscode/cookbooks/blob/COOK-716/postgresql/recipes/server_redhat.rb

I could follow Joshua’s way of doing it, but I worry… what happens
if the mysql upstream package changes
? Then it doesn’t create it
"like the package will". Then I’ll be screwed in the middle of the
night when i am rebuilding a failed server.

Thoughts?