Infinite loop from apache2_mod_auth_cas and apache2_module 'auth_cas' resources
rgriffith opened this issue · comments
👻 Brief Description
Simply using apache2_mod_auth_cas 'auth_cas' results in an infinite loop which eventually causes my chef-client run to fail. Sample logging:
* directory[/var/cache/mod_auth_cas/] action create (up to date)
* apache2_mod_auth_cas[auth_cas] action install
* file[/etc/httpd/conf.d/auth_cas.conf] action create (skipped due to only_if)
* apache2_module[auth_cas] action enable
* apache2_mod_auth_cas[default] action install
* file[/etc/httpd/conf.d/auth_cas.conf] action create (skipped due to only_if)
* apache2_module[auth_cas] action enable
* apache2_mod_auth_cas[default] action install
* file[/etc/httpd/conf.d/auth_cas.conf] action create (skipped due to only_if)
* apache2_module[auth_cas] action enable
* apache2_mod_auth_cas[default] action install
...
🥞 Cookbook version
depends 'apache2', '~> 8.9.1'
👩🍳 Chef-Infra Version
[~]# chef-client --version
Chef Infra Client: 15.15.1
🎩 Platform details
Latest AWS Amazon Linux 2 AMI (ami-0915bcb5fa77e4892)
Steps To Reproduce
Steps to reproduce the behavior:
- Add the
apache2_mod_auth_casresource as-is to a wrapper cookbook - Run
chef-client - Notice the infinite loop
🚓 Expected behavior
No infinite looping and successful Chef Infra run.
I confirmed this is happening. I'm taking a look to see why this is happening.
Worth noting, I see the same issue with apache2_module 'auth_cas', so I think the circularity is stemming from that.
I've narrowed down the problem and will be pushing a fix soon.
@rgriffith can you please give the changes in #736 a try? It provides some additional fixes as well that I hope are useful to mod_auth_cas users.
@ramereth I'll try to work on testing this out.
Quick question, I'm already creating a config containing those CAS directives, among others, using apache2_conf so I don't really need that extra one being created by the resource. What would be the recommended way of removing that conf the resource is creating, but keeping the module enabled, so that it's not constantly being recreated and me having to use a resource (i.e. execute/bash) to delete it again?
@rgriffith I added that as httpd would refuse to start on some platforms without those options being set. If you'd like, I could create a new parameter called template_cookbook which will allow you to set this to your template. Would that work?
@ramereth that would be great if you could. In my case; however, perhaps providing that conf flag to bypass the config all-together would work well since i'm using that same config for more than just CAS directives.
@rgriffith so you'd like to be able to do the following?
apache2_mod_auth_cas 'default' do
conf false
endwhich would do the following in the resource:
apache2_module 'auth_cas' do
template_cookbook 'apache2'
conf new_resource.conf
mod_conf(
cache_dir: cache_dir,
login_url: new_resource.login_url,
validate_url: new_resource.validate_url
)
endThis of course would assume the user would need to be sure to provide a config so it works properly.
@ramereth That would work well for my particular use case, since I am supplying the directives elsewhere in another conf.
I did notice the other "helper" module resources don't really do that, though, so that would make this one different. Another option would be to add more CAS directives to the template so they can be overwritten, or provided; otherwise, I would have 3 directives in the module config and the remainder in my other config. Doable, but could be a main to troubleshoot on the server if one isn't aware of that.
For reference, the directives I am setting are:
- CASVersion
- CASDebug
- CASCookiePath
- CASLoginURL
- CASValidateURL
- CASCertificatePath (this one is only added under certain circumstances)
- CASSSOEnabled
- CASIdleTimeout
- CASTimeout
I'd rather we keep the amount of options to a minimum however what we could do is add a directives parameter which would allow you to add whatever options you'd like in the template. It would work similar to the mod_ssl template:
Lines 59 to 60 in 54647dc
apache2/templates/mods/ssl.conf.erb
Lines 96 to 100 in 54647dc
How does that sound instead? Then I could do that and not add the conf parameter.
@ramereth So you'll keep those "core" couple that are there currently and allow passing in arbitrary directives? I should be able to make that work.
@rgriffith ok, I've made that change to the PR. Can you please move any further discussion to the PR so we can discuss better in context of code if you need to? Thanks!
Sounds good, thank you @ramereth. Did you still need me to test anything, or are you planning to merge/release?
@rgriffith if you could test it yourself and make sure it works for you that'd be great. Then I can merge/release it!
@rgriffith did you get a chance to check on this?
Not yet @ramereth, but it's on my TODO list this week. I will follow up as soon as I can.
@ramereth I was able to get around to testing your branch and confirmed I no longer run into the infinite loop and the generated config file is as expected (i.e. with the added directives).
For reference, here's a snippet of the check in once I pointed to your branch:
* yum_package[mod_auth_cas] action install (up to date)
* directory[purge distro conf.modules.d] action nothing (skipped due to action :nothing)
* directory[purge distro conf.d] action nothing (skipped due to action :nothing)
* file[/etc/httpd/conf.d/auth_cas.conf] action create (skipped due to only_if)
* apache2_module[auth_cas] action enable
* template[/etc/httpd/mods-available/auth_cas.conf] action create
- create new file /etc/httpd/mods-available/auth_cas.conf
- update content in file /etc/httpd/mods-available/auth_cas.conf from none to a25cb9
--- /etc/httpd/mods-available/auth_cas.conf 2021-03-31 16:39:02.048184444 +0000
+++ /etc/httpd/mods-available/.chef-auth_cas20210331-2771-ko09zw.conf 2021-03-31 16:39:02.048184444 +0000
@@ -1,9 +1,18 @@
+CASCookiePath /var/cache/httpd/mod_auth_cas/
+CASLoginURL https://cas.example.com/idp/profile/cas/login
+CASValidateURL https://cas.example.com/idp/profile/cas/serviceValidate
+CASCookiePath /var/cache/mod_auth_cas/
+CASDebug Off
+CASIdleTimeout 3600
+CASSSOEnabled Off
+CASTimeout 7200
+CASVersion 2
* file[/etc/httpd/mods-available/auth_cas.load] action create
- create new file /etc/httpd/mods-available/auth_cas.load
- update content in file /etc/httpd/mods-available/auth_cas.load from none to 769b29
--- /etc/httpd/mods-available/auth_cas.load 2021-03-31 16:39:02.060184195 +0000
+++ /etc/httpd/mods-available/.chef-auth_cas20210331-2771-8rijgw.load 2021-03-31 16:39:02.060184195 +0000
@@ -1 +1,2 @@
+LoadModule auth_cas_module /usr/lib64/httpd/modules/mod_auth_cas.so
- change mode from '' to '0644'
* execute[a2enmod auth_cas] action run
- execute /usr/sbin/a2enmod auth_cas
* directory[/var/cache/httpd/mod_auth_cas] action create
- change mode from '0755' to '0700'
Thanks again for your assistance!
@ramereth Something I am noticing is if I make a change to the directives list the configuration updates as expected, but there is no restart of the Apache service. Is that to be expected? Here is an example output showing the configuration change:
* apache2_mod_auth_cas[auth_cas] action install
* yum_package[mod_auth_cas] action install (up to date)
* directory[purge distro conf.modules.d] action nothing (skipped due to action :nothing)
* directory[purge distro conf.d] action nothing (skipped due to action :nothing)
* file[/etc/httpd/conf.d/auth_cas.conf] action create (skipped due to only_if)
* apache2_module[auth_cas] action enable
* template[/etc/httpd/mods-available/auth_cas.conf] action create
- update content in file /etc/httpd/mods-available/auth_cas.conf from 2e645d to 21b542
--- /etc/httpd/mods-available/auth_cas.conf 2021-04-01 13:41:48.373022453 +0000
+++ /etc/httpd/mods-available/.chef-auth_cas20210401-22286-y1x085.conf 2021-04-01 14:02:18.305179871 +0000
@@ -1,6 +1,6 @@
CASCookiePath /var/cache/httpd/mod_auth_cas/
-CASLoginURL http://hhcas.hannonhill.com:8080/cas/login
-CASValidateURL http://hhcas.hannonhill.com:8080/cas/serviceValidate
+CASLoginURL https://casserver.herokuapp.com/cas/login
+CASValidateURL https://casserver.herokuapp.com/cas/serviceValidate
CASDebug Off
CASIdleTimeout 3600
CASSSOEnabled Off
* file[/etc/httpd/mods-available/auth_cas.load] action create (up to date)
* execute[a2enmod auth_cas] action run (skipped due to not_if)
* directory[/var/cache/httpd/mod_auth_cas] action create (up to date)
But there is no delayed restart of Apache at the end of the run.
That was missed on my part, I'll push a fix for that soon! Thanks for noticing that.
@rgriffith would a reload be enough? I don't think we need to do a full restart
Yup, a reload is perfect!
This isn't related to CAS, but more modules in general so let me know if I need to post this elsewhere. I am seeing an interesting error where when I am iterating over an array of modules to install and have effectively generated the following:
apache2_mod_proxy 'mod_proxy' do
require 'all granted'
end
apache2_module 'proxy_ajp'
apache2_module 'proxy_wstunnel'
When Apache goes to start (or I guess restart), I get the following error:
httpd[7224]: httpd: Syntax error on line 80 of /etc/httpd/conf/httpd.conf: Syntax error on line 1 of /etc/httpd/mods-enabled/proxy_ajp.load: Cannot load /usr/lib64/httpd/modules/...ol: proxy_module
If I rename proxy_ajp.load and proxy_wstunnel.load to be prefixed with a z so they are loaded later, Apache starts fine. Assuming because proxy is a requirement of the two and needs to load first.
Wondering if you've heard about or ran into this sort of behavior before.
Sorry, I think I see the issue now that I look at mods-enabled. The proxy module is no where to be seen.
Seems like there's an issue with apache2_mod_proxy where it's not actually enabling the module. Looking at that resource, there doesn't seem to be a call to enable it.
Can you please make an issue separately for that?
I just pushed a fix for reloading the resource, can you please verify that works for you?
Thanks, I'll check to see if there are existing issues first and post something when I can.
I switched gears a bit to test the cookbook with our Shibboleth setup, but will test again as soon as I can.
If I don't hear back from you within the next day, I'll just go ahead and release this PR since I think it's close enough.
I just tested a similar change on my apache2_conf resources where I wasn't seeing reloads until I added a notifies :reload, 'service[apache2]' action to them.
Safe to assume the same will occur with your recent change or would you prefer I still test the apache2_mod_auth_cas resource?
@ramereth I went ahead and tested this out instead of being lazy 😄 .
I added a change which triggers an update to the config via directives, but not seeing a reload at the end.
Er, my fault I forgot to delete the cached apache2 cookbook which didn't have your recent change in it.
I confirmed that I am seeing an Apache reload when the directives change.