Okay, so as per what I just wrote here, after a fucking hour spent writing this, which itself was in trying to process fucking broken technology.
Wine time.
And switching away from this god-awful platform is now going to happen this weekend.
Okay, so as per what I just wrote here, after a fucking hour spent writing this, which itself was in trying to process fucking broken technology.
Wine time.
And switching away from this god-awful platform is now going to happen this weekend.
To state that there was a non-minor daisychain of clusterfucks that led to me even writing this post right now… almost feels like the emotive commitment to “attempting to express this” was abandoned mid-way.
Which I know is a far cry from the usual tech-heavy contents of this blog in the past, and well fuckit. Feelings are real too.
So, the starting point: I finally scrape together enough mental capacity to change my fucking seat, move over to my piano/keyboard, and get some practice in. ADHD + executive function issues. Shit’s great.
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.
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:
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
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.
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.
1x FiiO E10K
1x Sennheiser HD598
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.
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)
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.
mysql> delete from wp_comments where comment_approved=0; Query OK, 16330 rows affected, 40 warnings (0.59 sec)
*updates wordpress, disables comments, leaves Disqus to do the rest*
Been a while. I wrote some small bad software. The cornercase for which I needed it was “mutually-viewed screen session running pushloop, which does puppet runs” for some work a colleague and I were doing. Post-receive config to echo to a file (from your DVCS of choice), done/done.
I’ll also be doing a talk on Logcabin at PyconZA this coming week (with opensourcing the module coming in the near future). It’s been fun doing things with that.
Outside of the tech space I guess I’m just waiting for things to tick up.
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.