Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ensure csr_package is 'installed' instead of 'latest' #1594

Merged
merged 1 commit into from
Jul 10, 2017
Merged

ensure csr_package is 'installed' instead of 'latest' #1594

merged 1 commit into from
Jul 10, 2017

Conversation

pyther
Copy link
Contributor

@pyther pyther commented Jan 24, 2017

mod/security.pp is the only module that ensures the package is latest. This change makes the behavior of mod/security.pp consistent.

Other modules ensure present or installed

  • mod.pp = present
  • mod/php.pp = present
  • mod/mime.php = installed

@pyther
Copy link
Contributor Author

pyther commented Jan 24, 2017

In my environment, our system patching procedure is to create snapshots. When we roll over to the new repositories (update the yum config) we have other process that actually updates the machine.

  • Rolled Over our repostories
  • Puppet ran, updating mod_security_csr (because of ensure => latest)
  • Apache failed to restart with the following configuration error
Jan 24 16:00:13 web-dev.example.com httpd[11964]: AH00526: Syntax error on line 97 of /etc/httpd/modsecurity.d/security_crs.conf:
Jan 24 16:00:13 web-dev.example.com httpd[11964]: ModSecurity: Found another rule with the same id
  • Package installs /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf
  • Run puppet again, puppet removes /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf and restart is successful

In my case there were two issues:

  1. The package behavior (installed vs latest) is inconsistent (this PR fixes this)
  2. The package should be installed before managing $modsec_dir

EDIT: It turns out issue 2 is fixed, unfortunately we are using an old version of puppetlabs-apache.

@gdubicki
Copy link

I stumbled upon the ModSecurity: Found another rule with the same id issue too. But for me even upgrade to current 1.11.0 version of this module didn't help. But it was probably because I started with 1.4.1 and solutions mentioned in https://tickets.puppetlabs.com/browse/MODULES-3744 were sensitive to existing files. Probably cleaning /etc/httpd or other config dirs would help.

@tphoney
Copy link
Contributor

tphoney commented Jul 10, 2017

Thanks for the change @pyther

@tphoney tphoney merged commit a5f3bf2 into puppetlabs:master Jul 10, 2017
cegeka-jenkins pushed a commit to cegeka/puppet-apache that referenced this pull request Jul 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants