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

[RILINDO FOSTER < >]

Its a fresh build of CentOS, newly build made especially for your cookbook. 
:) And it appears all the variables have been set correctly in authconfig:

stardust:cookbooks rilindo$ more authconfig/recipes/ldapauthtls.rb 
include_recipe "authconfig"

node.override['authconfig']['sssd']['enable'] = true
node.override['authconfig']['ldap']['enable'] = true
node.override['authconfig']['ldap']['tls'] = true
node.override['authconfig']['ldap']['server'] = 'kerberos.example.com'
node.override['authconfig']['ldap']['basedn'] = 'dc=example,dc=com'
node.override['authconfig']['ldap']['auth'] = true
node.override['authconfig']['ldap']['cacerturl'] = 
'http://192.168.15.100/mirrors/ks/keys/cacert.pem'


 
 sysconfig]# cat authconfig 
USEMKHOMEDIR=no
USEPAMACCESS=no
CACHECREDENTIALS=yes
USESSSDAUTH=no
USESHADOW=yes
USEWINBIND=no
PASSWDALGORITHM=sha512
FORCELEGACY=no
USEFPRINTD=no
USEHESIOD=no
FORCESMARTCARD=no
USEDB=no
USELDAPAUTH=yes
USELDAP=yes
USECRACKLIB=yes
USEWINBINDAUTH=no
USESMARTCARD=no
USELOCAUTHORIZE=yes
USENIS=no
USEKERBEROS=no
USESYSNETAUTH=no
USESSSD=yes
USEPASSWDQC=no

It is important that it did work. The configuration stayed idempotent even 
after that error. I just not sure if I doing it right by using a recipe to 
override the node attribute.

 - Rilindo

On Jan 21, 2012, at 6:08 PM, Jesse Campbell wrote:

> hmm. well that is somewhat unexpected.
> 
> Which linux are you running?
> Sorry, I had only tested this on centos 6.1, and i hadn't expanded
> testing beyond that yet...
> 
> try taking a look at /etc/authconfig/arguments and see if all your
> variables ended up in there correctly...
> also, try running the authconfig command by itself with no arguments
> at all... it should list off all of the possible command line
> arguments, and maybe there are some unsupported ones...
> 
> which makes me think I may need a more robust way to check which
> arguments are supported by authconfig besides just checking the node's
> distribution version.
> 
> -Jesse
> 
> On Sat, Jan 21, 2012 at 18:01, RILINDO FOSTER 
> <
 >
>  wrote:
>> That sort of got me further.
>> 
>> I added the following in the recipe file:
>> 
>> include_recipe "authconfig"
>> 
>> Which does not appear to have any effect. Then I add the authconfig in the
>> run list first:
>> 
>> stardust:cookbooks rilindo$ knife node run_list add ldaptls
>> "recipe[authconfig::ldapauthtls]"
>> run_list:
>>     recipe[chef-client]
>>     recipe[ohai]
>>     recipe[authconfig]
>>     recipe[authconfig::ldapauthtls]
>> 
>> And that did it. However, restarting chef-client again returns the
>> following:
>> 
>> [Sat, 21 Jan 2012 17:53:25 -0500] INFO: Processing
>> execute[authconfig-update] action run (authconfig::default line 23)
>> [Sat, 21 Jan 2012 17:53:25 -0500] INFO: execute[authconfig-update]
>> sh(/bin/cat /etc/authconfig/arguments | /usr/bin/xargs /usr/sbin/authconfig
>> --update)
>> [Sat, 21 Jan 2012 17:53:29 -0500] FATAL: SIGTERM received, stopping
>> [Sat, 21 Jan 2012 17:53:29 -0500] ERROR: Running exception handlers
>> [Sat, 21 Jan 2012 17:53:30 -0500] FATAL: Saving node information to
>> /var/chef/cache/failed-run-data.json
>> [Sat, 21 Jan 2012 17:53:30 -0500] ERROR: Exception handlers complete
>> 
>> 
>> Looking at the run file, I see:
>> 
>>   "exception": "SystemExit: exit",
>>   "backtrace": [
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/application.rb:143:in
>> `exit'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/application.rb:143:in
>> `fatal!'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/application.rb:35:in
>> `block in initialize'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shell_out/unix.rb:31:in
>> `call'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shell_out/unix.rb:31:in
>> `select'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shell_out/unix.rb:31:in
>> `run_command'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shell_out.rb:180:in
>> `run_command'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/mixin/shell_out.rb:30:in
>> `shell_out'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/mixin/shell_out.rb:35:in
>> `shell_out!'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/provider/execute.rb:58:in
>> `action_run'",
>>     
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/resource.rb:440:in
>> `run_action'",
>>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/runner.rb:45:in
>> `run_action'",
>>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/runner.rb:53:in
>> `block in run_action'",
>>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/runner.rb:51:in
>> `each'",
>>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/runner.rb:51:in
>> `run_action'",
>>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/runner.rb:81:in
>> `block (2 levels) in converge'",
>>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/runner.rb:81:in
>> `each'",
>>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/runner.rb:81:in
>> `block in converge'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/resource_collection.rb:94:in
>> `block in execute_each_resource'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/resource_collection/stepable_iterator.rb:116:in
>> `call'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/resource_collection/stepable_iterator.rb:116:in
>> `call_iterator_block'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/resource_collection/stepable_iterator.rb:85:in
>> `step'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/resource_collection/stepable_iterator.rb:104:in
>> `iterate'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/resource_collection/stepable_iterator.rb:55:in
>> `each_with_index'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/resource_collection.rb:92:in
>> `execute_each_resource'",
>>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/runner.rb:76:in
>> `converge'",
>>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/client.rb:312:in
>> `converge'",
>>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/client.rb:160:in
>> `run'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/application/client.rb:239:in
>> `block in run_application'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/application/client.rb:229:in
>> `loop'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/application/client.rb:229:in
>> `run_application'",
>> 
>> "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/application.rb:67:in
>> `run'",
>>     "/usr/lib64/ruby/gems/1.9.1/gems/chef-0.10.8/bin/chef-client:26:in 
>> `<top
>> (required)>'",
>>     "/usr/bin/chef-client:19:in `load'",
>>     "/usr/bin/chef-client:19:in `<main>'"
>>   ]
>> }[
>> 
>> 
>> I am going to expose my inexperience with chef and say that I am not sure 
>> if
>> this the right way to go. If the preferable way is to set through the role
>> or node attributes (although I am not sure how to do the latter), then I'll
>> do that instead.  :)
>> 
>>  - Rilindo
>> 
>> 
>> On Jan 21, 2012, at 5:42 PM, Jesse Campbell wrote:
>> 
>> Hmm...
>> I usually set the overrides on the chef server through role or node
>> attributes, i haven't before tried to set them on the node directly with a
>> file... Though it may work regardless.
>> You may need to include the authconfig default recipe ( recipe[authconfig] 
>> )
>> 
>> On Jan 21, 2012 5:24 PM, "RILINDO FOSTER" 
>> <
 >
>>  wrote:
>>> 
>>> Testing it out, I set the attributes as such in a recipe file:
>>> 
>>> stardust:recipes rilindo$ more ldapauthtls.rb
>>> node.override['authconfig']['sssd']['enable'] = true
>>> node.override['authconfig']['ldap']['enable'] = true
>>> node.override['authconfig']['ldap']['tls'] = true
>>> node.override['authconfig']['ldap']['server'] = 'kerberos.example.com'
>>> node.override['authconfig']['ldap']['basedn'] = 'dc=example,dc=com'
>>> node.override['authconfig']['ldap']['auth'] = true
>>> node.override['authconfig']['ldap']['cacerturl'] =
>>> 'http://192.168.15.100/mirrors/ks/keys/cacert.pem'
>>> 
>>> And added it in:
>>> 
>>> 
>>> stardust:recipes rilindo$ knife node run_list add ldaptls
>>> "recipe[authconfig::ldapauthtls]"
>>> run_list:
>>>    recipe[chef-client]
>>>    recipe[ohai]
>>>    recipe[authconfig::ldapauthtls]
>>> 
>>> And restarted chef-client on my test node. So far, it didn't set the
>>> configs as intended.
>>> 
>>> Perhaps it is my inexperience with chef getting in the way, but is this
>>> the right way to set it up?
>>> 
>>> - Rilindo
>>> 
>>> On Jan 21, 2012, at 12:45 PM, Jesse Campbell wrote:
>>> 
>>> I was looking for a cookbook to manage ldap configuration on centos
>>> 6.1 vms that I'd spun up, as well as our other 300-odd centos 5.5 vms.
>>> 
>>> First looked at the openldap cookbook and wasn't terribly impressed...
>>> it has lots of dependencies on debian locations of things that I'd
>>> have to mess about with to make it work with centos.
>>> 
>>> Authconfig is a built-in CLI for managing auth configuration, be it
>>> for ldap, winbind, kerberos, nis, etc. It automagically updates all of
>>> the required files, using the new SSSD subsystem on EL6 systems.
>>> Rather than reinventing that wheel, I decided to take advantage of the
>>> built-in and call out to it from chef.
>>> 
>>> There was no method i found for telling authconfig to pull the
>>> configuration from a file, so instead I build out an arguments list
>>> from node attributes. If the file changes, it will re-run authconfig,
>>> so it is idempotent.
>>> The defaults follow what came on a bare centos 6.1 system, but should
>>> work with others.
>>> 
>>> Current issue:
>>> the functionality to tell winbind to join a domain is not included, it
>>> seemed to need an admin user specified, and likely would prompt for a
>>> password. Not having a domain server to test against, I did not have
>>> any way to find out.
>>> 
>>> http://community.opscode.com/cookbooks/authconfig
>>> 
>>> I have only tested this on CentOS 6 so far, but would appreciate if
>>> anyone else tries it to let me know if it works, or bugs they run
>>> into...
>>> 
>>> Thanks!
>>> -Jesse
>>> 
>>> 
>>