* silence errorneous output when not generating reports
* remove incorrect variable assignment
* change error messages and logic when reports turned off
* changing warn -> inf
Co-authored-by: Charles Harris
Co-authored-by: Georg Lauterbach
* documentation and script updates trying to fix#1647
* preparations for refactoring target/bin/
* complete refactor for target/bin/
* changing script output slightly
* outsourcing functions in `bin-helper.sh`
* re-wrote linting to allow for proper shellcheck -x execution
* show explanation for shellcheck ignore
* adding some more information
* added option to use non-default network-interface (#1227)
* minor (stylistic) changes
* properly working with Bash arrays for CONTAINER_NETWORKS
* cleanup to trigger rebuild
* added CODE_OF_CONDUCT to trigger rebuild
Previously, only postfix-relaymap.cf and postfix-accounts.cf would be
used to populate the relayhost_map file.
Now, also use postfix-virtual.cf when present. To me, there is nothing
absurd about sending mail "From:" a virtual account (or more
specifically its domain) so it makes sense that when a $RELAY_HOST is
defined it should be used for virtual accounts as well.
check-for-changes.sh did not have a special case to handle lines in
postfix-relaymap.cf consisting of only a domain (indicating that said
domain should never be relayed). This case is handled by
start-mailserver.sh so when such a line existed, things would work well
until a config file update was detected by check-for-changes.sh. After
that, the generated relayhost_map file would be corrupted.
Fixed by factoring a 'populate_relayhost_map' function out of
start-mailserver.sh and into helper_functions.sh and reusing it in
check-for-changes.sh.
Note: There are certainly quite a few more pieces of code that could be
refactored in a similar fashion.
Note2: check-for-changes.sh would previously never update the
relayhost_map file when $ENABLE_LDAP was set to 1. I don't think this
was intended —there is after all no such condition in
start-mailserver.sh— and so this condition no longer applies.
If a change to one of the tracked files happened soon after (<1 second?)
a previously detected change, it could end up going undetected. In
particular, this could cause integration tests to fail (see next
commits).
Fixed by computing the new checksum file _before_ checking for changes.
