profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/polarathene/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Brennan Kinney polarathene Auckland, New Zealand

polarathene/biglobby 37

[DEPRECATED] A BLT mod for Payday 2. Allows games to have more than 4 players at once. [See README for link to BigLobby3]

polarathene/acmed 0

ACME (RFC 8555) client daemon

polarathene/actions-netlify 0

🚀 Netlify deploy from GitHub Actions

polarathene/caddy-docker 0

Source for the official Caddy v2 Docker Image

polarathene/caniuse 0

Raw browser/feature support data from caniuse.com

polarathene/cloudflare 0

Caddy module: dns.providers.cloudflare

polarathene/composer 0

Dependency Manager for PHP

polarathene/coredns-mdns 0

CoreDNS plugin that serves .local mDNS info over normal DNS

polarathene/coredns.io 0

CoreDNS website

Pull request review commentdocker-mailserver/docker-mailserver

fix: Remove `mkcert.sh` usage + `_setup_ssl` refactor.

 function _setup_docker_permit    if [[ -z ${CONTAINER_IP} ]]   then-    _notify 'err' "Detecting the container IP address failed. Check if NETWORK_INTERFACE is correctly configured."-    _shutdown+    _shutdown "Detecting the container IP address failed. Check if NETWORK_INTERFACE is correctly configured."

_shutdown($PANIC_NO_HOST)

I removed the vars so anyone that wants to panic/shutdown doesn't have to copy/paste a specific one, if they're going to lookup the options to copy/paste might as well just make it a method name and/or prevent any typo mistakes?

In my editor it also seems to autocomplete with a suggestion if I type the function name, but that might be because I've opened helper-functions.sh and was working on the method :sweat_smile:

You're right that it's over-engineered for what it is and our needs atm. I wanted to panic within _setup_tls under some common conditions and wasn't aware of _shutdown at the time, so I wrote a method to reduce copy/paste if I need it in future and avoid typing similar error messages for the same thing months later :sweat_smile:

I personally prefer the current method as it's more maintainable / flexible, than adding new string vars for more specific failures (which has less value in co-location vs inline?).

_shutdown still works directly but expects a message arg (I could make it optional if desired), which is to encourage invoking it with some context of where it was called (less of an issue with us and having a review process though :stuck_out_tongue: ).


I'm fine with whatever is agreed on. The current approach might be a bit much, but it works and shouldn't cause any maintenance woes, probably best to not bike shed on it too much :smile:

polarathene

comment created time in 8 hours

PullRequestReviewEvent

issue commentnginx-proxy/acme-companion

Allow disabling DH param generation _or_ Use RFC 7919 DH group instead of self-generation

I actually brought this up earlier in the year (hidden as off-topic) :sweat_smile:

I just noticed the following PR, this change doubled the DH params size without proper justification and enabled the usage of -dsaparam

While on topic, this is probably relevant to the project too:

That said, nginx-proxy-letsencrypt-companion, still uses 2048-bit DH params (generated as well instead of using RFC 7919 groups), and provisions RSA certs with key size of 4096-bit size by default. 2048-bit is plenty secure.

This default was inherited from simp_le before switching to acme.sh (which defaults to 2048-bit like certbot), but due to the config support to change default RSA key size from simp_le 4096-bit, they've carried over that 4096-bit RSA default :\

polarathene

comment created time in 9 hours

issue openednginx-proxy/acme-companion

Allow disabling DH param generation _or_ Use RFC 7919 DH group instead of self-generation

Bug description

DH params generation is not possible to disable?:

https://github.com/nginx-proxy/acme-companion/blob/7f1b75460d2a4ba9aa81e6da06c3119b41ef94db/app/entrypoint.sh#L47

nginx-proxy container however provides an ENV to disable generation with DHPARAM_GENERATION=false.

In my case this is for docs on a project with several popular approaches via Docker to automate cert renewal, but the project itself has it's own internal DH params file where it handles TLS connections that are not using HTTPS. AFAIK acme-companion and nginx-proxy should be fine provisioning certs without requiring DH params?


If DH params are actually required, or you'd prefer to not generate them.. you can use standardized RFC 7919 DH groups. The project I'm a maintainer of uses ffdhe4096.pem, these DH groups are generally advised to use vs generating your own. `openssl wiki advises adopting RFC 7919 too and provides the pem content too.

NOTE: You are currently generating with -dsaparam option, this is much faster but does pose some risk (2016 CVE advisory), as the openssl docs mention:

Beware that with such DSA-style DH parameters, a fresh DH key should be created for each use to avoid small-subgroup attacks that may be possible otherwise.

Using DH groups from RFC 7919 is also advised by Mozilla among others, and part of TLS v1.3 (which only negotiates these DH groups IIRC, rather than custom provided ones that TLS 1.2 or earlier allow).

In the project I help maintain, we have just added a copy of ffdhe4096.pem to the repo and use COPY during Dockerfile build.

acme-companion image version

No deployment, this is a feature request + advice.

nginx-proxy's Docker configuration

N/A

rendered nginx configuration

N/A

Containers logs

N/A

Docker host

N/A

created time in 9 hours

Pull request review commentdocker-mailserver/docker-mailserver

fix: Remove `mkcert.sh` usage + `_setup_ssl` refactor.

 function _setup_docker_permit    if [[ -z ${CONTAINER_IP} ]]   then-    _notify 'err' "Detecting the container IP address failed. Check if NETWORK_INTERFACE is correctly configured."-    _shutdown+    _shutdown "Detecting the container IP address failed. Check if NETWORK_INTERFACE is correctly configured."

Hopefully the new commit makes my intent more clear :)

I did it in two stages:

  • 1st commit is about what was discussed here.
  • 2nd commit is a refactor based on better developer experience.
polarathene

comment created time in 17 hours

PullRequestReviewEvent

push eventpolarathene/docker-mailserver

polarathene

commit sha ea3e3e0b4191397dc1f1a76873439783618d0c17

Add misconfigured panic type + adopt dms_panic elsewhere The two previous `_shutdown` methods can benefit from using `dms_panic` wrapper instead to standardize on panic messages.

view details

polarathene

commit sha 44793f31c0558d0c2dd5b2faea06668f3c8ea601

Refactor `dms_panic` - Arg order was changed to move the scope (optional) to the last arg. - Rather than copy/paste PANIC_ vars as an arg, encourage wrapper methods instead that implicitly provide the PANIC_TYPE arg. - PANIC_TYPE variant vars no longer required, switched to direct strings. - Added inline comment about expected PANIC_INFO value/format for each panic type case. - Revised doc comments.

view details

push time in 18 hours

pull request commentdocker-mailserver/docker-mailserver

Update all docker-compose files to use the same version and examples

I am now wrapping up this PR.

williamdes

comment created time in 19 hours

Pull request review commentdocker-mailserver/docker-mailserver

fix: Remove `mkcert.sh` usage + `_setup_ssl` refactor.

 function _setup_docker_permit    if [[ -z ${CONTAINER_IP} ]]   then-    _notify 'err' "Detecting the container IP address failed. Check if NETWORK_INTERFACE is correctly configured."-    _shutdown+    _shutdown "Detecting the container IP address failed. Check if NETWORK_INTERFACE is correctly configured."

Possibly.

Do you want the same/similar message or is there an appropriate generic one that could benefit from a new PANIC_TYPE?

Could emit the "Detecting the container IP address failed." via _notify 'err' prior to the shutdown/panic fatal error: "Possible misconfiguration for NETWORK_INTERFACE" (new panic type, PANIC_MISCONFIGURED)?

polarathene

comment created time in 19 hours

PullRequestReviewEvent

push eventpolarathene/docker-mailserver

polarathene

commit sha fb743325b5c28370bd74ee28c65e5ba5464da5bf

Obsolete `_shutdown_with_message` As per review feedback, delegate to `_shutdown` instead by moving the fatal`_notify` and accepting an arg to provide shutdown context within `_shutdown`, which is now expected to only be called if something considered fatal has occurred.

view details

push time in 20 hours

pull request commentdocker-mailserver/docker-mailserver

fix: Remove `mkcert.sh` usage + `_setup_ssl` refactor.

@casperklein thanks for taking the time to review it! Glad the commit messages were helpful :)

I've replaced exit 1 with _shutdown. I think shutdown could be called without the intent of it being fatal, so I've retained the inner function for adding context. When this type of functionality is desired it's probably better handled/listed in this dms_panic method?

If someone finds a reason not to need dms_panic but want to use the the inner function _shutdown_with_message; it could be made more generic and available to others to call directly instead at that time.

polarathene

comment created time in 21 hours

push eventpolarathene/docker-mailserver

polarathene

commit sha 6b7b01904655a8ec70f5ed55a09dc99ce48edb9f

Panic with kill (shutdown) not exit (errex) - `kill 1` from `_shutdown` will send SIGTERM signal to PID 1 (init process). - `exit 1` within the `start-mailserver.sh` init scripts context, will just exit the initialization script leaving the container running when it shouldn't.

view details

push time in 21 hours

pull request commentdocker-mailserver/docker-mailserver

fix: Don't needlessly invalidate cache layers

I'll merge this after https://github.com/docker-mailserver/docker-mailserver/pull/2196 is merged.

polarathene

comment created time in 21 hours

Pull request review commentdocker-mailserver/docker-mailserver

tests: Refactored bounced spam test + Introduce common container setup template

 function wait_for_empty_mail_queue_in_container() {     # shellcheck disable=SC2016     repeat_in_container_until_success_or_timeout "${TIMEOUT}" "${CONTAINER_NAME}" bash -c '[[ $(mailq) == *"Mail queue is empty"* ]]' }++# Common defaults appropriate for most tests, override vars in each test when necessary.+# TODO: Check how many tests need write access. Consider using `docker create` + `docker cp` for easier cleanup.+function init_with_defaults() {+  # Ignore absolute dir path and file extension, only extract filename:+  export TEST_NAME+  TEST_NAME="$(basename "${BATS_TEST_FILENAME}" '.bats')"++  export PRIVATE_CONFIG+  PRIVATE_CONFIG="$(duplicate_config_for_container . "${TEST_NAME}")"+  export TEST_FILES_VOLUME="${PWD}/test/test-files:/tmp/docker-mailserver-test:ro"+  export TEST_CONFIG_VOLUME="${PRIVATE_CONFIG}:/tmp/docker-mailserver:ro"++  export TEST_FQDN='mail.my-domain.com'

Oh for sure. I use mail.example.test myself, the cipherlist test uses such a domain with the self-signed certs for such a domain.

I left it as this though since many of the existing tests that do involve a domain name in their tests use this one I think. I'll replace it in the future as a find/replace commit for all occurrences.

polarathene

comment created time in 21 hours

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentdocker-mailserver/docker-mailserver

fix: Remove `mkcert.sh` usage + `_setup_ssl` refactor.

 function errex   exit 1 } +PANIC_NO_ENV='no-env'+PANIC_NO_FILE='no-file'+PANIC_INVALID_VALUE='invalid-value'+function dms_panic

Inline or above the function:)

Done, above the function, a tad verbose though :sweat_smile:

polarathene

comment created time in a day

push eventpolarathene/docker-mailserver

polarathene

commit sha 48aac7ac9022e7ba50a32e798051069b5d4fc3f9

Add inline documentation for `dms_panic` This could later be better formatted and placed into contributor docs.

view details

push time in a day

PR opened docker-mailserver/docker-mailserver

tests: Refactored bounced spam test + Introduce common container setup template

Description

Originally I spotted a typo in this test when it failed on me the other day. Earlier commit resolved that, but I've since refactored due to the 2nd change (adding new test helper methods).

I have also been wanting to better consolidate container setup for most tests which tend to just add some env and copy/paste other common options, this introduces an initial approach to handle that.

I also noticed that tests were starting a few seconds too fast with the original wait condition, resulting in failure when trying to connect to an unintialized postfix (becomes available a few seconds after the ready state in the test environment). Someone put together some awesome test helpers, so that was an easy fix :)

In a future update, tests will get grouped for delegating to multiple job runners in parallel. Tests will use actual .env files unless there is better suggestion (not really a fan of the heredoc syntax).

Type of change

  • [x] Bug fix (non-breaking change which fixes an issue)
  • [x] New feature (non-breaking change which adds functionality)
  • [x] Improvement (non-breaking change that does improve existing functionality)
  • [ ] This change requires a documentation update

The new test helper might need some docs, but it's not in use by any other tests as of yet and still needs to be iterated on a bit, so beyond this PR, not much value in documenting it further?

Checklist:

  • [x] My code follows the style guidelines of this project
  • [x] I have performed a self-review of my own code
  • [x] I have commented my code, particularly in hard-to-understand areas
  • [ ] I have made corresponding changes to the documentation (README.md or the documentation under docs/)
  • [x] If necessary I have added tests that prove my fix is effective or that my feature works
  • [x] New and existing unit tests pass locally with my changes
+79 -43

0 comment

3 changed files

pr created time in a day

create barnchpolarathene/docker-mailserver

branch : tests/bounced-spam-refactor

created branch time in a day

pull request commentdocker-mailserver/docker-mailserver

fix: Don't needlessly invalidate cache layers

Yes it's just the two setup tests that are failing due to a partial revert.

We were delaying merging the 10.2 release until https://github.com/docker-mailserver/docker-mailserver/pull/2196 was ready (for the mkcert.sh to be dropped). It's not a blocker though, so we could go ahead and follow up with a 10.3 afterwards. The other PRs preventing upgrade to Debian Bullseye have already been merged.

polarathene

comment created time in a day

Pull request review commentdocker-mailserver/docker-mailserver

fix: Remove `mkcert.sh` usage + `_setup_ssl` refactor.

 function errex   exit 1 } +PANIC_NO_ENV='no-env'+PANIC_NO_FILE='no-file'+PANIC_INVALID_VALUE='invalid-value'+function dms_panic

This leads to, why do we need dms_panic()

It just provides convenience messages for certain types of errors to avoid repetition (which'd likely diverge a bit).

when there is already _shutdown()

Shutdown is doing a kill 1 instead of exit 1, what is the difference? Panic seems more similar to errex (error exit?), as it's meant to stop/exit immediately, whereas shutdown usually implies more of a process with graceful shutdown orchestration.

I chose "panic" as akin to kernel panic, or panic in Rust. It additionally uses the _notify with "fatal" to indicate something has gone quite wrong/broke, as in show stopping not a recoverable/ignorable error.

Happy to rework it if you like or integrate with _shutdown or errex.

polarathene

comment created time in a day

PullRequestReviewEvent

pull request commentdocker-mailserver/docker-mailserver

Follow up on PR for fixing tests (mostly styling)

@NorseGaud what did you do to trigger those commit references? They tag me via notification because my username is mentioned, and likewise the PR reference (no notification for me) appears on this PR and referenced one.

Is this something Github is doing when you updated a branch/PR of yours?

georglauterbach

comment created time in 2 days

pull request commentdocker-mailserver/docker-mailserver

fix: Don't needlessly invalidate cache layers

@NorseGaud gripe for you too in your long-lived PR I take it? :joy:

I've been using this uncommitted in my current PRs, much better experience :stuck_out_tongue:


For a CI improvement, I notice that building images is taking 15-20 minutes. I assume our tests are only running on the x86_64 image, so building the other images is probably wasteful in resources and time. We could instead delay building for other platforms until tests pass / finish?

This PR for example takes approx 50 minutes for the full test suite + CI builds to run. Tests time can be reduced via multiple job runners in parallel (might be complicated a bit by distribution of the testing image, I think we can use a similar technique that the doc previews use), I'd just need to look into what tests are expensive in time to offload to other jobs (eg the cipherlists).

polarathene

comment created time in 2 days

PR opened docker-mailserver/docker-mailserver

fix: Don't needlessly invalidate cache layers

Description

Recent sedfile addition moved all scripts section earlier into the Dockerfile so that sedfile could be used within the Dockerfile.

However whenever a change is made to scripts which is most of the time for this project, building the Docker image for tests results in all layers after the scripts being invalidated, notably ClamAV, wasting storage of previous instances and increasing build time unnecessarily.

This isn't as noticeable of an issue via the CI as we don't leverage any caching at present there, but for iterating on a local branch and testing, it can be quite the drawback.

  • sedfile is handled early in the Dockerfile still, while the scripts have been moved as far down as it made sense to.
  • chmod was split out into it's own RUN command as again it's unnecessary for the rest of it's prior RUN command group to be invalidated.

Type of change

  • [x] Improvement (non-breaking change that does improve existing functionality)

Checklist:

  • [x] My code follows the style guidelines of this project
  • [x] I have performed a self-review of my own code
  • [x] New and existing unit tests pass locally with my changes
+27 -26

0 comment

1 changed file

pr created time in 2 days

Pull request review commentdocker-mailserver/docker-mailserver

fix: Remove `mkcert.sh` usage + `_setup_ssl` refactor.

 function errex   exit 1 } +PANIC_NO_ENV='no-env'+PANIC_NO_FILE='no-file'+PANIC_INVALID_VALUE='invalid-value'+function dms_panic

Sure! Did you want inline documentation in this file, or did you mean our contributor docs?

polarathene

comment created time in 2 days

PullRequestReviewEvent