saltstack-formulas/apache-formula

Set up and configure the Apache HTTP server

apache-formula's Issues

Please support additional options for Proxypass

It would be great if the ProxyPass option supported addtional options e.g by using something like ProxyPassTargetOptions.:

ProxyPassTargetOptions: "connectiontimeout=5 timeout=30"

ProxyPass "/example" "http://backend.example.com" connectiontimeout=5 timeout=30

support for listing modules to enable

It would be nice to have a way to enable modules through pillars

Multi ProxyPassSource declaration

I would like to declare multi proxy pass from the main configuration:

The error log in master conf is :
2015-03-09 16:49:45,498 [salt.pillar ][CRITICAL] Rendering SLS 'apache.frontal_sis' failed, render error:
Conflicting ID 'ProxyPassSource'
2015-03-09 16:49:45,498 [salt.pillar ][CRITICAL] Pillar render error: Rendering SLS 'apache.frontal_sis' failed. Please see master log for details.
2015-03-09 17:12:19,821 [salt.pillar ][CRITICAL] Rendering SLS 'apache.frontal_sis' failed, render error:
Conflicting ID 'ProxyPassSource'
2015-03-09 17:12:19,821 [salt.pillar ][CRITICAL] Pillar render error: Rendering SLS 'apache.frontal_sis' failed. Please see master log for details.
2015-03-09 17:25:38,889 [salt.pillar ][CRITICAL] Rendering SLS 'apache.frontal_sis' failed, render error:
Conflicting ID 'ProxyPassSource'
2015-03-09 17:25:38,889 [salt.pillar ][CRITICAL] Pillar render error: Rendering SLS 'apache.frontal_sis' failed. Please see master log for details.

Can't use both apache.mod_proxy and apache.modules (with proxy in the enabled modules)

    Detected conflicting IDs, SLS IDs need to be globally unique.
    The conflicting ID is "a2enmod proxy" and is found in SLS "base:apache.mod_proxy" and SLS "base:apache.modules"

A simple fix would be to have a nice unique id in apache.mod_proxy (and in apache.modules while we're at it).

Pillar example fails to render

Using pillar.example as is.

Salt: 0.17.0

root@precise64:/home/vagrant# salt '*' state.sls apache
seed-minion.pub:
    Data failed to compile:
----------
    Pillar failed to render with the following messages:
----------
    Rendering SLS 'apache' failed, render error:
Undefined jinja variable; line 57 in template

Archlinux: state apache fails (with pillars)

Needs investigation, pillars derived from pillar.example.

State apache fails on Archlinux
[ERROR   ] Rendering exception occurred: Jinja variable 'dict object' has no attribute 'server'
[CRITICAL] Rendering SLS 'base:apache' failed: Jinja variable 'dict object' has no attribute 'server'
----------
    Rendering SLS 'base:apache' failed: Jinja variable 'dict object' has no attribute 'server'

Activate mod_ssl through state config

Activate apache2 mod_ssl from a config state

Incompatible 2.2 RH config

There are several Require all statements in the RH 2.2 config, whereas this syntax is not allowed for apache < 2.4

conf.d and vhosts.d directories are hardcoded for RH 2.2 config

These two lines are hard-coded in the httpd.conf for RH 2.2 config:

Include conf.d/.conf
Include vhosts.d/.conf

So if I'm changing vhostsdir in my config, I'm getting an error "Include directory '/etc/httpd/vhosts.d' not found"

Listen directives in apache/files/RedHat/apache-2.4.config.jinja conflict with default mod_ssl installation

While using the latest release of apache-formula (master branch, commit adc80ed), I'm running into an issue while setting up a virtual host directive using SSL. Adding interface: * and port: 443 to the pillar data results in a conflicting Listen directive configuration in /etc/httpd/conf/httpd.conf

# systemctl status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2016-07-20 15:57:48 UTC; 1h 26min ago
     Docs: man:httpd(8)
           man:apachectl(8)
  Process: 4450 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/FAILURE)
  Process: 4449 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)
 Main PID: 4449 (code=exited, status=1/FAILURE)

Jul 20 15:57:48 localhost systemd[1]: Starting The Apache HTTP Server... 
Jul 20 15:57:48 localhost httpd[4449]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
Jul 20 15:57:48 localhost systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE
Jul 20 15:57:48 localhost kill[4450]: kill: cannot find process ""
Jul 20 15:57:48 localhost systemd[1]: httpd.service: control process exited, code=exited status=1
Jul 20 15:57:48 localhost systemd[1]: Failed to start The Apache HTTP Server.
Jul 20 15:57:48 localhost systemd[1]: Unit httpd.service entered failed state.
Jul 20 15:57:48 localhost systemd[1]: httpd.service failed.

# grep -A3 -B3 -ir "^listen" /etc/httpd/*
/etc/httpd/conf/httpd.conf-# Managed by saltstack
/etc/httpd/conf/httpd.conf-
/etc/httpd/conf/httpd.conf-
/etc/httpd/conf/httpd.conf:Listen  *:443
/etc/httpd/conf/httpd.conf:Listen  *:80
/etc/httpd/conf/httpd.conf-
/etc/httpd/conf/httpd.conf-#
/etc/httpd/conf/httpd.conf-# Dynamic Shared Object (DSO) Support
--
/etc/httpd/conf.d/ssl.conf-# When we also provide SSL we have to listen to the 
/etc/httpd/conf.d/ssl.conf-# the HTTPS port in addition.
/etc/httpd/conf.d/ssl.conf-#
/etc/httpd/conf.d/ssl.conf:Listen 443 https
/etc/httpd/conf.d/ssl.conf-
/etc/httpd/conf.d/ssl.conf-##
/etc/httpd/conf.d/ssl.conf-##  SSL Global Context

The minion is running the following:

# salt-minion --versions-report
Salt Version:
           Salt: 2016.3.1

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.7.2
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: 0.21.1
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.7
   mysql-python: 1.2.3
      pycparser: Not Installed
       pycrypto: 2.6.1
         pygit2: Not Installed
         Python: 2.7.5 (default, Nov 20 2015, 02:00:19)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 14.7.0
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.0.5

System Versions:
           dist: centos 7.2.1511 Core
        machine: x86_64
        release: 3.10.0-327.22.2.el7.x86_64
         system: Linux
        version: CentOS Linux 7.2.1511 Core

The master is running the following:

# salt --versions-report
Salt Version:
           Salt: 2016.3.1

Dependency Versions:
           cffi: 0.8.6
       cherrypy: 3.2.2
       dateutil: 1.5
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.7.2
        libgit2: 0.21.0
        libnacl: Not Installed
       M2Crypto: 0.21.1
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.7
   mysql-python: Not Installed
      pycparser: 2.14
       pycrypto: 2.6.1
         pygit2: 0.21.4
         Python: 2.7.5 (default, Nov 20 2015, 02:00:19)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 14.7.0
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.0.5

System Versions:
           dist: centos 7.2.1511 Core
        machine: x86_64
        release: 3.10.0-327.18.2.el7.x86_64
         system: Linux
        version: CentOS Linux 7.2.1511 Core

Please let me know if additional information is required.

Thanks
Rob

Processing error with apache.manage_security state

There seems to be an issue with the apache.manage_security.sls with the file.blockreplace & file.accumulated and I've not been able to determine if it's in the file state functions or the formula itself...

If I provide the following pillar excerpt to the minion:

apache:
  security:
    ServerTokens: 'Prod'
    ServerSignature: 'Off'

What I'd expect from reading the manage_security.sls state file would be something like:

# START managed zone -DO-NOT-EDIT-
ServerSignature Off
ServerTokens Prod
# END managed zone --

However, what I'm actually getting is:

# START managed zone -DO-NOT-EDIT-
ServerSignature Off
ServerTokens Prod# END managed zone --

Which when you run apachectl configtest or the formula attempts to restart Apache fails.

$ sudo apachectl configtest
AH00526: Syntax error on line 77 of /etc/apache2/conf-enabled/security.conf:
ServerTokens takes 1-2 arguments, Determine tokens displayed in the Server: header - Min(imal), Major, Minor, Prod, OS or Full
Action 'configtest' failed.
The Apache error log may have more information.

Simply going and adding the carriage return and moving the "# END managed zone --" marker end string to a new line fixes the problem. Not sure if this is expected behavior with the blockreplace/accumulated file functions or if something is wrong in the formula but it makes using apache.managed_security useless.

support for apache 2.2 apache.config.jinja

I am stuck on on Apache 2.2 on RHEL 6. It seems the apache.config.jinja httpd.conf template files in this formula are all written for Apache 2.4. I have been pondering how to add 2.2 template versions (ostensibly salt://apache/files/RedHat/apache22.config.jinja for example). Here are some ideas for feedback - none of which I particularly like

• A: add config22.sls that is like config.sls, but uses the apache22.config.jinja template. We can then use - apache.config22 in our top file
• B: put some logic in the config.sls to pick the apache22.config.jinja vs the apache.config.jinja file. I'm not sure the best way to write logic to choose this. Maybe we need to add an apache:version to the pillar. We really only care if it is 2.2 or 2.4 - not the full version so I'm not sure how to deal with that.
• C: create a hybrid. Use the apache formula as is, then create a separate custom formula for apache 2.2 that can make use of the base apache formula except for the config piece. This is what I am doing now but it is a little odd. It is only half a formula.

I guess it would help to understand the position of the maintainers of this formula. Do they want to make it primarily a 2.4 formula or is there interest in integrating 2.2 pieces in?

Configure ssl.conf parameters

It would be nice to be able to control the following parameters via the pillars for mod_ssl (defaults are from debian stretch) :

    SSLCipherSuite: 'HIGH:!aNULL'
    SSLHonorCipherOrder: 'Off'
    SSLProtocol: 'all -SSLv3'

apache service.running configurable

I would like apache.service.running to be configurable via map.jinja.

This supports any UC where default apache formula runs with service stopped.

NGINX is badly packaged and aborts pkg installers if tcp/80 is already bound, leaving package managers in a mess. Run apache + nginx salt formulas sequence to replicate.

For both situations, this configurable is useful.

Archlinux: State apache.config fails on Archlinux

Needs investigation, using pillars derived from pillar.example

[ERROR   ] Rendering exception occurred: Jinja variable 'dict object' has no attribute 'configfile'
[CRITICAL] Rendering SLS 'base:apache.config' failed: Jinja variable 'dict object' has no attribute 'configfile'
----------
    Rendering SLS 'base:apache.config' failed: Jinja variable 'dict object' has no attribute 'configfile'

Do not add ServerAlias unless defined

I've noted that the formula is adding 'ServerAlias' even if its not defined in the config, using the default of 'www.{{servername}}' which is often complete nonesense in respect to the vhost config.

Some examples:

A redirect to https:

ServerName: www.example.com
ServerAlias: www.www.example.com  # What?! Why?

A subdomain:

ServerName: mail.example.com
ServerAlias: www.mail.example.com # Not required

A redirect to www:

ServerName: example.com
ServerAlias: www.example.com # No! I have a host defined as www.example.com, get out of my config!

Consistency: `state: enabled` and `enabled: true`.

Right now, there are 2 mechanisms to enable a site.

The current one, used by apache.register_site is the state: enabled attribute from the pillar apache:register-site:$SITE.

Another one which was introduced in @c195dce07c11f50d7914ecd324108fa95e70b3e5 uses the enabled attribute in apache:sites:$SITE.

I believe the latter approach is the better one, as apache.register_site is currently specific to grains['os_family'] == 'Debian', so apache.register_site should be changed to use the other approach.
Otherwise there will be 2 keys to realize more or less the same mechanism which is incosistent and might cause confusion.

wrong osfinger of CentOS

I am using salt 2015.5.2, grains.item osfinger returns 'CentOS Linux-7' on CentOS 7, but I see CentOS-7 here.
https://github.com/saltstack-formulas/apache-formula/blob/master/apache/osfingermap.yaml#L9

What am I missing?

Debian and Ubuntu listen settings should be managed in apache2/ports.conf

The standard.tmpl file prepends the Listen directive to the top of every virtualhost config file. This can prevent apache from starting with the message:

Jan 31 16:46:39 web1 apache2[2023]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80
Jan 31 16:46:59 web1 apache2[2023]: failed!

For Debian/Ubuntu hosts the listen directive should instead be managed in the apache2/ports.conf file.

ability to configure listening ports

Missing the ability to control the 'Listen' directives. On Debian 14.04, that is configured with the file /etc/apache2/ports.conf

Handle php7 on Ubuntu

As indicated by its name, apache.mod_php5 handles php5 only. However, the current Ubuntu 16.04 LTS distribution provides php7 so apache.mod_php5 fails on this system.

On standard.tmpl Customlog and Logformat directive leads to an error

On my RHEL 7.4 with httpd 2.4.6, the Logformat and Customlog merged directive does not work

 {% if site.get('CustomLog') != False -%}CustomLog {{ vals.CustomLog }} {{ vals.LogFormat }}{% endif %}

This version works better

    {% if site.get('LogFormat') != False -%}LogFormat {{ vals.LogFormat }}{% endif %}
    {% if site.get('CustomLog') != False -%}CustomLog {{ vals.CustomLog }} {% endif %}

can you consider update it ?

minimal.tmpl referenced in pillar.example not present in apache/vhosts/

title says it all

/etc/httpd/conf.d/wsgi.conf: file not found

Hello,

I tried to install apache with mod_wsgi but got an error.

Here is the error:

          ID: /etc/httpd/conf.d/wsgi.conf
    Function: file.uncomment
      Result: False
     Comment: /etc/httpd/conf.d/wsgi.conf: file not found
     Started: 21:49:29.489326
    Duration: 1.944 ms
     Changes: 

Here is my pillar file:

apache:
  name_virtual_hosts:
    - interface: '*'
      port: 80

  sites:

    keystone.apache.jblur.com:
      enabled: True
      template_file: salt://apache/vhosts/standard.tmpl
      port: '8880'

Here is my states file:

include:
  - apache
  - apache.config
  - apache.mod_wsgi

Why does it happen?

My OS is: CentOS 7.2

Best regards,
Alexandr

grains[os_family] broken in opensuse LEAP for Salt 2016.3

The apache.modules state fails on opensuse LEAP (Salt 2016.3). The critical error message reports Rendering SLS error complaining about Conflicting ID: Location.

The apache.modules state succeeds if following changes are applied. I can do PR.

+++ b/apache/config.sls
@@ -57,7 +57,7 @@ include:
- service: apache
{% endif %}

-{% if grains['os_family']=="Suse" %}
+{% if grains['os_family']=="Suse" or salt'grains.get' == 'SUSE' %}
/etc/apache2/global.conf:
file.managed:
- template: jinja
diff --git a/apache/mod_php5.sls b/apache/mod_php5.sls
index 370e360..93e16a3 100644
--- a/apache/mod_php5.sls
+++ b/apache/mod_php5.sls
@@ -46,7 +46,7 @@ a2enmod php5:

{% endif %}

-{% if grains['os_family']=="Suse" %}
+{% if grains['os_family']=="Suse" or salt'grains.get' == 'SUSE' %}

Question regarding `register-site` pillar

Could you explain, what exactly needs to be provided in this block?

  # ``apache.debian_full`` formula additional configuration:
  register-site:
    # any name as an array index, and you can duplicate this section
    UNIQUE_VALUE_HERE:
      name: 'my name'
      path: 'salt://path/to/sites-available/conf/file'
      state: 'enabled'

What exactly must be contained in salt://path/to/sites-available/conf/file?
Isn't it being generated by sites block (apache.vhosts) already?

How can I add environment variables using apache formula

Hello every one,
I want to add some variables environment to the client vhost using apache formula (apache2.4):
This an example: (there is a {{name}} : {{value}} )
ENV_UPLOAD_PATH: '/home/user/htdocs/'
ENV_VIDEO_URL: 'https://example.com/player/'
ENV_VIDEO_PATH: '/home/user/htdocs/player/'
ENV_VIDEO_SSL_URL: 'https://example.com/player/'
ENV_VIDEO_SECURE_URL: 'https://example.com/player/'

I want that it will be like this in the virtualhost:

SetEnv ENV_UPLOAD_PATH /home/user/htdocs/
SetEnv ENV_VIDEO_URL https://example.com/player/
SetEnv ENV_VIDEO_PATH /home/user/htdocs/player/
SetEnv ENV_VIDEO_SSL_URL https://example.com/player/
SetEnv ENV_VIDEO_SECURE_URL https://example.com/player/

In the pillar.example in apache_formula I can't precise which option or parametre i can use to achieve my goal.
https://github.com/saltstack-formulas/apache-formula/blob/72dc03a4e774c0e26e37e6df5e11ca498c996300/pillar.example
Can any one help me to add those variables.
Thank you for your Help

Deprecated iteritems() method not forward-compatible with Python 3

Formulas iterating over dictionaries should use the items() method instead of iteritems() because the latter method has been removed from Python 3. While the items() method in Python 2 uses more memory than iteritems(), these dictionaries are typically small (e.g., sets of settings from Pillar).

mod_wsgi state fails to compile

Running the apache.mod_wsgi state on Ubuntu 16.04 with Salt 2017.7.2 throws the following error:

local:
    Data failed to compile:
----------
    Rendering SLS 'base:apache.mod_wsgi' failed: Jinja variable 'dict object' has no attribute 'conf_mod_wsgi'

Formula no longer works as is

With the changes made in the apt formula in saltstack-formulas/apt-formula@e1e06be all of the

include:
  - apt

declarations no longer work

Terrible-looking site configurations

If you don't need most of default values for {{standard.tmpl}} then you config will look like this:

<VirtualHost *:80>
    ServerName example.com







    LogLevel info
    ErrorLog /var/logs/error.log
    CustomLog /var/logs/access.log combined













    <Location "/">







    </Location>



</VirtualHost>

I think it's possible to make all these blank lines disapear. Mind if I try to with PR?

Please Support 'Location' directive in proxy.tmpl

In some cases, it is desirable to have the ability to use Apache as a bouncer for a proxied web host. Currently the proxy.tmpl does not support the 'Location' directive, and thus one cannot define access control for a proxy site unless they use the Formula_Append.

While Formula_Append works, it would be a 'nice to have' to add this into the possible config for proxy.tmpl

CentOS 7 uses Apache 2.2 syntax

CentOS 7 runs Apache 2.4, but the standard.tmpl template generates a 2.2-style configuration. This is because the default RedHat setting for use_require in map.jinja is False.

I fixed this by adding an override for CentOS 7, but I was wondering whether use_require is needed at all. osfingermap.yaml already maps the OS to the Apache version. Would it be possible to replace use_require with simple version checks in the template?

For example, replacing

{% if map.use_require %}
{% if dvals.get('Require') != False %}Require {{dvals.Require}}{% endif %}
{% else %}

with

{% if map.version == '2.4' %}
{% if dvals.get('Require') != False %}Require {{dvals.Require}}{% endif %}
{% else %}

Fix wrong file structure.

Move *.sls files into apache folder.
Move Pillar data into example file.

Apache 2.4 support?

Hi,

I've been trying to use this formula on a box that I'm building. I'm running into a few issues though, and they seem to stern from the fact that I'm using a Ubuntu Trusty box, which contains Apache 2.4.8, and that contains some bc-breaks:

• The Debian-specific 000-default has been renamed to 000-default.conf, which means the default config file will not be disabled, even when you use apache.debian_full. This seems easy to fix by checking if the apache version is 2.4, and appending .conf if this is the case.
• The config apache2.conf now ends with a line which says IncludeOptional sites-enabled/*.conf, meaning that when you add a "site" named "foo.com", it won't be picked up by Apache, and you'll have to name your site "foo.com.conf". It seems this is simple to fix by always appending .conf to the site name (unless it ends with .conf, naturally).
• The most irritating change: Order allow,deny and Allow from All no longer works, and has been changed to Require all denied or Require all granted. This means that the default template for a VirtualHost you're supplying will always result in a 403 Forbidden.

it seems this formula is really useful, but not so much when using Apache > 2.4.

EDIT: Normally, I would take a stab at it at fixing this myself, but I'm just getting started with using SaltStack, and I don't know the conventions yet.

Support for Redirect Code needed

Hi folks,

This formula does many wonderful things, however it lacks the ability to control the type of redirect in the redirect.tmpl. Redirect by default uses code 302 (temporary), however in many cases these must be 301 (permanent) redirects; when you're forcing a user from example.com to www.example.com for example.

It would be nice to provide an option like so:

RedirectCode: '301'        # This could also be 'permanent'
RedirectSource: '/'
RedirectTarget: 'http://www.example.net'

And in redirect.tmpl:

Redirect {% if site.get('RedirectCode') %}{{ site.RedirectCode }}{% endif %} {{ vals.RedirectSource }} {{ vals.RedirectTarget }}

Thanks for your hard work.

Debian Wheezy: file httpd.conf specified in apache2.conf but missing

Hello,

I'm trying this module, and with a very basic configuration, I always got an error about the service:

ERROR   ] output: apache2: Syntax error on line 214 of /etc/apache2/apache2.conf: Could not open configuration file /etc/apache2/httpd.conf: No such file or directory

In fact I see in /etc/apache2/apache2.conf

# Include all the user configurations:
Include httpd.conf

The problem is this file doesn't exist.
And looking at map.jinja is nowhere defined for Debian. (Debian use the apache2.conf not httpd.conf).

Support for installing/configuring MPM's.

Hi

Is there a chance of supporting the installation/configuration of prefork, worker or event mpm's? Thanks

fintan

Unable to issue a HTTP->HTTPS redirect on same virtual host name

As far as I know, there's no way to configure a HTTP to HTTPS redirection for the same virtual host, since:

• the virtual host configuration in Apache is somehow "keyed" with the hostname + the port number
• but the configuration in this formula is only keyed by the hostname (the port is a inner variable of the hostname)

Am I missing something?

CentOS 6 not configuring correctly

The apache.config state incorrectly applies 2.4 style syntax with Apache 2.2 on CentOS 6. This is because the osfingermap.yaml file assumes CentOS reports an osfinger of 'CentOS Linux-6' when it instead returns 'CentOS-6'.

I have submitted a pull request #181 to fix the issue for CentOS 6.

how to create extra LogDir and using apache/vhosts/standard.sls and hanling apache-reload?

I would like to create some extra dir for apache:sites, managed through apache.vhosts.standard state.

I would like to add log_dir creation before apache is restarted, dir are created by an external state create_dir.sls

But when running state.highstate, apache is complaining that error reloading, because a2ensite is launching apache-reload before LogDir are created.

What would be the way to add LogDir creation before vhosts?
I don't necessarily need to alter the formula, I just want to introduce my own step.

pillar top.sls

# Pillar top inclusions
base:
  '*':
    - customers
  'web*':
    - webserver # stantdard pillar config
    - auto.webconfig # sites are separated here

I added a LogDir key for that purpose (could be dirname calculated, but that's another story)

auto/webconfig.sls

apache:
  sites:
    client1-domain.fr:
      # template_file: salt://webserver/vhosts/minimal.tmpl
      ServerName: client1-domain.fr
      ServerAlias: www.client1-domain.fr
      ServerAdmin: [email protected]

      LogLevel: warn
      LogDir: /home/client1/logs
      ErrorLog: /home/client1/logs/error.log
      CustomLog: /home/client1/logs/access.log

      DocumentRoot: /home/client1/vhost/www

      Directory:
        default:
          Options: -Indexes +FollowSymLinks
          Order: allow,deny
          Allow: from all
          Require: all granted
          AllowOverride: None

state

top.sls

base:
  '*':
    - fail2ban
    - salt-minion
  'web*':
    - apache
    - apache.modules
    - apache.mod_fastcgi
    - webserver.php-fpm
    - webserver.create_dir
    - apache.vhosts.standard

webserver/create_dir.sls

# create users dir not created by the formula
#
{% for id, site in salt['pillar.get']('apache:sites', {}).items() %}
{% set logdir = site.get('LogDir') %}

{{ id }}-logdir:
  file.directory:
    - unless: test -d {{ logdir }}
    - name: {{ logdir }}
    - makedirs: True
    - allow_symlink: True
{% endfor %}

Unexpected keyword argument 'merge' in map.jinja

Salt-master: Ubuntu 12.04

This issue can be reproduced on minion with CentOS 6.4x86_64 and Ubuntu 12.04.

sudo salt minion1 state.highstate

minion1:

Data failed to compile:

Rendering SLS apache failed, render error: Traceback (most recent call last):

File "/usr/lib/python2.6/site-packages/salt/utils/templates.py", line 63, in render_tmpl
output = render_str(tmplstr, context, tmplpath)
File "/usr/lib/python2.6/site-packages/salt/utils/templates.py", line 116, in render_jinja_tmpl
output = jinja_env.from_string(tmplstr).render(**context)
File "/usr/lib64/python2.6/site-packages/jinja2/environment.py", line 669, in render
return self.environment.handle_exception(exc_info, True)
File "", line 1, in top-level template code
File "/usr/lib64/python2.6/site-packages/jinja2/environment.py", line 713, in make_module
return TemplateModule(self, self.new_context(vars, shared, locals))
File "/usr/lib64/python2.6/site-packages/jinja2/environment.py", line 769, in init
self._body_stream = list(template.root_render_func(context))
File "/var/cache/salt/minion/files/base/apache/map.jinja", line 1, in top-level template code
{% set apache = salt['grains.filter_by']({
TypeError: filter_by() got an unexpected keyword argument 'merge'

Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/salt/state.py", line 1904, in render_state
rendered_sls=mods
File "/usr/lib/python2.6/site-packages/salt/template.py", line 68, in compile_template
ret = render(input_data, env, sls, **render_kwargs)
File "/usr/lib/python2.6/site-packages/salt/renderers/jinja.py", line 41, in render
tmp_data.get('data', 'Unknown render error in jinja renderer')
SaltRenderError: Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/salt/utils/templates.py", line 63, in render_tmpl
output = render_str(tmplstr, context, tmplpath)
File "/usr/lib/python2.6/site-packages/salt/utils/templates.py", line 116, in render_jinja_tmpl
output = jinja_env.from_string(tmplstr).render(**context)
File "/usr/lib64/python2.6/site-packages/jinja2/environment.py", line 669, in render
return self.environment.handle_exception(exc_info, True)
File "", line 1, in top-level template code
File "/usr/lib64/python2.6/site-packages/jinja2/environment.py", line 713, in make_module
return TemplateModule(self, self.new_context(vars, shared, locals))
File "/usr/lib64/python2.6/site-packages/jinja2/environment.py", line 769, in init
self._body_stream = list(template.root_render_func(context))
File "/var/cache/salt/minion/files/base/apache/map.jinja", line 1, in top-level template code
{% set apache = salt['grains.filter_by']({
TypeError: filter_by() got an unexpected keyword argument 'merge'

The state can be provided, after deleting this from map.jinja.

"merge=salt'pillar.get')"

map.jinja merges pillar 'apache:lookup' but pillar.example has no 'lookup' attribute

map.jinja merges with the "apache:lookup" pillar in the last line; however, pillar.example has no "apache:lookup" section. If I go back over a year it is still like this (apache:lookup in map.jina and no "lookup" in pillar.example) - so perhaps I'm confused on how "lookup" is supposed to work? Is this some special keyword?

At the very least this is probably confusing other people because the official salt docs show "lookup" in an actual pillar file for apache here

Is there something I'm not getting or is there an issue with the formula?

PR #45 broke default DocumentRoot

In PR #45 code was added that does not allow for the default DocumentRoot.

Thus all existing Salt states that are using the default are now broken and returning the following error:

----------
          ID: www.host.com-documentroot
    Function: file.directory
        Name: None
      Result: False
     Comment: Specified file None is not an absolute path
     Started: 23:25:55.852689
    Duration: 4.705 ms
     Changes:

Example problem:

{{ id }}-documentroot:
  file.directory:
    - unless: test -d {{ site.get('DocumentRoot') }}
    - name: {{ site.get('DocumentRoot') }}

This is contrary to the existing behavior of the virtual host templates which implements the default thusly:

site.get('DocumentRoot', '{0}/{1}'.format(map.wwwdir, sitename))

@thornycrackers please fix.

Everyone else, if you use default DocumentRoot I recommend you don't update to the latest version of this repo. @1949ff4 is still a good version.

service.running with enable: True and mod_watch is deprecated

https://github.com/saltstack-formulas/apache-formula/blob/master/apache/init.sls#L8

Adding a watch to service.running give me the following warning :

----------
          ID: apache
    Function: service.running
        Name: apache2
      Result: False
     Comment: Failed to start the service
     Started: 
    Duration: 
     Changes:   
              ----------
              apache2:
                  False
    Warnings: 'enable' is an invalid keyword argument for 'service.mod_watch'.
              If you were trying to pass additional data to be used in a
              template context, please populate 'context' with 'key: value'
              pairs. Your approach will work until Salt Lithium is out. Please
              update your state files.

Conflict ID when using apache.mod_fcgid and fcgid in module list apache.modules

    Data failed to compile:
----------
    Detected conflicting IDs, SLS IDs need to be globally unique.
    The conflicting ID is 'a2enmod fcgid' and is found in SLS 'base:apache.modules' and SLS 'base:apache.mod_fcgid'

This could be fixed by using a specific id in the apache.mod_fcgid.

standard.sls fails if docroot is a symlink

what it says :)

needs allow_symlink added to the file.directory state...

not sure if this needs to be configurable...

Support SSL in redirect.tmpl

SSL Redirects do some funny stuff if you do not turn the engine on and present certs. In my case mail.example.com presented the certs for dev.example.com and failed redirect to mail.example.org because this misconfiguration triggered a browser error.

I've passed the SSL settings through the Formula_Append, however redirect.tmpl should support this as it is required to properly redirect over HTTPS

Cannot include apache.debian_full

When one tries to include apache.debian_full the following error occurs:

 --- foo.sls
 include:
  - apache.debian_full

 --- salt '*' state.highstate
 foo:
     Data failed to compile:
 ----------
     Rendering SLS "base:apache.debian_full" failed: Conflicting ID "extend"

which is due to the multiple extends in that state, which should be merged into one.

apache.config and apache states have a conflicting ID

The vhost directory is defined as an ID in both apache/config.sls and apache/init.sls. This is invalid and causes a rendering exception when running the config state:

Detected conflicting IDs, SLS IDs need to be globally unique.
    The conflicting ID is '/etc/apache2/sites-available' and is found in SLS 'base:apache' and SLS 'base:apache.config'