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

[Jesse Campbell < >]

hmm okay...
i'm still confused by the error message though...
perhaps the include i the ldapauthtls.rb caused it to run the
authconfig recipe twice? perhaps remove the include_recipe, and change
the run_list order so that your ldapauthtls.rb comes first... that is
all I can think of.

Does it work? is it connecting to your ldap server?

On Sat, Jan 21, 2012 at 18:17, RILINDO FOSTER 
<
 >
 wrote:
> Its a fresh build of CentOS, newly build made especially for your cookbook. 
> :) And it appears all the variables have been set correctly in authconfig:
>
> stardust:cookbooks rilindo$ more authconfig/recipes/ldapauthtls.rb
> include_recipe "authconfig"
>
> 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'
>
> 
 
>  sysconfig]# cat authconfig
> USEMKHOMEDIR=no
> USEPAMACCESS=no
> CACHECREDENTIALS=yes
> USESSSDAUTH=no
> USESHADOW=yes
> USEWINBIND=no
> PASSWDALGORITHM=sha512
> FORCELEGACY=no
> USEFPRINTD=no
> USEHESIOD=no
> FORCESMARTCARD=no
> USEDB=no
> USELDAPAUTH=yes
> USELDAP=yes
> USECRACKLIB=yes
> USEWINBINDAUTH=no
> USESMARTCARD=no
> USELOCAUTHORIZE=yes
> USENIS=no
> USEKERBEROS=no
> USESYSNETAUTH=no
> USESSSD=yes
> USEPASSWDQC=no
>
> It is important that it did work. The configuration stayed idempotent even 
> after that error. I just not sure if I doing it right by using a recipe to 
> override the node attribute.
>
>  - Rilindo
>
> On Jan 21, 2012, at 6:08 PM, Jesse Campbell wrote:
>
>> 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
>>>>
>>>>
>>>
>