# New cookbook: authconfig for RHEL/CentOS/compat

**URL:** <https://discourse.chef.io/t/new-cookbook-authconfig-for-rhel-centos-compat/2370>\
**Category:** Chef Infra (archive)\
**Created:** [January 21, 2012, 5:45pm UTC](https://discourse.chef.io/t/new-cookbook-authconfig-for-rhel-centos-compat/2370 "2012-01-21T17:45:10Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jesse\_Campbell](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jesse_campbell/32/251_2.png) [@Jesse\_Campbell](https://discourse.chef.io/u/Jesse_Campbell)\
**Post date:** [January 21, 2012, 5:45pm UTC](https://discourse.chef.io/t/new-cookbook-authconfig-for-rhel-centos-compat/2370/1 "2012-01-21T17:45:10Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Rilindo\_Foster](https://avatars.discourse-cdn.com/v4/letter/r/46a35a/32.png) [@Rilindo\_Foster](https://discourse.chef.io/u/Rilindo_Foster)\
**Post date:** [January 21, 2012, 10:24pm UTC](https://discourse.chef.io/t/new-cookbook-authconfig-for-rhel-centos-compat/2370/2 "2012-01-21T22:24:00Z")

</div>

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](http://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](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](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

---

<div class="post-metadata">

**Author:** ![Jesse\_Campbell](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jesse_campbell/32/251_2.png) [@Jesse\_Campbell](https://discourse.chef.io/u/Jesse_Campbell)\
**Post date:** [January 21, 2012, 10:42pm UTC](https://discourse.chef.io/t/new-cookbook-authconfig-for-rhel-centos-compat/2370/3 "2012-01-21T22:42:08Z")

</div>

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" [rilindo@mac.com](mailto:rilindo@mac.com) 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](http://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](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](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

---

<div class="post-metadata">

**Author:** ![Rilindo\_Foster](https://avatars.discourse-cdn.com/v4/letter/r/46a35a/32.png) [@Rilindo\_Foster](https://discourse.chef.io/u/Rilindo_Foster)\
**Post date:** [January 21, 2012, 11:01pm UTC](https://discourse.chef.io/t/new-cookbook-authconfig-for-rhel-centos-compat/2370/4 "2012-01-21T23:01:41Z")

</div>

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 `'"  
]  
}[

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" [rilindo@mac.com](mailto:rilindo@mac.com) 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](http://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](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](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

---

<div class="post-metadata">

**Author:** ![Jesse\_Campbell](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jesse_campbell/32/251_2.png) [@Jesse\_Campbell](https://discourse.chef.io/u/Jesse_Campbell)\
**Post date:** [January 21, 2012, 11:08pm UTC](https://discourse.chef.io/t/new-cookbook-authconfig-for-rhel-centos-compat/2370/5 "2012-01-21T23:08:36Z")

</div>

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 [rilindo@mac.com](mailto:rilindo@mac.com) 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 `'"  
> ]  
> }[
> 
> 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" [rilindo@mac.com](mailto:rilindo@mac.com) 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](http://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](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](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

---

<div class="post-metadata">

**Author:** ![Rilindo\_Foster](https://avatars.discourse-cdn.com/v4/letter/r/46a35a/32.png) [@Rilindo\_Foster](https://discourse.chef.io/u/Rilindo_Foster)\
**Post date:** [January 21, 2012, 11:17pm UTC](https://discourse.chef.io/t/new-cookbook-authconfig-for-rhel-centos-compat/2370/6 "2012-01-21T23:17:54Z")

</div>

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](http://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](http://192.168.15.100/mirrors/ks/keys/cacert.pem)'

[root@ldaptls 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 [rilindo@mac.com](mailto:rilindo@mac.com) 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 `'"  
> > ]  
> > }[
> > 
> > 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" [rilindo@mac.com](mailto:rilindo@mac.com) 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](http://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](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](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

---

<div class="post-metadata">

**Author:** ![Jesse\_Campbell](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jesse_campbell/32/251_2.png) [@Jesse\_Campbell](https://discourse.chef.io/u/Jesse_Campbell)\
**Post date:** [January 21, 2012, 11:25pm UTC](https://discourse.chef.io/t/new-cookbook-authconfig-for-rhel-centos-compat/2370/7 "2012-01-21T23:25:50Z")

</div>

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 [rilindo@mac.com](mailto:rilindo@mac.com) 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](http://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](http://192.168.15.100/mirrors/ks/keys/cacert.pem)'
> 
> [root@ldaptls 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 [rilindo@mac.com](mailto:rilindo@mac.com) 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 `'"  
> > > ]  
> > > }[
> > > 
> > > 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" [rilindo@mac.com](mailto:rilindo@mac.com) 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](http://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](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](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

---

<div class="post-metadata">

**Author:** ![Rilindo\_Foster](https://avatars.discourse-cdn.com/v4/letter/r/46a35a/32.png) [@Rilindo\_Foster](https://discourse.chef.io/u/Rilindo_Foster)\
**Post date:** [January 21, 2012, 11:32pm UTC](https://discourse.chef.io/t/new-cookbook-authconfig-for-rhel-centos-compat/2370/8 "2012-01-21T23:32:37Z")

</div>

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 [rilindo@mac.com](mailto:rilindo@mac.com) 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](http://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](http://192.168.15.100/mirrors/ks/keys/cacert.pem)'
> > 
> > [root@ldaptls 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 [rilindo@mac.com](mailto:rilindo@mac.com) 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 `'"  
> > > > ]  
> > > > }[
> > > > 
> > > > 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" [rilindo@mac.com](mailto:rilindo@mac.com) 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](http://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](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](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

---

<div class="post-metadata">

**Author:** ![Rilindo\_Foster](https://avatars.discourse-cdn.com/v4/letter/r/46a35a/32.png) [@Rilindo\_Foster](https://discourse.chef.io/u/Rilindo_Foster)\
**Post date:** [January 22, 2012, 4:36am UTC](https://discourse.chef.io/t/new-cookbook-authconfig-for-rhel-centos-compat/2370/9 "2012-01-22T04:36:06Z")

</div>

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 [rilindo@mac.com](mailto:rilindo@mac.com) 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](http://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](http://192.168.15.100/mirrors/ks/keys/cacert.pem)'
> > > 
> > > [root@ldaptls 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 [rilindo@mac.com](mailto:rilindo@mac.com) 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 `'"  
> > > > > ]  
> > > > > }[
> > > > > 
> > > > > 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" [rilindo@mac.com](mailto:rilindo@mac.com) 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](http://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](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](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