1 Reply Latest reply on Mar 9, 2015 7:46 AM by Bill Robinson

    Compliance job checking mulitple httpd configuration files in different directories

      For security reasons we need to ensure that export-grade SSL ciphers are never used. So I need to create a compliance job which will check that if there is a parameter "SSLCipherSuite" in a httpd configuration file, it should contain the string "!EXPORT". My implementation plan so far is:

      - Check that this key/value is correct in /etc/httpd/conf/httpd.conf

      - Check that this key/value is correct in /etc/httpd/conf.d/ssl.conf

      However in its default setup there are already a couple of configuration files in /etc/httpd/conf.d. To make it even worse, there can be more than 1 ServerRoot on a server, so httpd configuration files on many (variable) locations. I have read a number of answers stating to use a local property in the component template, instantiate that property to match with the well-known values, however there is no real solution for dynamic configurations. Does anyone have a suggestion how to deal with this?

      So what I want to have is a scalable solution where we find an httpd.conf on a server, deduct HTTPD_ROOT as the ServerRoot from that httpd.conf and setup a set of config files as ??HTTPD_ROOT??/conf.d/*.conf which need to be included in the component template.

        • 1. Re: Compliance job checking mulitple httpd configuration files in different directories
          Bill Robinson

          if you want to use properties and such then the approach is:

          - define the path properties, etc

          - run a nsh/blcli script that finds all of the possible locations for httpd, creates psis in the template and then sets the possible values, config files, etc.

          - run discovery

          - run compliance

          then benefit would be that you could use a blpackage to remediate this.


          another approach is to write a script that does the 'find' (locally) and does the check for the configurations you want and then spits out a pass fail, probably w/ some pathing information and then the compliance condition is that your EO spits out 'pass'. and the remediation would have to be another script called by a blpackage to do the find again and fix up the files.


          if you are on 8.5 you might be able to use the new 'command' construct in the condition to do the find and variable assignment - Defining a basic condition - BMC Server Automation 8.5 - BMC Documentation  it looks promising but i haven't had a chance to mess w/ it much.