I'd bought an ATtiny85 to play with some of the ATtiny Arduino support (or failing that, work out how to use avr-gcc directly). I also had a bunch of very bright LEDs and some cheapy cell batteries sitting around doing nothing.

First, I took one of the spiffy cases from when we bought some kids' earrings recently, and drilled holes to shape out a heart.

Poking the LEDs through, I kept the cathodes all in the centre, so I could bend them all inwards and haphazardly solder them all together. I also used wire to bridge each LED with its opposite, so I'm driving a ring of ten LEDs with five pins.

Finally, I soldered the pre-programmed ATtiny85 to the LED anodes, using a small piece of electrical tape to ensure it isn't going to inadvertently touch any of the mess below it. The cells (wrapped in electrical tape) go directly to the power & ground pins on the chip, and a resistor feeds the ground to the LED cathodes.

Brilliant.

Except I made an off-by-one error in my sketch that I didn't notice during testing (c % 6, instead of c % 5). Thankfully, I was able to fairly easily solder on wires to a 6-pin ISP header and flash a new program.

Final result:

The source code is available here: https://github.com/mibus/MibusArduino/tree/master/MothersDayFlasher

Dutifully, I checked the record:

$ dig @ns43.domaincontrol.com mibus.org mx

;; Query time: 89 msec
;; SERVER: 216.69.185.22#53(216.69.185.22)
;; WHEN: Fri Feb 24 08:42:50 2012
;; MSG SIZE rcvd: 155


Yep, there it is.

(...and yes, I'm with GoDaddy. I'm horribly likely to shift at my next renewal - if not before. But anyway).

Wait. "MibUs.OrG."?

It's repeatable, on that _one_ NS, from both the US and here in Australia. The other NS, is fine. Non-MX queries... are also fine. Mixed-case queries for the MX, all come back in that one same (different) case.

What. The. Hell.

I made a change to my zone data with their pretty web-based console. Re-ran the query... and it was fine. Except, all the mixed-case queries all came back lowercase.

Hmm. I wonder.

I made another change.

$ dig @ns43.domaincontrol.com Mibus.Org mx

;; Query time: 86 msec
;; SERVER: 216.69.185.22#53(216.69.185.22)
;; WHEN: Fri Feb 24 08:47:52 2012
;; MSG SIZE rcvd: 155


...and now, all DNS queries come back with this "proper case" version.

It's my humble opinion as a DNS administrator elsewhere, that they're running some sort of fancy reverse-caching DNS server in front of their "real" DNS servers; one that fakes the "AA" flag on responses, doesn't drop the TTL, and is cleared by their software on updates.

Oh, and one that preserves the case of the first query it sees in its cache, and keeps it around.

Why is this important? Well, for starters it's just stupid. For seconds, people are starting to use bit 0x20 (ie., the "shift" bit) for adding extra entropy in to DNS queries. GoDaddy's DNS servers go well beyond breaking it and in to the territory of royally messing it up.

• A coworker asks if I want to join them for a coffee. (This happens multiple times per day, FWIW). I say "Yes!" and jump up...
• ...then sit back down to lock my computer screen, and hop back up...
• ...only to realise I've left my music playing - so I sit down, unlock my screen, pause my music, and re-lock my screen...
• ...at which point, my coworkers have already long since disappeared.

My solution? A Desktop SCRAM button, where I can just go whack and walk away with impunity.

It's made up of a USB-serial cable, and a ~$10 button. The button's two contacts are wired to the DSR and Ground lines respectively.

The code is available (GPLv3) at: http://github.com/mibus/DesktopScram/

I bought the Pebble v2 demo kit and attended the "Arduino miniconf", and the "bag schwag" included the Freetronics LeoStick.

Here's a demo video I made of a Raining display on the LCD.

It uses the Pebble v2's 20x4 LCD display and custom characters to display a "rain" effect (the LCD needs to be mounted sideways, as shown in the video). It could readily be extended to have different levels of rain based on CPU load or net traffic, or some other monitorable metric.

The code is available for download, along with a lot of other mini-projects I've hacked up in the last month.

I have a new hobby!

Get the custom pymds fork here; it'll be merged upstream shortly-ish.

Caught out needing new "Sun" Java packages for Ubuntu, by the DLJ revocation?

Grab a usable set of build source packages from http://archive.canonical.com/ubuntu/pool/partner/s/sun-java6/ - you'll need an *.orig.tar.gz, a *.dsc, and a *.debian.tar.gz file for the version you've picked. I used a 6.26 version from Natty.

Grab a latest (currently 6u30) "bin" Linux packages for each architecture from http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase6-419409.html (Note: needs Javascript!).

dpkg-source -x *.dsc
cd sun-java6-6.26/
rm *bin
mv ~/Downloads/jdk-6u30-linux-i586.bin jdk-6u30-dlj-linux-i586.bin
mv ~/Downloads/jdk-6u30-linux-x64.bin jdk-6u30-dlj-linux-amd64.bin


Edit debian/rules, comment out the section following the comment 'check if the sources are the "same"'.

dch -v 6.30

(add in a stub changelog entry - this is just so it realises what version it's building)


cd ../sun-java6-6.30
dpkg-buildpackage -b -uc


Then you should be left with workable packages matching the last Ubuntu-released ones, but with a newer JRE/JDK.

Note #1: I haven't so much as installed these packages, it's just theory. It built, it ships - I mean, hey, it's New Year's Eve! ;-)
Note #2: This won't include a working web plugin - I pulled the build packages from after 6.26-1natty1, which was the last release with a working web plugin.

We're pleased to announce that your proposal(s) has/have been ACCEPTED for LCA2012.

<SNIP>

---
 IPv6 Dynamic Reverse Mapping - the magic, misery and mayhem
---

So - wow! I'll see you there :)

But still, screwups happen. Here's some tips on what to do to try to ensure you aren't caught out in the cold.

Tip 1: Have multiple servers.

Without a doubt, this is the biggest tip about DNS. Designed in from the beginning was an assumption that you'd have multiple nameservers for a given zone. So... have them!

Put them as far apart as you reasonably can - different hosts, different networks, different power. The more they share, the more risk you're in.

Countertip: Hosting your DNS server only over your ADSL link.

Tip 2: Do backups.

Pretty standard sysadmin fare. RAID isn't a backup, and neither is a slaved nameserver.

Tip 3: Nameservers must all agree.

You know how kids will sometimes ask their parents the same question independently, hoping for a different answer? It's important that the parents always give the same answer, and it's downright vital that your nameservers do too. Don't let them get out of sync!

Typically, zone transfers fix all your woes here, but do make sure they're working.

Tip 4: Test your changes directly against all nameservers.

It's just a small change, right? What could go wrong? Lots! So test each server individually. If one doesn't update, maybe you have a problem that you need to fix. (Or maybe it's just a bit laggy - it happens). "dig" is your friend.

Countertip: Not realising until too late that you're breaking Tip 3

Tip 5: Make your NS records match your glue.

If you've told your domain registrar that your nameservers are ns1.example.org and ns2.example.org, then make sure you put that in your zone file too - all sorts of wacky caching issues can ensue when you don't.

Tip 6: If you use a CNAME record, don't use anything else.

CNAMEs are a really convenient way of saying "www.example.org is really webserver.example.org". You can't then say "But www has an MX of foo.example.org" or "www is also a subdomain with nameservers at ...".

That'd be contradictory, because you've already said with the CNAME that it's really webserver.example.org. It can't be both, if it's both then it's actually something different altogether and needs its own records.

Relatedly, don't point a CNAME at anything other than a plain hostname - Don't try to CNAME www.example.org to example.org, it'll just break stuff.

Tip 7: Don't firewall out DNS queries to your nameserver.

No, really. The whole internet needs to be able to look up domain names, not just some of it, not just most of it. (You're excused if it's a private nameserver, of course!).

Counterpoint: Using bogon filters on nameservers and ignoring genuine queries.

Bonus Tip: Monitor your servers.

If you're running DNS servers in production, monitor them so you know that you haven't lost one. Once it's all set up right, you really can lose one without noticing.

An easy win here is to normalise the numbers you call. In South Australia, a number listed as "(08) 5550 1234" can be dialled as either 0855501234 or 55501234 - the "08" prefix is optional, since it merely clarifies the area code.

Since you don't want to have to reconcile against both forms (that just makes things messy), let's clean it up so it always appears with the leading '08':

;; Handle 08XXXXXXXX calls by default, as this is our "native" area code here in SA.
exten => _XXXXXXXX,1,Goto(08${EXTEN},1)


Easily done.

Another common issue is to 'answer' an outbound call (either explictly with Answer() or implicitly with something like Playback()) before actually dialling. Answering the call too early means your billsec - which you're potentially basing your customer billing on - is higher than it should be!

If you want to play a message back to the caller before the call itself is made, use Progress() to indicate that you're doing it as the call progresses, and that the call isn't actually connected yet.

A final example is much less common - when dialling one number actually calls another; you have several options available with different tradeoffs. For this example, pretend that the PSTN-looking number 0855501234 should actually be delivered to the VoIP-looking number 0870101234. (Maybe it's a cheaper internal-use-only equivalent number, and people forget to use it?)

This example will have your CDR showing the original number (the PSTN number that was dialled, rather than the number that was actually called). It assumes your upstream SIP provider is named vsp1


exten => 0855501234,1,Dial(SIP/0870101234@vsp1)


This example will have your CDR showing the number that was really called, not the number dialled:


exten => 0855501234,1,Goto(0870101234,1)


The following will have a mix of the two - a CDR for 0870101234 for the ringing, and a CDR for 0855501234 covering the ringing and the billable call. This assumes regular_outbound is your context for outbound calls.

exten => 0855501234,n,Dial(LOCAL/0870101234@regular_outbound)


So, that's a few easy ways to make sure that your CDRs are actually worth the bits they're saved with.

Absolutely!

As an example, imagine the contexts incoming (where calls go to when they come in to Asterisk from a SIP provider) and outgoing (which allows outbound calls from internal phones). There's also an internal context to allow calls between internal phones.

[internal]
exten => s,1,WaitForExten

;Internal extensions
exten => 1000,1,Dial(SIP/alice)
exten => 1001,1,Dial(SIP/bob)
exten => 1002,1,Dial(SIP/charlie)
exten => 1003,1,Dial(SIP/jack)

[outgoing]
include => internal
;External calls
exten => _XX.,1,Dial(SIP/${EXTEN}@voipprovider)

[incoming]
; Incoming calls go to Alice, our receptionist
exten => s,1,Dial(SIP/alice)

Let's add in an override for when an employee rings in from their mobile phone - instead of having to talk to Alice, they get put back into the internal context, so they get to directly dial an extension.

Within the incoming context, add:

exten => s/0491570156,1,Playback(please-enter-the)
exten => s/0491570156,n,Playback(number)
exten => s/0491570156,n,Goto(internal)

We can make it a bit better yet. Let's allow another employee's mobile phone in, and let's share the config by moving them to a different context. We can also reuse parts of the dialplan in the new context by only using the CallerID information to override the first part of the sequence.

[incoming]
exten => s/0491570156,1,Goto(employeemobiles)
exten => s/0491570157,1,Goto(employeemobiles)
exten => s/0491570158,1,Goto(employeemobiles)
[employeemobiles]
exten => s/0491570156,1,Set(CDR(accountcode)=alice)
exten => s/0491570157,1,Set(CDR(accountcode)=bob)
exten => s/0491570158,1,Set(CDR(accountcode)=charlie)
exten => s,2,Background(please-enter-the)
exten => s,3,Background(number)
exten => s,4,WaitForExten
include => internal

Note the accountcode being set - this way, you can readily choose to allow outgoing calls from your PABX for remote employees - and it all gets tracked separately (per employee) in your call data records.

You can also just as easily use include => outgoing so that calls in from the mobiles can make calls back out to any other number (eg. if you have great international rates from your PABX, or free calls to certain numbers).