Getting Started with Itty - The Very Small Erlang Webserver

_Itty is a tiny webserver, written in Erlang, for the purposes of learning Erlang. _

The code is not very pretty, but it is an attempt to learning how a webserver works while teaching myself Erlang.  My hope is to someday have a somewhat complete (robust, all the expected features, minimal bugs, and concise) version of itty to use as a tool to teach others Erlang.  As itty is improved and debugged I hope to publish more articles highlighting the challenges encountered and the techniques used to help others learn along the way.

Currently, itty will serve several types of files (see src/mime.erl) from a static directory.  In the near future I hope to add directory browsing as well as simple, dynamic templates.  Itty was mainly developed on Ubuntu Linux, I hope to add/verify other Linux platforms as well as Windows.

What you will need

Installing

  • Clone from github.com

    • “git clone git://github.com/zpeters/itty.git”

    • Current as of writing is tree: __ 7eff8d8

  • Edit ‘application.cfg”

  • Set the port (above 1024 if you aren’t running as root)

  • Set the “docroot”, absolute path with no trailing slash

  • Set the “http_logfile” and “event_logfile”

  • Make sure ‘index.html’ exists in your docroot (itty doesn’t do directory browsing yet)

  • “make run”

Tada

If all is well (and debugging is on) you will see a quick display of the current config and should be able to see the webserver on the appropriate port

That’s about it.

For now development continues (you can see my todo list in Readme.org).  If you enjoy Erlang, whether your a seasoned professional or just learning as a hobby, I greatly welcome your feedback.  If you wish to contribute to itty itself  patches can be emailed to me directly, or you can send me a pull-request on github.

Thank you.

Using Git as a "Poor Man's" Time Machine - Part Two

Audience: _waits patiently between blog posts, enjoys highly contrived scenarios involving time travel _

In our last installment we saw how to setup a git-repo-come-poorman’s-timemachine. We went through the basics of initializing our git repo and adding or initial list of files and folders track. In this installment we will be exploring how to use our setup to recover from typical day-to-day disasters, putting you on the road to be a time-traveling-IT-superstar.

By now you should have several days worth of new and changed files recorded into your repository, ermmm “time machine”. Its time to run through some common scenarios where our system will start to show its usefulness.

Just so everyone is on the same page

we are going to setup a sandbox environment for trying out our commands. It isn’t because I don’t trust you. I know you have been dutifully watching your automated git system recording change after change - doggedly clicking refresh on thehelpfulhacker.net until the day our lesson would continue. It’s just that those other guys, well, it’s best to give them a clear, concise example they can follow step by step. I know you will wield your awesome time-bending powers for good, but lets just make sure these guys are on the level.

Let’s setup our sandbox

Setup the directory we are working in:

$ mkdir SuperImportantStuff
$ cd SuperImportantStuff

Initialize the git repo

$ git init
Initialized empty Git repository in /home/zach/tmp/SuperImportantStuff/.git/
$ git status
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)

Add some content (adding “.” is shorthand for “just add everything new”):

$ echo "Foobar" > a.txt
$ echo "Moobar" > b.txt
$ echo "Foobaz" > c.txt
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#    a.txt
#    b.txt
#    c.txt
nothing added to commit but untracked files present (use "git add" to track)
$ git add .

Commit our changes ( “-m ‘My message here’” saves us from the laborious task of specifying the message at the end of our commit):

$ git commit -m "Added files"
[master (root-commit) 3398f4a] Added files
3 files changed, 3 insertions(+), 0 deletions(-)
create mode 100644 a.txt
create mode 100644 b.txt
create mode 100644 c.txt

Now we will modify some content and add a new file ( “-am ‘My message here’” saves us from the laborious task of “adding all files” then specifying the message at the end of our commit)

$ echo "This is something completely different" >> c.txt
$ echo "Foobaz" > d.txt
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#    modified:   c.txt
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#    d.txt
no changes added to commit (use "git add" and/or "git commit -a")
$ git commit -am "Added more stuffs"
[master 73ab7b3] Added more stuffs
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 d.txt

And again

$ echo "Blah blah blah" > a.txt
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#    modified:   a.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git commit -am "Updated a.txt"
[master 892c425] Updated a.txt
1 files changed, 1 insertions(+), 1 deletions(-)

Checking Our Recent Activity

Oh man this is so so so easy since you are a git-fu ninja now.  But in case you can’t guess the command is “git log”.  Yep that’s it.  Save the dramatic drum-roll for configuring sendmail m4 macros, because this is cake.

git log
commit 8ee6fbbefecceab8325fba276b8654484af207f6
Author: Zach Peters
Date:   Mon Jul 12 19:47:59 2010 -0500

    Updated a.txt

commit 52c12c93e5202d49a5e6873cfb6f0e0bb69ea78d
Author: Zach Peters
Date:   Mon Jul 12 19:44:25 2010 -0500

    Added more stuffs

commit 0d393786c2e57996f2a0c780733d5f712c3f01c2
Author: Zach Peters
Date:   Mon Jul 12 19:43:59 2010 -0500

    Added files

Please explore the various formatting options with git log --help

But wait

you say, it’s all fine and well to see a log of fancy-pants comments for each commit, but what happens, what truly happens if we are automating this. Every day will contain an entry like Update for 2010-07-04. Isn’t that kinda useless?

The honest answer is “yes”. So, what do you do when you really just want to know what changed since the last commit. Enter the aptly named git whatchanged. Predictably, it will show you what changed.

git whatchanged
commit 8ee6fbbefecceab8325fba276b8654484af207f6
Author: Zach Peters
Date:   Mon Jul 12 19:47:59 2010 -0500

    Updated a.txt

:100644 100644 d0e3340... 0b623c3... M	a.txt

commit 52c12c93e5202d49a5e6873cfb6f0e0bb69ea78d
Author: Zach Peters
Date:   Mon Jul 12 19:44:25 2010 -0500

    Added more stuffs

:100644 100644 7ae6e84... 6331f52... M	c.txt
:000000 100644 0000000... 7ae6e84... A	d.txt

commit 0d393786c2e57996f2a0c780733d5f712c3f01c2
Author: Zach Peters
Date:   Mon Jul 12 19:43:59 2010 -0500

    Added files

:000000 100644 0000000... d0e3340... A	a.txt
:000000 100644 0000000... 9e5d442... A	b.txt
:000000 100644 0000000... 7ae6e84... A	c.txt
[SuperImportantStuff|master]%

So whats next?

Now that we have mastered adding and commit files we will soon be taking a look at what we technical folk call “do over”.  Specifically, we will be taking a look at seeing what changed in a files contents, reverting to previous versions of a file and where we can go from there.

A Small List of Best Practices for Sysadmins and Programmers

I present you with my small list of best practices that I have used in the past as reference material and guidelines for work I have done.  I hope that by sharing this it will inspire you to share your favorites, or even create your own best practices documents to help move the practice of system administration and programming forward.

Programming

Web

  • Yahoo! has created a great checklist for speeding up your website.  The think I enjoy about this guide is that they are practical examples along with why you want to do it. If you like this, please check out their automated tool YSlow.

DNS

  • Monkey House has a nice Top 10 DNS best practices.  While, I’m not sure of this are truly the top ten most common slip ups or the top ten most important things to consider, it is a well-rounded look at some things you should consider when setting up or maintaining DNS

  • Again, not so much a list of best practices, but Cisco offers a great overview/refresher to dns as well as a detailed list for detecting and preventing dns abuse of Cisco products

  • ComputerWorld presents a decent, high-level overview of best practices for reliable dns and dhcp.  Referenced in the article is CERT’s  Securing an Internet Name Server.  Some of the techniques in this paper were specific to certain versions of BIND, but the theory can be applied elsewhere

Active Directory

Infosec

Thanks for reading.  I look forward to hearing what your best practices are.  Are they hard-won lessons learned on the job?  Industry standards?  Personal preferences?