New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
scripts: small refactorings #2485
Conversation
This was not actually needed (and not a good idea either - ask me how I know: "warning: error loading certificate chain: key at index 1 in /etc/dms/tls/key does not match the certificate" in my log due to my custom Postfix `main.cf`). It turns out the _setup_ssl call would just set the exact same files again, which does absolutely nothing (except messing with custom configurations...). I therefore removed this portion again. I left the checksum generation for the files in the `_monitored_files_checksums` function because restarting Postfix is desired. Removing the test is also fine because 1. it was flawed to begin with 2. the changedetector functionality of detecting file changes is already tested in another test
We now use HEREDOCs to add new files to cron. This is, after testing the alternatives of copying files, the best solution in my opinion. We have munite control over the contents (especially when the content of the cron files depends on environment variables). Moreover, we need not adjust the `Dockerfile`.
The job could fail if no new fresh updates are available. This is however not a reason to receive a new email telling me the job failed. This commit provides a solution.
After reading the docs on the exit code, we can do better.
This is a bigger commit - it reworks the whole log functionality. The old one was confusing and not adhering to common standards, i.e. not following convention over configuration. With this commit, we use the common standard log levels 4. TRACE 3. DEBUG 2. INFO 1. WARN 0. ERROR to better provide the information to users and maintainers. With this changes, `DMS_DEBUG` was removed and `LOG_LEVEL` introduced. `DMS_DEBUG` is not usefule anymore (obviously), and replaced by the new `LOG_LEVEL`, which defaults to `info`. All scripts and tests were adjusted to use the new format. There is a special log level (`always`) which is used only by `start-mailserver.sh` to show the welcome messages independent of the log level. I took some care when converting the "old" log levels. With this rework, it should be easier to identify problems in logs and provide users with a clear and straight forward log level variable which is easy to understand. This is not actually a breaking change, but I thought it is fitting for the next major release `v11`.
We need not write up to loggers, sourcing the already present one is fine. This simplifies the whole script.
Documentation preview for this PR is ready! 🎉 Built with commit: 75531fd |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good PR overall! 👍
- Some minor change suggestions if you think any would be improvements.
- Caution towards the SSL
check-for-changes.sh
change. It may regress support for other users without third-party customizations. log.sh
should have expliciterror
case,always
is better suited to use the*
fallback. Not sure whyerror
is set as defaultLOG_LEVEL
case to rely on*
as fallback/highlighting?- Possible bug with one of your cron heredoc additions.
Feedback: Personal opinion - Not a fan of HEREDOC
Cron jobs to heredocs (relevant commit with commit message for context) is not something I'm fond of personally.
I prefer external files instead of embedded/inlined, ENV as a convenience isn't sufficient for me. We already write ENV to a file for other scripts to read and utilize. I'd rather cron jobs we add are all in a common location from a maintenance perspective, but I understand if the majority of maintainers prefer the heredoc approach instead and have no interest in fighting that decision.
Feedback: Log changes could have been covered in a separate PR
The log level change is rather large and seems it would have suited it's own PR rather than mixed in with the other changes covered (relevant commit covering the bulk of logging changes). I understand it's mostly isolated to the linked commit, but for review purposes separate PRs would have been nicer 😅
Thanks!
All resolved :D
I have to admit I disagree, obviously (otherwise I wouldn't have done it). I first tried your approach to see how it goes, but then I noticed that it is way more work to handle these scripts if they are not "inlined" into
I agree. Therefore, I opened #2486. |
Depends on the use-case IMO. Regarding the usage for our cron jobs, I think this is a good solution. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly some changes you still want to make, otherwise LGTM 👍
Thanks for the good feedback, very much appreciated! |
Co-authored-by: Casper <casperklein@users.noreply.github.com>
Description
The commit descriptions are somewhat detailed. It basically boils down to:
Type of change
Checklist:
docs/
)