In Memoriam: Jon Portnoy (avenj)

Occasionally folks come into large IRC channels and ask some variant of “anybody alive?”. Sometimes I would reply, “No, we are all ghosts in the shell”.

Today, I logged onto IRC and found out that we did indeed have a ghost in our midst.

Jon “avenj” Portnoy is the type of dude on IRC who always says “hey” back no matter the time. Sometimes I thought the dude never slept. An avid Perl programmer he made me see beauty in a language where I only saw gibberish. #otw will never be the same again but I hope the rest of us can keep the spirit of it alive.

In his memory, I have made a donation to The Perl Foundation. If you wish to do so as well, you can do so from here.

Rest in peace, friend.

Firewatch and SUPERHOT: A Tale of Two Games

This past weekend I played two games: Firewatch and SUPERHOT. This post is not intended to be a review of the two games but a look at the polar differences between the two and why one gets a lot of flack for its perceived lack of content and why the other is praised for its mechanical purity.

Now you might ask, “Sadiq, why does this matter? These are two entirely separate games in two entirely different genres!”. To that I answer:

  1. Humour me, I need to flex my writing muscles.
  2. Do the words “value proposition” sound important to you? If so, you are in for a treat.
  3. The voices in my head say interesting things sometimes and I would like to write this down.

Let us jump in shall we?

Continue reading “Firewatch and SUPERHOT: A Tale of Two Games”

An overview of OS support for IPv6 resolver distribution methods

In this post I will be going over the various levels of support for IPv6 resolver distribution for popular operating systems. Focus on desktop and mobile versions of OSes as those are the ones where we are usually automatically distributing resolver information. Dual stack is implied but IPv6 only functionality can be gleaned from said information as well.

Continue reading “An overview of OS support for IPv6 resolver distribution methods”

CCIE Lab Diary – OSPF Lab

This one is a bit late, but hey better late than never. BGP is next so hopefully no more frame relay.

Overview/Goals

Implement OSPF in a 9 router network with frame relay as the underlying L2 encapsulation to demonstrate protocol behaviours in a NBMA environment. Also involves tweaking of various parameters using summarization, redistribution, distribute lists, virtual links, LSAs etc.

Technologies involved:

  • Serial interfaces
  • Ethernet interfaces
  • Frame Relay
  • OSPF

Logical topology

ospflab

Pitfalls/Things to watch out for

  • OSPF LSA database vs. router’s route table
  • OSPF network types and timers

CCIE Lab Diary – EIGRP Lab

Overview/Goals

Implement EIGRP in a 9 router network with frame relay as the underlying L2 encapsulation to demonstrate protocol behaviours in a NBMA environment. Also involves tweaking of various parameters using summarization, redistribution, various stub types, distribute lists etc.

Technologies involved:

  • Serial interfaces
  • Ethernet interfaces
  • Frame Relay
  • EIGRP

Logical topology

eigrplab

Pitfalls/Things to watch out for

  • Frame Relay PVC issues
  • EIGRP timers on “slow” links, might want to tune them

CCIE Lab Diary – Layer 2 Lab

This is going to be a series of posts regarding the labs from the CCIE Routing and Switching class at UOIT.

I feel like these labs are complex enough for such posts to be interesting.

Overview/Goals

As the title of the post suggest this is a lab that incorporates various L2 technologies to implement.

Technologies involved:

  • Ethernet interfaces
  • Serial interfaces
  • VLANs
  • STP
  • LAGG (EtherChannel)
  • PPP with CHAP/PAP authentication
  • Frame Relay (ugh.)

Logical topology

l2lablogicaltopology

Pitfalls/Things to watch out for

  • The lab requires you to configure VLAN pruning on trunk links appropriately. Make sure to take a look at both the physical and logical topology to figure that out. Do this right the first time, you don’t want to backtrack later to fix issues with that later.
  • Frame relay is just as annoying as it was during the CCNA labs. Lack of practice with it does not help. Not all the DLCIs shown in the logical topology actually need to be used.

Auto playing videos

Usually don’t do posts like these but..

Twitter, Facebook, $SOCIALNETWORKINGSITE:

Auto playing videos are stupid.

  • You are wasting my bandwidth and yours
  • If I wanted to see the video, I would you know..click it and watch it. What a novel concept.

Stop. doing. them.

I do not care if it is the cutest cat video this side of the Milky Way or a horrifying video of a journalist being shot. Just stop.

Thanks,
An Internet user who knows how to click things he wants to watch.

Adiós self-hosted mail server

As the title suggests, I will be retiring my self-hosted mail server (mx1.staticsafe.ca) soon, most likely by next month.

It has been a lot of fun and an excellent learning experience but I simply cannot devote the time and/or effort into active maintenance of the server.

I am moving all of the mailing lists that I used this server for to the extremely competent folks over at Fastmail.

The retirement will be done in a few stages as follows:

  1. Stage 1 – Personal mailing list subscription move (completed)
  2. Stage 2 – Change of MX, SPF records for staticsafe.ca to Fastmail’s servers and add a wildcard alias there.
  3. Stage 3 – Discontinuation of relay/non-personal services on mx1.staticsafe.ca. One person is using this server as a submission relay for their server. I will be asking them to move to my new MSA only server. Services for caffeine-linux.org will also have to be discontinued.
  4. Stage 4 – Stop all relevant daemons. Postfix, Dovecot, amavisd-new.

My Thanks

A lot of people and/or companies have provided direct and/or indirect support for this learning experience.

  • Linode Library for providing initial inspiration for the current configuration of the server
  • The folks in the Postfix and Dovecot communities. (#postfix, postfix-users, #dovecot, Wietse for the wonderful software)
  • purrdeta for telling me mail servers are a lot of fun

Addendum

I have put my server configuration files on Github if anyone is interested, you can see them here.

Ubuntu 14.04 Server and IPv6 Temporary Addresses

So, as we all know Ubuntu 14.04 was released today. I downloaded the server ISO to test in VirtualBox.

Let us see what we have here:

ss@trusty-testing:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04 LTS"

ss@trusty-testing:~$ ip -6 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
 inet6 2001:470:1d:96b:70bb:7393:2071:faa2/64 scope global temporary dynamic
 valid_lft 597675sec preferred_lft 78675sec

Wait what? Am I going blind or is that an IPv6 temporary address [0] on a supposedly server image?

Investigating further:

ss@trusty-testing:~$ sudo sysctl -a | grep tempaddr
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
net.ipv6.conf.eth0.use_tempaddr = 2
net.ipv6.conf.lo.use_tempaddr = 2

What the hell? Not only did they leave temporary addresses turned on, they set the sysctl value at 2 which means that the system will prefer temporary addresses over standard ones for making connections. [1]

I asked around and apparently this is the case on Ubuntu 12.04 server as well.

ss@ubuntu-testing:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.4 LTS"

ss@ubuntu-testing:~$ sudo sysctl -a | grep tempaddr
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
net.ipv6.conf.eth0.use_tempaddr = 2
net.ipv6.conf.lo.use_tempaddr = 2

So that is two LTS server releases with IPv6 temporary addresses turned on and set to 2.

Why are temporary addresses bad on a server?

Unpredictability – anything depending on source address validation. Even SLAAC addresses are more predictable because they can be calculated given the MAC address of the NIC.

Ideally, you should be configuring your server’s addresses statically. Leaving temporary addresses turned on on a server image is just a bad default.

References:
[0] – https://tools.ietf.org/html/rfc4941
[1] – http://ipv6int.net/systems/linux-ipv6.html#privacy