A Deep Dive into Iptables and Netfilter Architecture

It’s been a while since I had to dive into the iptables and netfilter. These days I mostly have to do some basic configuration here and there, with occasional adjustments or troubleshooting (less and less so, thanks to Amazon AWS). But if drilled on the details, I quickly lose my confidence. In an effort to refresh my memory, I looked around for a blog post or an article that is short and simple, yet deep enough for me to brush some rust of. I found “A Deep Dive into Iptables and Netfilter Architecture” very helpful.

Turns out, the bit I needed the most was this one:

Chain Traversal Order

Assuming that the server knows how to route a packet and that the firewall rules permit its transmission, the following flows represent the paths that will be traversed in different situations:

* Incoming packets destined for the local systemPREROUTING -> INPUT
* Incoming packets destined to another hostPREROUTING -> FORWARD -> POSTROUTING
* Locally generated packetsOUTPUT -> POSTROUTING

Technical documentation is so much easier these days. I remember the old days of manual pages and HOWTO guides, and I think we’ve made a lot of progress.

Dotfile madness

Dotfile madness” is an excellent look at the problem of hidden data and configuration files that seem to be multiplying lately in the users’ home directories:

We are no longer in control of our home directories.
My own home directory contains 25 ordinary files and 144 hidden files. The dotfiles contain data that doesn’t belong to me: it belongs to the programmers whose programs decided to hijack the primary location designed as a storage for my personal files. I can’t place those dotfiles anywhere else and they will appear again if I try to delete them. All I can do is sit here knowing that in the darkness, behind the scenes, they are there. Waiting in silence. Some of those programmers decided to additionally place some normal files and directories in the same place. Those are clearly visible every time I execute ls in my home directory. 

While there is no easy centralized solution to this problem, as each application’s developer decides for himself, the article proposes a better way of doing things, reminding us about the XDG Base Directory Specification. This spec allows for a much finer control of where things go via the XDG_* environment variables.

Nice one!

gita – manage multiple git repositories

gita is a command line tool to manage multiple git repositories in parallel. You can easily check the status of several repositories, pull, push, commit, and so on.

This is a nice alternative to how we are handling things at work, with hundreds of repositories all around, but with a lot of overlap between them too. For us, a custom set of scripts works pretty well, with a combination of a powerful terminal emulator. Terminator, for example, provides handy functionality of split screen view, with grouped terminals, where multiple screens can be easily updated with a single command input.

SpaceVim – extended Vim configuration bundle

There are many different configuration bundles for Vim, which easy the discovery, installation, configuration, and documentation of different plugins and features of this powerful text editor. SpaceVim is yet another one of these.

If you are new to Vim, or have grown tired of trying to tweak it to your liking, please give it a try. It might just work for all your needs.

fx – command-line tool and terminal JSON viewer

fx is yet another command-line tool for working with JSON data. Some of the supported features:

  • Formatting and highlighting
  • Standalone binary
  • Interactive mode 
  • Themes support

This looks like a good alternative or a complimenting tool for both jq and jo.