search

voxpupuli / puppet-postfix

Puppet postfix module
Apache License 2.0
70 stars 173 forks source link

Problem with hardcoded "hash" (=Berkeley DB) on distros phasing out Berkeley DB #335

Closed timdeluxe closed 2 years ago

timdeluxe commented 2 years ago

Affected Puppet, Ruby, OS and module versions/distributions

How to reproduce (e.g Puppet code you use)

Use module with mta set to true: class { 'postfix': mta => true }

What are you seeing

main.cf gets config lines with "hash:". mails do not get delivered, see mail logfile (shortened to important stuff): postfix/cleanup[xxxxx]: warning: hash:/etc/postfix/virtual is unavailable. unsupported dictionary type: hash postfix/cleanup[xxxxx]: warning: hash:/etc/postfix/virtual lookup error for "root@my.server.example.com" postfix/cleanup[xxxxx]: warning: ABCDEF123: virtual_alias_maps map lookup problem for root@my.server.example.com -- message not accepted, try again later messages hanging in queue and do not get delivered

What behaviour did you expect instead

mails get delivered

Output log

see above

Any additional information you'd like to impart

Oracle (owning Berkeley DB) changed the license of Berkeley DB in version 6 to AGPL, which makes it incompatible as per my understanding (forgive me anything wrong here, i am no license expert) to ship it with other GPLv2 licensed software. Looks like this change was already made many years ago, but now the first distros make action. Alpine is removing it and already has removed the "hash" support for postfix, see [1]. SLES is deprecating it since SLES15-SP3 - in the default install it is already gone for postfix, if you want to have it back, you need to take manual action - see [2]. Debian/Ubuntu had a discussion back in 2013 (!!) on their "legal" mailing list with no real result [3] - they currently stick to berkeley DB 5.x in current and future releases. Don't know if that is carved in stone or if they just ignore the issue and get hit by it later.

So at least there is one affected supported distro (Alpine) and one affected distro (SLES) which is not officially supported, but where this module works pretty well apart from this issue.

The module has places, where "hash" is hardcoded, example: https://github.com/voxpupuli/puppet-postfix/blob/master/manifests/mta.pp#L39 "hash" basically means Berkeley DB, see [4] - useful replacements are cdb or lmdb. cdb looks nice, since it is in the core since postfix 2.2, lmdb requires that postfix was compiled with support for it. However if the module is changed due to this issue, it should be made more flexible and allow parameters to define the lookup db type, instead of hardcoding it again. "postmap" by the way sticks to the "default_database_type" postfix setting, if none is given. But it is then important that the same type is used in the main.cf (etc.) settings. Also the generated files have a different suffix. So hardcoded suffixes like here https://github.com/voxpupuli/puppet-postfix/blob/master/manifests/map.pp#L84 also need a change.

I would offer to make a code change and raise a PR, but before starting that, i am interested in your feedback about that.

[1] https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0#Deprecation_of_Berkeley_DB_.28BDB.29 [2] https://www.suse.com/releasenotes/x86_64/SUSE-SLES/15-SP3/index.html#jsc-SLE-12191 [3] https://lists.debian.org/debian-legal/2013/07/msg00000.html [4] http://www.postfix.org/DATABASE_README.html#types

timdeluxe commented 2 years ago

While working on the PR (we need that anyway), i saw that there is hiera data and config file templates for SLES. Shouldn't it then be stated in metadata.json, that SLES is supported as well?

smortex commented 2 years ago

While working on the PR (we need that anyway), i saw that there is hiera data and config file templates for SLES. Shouldn't it then be stated in metadata.json, that SLES is supported as well?

This generally happen when the support in kinda "unofficial", e.g. when I add support for FreeBSD to a module, I generally don't add it to metadata.json right away, only after being using it for some time. If you have been using the module on SLES for some time with great success, it makes sense to fill-in a PR to add it to metadata.json :wink:

timdeluxe commented 2 years ago

While working on the PR (we need that anyway), i saw that there is hiera data and config file templates for SLES. Shouldn't it then be stated in metadata.json, that SLES is supported as well?

This generally happen when the support in kinda "unofficial", e.g. when I add support for FreeBSD to a module, I generally don't add it to metadata.json right away, only after being using it for some time. If you have been using the module on SLES for some time with great success, it makes sense to fill-in a PR to add it to metadata.json 😉

Well, we are just getting started with using it on SLES, hence this issue and the referenced PR. I agree with you that adding it does only make more sense, if a broader group has made longer experience with it... So, lets leave metadata.json as it is for now...