Gol10dr's Crease

This past week my Zoom cable modem was dropping my connection a lot due to the increased speeds that Cox was delivering in my Premium Internet package. The current service should deliver around 25Mpbs down and about 15Mbps up but I was not seeing anywhere near that.  I had the Cox technician come out to adjust some of the connections inside and outside the house and he recommended using a Docsis 3.0 compliant cable modem.  I did some research and found the Motorola Surfboard SBG-6580 which has a DOCSis 3.0 cabel modem coupled with a dual Wireless N router that can have both a internal and guest wireless broadcast.

Inside the house I have the first generation N Wirelless Apple Airport Extreme which has been functioning as my router for the past 3 or so years.  First I read a couple of posts on just disabling NAT on the Surfboard and keeping my router configuration on the Aiport the same.  This worked alright but was prone to losing connectivity since there is really no way to completely disable the router portion of the Surfboard. This resulted in both devices being disconnected and then the Surfboard being put back online followed by the Airport.  

To avoid this issue, I opted to do the following:

1. Use the Motorola router's NAT (aquiring the public IP from the ISP)
2. Setup the Airport to hand out a series of addresses on the same submet (10.0.x.10 - 25)

Below are the setup screens for the settings in both the Surfboard and Airport:

(download)

Click here to download:

motorola-surfboard-sb6580-playing-nice-with-apple-s-airport-extreme-vADjJEFsIFsIysyqnqod.zip (319 KB)

Once the Surfboard's modem connects, it will establish that verified handshake with your ISP, then the router gets the public address and distributes an address to the Airport.  The airport is given a specific range of address which get marked STATIC on the Surfboard and all your devices are now talking to the Airport without any disruption.  This has been bomber even if the power goes out and the system comes back up.  Below are my connection stats:

On June 15, 2011 Google's official Chrome operating system was finally released and hit the market on a couple of models by Samsung and Acer.  ChromeOS is a lightweight operating system built on a striped down version of Linux to run the Chrome browser.

Since I live on Google and our company is also on Google Apps, I wanted to see how feasable it was to function on a device so forward thinking.  Obviously this is not a replacement device for a superuser or someone who has specific needs like running SolidWorks or doing long form video editing.  What it does offer is a sleak device that boots in 8 seconds, (6 to the login screen) from the off state and gets you on the Internet to do what we all do there, browse, research, email, socialize, share...and the list goes on and on.

With so many companies attempting to move today's desktop applications like video editing, engineering tools like CAD and other CAE applications,  even going as far as hosting full sofware developement environments to offload the resources need by the user. 

Personally I have been interested in this for a couple years and had purchased a eee701 on Amazon for about $140 USD and installed ChromiumOS, the open source project of Google's ChromeOS, in order to get a feel for how this could be.  The early days were rough, as many open source tools are at first, but I have to say Google has really moved this product forward and it is a pretty good V1 product.  Don't get me wrong, there is still room for improvement but instead of focusing on what an internet browser only operating system can't do, focus on what it can.  

So over the next month or so I am going to put the 11" Acer Chromebook to the test and see how it stacks up to other secondary computing devices like tablets and smartphones. So far the only major issues I have run into would be:

• GoToMeeting is not supported
• Skype is not yet supported for the full experience
• VPN for Cisco (although the current build does support L2TP/IPSEC (with shared key or user cert)

Enabling SSL on Apache2 is actually pretty easy and out of the box will enable self-signed certificates.  This will suffice for testing but if your goal is to lock down sensitive information and be trusted by users, getting an SSL certificate for your domain will be key.  When I setup my FedOne server about a year ago, I had to go through getting certificates for federation to work with the Google's Sandbox.

Enable SSL in Apache2:

I am assuming you already have Apache2 installed and own a domain name with postmaster/webmaster access.  Here are the steps to get the SSL module of Apache2 running:

1 - Enable ssl:

$: a2enmod ssl

Out of the box this will use self-signed certiicates which will light up most broswers with a red "This site's security certificate is not trusted!".  The self-signed certificates are great for testing especially since Ubuntu 10.04 which contains it's own SSL conf file. 

2 -  Once the SSL is enabled, restart Apache:

$: sudo /etc/init.d/apache2 restart

Now that SSL is enabled and https://yourdomain.com is using the self signed certs, we need to generate a certificate request file and a private key from our server and use a 3rd party signer to get our certificate.  

Generate CSR and Server Key:

1 - I used the same script to generate both the private key and certificate request.

$: sudo nano make-csr.sh

2 - Enter the following code:

#!/bin/bash

NAME=$1

if [ "$NAME" == '' ]

then

echo "$0 " 1>&2

  exit 1

fi

openssl genrsa 2048 | openssl pkcs8 -topk8 -nocrypt -out $NAME.key

openssl req -new -nodes -sha1 -days 365 -key $NAME.key -out $NAME.csr

3 - Make the script executible:

er$: sudo chmod a+x make-csr.sh

3 - Run the script, adding the name you want on the end.  I choose "server":

$: sudo ./make-csr.sh server

This generated two files:

server.key
server.csr 

Validate Domain with StartSSL:

I choose StartSSL since I used them during my FedOne setup and it was rather easy and free to boot.  Here are the steps:

1 - Go to http://www.startssl.com and create an account.  You will need to have a registered domain and access to the postmaster or webmaster of the domain in order to establish a certified connection.

2 - Click on "Sign-up" to begin the registration process.  This will have you fill out some information and will have you verify with an email.  Once verified a certificate will be installed in your browser (doesn't work on Chrome in my tests).

3 - Click on "Validations Wizard" and select "Domain Name Validation" (Continue)

4 - Type in your domain name (Continue).  An email verification will be sent and you will paste in the validation code to get your domain validated.

Request Certificate from StartSSL:

1 - Click on "Certificates Wizard" and for Certificate Target select "Web Server SSL/TLS Certificate (Continue)

2 - Click on Skip since we are going to use our own CSR from the above step (Skip)

3 - Copy the contents of the "server.csr" generated above by typing:

$: cat server.csr

* Make sure the contents of the certificate request includes the header and footers of the CSR with all the dashes! (Continue)

4 - The screen will appear with the contents of the newly generated SSL certificate.  Copy the contents and add it to a new file called "server.crt" on the server.

$: sudo nano server.crt

Configure Apache2 to use Signed Certificates:

I decided to create a directory to place my certificates in the Apache2 directory. You can place them anywhere you like.

1 - Make a directory in Apache2

$: sudo mkdir /etc/apache2/ssl

2 - Copy the certificate (server.csr) and private key (server.key) to the new directory

$: sudo cp server.crt /etc/apache2/ssl
$: sudo cp server.key /etc/apache2/ssl

3 - Point Apache to use your new files in the default-ssl file:

$: sudo nano /etc/apache2/sites-available/default-ssl

Make sure the SSL Engine is on and the proper paths are reflected:

SSLEngine On
SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key

4 - Restart Apache

$: sudo /etc/init.d/apache2 restart

Once restarted, Apache will now sign with your new certificates and users will see the green "https" in their browser bar.  Depending on what setup you require, you may need to still set your document root for your website and do a mod-rewrite in your .htaccess file to forward all your http traffic to https.

In my case, I was running my StatusNet instance with mixed mode SSL, protecting only sensitive pages since Meteor doesn't post via https yet without an unsupported proxy setup. ~Lou

Back about a year ago, I went through the rigors of getting a FedOne Wave server installed.  Although the Wave Protocol had been released at Google I/O in May 2009, there was not much excitement without being able to federate with the development sandbox.  The other issue was nobody had access till the preview lauched, except in the sandbox, and all the invite hell that followed.

Once Google opened up federation on wavesandbox.com many of us started trying to run our own servers so we could test out this cool new federation protocol.  Most of the setup was pretty easy but certificates, which are required for federation with Google's Wave Sandbox, can be quite the ordeal to get working properly.  Without completely re-outlining every step, I thought I would outline my setup since I recently moved my wave setup to another server and had to walk thought the steps again, refreshing my memory.

Server OS: Ubuntu 10.10 Server:

1 - Get necessary packages to setup the Wave-in-a-box environment:

$: sudo apt-get install mercurial ant default-jdk mongodb eclipse 

NOTE: With Ubuntu 10.10 you need to get the repository for Java first:

 $: sudo add-apt-repository ppa:sun-java-community-team/sun-java6

 $: sudo apt-get update

2 - Get current Wave-in-a-Box source:

$: mkdir wave-development

$: cd wave-development

$: hg clone https://wave-protocol.googlecode.com/hg/ wave-protocol

3 - Build Wave-in-a-Box:

$: cd wave-protocol

$: sudo ant

Building Wave-in-a-Box is pretty straight forward however there are a few things to know if you intend to federate with other Wave-in-a-Box instances, especially when authentication is used.  Two major components, not mentioned above, are required to establish secure signing between servers and to allow some of the live collaboration. You will need to install an XMPP server and have your certificates built for the domain you are going to use for federation.  I also needed to add a few things to my host file and setup SRV records on my domain registrar to get all to work correctly.

Below are some links to help you in getting all of Wave-in--Box setup and working:

Setup: http://www.waveprotocol.org/wave-in-a-box/setting-up

Building: http://www.waveprotocol.org/wave-in-a-box/building-wave-in-a-box

Installation: http://www.waveprotocol.org/code/installation

XMPP step by step (Openfire): http://www.waveprotocol.org/federation/openfire-installation

Federation Certificates: http://www.waveprotocol.org/federation/certificates

Certificate Issuer: http://www.startssl.com/

A great step by step by Ralf Rottman: http://www.24100.net/2009/11/federate-google-wave-sandbox-with-your-own-fedone-server/

Once you are setup you can start trying out your newly, self-hosted Wave server. WiaB comes with two client interfaces.  The first is a terminal client located in the "wave-protocol" directory which can be used by typing:

./run-console-client.sh <username>  

Once inside you can type "/help" to see the available commands.

The other interface is web-based and works rather well.  This is the area that is under major development to bring it to parity with Google Wave's web UI.  By default it is accessible on port 9898 so you can access it by visiting http:/yourdomain.com:9898.  

Currently Federation is only open on other WiaB instances in which it is enabled and the developers sandbox at http://wavesandbox.com.  If you just want to try to set WiaB without federation, certificates and XMPP servers are not necessary.  You can then setup the server and install and build the source and run the server.  There is currently a config file for no federation that will allow you to test out the web UI quickly with very little headache.  Federation is key to the success of this platform in the long run so if you are serious about sustaining a Wave server, get federation running too! ~Lou

A Few Images:

(download)

Click here to download:

google-boxes-up-wave-survival-via-federation-zCqmbrgypIcgFknjypzG.zip (149 KB)

If you have questions or run into any issues, please leave a comment or send me a message:

Twitter: @gol10dr

Wave: gol10dr@googlewave.com

Since this abrupt exit of my update process, my SSH MOTD (message of the day) which, by default displays the landscape sysinfo and available updates was static. Now every time I would SSH into the server, the login sysinfo was always the same and it showed that I had 311 updates that running and apt-get update then upgrade would yield no such update.  It also kept telling me that an update was required even though a reboot file was not present in:

/var/run/reboot-required

There are a couple of files that need to be changed in order to correct this static message. The first, which you should not edit but can clear since it is overwritten is located at:

/etc/motd

This file is updated with the MOTD info but removal of anything here will simply get rewritten with  updated infomation and anything located in the "tail" file.   Editing the MOTD tail will append the info pushed to /etc/motd.  Upon editing:

/etc/motd.tail

In my case the /etc/motd.tail contained the same static message that I was seeing in my SSH session. Clearing this or adding your own custom message will now display your correct landscape sysinfo and you new custom "tail" content. 

Note - If you clear the tail and reboot and immediately log in via SSH, you might receive a message saying "System information disabled due to load higher than 1" so wait about 10 minutes before logging in to see if you new MOTD will display correctly.  

You can also display the same welcome landscape sysinfo by running he following command:

/usr/bin/landscape-sysinfo

UPDATE:

Another thing I noticed is that my update-notifier module has somehow been removed so if you are noticing that your update notification from MOTD is not showing up, ensure that update-notifier in installed.

All the ThinkUp web app needed was to be dropped in a folder accessable from your website, given write access and have an empty mysql database and user to specify for the setup.  The easy way would be to create a folder in your root directory so you could access it by going to:

http://yourdomainname.com/webapp

In my case my Apache root is set to my StatusNet instance in my www root (ie. /var/www/statusnet) and I didn't want to place the ThinkUp app folder in my "statusnet" folder due to it messing with my upgrade workflow for StatusNet.

I opted to create a folder in my www root for Thinkup (/var/www/thinkupfolder) but since Apache's root was set to /var/www/statusnet, I needed to create a shortcut to this location. To do this I used an alias.  With your favorite editor edit:

/etc/apache2/sites-available/default

Add the following:

Alias /webapp /var/www/webapp/
<Directory /var/www/webapp>
Options Indexes MultiViews
AllowOverride All
Order allow,deny
Allow from all
</Directory>

You can visit Apache's site to learn how to restrict access and add other controls as well. Now you can keep your web apps separate but still access them from your domain root as a sub directory! ~Lou

StatusNet, the open source microblogging platform I use, supports a number of technologies within their plugin architecture, one of which is Meteor.  Only having a single server (for now) hosting my StatusNet site, I wanted to get Meteor running and coincide with Apache.  Since they both want to play in the HTTP playground known better was port 80, I needed to reconfigure Meteor to run.

Meteor Configuration:

- Follow all the setup instructions from the Meteor site.

- Before RUNNING Meteor you need to change Meteor's Config.pm to avoid colliding with Apache on port 80. (for example 8085 instead of 80)

Modifications:

- Edit /usr/local/meteor/Meteor/Config.pm to match the following:

1. ControllerIP => '127.0.0.1', (This is empty by default, leave the port to 4671)
2. SubscriberIP => 'ip.of.your.statusnet', (I used the IP of my domain name)
3. SubscriberPort => '8085', (This is my example port mentioned above)

- An additional change was made to the meteor.js file to reflect my new port specification (8085 in our example)

Modifications:

1. port: 8085 

- Run Meteor in the background, however in Ubuntu you will need to modify the "Meteord" file first.  This is detailed on step 3 in the Meteor installation site since they test in Fedora. (Also make sure /etc/init.d/meteord is set to executable (chmod +x meteord)

sudo /etc/init.d/meteord start

NOTE: You can also check that Meteor is running by running the following command:

sudo netstat -plunt

 StatusNet Configuration:

Since StatusNet has an extensive plugin framework, adding technologies like Meteor is a snap!  A few lines in your Config.php and realtime will be live!  Here are the steps: (using our 8085 port)

1. Edit your Config.php
2. Add the Plugin: (this will communicate with your Meteor server and add the play/pause buttons to the top of your site's timeline)

addPlugin('Meteor', array('webserver' => 'yourdomain.com', 'webport' => '8085', 'controlserver' => '127.0.0.1', 'controlport' => '4671'));

scripts/startdaemons.sh

scripts/stopdaemons.sh

ps aux

sudo kill PID (replace PID with found process ID)

Additional Notes:

Currently there appears to be an issue with pages continuously reloading on Webkit browsers like Chrome and Safari. The good folks at StatusNet have fixed this issue with on their Meteor site at meteor2.identi.ca.  I just pulled down the 4 files located in their public_html folder and replaced mine, adjusting the port in their meteor.js file as mentioned above. ~Lou