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

[RILINDO FOSTER < >]

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
>>>>> 
>>>>> 
>>>> 
>>