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

[RILINDO FOSTER < >]

Okay. I now reset the run list on the new server like so:

stardust:~ rilindo$ knife node run_list add ldaptls2 "recipe[authconfig]"
run_list: 
    recipe[chef-client]
    recipe[ohai]
    recipe[authconfig::ldapauthtls]
    recipe[authconfig]

That appear to address the earlier. I am not sure why changing the order 
would make a difference.

Now that it looks like it works on my CentOS 6, I'll test it on 5 next. :)

 - Rilindo

On Jan 21, 2012, at 6:32 PM, RILINDO FOSTER wrote:

> Yep. I am able to successfully authenticate. It is the same config values I 
> used in my kickstart file, so it worked once I got the recipe to be 
> recognized.
> 
> I'll build out another CentOS machine (I run a very underpowered KVM host 
> at home, so I can do that. :) ) and try out your suggestion. Stay tuned.
> 
> - Rilindo
> 
> 
> On Jan 21, 2012, at 6:25 PM, Jesse Campbell wrote:
> 
>> 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
>>>>>> 
>>>>>> 
>>>>> 
>>> 
>