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.

Six Degrees of Bacon!

This programming assignment, Six Degrees of  Bacon, by Steve Hodges has inspired me for the last two weeks. So on my first day off (yes, really) I have forgone food and a shower to make this homage.

The code is on GitHub: https://github.com/mike-matera/Six-Degrees

The Candle is Here!

It's Here

Setup

It's a fun day when you receive the first copy of a new circuit board. What did you forget to order? Are all the parts right? No. They never are. So here's what I missed:

1. Forgot to order my 3.3v regulators 
2. Forgot to order my 22k resistors
3. Ordered the level translator in the TSSOP instead of the SOIC package

There's a little silk screen error that's different between my gerbers and what the fab made. It cutoff the name of my website! Oh no. I'm getting everything ready for assembly. Now I just have to figure out how I'm going to use the wireless connectivity. 

Candle Controller

My prototype digital candle looked really good. The prototype used a separate power board wired to the Teensy3.0. That was cost effective but cost a lot of labor and delicate soldering to complete. This new board swallows the Teensy and incorporates the power supply. Better still it has a slot to swallow an XBee. That means this board will be able to communicate with the outside world. I'm not sure what I'm going to do with that just yet. I'll think of something.

Benchmarks

I got Cznic's code to work with very little trouble. I spent much more time thinking about how to make benchmark results comparable. The issues I considered are:

1. The trees must be of the same order (I used 128)
2. The trees must use the same key type (I used uint64)
3. The trees must be pre-filled with a large number of elements

Let me take a moment to explain #3. The benchmarking engine in Go works by calling your code with an iteration count. It times your code and then divides the time by the count to determine the number of nanoseconds per iteration. It starts with a small iteration count and increases the value until the sample is statistically valid. This has a poor property for comparing b-trees: The more elements in the tree the slower most operations will proceed. I can't control the iteration counts, instead I pre-filled the trees with 4 million elements. Why 4 million elements? Because inserting another million elements is not likely to change depth of the tree. 

The results of the benchmark:

BenchmarkRandomPut  200000      11836 ns/op
BenchmarkCznicRandomPut   1000000       1556 ns/op
BenchmarkRandomGet 5000000        652 ns/op
BenchmarkCznicRandomGet   2000000        797 ns/op
BenchmarkRandomDelete   200000      12581 ns/op
BenchmarkCznicRandomDelete 1000000 1228 ns/op

There's clearly a severe penalty for the Load() and Store() operations making my implementation an order of magnitude slower for operations that alter the tree. The good news is that my fetch implementation is somewhat faster. Since the expected mix of operations on a b-tree heavily favors lookups I believe that this offsets my poor update performance somewhat. 

How do I know that Load() and Store() eat up a lot of time? Go has a built-in profiling tool. Here's how it works. First you add some profiling code to a test harness. This is what I did:

file, _ := os.Create("insertions.out")

pprof.StartCPUProfile(file)

for i:=0; i<5000000; i++ {

tree.Put(uint64(src.Int63()), i)

}

pprof.StopCPUProfile()

You can then open your profile result (insertions.out) like this:

$ go tool pprof bin/main insertions.out

Welcome to pprof!  For help, type 'help'.

(pprof) 

In this case "bin/main" is the name of my executable. Much more information on how to use Go's pprof can be found here. The first command you're likely to use is the "top" command which shows you your top 10 CPU users. 

(pprof) top

Total: 5291 samples

    1289  24.4%  24.4%     2563  48.4% github.com/mike-matera/Go/btree.(*SimpleNode).Store

    1069  20.2%  44.6%     1069  20.2% github.com/mike-matera/Go/btree.(*SimpleNode).Load

     272   5.1%  49.7%      285   5.4% github.com/mike-matera/Go/btree.(*SimpleNode).Find

     240   4.5%  54.2%      809  15.3% runtime.assertE2T

     233   4.4%  58.6%      233   4.4% runtime.memcopy64

     209   4.0%  62.6%      584  11.0% assertE2Tret

     200   3.8%  66.4%      433   8.2% copyout

     196   3.7%  70.1%      344   6.5% sweepspan

     195   3.7%  73.8%      195   3.7% flushptrbuf

     141   2.7%  76.4%      344   6.5% scanblock

You can see that the top CPU hogs were Store() and Load(). The right most percentage is the percent of samples where those functions were on the call stack. A whopping 68.6% of the time. The 'web' command creates a nice SVG image of the result. Below are the results of the loop above and a similar one that fetches values.

Insertions Profile

Fetches Profile