Giter VIP home page Giter VIP logo

puppet-dovecot's Introduction

puppet-dovecot

Build Status Puppet Forge Puppet Forge

Table of Contents

  1. Description
  2. Usage
  3. Reference
  4. Development

Description

This module installs and manages the dovecot imap server and its plugins, and provides resources and functions to configure the dovecot system. It does, however, not configure any of those systems beyond the upstream defaults.

This module is intended to work with Puppet 5 and 6, tested dovceot and OS versions are listed below. Patches to support other setups are welcome.

Usage

What this module affects

By default, this module...

  • installs the dovecot package
  • recursively purges all dovecot config files

Configuration options

While on a puppet-managed host, splitting the config into multiple conf.d files provides not much advantage, this module supports managing both the dovecot.conf file and several conf.d files.

The dovecot class takes two parameters, $config for dovecot.conf entries and $configs for conf.d file entries:

class { 'dovecot':
  plugins => ['imap', 'lmtp'],
  config => {
    protocols => 'imap lmtp',
    listen    => '*, ::',
  },
  configs => {
    '10-auth' => {
      passdb => {
        driver => 'passwd-file',
        args   => 'username_format=%u /etc/dovecot/virtual_accounts_passwd',
      },
    },
    '10-logging' => {
      log_path => 'syslog',
    },
  }
}

This can be conveniently used from hiera:

dovecot::plugins:
  - imap
  - lmtp
  - sieve
dovecot::config:
  protocols: imap sieve lmtp
  hostname: "%{::fqdn}"
dovecot::configs:
  '10-auth':
    disable_plaintext_auth: yes
    passdb:
      driver: passwd-file
      args: scheme=CRYPT username_format=%u /etc/dovecot/virtual_accounts_passwd
  '10-master':
    default_process_limit: 200
    default_client_limit: 2000
    service lmtp:
      unix_listener /var/spool/postfix/private/dovecot-lmtp:
        user: postfix
        group: postfix
        mode: '0600'
  '10-ssl':
    ssl: yes
    ssl_cert: '</etc/dovecot/ssl/dovecot.crt'
    ssl_key: '</etc/dovecot/ssl/dovecot.key'

For advanced use-cases you can also use the provided dovecot::create_config_resources and dovecot::create_config_file_resources functions, that are used to handle the $config and $configs parameters.

If you want to use the dovecot::config resource directly, the easiest way is to put both the file (optional) and the hierachical config key into the resource title:

dovecot::config {
  'protocols': value => 'imap lmtp';
  'listen':
     value => '*, ::',
     comment => 'Listen on all interfaces',
  ;
  '10-auth:passdb.driver': value => 'passwd-file';
  '10-auth:passdb.args': value => 'username_format=%u /etc/dovecot/virtual_accounts_passwd'
}

But you can also specify them separately:

dovecot::config { 'dovecot passdb driver':
  file     => '10-auth',
  sections => ['passdb'],
  key      => 'driver',
  value    => 'passwd-file',
}

By default all regular config files are created with mode 0644, but this can be changed by creating the dovecot::configfile instance manually and specifying the $mode param, or by setting the global dovecot::configs_mode parameter/hiera key.

External config files

In some cases, dovecot requires an external config file to be passed as a config value. This is especially the case for SQL- and LDAP-based userdbs.

These external config files are using a similar syntax, but are parsed by a different parser (and at a different point of time), as explained in the Dovecot wiki.

This module supports such external config files using the dovecot::extconfigfile type, or the dovecot::extconfigs parameter/hiera key:

dovecot::configs:
  '10-auth':
    passdb:
      driver: sql
      args: /etc/dovecot/dovecot-sql.conf.ext
dovecot::extconfigs:
  'dovecot-sql.conf.ext':
     driver: pgsql
     connect: host=sql.example.com dbname=virtual user=virtual password=blarg
     default_pass_scheme: SHA256-CRYPT
     password_query: "SELECT email as user, password FROM virtual_users WHERE email='%u';"

Since external config files often contain sensitive information like database passwords, they are set to mode 0600 by default. This can be changed using the type's $mode parameter, or the global dovecot::extconfigs_mode parameter/hiera key.

If you need to specify additional content in the file, like dict maps, you can use the extended notation that takes an entries and an additional_content key:

dovecot::extconfigs:
  'dovecot-dict-sql.conf.ext':
    entries:
      connect: host=localhost dbname=mails user=sqluser password=sqlpass
    additional_content: |+
      map {
        pattern = shared/shared-boxes/user/$to/$from
        table = user_shares
        value_field = dummy

        fields {
          from_user = $from
          to_user = $to
        }
      }

NOTE: These external config files are usually stored in /etc/dovecot. Unfortunately, the example-config delivered with Dovecot also contains .conf.ext files in conf.d/, which are !included from 10-auth.conf. Please note that these are not external config files as explained here, they are included and parsed by the normal config parser. The example config splits them out to provide multiple options the user can easily choose one from. In a puppet-based setup, this should not be necessary, and is thus currently not supported by this module. Please provide a valid use-case as a bug report, if you have one.

Poolmon configuration

For multi-server setups it is possible to enable built-in support for Poolmon:

dovecot::poolmon_manage: true
dovecot::poolmon_version: '0.6'

dovecot::poolmon_config:
  scan_interval: 30
  check_timeout: 5
  log_debug: false
  logfile: 'syslog'
  check_port:
    - 110
    - 143
  check_ssl:
    - 993
  socket: '/var/run/dovecot/director-admin'
  lockfile: '/var/run/poolmon.pid'

NOTE: $dovecot::poolmon_config uses "hash" merge behavior during lookup (see Merge behavior below).

Reference

Classes and parameters are documented in REFERENCE.md.

Merge behavior

Although this module defaults to "deep" merge behavior for lookups, there's one notable exception. The poolmon configuration $dovecot::poolmon_config utilizes the "hash" merge behavior. This way it is possible to replace default values when necessary, i.e. the check_port item.

Development

Contributing

Please use the GitHub issues functionality to report any bugs or requests for new features. Feel free to fork and submit pull requests for potential contributions.

puppet-dovecot's People

Contributors

c33s avatar fraenki avatar lightning- avatar mat1010 avatar mgariepy avatar oxc avatar sazzle2611 avatar trefzer avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

puppet-dovecot's Issues

dovecot::extconfigs just printing additional_content

I am currently using the module to set up a dovecot server. I am trying to fill the file auth-sql.conf.ext with the following content:

passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
userdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}

Declaring it in Hiera like this:

dovecot::extconfigs:
  'auth-sql.conf.ext':
    additional_content: |+
      passdb {
        driver = sql
        args = /etc/dovecot/dovecot-sql.conf.ext
      }
      userdb {
        driver = sql
        args = /etc/dovecot/dovecot-sql.conf.ext
      }

ends up with content like this:

additional_content = passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
userdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}

Whats the correct way to solve this?

Purging config files under conf.d

Unmanaged configs within /etc/dovecot are being wiped out already by
https://github.com/oxc/puppet-dovecot/blob/855c0d85bd206eafeb339b2d073c55e6dbe5d77f/manifests/configuration.pp#L4-L12
Is there anything that would speak against adding the same purge mechanism to the underlying conf.d directory? Right now the conf.d is left untouched if there are already untouched example configs (like it's the case for e.g. EL7):
https://github.com/oxc/puppet-dovecot/blob/855c0d85bd206eafeb339b2d073c55e6dbe5d77f/manifests/configuration.pp#L15-L17

Multiple passdb configs in 10-auth

Hi there,

I'm trying to implement multiple passdb's in my 10-auth config as users need to authenticate against two domains, however I don't seem to see a way to do this.

I can define the LDAP config within the .ext files however defining multiple passdb's isn't possible due to using duplicate key values.

      '10-auth'    => {
        disable_plaintext_auth => 'yes',
        auth_default_realm     => 'domain.co.uk',
        auth_username_char     => 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@\'',
        auth_mechanisms        => 'plain login',
        passdb                 => {
          driver => 'ldap',
          args   => '/etc/dovecot/dovecot-pass-method1-ldap.conf.ext',
        },
        passdb                 => {
          driver => 'ldap',
          args   => '/etc/dovecot/dovecot-pass-method2-ldap.conf.ext',
        },
        userdb                 => {
          driver => 'ldap',
          args   => '/etc/dovecot/dovecot-user-method1-ldap.conf.ext',
        },
        userdb                 => {
          driver => 'ldap',
          args   => '/etc/dovecot/dovecot-user-method2-ldap.conf.ext',
        },
      },

I can't work out a way that this could be done, I was thinking of using an !include configuration but this isn't supported with the whole key value pair setup.

Has anyone been able to setup dual authentication using this module?

Cheers.

Stdlib dependency outdated

The current stdlib requirement of < 6.0.0 is outdated due to the latest stdlib releases which are > 6.0.0. The requirement of stdlib should be bumped to < 7.0.0 to avoid issues during installing / upgrading the module itself.

Release on forge

Please let me know when this module is released on the puppet forge under the new namespace, so I can deprecate the old module.

Hashes in extconfig

Is there a way adding hashes into an extconfig? Most of my extconfigs follow the rules of the module and it works great so far. But I have one extconfig, for acls that are saved in the database, that would require a hash.

The final extconfig should look like this:

connect = host=127.0.0.1 dbname=mail user=username password=password
map {
  pattern = shared/shared-boxes/user/$to/$from
  table = user_shares
  value_field = dummy
  fields {
    from_user = $from
    to_user = $to
  }
}
map {
  pattern = shared/shared-boxes/anyone/$from
  table = anyone_shares
  value_field = dummy

  fields {
    from_user = $from
  }
}

The extconfigs resource I tried it with looks like this

dovecot::extconfigs:
  'dovecot-dict-sql.conf.ext':
    connect: "host=127.0.0.1 dbname=mail user=imap%{serverid} password=%{lookup('imap_mysql_password')}"
    map:
      pattern: shared/shared-boxes/user/$to/$from
      table: user_shares
      value_field: dummy
      fields:
        from_user: $from
        to_user: $to
    map:
      pattern: shared/shared-boxes/anyone/$from
      table: anyone_shares
      value_field: dummy
      fields:
        from_user: $from

Right now this fails, since only strings are allowed in the key: value mappings. Is there a way arround it?

Thanks in advance

Update link to Forge

This repo's "about box" still links to this module in the oxc namespace on the Forge.

Have you planned to make ext files/all config files manageable?

picked your module instead of um/dovecot because i really like the hiera syntax and the flexible way i can configure all conf files in conf.d but then i haven't found a direct way to manage all the ext files like /etc/dovecot/dovecot-sql.conf.ext or /etc/dovecot/conf.d/auth-sql.conf.ext

normally dovecot uses the args setting with a file path for the settings:

/etc/dovecot/conf.d/auth-sql.conf.ext:

...
passdb {
  driver = sql

  # Path for SQL configuration file, see example-config/dovecot-sql.conf.ext
  args = /etc/dovecot/dovecot-sql.conf.ext
}
...

/etc/dovecot/dovecot-sql.conf.ext:

driver = mysql
connect = host=127.0.0.1 dbname=mailserver user=mailuser password=ChangeMe  <- use your database access password instead
default_pass_scheme = SHA256-CRYPT
password_query = SELECT email as user, password FROM virtual_users WHERE email='%u';

is it possible to set this with your module?

$extconfigfile missing in init.pp ?

Are we missing $extconfigfile in the init.pp so we can use extconfig and extconfigfile both ?

I'm not sure but is this based on the current dovecot design as I now use $configs to fill my dovecot-ldap.conf.ext for an example and I doubt if this is the right way.

notation for empty section

Hey,

I am having a hard time finding a way to declare an empty section, like

plugin {
}

This notiation…

plugin        => {},

… gets ignored unless you put configuration entries in the brackets.

Do you have a suggestion on how to write the puppet code?

Thanks and best.

dovecot::sieve does not work with `source` anymore

The dovecot::sieve resource now requires content to be a non-optional String, which ironically still defaults to undef ;)

define dovecot::sieve (
String $content = undef,

However, both the content and the source attributes are passed through to the file resource, and are mutually exclusive. So there is no way to set source, since content must be set to a string, which breaks the file resource ("You cannot specify more than one of content, source, target")

The easiest solution is probably to make content Optional[String], and let the file resource complain about a missing property.

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.