Prompt: How can I create dummy MaxMind GeoLite2 .mmdb files that will respond to ALL IP lookups with the same information? For example these these would be .mmdb files that will have entries for 0.0.0.0/0 and ::/0 that will cover all possible IP lookups?

Gemini 2.0 Flash will actually provide a moderately useful response, albeit one based on the legacy MaxMind perl based code available from MaxMind-DB-Writer-perl. It also correctly recommends using the mmdbinspect tool to test the .mmdb files that have been produced.

ChatGPT (free not Plus) also provides a fairly useful response, albeit one based on python code. It doesn't seem to know about mmdbinspect and does produced .mmdb file testing using python code instead.

Claude.ai provides something similar to ChatGPT's solution.

The Better Solution

However, unsurprisingly, while all of these solutions appear valid, they're based on outdated information and are incomplete if you want detailed GeoIP lookup data to be returned. To really get the solution you want, even if you were to stick with their perl/python code (assuming it actually works out of the paste...), will require a deep dive on what fields can/should exist.

When you're building packages for Elastic Fleet/Agent, if you're providing sample logs to test pipeline and system processes with it's not uncommon to have elastic-package whinge about non-approved IP's being there similar to the below.

Elastic's rationale is, presumably, that sensitive IP information may be leaked if it's not replaced with IP's from an approved set. To a lesser extent I believe they're trying to force the use of real IP's that will have actual GeoIP information associated with them so that if a geoip processor is used in an ingest pipeline it will actually return geoip data that will be inserted into documents.

Frustratingly this also means that elastic-package will not accept RFC defined documentation network IP's, e.g. 192.0.2.0/24, 203.0.113.0/24, 2001:db8::/something etc.

If you're running MacOS and using XQuartz in order to transport app GUI display over SSH from a remote system you may run into an issue with XQuartz displayed window sizes not being adjustable beyond maximising it to the fill the screen or returning it to the initial size.

Normally each window is resized via the very bottom right corner however the initial display of the app may result in that corner being outside the size of your actually display.

After a little bit of time on Google I came across a script that uses xwininfo to identify the window to resize and then xdotool to actually resize it.

Unfortunately that script didn't work straight out of the box.

Some slight modifications led me to creating a working version as below.

This is a new site and a new attempt to invigorate what was once a passion for blogging and sharing solutions to technology problems.