Category Archives: tech

Another old copy

This post is by request (after I mentioned the trick in passing to someone on IRC).

So, the lay of the land: you find yourself in some dubious or highly unconventional position of server access. Maybe it’s behind a few layers of ssh jumps and VPN paths. Maybe the only way to get data input is that it’s on the other side of a phonecall, a human slowly typing in some things as you read it out to them. Maybe it’s just some damned SSO config on a corporate network somewhere. Doesn’t matter exactly which it is, you have the problem that you cannot easily copy a set of files to where you need it.

There’s a few handfuls of ways in which one can deal with this. One of the easiest, if you can manage, is to stick it somewhere as an HTTPS resource and pull that down. But… sometimes you don’t have HTTPS access (or, for that matter, any outbound internet access at all). Maybe you can do some DNS tunneling? The difficulty of that ramps up rather quickly, unfortunately. You just happen to not have your DNS fileserver running today!

But… hey, you already have a shell, right? And there’s a `base64` or `od` binary on that host, or maybe some python or Perl or even bash?

Well then, lucky you.

Take your file on the input side. Pop it through a base64 encode.

# presuming OSX
source% base64 -i some_input -o the_base64

Read that base64 into your pastebuffer, paste on the other side. End off your heredoc (they do make it easier in many cases). Remake your file as you need it.

# presuming linux
dest% cat <<EOF>> base64_input
< the paste goes here >
EOF
dest% base64 -d base64_input > the_original

You need multiple files? Roundtrip it through an archive!

Maybe they’re big files and you’re worried about items getting lost? `split` and `par2` are your friends! Don’t have `par2`? No matter, you can install it in this manner!

You can see how versatile this technique can be. And how insane. But it’s a nice enough wrench to have in your toolbox if you ever need to hit a nail in, if you know what I mean.

It’s also by no means new. Nor is it previously undocumented. Or even the only variation of this trick[0]. It’s just one of those things that sometimes happens to need to be shown. Lest the arcana be forgotten.

[0] – for a fun exercise, see how many variations of this you can come up with.

Drone CI Slack plugin changes for 0.4 to 0.5

Recently I’ve setup Drone CI for internal use, and ran into an issue with the Slack plugin failing to work. I thought I’d give a quick summary here of what was necessary to fix it on my setup, as the documentation (as it stands today) didn’t make it very clear.

The config required for making the Slack plugin work on 0.4 looks like this:

notify:
  slack:
    webhook_url: https://hooks.slack.com/services/...
    channel: general
    username: drone

And the config for 0.5 like this:

pipeline:
  ...

  slack:
    image: plugins/slack
    webhook: https://hooks.slack.com/services/...
    channel: general
    username: drone

The main differences I observed are:

  • the depth at which the notification plugin is stated (on 0.4 it’s at the root, on 0.5 it’s under pipeline)
  • “webhook_url” changed to “webhook”
  • the notify keyword/section appears to no longer be required

Mailmate Submailbox SNR hack

Problem statement: One of my customers uses Bitbucket for their code, and I have a noisy mailbox.

Instead of writing even more filters¹, I opted to use the Mailmate Smart Mailbox feature to get a better signal about/for things from Bitbucket

Here’s a regex I used:

${subject.body/Pull request #([0-9]+): (.*) \(.*\/(.*)\).*/${3} - #${1} ${2}/}

It works pretty well.

And credit where credit is due: I first saw pbrooko do this, so the idea inspiration is there.

¹) I find filters to be cause for problems in experience across all my devices and interfaces

My sound setup

Since I find myself linking to this frequently enough (and because it’s been a while since this had a post), I figured I’d just write it up somewhere.

Portable set

1x Hardshell case
1x Sennheiser HD558
1x FiiO E10K
1x Shorter cable

The carry case isn’t amazing, but it gets the job done, and I got it delivered in something like a day during one of my recent US trips.

More stationary/”used in study” set

1x FiiO E10K
1x Sennheiser HD598

What I’d change

At some point I might get a Maverick DAC (or one of the other ones you can find these days), and maybe a set of HD650 cans.

What I like

My phone has enough juice on its output to be able to drive the HD558 set reasonably, but does have a noticably lower maximum compared to the DAC. If I were to try go past that, I’ve eyed the E6 and E12 as possible options. No major reason for the FiiO units above anything else, they’ve just not let me down yet and they’re cheap enough to be reasonable (which factors in on shipping things to .za)

What sucks

Both the headphone models above are open-back, which have issues being used in more crowded places or alongside busy roads or on the train, etc. I used to use a set of Sennheiser CX200 instead during those times, but mine got lost somewhere before the move. One friend has recommended the NVX XPT100 as an option, and another the Allesandro MS-1s (which are basically a re-release of the Grados or somesuch). I prefer over-ear over on-ear, so I expect I’d probably try something like the XPT100 set first.

Keys, identity, etc

This post serves as a general notice of key update, as well as a short bit of history.

My new GPG key is a 4096 RSA. It’s available on the SKS keyservers already, and has the fingerprint 1A9260611F0D15319BE6465E474E16D0F70C7CC9. I have also updated my Keybase identity with this as appropriate, as well as updating my online pubkey store.

My old key was E5BB45ADAC20F87D8E5C2316D3C406A99ABE41AE, 1024 DSA. I’ll be pushing a revocation for this in about a week’s time.

The intention behind this is a general update, plus also just adding some clarity to my public key situation. I have some Older Keys which happened, in various states, from times when I had no clue to times where I had no ability to survive machine or disk failures. Aside from those conditions, I had another key which I also no longer wish to use (due to reasonable key size concerns etc).

DHCP, LXC, phy-less (?) bridges, and checksums

tl;dr: if your lxc container on a bridged/veth network is randomly failing to get a dhcp address, you can probably fix it with `ethtool br0 x off  tx off` (br0 being the bridge interface).

With my home DSL acting up quite a bit lately (“lately” == month and a half now. “acting up” == ground fault, and waiting for the telco to fix it..), I’ve been doing a lot of sandboxing work on my microserver at home. But because of its resource scarcity (2GB RAM, and I just haven’t bought more yet), I’ve been giving LXC a go[0] (where I’d normally just do libvirt’d kvm). It’s pretty easy to get started (check this post for pretty all much info you need), but I did deviate from the norm slightly.

I like my eth interfaces a server like this to be non-bridged, mostly because of a lack of ipmi (but also because brctl is a clown sometimes). So my setup for this at home looks like so:

auto lxc0
iface lxc0 inet static
  address 192.168.2.1
  broadcast 192.168.2.255
  netmask 255.255.255.0
  bridge_stp on
  pre-up /sbin/brctl addbr lxc0
  post-down /sbin/brctl delbr lxc0

I’ve also got dnsmasq listening on everything, although I hadn’t had it doing dhcp on that interface yet. Today I decided to change that, which is what led me to discovering this: (afaict) if you don’t have a phy interface attached to your bridge, checksum offloading behaviour on that bridge appears to be fucked-by-default.

How this manifested in my case was that lxc containers couldn’t succesfully DHCP (mostly silent failure), but doing a pcap or dhcpdump on the inside interface would show responses actually getting to your container. After some various derpery with dhclient’s options and applying enough patience, I finally managed to see a message: ‘5 bad udp checksums in 5 packets’. Some quick searching revealed people advising doing `iptables -A POSTROUTING -t mangle -p udp –dport bootpc -j CHECKSUM –checksum-fill` to fix this. Not just liking magic patches, I did check into why this is the case, and as mentioned earlier, it seems that this happens when you don’t have a phy attached to the bridge[0].

My network config for that interface now has a `post-up /sbin/ethtool tor0 rx off tx off` in it, and things seem dandy.

[0] – Mostly works pretty well. On debian wheezy you need some backported stuff for the various cgroups support. I think I got them from sid.
[1] – “seems”, because a) I don’t feel like testing this by attach a real phy to the bridge now, and b) I haven’t run into this before when using various other things (KVM usually) that were running on phy-attached bridges so I can only guess this is what happens. Feel free to test and let me know.

puppetvpn

Just a quick post to announce puppetvpn. It’s a puppet module for easily setting up openvpn links (p2p and hub-and-spoke), with the main point/attraction/difference being that it lets puppet take care of the key management effort.

Based on initial work by Tristan, so all credit as due goes there.

It’s not very smart right now (presumes a whole bunch of things). Patches accepted.

And another one

Seriously loving my cellphone company right now.

vodacom billing engine excellence

PRERATE ALL THE THINGS

So, to whichever unfortunate person ends up with my support ticket for this, I wish you luck.

P.S. I was told there’s more context needed, so: look at the bundle type in the top bar, and then at the used/avaiable counts. What happened (my guess, but I’m pretty sure) is that when I bought it, their rating system preburned all the data I’ve already done this month (under previous rollover bundle).

Rocket-solid .za DSL setup

After a couple of SOHO router iterations (not all my own, sometimes seen via other people), recurring problems:

  • overheating devices due to bad design
  • crappy stock firmware
  • bugs (that often never get fixed, or updates are never applied)
  • other assorted silly issues, like a 1000-connection session table, or small arp tables, or or or …

Much like the rest of the local linux community, I’d long just done DSL bridging and let a Linux box do the work of Real Internet Connection(tm), but that’s not the easiest pitch for Joe Average Home User. So I found an alternative set of things that works fairly well, and is solid enough for you to fire rockets at it. The recipe is as follows

  • 1x DSL bridge of some kind. Some Broadcom chipsets are excellent
    • I’ve had a hell of a lot of lifetime out of the DSL-2500U
    • if you want cheaper, this Tenda unit
  • 1x Non-shit router
    • A RB750 is pretty good for this. Gets your packets going without too much fancy. Has other benefits too
  • 1x Extra switch, because cheap gigabit is good
    • again, a Tenda unit
    • there are some cheap tp-links and HPs around too that I’ve had before

Cheap, effective, and just slightly annoying on amount of power sockets used. The power used is fairly low, too (we’ve had to test it on another project before, and it’s something like R20/month).

I’ll update the post a bit later with the basic tik config to apply.

My IRC setup

Potentially a somewhat bland topic, but I find myself referring to this often enough that I wanted to write it up; saves me the effort of explaining it in future.

First off, a couple of requirements:

  • low latency on the user input side
  • deal with my somewhat ridiculous volume of IRC usage
  • accessible from any reasonable platform (which I roughly classify as “anything with a keyboard for input, and has internet”)

So when I say “somewhat ridiculous”, that means:

  • 12 IRC networks
  • 65 channels (of varying volume)
  • varying numbers of query windows, usually about 30+ open

I flatten my jabber/gtalk to IRC as well, by using bitlbee. It counts among the 12.

Historically, I had this set up as irssi with irssi-proxy in the USA, then another irssi+irssi-proxy at my home (to join a network only accessible via the WUG at that point), and then I would connect my machine-local client to that server (which was on dyndns). A couple of pain points with this included the fact that dyndns sucks donkey balls, and syncing of logs (which I did with rsync at the time) was crappy. At the time I also had less IRC volume than I do now.

Aside from those pain points, and the occasional power outage at home (which just made me link up to my parent client), this worked well. Quassel’s backlog fetching is shiny, though. Very shiny. I wanted it. So I redid my IRC setup. Now there’s only one master server (currently in Germany), with a quassel core connecting to it. The irssi proxy config looks like so:

20:08:39 -!- Irssi: Module proxy/proxy already loaded
20:08:44 [irssiproxy]
20:08:44 irssiproxy_bind = 127.0.0.1
20:08:44 irssiproxy_password = passwordhere
20:08:44 irssiproxy_ports = freenode=6001 shadowfire=6002 oftc=6003 bitlbee=6004 ...

So basically:

  • /load proxy
  • /set irssiproxy_bind ip
  • /set irssiproxy_password ircpassword
  • /set irssiproxy_ports network=port network2=port2

Connect the quassel core up to the proxy, and that’s it. Infinite scrollback for any of my devices with quassel, and I can just ssh from some random server and connect up to screen as well (which has saved my bacon in DCs a few times).

And yes, I know this is (a bit) crazy.