Random Piths

Frameworks vs Libraries (or Systems vs Tools)

Frameworks tend to make your design decisions for you before your project ever exists so you are always going to be constrained to the framework's approach, which invariably yields a selection of the problem space much smaller than the total space advertised by the framework that it is the solution of. These blind spots arise mainly from the designers' ignorance and/or bliss. Also there are always hidden and abstracted layers of auto code that you don't know about and/or don't want to know about.

Libraries tend to be collections of utilities where each is maximized to their most useful and basic utility without diluting the value of each utility below the threshold of convenience, novelty, or beauty. Good libraries don't impose state or evolutionary patterns on your project.

Conclusion: Use a framework for something dreadfully time or resource constrained with the idea to redo it later.

On Selecting, Editing, and Using a Development Pattern or Design

Often trivial design elements, whether used for pedagogical work or because they posit a facile but expressive symmetry, are extrapolated due to affinity for their deceptively elegant ontology into absurd abstrusions that abrade utility in a most vexing and distracting counterpoint. When the prescribed design presides over the dictates of the existential problem or need set, the design eclipses the problem by a scale measured in orders of magnitude.

Conclusion: Don't code to a design when the design malevolently subverts the problem you are trying to solve.

The Proper Method of Maintaining Institutional Knowledge

Ideally, each engineer on a team will actively promote and disseminate their essential institutional knowledge until at least one complete logical copy thereof exists in and can be assembled from the P2P context of the team's total knowledge collective.

Conclusion: Don't hide or allow to be hidden essential knowledge from the team's communication network.

| Posted: |

iptables: -p vs --proto vs --protocol

Observe the following three iptables commands:

# iptables -A INPUT -s 10.20.0.0/24 -d 10.10.0.0/24 -i eth0 -m policy -p esp --dir in --pol ipsec --reqid 1 -j ACCEPT
# iptables -A INPUT -s 10.20.0.0/24 -d 10.10.0.0/24 -i eth0 -m policy --proto esp --dir in --pol ipsec --reqid 1 -j ACCEPT
# iptables -A INPUT -s 10.20.0.0/24 -d 10.10.0.0/24 -i eth0 -m policy --protocol esp --dir in --pol ipsec --reqid 1 -j ACCEPT

Whereas --proto is a valid synonym for --protocol (as are -p, --proto[c[o[l]]]), if it, namely the exact token --proto, appears in the rule after -m policy, it will be appropriated by the policy extension of iptables. Indeed, the resulting rules as reported by iptables -vL are:

# iptables -vL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     esp  --  eth0   any     10.20.0.0/24         10.10.0.0/24         policy match dir in pol ipsec reqid 1
    0     0 ACCEPT     all  --  eth0   any     10.20.0.0/24         10.10.0.0/24         policy match dir in pol ipsec reqid 1 proto esp
    0     0 ACCEPT     esp  --  eth0   any     10.20.0.0/24         10.10.0.0/24         policy match dir in pol ipsec reqid 1

This token overloading is an unfortunate design conflict, and such subtlety confounded SaltStack's iptables state module, though not its execution module. It's also really confusing unless you know that --proto can be used in two distinct ways in two distinct places.

So, according to the iptables(8) and iptables-extensions(8) man pages, -p, --proto[c[o[l]]] specify "The protocol of the rule or of the packet to check." and --proto as used by the IPSec policy extension matches the encapsulation protocol. Evidently the encapsulation protocol is different from the protocol used for IPSec traffic. I still have more to learn about this, otherwise I would be more helpful here.

| Posted: |

strongSwan VPN Between Two VMs

A Pleasant Discovery

In the course of technological events arising from the labor of one's job, frequently the occasion occurs that one finds oneself either forestalled by uncertainty and variability in setting up an unfamiliar system/tool or confused by the complexity of such system/tool and its unwholesome documentation or both. (The appreciable frequency of this scenario being one of the reasons why filtering on flat task lists for job candidates often proves so foolhardy even as it is defended as the safe choice. Rather, Aristotle I think would advise not to look upon a person's resume, but at what that person will do next.)

Read more…

| Posted: |