mod_fastcgi URL is unreachable. Cannot run the recipe anymore

[jujugrrr]

https://github.com/svanzoest-cookbooks/apache2/blob/master/attributes/mod_fastcgi.rb#L20 doesn't work anymore. It seems www.fastcgi.com is gone

http://webcache.googleusercontent.com/search?q=cache:e0DGxuMJ684J:www.fastcgi.com/+&cd=1&hl=en&ct=clnk&gl=uk

http://www.fastcgi.com

[svanzoest]

Do you have an updated URL the cookbook should use? By default it should use the package, so it should not impact people immediately.

[matthyatt]

I've been having the same issue. I've only been using chef a few months, but if I read the recipe correctly, when the platform_family is 'rhel' it will always use the source install method and only uses the package on platform_family debian when the install_method is not 'source'. I'm using this cookbook on centos and this recipe attempts to download the source tarball and fails. There's no guard for the remote_file resource so it tries to download it on every converge.

Our current workaround is to self-host the source package.

https://github.com/svanzoest-cookbooks/apache2/blob/master/recipes/mod_fastcgi.rb#L35

[jujugrrr]

Our current workaround is to self-host the source package.

Same here @svanzoest

[svanzoest]

It is generally best to leverage package install methods everywhere over dynamic source based downloads as they can be unreliable as seen here.

It looks like the rhel platform family does not have a package for mod_fastcgi available in the standard operating system package repositories. It seems that they expect you to use mod_proxy_fcgi or mod_fcgid instead. What would you consider the best course of action? I have made the default a package install on all platforms in #416, however, there is no way we could have any reliable test coverage as the package is not available by default.

Considering this module is not part of the ASF httpd project itself, I would suggest this gets removed from the apache2 cookbook entirely and made into its own chef cookbook. Since you all are dependent on this, do you plan to take that on? If so, I would be happy to remove it from the cookbook and direct others your way.

[matthyatt]

I would generally agree that since mod_fastcgi isn't available through the ASF httpd source that it shouldn't be included in this cookbook. Installing from a source package is the only way for rhel but this package hasn't been updated since 2007 and their site is down so I don't what the future for the mod_fastcgi package is.

As for working with what's in place now, I would think adding a guard to the remote file resource like the bash resource could be a quick fix.

not_if "test -f #{node['apache']['dir']}/mods-available/fastcgi.conf"

This would make the recipe only download the package if the module isn't installed (i.e. conf file doesn't exist). The package isn't compiled anyway if it's already installed so I don't see the need to download it in this case. That would resolve issues where the source package isn't available but has already been installed and error out as expected if it's not installed and can't be downloaded. I think this would make it a little more idempotent as if the package is already installed it will be executing fewer resources.

A better solution I think would be to specify a checksum for the source package as well as the url. This would allow you to check if the package downloaded is different from the one expected or specified in the configuration and download/compile/install if it's changed or fail if the checksum doesn't match (after pulling down a fresh copy). You can base the guards for downloading and compiling on that checksum matching the cached package and the conf file check to cover the different scenarios. This allows for updating the package source and checksum together and feels a little more idempotent and secure as well.

Other than that I don't have much input. I'm consuming this cookbook indirectly by way of magentostack through Rackspace.

https://github.com/rackspace-cookbooks/magentostack

[svanzoest]

@martinb3 does it make sense to have magentostack move to something other then mod_fastcgi?

[martinb3]

@svanzoest It would, but we're not likely to do a ton of new development on that cookbook right now. @jujugrrr and I would definitely merge PRs and help guide it, but our Magento attention is focused elsewhere at the moment.

[svanzoest]

I am not sure what more we can do on this ticket, so I am going to close this. I would love to see a separate cookbook or otherwise suggest people switch to mod_fcgid or mod_proxy_fcgi

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.