andi abes | 24 Jul 15:55 2014
Picon

knife ec2 create - equivalent of iam-instance-profile

Ohai,

  Trying to find a way to attach an instance-profile at boot time. I'm not finding anything that would do that on knife ec2 server create.
Any pointers appreciated.

Stephen Corbesero | 24 Jul 15:27 2014

How tdo I configure the ssl to make the chef client and server happy

 

I am setting up a chef server for a project in AWS, and I am trying to find the best way to make the server and client happy wrt the ssl settings.

 

I want to do the following.

 

·        Create a chef server with a private IP address and a public (elastic) IP address.

·        I want to use chef01.some.dom.com as the DNS/hostname for the private IP address, and I want to use chef01-eip.some.dom.com as the DNS for the public IP address,  AND I want to create  a CNAME of just chef.some.dom.com which I will use as the name of the chef server in the client.rb files.

 

When I do that, the ssl checking fails.  The name of the server in client.rb (che.some.dom.com) does not match the name on the certificate, which was generated with the machines hostname, chef01.some.dom.com.

 

I try to outsmart the “chef-server-ctl reconfigure” command by temporarily changing the host name to my CNAME (chef.some.dom.com).  Well, chef-server-ctl  is too clever for me.  It does a DNS lookup and finds the actual name associated with the address so it now generates a certificate with name chef01-eip.some.dom.com. 

 

What should I be doing?  I am perfectly happy with the self-generated certificate.

 

On a related note, will I also have to copy that cert to the trusted_certs/ directory on all the clients?

 

 

 

--

Stephen Corbesero, DevOps Engineer

Synchronoss - Mobile Innovation for a Connected World

stephen.corbesero <at> synchronoss.com | www.synchronoss.com

 

Custom LWRP Initialise Error

Morning Guys

 

Got a question about LWRP’s.  I’m writing a library cookbook and testing components of it as I go.

I’ve written an LWRP to perform a dll drop on a server.

Everything seems ok, I’ve done a lot of reading online about this and managed to narrow it down to this last error.

The error is:

“[2014-07-24T06:59:57-04:00] FATAL: NameError: AW_DLLDrop_dlldrop[7.1_HF05_Overlay_SAML_fix.zip] (AW_DLLDrop::default line 25) had an error: NameError: uninitialized constant Chef::Resource::DllDrop”

 

The code from the LWRP in question is:

“    

      def whyrun_supported?

        true

      end

     

      action :drop do

        converge_by("Drop #{ <at> new_resource}") do

          perform_dll_drop

        end

      end

     

      action :undo do

        converge_by("Undo #{ <at> new_resource}") do

          undo_dll_drop

        end

      end

     

      def load_current_resource

        <at> current_resource = Chef::Resource::DllDrop.new( <at> new_resource.name)

        <at> current_resource.name( <at> new_resource.name)

      end”

 

Can anyone shed any light on what I’m missing with this?  One of my colleagues has pointed out that there may be an issue with <at> new_resource.name retuning null?  Any way I can check this?

 

Any pointers would be great as I’m struggling a little with this.

 

Thanks

Chris

Seth Vargo | 23 Jul 19:28 2014

Omnibus v3.2.0

Ohai Chefs,

After 3 release candidates, I am excited to announce that omnibus v3.2.0 has hit the shelves!

Here is the high-level changeset. For a complete listing, you can review the full diff here: https://github.com/opscode/omnibus/compare/v3.1.1...v3.2.0

- Make build commands output during `log.info` instead of `log.debug`
- Refactor Chef Sugar into an includable module, permitting DSL methods in both Software and Project definitions
- Refactor `omnibus release` into a non-S3-specific backend "publisher"
- Add support for specifying a dir glob to the `publish` command to upload multiple packages
- "Package" is now a public API
- Generate a real omnibus configuration file (no more `omnibus.rb.example`)
- Add a releaser for Artifactory
- Add additional information to package metdata (such as shasums)
- Remove uses of Omnibus.config and use the Config object directly
- Add the ability to define multiple `software_gems` in the config
- Add the ability to define `local_software_paths` in the config
- Add the ability to disable git caching in the config
- Omnibus.load_configuration now requires a file path
- Add new API for loading a project - `Project.load`
- Add new API for loading a software - `Software.load`
- Add publish APIs for dirtying the git cache
- Add test coverage for the "public" API
- Add validation to `source` in software DSL
- Add logging to the Packager class
- Add functional tests for builders
- Update generator templates to use the new APIs
- Upgrade to Ohai 7.2
- Improve YARDoc

### Deprecations
- Remove deprecated `Omnibus.configure` method
- Deprecate `Omnibus.config.value` in favor of `Config.value` instead
- Deprecate `Omnibus.project_root` in favor of `Config.project_root`
- Deprecate [DSL] `platform` in favor of `Ohai['platform']`
- Deprecate [DSL] `platform_family` in favor of `Ohai['platform_family']`
- Deprecate [DSL] `platform_version` in favor of `Ohai['platform_version']`
- Deprecate [DSL] `build_dir` in favor of `Config.build_dir`
- Deprecate [DSL] `cache_dir` in favor of `Config.cache_dir`
- Deprecate [DSL] `source_dir` in favor of `Config.source_dir`
- Deprecate [DSL] `config` in favor of `Config` (capitalized)
- Deprecate `Ohai.value` in favor of `Ohai['value']`
- Deprecate `Project#install_path` in favor of `Project.install_dir`
- Deprecate [DSL] `install_path` in favor of `install_dir`
- Rename `Config.install_path_cache_dir` to `git_cache_dir`
- Fix a bug in the deprecations where a hardcoded output was used instead of a dynamic variable

### DSL Changes
- Add `with_embedded_path` to software
- Add `with_standard_compiler_flags` to software
- Add `package_scripts_path` to project
- Add builder DSL methods for `mkdir`, `touch`, `delete`, `copy`, `move`, `link`, and `sync`

### Bug fixes
- Fix a small typo in the project generator (come -> some)
- Update sample software definition for libpng to 1.5.18
- Improved logging output
- Include Chef Sugar in both software and project DSLs
- Documentation updates and typographical fixes
- Change the generated omnibus.rb to use a default homepage that includes the protocol
- Ensure that software fetched via the PathFetcher are cached correctly
- Downgrade FPM to ~> 0.4 - FPM 1.0.0+ uses FFI to attach to some libc functions. This fails on RHEL 5 & 6. As we don’t need a bleeding edge FPM the easiest fix is to just downgrade to the most recent pre-1.0.0 version.
- Always print backtraces when errors occur
- Do not sent ldd/otool to the same file - first steps in allowing parallel builds
- Only rescue `Omnibus::Error` when invoked through the CLI - this will allow other bugs to actually raise at the Ruby level
- Refactor the algorithm for git caching to take into account overrides and missing versions
- Remove nested git directories before incremental caching occurs
- Intelligently parse the project's homepage because Ruby's native URI implementation is buggy
- Fetch all software at the start of the build - this fixes a bug where a build would fail halfway through because of a tiny typo of GitHub outage. Now, all required software is downloaded **before** the build starts, lowering the feedback time for a failure due to networking issues
- Use the fetcher's `version_for_cache` method directly, falling back to `0.0.0` (and a warining) if no version is given
- Require `net/http`, `net/https`, and `net/ftp` in the base fetcher module
- Use -R, not -W1 on FreeBSD's compile flags
- Expand all paths relative to the project_root
- Unset all Ruby, Bundler, amd Gem-related environment variables before shelling out
- Various documentation fixes and updates

### Potentially breaking changes
- Merged `Package` and `Artifact` into the same class and updated API - this was considered an **internal** API so it is not a violation of semver
- Use a common class for Omnibus exceptions - if you were rescuing Omnibus::Error, you might be rescuing all exceptions now
- Use a cleanroom object when evaluating the DSL - prior to this release, Omnibus did not declare a public API. Project and software definitions had unrestricted access to the entire project.rb and software.rb methods respectively. This poses two problems - first, it makes it impossible to guarantee a public DSL API over a public (code) API. Second, it permits a developer to change the behavior of project.rb or software.rb accidentially, simply by defining a new method. The introducing of a cleanroom fixes both these bugs, however, it was impossible to know what was formerly considered a public API. Thus, it is possible that a previously-relied-on method is now unavaiable using the cleanroom. Please open an issue if you encounter such a case.
- Remove mixlib-config - if you were relying on mixlib-config as a transitive dependency, it is no longer available
- Remove the ability to use an overrides file - this was for internal use only and was never exposed as a public API. However, if you dug into the code and found it, it has now been removed. For BC purposes, the value still exists in the configuration object, but is essentially a no-op
- Move project loading from INFO to DEBUG
- Truncate platforms to short versions
- All paths are represented internally as Unix-style paths - previously Omnibus would try to intelligently build your paths differently on Windows for the purposes of shelling out to the system. This proved to be unmaintainable and makes Ruby very unhappy in most circumsatances. As such, we have exposed the `windows_safe_path` method in the Builder DSL that will convert a string to a "Windows-safe path". This is only needed when shelling out to the system.

There are a number of new and awesome changes, as well as some "potentially breaking changes". Please review the changelog carefully and upgrade in an isolated environment first.

As an added bonus, omnibus-ruby is now dead! That's right, the repository now lives at opscode/omnibus to alleviate any confusion. The old clojure repo has been retained in a branch for historical purposes, but is no longer supported.

If you experience any problems, please open an issue on the GitHub repository (https://github.com/opscode/omnibus/issues).

Happy Bussing,
Seth
<at> sethvargo
Attachment (smime.p7s): application/pkcs7-signature, 6609 bytes
Phillip Roberts | 23 Jul 19:09 2014

RE: Ohai Chefs! - Template writing issue.

I apologize ahead of time for the subject line. I hit send before I should have :P

 

Thanks,

 

Phillip Roberts | Sr. Linux Systems Administrator

MyBuys - Know Every Consumer

O 734.922.7014| M 614.423.9871 | proberts <at> mybuys.com

<at> MyBuys | LinkedIn | Facebook

 

 

From: Phillip Roberts [mailto:proberts <at> mybuys.com]
Sent: Wednesday, July 23, 2014 1:08 PM
To: chef <at> lists.opscode.com
Subject: [chef] Ohai Chefs!

 

Is there a way to make a recipe only write a template file if the file doesn’t exist or if the template has changed?

 

For instance, I have a recipe that generates zone files for bind based off of a list of domains in a data bag. However, on every chef-client run, it is regenerating the file, which is also regenerating the serial number.

 

Any assistance would be appreciated.

 

Thanks,

 

Phillip Roberts | Sr. Linux Systems Administrator

MyBuys - Know Every Consumer

O 734.922.7014| M 614.423.9871 | proberts <at> mybuys.com

<at> MyBuys | LinkedIn | Facebook

 

 

Phillip Roberts | 23 Jul 19:07 2014

Ohai Chefs!

Is there a way to make a recipe only write a template file if the file doesn’t exist or if the template has changed?

 

For instance, I have a recipe that generates zone files for bind based off of a list of domains in a data bag. However, on every chef-client run, it is regenerating the file, which is also regenerating the serial number.

 

Any assistance would be appreciated.

 

Thanks,

 

Phillip Roberts | Sr. Linux Systems Administrator

MyBuys - Know Every Consumer

O 734.922.7014| M 614.423.9871 | proberts <at> mybuys.com

<at> MyBuys | LinkedIn | Facebook

 

 

Jeremy Bingham | 23 Jul 18:51 2014
Picon

goiardi 0.7.0 "Orphans of the Sky" released, implementing Chef RFC 014

Astute readers of old science fiction will remember that the novella that makes up the first part of Robert A. Heinlein's novel "Orphans of the Sky" is titled "Universe".

Aside from some bug fixes with making file uploading and cookbook metadata checking a little more forgiving, this release adds support for the Berkshelf /universe endpoint. This was originally going to be a small update, but testing with the full complement of cookbooks from the Supermarket revealed that goiardi was running like a dog with 6200+ cookbooks trying to use the same functions designed for fetching one cookbook in in-memory mode. Sensible enough, but it also turned out that while golang's gob encoding is almost always faster than JSON encoding it is NOT the case when encoding complex data structures found in cookbooks, nodes, etc.

Thus, this version of goiardi introduces another breaking change: complex data structures in the database are now stored with JSON instead of gob encoding. You have to export your data, do a sqitch revert and deploy (or drop the database and load the schema dump), and import your data again if you're using one of the SQL backends. While a little painful, it leads to a good result; if you're using Postgres as a datastore, goiardi's able to take advantage of Postgres specific goodies with JSON and load the universe with all the supermarket cookbooks in ~325-350 milliseconds. MySQL can't take advantage of the JSON goodies, so it takes about 1 second to serve up the full supermarket, and in-memory takes about 1.2 seconds. If you have that many cookbooks, I would recommend using Postgres.


-j
Stewart, Curtis | 23 Jul 18:36 2014

Chef Search Returns nil entry

Using the Chef::Search::Query class, a search for all nodes returns the same nodes as "knife search node '*:*'" as well as what's displayed in the web ui, however, it also returns a single nil entry.


Is there anyway to clean this up?


Thanks,

Curtis
--
 
Curtis Stewart

Consultant
m 217.390.5067

Skype cstewart8710
cstewart <at> momentumsi.com

www.momentumsi.com



Cloud Migration - Architecture - DevOps - Big Data - App Dev


Julian C. Dunn | 23 Jul 05:16 2014

Platform support RFC

Folks,

As we've had a fair amount of confusion around which OSes and what
versions of those OSes are supported by Chef Client, Chef Server,
ChefDK, etc. I've put together a public RFC to clarify this. Please
review it and leave comments inline on the PR if you are interested.

https://github.com/opscode/chef-rfc/pull/21

- Julian

--

-- 
[ Julian C. Dunn <jdunn <at> 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       ]

anasofia1072 | 22 Jul 12:57 2014
Picon

[chef-client] how to create a client without root permissions

Hello,

I m trying to create a client, that runs SLES 11, with non-root permission.
I use de knife bootstrap to create the nodes, but in this situation it does t
seems correct. because it need the user to be root.

Can someone guide me on how to do this.

Thank you

Anton Koldaev | 22 Jul 12:22 2014
Picon

Which redis cookbook to use

Hi there,

We want to switch from self-written redis cookbook to a better one having LWRP's and sentinel support. Can someone recommend the best cookbook to use?

Here's what I found:
  1. https://github.com/miah/chef-redis - has sentinel support, but has not been updated for a while and has a bunch of open issues/bugs
  2. https://github.com/opscode-cookbooks/oc-redis - from opscode, but only one commit and no activity, is anyone using it?
  3. https://github.com/brianbianco/redisio - looks similar to chef-redis, not much activity, a bunch of open issues and no sentinel support
  4. https://supermarket.getchef.com/cookbooks/redis - I was unable to find it's source



--
Best regards,
Koldaev Anton

Gmane