No chefdk RPM available for RHEL 5?

I’ve been testing some environments with RHEL 6 and chefdk 0.4.0, which works well, but can’t seem to find chedk for RHEL 5. I particularly want it for the integrated Berkshelf support, which is much easier to use from chefdk rather than compiling it locally.

Is thee a chefk RPM available for RHEL 5? Can I do anything to help create one? I’ve done many, many, many RPM backports in my career.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com

You should be able to use the RHEL 6 rpm on RHEL 5. Worth a try.

On Wed, Mar 4, 2015 at 6:27 PM, Nico Kadel-Garcia <
nkadel@skyhookwireless.com> wrote:

I've been testing some environments with RHEL 6 and chefdk 0.4.0, which
works well, but can't seem to find chedk for RHEL 5. I particularly want it
for the integrated Berkshelf support, which is much easier to use from
chefdk rather than compiling it locally.

Is thee a chefk RPM available for RHEL 5? Can I do anything to help create
one? I've done many, many, many RPM backports in my career.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com

--

Peter Burkholder — Customer Success Engineer

Unavailability: Travel March 2-3; Vacation March 16-20; ChefConf March
30-April 3

301-204-5767 – pburkholder@chef.io – *my: *Linkedin
http://www.linkedin.com/in/pburkholder Twitter
http://www.twitter.com/pburkholder Cal
https://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEK
endar

CHEF

CHEF.IO http://www.chef.io/

TM

chef.io http://www.chef.io/ Blog http://www.chef.io/blog/ Facebook
https://www.facebook.com/getchefdotcom Twitter
https://twitter.com/chef Youtube https://www.youtube.com/getchef

I’ve tried installing ChefDK on RHEL 5.11 to no avail since it requires ruby libraries that are not available.

Chris

From: Peter Burkholder [mailto:pburkholder@chef.io]
Sent: Wednesday, March 04, 2015 10:31 PM
To: chef@lists.opscode.com
Subject: [chef] Re: No chefdk RPM available for RHEL 5?

You should be able to use the RHEL 6 rpm on RHEL 5. Worth a try.

On Wed, Mar 4, 2015 at 6:27 PM, Nico Kadel-Garcia <nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com> wrote:
I’ve been testing some environments with RHEL 6 and chefdk 0.4.0, which works well, but can’t seem to find chedk for RHEL 5. I particularly want it for the integrated Berkshelf support, which is much easier to use from chefdk rather than compiling it locally.

Is thee a chefk RPM available for RHEL 5? Can I do anything to help create one? I’ve done many, many, many RPM backports in my career.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com

Peter Burkholder — Customer Success Engineer

Unavailability: Travel March 2-3; Vacation March 16-20; ChefConf March 30-April 3

301-204-5767 – pburkholder@chef.iomailto:pburkholder@chef.io – my: Linkedinhttp://www.linkedin.com/in/pburkholder Twitterhttp://www.twitter.com/pburkholder Calhttps://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEKendar

CHEF

CHEF.IOhttp://www.chef.io/

TM

chef.iohttp://www.chef.io/ Bloghttp://www.chef.io/blog/ Facebookhttps://www.facebook.com/getchefdotcom Twitterhttps://twitter.com/chef Youtubehttps://www.youtube.com/getchef

Might be time to open the RPM, and do a bit of hacking :slight_smile:

On Thu, Mar 5, 2015 at 7:46 AM, Fouts, Chris Chris.Fouts@sensus.com wrote:

I’ve tried installing ChefDK on RHEL 5.11 to no avail since it requires
ruby libraries that are not available.

Chris

From: Peter Burkholder [mailto:pburkholder@chef.io]
Sent: Wednesday, March 04, 2015 10:31 PM
To: chef@lists.opscode.com
Subject: [chef] Re: No chefdk RPM available for RHEL 5?

You should be able to use the RHEL 6 rpm on RHEL 5. Worth a try.

On Wed, Mar 4, 2015 at 6:27 PM, Nico Kadel-Garcia <
nkadel@skyhookwireless.com> wrote:

I've been testing some environments with RHEL 6 and chefdk 0.4.0, which
works well, but can't seem to find chedk for RHEL 5. I particularly want it
for the integrated Berkshelf support, which is much easier to use from
chefdk rather than compiling it locally.

Is thee a chefk RPM available for RHEL 5? Can I do anything to help create
one? I've done many, many, many RPM backports in my career.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com

--

Peter Burkholder — Customer Success Engineer

Unavailability: Travel March 2-3; Vacation March 16-20; ChefConf March
30-April 3

301-204-5767 – pburkholder@chef.io – *my: *Linkedin
http://www.linkedin.com/in/pburkholder Twitter
http://www.twitter.com/pburkholder Cal
https://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEK
endar

CHEF

CHEF.IO http://www.chef.io/

TM

chef.io http://www.chef.io/ Blog http://www.chef.io/blog/
Facebook https://www.facebook.com/getchefdotcom Twitter
https://twitter.com/chef Youtube https://www.youtube.com/getchef

--

Kenneth Barry
TuneIn | Build and Release Engineer
M: 409-673-0544

One should be able to generate an chef-dk RPM package for EL5 with
omnibus-chef from here: GitHub - chef-boneyard/omnibus-chef: Omnibus packaging for Chef

Eric G. Wolfe
email: eric.wolfe@cyclecomputing.com
cell: 304.942.3970
twitter: @atomic_penguin

Cycle Computing
Better Answers. Faster.

http://www.cyclecomputing.com
twitter: @cyclecomputing

On 03/05/2015 11:31 AM, Kenneth Barry wrote:

Might be time to open the RPM, and do a bit of hacking :slight_smile:

On Thu, Mar 5, 2015 at 7:46 AM, Fouts, Chris Chris.Fouts@sensus.com wrote:

I’ve tried installing ChefDK on RHEL 5.11 to no avail since it requires
ruby libraries that are not available.

Chris

From: Peter Burkholder [mailto:pburkholder@chef.io]
Sent: Wednesday, March 04, 2015 10:31 PM
To: chef@lists.opscode.com
Subject: [chef] Re: No chefdk RPM available for RHEL 5?

You should be able to use the RHEL 6 rpm on RHEL 5. Worth a try.

On Wed, Mar 4, 2015 at 6:27 PM, Nico Kadel-Garcia <
nkadel@skyhookwireless.com> wrote:

I've been testing some environments with RHEL 6 and chefdk 0.4.0, which
works well, but can't seem to find chedk for RHEL 5. I particularly want it
for the integrated Berkshelf support, which is much easier to use from
chefdk rather than compiling it locally.

Is thee a chefk RPM available for RHEL 5? Can I do anything to help create
one? I've done many, many, many RPM backports in my career.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com

--

Peter Burkholder — Customer Success Engineer

Unavailability: Travel March 2-3; Vacation March 16-20; ChefConf March
30-April 3

301-204-5767 – pburkholder@chef.io – *my: *Linkedin
http://www.linkedin.com/in/pburkholder Twitter
http://www.twitter.com/pburkholder Cal
https://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEK
endar

CHEF

CHEF.IO http://www.chef.io/

TM

chef.io http://www.chef.io/ Blog http://www.chef.io/blog/
Facebook https://www.facebook.com/getchefdotcom Twitter
https://twitter.com/chef Youtube https://www.youtube.com/getchef

We made a conscious product decision not to support RHEL 5 as a platform
for ChefDK.

  • Julian

On Thu, Mar 5, 2015 at 9:46 AM, Fouts, Chris Chris.Fouts@sensus.com wrote:

I’ve tried installing ChefDK on RHEL 5.11 to no avail since it requires
ruby libraries that are not available.

Chris

From: Peter Burkholder [mailto:pburkholder@chef.io]
Sent: Wednesday, March 04, 2015 10:31 PM
To: chef@lists.opscode.com
Subject: [chef] Re: No chefdk RPM available for RHEL 5?

You should be able to use the RHEL 6 rpm on RHEL 5. Worth a try.

On Wed, Mar 4, 2015 at 6:27 PM, Nico Kadel-Garcia <
nkadel@skyhookwireless.com> wrote:

I've been testing some environments with RHEL 6 and chefdk 0.4.0, which
works well, but can't seem to find chedk for RHEL 5. I particularly want it
for the integrated Berkshelf support, which is much easier to use from
chefdk rather than compiling it locally.

Is thee a chefk RPM available for RHEL 5? Can I do anything to help create
one? I've done many, many, many RPM backports in my career.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com

--

Peter Burkholder — Customer Success Engineer

Unavailability: Travel March 2-3; Vacation March 16-20; ChefConf March
30-April 3

301-204-5767 – pburkholder@chef.io – *my: *Linkedin
http://www.linkedin.com/in/pburkholder Twitter
http://www.twitter.com/pburkholder Cal
https://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEK
endar

CHEF

CHEF.IO http://www.chef.io/

TM

chef.io http://www.chef.io/ Blog http://www.chef.io/blog/
Facebook https://www.facebook.com/getchefdotcom Twitter
https://twitter.com/chef Youtube https://www.youtube.com/getchef

--
[ Julian C. Dunn jdunn@aquezada.com * Sorry, I'm ]
[ WWW: Julian Dunn's Blog - Commentary on media, technology, and everything in between. * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]

I’m afraid this puts me in a difficult place. It means that, for RHEL 5 based operating systems, I’ll have to use the standard ‘chef’ client, which means that to use Berkshelf on them I’ll have to compile Berkshelf. I’m not sure if anyone’s mentioned lately that Berkshelf takes a quite long time, and quite a few resources, to compile: many smaller virtual machins running RHEL 5 will effectively swap themselves to death, or even run out of swap space and crash, if the root user tries to compile Berkshelf. It means that to use my preferred chef-solo environments for RHEL 5 based systems, I’ll have to compile it on a sample host and push the newly compiled components, out of band, to the target systems.

I’d be happy to take a look at building an RHEL 5 RPM myself, if I had some sense of the build environments or .spec files actually used for chefdk RPM building. Are the SRPM’s available anywhere, or source with the actual .spec files and any applied patches, available anywhere public? I’d also really like to encourage publishing the SRPM.

In fact, as I checked the RPM, I noticed that it has no ‘License’ option set. May I suggest putting that in the spec file? I’d offer a patch to it, but I can’t seem to find the relevant chefdk.spec file in a public repository.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com

From: Julian C. Dunn [mailto:jdunn@aquezada.com]
Sent: Thursday, March 05, 2015 5:56 PM
To: chef@lists.opscode.com
Subject: [chef] Re: RE: Re: No chefdk RPM available for RHEL 5?

We made a conscious product decision not to support RHEL 5 as a platform for ChefDK.

  • Julian

On Thu, Mar 5, 2015 at 9:46 AM, Fouts, Chris <Chris.Fouts@sensus.commailto:Chris.Fouts@sensus.com> wrote:
I’ve tried installing ChefDK on RHEL 5.11 to no avail since it requires ruby libraries that are not available.

Chris

From: Peter Burkholder [mailto:pburkholder@chef.iomailto:pburkholder@chef.io]
Sent: Wednesday, March 04, 2015 10:31 PM
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: [chef] Re: No chefdk RPM available for RHEL 5?

You should be able to use the RHEL 6 rpm on RHEL 5. Worth a try.

On Wed, Mar 4, 2015 at 6:27 PM, Nico Kadel-Garcia <nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com> wrote:
I’ve been testing some environments with RHEL 6 and chefdk 0.4.0, which works well, but can’t seem to find chedk for RHEL 5. I particularly want it for the integrated Berkshelf support, which is much easier to use from chefdk rather than compiling it locally.

Is thee a chefk RPM available for RHEL 5? Can I do anything to help create one? I’ve done many, many, many RPM backports in my career.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com

Peter Burkholder — Customer Success Engineer

Unavailability: Travel March 2-3; Vacation March 16-20; ChefConf March 30-April 3

301-204-5767tel:301-204-5767pburkholder@chef.iomailto:pburkholder@chef.io – my: Linkedinhttp://www.linkedin.com/in/pburkholder Twitterhttp://www.twitter.com/pburkholder Calhttps://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEKendar

CHEF

CHEF.IOhttp://www.chef.io/

TM

chef.iohttp://www.chef.io/ Bloghttp://www.chef.io/blog/ Facebookhttps://www.facebook.com/getchefdotcom Twitterhttps://twitter.com/chef Youtubehttps://www.youtube.com/getchef


[ Julian C. Dunn <jdunn@aquezada.commailto:jdunn@aquezada.com> * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/http://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]

I am pretty confident that there are no srpms. It's all omnibus. I know,
:mindblown:, right?

https://github.com/chef/omnibus-chef/blob/master/config/projects/chefdk.rb

Why do you need berkshelf on your edge nodes? you typically run it from a
workstation/CI then consume the assembled assets toward the edge. Resolving
on the edge all the time is not something seen very often, I think.

You may have varying mileage by modifying the omnibus-chef/chef-dk/.. to
target RH5 as a build platform; you typically just setup whatever Omnibus
needs then run it inside the VM.

GL, HF!

cheers,

--aj

On Tue, Mar 17, 2015 at 10:31 AM, Nico Kadel-Garcia <
nkadel@skyhookwireless.com> wrote:

I’m afraid this puts me in a difficult place. It means that, for RHEL 5
based operating systems, I’ll have to use the standard ‘chef’ client, which
means that to use Berkshelf on them I’ll have to compile Berkshelf. I’m not
sure if anyone’s mentioned lately that Berkshelf takes a quite long time,
and quite a few resources, to compile: many smaller virtual machins running
RHEL 5 will effectively swap themselves to death, or even run out of swap
space and crash, if the root user tries to compile Berkshelf. It means that
to use my preferred chef-solo environments for RHEL 5 based systems, I’ll
have to compile it on a sample host and push the newly compiled components,
out of band, to the target systems.

I’d be happy to take a look at building an RHEL 5 RPM myself, if I had
some sense of the build environments or .spec files actually used for
chefdk RPM building. Are the SRPM’s available anywhere, or source with the
actual .spec files and any applied patches, available anywhere public? I’d
also really like to encourage publishing the SRPM.

In fact, as I checked the RPM, I noticed that it has no ‘License’ option
set. May I suggest putting that in the spec file? I’d offer a patch to it,
but I can’t seem to find the relevant chefdk.spec file in a public
repository.

Nico Kadel-Garcia

Lead DevOps Engineer

nkadel@skyhookwireless.com

From: Julian C. Dunn [mailto:jdunn@aquezada.com]
Sent: Thursday, March 05, 2015 5:56 PM
To: chef@lists.opscode.com
Subject: [chef] Re: RE: Re: No chefdk RPM available for RHEL 5?

We made a conscious product decision not to support RHEL 5 as a platform
for ChefDK.

https://github.com/chef/chef-rfc/blob/master/rfc021-platform-support-policy.md

  • Julian

On Thu, Mar 5, 2015 at 9:46 AM, Fouts, Chris Chris.Fouts@sensus.com
wrote:

I’ve tried installing ChefDK on RHEL 5.11 to no avail since it requires
ruby libraries that are not available.

Chris

From: Peter Burkholder [mailto:pburkholder@chef.io]
Sent: Wednesday, March 04, 2015 10:31 PM
To: chef@lists.opscode.com
Subject: [chef] Re: No chefdk RPM available for RHEL 5?

You should be able to use the RHEL 6 rpm on RHEL 5. Worth a try.

On Wed, Mar 4, 2015 at 6:27 PM, Nico Kadel-Garcia <
nkadel@skyhookwireless.com> wrote:

I've been testing some environments with RHEL 6 and chefdk 0.4.0, which
works well, but can't seem to find chedk for RHEL 5. I particularly want it
for the integrated Berkshelf support, which is much easier to use from
chefdk rather than compiling it locally.

Is thee a chefk RPM available for RHEL 5? Can I do anything to help create
one? I've done many, many, many RPM backports in my career.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com

--

Peter Burkholder — Customer Success Engineer

Unavailability: Travel March 2-3; Vacation March 16-20; ChefConf March
30-April 3

301-204-5767 – pburkholder@chef.io – *my: *Linkedin
http://www.linkedin.com/in/pburkholder Twitter
http://www.twitter.com/pburkholder Cal
https://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEK
endar

CHEF

CHEF.IO http://www.chef.io/

TM

chef.io http://www.chef.io/ Blog http://www.chef.io/blog/
Facebook https://www.facebook.com/getchefdotcom Twitter
https://twitter.com/chef Youtube https://www.youtube.com/getchef

--

[ Julian C. Dunn jdunn@aquezada.com * Sorry, I'm ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]

You don’t have to compile Berkshelf for RHEL 5, you just have to install the gem. I do exactly this.

Chris

From: Nico Kadel-Garcia [mailto:nkadel@skyhookwireless.com]
Sent: Monday, March 16, 2015 5:32 PM
To: chef@lists.opscode.com
Subject: [chef] RE: Re: RE: Re: No chefdk RPM available for RHEL 5?

I’m afraid this puts me in a difficult place. It means that, for RHEL 5 based operating systems, I’ll have to use the standard ‘chef’ client, which means that to use Berkshelf on them I’ll have to compile Berkshelf. I’m not sure if anyone’s mentioned lately that Berkshelf takes a quite long time, and quite a few resources, to compile: many smaller virtual machins running RHEL 5 will effectively swap themselves to death, or even run out of swap space and crash, if the root user tries to compile Berkshelf. It means that to use my preferred chef-solo environments for RHEL 5 based systems, I’ll have to compile it on a sample host and push the newly compiled components, out of band, to the target systems.

I’d be happy to take a look at building an RHEL 5 RPM myself, if I had some sense of the build environments or .spec files actually used for chefdk RPM building. Are the SRPM’s available anywhere, or source with the actual .spec files and any applied patches, available anywhere public? I’d also really like to encourage publishing the SRPM.

In fact, as I checked the RPM, I noticed that it has no ‘License’ option set. May I suggest putting that in the spec file? I’d offer a patch to it, but I can’t seem to find the relevant chefdk.spec file in a public repository.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com

From: Julian C. Dunn [mailto:jdunn@aquezada.com]
Sent: Thursday, March 05, 2015 5:56 PM
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: [chef] Re: RE: Re: No chefdk RPM available for RHEL 5?

We made a conscious product decision not to support RHEL 5 as a platform for ChefDK.

  • Julian

On Thu, Mar 5, 2015 at 9:46 AM, Fouts, Chris <Chris.Fouts@sensus.commailto:Chris.Fouts@sensus.com> wrote:
I’ve tried installing ChefDK on RHEL 5.11 to no avail since it requires ruby libraries that are not available.

Chris

From: Peter Burkholder [mailto:pburkholder@chef.iomailto:pburkholder@chef.io]
Sent: Wednesday, March 04, 2015 10:31 PM
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: [chef] Re: No chefdk RPM available for RHEL 5?

You should be able to use the RHEL 6 rpm on RHEL 5. Worth a try.

On Wed, Mar 4, 2015 at 6:27 PM, Nico Kadel-Garcia <nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com> wrote:
I’ve been testing some environments with RHEL 6 and chefdk 0.4.0, which works well, but can’t seem to find chedk for RHEL 5. I particularly want it for the integrated Berkshelf support, which is much easier to use from chefdk rather than compiling it locally.

Is thee a chefk RPM available for RHEL 5? Can I do anything to help create one? I’ve done many, many, many RPM backports in my career.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com

Peter Burkholder — Customer Success Engineer

Unavailability: Travel March 2-3; Vacation March 16-20; ChefConf March 30-April 3

301-204-5767tel:301-204-5767pburkholder@chef.iomailto:pburkholder@chef.io – my: Linkedinhttp://www.linkedin.com/in/pburkholder Twitterhttp://www.twitter.com/pburkholder Calhttps://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEKendar

CHEF

CHEF.IOhttp://www.chef.io/

TM

chef.iohttp://www.chef.io/ Bloghttp://www.chef.io/blog/ Facebookhttps://www.facebook.com/getchefdotcom Twitterhttps://twitter.com/chef Youtubehttps://www.youtube.com/getchef


[ Julian C. Dunn <jdunn@aquezada.commailto:jdunn@aquezada.com> * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/http://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]

I was unclear. When installing the Berkshelf gem, it requires various other gems, including the libgecode libraries, and those are what take so long and consume so many resources to compile.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com

From: Fouts, Chris [mailto:Chris.Fouts@Sensus.com]
Sent: Tuesday, March 17, 2015 9:50 AM
To: chef@lists.opscode.com
Subject: [chef] RE: RE: Re: RE: Re: No chefdk RPM available for RHEL 5?

You don’t have to compile Berkshelf for RHEL 5, you just have to install the gem. I do exactly this.

Chris

From: Nico Kadel-Garcia [mailto:nkadel@skyhookwireless.com]
Sent: Monday, March 16, 2015 5:32 PM
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: [chef] RE: Re: RE: Re: No chefdk RPM available for RHEL 5?

I’m afraid this puts me in a difficult place. It means that, for RHEL 5 based operating systems, I’ll have to use the standard ‘chef’ client, which means that to use Berkshelf on them I’ll have to compile Berkshelf. I’m not sure if anyone’s mentioned lately that Berkshelf takes a quite long time, and quite a few resources, to compile: many smaller virtual machins running RHEL 5 will effectively swap themselves to death, or even run out of swap space and crash, if the root user tries to compile Berkshelf. It means that to use my preferred chef-solo environments for RHEL 5 based systems, I’ll have to compile it on a sample host and push the newly compiled components, out of band, to the target systems.

I’d be happy to take a look at building an RHEL 5 RPM myself, if I had some sense of the build environments or .spec files actually used for chefdk RPM building. Are the SRPM’s available anywhere, or source with the actual .spec files and any applied patches, available anywhere public? I’d also really like to encourage publishing the SRPM.

In fact, as I checked the RPM, I noticed that it has no ‘License’ option set. May I suggest putting that in the spec file? I’d offer a patch to it, but I can’t seem to find the relevant chefdk.spec file in a public repository.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com

From: Julian C. Dunn [mailto:jdunn@aquezada.com]
Sent: Thursday, March 05, 2015 5:56 PM
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: [chef] Re: RE: Re: No chefdk RPM available for RHEL 5?

We made a conscious product decision not to support RHEL 5 as a platform for ChefDK.

  • Julian

On Thu, Mar 5, 2015 at 9:46 AM, Fouts, Chris <Chris.Fouts@sensus.commailto:Chris.Fouts@sensus.com> wrote:
I’ve tried installing ChefDK on RHEL 5.11 to no avail since it requires ruby libraries that are not available.

Chris

From: Peter Burkholder [mailto:pburkholder@chef.iomailto:pburkholder@chef.io]
Sent: Wednesday, March 04, 2015 10:31 PM
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: [chef] Re: No chefdk RPM available for RHEL 5?

You should be able to use the RHEL 6 rpm on RHEL 5. Worth a try.

On Wed, Mar 4, 2015 at 6:27 PM, Nico Kadel-Garcia <nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com> wrote:
I’ve been testing some environments with RHEL 6 and chefdk 0.4.0, which works well, but can’t seem to find chedk for RHEL 5. I particularly want it for the integrated Berkshelf support, which is much easier to use from chefdk rather than compiling it locally.

Is thee a chefk RPM available for RHEL 5? Can I do anything to help create one? I’ve done many, many, many RPM backports in my career.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com

Peter Burkholder — Customer Success Engineer

Unavailability: Travel March 2-3; Vacation March 16-20; ChefConf March 30-April 3

301-204-5767tel:301-204-5767pburkholder@chef.iomailto:pburkholder@chef.io – my: Linkedinhttp://www.linkedin.com/in/pburkholder Twitterhttp://www.twitter.com/pburkholder Calhttps://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEKendar

CHEF

CHEF.IOhttp://www.chef.io/

TM

chef.iohttp://www.chef.io/ Bloghttp://www.chef.io/blog/ Facebookhttps://www.facebook.com/getchefdotcom Twitterhttps://twitter.com/chef Youtubehttps://www.youtube.com/getchef


[ Julian C. Dunn <jdunn@aquezada.commailto:jdunn@aquezada.com> * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/http://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]

We build ChefDK using this project: GitHub - chef-boneyard/omnibus-chef: Omnibus packaging for Chef

You can either set up a CentOS5 machine with compilers and a recent ruby yourself and then run bundle exec omnibus build chefdk or you can use the built-in test kitchen stuff to run the build in a VM for you.

--
Daniel DeLeo

On Tuesday, March 17, 2015 at 7:41 AM, Nico Kadel-Garcia wrote:

I was unclear. When installing the Berkshelf gem, it requires various other gems, including the libgecode libraries, and those are what take so long and consume so many resources to compile.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com (mailto:nkadel@skyhookwireless.com)

From: Fouts, Chris [mailto:Chris.Fouts@Sensus.com]
Sent: Tuesday, March 17, 2015 9:50 AM
To: chef@lists.opscode.com (mailto:chef@lists.opscode.com)
Subject: [chef] RE: RE: Re: RE: Re: No chefdk RPM available for RHEL 5?

You don’t have to compile Berkshelf for RHEL 5, you just have to install the gem. I do exactly this.

Chris

From: Nico Kadel-Garcia [mailto:nkadel@skyhookwireless.com]
Sent: Monday, March 16, 2015 5:32 PM
To: chef@lists.opscode.com (mailto:chef@lists.opscode.com)
Subject: [chef] RE: Re: RE: Re: No chefdk RPM available for RHEL 5?

I’m afraid this puts me in a difficult place. It means that, for RHEL 5 based operating systems, I’ll have to use the standard ‘chef’ client, which means that to use Berkshelf on them I’ll have to compile Berkshelf. I’m not sure if anyone’s mentioned lately that Berkshelf takes a quite long time, and quite a few resources, to compile: many smaller virtual machins running RHEL 5 will effectively swap themselves to death, or even run out of swap space and crash, if the root user tries to compile Berkshelf. It means that to use my preferred chef-solo environments for RHEL 5 based systems, I’ll have to compile it on a sample host and push the newly compiled components, out of band, to the target systems.

I’d be happy to take a look at building an RHEL 5 RPM myself, if I had some sense of the build environments or .spec files actually used for chefdk RPM building. Are the SRPM’s available anywhere, or source with the actual .spec files and any applied patches, available anywhere public? I’d also really like to encourage publishing the SRPM.

In fact, as I checked the RPM, I noticed that it has no ‘License’ option set. May I suggest putting that in the spec file? I’d offer a patch to it, but I can’t seem to find the relevant chefdk.spec file in a public repository.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com (mailto:nkadel@skyhookwireless.com)

From: Julian C. Dunn [mailto:jdunn@aquezada.com]
Sent: Thursday, March 05, 2015 5:56 PM
To: chef@lists.opscode.com (mailto:chef@lists.opscode.com)
Subject: [chef] Re: RE: Re: No chefdk RPM available for RHEL 5?

We made a conscious product decision not to support RHEL 5 as a platform for ChefDK.

https://github.com/chef/chef-rfc/blob/master/rfc021-platform-support-policy.md

  • Julian

On Thu, Mar 5, 2015 at 9:46 AM, Fouts, Chris <Chris.Fouts@sensus.com (mailto:Chris.Fouts@sensus.com)> wrote:

I’ve tried installing ChefDK on RHEL 5.11 to no avail since it requires ruby libraries that are not available.

Chris

From: Peter Burkholder [mailto:pburkholder@chef.io]
Sent: Wednesday, March 04, 2015 10:31 PM
To: chef@lists.opscode.com (mailto:chef@lists.opscode.com)
Subject: [chef] Re: No chefdk RPM available for RHEL 5?

You should be able to use the RHEL 6 rpm on RHEL 5. Worth a try.

On Wed, Mar 4, 2015 at 6:27 PM, Nico Kadel-Garcia <nkadel@skyhookwireless.com (mailto:nkadel@skyhookwireless.com)> wrote:
I've been testing some environments with RHEL 6 and chefdk 0.4.0, which works well, but can't seem to find chedk for RHEL 5. I particularly want it for the integrated Berkshelf support, which is much easier to use from chefdk rather than compiling it locally.

Is thee a chefk RPM available for RHEL 5? Can I do anything to help create one? I've done many, many, many RPM backports in my career.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com (mailto:nkadel@skyhookwireless.com)

--

Peter Burkholder — Customer Success Engineer

Unavailability: Travel March 2-3; Vacation March 16-20; ChefConf March 30-April 3

301-204-5767 (tel:301-204-5767) – pburkholder@chef.io (mailto:pburkholder@chef.io) – my: Linkedin (http://www.linkedin.com/in/pburkholder) Twitter (http://www.twitter.com/pburkholder) Cal (https://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEK)endar

CHEF

CHEF.IO (http://www.chef.io/)

TM

chef.io (http://www.chef.io/) Blog (Chef Blog - IT Automation for everything from configuration management to continuous delivery. | Chef) Facebook (Progress Chef | Seattle WA) Twitter (https://twitter.com/chef) Youtube (https://www.youtube.com/getchef)

--
[ Julian C. Dunn <jdunn@aquezada.com (mailto:jdunn@aquezada.com)> * Sorry, I'm ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ (http://sdf.org/1/users/keymaker/) * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]

The reluctance for the chefdk develers to directly support CentOS 5 is understandable, the ruby on it is quite out of date and insufficient for the current build tools.
I've activated a "ruby-1.9.3" cookbook on a CentOS 5 VM, and encountered adventures trying to use the bundle tool, but the CentOS 5 build chefdk RPM seems to work in my casual testing. I do have some comments.

  • Using "bundle" to build up the chefdk toolkit the first time runs into exactly the problems the basic "chef" and "chef-server" packages have building Berkshelf. It requires extensive compilation tools, and a LOT of RAM or swap, to successfully build the "dep-selector-gem" requirement. I wound up having to add several gigabytes of swap space just to allow it to complete.

  • The massive resource consumption of libgecode compilation is exacerbated by the hardcoded "make -j5", which I personally consider a premature optimization. The default should, ideally, be "make -j1" which complex tests or manual settings can optimize for powerful environments: being slow on instances that could compile faster is much safer than breaking on lightweight instances. I've actually commented about this before from a different workplace, and it's one of my compelling reasons to want to simply install chefdk in the first place..

  • The "bundle exec omnibus build chefdk" command uses the "Packager::RPM" tool to build the RPM on CentOS 5. Unfortunately, that tool builds only RPM's, not SRPM's. I wish I understood the tool well enough to fix that, but I don't today. That gets into security and source code management for RPM's: a build environment you construct from git, or anything else on the fly, does not necessarily bear a strong resemblance to the code used to build an earlier or later RPM, especially if the .spec file or any patches are generated dynamically. And sure enough, in this case, the .spec file is generated dynamically. So to analyze any '%post' or RPM macro controlled settings, you have to disassemble the whole RPM::Packager toolkit rather than having an SRPM to read.

Overall, this looks like it's actually in reach for CentOS or RHEL 5: the key is the lack of a recent enough ruby in CentOS 5 itself to build the packages.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com

-----Original Message-----
From: Daniel DeLeo [mailto:ddeleo@kallistec.com] On Behalf Of Daniel DeLeo
Sent: Tuesday, March 17, 2015 11:33 AM
To: chef@lists.opscode.com
Subject: [chef] Re: RE: RE: RE: Re: RE: Re: No chefdk RPM available for RHEL 5?

We build ChefDK using this project: GitHub - chef-boneyard/omnibus-chef: Omnibus packaging for Chef

You can either set up a CentOS5 machine with compilers and a recent ruby
yourself and then run bundle exec omnibus build chefdk or you can use the
built-in test kitchen stuff to run the build in a VM for you.

--
Daniel DeLeo

On Wednesday, March 25, 2015 at 3:12 PM, Nico Kadel-Garcia wrote:

The reluctance for the chefdk develers to directly support CentOS 5 is understandable, the ruby on it is quite out of date and insufficient for the current build tools.
I've activated a "ruby-1.9.3" cookbook on a CentOS 5 VM, and encountered adventures trying to use the bundle tool, but the CentOS 5 build chefdk RPM seems to work in my casual testing. I do have some comments.

You can use the built-in test kitchen stuff to do this, or you can reverse engineer it to get the cookbooks it uses and run them.

  • Using "bundle" to build up the chefdk toolkit the first time runs into exactly the problems the basic "chef" and "chef-server" packages have building Berkshelf. It requires extensive compilation tools, and a LOT of RAM or swap, to successfully build the "dep-selector-gem" requirement. I wound up having to add several gigabytes of swap space just to allow it to complete.
    The built-in kitchen stuff again handles this, or you can crib from it to size your build machines: https://github.com/chef/omnibus-chef/blob/master/.kitchen.yml
  • The massive resource consumption of libgecode compilation is exacerbated by the hardcoded "make -j5", which I personally consider a premature optimization. The default should, ideally, be "make -j1" which complex tests or manual settings can optimize for powerful environments: being slow on instances that could compile faster is much safer than breaking on lightweight instances. I've actually commented about this before from a different workplace, and it's one of my compelling reasons to want to simply install chefdk in the first place..
    It’s definitely not premature, we have to build it as part of the build process for ChefDK and Chef Server; getting the build down to a few minutes saves a ton of time. I’ve sketched out how to use ohai to make the build auto-detect lower resource machines, I just need someone to try it and ensure the build works. You’ve probably seen my comment about it in the pull request discussions.
  • The "bundle exec omnibus build chefdk" command uses the "Packager::RPM" tool to build the RPM on CentOS 5. Unfortunately, that tool builds only RPM's, not SRPM's. I wish I understood the tool well enough to fix that, but I don't today. That gets into security and source code management for RPM's: a build environment you construct from git, or anything else on the fly, does not necessarily bear a strong resemblance to the code used to build an earlier or later RPM, especially if the .spec file or any patches are generated dynamically. And sure enough, in this case, the .spec file is generated dynamically. So to analyze any '%post' or RPM macro controlled settings, you have to disassemble the whole RPM::Packager toolkit rather than having an SRPM to read.
    It’s all in omnibus, which saves us a ton of time by standardizing our build across platforms, as much as is possible anyway. The package scripts are here if you want to look at them: https://github.com/chef/omnibus-chef/tree/master/package-scripts/chefdk I realize this means that we’re breaking some of the platform conventions you’re used to, but without it we couldn’t support making packages for as many platforms as we do at all. You’re of course welcome to mirror all of it and build the packages yourself if you need to, and we’ll try to help if you run into any issues with that.

Overall, this looks like it's actually in reach for CentOS or RHEL 5: the key is the lack of a recent enough ruby in CentOS 5 itself to build the packages.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com (mailto:nkadel@skyhookwireless.com)

--
Daniel DeLeo

Hi Nico,

I hope you're not shaving the wrong yak here. ChefDK and Berkshelf are
generally only needed on development systems, not on the chef-client
systems. If you have RHEL6 or Ubuntu or Windows or OsX then you should be
fine developing cookbooks for RHEL5 clients. Sorry if I'm missing something
obvious, but are you sure you need ChefDK or Berkshelf for RHEL5, as
opposed to just the chef-client?

In an earlier message you mentioned, "I’ll have to use the standard ‘chef’
client, which means that to use Berkshelf on them I’ll have to compile
Berkshelf," but Berkshelf is only needed for dependency management on the
development side, not on the client end of things.

--Peter

On Wed, Mar 25, 2015 at 8:54 PM Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, March 25, 2015 at 3:12 PM, Nico Kadel-Garcia wrote:

The reluctance for the chefdk develers to directly support CentOS 5 is
understandable, the ruby on it is quite out of date and insufficient for
the current build tools.
I've activated a "ruby-1.9.3" cookbook on a CentOS 5 VM, and encountered
adventures trying to use the bundle tool, but the CentOS 5 build chefdk RPM
seems to work in my casual testing. I do have some comments.

You can use the built-in test kitchen stuff to do this, or you can reverse
engineer it to get the cookbooks it uses and run them.

  • Using "bundle" to build up the chefdk toolkit the first time runs into
    exactly the problems the basic "chef" and "chef-server" packages have
    building Berkshelf. It requires extensive compilation tools, and a LOT of
    RAM or swap, to successfully build the "dep-selector-gem" requirement. I
    wound up having to add several gigabytes of swap space just to allow it to
    complete.
    The built-in kitchen stuff again handles this, or you can crib from it to
    size your build machines: Progress Chef · GitHub
    omnibus-chef/blob/master/.kitchen.yml
  • The massive resource consumption of libgecode compilation is
    exacerbated by the hardcoded "make -j5", which I personally consider a
    premature optimization. The default should, ideally, be "make -j1" which
    complex tests or manual settings can optimize for powerful environments:
    being slow on instances that could compile faster is much safer than
    breaking on lightweight instances. I've actually commented about this
    before from a different workplace, and it's one of my compelling reasons to
    want to simply install chefdk in the first place..
    It’s definitely not premature, we have to build it as part of the build
    process for ChefDK and Chef Server; getting the build down to a few minutes
    saves a ton of time. I’ve sketched out how to use ohai to make the build
    auto-detect lower resource machines, I just need someone to try it and
    ensure the build works. You’ve probably seen my comment about it in the
    pull request discussions.
  • The "bundle exec omnibus build chefdk" command uses the
    "Packager::RPM" tool to build the RPM on CentOS 5. Unfortunately, that tool
    builds only RPM's, not SRPM's. I wish I understood the tool well enough to
    fix that, but I don't today. That gets into security and source code
    management for RPM's: a build environment you construct from git, or
    anything else on the fly, does not necessarily bear a strong resemblance to
    the code used to build an earlier or later RPM, especially if the .spec
    file or any patches are generated dynamically. And sure enough, in this
    case, the .spec file is generated dynamically. So to analyze any '%post' or
    RPM macro controlled settings, you have to disassemble the whole
    RPM::Packager toolkit rather than having an SRPM to read.
    It’s all in omnibus, which saves us a ton of time by standardizing our
    build across platforms, as much as is possible anyway. The package scripts
    are here if you want to look at them: Progress Chef · GitHub
    omnibus-chef/tree/master/package-scripts/chefdk I realize this means that
    we’re breaking some of the platform conventions you’re used to, but without
    it we couldn’t support making packages for as many platforms as we do at
    all. You’re of course welcome to mirror all of it and build the packages
    yourself if you need to, and we’ll try to help if you run into any issues
    with that.

Overall, this looks like it's actually in reach for CentOS or RHEL 5:
the key is the lack of a recent enough ruby in CentOS 5 itself to build the
packages.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com (mailto:nkadel@skyhookwireless.com)

--
Daniel DeLeo

I’ve several reasons to want chefdk on individual hosts:

· Chef servers are, from painful personal experience, bulky, expensive to host, and destabilizing to dynamic, mixed environments. A single mistaken update to a data bag for a central service, or a simple cookbook update, can take down an entire environment by screwing up every host. Particular examples include:

o Typos in ‘bind’ configuration files, for which there used to be no sanity checking and would break the ‘named’ service on restart.

o The refactoring and non-backwards-compatible update to yum, splitting off “yum::epel” recipe to a separate “yum-epel” cookbook and breaking all the old cookbooks that relied on yum::epel.

o The refactoring and non-backwards-compatible update to mysql, which went from a single MySQL instance configuration tool to an LWRP for multiple instances, and which deleted /etc/my.cnf.

· Using chef-solo on individual hosts makes them much safer to modify and update.

· chefdk is prefereable to the “chef-client” tool because already contains precompiled copies of the libgecode software, and I can pre-deploy it in a managed fashion to my chef-solo environments to manage their cookbooks individually.

o I consider the components necessary to build libgecode to be inappropriate to install on lightweight, exposed servers of any sort. (gcc and g++, in particular, are begging for trouble to install on a production server.) chefdk is therefore, much, much safer than building libgecode.

· I’d use librarian-chef instead of Berkshelf, but librarian-chef has a nasty tendency to update every depencency for your designated cookbook is unacceptable for daily use. This is unsafe, precisely because of the unexpected ‘yum’ and ‘mysql’ udpates I mentioned above.

· If you have two sysadmins developing changes on the same cookbook pushed to the same chef server, you’re going to have conflicts when you both upload modified cookbooks with the same number. There is no way around this that fits the standard numbering schemes for chef: one of you can take a much lower build number and keep it out of the way of the other active developer, but that’s likely to cause confusion

So, I use chef-solo for small environments, I use Berkshelf to manipulate localized chef cookbook selection on each host, and I use chefdk to get Berkshelf installed consistently.

Now, if I could find and shave the yak responsible for making libgecode a requirement for Berrkshelf, I’d do so. But that code is a bit out of my personal reach to rewrite or publish fixes for.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com

From: Peter Burkholder [mailto:pburkholder@pobox.com]
Sent: Wednesday, March 25, 2015 10:12 PM
To: chef@lists.opscode.com
Subject: [chef] Re: Re: RE: Re: RE: RE: RE: Re: RE: Re: No chefdk RPM available for RHEL 5?

Hi Nico,

I hope you're not shaving the wrong yak here. ChefDK and Berkshelf are generally only needed on development systems, not on the chef-client systems. If you have RHEL6 or Ubuntu or Windows or OsX then you should be fine developing cookbooks for RHEL5 clients. Sorry if I'm missing something obvious, but are you sure you need ChefDK or Berkshelf for RHEL5, as opposed to just the chef-client?

In an earlier message you mentioned, "I’ll have to use the standard ‘chef’ client, which means that to use Berkshelf on them I’ll have to compile Berkshelf," but Berkshelf is only needed for dependency management on the development side, not on the client end of things.

--Peter

On Wed, Mar 25, 2015 at 8:54 PM Daniel DeLeo <dan@kallistec.commailto:dan@kallistec.com> wrote:

On Wednesday, March 25, 2015 at 3:12 PM, Nico Kadel-Garcia wrote:

The reluctance for the chefdk develers to directly support CentOS 5 is understandable, the ruby on it is quite out of date and insufficient for the current build tools.
I've activated a "ruby-1.9.3" cookbook on a CentOS 5 VM, and encountered adventures trying to use the bundle tool, but the CentOS 5 build chefdk RPM seems to work in my casual testing. I do have some comments.

You can use the built-in test kitchen stuff to do this, or you can reverse engineer it to get the cookbooks it uses and run them.

  • Using "bundle" to build up the chefdk toolkit the first time runs into exactly the problems the basic "chef" and "chef-server" packages have building Berkshelf. It requires extensive compilation tools, and a LOT of RAM or swap, to successfully build the "dep-selector-gem" requirement. I wound up having to add several gigabytes of swap space just to allow it to complete.
    The built-in kitchen stuff again handles this, or you can crib from it to size your build machines: https://github.com/chef/omnibus-chef/blob/master/.kitchen.yml
  • The massive resource consumption of libgecode compilation is exacerbated by the hardcoded "make -j5", which I personally consider a premature optimization. The default should, ideally, be "make -j1" which complex tests or manual settings can optimize for powerful environments: being slow on instances that could compile faster is much safer than breaking on lightweight instances. I've actually commented about this before from a different workplace, and it's one of my compelling reasons to want to simply install chefdk in the first place..
    It’s definitely not premature, we have to build it as part of the build process for ChefDK and Chef Server; getting the build down to a few minutes saves a ton of time. I’ve sketched out how to use ohai to make the build auto-detect lower resource machines, I just need someone to try it and ensure the build works. You’ve probably seen my comment about it in the pull request discussions.
  • The "bundle exec omnibus build chefdk" command uses the "Packager::RPM" tool to build the RPM on CentOS 5. Unfortunately, that tool builds only RPM's, not SRPM's. I wish I understood the tool well enough to fix that, but I don't today. That gets into security and source code management for RPM's: a build environment you construct from git, or anything else on the fly, does not necessarily bear a strong resemblance to the code used to build an earlier or later RPM, especially if the .spec file or any patches are generated dynamically. And sure enough, in this case, the .spec file is generated dynamically. So to analyze any '%post' or RPM macro controlled settings, you have to disassemble the whole RPM::Packager toolkit rather than having an SRPM to read.
    It’s all in omnibus, which saves us a ton of time by standardizing our build across platforms, as much as is possible anyway. The package scripts are here if you want to look at them: https://github.com/chef/omnibus-chef/tree/master/package-scripts/chefdk I realize this means that we’re breaking some of the platform conventions you’re used to, but without it we couldn’t support making packages for as many platforms as we do at all. You’re of course welcome to mirror all of it and build the packages yourself if you need to, and we’ll try to help if you run into any issues with that.

Overall, this looks like it's actually in reach for CentOS or RHEL 5: the key is the lack of a recent enough ruby in CentOS 5 itself to build the packages.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com (mailto:nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com)

--
Daniel DeLeo

On Thursday, March 26, 2015 at 3:12 PM, Nico Kadel-Garcia wrote:

I’ve several reasons to want chefdk on individual hosts:

· Chef servers are, from painful personal experience, bulky, expensive to host, and destabilizing to dynamic, mixed environments. A single mistaken update to a data bag for a central service, or a simple cookbook update, can take down an entire environment by screwing up every host. Particular examples include:
o Typos in ‘bind’ configuration files, for which there used to be no sanity checking and would break the ‘named’ service on restart.
o The refactoring and non-backwards-compatible update to yum, splitting off “yum::epel” recipe to a separate “yum-epel” cookbook and breaking all the old cookbooks that relied on yum::epel.
o The refactoring and non-backwards-compatible update to mysql, which went from a single MySQL instance configuration tool to an LWRP for multiple instances, and which deleted /etc/my.cnf.
· Using chef-solo on individual hosts makes them much safer to modify and update.
· chefdk is prefereable to the “chef-client” tool because already contains precompiled copies of the libgecode software, and I can pre-deploy it in a managed fashion to my chef-solo environments to manage their cookbooks individually.
o I consider the components necessary to build libgecode to be inappropriate to install on lightweight, exposed servers of any sort. (gcc and g++, in particular, are begging for trouble to install on a production server.) chefdk is therefore, much, much safer than building libgecode.
· I’d use librarian-chef instead of Berkshelf, but librarian-chef has a nasty tendency to update every depencency for your designated cookbook is unacceptable for daily use. This is unsafe, precisely because of the unexpected ‘yum’ and ‘mysql’ udpates I mentioned above.
· If you have two sysadmins developing changes on the same cookbook pushed to the same chef server, you’re going to have conflicts when you both upload modified cookbooks with the same number. There is no way around this that fits the standard numbering schemes for chef: one of you can take a much lower build number and keep it out of the way of the other active developer, but that’s likely to cause confusion

So, I use chef-solo for small environments, I use Berkshelf to manipulate localized chef cookbook selection on each host, and I use chefdk to get Berkshelf installed consistently.

Now, if I could find and shave the yak responsible for making libgecode a requirement for Berrkshelf, I’d do so. But that code is a bit out of my personal reach to rewrite or publish fixes for.

You’re right about the risk of dynamic updates of code to Chef Servers; that’s what the Policyfile feature seeks to address, and I hope you’ll give it a shot as it becomes available.

As for the other parts of your workflow, it seems like this is exactly what berks package is for.

--
Daniel DeLeo

You might experiment with Batali [0] for on-node dependency resolution.
It's still in early development, but the releases are stable, and we use it
regularly. It does least impact resolution by default, and is a fairly
lightweight gem.

If you do try it, and run into any issues or have suggests, please open a
Github Issue; we're pretty responsive!

[0] GitHub - spox/batali: Light weight cookbook resolver

--
Michael F. Weinberg | Director of Operations
http://heavywaterops.com | @heavywaterops

On Thu, Mar 26, 2015 at 3:12 PM, Nico Kadel-Garcia <
nkadel@skyhookwireless.com> wrote:

I’ve several reasons to want chefdk on individual hosts:

· Chef servers are, from painful personal experience, bulky,
expensive to host, and destabilizing to dynamic, mixed environments. A
single mistaken update to a data bag for a central service, or a simple
cookbook update, can take down an entire environment by screwing up every
host. Particular examples include:

o Typos in ‘bind’ configuration files, for which there used to be no
sanity checking and would break the ‘named’ service on restart.

o The refactoring and non-backwards-compatible update to yum, splitting
off “yum::epel” recipe to a separate “yum-epel” cookbook and breaking all
the old cookbooks that relied on yum::epel.

o The refactoring and non-backwards-compatible update to mysql, which
went from a single MySQL instance configuration tool to an LWRP for
multiple instances, and which deleted /etc/my.cnf.

· Using chef-solo on individual hosts makes them much safer to
modify and update.

· chefdk is prefereable to the “chef-client” tool because already
contains precompiled copies of the libgecode software, and I can pre-deploy
it in a managed fashion to my chef-solo environments to manage their
cookbooks individually.

o I consider the components necessary to build libgecode to be
inappropriate to install on lightweight, exposed servers of any sort. (gcc
and g++, in particular, are begging for trouble to install on a production
server.) chefdk is therefore, much, much safer than building libgecode.

· I’d use librarian-chef instead of Berkshelf, but librarian-chef
has a nasty tendency to update every depencency for your designated
cookbook is unacceptable for daily use. This is unsafe, precisely because
of the unexpected ‘yum’ and ‘mysql’ udpates I mentioned above.

· If you have two sysadmins developing changes on the same
cookbook pushed to the same chef server, you’re going to have conflicts
when you both upload modified cookbooks with the same number. There is no
way around this that fits the standard numbering schemes for chef: one of
you can take a much lower build number and keep it out of the way of
the other active developer, but that’s likely to cause confusion

So, I use chef-solo for small environments, I use Berkshelf to manipulate
localized chef cookbook selection on each host, and I use chefdk to get
Berkshelf installed consistently.

Now, if I could find and shave the yak responsible for making libgecode a
requirement for Berrkshelf, I’d do so. But that code is a bit out of my
personal reach to rewrite or publish fixes for.

Nico Kadel-Garcia

Lead DevOps Engineer

nkadel@skyhookwireless.com

From: Peter Burkholder [mailto:pburkholder@pobox.com]
Sent: Wednesday, March 25, 2015 10:12 PM
To: chef@lists.opscode.com
Subject: [chef] Re: Re: RE: Re: RE: RE: RE: Re: RE: Re: No chefdk RPM
available for RHEL 5?

Hi Nico,

I hope you're not shaving the wrong yak here. ChefDK and Berkshelf are
generally only needed on development systems, not on the chef-client
systems. If you have RHEL6 or Ubuntu or Windows or OsX then you should be
fine developing cookbooks for RHEL5 clients. Sorry if I'm missing something
obvious, but are you sure you need ChefDK or Berkshelf for RHEL5, as
opposed to just the chef-client?

In an earlier message you mentioned, "I’ll have to use the standard ‘chef’
client, which means that to use Berkshelf on them I’ll have to compile
Berkshelf," but Berkshelf is only needed for dependency management on the
development side, not on the client end of things.

--Peter

On Wed, Mar 25, 2015 at 8:54 PM Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, March 25, 2015 at 3:12 PM, Nico Kadel-Garcia wrote:

The reluctance for the chefdk develers to directly support CentOS 5 is
understandable, the ruby on it is quite out of date and insufficient for
the current build tools.
I've activated a "ruby-1.9.3" cookbook on a CentOS 5 VM, and encountered
adventures trying to use the bundle tool, but the CentOS 5 build chefdk RPM
seems to work in my casual testing. I do have some comments.

You can use the built-in test kitchen stuff to do this, or you can reverse
engineer it to get the cookbooks it uses and run them.

  • Using "bundle" to build up the chefdk toolkit the first time runs into
    exactly the problems the basic "chef" and "chef-server" packages have
    building Berkshelf. It requires extensive compilation tools, and a LOT of
    RAM or swap, to successfully build the "dep-selector-gem" requirement. I
    wound up having to add several gigabytes of swap space just to allow it to
    complete.
    The built-in kitchen stuff again handles this, or you can crib from it to
    size your build machines:
    https://github.com/chef/omnibus-chef/blob/master/.kitchen.yml
  • The massive resource consumption of libgecode compilation is
    exacerbated by the hardcoded "make -j5", which I personally consider a
    premature optimization. The default should, ideally, be "make -j1" which
    complex tests or manual settings can optimize for powerful environments:
    being slow on instances that could compile faster is much safer than
    breaking on lightweight instances. I've actually commented about this
    before from a different workplace, and it's one of my compelling reasons to
    want to simply install chefdk in the first place..
    It’s definitely not premature, we have to build it as part of the build
    process for ChefDK and Chef Server; getting the build down to a few minutes
    saves a ton of time. I’ve sketched out how to use ohai to make the build
    auto-detect lower resource machines, I just need someone to try it and
    ensure the build works. You’ve probably seen my comment about it in the
    pull request discussions.
  • The "bundle exec omnibus build chefdk" command uses the
    "Packager::RPM" tool to build the RPM on CentOS 5. Unfortunately, that tool
    builds only RPM's, not SRPM's. I wish I understood the tool well enough to
    fix that, but I don't today. That gets into security and source code
    management for RPM's: a build environment you construct from git, or
    anything else on the fly, does not necessarily bear a strong resemblance to
    the code used to build an earlier or later RPM, especially if the .spec
    file or any patches are generated dynamically. And sure enough, in this
    case, the .spec file is generated dynamically. So to analyze any '%post' or
    RPM macro controlled settings, you have to disassemble the whole
    RPM::Packager toolkit rather than having an SRPM to read.
    It’s all in omnibus, which saves us a ton of time by standardizing our
    build across platforms, as much as is possible anyway. The package scripts
    are here if you want to look at them:
    https://github.com/chef/omnibus-chef/tree/master/package-scripts/chefdk I
    realize this means that we’re breaking some of the platform conventions
    you’re used to, but without it we couldn’t support making packages for as
    many platforms as we do at all. You’re of course welcome to mirror all of
    it and build the packages yourself if you need to, and we’ll try to help if
    you run into any issues with that.

Overall, this looks like it's actually in reach for CentOS or RHEL 5:
the key is the lack of a recent enough ruby in CentOS 5 itself to build the
packages.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com (mailto:nkadel@skyhookwireless.com)

--
Daniel DeLeo

If I use 'berks package', or 'Policyfile', I only get control of cookbooks. By using chefdk and locally controlled chef-solo setups, with centralized git management, I also get the vital control of node configurations, data bags, roles, and if necessary environments. So I'm afraid I don't see any practical use for those tools in a small environment, unless I really need to have some out of band cookbook deployment method. I get the equivalent of "Policyfile" by doing my Berksfile work in git, working in branches, and pushing changes upstream as needed.

Nico Kadel-Garcia
Lead DevOps Engineer
nkadel@skyhookwireless.com

-----Original Message-----
From: Daniel DeLeo [mailto:ddeleo@kallistec.com] On Behalf Of Daniel DeLeo

You’re right about the risk of dynamic updates of code to Chef Servers; that’s
what the Policyfile feature seeks to address, and I hope you’ll give it a shot as it
becomes available.

As for the other parts of your workflow, it seems like this is exactly what berks package is for.

--
Daniel DeLeo

On Thursday, March 26, 2015 at 4:08 PM, Nico Kadel-Garcia wrote:

If I use 'berks package', or 'Policyfile', I only get control of cookbooks. By using chefdk and locally controlled chef-solo setups, with centralized git management, I also get the vital control of node configurations, data bags, roles, and if necessary environments. So I'm afraid I don't see any practical use for those tools in a small environment, unless I really need to have some out of band cookbook deployment method. I get the equivalent of "Policyfile" by doing my Berksfile work in git, working in branches, and pushing changes upstream as needed.

Nico Kadel-Garcia
Policyfiles also control your node configurations, but that’s a topic for another thread.

--
Daniel DeLeo