[chef] Re: Re: Re: Re: new cookbook: authconfig for RHEL/CentOS/compat


Chronological Thread 
  • From: Jesse Campbell < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: new cookbook: authconfig for RHEL/CentOS/compat
  • Date: Sat, 21 Jan 2012 18:08:36 -0500

hmm. well that is somewhat unexpected.

Which linux are you running?
Sorry, I had only tested this on centos 6.1, and i hadn't expanded
testing beyond that yet...

try taking a look at /etc/authconfig/arguments and see if all your
variables ended up in there correctly...
also, try running the authconfig command by itself with no arguments
at all... it should list off all of the possible command line
arguments, and maybe there are some unsupported ones...

which makes me think I may need a more robust way to check which
arguments are supported by authconfig besides just checking the node's
distribution version.

-Jesse

On Sat, Jan 21, 2012 at 18:01, RILINDO FOSTER 
< >
 wrote:
> That sort of got me further.
>
> I added the following in the recipe file:
>
> include_recipe "authconfig"
>
> Which does not appear to have any effect. Then I add the authconfig in the
> run list first:
>
> stardust:cookbooks rilindo$ knife node run_list add ldaptls
> "recipe[authconfig::ldapauthtls]"
> run_list:
>     recipe[chef-client]
>     recipe[ohai]
>     recipe[authconfig]
>     recipe[authconfig::ldapauthtls]
>
> And that did it. However, restarting chef-client again returns the
> following:
>
> [Sat, 21 Jan 2012 17:53:25 -0500] INFO: Processing
> execute[authconfig-update] action run (authconfig::default line 23)
> [Sat, 21 Jan 2012 17:53:25 -0500] INFO: execute[authconfig-update]
> sh(/bin/cat /etc/authconfig/arguments | /usr/bin/xargs /usr/sbin/authconfig
> --update)
> [Sat, 21 Jan 2012 17:53:29 -0500] FATAL: SIGTERM received, stopping
> [Sat, 21 Jan 2012 17:53:29 -0500] ERROR: Running exception handlers
> [Sat, 21 Jan 2012 17:53:30 -0500] FATAL: Saving node information to
> /var/chef/cache/failed-run-data.json
> [Sat, 21 Jan 2012 17:53:30 -0500] ERROR: Exception handlers complete
>
>
> Looking at the run file, I see:
>
>   "exception": "SystemExit: exit",
>   "backtrace": [
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/application.rb:143:in
> `exit'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/application.rb:143:in
> `fatal!'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/application.rb:35:in
> `block in initialize'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shell_out/unix.rb:31:in
> `call'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shell_out/unix.rb:31:in
> `select'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shell_out/unix.rb:31:in
> `run_command'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shell_out.rb:180:in
> `run_command'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/mixin/shell_out.rb:30:in
> `shell_out'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/mixin/shell_out.rb:35:in
> `shell_out!'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/provider/execute.rb:58:in
> `action_run'",
>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/resource.rb:440:in
> `run_action'",
>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/runner.rb:45:in
> `run_action'",
>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/runner.rb:53:in
> `block in run_action'",
>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/runner.rb:51:in
> `each'",
>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/runner.rb:51:in
> `run_action'",
>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/runner.rb:81:in
> `block (2 levels) in converge'",
>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/runner.rb:81:in
> `each'",
>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/runner.rb:81:in
> `block in converge'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/resource_collection.rb:94:in
> `block in execute_each_resource'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/resource_collection/stepable_iterator.rb:116:in
> `call'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/resource_collection/stepable_iterator.rb:116:in
> `call_iterator_block'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/resource_collection/stepable_iterator.rb:85:in
> `step'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/resource_collection/stepable_iterator.rb:104:in
> `iterate'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/resource_collection/stepable_iterator.rb:55:in
> `each_with_index'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/resource_collection.rb:92:in
> `execute_each_resource'",
>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/runner.rb:76:in
> `converge'",
>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/client.rb:312:in
> `converge'",
>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/client.rb:160:in
> `run'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/application/client.rb:239:in
> `block in run_application'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/application/client.rb:229:in
> `loop'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/application/client.rb:229:in
> `run_application'",
>
> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/application.rb:67:in
> `run'",
>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/bin/chef-client:26:in `<top
> (required)>'",
>     "/usr/bin/chef-client:19:in `load'",
>     "/usr/bin/chef-client:19:in `<main>'"
>   ]
> }[
>
>
> I am going to expose my inexperience with chef and say that I am not sure if
> this the right way to go. If the preferable way is to set through the role
> or node attributes (although I am not sure how to do the latter), then I'll
> do that instead.  :)
>
>  - Rilindo
>
>
> On Jan 21, 2012, at 5:42 PM, Jesse Campbell wrote:
>
> Hmm...
> I usually set the overrides on the chef server through role or node
> attributes, i haven't before tried to set them on the node directly with a
> file... Though it may work regardless.
> You may need to include the authconfig default recipe ( recipe[authconfig] )
>
> On Jan 21, 2012 5:24 PM, "RILINDO FOSTER" 
> < >
>  wrote:
>>
>> Testing it out, I set the attributes as such in a recipe file:
>>
>> stardust:recipes rilindo$ more ldapauthtls.rb
>> node.override['authconfig']['sssd']['enable'] = true
>> node.override['authconfig']['ldap']['enable'] = true
>> node.override['authconfig']['ldap']['tls'] = true
>> node.override['authconfig']['ldap']['server'] = 'kerberos.example.com'
>> node.override['authconfig']['ldap']['basedn'] = 'dc=example,dc=com'
>> node.override['authconfig']['ldap']['auth'] = true
>> node.override['authconfig']['ldap']['cacerturl'] =
>> 'http://192.168.15.100/mirrors/ks/keys/cacert.pem'
>>
>> And added it in:
>>
>>
>> stardust:recipes rilindo$ knife node run_list add ldaptls
>> "recipe[authconfig::ldapauthtls]"
>> run_list:
>>    recipe[chef-client]
>>    recipe[ohai]
>>    recipe[authconfig::ldapauthtls]
>>
>> And restarted chef-client on my test node. So far, it didn't set the
>> configs as intended.
>>
>> Perhaps it is my inexperience with chef getting in the way, but is this
>> the right way to set it up?
>>
>> - Rilindo
>>
>> On Jan 21, 2012, at 12:45 PM, Jesse Campbell wrote:
>>
>> I was looking for a cookbook to manage ldap configuration on centos
>> 6.1 vms that I'd spun up, as well as our other 300-odd centos 5.5 vms.
>>
>> First looked at the openldap cookbook and wasn't terribly impressed...
>> it has lots of dependencies on debian locations of things that I'd
>> have to mess about with to make it work with centos.
>>
>> Authconfig is a built-in CLI for managing auth configuration, be it
>> for ldap, winbind, kerberos, nis, etc. It automagically updates all of
>> the required files, using the new SSSD subsystem on EL6 systems.
>> Rather than reinventing that wheel, I decided to take advantage of the
>> built-in and call out to it from chef.
>>
>> There was no method i found for telling authconfig to pull the
>> configuration from a file, so instead I build out an arguments list
>> from node attributes. If the file changes, it will re-run authconfig,
>> so it is idempotent.
>> The defaults follow what came on a bare centos 6.1 system, but should
>> work with others.
>>
>> Current issue:
>> the functionality to tell winbind to join a domain is not included, it
>> seemed to need an admin user specified, and likely would prompt for a
>> password. Not having a domain server to test against, I did not have
>> any way to find out.
>>
>http://community.opscode.com/cookbooks/authconfig
>>
>> I have only tested this on CentOS 6 so far, but would appreciate if
>> anyone else tries it to let me know if it works, or bugs they run
>> into...
>>
>> Thanks!
>> -Jesse
>>
>>
>



Archive powered by MHonArc 2.6.16.

§