Category Archives: minipost - Page 2

ThoughtStreams

In various ways, I’ll likely stop using the minipost tag/category, and rather feed all of that over here now: https://thoughtstreams.io/froztbyte

In general it seems like a platform better suited to that sort of thing. Time will tell.

Rage About Dinosaurs

This text snippet from a colleague, although I’m fairly sure I’ll get my copy of the announcement soon as well:

“Up until now, Last.fm radio has been a subscription only feature in your country. However, unfortunately, from Tuesday 15 January 2013 we are no longer able to provide radio streaming to you due to licensing restrictions, and you will no longer be able to listen to Last.fm radio.”

I honestly wish all these dinosaur media companies and committees and agencies and whatever would just die already. Earlier today I was speaking to a friend of mine, one who also happens to be an artist. She’s currently raising money for her new album, and is just running it entirely by herself. Not that any of this is new to anyone sensible, of course. All of this licensing crap is just ridiculously frustrating, and at a guess I’m fairly sure it doesn’t actually end up helping all that many artists.

Ah well….hopefully time brings some useful change. At least the antiquated ITU seems to have been sent a decent message about how things should work.

Zenoss Device Listing

Nice for if you need some form of automated report in zenoss, here’s a code snippet to print out a list of devices per class, formatted in markdown markup

typehash = {}
for d in dmd.Devices.getSubDevices():
    if typehash.has_key(d.getDeviceClassPath()) == False:
        typehash[d.getDeviceClassPath()] = []
    typehash[d.getDeviceClassPath()].append(d.viewName())

for key in typehash:
    print """### %s\n""" % (key)
    for item in typehash[key]:
        print "*   %s\n" % (item)
    print ""

Run it in the zenoss console, or anything with a dmd connection. Tested on 2.5.x, but should be trivial to port forward if it breaks.

(PS: I could probably fix up that last bit to do something with .iteritems() instead…)

Post-jump, things everywhere die

Always a bit interesting to check out stats for things on the internet after a major event like Felix Baumgartner’s jump from space today. Here’s a graph for JINX, one of the two .za INXs.

Interestingly, it seems to have all come from only one of the two GGCs that are visible via that path.

Elsewhere we see similar drops, and also some of the GGCs dying (502’s were served up for a while). Here’s the CAR-IX stats:

During the stream, some people were handed off to Akamai edge nodes. I don’t have that much information on what was happening in all the various networks, though. Will be interesting to see that coming to light soon from the likes of Renesys and such.

Update: I see the first image from this page made it onto one of the .za news syndicators without credit. Nice of them.

Old tricks, new coins; same problems

In setting up some mirrors recently, I’ve come to learn that rsync’s algorithm by default doesn’t deal well with long-haul TCP going hand in hand with small files. I still need to set aside some time to find a nice set of optimization flags to tweak that up a bit more. And when I say “doesn’t deal well”, I mean in the region of “can tx about 1/3rd a single-session TCP speedtest can do over the same path”. Later’s worry, though.

So, the point of this point:

receiver$ nc -l 1234 | pv | tar xf
sender$ tar cf - moz | pv | nc receiver.domain.tld 1234

And there you have a minimal-CPU-usage streaming file delivery setup. Of course, this doesn’t deal with retransmits or anything else. This just gets the bulk over. After that you can run an rsync with big block lengths over all of it, and get any files fixed using that.

And the “old trick” part of this? As far as I know, this is pretty much how the whole tape drive thing used to work[0]. I’ve just added some internet in the middle.

[0] – I wouldn’t know for certain, before my time

Elegua

Public Service Announcement

Anyone who makes use of elegua, the transition of services on it is now complete and I’ve updated the main A and AAAA records to point at the new host.

If you have any issues, you know where to find me.

(That said, the original TTLs were like six gazillion years or something, so caches might flush later as they go. Query the upstream NS for the new record if you need it.)

Fun things to come home to

*sigh*….so much for the idea of doing work on Coursera thing (I just signed up for today) tonight:

yariman# tail -n 100 syslog | grep ppp
Sep 10 16:44:41 yariman pppd[24971]: Plugin rp-pppoe.so loaded.
Sep 10 16:44:41 yariman pppd[24972]: pppd 2.4.5 started by root, uid 0
Sep 10 16:45:16 yariman pppd[24972]: Timeout waiting for PADO packets
Sep 10 16:45:16 yariman pppd[24972]: Unable to complete PPPoE Discovery
Sep 10 16:46:21 yariman pppd[24972]: Timeout waiting for PADO packets
Sep 10 16:46:21 yariman pppd[24972]: Unable to complete PPPoE Discovery
Sep 10 16:47:26 yariman pppd[24972]: Timeout waiting for PADO packets
Sep 10 16:47:26 yariman pppd[24972]: Unable to complete PPPoE Discovery
Sep 10 16:48:31 yariman pppd[24972]: Timeout waiting for PADO packets
Sep 10 16:48:31 yariman pppd[24972]: Unable to complete PPPoE Discovery
Sep 10 16:49:36 yariman pppd[24972]: Timeout waiting for PADO packets
Sep 10 16:49:36 yariman pppd[24972]: Unable to complete PPPoE Discovery
Sep 10 16:50:41 yariman pppd[24972]: Timeout waiting for PADO packets
Sep 10 16:50:41 yariman pppd[24972]: Unable to complete PPPoE Discovery
Sep 10 16:51:46 yariman pppd[24972]: Timeout waiting for PADO packets
Sep 10 16:51:46 yariman pppd[24972]: Unable to complete PPPoE Discovery
Sep 10 16:52:51 yariman pppd[24972]: Timeout waiting for PADO packets
Sep 10 16:52:51 yariman pppd[24972]: Unable to complete PPPoE Discovery
Sep 10 16:53:00 yariman pppd[24972]: Terminating on signal 15
Sep 10 16:53:00 yariman pppd[24972]: Exit.

Line sync’d where it always has, good signal vs noise, etc. DSLAM or something in the middle just missing. Now to wait and hope my ticket gets to a useful support person. It *sucks* not having access to the local loop.

And Justin Case™ you couldn’t guess it, that post title is a lie.

Everything is not “just a string”

During a quick conversation on unicode and punycode, I managed to find http://☁→❄→☃→☀→☺→☂→☹→✝.ws

Cute, and a sad reminder of how many people still fight this.

Should I buy some stock?

thoughts: I still have some stock account balance left..wonder if I should buy some..

In [1]: from random import choice
In [2]: choices = {'buy': 0, 'wait': 0}
In [3]: for i in range(0,5000):
    choices[choice(['buy','wait'])] += 1
   ...:
In [4]: choices
Out[4]: {'buy': 2518, 'wait': 2482}

Guess I’ll buy some stocks.

[ed's note: this method works equally well to decide which stocks you want to buy when you're lazy]

S(hitty)NMP

This post will highlight Mikrotik/RouterOS issues, but it’s certainly not only them that suffer from S(hitty)NMP implementations.

Far be it from me thinking SNMP is perfect, nor that it’s necessarily always a good idea. I just have to wonder how it’s possible to screw up such a simple thing.

For example, Mikrotik has this nifty feature where you can look up the OIDs in a specific context by calling the print command with the parameter oid:

[user@R1] /system resource> pri oid
           uptime: .1.3.6.1.2.1.1.3.0
  total-hdd-space: .1.3.6.1.2.1.25.2.3.1.5.131073
   used-hdd-space: .1.3.6.1.2.1.25.2.3.1.6.131073

Except then this happens:

mon# snmpwalk -c ${com} -v 2c ${host} 1.3.6.1.2.1.25.2.3.1.5.131073
HOST-RESOURCES-MIB::hrStorageSize.131073 = No more variables left in this MIB View (It is past the end of the MIB tree)
mon# snmpwalk -c ${com} -v 2c ${host} 1.3.6.1.2.1.25.2.3.1.6.131073
HOST-RESOURCES-MIB::hrStorageUsed.131073 = No more variables left in this MIB View (It is past the end of the MIB tree)

The situation has at least improved vastly, though. Instead of finding the MIB file in some godforsaken dead corner of their documentation site (which is basically just kept on life support), the wiki has a formal section for it now. Still…things could be better:

  • Still no trap support in the various routing protocols/daemons (as far as I know)
  • Various bits of inconsistency like the above items
  • Indexes on dynamic interfaces and the like change, and with no way (that I’m aware of, once again) to lock them to a specific index irrespective of interface state.

There’s another issue that might’ve been fixed in the meantime, I haven’t checked in a while. SNMPv1 has a specific set of counter types, and anything bigger than n (where n was some signed integer limit or something) would only be displayable in SNMPv2. RouterOS just decided to not care about this at all, and respond with the number under the same counter type, but only ever when using SNMPv1.

Seriously, why is this stuff so broken?