New cookbook: authconfig for RHEL/CentOS/compat

Chef Infra (archive)
1

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

2

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

3

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

4

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. :slight_smile:

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

5

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 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. :slight_smile:

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

6

Its a fresh build of CentOS, newly build made especially for your cookbook. :slight_smile: 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'

[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 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. :slight_smile:

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

7

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

Its a fresh build of CentOS, newly build made especially for your cookbook. :slight_smile: 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'

[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 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. :slight_smile:

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

8

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. :slight_smile: ) 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 wrote:

Its a fresh build of CentOS, newly build made especially for your cookbook. :slight_smile: 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'

[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 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. :slight_smile:

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

9

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. :slight_smile:

  • 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. :slight_smile: ) 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 wrote:

Its a fresh build of CentOS, newly build made especially for your cookbook. :slight_smile: 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'

[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 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. :slight_smile:

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