Reliance on mime.types

[jacksgt]

Hey there,

excellent puppet module!

However, while experimenting with this module, I have stumbled upon a problem: the module blindly relies on the presence of a mime.types files (specifically in

puppet-nginx/templates/conf.d/nginx.conf.erb

Line 69 in 0ef72eb

include <%= @conf_dir %>/mime.types;

). While this will work for most distributions, it does not work when using a custom config directory (nginx::conf_dir).

In my case, the configuration gets generated as follows (nginx.conf):

# MANAGED BY PUPPET
user www-data;
worker_processes 1;
worker_rlimit_nofile 1024;
...
http {

  include       /mnt/etc/nginx/mime.types;
  default_type  application/octet-stream;
  ...
  include /mnt/etc/nginx/conf.d/*.conf;
  include /mnt/etc/nginx/sites-enabled/*;
}

Since /mnt/etc/nginx was created by the module itself, it is initially empty and therefore lacks mime.types.

Upon startup, nginx then complains:

nginx: [emerg] open() "/mnt/etc/nginx/mime.types" failed (2: No such file or directory) in /mnt/etc/nginx/nginx.conf:17

[jacksgt]

I see two possible ways out of this.

1. Make the mime.type-file path configurable.
2. Include a mime.type-file in this module and ensure it is present at the required location.

I'd prefer the second options, what do you think?

[ekohl]

I think the first option is the least invasive one. The mime types file contents could easily go out of date or be different on various distros.

[martialblog]

@ekohl I thought about maybe having a simple erb that gets filed with a hash, since the mime types file is rather simple. But yes, there could be variation in distros.

[jacksgt]

@martialblog Excellent idea!
Since the Nginx configuration is managed by this module anyway, I don't think the variations between distros are a problem.

[martialblog]

I wrote a little example of a template based solution.

https://github.com/vision-it/puppet-nginx/commit/3a9a68d13cba85c07b3c7907ca0608573474d281