Chef openid to ldap gateway

Setting up a openid to ldap gateway for chef authentication.

So one of my main complaints about chef and I might mention the office joke is the use of openid for authentication of users. This presented two problems for me, one that I would never trust the authentication to my management server to a outside source and second that my chef server does not have internet access. Chef pointed me in the direction of http://www.openid-ldap.org/ and after a little wresting I was able to have a working internal openid auth system using already existing ldap auth system.

I am running openidldap on a system that I have configured to handle admin web apps, and the install consisted of simply creating the web root and updating the ldap.php. A few things I did fine useful was to rename it the directory to openid. The ldap.php was pretty easy but one place I did get stuck was that I did not clearly read the directions and tried to create .htaccess files rather then just update /etc/httpd/conf.d/ssl.conf and /etc/httpd/conf/httpd.conf like they said.

If you follow the directions it should be a 10 minute setup at most.

Untar the file in your webroot, rename directory to openid

append to httpd.conf or virtualhost.conf if your using one


---
RewriteEngine On

RewriteRule ^/openid$ https://openid.int.mycompany/openid/ [R=permanent,L]
RewriteRule ^/openid/$ https://openid.int.mycompany/openid/ [R=permanent,L]
RewriteRule ^/openid/(.*)$ https://openid.int.mycompany/openid/$1 [R=permanent,L]
---

insert inside the virtualhost of ssl.conf


---
SSLProxyEngine On
RewriteEngine On

RewriteCond %{REQUEST_URI} !^/(.+)\.php(.*)$
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /openid/([A-Za-z0-9]+)\?(.*)\ HTTP/
RewriteRule ^/openid/(.*)$ https://openid.int.mycompany/openid/index.php?user=%1&%2 [P]

RewriteCond %{REQUEST_URI} !^/(.+)\.php(.*)$
RewriteRule ^/openid/([A-Za-z0-9]+)$ https://openid.int.mycompany/openid/index.php?user=$1 [P]
---

update the ldap.php in the openid directory you just created, which is pretty clear but I did have to edit the following lines to make sure the name showed up correctly.


---
# SREG names matching to LDAP attribute names
'nickname' => 'uid',
'email' => 'mail',
'fullname' => 'cn',
---

then simply test by going to https://yourhostname/openid/

One thing I have yet to fix is that my chef server straddles two networks, one side that I can access form the office the other that servers talk on and this creates havok on my logins, for now I wound up creating a openid.int.mycompany entry pointing to the ip visible to my mac and that gets me round he problem of int.mycompany not being routable outside the server server network.

Bug in chef::client recipe on CentOS 5 ( or not )

So while now that I have fixed it so I can run the chef::client recipe a new error has cropped up, and how I fixed it.

So while now that I have fixed it so I can run the chef::client recipe a new error has cropped up, and how I fixed it.

[Tue, 15 Sep 2009 22:06:36 -0700] INFO: Creating a symbolic link from -> /etc/init.d/chef-client for link[/etc/init.d/chef-client]
[Tue, 15 Sep 2009 22:06:36 -0700] INFO: Creating a symbolic link from /chef-client -> /chef-client for link[/chef-client]
[Tue, 15 Sep 2009 22:06:38 -0700] INFO: Chef Run complete in 3.967334 seconds
[root@srv-101-25 ~]# chef-client
/usr/lib/ruby/1.8/net/http.rb:560:in `initialize’: getaddrinfo: Name or service not known (SocketError)
from /usr/lib/ruby/1.8/net/http.rb:560:in `open’
from /usr/lib/ruby/1.8/net/http.rb:560:in `connect’
from /usr/lib/ruby/1.8/timeout.rb:53:in `timeout’
from /usr/lib/ruby/1.8/timeout.rb:93:in `timeout’
from /usr/lib/ruby/1.8/net/http.rb:560:in `connect’
from /usr/lib/ruby/1.8/net/http.rb:553:in `do_start’
from /usr/lib/ruby/1.8/net/http.rb:542:in `start’
from /usr/lib/ruby/1.8/net/http.rb:1035:in `request’
… 7 levels…
from /usr/lib/ruby/gems/1.8/gems/chef-0.7.8/lib/chef/application.rb:57:in `run’
from /usr/lib/ruby/gems/1.8/gems/chef-0.7.8/bin/chef-client:26
from /usr/bin/chef-client:19:in `load’
from /usr/bin/chef-client:19

Update 1:
Found the problem, when it installs the client is generates a new /etc/chef/client.rb file that uses the local server name as default value for the chef server, which is of course a problem.

[root@srv-101-10 ~]# vi /etc/chef/client.rb
---
# Chef Client Config File
#
# Dynamically generated by Chef - local modifications will be replaced
#

log_level :info
log_location "/var/log/chef/client.log"
ssl_verify_mode :verify_none
registration_url "https://srv-101-10.int.mycompany.int.mycompany"
openid_url "https://srv-101-10.int.mycompany.int.mycompany:444"
template_url "https://srv-101-10.int.mycompany.int.mycompany"
remotefile_url "https://srv-101-10.int.mycompany.int.mycompany"
search_url "https://srv-101-10.int.mycompany.int.mycompany"
role_url "https://srv-101-10.int.mycompany.int.mycompany"

file_store_path "/srv/chef/file_store"
file_cache_path "/srv/chef/cache"

pid_file "/var/run/chef/chef-client.pid"

Chef::Log::Formatter.show_time = true
---

where as it should read:

---
#
# Chef Client Config File
#
# Dynamically generated by Chef - local modifications will be replaced
#

log_level :info
log_location "/var/log/chef/client.log"
ssl_verify_mode :verify_none
registration_url "https://chef.int.mycompany"
openid_url "https://chef.int.mycompany:444"
template_url "https://chef.int.mycompany"
remotefile_url "https://chef.int.mycompany"
search_url "https://chef.int.mycompany"
role_url "https://chef.int.mycompany"

file_store_path "/srv/chef/file_store"
file_cache_path "/srv/chef/cache"

pid_file "/var/run/chef/chef-client.pid"

Chef::Log::Formatter.show_time = true
---

Now I am off to find the problem causing recipe

and the fix turned out to be updating the json overide properties for my COMPANY_BASE_ROLE


---
{
"defaults":{},
"overrides":{
"chef":{
"client_splay":"20",
"client_interval":"600",
"server_fqdn":"chef.int.company"
},
"authorization":{
"sudo":{
"groups":["group1"
],
"users":[]
}
},
"ntp":{
"is_server":false,
"service":"ntpd",
"servers":["time01.int.company",
"time02.int.company"
]
}
}
}
---

Chef for fun and maybe some profit

Upon joining my new company last month I came into the perfect env of empty servers and all the freedom I wanted. I had been testing Cobbler https://fedorahosted.org/cobbler/ and Chef http://wiki.opscode.com/display/chef/Home over the last month as a replacement for my home grown build system. Well the joy of testing on virtual systems did not truly expose me to the joys of deploying chef in a closed system. I designed the environment to not be reaching outside of our network for anything and chef did not like that, but it turned out to be OK after lots and lots of fun.

Upon joining my new company last month I came into the perfect env of empty servers and all the freedom I wanted. I had been testing Cobbler https://fedorahosted.org/cobbler/ and Chef http://wiki.opscode.com/display/chef/Home the previous month at my at Tagged, Inc as a replacement for my home grown build system that had been implemented there and at Pay By Touch. Well the joy of testing on virtual systems did not truly expose me to the joys of deploying chef in a closed environment. As any security minded person would do I designed the new environment to not allow reaching outside of the local network for anything and chef did not like that, but it turned out to be OK after lots and lots of fun.

My cobbler server is providing a local mirror of http://elff.bravenet.com/, and I have pulled down the current bootstrap file to my cobbler system Apache server.

In the package section of my company_base.ks file, I include

rubygem-chef

Based on notes I found for puppet install I created a snippet in my cobbler install:

Then to prep for install of chef client this is run before the %post section in my company_base.ks file
$SNIPPET(‘company_chef_chroot’)

[jmiller@cobbler ~]$ cat /var/lib/cobbler/snippets/company_chef_nochroot

# Make sure we have network stuff in place so when we register with the server all is well

%post --nochroot
# Copy netinfo, which has our FQDN from DHCP, into the chroot
test -f /tmp/netinfo && cp /tmp/netinfo /mnt/sysimage/tmp/

This snippet in my company_base.ks file installs, validates, and first runs the chef client
$SNIPPET(‘rdio_chef_client’)

[jmiller@cobbler ~]$ cat /var/lib/cobbler/snippets/company_chef_client

# In this script we actually install the client

cat < /root/solo.rb
file_cache_path "/tmp/chef-solo"
cookbook_path "/tmp/chef-solo/cookbooks"
EOF

cat < /root/chef.json
{
"chef": {
"server_fqdn": "chef.int.company"
},
"packages": {
"dist_only": true
},
"recipes": "chef::client"
}
EOF

cat < /root/client.json
{
"run_list": ["role[COMPANY_BASE]"]
}
EOF

# Configure the Env
echo "Installing Chef Bootstrap"
cd /root/
chef-solo -c solo.rb -j chef.json -r http://chef.int.company/bootstrap-0.7.8.tar.gz
cd -

# register with the server
echo "Register with Chef"
chef-client -t "myAuthToken" -j /root/client.json

chef-client
[jmiller@cobbler ~]$

My COMPANY_BASE role in chef was lacking a few recipes and threw me for a huge loop.

recipes in COMPANY_BASE ( chef chef::client sudo screen ntp openssh snmp git )


[root@srv-101-25 ~]# chef-client -l debug -j /root/client.json
/usr/lib/ruby/gems/1.8/gems/chef-0.7.8/lib/chef/recipe.rb:200:in `method_missing': Cannot find Chef::Resource::DistOnly? for dist_only? (NameError)
Original: undefined method `DistOnly?' for Chef::Resource:Class

After a lot of troubleshooting with Joshua Timberman of Opsec we found out that I needed two more recipes ( packages & runit ), turns out this is limit with RPM based systems and caused me a lot of hurt.

Sites I owe a lot of thank you to:
http://wiki.opscode.com/display/chef/Home
https://fedorahosted.org/cobbler/
http://reductivelabs.com/trac/puppet/wiki/BootstrappingWithPuppet
http://wiki.opscode.com/display/chef/Installation+on+RHEL+and+CentOS+5+with+RPMs