OpenSSH’s SOCKS forwarding

Sunday, 01. 18. 2009  –  Category: stash, web

It’s always great to discover a feature in a tool you use everyday. Someone pointed out to me that, in addition to local and remote port forwarding, OpenSSH also offers what it calls dynamic application-level port forwarding. Put more simply, OpenSSH can act as a local SOCKS proxy punting the traffic out the remote end of the connection:

ssh -Dlocalhost:1080 -C host.example.com

You can now aim your browser’s SOCKS settting at localhost:1080. Bonus points for using a locally-hosted PAC file to determine which traffic is routed via the proxy:

function FindProxyForURL(url, host) {
  if (shExpMatch(host, "*.example.com"))
    return "SOCKS 127.0.0.1:1080"
  else
    return "DIRECT";
}

For getting sight of servers behind a firewall without remote proxies (hello Privoxy) and continual browser fiddling this is ideal. Thanks Murb!

MySQL replication health

Tuesday, 09. 30. 2008  –  Category: sw

It’s possible for MySQL’s statement-based replication to get out of sync. I’ve yet to see a real example myself, perhaps because the DB abstraction layers I encounter not creating the “dangerous” queries that can make this happen. Still, other than monitoring replication health with SHOW SLAVE STATUS and friends I’ve sometimes been concerned about whether my MySQL slaves are faithful copies of the master. Finding that out during a failover moment is the wrong time.

The author of the piece linked above has scratched this itch with Maatkit, a suite of replication-focused MySQL tools which include some for checksumming tables.

This can run with standalone instances but most appealing is the way it runs across a replication chain: the statements to perform the table checksums are themselves introduced into the replication and store their results in a table alongside the master’s checksums. You can then compare and contrast on each slave: neat. All straightforward to roll into Nagios or other monitoring.

Firewalls

Friday, 09. 5. 2008  –  Category: vague

Ace quote from Bruce Schneier’s book Secrets and Lies:

The first firewalls were on trains. Coal-powered trains had a large furnace in the engine room, along with a pile of coal. The engineer would shovel coal into the engine. This process created coal dust, which was highly flammable. Occasionally the coal dust would catch fire, causing an engine fire that sometimes spread into the passenger cars. Since dead passengers reduced revenue, train engines were built with iron walls right behind the engine compartment. This stopped fires from spreading into the passenger cars, but didn’t protect the engineer between the coal pile and the furnace. (There’s a lesson for sysadmins in this somewhere.)

(My emphasis)

« Older Entries