GithubHelp home page GithubHelp logo

saltstack-formulas / apache-formula Goto Github PK

View Code? Open in Web Editor NEW
50.0 46.0 286.0 1.46 MB

Set up and configure the Apache HTTP server

Home Page: http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html

License: Other

SaltStack 30.34% Ruby 6.76% JavaScript 1.79% Shell 2.22% Jinja 58.90%

apache-formula's Introduction

apache

Travis CI Build Status Semantic Release

Formulas to set up and configure the Apache HTTP server on GNU/Linux, FreeBSD, and Windows OS.

Table of Contents

General notes

See the full SaltStack Formulas installation and usage instructions.

If you are interested in writing or contributing to formulas, please pay attention to the Writing Formula Section.

If you want to use this formula, please pay attention to the FORMULA file and/or git tag, which contains the currently released version. This formula is versioned according to Semantic Versioning.

See Formula Versioning Section for more details.

Contributing to this repo

Commit message formatting is significant!!

Please see How to contribute for more details.

Available states

apache

Installs the Apache package and starts the service.

apache.config

Metastate to apply all apache configuration

apache.config.file

Configures apache based on os_family

apache.config.flags

Configures apache flags on SuSE

apache.config.certificates

Deploy SSL certificates from pillars

apache.config.modules

Metastate to Enable and disable Apache modules.

apache.config.modules.mod_mpm

Configures the apache mpm modules on Debian mpm_prefork, mpm_worker or mpm_event (Debian Only)

apache.config.modules.mod_rewrite

Enabled the Apache module mod_rewrite (Debian and FreeBSD only)

apache.config.modules.mod_proxy

Enables the Apache module mod_proxy. (Debian and FreeBSD only)

apache.config.modules.mod_proxy_http

Enables the Apache module mod_proxy_http and requires the Apache module mod_proxy to be enabled. (Debian Only)

apache.config.modules.mod_proxy_fcgi

Enables the Apache module mod_proxy_fcgi and requires the Apache module mod_proxy to be enabled. (Debian Only)

apache.config.modules.mod_wsgi

Installs the mod_wsgi package and enables the Apache module.

apache.config.modules.mod_actions

Enables the Apache module mod_actions. (Debian Only)

apache.config.modules.mod_headers

Enables the Apache module mod_headers. (Debian Only)

apache.config.modules.mod_pagespeed

Installs and Enables the mod_pagespeed module. (Debian and RedHat Only)

apache.config.modules.mod_perl2

Installs and enables the mod_perl2 module (Debian and FreeBSD only)

apache.config.modules.mod_geoip

Installs and enables the mod_geoIP (RedHat only)

apache.config.modules.mod_php5

Installs and enables the mod_php5 module

apache.config.modules.mod_cgi

Enables mod_cgi. (FreeBSD only)

apache.config.modules.mod_fcgid

Installs and enables the mod_fcgid module (Debian only)

apache.config.modules.mod_fastcgi

Installs and enables the mod_fastcgi module

apache.config.modules.mod_dav_svn

Installs and enables the mod_dav_svn module (Debian only)

apache.config.modules.mod_security

Installs an enables the Apache mod_security2 WAF using data from Pillar. (Debian and RedHat Only)

Allows you to install the basic Core Rules (CRS) and some basic configuration for mod_security2

apache.config.modules.mod_security.rules

This state can create symlinks based on basic Core Rules package. (Debian only) Or it can distribute a mod_security rule file and place it /etc/modsecurity/

apache.config.modules.mod_socache_shmcb

Enables mod_socache_shmcb. (FreeBSD only)

apache.config.modules.mod_ssl

Installs and enables the mod_ssl module (Debian, RedHat and FreeBSD only)

apache.config.modules.mod_suexec

Enables mod_suexec. (FreeBSD only)

apache.config.modules.mod_vhost_alias

Enables the Apache module vhost_alias (Debian Only)

apache.config.modules.mod_remoteip

Enables and configures the Apache module mod_remoteip using data from Pillar. (Debian Only)

apache.config.modules.mod_xsendfile

Installs and enables mod_xsendfile module. (Debian Only)

apache.config.own_default_vhost

Replace default vhost with own version. By default, it's 503 code. (Debian Only)

apache.config.no_default_vhost

Remove the default vhost. (Debian Only)

apache.config.vhosts.standard

Configures Apache name-based virtual hosts and creates virtual host directories using data from Pillar.

Example Pillar:

apache:
  sites:
    example.com: # must be unique; used as an ID declaration in Salt; also passed to the template context as {{ id }}
      template_file: salt://apache/vhosts/standard.tmpl

When using the provided templates, one can use a space separated list of interfaces to bind to. For example, to bind both IPv4 and IPv6:

apache:
  sites:
    example.com:
      interface: '1.2.3.4 [2001:abc:def:100::3]'

apache.config.manage_security

Configures Apache's security.conf options by reassinging them using data from Pillar.

apache.config.modules.mod_status

Configures Apache's server_status handler for localhost

apache.config.debian_full

Installs and configures Apache on Debian and Ubuntu systems.

apache.config.clean

Metastate to cleanup all apache configuration.

apache.clean

Stops the Apache service and uninstalls the package.

These states are ordered using the order declaration. Different stages are divided into the following number ranges:

  1. apache will use 1-500 for ordering
  2. apache will reserve 1 -100 as unused
  3. apache will reserve 101-150 for pre pkg install
  4. apache will reserve 151-200 for pkg install
  5. apache will reserve 201-250 for pkg configure
  6. apache will reserve 251-300 for downloads, git stuff, load data
  7. apache will reserve 301-400 for unknown purposes
  8. apache will reserve 401-450 for service restart-reloads
  9. apache WILL reserve 451-460 for service.running
  10. apache will reserve 461-500 for cmd requiring operational services

Example Pillar:

apache:
  register-site:
    # any name as an array index, and you can duplicate this section
    {{UNIQUE}}:
      name: 'my name'
      path: 'salt://path/to/sites-available/conf/file'
      state: 'enabled'

  sites:
    # Force SSL: Redirect from 80 to 443
    example.com:
      port: 80
      template_file: salt://apache/vhosts/redirect.tmpl
      RedirectSource: 'permanent /'
      # Trailing slash is important
      RedirectTarget: 'https://example.com/'
    example.com_ssl:
      port: 443
      ServerName: example.com
      SSLCertificateFile: /path/to/ssl.crt
      SSLCertificateKeyFile: /path/to/ssl.key
      SSLCertificateChainFile: /path/to/ssl.ca.crt

apache.config.vhosts.clean

Remove non-declared virtual hosts, and deactivates the service.

apache.config.vhosts.cleanup

Remove non-declared virtual hosts, but keeps the service running.

Testing

Linux testing is done with kitchen-salt.

Requirements

  • Ruby
  • Docker
$ gem install bundler
$ bundle install
$ bin/kitchen test [platform]

Where [platform] is the platform name defined in kitchen.yml, e.g. debian-9-2019-2-py3.

bin/kitchen converge

Creates the docker instance and runs the apache main states, ready for testing.

bin/kitchen verify

Runs the inspec tests on the actual instance.

bin/kitchen destroy

Removes the docker instance.

bin/kitchen test

Runs all of the stages above in one go: i.e. destroy + converge + verify + destroy.

bin/kitchen login

Gives you SSH access to the instance for manual testing.

Testing with Vagrant

Windows/FreeBSD/OpenBSD testing is done with kitchen-salt.

Requirements

  • Ruby
  • Virtualbox
  • Vagrant

Setup

$ gem install bundler
$ bundle install --with=vagrant
$ bin/kitchen test [platform]

Where [platform] is the platform name defined in kitchen.vagrant.yml, e.g. windows-81-latest-py3.

Note

When testing using Vagrant you must set the environment variable KITCHEN_LOCAL_YAML to kitchen.vagrant.yml. For example:

$ KITCHEN_LOCAL_YAML=kitchen.vagrant.yml bin/kitchen test      # Alternatively,
$ export KITCHEN_LOCAL_YAML=kitchen.vagrant.yml
$ bin/kitchen test

Then run the following commands as needed.

bin/kitchen converge

Creates the Vagrant instance and runs the apache main states, ready for testing.

bin/kitchen verify

Runs the inspec tests on the actual instance.

bin/kitchen destroy

Removes the Vagrant instance.

bin/kitchen test

Runs all of the stages above in one go: i.e. destroy + converge + verify + destroy.

bin/kitchen login

Gives you RDP/SSH access to the instance for manual testing.

apache-formula's People

Contributors

aboe76 avatar alxwr avatar arthurzenika avatar bmwiedemann avatar bradthurber avatar daschatten avatar dexbleeker avatar eliasp avatar genuss avatar gravyboat avatar ixs avatar javierbertoli avatar kadogo avatar landergate avatar multani avatar myii avatar nmadhok avatar noelmcloughlin avatar porunov avatar puneetk avatar rhertzog avatar scambra avatar semantic-release-bot avatar stp-ip avatar supertux88 avatar tangresh avatar techhat avatar vincentfretin avatar whiteinge avatar wwentland avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

apache-formula's Issues

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'

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.

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'

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' %}

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?

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.

/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

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?

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'

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 %}

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?

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')"

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.

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.

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.

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

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?

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.

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.

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).

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.

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

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

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

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

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.

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

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.

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.

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?

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 ?

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!

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'

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.

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'

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 %}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.