Wednesday, June 5, 2013

Preventing git merge requests when making a git pull

Don't you hate when it happens? You do a git pull and then suddenly you are smacked with this message:

 $ Merge branch 'your-branch' into your-branch  

And it's a commit. It's laying in your history, testifying to some inscrutable mistake you made. "Why am I merging my own branch into the same dang branch?" you ask yourself in bewilderment.

Worse yet, if you do a push, it lives in your branch history forever!


It's actually a pretty simple problem. Basically, the local version of the branch you're working on has diverged from the remote version. You're merging the remote version of your branch in with the local version.

The fix is easy.

  git pull --rebase

What does this do? It rebases the remote branch against your local version. This means it will take your changes and put them aside, then apply all of the remote changes before finally attempting to apply your changes on top. In other words it makes your branch up-to-date before applying your changes.

Do you get file conflicts? No worries! That's expected if you're working on the same files. Simply open up each conflicted file and make the necessary adjustments.

Tuesday, June 4, 2013

Use your raspberry Pi as a DNS cache to speed up your internet

I want my internet to go faster

Here's something you can do with your raspberry pi that will make your internet experience faster.

Set up your raspberry pi to cache DNS queries so that they can be answered locally in a fraction of time and ditch your slow ISP domain name server.

If you'd rather not read the windy explanation of what this is or how this works, you can skip all the way down to the bottom for the script example, or simply run:

$ curl "https://raw.github.com/stephen-mw/raspberrypi/master/roles/dnsmasq_server" | sudo sh

But never run a command like that without first checking the source file.

A little background on DNS

When you type in "www.heystephenwood.com" into your browser and hit enter, there's a little transaction that goes on under the hood. In order to visit the website, your machine must translate the alphanumeric website name into a series of numbers called an IP address. It accomplishes this by sending the query to a domain name server.

The whole trip can take anywhere between 1 ms to 250 ms or more depending on your connection. This happens every time you visit a url (depending on your browser).

You can test it yourself using the tool dig.

  $ dig heystephenwood.com   
  ; <<>> DiG 9.7.6-P1 <<>> heystephenwood.com   
  ;; global options: +cmd   
  ;; Got answer:   
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42972   
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0   
  ;; QUESTION SECTION:   
  ;heystephenwood.com. IN A   
  ;; ANSWER SECTION:   
  heystephenwood.com. 14359 IN A 64.90.54.29   
  heystephenwood.com. 14359 IN A 216.239.38.21   
  heystephenwood.com. 14359 IN A 216.239.36.21   
  heystephenwood.com. 14359 IN A 216.239.34.21   
  heystephenwood.com. 14359 IN A 216.239.32.21   
  ;; Query time: 130 msec   
  ;; SERVER: 192.168.0.1#53(192.168.0.1)   
  ;; WHEN: Sun Feb 10 22:09:26 2013   
  ;; MSG SIZE rcvd: 116  

Dig is a very powerful and fun tool. Here you'll see the question and answer. The important part is right in the middle:

  ;; Query time: 130 msec   

That query took 130 ms. That means from the time I hit "enter" on my browser to the point where I was actually able to fetch and display a webpage there was a 120 ms pause while I waited to get the server's address. Those little pauses add up!

We're going to make our internet experience faster by storing these records in memory on our own DNS cache so that they can be fetched nearly instantaneously. The best part of this is that the cache is shared for all users, so the more people you have browser the web at your house the bigger and better the cache.

Introducing dnsmasq

Dnsasq is a very lightweight dns and dhcpd server. The benefit of dnsmasq is that it's fast, very easy to use, and offers the ability to use both dns and dhcpd services under one roof. The raspberry pi makes for a perfect vessel for a DNS server because of its low power consumption and easy setup.

Testing DNS query times

These next steps are optional but make the transition to your own raspberry pi dns server more more fun. We'll run the loop below to get a good working baseline for our DNS speed. You can run this from your raspberry pi or from a linux or mac osx box.

In this example I'm using the default Comcast public DNS server which they supply. Here's a bash loop without any averages:

 $ for i in {1..30}; do dig heystephenwood.com | grep time; done   
  ;; Query time: 159 msec   
  ;; Query time: 17 msec   
  ;; Query time: 23 msec   
  ;; Query time: 18 msec   
  ;; Query time: 156 msec   
  ;; Query time: 93 msec   
  ...  
  ... 

Doing it serially can take awhile, so let's pipe the whole thing into xargs and run it in parallel of sets of 10:

$ for i in {1..30}; do echo heystephenwood.com;done | xargs -I^ -P10 dig ^ | grep time 

Let's average them and get a baseline, because what's the point in trying to optimize a system if we can't actually see if it's improved? We're going to run the same command but we'll pipe it to awk to sum the columns for us to grab our mean.

  $ for i in {1..30}; do echo heystephenwood.com; done | xargs -I^ -P10 dig ^ | grep time | awk /time/'{sum+=$4} END { print "Average query = ",sum/NR,"ms"}'   
  Average query = 41.3 ms  

Let's take a look at just how far our packets need to travel to our DNS server:

$ traceroute 75.75.75.75   
  traceroute to 75.75.75.75 (75.75.75.75), 64 hops max, 52 byte packets   
  1 192.168.0.1 (192.168.0.1) 2.989 ms 0.927 ms 0.982 ms   
  2 73.97.112.1 (73.97.112.1) 10.238 ms 8.582 ms 10.133 ms   
  3 te-0-0-0-7-ur08.seattle.wa.seattle.comcast.net (68.87.207.89) 14.287 ms 19.168 ms 10.108 ms   
  4 ae-20-0-ar03.seattle.wa.seattle.comcast.net (69.139.164.129) 24.351 ms 12.557 ms 14.335 ms   
  5 he-1-6-0-0-10-cr01.seattle.wa.ibone.comcast.net (68.86.94.69) 15.803 ms   
   he-1-8-0-0-11-cr01.seattle.wa.ibone.comcast.net (68.86.95.249) 15.441 ms 23.240 ms   
  6 so-6-1-0-0-ar03.troutdale.or.bverton.comcast.net (68.86.90.214) 14.503 ms 16.077 ms 14.468 ms   
  7 te-7-4-ur01-d.beaverton.or.bverton.comcast.net (68.87.216.41) 15.748 ms 17.018 ms 18.251 ms   
  8 cdns01.comcast.net (75.75.75.75) 15.407 ms 23.341 ms 14.946 ms   

In this case it's 8 hops. Generally speaking, the less hops a packet needs to travel to a destination the better. By using a cache, we'll only need to make this trip once, then we'll store the record for quick retrieval.

Let's talk cache

Installing dnsmasq is easy on your raspberry pi:

 $ sudo apt-get install -y dnsmasq  

Stop the service so that we can tinker with its configurations

 $ sudo service dnsmasq stop   

Let's open the conf file and get the settings we want. For reference I've included my own configuration.

You'll find the configuration at /etc/dnsmasq.conf if you installed from the repo.


# Dnsmasq.conf for raspberry pi
# /etc/dnsmasq.conf
# http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq.conf.example

# Set up your local domain here
domain=raspberry.local
resolv-file=/etc/resolv.dnsmasq
min-port=4096
server=8.8.8.8
server=8.8.4.4

# Max cache size dnsmasq can give us, and we want all of it!
cache-size=10000

# Below are settings for dhcp. Comment them out if you dont want
# dnsmasq to serve up dhcpd requests.
# dhcp-range=192.168.0.100,192.168.0.149,255.255.255.0,1440m
# dhcp-option=3,192.168.0.1
# dhcp-authoritative

The "server=" setting is declaring the upstream domain name servers. dnsmasq never actually looks at root hints to resolve an ip address. If it doesn't know the answer, it just asks a different dns (in this case it's google).

I've included the settings for having dnsmasq be the dhcp server as well. This is optional, but it gives you a few extra perks: the dnsmasq dns will be the default, and you can control the lease space.

Note: these settings assume that 192.160.0.1 is your default gateway. If it's not, you'll need to adjust the settings to reflect it.

Don't forget to start the service again

 $ service dnsmasq start  

Test your new dns cache

Let's run that same command earlier. Once the record is retrieved, dnsmasq will store the record locally.

 $ for i in {1..30}; do dig heystephenwood.com | grep time; sleep 1; done | awk /time/'{sum+=$4} END { print "Average query = ",sum/NR,"ms"}'  
 Average query = 2.33333 ms  

From 41 ms down to 2.3? I'll take that!

Set up your computer to use your new DNS server

This part can be accomplished a few different ways. For mac, you can see this guide, or for windows you can see here. I recommend you use your raspberry pi as a dhcp server as well, that way every device on your network will use your fancy new dns server by default.

Script the bootstrap

Anytime you need to do something on your linux server, you should get into two habits: 1) distilling your creation into scripts that can be called over and over again, and 2) storing those configurations in source control.

Let's bootstrap the whole gosh darn thing with a single bash script.

You can call the script simply enough right from your raspberry pi

$ curl "https://raw.github.com/stephen-w/raspberrypi/master/roles/dnsmasq_server" 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
#!/bin/bash
set -e

# Raspberry Pi dnsmasq script
# Stephen Wood
# www.heystephenwood.com
#
# Usage: $ sudo ./raspberrypi_dnsmasq
#
# Net install:
#   $ curl https://raw.github.com/stephen-mw/raspberrypi/master/roles/dnsmasq_server | sudo sh

# Must be run as root
if [[ `whoami` != "root" ]]
then
  echo "This install must be run as root or with sudo."
  exit
fi

apt-get install -y dnsmasq
cat - > /etc/dnsmasq.conf <<DNSMASQCONF
# Dnsmasq.conf for raspberry pi
# By Stephen Wood heystephenwood.com
# Full examples found here:
# http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq.conf.example

# Set up your local domain here
domain=raspberry.local
resolv-file=/etc/resolv.dnsmasq
min-port=4096
server=8.8.8.8
server=8.8.4.4

# Max cache size dnsmasq can give us, and we want all of it!
cache-size=10000

# Below are settings for dhcp. Comment them out if you dont want
# dnsmasq to serve up dhcpd requests.
# dhcp-range=192.168.0.100,192.168.0.149,255.255.255.0,1440m
# dhcp-option=3,192.168.0.1
# dhcp-authoritative

DNSMASQCONF

service dnsmasq restart

echo "Testing dns performance with random urls"

# We'll generate a list of urls that we're moderately certain doesn't exist in our cache to get a good base line for speed increases.
URLS=`for i in {1..50}; do echo www.$RANDOM.com;done`

# Make the requests in parallel
echo $URLS | xargs -I^ -P50 dig @127.0.0.1 grep time | awk /time/'{sum+=$4} END { print "average response = ", sum/NR,"ms"}'
echo $URLS | xargs -I^ -P50 dig @127.0.0.1 grep time | awk /time/'{sum+=$4} END { print "average response = ", sum/NR,"ms"}'
echo $URLS | xargs -I^ -P50 dig @127.0.0.1 grep time | awk /time/'{sum+=$4} END { print "average response = ", sum/NR,"ms"}'

echo 'Installation complete. Enjoy!'







Sunday, May 26, 2013

varnish and varnishncsa init (upstart) script

Here is a simple upstart script for the varnish and varnishncsa daemon. As of 3.0.3 upstart scripts aren't included in the standard debian package.

Nothing too fancy here. I'm going to be referencing these upstart scripts when I talk about plugging in logstash to varnishnicsa in another post. The real beauty is you get to hook varnishncsa into starting and stopping with varnish starts and stops.

varnish init (upstart) script:

# varnish - HTTP accelerator   
#   
     
description  "load balancer for Python api workers"   
     
start on (local-filesystems   
   and net-device-up IFACE!=lo)   
stop on runlevel[!2345]   
     
respawn   
     
# These are from the default init.d script   
limit nofile 131072 131072   
limit memlock 82000 82000   
     
exec "/usr/sbin/varnishd -F -a :80 -T localhost:6082 \   
   -f /etc/varnish/default.vcl -S /etc/varnish/secret \   
   -u varnish -g varnish -s malloc,256m" 

varnishncsa init (upstart) script:

# varnishncsa - Logging daemon for varnish  
#  
   
description   "logging daemon for varnish"  
   
env LOG_OPTIONS='%h %l %u %t "%r" %s %b %{Varnish:time_firstbyte}x %{Varnish:handling}x'  
start on started varnish  
stop on stopped varnish  
   
respawn  
   
exec /usr/bin/varnishncsa -a -F "$LOG_OPTIONS" -w /var/log/varnish/varnishncsa.log  

Remember that when you replace the init.d script with the upstart version you effectively deprecate the settings in /etc/defaults/varnish*, so you'll need to incorporate any of those configuration settings into these scripts.

You can test these settings by running:

 $ service varnish start  
   varnish start/running, process 13562  

And behold! It started both varnish and the varnishncsa logging daemon:

$ ps aux | grep varnish   
  root  13617 8.0 2.0 117236 84684 ?  SLs 19:13 0:00 /usr/sbin/varnishd -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -u varnish -g varnish -s malloc,256m   
  root  13618 0.0 0.0 93840 684 ?  Ss 19:13 0:00 /usr/bin/varnishncsa -a -F %h %l %u %t "%r" %s %b %{Varnish:time_firstbyte}x %{Varnish:handling}x -w /var/log/varnish/varnishncsa.log   
  varnish 13628 0.0 0.0 270936 1400 ?  Sl 19:13 0:00 /usr/sbin/varnishd -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -u varnish -g varnish -s malloc,256m  
   

If it looks funny to you that there are 2 varnishd programs running, don't forget that varnish intentionally spawns a child.

I hope that helps.

Monday, May 20, 2013

Installing Raspberry Pi on SD card on mac or linux

If you're on mac or linux, installing the raspberry pi operating system on a sd card is quick and easy. Here's the instructions for doing it using the tool dd.

Warning: with one wrong typo you can wipe out your entire hard drive with the command dd. Be very careful with the dd step that you're pointing it at your sd card.

We'll be doing this all in the terminal. Open up your terminal by typing "command + space" then typing in terminal if you're on a mac. If you're using ubuntu it's "ctrl + t".

Download the newest raspberry pi image and unzip it

 $ cd ~/Downloads   
 $ wget http://files.velocix.com/c1410/images/raspbian/2013-02-09-wheezy-raspbian/2013-02-09-wheezy-raspbian.zip .   
 $ unzip 2013-02-09-wheezy-raspbian.zip  

Find out what the device name is, and then unmount it. Ignore the "s1" part after the device name if you're on a mac. In this case it's "/dev/disk1".

  $ df -lh    
   Filesystem Size Used Avail Capacity iused ifree %iused Mounted on    
   /dev/disk0s2 233Gi 97Gi 135Gi 42% 25586022 35483418 42% /    
   /dev/disk1s1 56Mi 19Mi 37Mi 34% 512 0 100% /Volumes/Untitled    
  $ diskutil umount /Volumes/Untitled   

Send the data using the dd command.

WARNING: Be very careful with this step. The "of=" MUST be the device name for the sd card. Measure twice and cut once. There's a reason sysadmins sometimes refer to dd as "disk destroyer."

$ sudo dd if=2013-02-09-wheezy-raspbian.img of=/dev/disk1 bs=1  

You can check the progressing by sending a "SIGINFO" (ctrl + t):

load: 0.85 cmd: dd 24671 uninterruptible 31.47u 174.72s    
  112168961+0 records in    
  112168960+0 records out    
  112168960 bytes transferred in 410.701456 secs (273116 bytes/sec)

That's it! You're done. 

Thursday, December 27, 2012

Raspberry Pi as an SSH Tunnel Gateway

The Raspberry Pi is a neat little Linux box that costs $25 and is the size of a credit card. I've been tinkering with mine for about a month now. I know a few people who bought them and are wondering what they can do with it, so I'm going to do a series called "10 slices of Pi"

In this first post, I'm going to show you how to set up your Raspberry Pi to tunnel SSH traffic through your home network. This will help you browse privately and securely from behind firewalls and public wireless hotspot.


Why tunnel SSH traffic?

There are a few good reasons you may want to tunnel your web traffic through your home.

By tunneling your traffic through SSH, it is encrypted to any prying eyes that may be hoping to sniff passwords and sensitive information on a public wireless hotspot. 

Encrypting your traffic defeats website-blocking firewalls at your school, work, or oppressive country.


Requirements

  1. An "always-on" SSH server on a trusted network (like your home). This is what the raspberry pi will become.
  2. An SSH client on the computer or laptop you wish to do the tunneling (mac has a native ssh application, and for windows you can use PuTTY.
  3. Firewall rules that allow you to access your open-ssh server from the outside.
  4. A browser that supports SOCKS proxies.


Setting up the Raspberry Pi

Fortunately, there's very little setup we'll actually do on the RPI. Most of what will take place will happen on your router or laptop. The first thing we'll need to do is make sure that your openssh-server is running and accepting connections.

If you're logged into your RPI, simply check if openssh is listening on port 22



$ nc localhost 22
SSH-2.0-OpenSSH_6.0p1 Debian-3

Looks like it is! If it wasn't listening, netcat would simply hang up on you. 
If openssh isn't listening, you can run the config again to enable the server.
 sudo dpkg-reconfigure


Give the Raspberry Pi a static IP

Before you go on to the port forwarding step, you'll want to take a moment to give your RPI a static IP on the network. Since it's a regular linux computer the steps are the same. 

$ sudo vi /etc/network/interfaces
    auto eth0
    iface eth0 inet static
        address 192.168.1.3
        netmask 255.255.255.0
        gateway 192.168.1.1
$ ifdown eth0$ ifup eth0


Granting Access To Port 22

The next step is to make sure you can access your raspberry pi from the outside world. This is where it gets tricky. Most everyone has their computers protected from the outside world via the firewall on their router, but we need a way to snake our way through the firewall and onto our RPI. For purposes like this, routers come with a feature called "port forwarding" which allows you to route specific traffic to a particular host.


Settings on your router

To log into your router, typically you type in 192.168.1.1 or 192.168.0.1 into your browser window. You'll find port forwarding usually around access control. 

Since port 22 is a privileged port and is frequently scanned. I'm going to pick a random and unprivileged port (those above port number 1024).


In this example, we're forward external port 7000 from the outside to internal port 22 on the RPI server. 


This means when you connect to your router on port 7000, it will send that traffic to your rpi on port 22. You'll need to forward it to your raspberry pi internal network address. 

Here's what my home network settings look like:




Put in your appropriate settings and restart your router. Now it's time to test if it's listening properly to the outside world. You can use the port forwarding tester over at yougetsignal.com


Setting up your SOCKS proxy

Now you need to connect to your RPI using your SSH client to establish a SOCKS proxy. 

Directions for doing that in Windows using PuTTY can be found here.

If you're on a mac you can look at my previous post here: How to SSH Tunnel on a Mac.


Setting up your browser

Our last step is to set up our browser to use the new SOCKS proxy for all web traffic. I usually keep a copy of portable firefox just for this. You can even stash firefox and portable PuTTY on a flash drive and carry it around with you.

In Firefox, you can adjust the settings by doing the following:
  1. Go to preferences, and select the "Advanced" tab.
  2. Select "Network" button and choose "Settings"
  3. Select "Manual proxy configuration" and under "SOCKS Host", you're going to put your local loopback address (127.0.0.1) and the port you selected when you opened up the proxy 
You are now relaying your internet traffic through your raspberry pi as a proxy. 


Caveats

This will forward your web traffic (port 80, 443), but will not forward DNS queries (port 53). Your DNS server could be keeping a log, so your browsing isn't completely private. 

Tuesday, December 18, 2012

Macbook Pro Displayport Audio Out

I was unable to get digital audio out working with my macbook pro. The fix was simple but took some digging. It turns out out that my receiver didn't support the format that the mac osx outputted by default. It's pretty easy to test and change this if you're having trouble.

If you're having trouble getting audio to work with your displayport adapter, try this:

Open up the audio settings first and make sure that displayport is set as the audio out source.


Next open up Audio MIDI Setup and make sure that the format is something that your receiver can handle. I had to change the bitrate from 48 to 44 Hz. Play around with it.


Saturday, December 15, 2012

Bootstrap your Raspberry Pi with a Bash Script

I love my raspberry pi. I use it for fun projects. It's inexpensive, easy to use, and fun! Coincidentally, it also makes an easy dev environment for small projects.

I like to treat mine as a disposable test bed for different things I'm working on. I find myself doing repetitive configuration changes to the pi, so I've instead decided to script all the initial installation stuff.

Here's my setup script for all to use and enjoy. After my raspberry pi finishes it's general config screen, bootstrapping it is very easy (and interactive). If you have any comments, feel free to post them on Git or right here on the blog.

You can see the raw or full mode on github here.

If you'd like to run it and test it yourself, just run from root:

$ curl -q "https://raw.github.com/stephendotexe/raspberrypi/master/configuration/setup_pi_interactive" > ~/setup_pi_interactive 

(open up the file -- never run anything from the web as root without first looking it over)

$ ~/setup_pi_interactive


Let's break it down:

#!/bin/bash

# Interactive Raspberry Pi setup script
# Author: Stephen Wood (www.heystephenwood.com)

# Die on any errors
set -e 

if [[ `whoami` != "root" ]]
then
  echo "Script must be run as root."
  exit 1
fi

# Variables for the rest of the script
echo -n "Choose a hostname: "
read NEW_HOSTNAME
echo -n "User: "
read NEW_USER
echo -n "Password for user (leave blank for disabled): "
read PASS_PROMPT
echo -n "Paste public key (leave blank for disabled): "
read PUBLIC_KEY

I left this interactive for the sake of anyone else running the script. On my own personal version, I set this variables by hand and run it straight off, which is nice because you can do it in one line (curl "http://script" | bash), just make sure it's securely hosted locally if you are putting passwords in it.

apt-get -y update
apt-get -y upgrade

# Install some base packages
apt-get install -y --force-yes dnsutils g++ gcc ipython \
make ntp python python-pip vim vlc

Install whatever packages you want. I find this to be ones I like on every system.

# Update hostname
echo "$NEW_HOSTNAME" > /etc/hostname
sed -i 's/pi/$NEW_HOSTNAME/' /etc/hosts

# Set VIM as the default editor
update-alternatives --set editor /usr/bin/vim.basic

# Add user and authorized_keys
if [[ "$PASS_PROMPT" = "" ]]
then
  useradd -b /home --create-home -s /bin/bash -G sudo $NEW_USER
else
  useradd -b /home --create-home -s /bin/bash -G sudo $NEW_USER -p `echo "$PASS_PROMPT" | openssl passwd -1 -stdin` 
fi

Personally, I recommend you do SSH key-pairs for everything, but sometimes a password is just easier.

# Remove Pi user's password
passwd -d pi

The whole world knows the default password to this user, so disable the password or the user, your choice. I remove the password here. If you want to delete the user, you won't be able to do it with sudo on the first run.

if [[ "$PUBLIC_KEY" != "" ]]
then
  mkdir -p /home/$NEW_USER/.ssh/
  echo "$PUBLIC_KEY" > /home/$NEW_USER/.ssh/authorized_keys
fi
chown -R $NEW_USER:$NEW_USER /home/$NEW_USER

# Allow users in the sudo group to sudo without password
sed -i 's/%sudo.*/%sudo   ALL=NOPASSWD: ALL/g' /etc/sudoers

# Turn off password authentication 
sed -i 's/#   PasswordAuthentication yes/    PasswordAuthentication no/g' /etc/ssh/ssh_config

# Now for some memory tweaks!
# Remove unnecessary consoles
sed -ie 's|l4:4:wait:/etc/init.d/rc 4|#l4:4:wait:/etc/init.d/rc 4|g' /etc/inittab
sed -ie 's|l5:5:wait:/etc/init.d/rc 5|#l5:5:wait:/etc/init.d/rc 5|g' /etc/inittab
sed -ie 's|l6:6:wait:/etc/init.d/rc 6|#l6:6:wait:/etc/init.d/rc 6|g' /etc/inittab
# Also disable serial console
sed -ie 's|T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100|#T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100|g' /etc/inittab 

echo "Installation Complete. Some changes might require a reboot."

I got these tweaks from the blog Gordon @ Drogon.