Bacon Pecan Pie

I made a pecan pie for Pi day. I love pecans but I've never liked pecan pie because the overly sweet goo is such a put-off. Corn syrup is much cheaper than pecans so I guess you get what you pay for. My pies turned out right on the edge of sweet and savory. I loved them. Here's my recipe.

• 2 lbs. whole raw pecans
• 1 cup brown sugar
• 1 cup maple syrup
• 4 strips thick-cut bacon
• 3 medium eggs

Fry the bacon until it's crisp. Cut three strips into bits and save one for garnish. In a saucepan combine the sugar and syrup with two table spoons of bacon grease and heat until the sugar is dissolved. Stir smashed pecans and bacon bits into the syrup mixture and allow it to cool somewhat then stir in the beaten eggs. I baked mine in two prefab pie crusts at 400 degrees for 40 minutes.

The Internet of Horticulture

At the beginning of the school year Peter Shaw from the Horticulture Department asked to meet with the CS/CIS faculty about using technology in their growing operations. The Horticulture Department has magnificent greenhouses and very high tech hydroponics. So how can digital technology enable agricultural technology? The challenge seems almost too perfect a fit for exploration of the Internet of Things.

So what do you build?

We decided to take an existing function and make it more user friendly. The greenhouse has a system that uses the daily light integral to determine how much to water. It's a simple system. Light is accumulated until the measurement reaches a threshold then the water is turned on for a time. So how could a system that has two parameters (threshold and duration) be unfriendly? When both parameters are set by DIP switch. Ouch!

What networked gadget measures light?

This device is designed to use solar power alone. Since it's measuring the sun it's safe to assume it will be put in the sun and the ATtiny85 processor packs a lot of Arduino compatible punch with very little power. The bulk of power consumption comes from turning the XBee on once and a while. The robotics club prototyped this circuit over the fall semester using a breadboard. Now it's time for our first PCB!

Howto: Setup web-based IRC on Ubuntu

I want a way for students to chat me when I'm in my office hours. My classes are online and I want to make it easy for remote students to reach me. I had some time to try different solutions and I found one that is very easy to use. I had a few constraints:

1. Anonymous signin from the web. I don't want to have to create and delete accounts for students because that's a lot of work and, since I'm using my own server, I don't have access to the CIS AD server.
2. Use a popular protocol. Just because students login on the web doesn't mean that I should login from the web. I want to have my choice of clients so that I can pick one that's easy for me to manage. 
3. Using Ubuntu (of course)

So here's what I came up with. I started with ircd-hybrid. It's fairly simple to configure with a very readable configuration syntax. Install it:

apt-get install ircd-hybrid 

There are two files you will need to change first-thing:

/etc/ircd-hybrid/ircd.conf (the main configuration file)

/etc/ircd-hybrid/ircd.motd (the login message)

The ircd.conf file is fairly well documented. I setup the basic settings, naming my server and providing admin information. Because we'll be accessing this server over the web and because my webserver runs on the same machine I had to tweak the configuration somewhat. 

The irc daemon by default trusts clients connected from "localhost" (127.0.0.1). That's usually a very safe thing to do. In my case localhost should not be trusted so I altered the following section: 

auth {

        user = "*@127.0.0.1";

        spoof = "irc.lifealgorithmic.com";

        class = "users";

        flags = need_password, spoof_notice, no_tilde;

};

In this definition I use the "spoof" directive because I want to control what the domain name looks like in the client. In the default auth section I set a password:

auth {

        user = "*@*";

        class = "users";

        password = "SoooperSeeeeecretPaaaaasword";

};

This will keep random lurkers out because I can give my students the password in class. A determined person could watch my class or slides for the password but that would take more than a port scanner. If need be I can password protect the web interface. 

Now we need a web client. There happens to be a really nice and attractive one called KiwiIRC. It hasn't made it into Ubuntu yet but I hope it will someday. It's a very elegant program written in node.js. I read the installation instructions, but they need to be amended if you intend to run securely as a daemon. 

1. Install node.js and some components 

apt-get install npm

2. Create a user for kiwi. 

useradd -d /srv/kiwi -r kiwiuser

The user's home is in /srv/kiwi where I intend to install it. The kiwi user is a system user and doesn't (shouldn't) have a password. Create the home directory and make sure kiwi owns it:

mkdir /srv/kiwi

chown -R kiwiuser:kiwiuser /srv/kiwi 

3. Become kiwiuser and follow the installation instructions.

4. Make it an always thing. Until they throw upstart overboard we need to add a script to /etc/init. 

# This is /etc/init/kiwi.conf

# kiwi - The Kiwi web based IRC server

description "Kiwi server"

start on runlevel [2345]

stop on runlevel [!2345]

script

  HOME=/srv/kiwi

  export HOME

  cd /srv/kiwi

  exec /srv/kiwi/kiwi start

end script

exec /srv/kiwi/kiwi start

Now you can start kiwi with

service kiwi start

Unfortunately kiwi doesn't play nice with upstart and stopping the service must be done by hand. It's a small price to pay. Kiwi's configuration (found in config.js) is very simple. These lines matter if you're starting it as root: 

conf.user = "kiwiuser";

conf.group = "kiwiuser";

They tell kiwi to drop permissions, which it does. The daemon logs as it's own user so you will have to create a separate directory in /var/log to store the log file and give it proper permissions. Here's how you get kiwi to only connect to the local IRC server:

conf.outgoing_address = {

    IPv4: '127.0.0.1'

};

It won't be able to make connections anywhere else with that address. That's a good thing for me because I don't want my site to be abused. In the "conf.client" section you can set the default values the client gets. They can be overridden by the user or using HTML (which is rad). But the more interesting section to me was this group of directives: 

conf.restrict_server = "irc.lifealgorithmic.com";

conf.restrict_server_port = 6667;

conf.restrict_server_ssl = false;

conf.restrict_server_channel = "#web";

You can use these directives to force the way kiwi can connect to the server. This let's me put all my web clients into the "#web" jail if I want. It also keeps clever hackers from using HTML to override my defaults. The last step is to embed the widget onto your site. You can do that with an iframe element. Add HTTP arguments to control default values. Here's an example: 

<iframe frameborder="0" height="400" width="400px"

  src="http://irc.lifealgorithmic.com:7778/?theme=mini&amp;channel=#office"

></iframe>

Notice you can specify what channel to login to by default. Assuming you haven't put your users in the web jail you can use that to make widgets chat-room specific. That's what I want. 

Cisco Configuration Cheat Sheet - Part 2: More security

 h/t Omar Noory

Security is important (no, critical) to the success of a network. The cartoon on the right is the first image macro stating what is now known as an axiom of Internet life:

"Haters gonna hate"

 The phrase is used to dismiss hateful speech (often called trolling) on the Internet, especially in anonymous forums. But it's implications go much further. More people connected to the Internet means greater diversity and flow of ideas and possibly greater Democracy. It also means a greater diversity of bad behavior like trolling and hacking. People that have been into computers for a long time wish for the old days when everyone on the Internet could be trusted. Those days are gone and that's for the better.

The complexity of networks makes them resemble living things. Like living things they are constantly under threat and those threats will test their defenses and adapt. Networks, therefore, must be adaptable, resilient and self-healing. Our bodies have developed immunity to viruses in order to preserve our lives and our genes, but the defense isn't perfect and, as we now know, viruses are key drivers of human evolution. Without the viruses (and the damage they cause) we would not grow. That's true for networks, too.

So in celebration of hackers, here's something you can do to keep them out. Keep your sessions secure by doing some basic configuration:

// Make sure passwords are good passwords 
// (8 is not enough!)
(config)# security password min-length 12 

// Don't let people guess at will or they 
// will use automated bots to guess
(config)# login block-for 120 attempts 3 within 60

// Logout after a while so someone can't hijack your 
// terminal while you're at lunch
(config)# line vty 0 15

(config-line)# exec-timeout 10 

Cisco Configuration Cheat Sheet - Part 1

I'm teaching CIS-81 Fundamentals of Networking next semester (with the great Rick Graziani). The class is taught using Cisco equipment. Until this summer I've never touched a piece of Cisco hardware in my life. What an eye opener! The CLI is very strange and primitive compared to Linux. But it's a CLI, therefor I like it.

I've been using Packet Tracer (AMAZING!) to do my labs and it's really incredibly fun. So here are the first tasks I do when setting up a network. The network is pictured on the left.

I'm going to start by configuring the router. I don't use the default configuration dialog because I want to do everything myself.

// Step 0: Basics 
> enable
# config t 
(config)# hostname ginsu
(config)# ip domain name lifealgorithmic.com // Need for SSH
(config)# banner login \

(config)# banner motd \

// Step 1: Security 

// Set the "enable" password. Never use enable password!
(config)# enable secret cisco 

// Set the password to login to the console
(config)# username cisco secret cisco 
(config)# line console 0 

(config-line)# login local
(config-line)# logging synchronous // I don't actually like this

// Make sure the login password is "encrypted"
(config)# service password-encryption

// Enable SSH (and disable evil Telnet)
(config)# crypto key generate rsa 
(config)# line vty 0 15
(config-line)# transport input ssh

(config-line)# login local

// Step 2: Interfaces (on the Router)
(config)# interface GigabitEthernet 0/1

(config-if)# ip address 10.0.0.1 255.0.0.0

(config-if)# ipv6 address 2001:db8:fade:1::1/64

(config-if)# ipv6 address fe80::1 link-local

(config-if)# description MyInterface

(config-if)# no shutdown

// Step 3: Management Interface (on the Switch)
(config)# interface Vlan 1

(config-if)# ip address 10.0.0.2 255.0.0.0

(config-if)# ipv6 address 2001:db8:fade:1::2/64

(config-if)# no shutdown

// Step 4: Configure DHCP on the router

(config)# ip dhcp excluded-address 10.0.0.1

(config)# ip dhcp excluded-address 10.0.0.2

(config)# ip dhcp pool mynet

(dhcp-config)# default-router 10.0.0.1

(dhcp-config)# dns-server 8.8.8.8

(dhcp-config)# network 10.0.0.0 255.0.0.0

// Step 5: Make it stick

# copy running-config startup-config

# reload

Can you spot the differences?

Of course you never go into production on revision A. Lesson learned: Never use autosensing level shifters for transmission applications. They just don't have enough drive strength for a long wire. They have a very counterintuitive property when they're driving a load that's too big: they go into oscillation. When the driver cannot bring the output level above threshold before the one-shot timeout it will switch directions. Then it will try to overwhelm the driver on the Teensy (it can't) and switch directions again. Repeat.

I also had to pick different capacitors for C1 and C5. The ones I had were to big to fit into the tube. The new ones have smaller values and less voltage margin. I really hope I get away with that.

There's one more thing different. Can you spot it?

New Candle Controller

Of course, as soon as you find a use for a board you figure out what's wrong with it. The candle controller is going to be used on my Burning Man project this year but needs to fit into a smaller tube. So a quick re-layout and ta-da. The narrow board. I never tested XBee on the first candle. I really hope it works.