As PgBouncer listens on port 6432 by default, I’ll use that for this example and constrain the capture by the destination port. To see the capabilities of capture filters in wireshark, please consult the Capture Filter Manual. To limit what you actually capture, write a filter specifying which packets you’re interested in. This limits the capture to packets on the local interface (which, in our case, was still a LOT). To see a list of available interfaces, you can run dumpcap -D ( dumpcap should be installed for you as a part of installing tshark). Please note the name of the interface largely depends - it can be loopback, lo, or something else.
As both the Puma server running our Rails app and PgBouncer are running locally in the container, the local lo interface should suffice. When you run tshark without any arguments, it tries to listen to all available interfaces. apt-get install tshark Step 1 - Identify the Interface You will, of course, also need access to your container of choice. The only tool you’ll need to install is tshark, which should also install dumpcap. Don’t redeploy for enhanced logging and don’t affect the system in any way. To be able to process the output with other tools and easily run it in multiple remote environments at once, use a command line-only tool with a scrapeable output. Look at the traffic between the Rails app and PgBouncer (which should both be running in a Docker container). While you should achieve similar results in most steps, the actual numbers (such as byte lengths, IP addresses, TCP source ports etc…) will almost surely differ on your machine. The examples you’ll see are snippets from capturing real network traffic, with sensitive data changed or redacted, to remain GDPR-compliant ). The app leverages a PostgreSQL database and the connections to it are managed by PgBouncer, which also resides in the container, listening on it’s default port 6432.
Have the Rails app running in a bare-bones Debian-based Docker container (no X Window System). The idea was to build the command using tshark until we had our data filtered out. Our task was to look at the traffic between the Rails app and PgBouncer on a remote machine without a graphical environment. We weren’t sure where this data was being stripped, but there were only a couple of options: In the Rails app, PgBouncer, or it was being stripped by PostgreSQL itself before logging.
Our PostgreSQL logs were being stripped of trailing C-style comments containing a GDPR-relevant ID. This short article/how-to will show you how to solve a real issue.
0 kommentar(er)
