Hello,
I have a local DNS resolver/blacklister (namely pi-hole) running on a raspberry pi on my local network.
When I boot up my local drupal instance the lagoon_logs module triggers a trainload of requests over to application-logs.lagoon.svc
which they do result in a NXDOMAIN response, enough to cripple to a halt my pi-hole.
I assume that this host is only resolved inside lagoon and points the lagoon kibana log pod, so is it possible to add a setting to programmatically switch off the lagoon_logs through settings.php or limit the request rate?
See screenshots, ~4000 requests in the span of a fraction of a second:
Thanks!
Comment | File | Size | Author |
---|---|---|---|
#10 | lagoon_logs.add-enable-setting.patch | 7.31 KB | tallytarik |
Screenshot from 2021-03-31 11-39-24.png | 9.72 KB | luigimannoni | |
Screenshot from 2021-03-31 11-38-20.png | 164.77 KB | luigimannoni |
Issue fork lagoon_logs-3206815
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3206815-local-dns-gets changes, plain diff MR !3
Comments
Comment #2
bomoko CreditAttribution: bomoko commentedHi @luigimannoni
Thanks for the request.
What are you thinking? We could have a config setting that, if set, effectively disables the module?
Comment #4
fjgarlin CreditAttribution: fjgarlin as a volunteer and commented@bomoko @luigimannoni - I added this feature to the D7 version of the module. See here: https://git.drupalcode.org/project/lagoon_logs/-/commit/243d8c56a471abd7...
If I get the time on the following days I'll work on the D8/9 version of it, tho feel free to go ahead.
Comment #6
fjgarlin CreditAttribution: fjgarlin as a volunteer and commented@bomoko - I am going to ask you to code-review this.
The PR contains a few changes:
* Adds a checkbox to enable or disable the functionality of the module (the module can stay enabled). This would fix this drupal.org issue and it also allows to override the value for local development by adding a value into settings.local.php
* Replaced the controller where the information was shown with a settings form and updated the routes.
* Added configure and admin menu links to the module.
--
@luigimannoni - please test this to see if it fixes the issue.
Comment #7
tallytarik CreditAttribution: tallytarik commentedWe're working on upgrading our site to PHP 8/8.1 and have come across another reason for adding a local/dev toggle: the behaviour of
@
to suppress errors has changed, so we're getting these whenever we have an error message pop up:The fsockopen call is actually
@fsockopen
, so it should suppress these warnings. They're no longer suppressed as of PHP 8, because of a change in the behaviour of@
anderror_reporting()
and custom error handlers.Since the errors aren't suppressed, it'd be great to be able to disable this module in development with a config toggle.
(Although I think this probably needs to be rerolled for 2.x first)
Comment #9
fjgarlin CreditAttribution: fjgarlin as a volunteer and commentedHi @tallytarik, can you try https://git.drupalcode.org/project/lagoon_logs/-/merge_requests/8
That should add the ability to enable/disable the logging of the module whilst the module is still enabled in Drupal.
Comment #10
tallytarik CreditAttribution: tallytarik commented@fjgarlin I'm on the 2.x branch so I've rerolled your MR, attached.
Works well! I've added it as a
local.settings.php
override and I can see it's not trying to log anything anymore, and I'm no longer getting thefsockopen
errors.Comment #13
bomoko CreditAttribution: bomoko at amazee.io commentedLGTM, thanks all -tested, merged and applied patches.
Will be in the latest release
Comment #14
luigimannoni CreditAttribution: luigimannoni commented@fjgarlin sorry somehow I haven't received a single email notification for this issue so has been a little bit forgotten from my side.
I've tested with the new 2.x release and that solves the request spam issue :)
Many thanks
Comment #16
fjgarlin CreditAttribution: fjgarlin as a volunteer and commented@luigimannoni @tallytarik - notice that in #3261904: Updating to latest version disables logging the logic introduced here has been reversed.