Recently, I gave the kindle a try, to see if I could really get back into reading books. Even though I’m a huge supporter and overzealous user of technology, I was wary of the kindle at first. I didn’t like the thought of not being able to flip pages, not being able to dog-ear pages and write notes in the book. It really bothered me that when I finished dedicating all that time to a novel, I wouldn’t have a paper back trophy to add to the collection. Then I actually gave it a try …

Kevin Mitnick’s autobiography, “Ghost in the Wires: My Adventures as the World’s Most Wanted Hacker“, instantly interested me as I had read “Takedown: The Pursuit and Capture of Kevin Mitnick, America’s Most Wanted Computer Outlaw-By the Man Who Did It” by Tsutomu Shimomura and John Markoff in highschool.

In this spare-no-details first hand account, Mitnick takes us through his rise to become the FBI’s most wanted target, detailing his steps in creating new identities to allude the law enforcement manhunt while (quite successfully) staging a counter snooping operation that kept him one step ahead of his pursuers for years.

Many of Mitnick’s exploits are based on an attack vector known as Social Engineering. He outlines the three steps to successful social engineering as:
1) Assume a position of authority
2) Convince the victim that you are supposed to be doing what you are asking them to do
3) Convince the victim that you are unable to do it yourself, and you need their help
These three steps, if performed properly, almost always result in the victim doing something for you that you shouldn’t be able to do yourself. Mitnick, by simply talking to people on the phone, was incredibly skilled in getting people to grant him access to restricted information and change systems that he didn’t have the permission to change himself.

Overall, this book assumes you have some background understanding of how a Telco operates, and is not for the technically challenged, although it rarely goes into great technical detail.

What I found most interesting was Mitnick’s thoughts on solitary confinement, a topic he became quite familiar with through first hand experience.  Spending 8 months in solitary confinement for non-violent crimes seems a little harsh, and Mitnick constantly describes the damaging psychological impact that it can have on a human being.

At one point, Mitnick describes being diagnosed as having an “addiction to hacking” in the same sense as an addiction to smoking or drinking.  This is easily justified given his lack of “for profit” exploits in lieu of a constantly exploiting Telcos on the quest for knowledge.

The truly shocking thing about this book is not Mitnick’s exploits, but the vulnerabilities in the Telco’s themselves, something I have been conscious of for years. Most of his code based exploits were piggybacked on Social Engineering attacks against the Telcos. The biggest vulnerability in the phone companies are the Operators, Service Technicians and general staff who are willing to break security protocol (or even completely disregard it) for someone who speaks their rare and unique, highly technical language. This is a terrifying reality considering the power one can wield by simply convincing people over the phone to do something.

I highly recommend this book to other tech junkies looking for a good read, and am looking forward to reading some of his other books.

You can check out the tab here.

I’ve been playing with the Facebook API for a while, and I’ve never really been satisfied with the final product.  Something about it always seemed incomplete.  There were all kinds of restrictions and all kinds of hacks to break restrictions.  For example, I had a photo gallery inside a Facebook tab that leveraged a Dialog window to display a full size image, thanks to the old Javascript API.  Way cool effect for a photo gallery, but hacked out and not really supported which eventually caused it to break.

I’ve been working on a website for a few months, and I wanted to build something that would extend its reach to Facebook.  I wanted to create something that would really allow people to interact with each other, on Facebook, the way they used to with Apps like SuperPoke.

1) Pick a gift.
2) Pick a friend.
3) DIRECT INTERACTION that all your friends see.

The popularity of App provoked direct interaction between two people on Facebook is something that has really faded, probably due to horrible API documentation, and been replaced by a more pure, unaided post based interaction.  Our solution was to build an App that provided quality content worthy of sharing on Facebook while making it a very simple to share the content with a friend.

Facebook has built in facilities for sharing content with friends.  They used to provide access to some of those facilities in older versions of the API, but have since stripped out access to those facilities and replaced it with a lower level access to Facebook data, effectively moving third party developers closer to the database.  This is very beneficial to developers if they can figure out how to interface with the API, as it not only allows, but forces the developer to build out the full flow of interaction, but unfortunately, often becomes a task of blindly reverse engineering return values and function calls.

Alright, enough bitching about Facebook, lets take a look at the product … and I’ll bitch some more later.

Our wall is composed of a huge list of beers that you can scroll through.  Step 1 is simply to pick a beer.  When you click on the beer, you are asked to authorize the app, giving access to your basic information (friends list).  After Authorizing the App (you only have to authorize it the first time you use it, it will be stored in your preferences), you will be shown a list of your friends in alphabetical order.  ‘In alphabetical order’ doesn’t seem that impressive, but it’s not built in.  The Graph API uses lazy sorting when it returns the friends list, so it had to be sorted in Javascript by the browser.

Step 2 is just as simple, click on one of your friends.

Step 3: Facebook dialog asking if you want to post the chosen beer to the chosen friends wall.  Type in a description, and click share.  Thats it.  3 clicks and you can share any of the almost 200 beers with any of your 342,000 friends.  Simple enough, right?  Now lets look at the code …

<html>
<head>
<style>
// Put some style info for your div ids and classes here
</style>
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.min.js" type="text/javascript"></script>
</head>

In the first block of code we setup a basic HTML layout and load the jquery script from Google’s Servers (Props to Google for hosting a lot of good frameworks for the masses).  The Jquery framework is going to help us with a few things, hiding and showing divs, getting and setting variable values, etc.

<body>
<div id="fb-root"></div>
<script>
window.fbAsyncInit = function() {
FB.init({
appId  : 'YOUR_APP_ID_HERE', //FILL IN YOUR APP ID
status : true, // check login status
cookie : true, // enable cookies to allow the server to access the session
xfbml  : true, // parse XFBML
oauth  : true // enable OAuth 2.0
});
//  FB.Event.subscribe('auth.statusChange', onFacebookStatusChange);
};
(function() {
var e = document.createElement('script');
e.src = document.location.protocol + '//connect.facebook.net/en_US/all.js';
e.async = true;
document.getElementById('fb-root').appendChild(e);
}());

The above code sets up the body element and uses javascript to load the Facebook Javascript API asynchronously.  Be sure to fill in your App ID or this will fail to load the API and all calls to the API will fail.

function onFacebookInitialLoginStatus(response) {
if (response.status != "connected" || response.authResponse == null) {
facebookLogin();
}
FB.api('/me/friends', function(response) {
var friends1 = response.data;
var friends = friends1.sort(sortByName);
var l = friends.length;
for (var i=0;i<l;i++) {
$('#friends ul').append("<li onclick=\"personSelected(" + friends[i].id + ");\"><img src=\"https://graph.facebook.com/" + friends[i].id + "/picture/\"><p>" + friends[i].name + "</p></li>");
}
$('.beers_image_list').hide();
$('#beers_page_header').hide();
$('#footer').hide();
$('#friends_header').show();
$('.friends_image_list').show();
});
}

The above function is responsible for checking the LoginStatus of the requesting user.  I had to reverse engineer the response object as there is no proper documentation outlining what actually gets returned.  What comes back is a list of friends stored in response.data, but the Graph API uses a lazy sorting method and returns the list without any useful sort performed.  We must therefore implement a method in Javascript to sort the returned list.  This all takes place in the browser instead of on the server.

function sortByName(a, b) {
var x = a.name.toLowerCase();
var y = b.name.toLowerCase();
return((x < y) ? -1 : ((x > y) ? 1 : 0));
}

The above function had to be implemented into the code (and was taken from HERE) to sort the list of friends.

function facebookLogin() {
FB.login(onFacebookInitialLoginStatus);
}

The facebookLogin() function does some stuff FILL IN EXPLAINATION

function shareBeer(selected_beer_img, selected_beer_link, selected_beer_name, selected_beer_brewery, selected_beer_type, selected_beer_locality) {
$('#selected_beer_image').html(selected_beer_img);
$('#selected_beer_link').html(selected_beer_link);
$('#selected_beer_name').html(selected_beer_name);
$('#selected_beer_brewery').html(selected_beer_brewery);
$('#selected_beer_type').html(selected_beer_type);
$('#selected_beer_locality').html(selected_beer_locality);
FB.getLoginStatus(onFacebookInitialLoginStatus);
}

The shareBeer() function is really the heart of what makes our product unique and easy to use.  By utilizing the Jquery framework, we are able to create a simple and easy to use user interface that allows users to perform step 1, Choose a Beer.  The function is fired by an onclick event attached to the <li> object that we will look at a little later in the HTML.  shareBeer() takes a few arguments, all of which are information that will get passed to the final dialog and describe the Beer that someone is going to share.  Because I am not overly familiar with Javascript, and it made debugging extremely easy, I chose to pass the variables from step 1 to step 2 inside of hidden div elements in the HTML.  The divs were hidden with CSS (display:hidden;).

function personSelected(person) {
FB.ui({
method: 'feed',
to: person,
name: $('#selected_beer_name').html(),
link: 'http://nationwidebarcrawl.com/link/',
picture: $('#selected_beer_image').html(),
caption: 'Free. As in Beer.',
description: '<center>Brewery: ' + $('#selected_beer_brewery').html() + '</center><center>Type: ' + $('#selected_beer_type').html() + '</center><center>Locality: ' + $('#selected_beer_locality').html() + '</center>'
}, function(response) {
if (response && response.post_id) {
alert('post published');
} else {
alert('post failed');
}
});
}
</script>

This function is responsible for popping the ‘post to wall’ dialog which is popped by calling the ‘feed’ method of the FB.ui() Graph API function.  We again utilize Jquery to pull the values from the Beer object variables that we set inside of hidden divs.  This function is triggered by an onclick event on the <li> that we will look at later in the HTML.  The onlick event passes the Facebook id of the friend who occupies the clicked <li>.  The FB.ui call utilizes this argument as the ‘to’ value for the call.  If you leave the ‘to’ value blank, the dialog will default to posting to the requesting users feed.  Without this ‘to’ argument, our Facebook App loses its ability to provoke social interaction, and thus, its value to the Facebook community.

The description utilizes the <center> tag to get line breaks in our post.  Currently, Facebook does not allow you to put line breaks in your post description, but wrapping each line inside of a <center></center> tag will display the content on separate lines.

<div id="friends">
<div id="friends_header"></div>
<ul></ul>
</div>
<div id="beers_page_header"><a href="http://nationwidebarcrawl.com/beers/" target="_blank"><img src="/media/images/facebook/beers_button.png" /></a></div>
<ul>
{% for beer in beers %}<li><a href="#" onclick="shareBeer('{{ beer.mainphoto.get_singlebeer_url }}', 'http://nationwidebarcrawl.com/beers/{{ beer.slug }}', '{{ beer }}', '{{ beer.brewery }}', '{{ beer.type }}', '{{ beer.get_locality_display }}');"><img src="{{ beer.mainphoto.get_singlebeer_url }}" /><p>{{ beer }}</p></a></li>{% if forloop.counter|divisibleby:"4" and not forloop.last %}</ul><ul>{% endif %}{% endfor %}
</ul>
<div id="footer"><a href="http://cloudcreativegroup.com/" target="_blank"><img src="/media/images/facebook/footer_logo.png"></a></div>
<div id="selected_beer_image"></div>
<div id="selected_beer_link"></div>
<div id="selected_beer_name"></div>
<div id="selected_beer_brewery"></div>
<div id="selected_beer_type"></div>
<div id="selected_beer_locality"></div>
</body>
</html>

The above HTML generates the entire 3 step process in a single page, embedded inside of a Facebook fan page, utilizing Jquery to require only the initial page load to facilitate the entire 3 step process of sharing a gift with a friend.

AN OPEN CALL TO FACEBOOK

Facebook, love the website.  In fact, it eats up a large amount of my daily time, but we have to have a talk about your API.  You guys have moved at an extremely fast pace over the last couple years, starting out as a College based social network and eventually expanding to encompass the whole world.  During this time, many developers have felt as though you haven’t put enough emphasis on keeping your API documentation up to date (and working for that matter).  I like how you guys have spent a lot of time trying to explain the concepts behind a lot of the inner workings of your API, but honestly, none of the documentation really helped me understand what was going on.

The one thing I think you guys could really improve, and quite easily, would be a full API reference.  If you’re not sure what one of those looks like, take a look at Google Maps API Version 3 reference here: http://code.google.com/apis/maps/documentation/javascript/reference.html

With a fully documented API reference, you will see a lot more quality apps being developed for your platform.

This is an updated version of an older blog post outlining a full (VE) build for django.  I had to update my server due to incompatibilities between the latest version of WordPress and the versions of PHP/MySQL found in the standard CentOS repos.

// SHOUTOUTS

Malcolm Frazier – (still) holding it down with the Linux knowledge.

// USER ACCOUNTS

The first step is to create a user account so you don’t have to use root

# useradd <username>
# passwd <username>

Add a user group so we can setup the sudoers file and add our new account to the group

# /usr/sbin/groupadd <new_group_name>
# /usr/sbin/usermod -a -G <new_group_name> <username>

I like to use the locate command a lot, so lets build the index of the file system that locate uses to search

# updatedb

Setup the sudoers config file

# vim /etc/sudoers

Add the following lines to the bottom of the file:

# Customizations
%<new_group_name>     ALL=(ALL)     ALL

*** The above modification more or less gives all users in <new_group_name> the ability to do anything root can do, without the root password.  This is fine for building the server, but after the server is built, you should restrict the permission levels a little bit more.

At this point you should be able to exit ssh and log back in as your new user account.  You can use sudo <command> to execute commands as root, or use sudo -s as a replacement for su.

// UPGRADE PACKAGES SYSTEM WIDE

# yum upgrade

// INSTALLING PYTHON 2.7

I’ve chosen to use Python 2.7 as my version of python for django.  CentOS 5.5 comes with Python 2.4 already installed.  I had some down time on a past project because I asked the techs at RackSpace to upgrade the version of Python on the server and they started by uninstalling Python 2.4.  The problem is that the yum package management system that CentOS uses is built on top of Python.  If you uninstall Python 2.4, you will not be able to use yum to install Python 2.7, or any other package at that point.  The solution is to install Python 2.7 in parallel to 2.4, have Django and all your other apps use the 2.7 install, and leave 2.4 to be used by yum and the underlying OS.

Before we start compiling, lets install the GCC compiler:

# yum install gcc

This will prevent the following error from occurring if you try to compile python without gcc:

configure: error: in `/root/Source/Python-2.7':
configure: error: no acceptable C compiler found in $PATH

Additionally, you’ll want to install a few extra optional dependencies for Python

# yum install readline-devel gdbm-devel sqlite-devel
# yum install openssl-devel ncurses-devel bzip2-devel

Theres a great tutorial on installing Python 2.7 on CentOS 5 here.

Instead of using /usr/src/ for all the source code, I created /root/Source/ to hold the source from all the packages.  Inside of Source, download and extract Python 2.7:

# wget http://www.python.org/ftp/python/2.7/Python-2.7.tar.bz2
# tar -xvjf Python-2.7.tar.bz2
# cd Python-2.7
# ./configure --help

Read through the configure help and see if there are any options you want to enable or customize.  Then run the configuration script:

# ./configure --prefix=/usr/local/python2.7 --enable-shared

–prefix tells python to install to a directory other than the default.  This is necessary if we want to run both 2.7 and 2.4 side by side.

–enable-shared will prevent an error later on when trying to build mod_wsgi.  If you get the following error when building mod_wsgi, recompile and reinstall python with –enable-shared:

/usr/local/python2.7/lib/libpython2.7.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
apxs:Error: Command failed with rc=65536
make: *** [mod_wsgi.la] Error 1

Now its time to build and install Python:

# make
# make install

// SETUP ENVIRONMENT VARIABLES

$ vim ~/.bashrc

Add the following to the bottom of .bashrc:

# User specific aliases and functions
alias python='/usr/local/python2.7/bin/python'

Log out, Log back in, and you should be able to execute the new Python 2.7

$ python
Python 2.7
>>>

// INSTALLING PIL (PYTHON IMAGING LIBRARY)

At this point, if you install PIL without first satisfying the optional dependencies, PIL will be built without libjpeg and zlib (png support).  The output of python setup.py install would be:

*** TKINTER support not available
*** JPEG support not available
*** ZLIB (PNG/ZIP) support not available
*** FREETYPE2 support not available
*** LITTLECMS support not available

Unfortunately, PIL doesn’t complain very loudly and will still install a working version that will not be able to handle .jpg or .png files.  If you install PIL without the header libraries for the dependencies present, you will receive the following error in django’s admin when trying to upload an image file:

Upload a valid image. The file you uploaded was either not an image or a corrupted image.

You can further verify if the proper support is compiled in from the shell:

$ python
>>> from PIL import Image
>>> i = Image.open("/path/to/some/image.jpg")
>>> i.verify()
>>> i.load()
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/usr/local/python2.7/lib/python2.7/site-packages/PIL/ImageFile.py", line 189, in load
d = Image._getdecoder(self.mode, d, a, self.decoderconfig)
File "/usr/local/python2.7/lib/python2.7/site-packages/PIL/Image.py", line 385, in _getdecoder
raise IOError("decoder %s not available" % decoder_name)
IOError: decoder jpeg not available

You can see from the above error that the jpeg decoder is not available.  If you’ve already installed PIL, uninstall it.  If you havn’t installed PIL yet, this will save you a lot of time (:

# yum install zlib zlib-devel
# yum install libjpeg libjpeg-devel
# yum install freetype freetype-devel

Django relies heavily on the PIL.  Again in our /root/Source directory, install PIL:

# wget http://effbot.org/downloads/Imaging-1.1.7.tar.gz
# tar xvfz Imaging-1.1.7.tar.gz
# cd Imaging-1.1.7
# python setup.py build_ext -i

Check to make sure that libjpeg and zlib were found:

*** TKINTER support not available
--- JPEG support available
--- ZLIB (PNG/ZIP) support available
--- FREETYPE2 support available
*** LITTLECMS support not available

Run a test to make sure that everything works:

# python selftest.py
--------------------------------------------------------------------
PIL 1.1.7 TEST SUMMARY
--------------------------------------------------------------------
Python modules loaded from ./PIL
Binary modules loaded from ./PIL
--------------------------------------------------------------------
--- PIL CORE support ok
*** TKINTER support not installed
--- JPEG support ok
--- ZLIB (PNG/ZIP) support ok
--- FREETYPE2 support ok
*** LITTLECMS support not installed
--------------------------------------------------------------------
Running selftest:
--- 57 tests passed.

And finally, install PIL:

# python setup.py install

You should now be able to import PIL inside of python:

$ python
>>>import PIL
>>>

// INSTALLING MYSQL

Enable the Remi Repository to install MySQL 5.5 and PHP 5.3.  More information about the Remi Repository can be found here.

# wget http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
# rpm -Uvh epel-release-5-4.noarch.rpm
# rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-5.rpm
# yum --enablerepo=remi list mysql mysql-server
# yum --enablerepo=remi install mysql.x86_64 mysql-server.x86_64

Start the MySQL Server:

# /etc/init.d/mysqld start

In order to set the initial root password, and get rid of the built in tables/user accounts for testing, run:

# /usr/bin/mysql_secure_installation

Follow the instructions, pick your customizations … then make sure MySQL is installed and working:

# mysql -u root -p
Enter password:
mysql> SELECT VERSION();
+-----------+
| VERSION() |
+-----------+
| 5.5.14    |
+-----------+
1 row in set (0.00 sec)

Add MySQL to the proper run level:

# /sbin/chkconfig mysqld on

// MYSQL-PYTHON GAP

Next, you need to install MySQL-python, the python interface to MySQL.  If you do not install MySQL-python, later on when you try to do a ‘python manage.py syncdb’ django will not be able to communicate with MySQL and will throw the following error:

django.core.exceptions.ImproperlyConfigured: Error loading MySQLdb module: No module named MySQLdb

Setuptools is a required dependency of MySQL-python.  Download it from here and install it, setting the prefix to our freshly installed python2.7

# sh setuptools*.egg --prefix=/usr/local/python2.7

Now install the MySQL headers from the Remi repo, then install MySQL-python:

# yum --enablerepo=remi install mysql-devel.x86_64
# wget http://sourceforge.net/projects/mysql-python/files/mysql-python/1.2.3/MySQL-python-1.2.3.tar.gz/download
# tar -zxvf MySQL-python-1.2.3.tar.gz
# cd MySQL-python-1.2.3
# python setup.py build
# python seutp.py install

At this point django should be able to talk to MySQL using MySQL-python.

// INSTALLING APACHE

Next we have to install our web server, Apache.  There’s a pretty straight forward tutorial on this here.

# yum install httpd
# /sbin/chkconfig httpd on
# /etc/init.d/httpd start
Starting httpd:                                            [  OK  ]

At this point, you should spend some quality time with /etc/httpd/conf/httpd.conf to really squeeze some power out of apache.

// INSTALLING DJANGO

The django install docs can be found here.

# wget http://www.djangoproject.com/download/1.3/tarball/
# tar xzvf Django-1.3.tar.gz
# cd Django-1.3
# python setup.py install
$ python
>>> import django
>>>

// INSTALLING PHPMYADMIN

PhpMyAdmin is a web interface for controlling your MySQL database.

# yum install phpmyadmin

This will install PHP as a dependency, but you will still need to setup PHP.  Setup the PHP Cookie:

# vim /usr/share/phpmyadmin/config.inc.php

Add the Python Shared Libraries

# vim /etc/ld.so.conf.d/python2.7.conf

add the following line:

/usr/local/python2.7/lib

Create necessary links and cache the new libraries:

# ldconfig

// INSTALLING MOD_WSGI

mod_wsgi is the link between apache and django.  It is responsible for taking the web request from apache and getting it to your django app for handling.  The mod_wsgi installation docs are a great resource, they can be found here.

First, we need to install the source code for apache, as mod_wsgi needs it to build.  Install the httpd-devel package, which will install the headers for apache.

# yum install httpd-devel

Get and install mod_wsgi

# wget http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz
# tar -zxvf mod_wsgi-3.3.tar.gz
# cd mod_wsgi-3.3
# ./configure --help
# ./configure --with-python=/usr/local/python2.7/bin/python
# make
# make_install

// POINT APACHE AT DJANGO USING MOD_WSGI

First, you need to tell apache which version of python to use so it doesn’t use the default 2.4:

# vim /etc/httpd/conf/httpd.conf

Add the following to the bottom of the file:

# Python Versioning Control for mod_wsgi
WSGIPythonHome /usr/local/python2.7

Make sure you load mod_wsgi in httpd.conf at the end of the LoadModule section

LoadModule wsgi_module modules/mod_wsgi.so

Then restart apache

# /etc/init.d/httpd restart

Now you can configure your virtual hosts in apache to point to a ‘django.wsgi’ file thats specific to each django project you create.  Add the WSGIScriptAlias to your Virtual Host configuration file:

WSGIScriptAlias / /path/to/your/django/project/django_project_name/apache/django.wsgi

Add the ‘apache’ directory to your django project, and create the django.wsgi file inside the apache directory:

$ cd /path/to/your/django/project/django_project_name/
$ mkdir apache
$ cd apache
$ vim django.wsgi

Copy the following into the django.wsgi file:

import os
import os.path
import sys

sys.path.append('/path/to/project/root')

os.environ['PYTHON_EGG_CACHE'] = '/path/to/a/directory/for/egg_cache'
os.environ['DJANGO_SETTINGS_MODULE'] = 'your_django_project_name.settings'

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

If you’ve made it this far, you should have a working django install.

(:

A Look at Facebook Five Years Later

”’ Solution ”’
For security reasons, FTP is disallowed on our server forcing everyone to use SFTP. As such, we were not able to simply disallow SSH as it is required for SFTP to function properly. After messing around with Linux file permissions for a while, we figured out a few modifications that need to be made to block our new users from SSH while maintaining their ability to SFTP to a specific directory and be able to modify all files under that directory.

The first step is to create a group for the new user to apply to their specific folder so we can set permissions on their files at the group level. Then we create a new user account and add them to the new group. For this post we will use the user NewUser and the group NewGroup.

# /usr/sbin/groupadd NewGroup
# /usr/sbin/useradd -g NewGroup NewUser
# /usr/bin/passwd NewUser

Now lets setup the directory the new user will drop into, and block their ability to do anything useful with SSH. Inside of /etc/passwd, find the line that looks something like this:

# vim /etc/passwd
NewUser:x:501:502::/home/NewUser/:/bin/bash

Now lets say the root directory for the site we want to the user to modify is /var/www/website.com/ so we change the home directory in /etc/passwd to point to this directory. When the user SFTPs into the website.com, they will be dropped in this directory. Additionally, we want to set their shell to the location of sftp-server, which can be found by running #which sftp-server

NewUser:x:501:502::/var/www/website.com/:/usr/libexec/openssh/sftp-server

Now we can change the group permissions on /var/www/website.com/ with

# cd /var/www/website.com/
# chgrp -R NewGroup *

This will let you control permissions for NewUser at the group level. The last thing to do is disallow the user read on the directory above website.com/ which will stop them from going up the directory tree, effectively locking them into website.com/

# cd /var
# chmod 771 www

At this point, NewUser will be able to SFTP to website.com which will drop them into /var/www/website.com/ but they will be unable to move up a directory and SSH will respond with a shell that isn’t interactive.

# Shoutouts
Most of this information came from Franchising: Running Multiple Sites from one Django Codebase by Huy Nguyen.  Really great article.

# Problem Context
For this project, we had to build 9 splash pages for a QR Code campaign. Each website had to have its own branding, and we were afforded the luxury of having a separate domain name for each page. By leveraging Django, we were able to provide a single page CMS to manage all of the splash pages while each splash page exists on its own domain.

# Solution
At some point from the initial request to the served template we had to distinguish which domain the request was generated from. This was accomplished at the apache level, using the django.wsgi script to add an environment variable equal to the domain the request originated from. The different django.wsgi scripts (1 for each domain) were then called by each virtual host individually.

At this point you should have a django project already created. There will be a single project that all of the individual sites are served from. Create the main project as you would at the beginning of any normal project.

# Setup Apache to call individual wsgi files
In your virtual host configuration file, you want to declare an alias that points to a common directory that will be used to hold the media for all the different domains, then point each domain at its own django.wsgi script:

Alias /media/ /directory/to/SharedDomainForAllSites.com/htdocs/media/
WSGIScriptAlias / /path/to/django_project/apache/IndividualSiteName/django.wsgi

Now in /path/to/django_project/apache/ create a directory for each domain that will call your project. We will put the django.wsgi file from above into this directory.

$ cd /path/to/django_project/
$ mkdir apache
$ cd apache
$ mkdir IndividualSiteName
$ cd IndividualSiteName
$ vim django.wsgi

Inside each django.wsgi file, set the OVERLOAD_SITE variable to a name that identifies each domain uniquely. We will use this variable to tell django which CSS file to load, which template to use, which domain to search for media files, etc.

import os
import os.path
import sys

sys.path.append('/path/to/django/django_project')

os.environ['DJANGO_SETTINGS_MODULE'] = 'django_project.settings'
os.environ['OVERLOAD_SITE'] = 'IndividualSiteName'

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

Back up in your main project directory, were going to modify the settings.py file to overload the MEDIA_ROOT and MEDIA_URL variables based on the request from each domain. At the bottom of settings.py, add the function that will overload the variables:

#
# IMPORT CUSTOM SETTINGS BASED ON DOMAIN MAKING THE CALL
#
import os
OVERLOAD_SITE = os.environ.get('OVERLOAD_SITE')
if OVERLOAD_SITE:
        OVERLOAD_SITE_MODULE ="site_overloads" + "." + OVERLOAD_SITE
        exec "from %s.settings import *" % (OVERLOAD_SITE_MODULE)
        # Overload the MEDIA_ROOT with site specific path
        try:
                MEDIA_ROOT = OVERLOAD_MEDIA_ROOT
        except:
                pass
        # Overload the MEDIA_URL with site specific URL
        try:
                MEDIA_URL = OVERLOAD_MEDIA_URL
        except:
                pass

For the MEDIA_ROOT and MEDIA_URL configuration at the top of the settings.py file, set a directory that will be a common directory used to host the media for all domains. If you override the MEDIA_URL for every domain, these settings will be ignored, so their values arn’t that important.

To set the override values, create the site_overloads directory that is referenced in the function we just added to settings.py. It should be in the project root.  Inside site_overloads, create a directory for each individual domain that has the same name as the OVERLOAD_SITE variable from the django.wsgi file. Inside of site overloads, you must add a blank __init__.py file, or django will not be able to pull files from the directory:

$ cd /path/to/django_project/
$ mkdir site_overloads
$ cd site_overloads
$ touch __init__.py
$ mkdir IndividualSiteName
$ cd IndividualSiteName
$ touch __init__.py

Now we will add a settings.py and urls.py file to each folder that will provide the overloads for each specific domain:

# settings.py
# Overload Default MEDIA_ROOT
# Use this if you want to serve up separate media for each domain
#OVERLOAD_MEDIA_ROOT = '/c2g/sites/auburnparkave.com/htdocs/media/'

# Overload Default MEDIA_URL
OVERLOAD_MEDIA_URL = 'http://IndividualSiteName.com/media/'

In your Apache Virtualhost config, recall that we set an Alias to /media/.  This Alias will allow you to put any domain in OVERLOAD_MEDIA_URL and have the single media directory exist at http://EachDomainName.com/media/.

New lets look at the urls.py.  For our project, each domain was hosting a single splash page, so we were able to serve all requests by providing the context straight from the url, letting us completely skip making any views.

# urls.py
from django.conf.urls.defaults import *
from django.views.generic.simple import direct_to_template
from pages.models import Page

urlpatterns = patterns('',
(r'^$', direct_to_template, {'template': 'SingleTemplate.html',
'extra_context': {'page': Page.objects.get(name__exact='IndividualSiteName'),
'sliderImages': Page.objects.get(name__exact='IndividualSiteName').slider.photos.all()}}),
)

The above assumes  you have a Page class in your models.py with a name field and a slider field.  You can modify the code to request anything you want from your models, or call a view for more indepth interaction.

Well, that should get you separate domains all hooked up to a single django app, capable of having a shared or individual media directories as well as individual domain names, all with a single page CMS for managing all your sites.

Enjoy.

http://blog.hackedexistence.com/mediatemple-centos-5-5-ve-server-build-django-1-3-python-2-7-mysql-5-5-php-5-3

Media Temple is End-Of-Life-ing their Grid Server Django Containers.  As such, I had to migrate all my django sites off the grid onto a new (VE) server.  This is a guide for building a stock CentOS 5.5 server with django and python 2.7.

// SHOUT OUTS

Malcolm Frazier – Holding it down with all the linux knowledge.

// USER ACCOUNTS

The first step is to create a user account so you don’t have to use root

# useradd <username>
# passwd <username>

Add a user group so we can setup the sudoers file and add our new user account to the group

# /usr/sbin/groupadd <new_group_name>
# /usr/sbin/usermod -a -G <new_group_name> <new_user_name>

I like to use the locate command a lot, so lets build the index of file names to search from

# updatedb

Setup the sudoers config file

# vim /etc/sudoers

Add the following lines to the bottom of the file:

# Customizations
%<new_group_name>    ALL=(ALL)       ALL

At this point you should be able to exit ssh and log back in as your new user account.  You can use sudo <command> to execute commands as root, or use sudo -s as a replacement for su.

// UPGRADE PACKAGES SYSTEM WIDE

# yum upgrade

// INSTALLING PYTHON 2.7

I’ve chosen to use Python 2.7 as my version of python for django.  CentOS comes with Python 2.4 already installed.  I had some down time on a project because I asked the techs at RackSpace to upgrade the version of python on the server and they started by trying to uninstall Python 2.4.  The problem is that the yum package management system that CentOS uses is built on top of python.  If you uninstall python 2.4, you will not be able to use yum to install python 2.7, or any package at that point.  The solution is to install Python 2.7 in parallel to 2.4, have Django and all your other apps use the 2.7 install, and leave 2.4 to be used by yum.

Theres a great tutorial on installing Python 2.7 on CentOS 5 here.

Instead of using /usr/src/ for all the source code, I created /root/Source/ to hold the source from all the packages.  Inside of Source, download and extract Python 2.7:

# wget http://www.python.org/ftp/python/2.7/Python-2.7.tar.bz2
# tar -xvjf Python-2.7.tar.bz2
# cd Python-2.7
# ./configure --help

Read through the configure help and see if there are any options you want to enable or customize.  Then ./configure

# ./configure --prefix=/usr/local/python2.7

–prefix tells the configure script to install python into /usr/local/python2.7/ to create a completely separate parallel installation next to python 2.4.

Because of a mod_wsgi error that you will run into later, you should install the following dependencies before installing python:

# yum install readline-devel
# yum install gdbm-devel
# yum install sqlite-devel

After installing the dependencies, you can run ./configure again after you do a # make clean.  This will get rid of the old config file and generate a new one.

# make clean
# ./configure --prefix=/usr/local/python2.7

Assuming everything went well, build and install python 2.7

# make
# make install

// SETUP ENVIRONMENT VARIABLES

$ vim ~/.bashrc

Add the following to the bottom of .bashrc:

# User specific aliases and functions
alias python='/usr/local/python27/bin/python'

Log out, Log back in, and you should be able to execute the new Python 2.7

$ python
Python 2.7 (r27:82500, Mar 22 2011, 13:20:42)

// INSTALLING PIL (PYTHON IMAGING LIBRARY)

At this point, if you install PIL without first satisfying dependencies, PIL will be built without libjpeg and zlib (png support).  The output of python setup.py install would be:

*** TKINTER support not available
*** JPEG support not available
*** ZLIB (PNG/ZIP) support not available
*** FREETYPE2 support not available
*** LITTLECMS support not available

Unfortunately, PIL doesn’t complain very loudly and will still install a working version that will not be able to handle .jpg or .png files.  If you install PIL without the header libraries for the dependencies present, you will receive the following error in django’s admin when trying to upload a file:

Upload a valid image. The file you uploaded was either not an image or a corrupted image.

You can further verify if the proper support is compiled in from the shell:

$ python
>>> from PIL import Image
>>> i = Image.open("/path/to/some/image.jpg")
>>> i.verify()
>>> i.load()
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/usr/local/python2.7/lib/python2.7/site-packages/PIL/ImageFile.py", line 189, in load
d = Image._getdecoder(self.mode, d, a, self.decoderconfig)
File "/usr/local/python2.7/lib/python2.7/site-packages/PIL/Image.py", line 385, in _getdecoder
raise IOError("decoder %s not available" % decoder_name)
IOError: decoder jpeg not available

You can see from the above error that the jpeg decoder is not available.  If you’ve already installed PIL, uninstall it.  If you havn’t installed PIL yet, this will save you a lot of time (:

# yum install zlib zlib-devel
# yum install libjpeg libjpeg-devel
# yum install freetype freetype-devel

Django relies heavily on the Python Imaging Library PIL.  Again in our /root/Source/ directory, install PIL

# wget http://effbot.org/downloads/Imaging-1.1.7.tar.gz
# tar xvfz Imaging-1.1.7.tar.gz
# cd Imaging-1.1.7
# python setup.py build_ext -i

Check to make sure that libjpeg and zlib were found:

*** TKINTER support not available
--- JPEG support available
--- ZLIB (PNG/ZIP) support available
--- FREETYPE2 support available
*** LITTLECMS support not available

Run a test to make sure that everything works:

# python selftest.py
--------------------------------------------------------------------
PIL 1.1.7 TEST SUMMARY
--------------------------------------------------------------------
Python modules loaded from ./PIL
Binary modules loaded from ./PIL
--------------------------------------------------------------------
--- PIL CORE support ok
*** TKINTER support not installed
--- JPEG support ok
--- ZLIB (PNG/ZIP) support ok
--- FREETYPE2 support ok
*** LITTLECMS support not installed
--------------------------------------------------------------------
Running selftest:
--- 57 tests passed.

And finally, install PIL

# python setup.py install

You should now be able to import PIL inside of python:

$ python
>>>import PIL
>>>

// INSTALLING APACHE

Next we have to install our web server, Apache.  Theres a pretty straight forward tutorial on this here.

# yum install httpd
# /sbin/chkconfig httpd on
# /etc/init.d/httpd start
Starting httpd:                                            [  OK  ]

At this point, you should spend some quality time with /etc/httpd/conf/httpd.conf to really squeeze some power out of apache.

// INSTALLING MOD_WSGI

mod_wsgi is the link between apache and django.  It is responsible for taking the web request from apache, and getting it to your django app for handling.  The mod_wsgi installation docs are a great resource, they can be found here.

First, we need to install the source code for apache, as mod_wsgi needs it to build.  Install the httpd-devel package, which will install the headers for apache.

# yum install httpd-devel

Get and install mod_wsgi, again from /root/Source/

# wget http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz
# tar -zxvf mod_wsgi-3.3.tar.gz
# cd mod_wsgi-3.3
# ./configure --help
# ./configure --with-python=/usr/local/python27/bin/python
# make
# make_install

// INSTALLING PHPMYADMIN

PhpMyAdmin is a web interface for controlling your MySQL database.  The RPM for PhpMyAdmin is in the rpmforge repo, so we will add that repo to yum.  Again from /root/Source/:

# wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.i386.rpm
# rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
# rpm -K rpmforge-release-0.5.2-2.el5.rf.*.rpm
# rpm -i rpmforge-release-0.5.2-2.el5.rf.*.rpm
# yum search phpmyadmin
# yum install phpmyadmin

Setup the PHP Cookie

# vim /usr/share/phpmyadmin/config.inc.php

Add the Python Shared Libraries

# vim /etc/ld.so.conf.d/python2.7.conf

add the following line:

/usr/local/python2.7/lib

// INSTALLING DJANGO

The django install docs can be found here.

# wget http://www.djangoproject.com/download/1.3/tarball/
# tar xzvf Django-1.3.tar.gz
# cd Django-1.3
# python setup.py install
$ python
>>> import django
>>>

// POINT APACHE AT DJANGO USING MOD_WSGI
First, you need to tell apache which version of python to use so it doesn’t use the built in 2.4

# vim /etc/httpd/conf/httpd.conf

Add the following to the bottom of the file

#Python Versioning Control for mod_wsgi
WSGIPythonHome /usr/local/python2.7

Then restart apache

# /etc/init.d/httpd restart

Now you can configure your virtual hosts in apache to point to a ‘django.wsgi’ file thats specific to your django project. Add the WSGIScriptAlias to your Virtual Host

WSGIScriptAlias / /path/to/your/django/project/django_project_name/apache/django.wsgi

Add the ‘apache’ directory to your django project, and copy the following into django.wsgi inside of the apache folder

import os
import os.path
import sys

sys.path.append('/path/to/project/root')

os.environ['PYTHON_EGG_CACHE'] = '/path/to/a/directory/for/egg_cache'
os.environ['DJANGO_SETTINGS_MODULE'] = 'your_django_project_name.settings'

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

If you’ve made it this far, you should have a working django install.

Example Context: Lets say you have a Person class and an Event class.  Now you want to have people be able to RSVP to Events.  In this case, the RSVP will be the Intermediary Model that links a Person to an Event and stores extra information about the link.  Here is what the classes would look like:

class Person(models.Model):
    name        = models.CharField(max_length=200)
    image       = models.ImageField(upload_to="person_images", blank=True)
    RSVPList    = models.ManyToManyField(Event, through='RSVP')

    def __unicode__(self):
        return self.name

class Event(models.Model):
    name        = models.CharField(max_length=200)
    date        = models.DateTimeField()

    def __unicode__(self):
        return self.name

class RSVP(models.Model):
    person      = models.ForeignKey(Person)
    event       = models.ForeignKey(Event)
    attending   = models.CharField(max_length=20, default='maybe')

    def __unicode__(self):
        return self.attending

The Event class is autonomous, it doesn’t have a relationship to anything, and exists solely to hold information that defines events.

The Person class has a ManyToMany relationship to Event.  This allows a single Person to RSVP to multiple Events.  RSVPList will provide a list of all the Events a single Person object has RSVP’d to.  The magic starts with through=’RSVP’.  This tells django that the RSVP class will define extra information about the relationship between a single Person and a single Event.

The RSVP class has a single ForeignKey to a Person object and an Event object, defining a specific relationship between the two objects while enforcing that a single Person can only have one RSVP to any single Event.  In the example, we have added the ‘attending’ attribute that will store extra information about the related Person and Event objects.  You can add as many extra attributes as you like that define extra information about the individual Person and Event.

The model defines a DB table that functions kind of like this:

Stay tuned, in Part 2 I will go over the view code that shows how to instantiate the RSVP object and attach it to a Person and Event.

Since viewers of a page already had the ability to post that page to Facebook, I wanted to give them the ability to Tweet about it as well.

Solution: Twitter provides http://twitter.com/share for you to call directly. By using the share function, we can allow users to post to their twitter feed without anything more than a single line of code. Twitter will handle authentication in the popup themselves. I put this in a popup window using window.open() so that my website will stay open in the background.

<a onclick="window.open('http://twitter.com/share?text=Check%20out%20this%20Super%20Cool%20Website&amp;url=http://cloudcreativegroup.com/{{ page.slug }}','C2G','menubar=no,width=550,height=450,toolbar=no'); return false;" href="#">Tweet this page</a>

The {{ page.slug }} variable is a django variable that puts a link directly to the current page. It can be removed to point to a static page, or generated with PHP if your site is written in PHP. One of the cool things about the share function is that it automatically uses a URL shortener for you, so all you have to do is provide the full URL.

As always, you can replace the “Tweet this page” text with a cool Twitter image.