I’ve touched on google_authenticator and pam_yubico for authentication in a previous post however I will be going into this in a bit more detail.

Taking a machine at home as an example. My requirements are simple

In order to meet these requirements I’m going to need the following

The server is running Archlinux, and luckily all of these are within AUR – and as such I’m not going to cover the install of the modules.

In order to restrict SSHd access as above I need the following auth lines in /etc/pam.d/sshd

# Check unix password
auth            required        pam_unix.so try_first_pass
# check to see if the User/IP combo is on the skip list - if so, skip the next two lines
auth            [success=2 default=ignore] pam_access.so accessfile=/etc/security/access_yubico.conf
# Check /etc/yubikey for the users yubikey and skip the next line if it all works
auth            [success=1 default=ignore ]     pam_yubico.so id=1 url=https://api.yubico.com/wsapi/2.0/verify?id=%d&otp=%s authfile=/etc/yubikey
# Check against google authenticator
auth            required        pam_google_authenticator.so
auth            required        pam_env.so

The next step is ensure that the relevant users and IP are listed in /etc/security/access_yubico.conf

# Allow welby from 1.2.3.4
+ : welby : 1.2.3.4
# Deny all others
- : ALL : ALL

After this is setup we will also need to setup the yubikey file /etc/yubikey

welby:ccccccdddddd:cccccccccccc

I’m not going to cover configuration of google authenticator with the google-authenticator command

The final changes are to the /etc/ssh/sshd_config ensuring that the following are set

PasswordAuthentication no
PubkeyAuthentication no
PermitRootLogin no
ChallengeResponseAuthentication yes
UsePAM yes

For a small business or ‘Prosumer’ (professional consumers) the market incumbent (RSA) is not a viable option due to the price of the tokens and the software / appliance that is required. There are cheaper (or free!) alternatives for which two that I’ve used at Google Authenticator, and Yubikey.

Google Authenticator is an OATH-TOTP system that much like RSA generates a one time password once every 30 seconds. It’s avaiable as an App for the Big three mobile platforms (iOS, Android and Blackberry).

Yubikey is a hardware token that emulates a USB keyboard, that when the button is pressed, generates a one time password. This is supported by services such as lastpass.

Both solutions have the ability to be used with their own PAM modules. Installation of either is simple, but what happens if you want to use both, but only require one of these.

Luckily PAM makes it quite easy !

auth            required        pam_unix.so try_first_pass
auth            [success=1 default=ignore ]     pam_yubico.so id=1 url=https://api.yubico.com/wsapi/2.0/verify?id=%d&otp=%s
auth            required        pam_google_authenticator.so

In the above example the user must enter a password and then provide either their yubikey or their google_authenticator.

Should the password be incorrect the user will still be prompted for their yubikey or google authenticator, but will then fail. Should they provide a password and then their yubikey, they will not be asked for their google authenticator. Should they provide password and not a yubikey, they will be prompted for their google authenticator!

For example

pvdisplay -m
--- Physical volume ---
PV Name /dev/sdb1
VG Name INTEL_RAID
PV Size 2.73 TiB / not usable 4.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 714539
Free PE 0
Allocated PE 714539
PV UUID XWiRzE-Ol3d-38En-ND6b-qo93-4zeF-xv8zDv

--- Physical Segments ---
Physical extent 0 to 604876:
Logical volume /dev/INTEL_RAID/MEDIA
Logical extents 0 to 604876
Physical extent 604877 to 617676:
Logical volume /dev/INTEL_RAID/backups_mimage_0
Logical extents 25600 to 38399
Physical extent 617677 to 617701:
Logical volume /dev/INTEL_RAID/EPG
Logical extents 0 to 24
Physical extent 617702 to 643301:
Logical volume /dev/INTEL_RAID/backups_mimage_0
Logical extents 0 to 25599
Physical extent 643302 to 714538:
Logical volume /dev/INTEL_RAID/MEDIA
Logical extents 604877 to 676113

--- Physical volume ---
PV Name /dev/sdc1
VG Name INTEL_RAID
PV Size 2.04 TiB / not usable 2.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 535726
Free PE 430323
Allocated PE 105403
PV UUID laOuKy-5FZa-cJ3h-JffV-qUub-diKC-O0wVqK

--- Physical Segments ---
Physical extent 0 to 25599:
Logical volume /dev/INTEL_RAID/backups_mimage_1
Logical extents 0 to 25599
Physical extent 25600 to 54202:
Logical volume /dev/INTEL_RAID/MEDIA
Logical extents 676114 to 704716
Physical extent 54203 to 67002:
Logical volume /dev/INTEL_RAID/NZB_DOWNLOAD
Logical extents 0 to 12799
Physical extent 67003 to 79802:
Logical volume /dev/INTEL_RAID/backups_mimage_1
Logical extents 25600 to 38399
Physical extent 79803 to 105402:
Logical volume /dev/INTEL_RAID/OLD_VM
Logical extents 0 to 25599
Physical extent 105403 to 535725:
FREE

From here you can see that /dev/INTEL_RAID/MEDIA is a Logical Volume (LV) on both PVs within the VG. If I was wanting to grow my mirrored LV, which requires space on both PVs, I’d have to migrate some of the extents of another LV. If I wanted to move some of the MEDIA lv, I should be able to do the following

pvmove /dev/sdb:643302-714538 /dev/sdc

This will move extents 643302-714538 to the next contiguious block on /dev/sdc

I’ve been using Asterisk for years (I remeber the 0.7 release) and have implemented it for companies before, usually with no issues, baring the continuall deadlocks in the 1.2 range. Recently I enabled my VoIP network segment for IPv6 only to find that GTalk stoped working on IPV6 Day. After a bit of digging about, it seems that Asterisk 1.8 does support IPV6! But, gtalk and similar are not supported, SIP is infact the only first class citezen it seems.

I’ve toyed with using freeswitch before, but unfortuantly have had varied sucsess with FreeTDM to Dahdi with BT caller ID and the likes. I did hack in support for it, but I’m not too sure if I trust my code, as my C is quite rusty to say the least.

I did however come up with another solution!

As I’m running a moderatly new Linux Kernel I can use LXC – Linux Containers – which are effectilvy the same idea as a wpar, chroot, openvz, whatever. After setting up asterisk in the LXC I needed to expose my Dahdi card to it. LXC allows you to restrict access on a per device basis. I’ve setup Dahdi on the host machine as normal so the kernel modules can be loaded etc. Once this is done I’ve preformed the following within the LXC

cd /
mkdir dev/dahdi
mknod dev/dahdi/1 c 196 1
mknod dev/dahdi/2 c 196 2
mknod dev/dahdi/3 c 196 3
mknod dev/dahdi/4 c 196 4
mknod dev/dahdi/channel c 196 254
mknod dev/dahdi/ctl c 196 0
mknod dev/dahdi/pseudo c 196 255
mknod dev/dahdi/timer c 196 253
mknod dev/dahdi/transcode c 196 250

This creates the Device nodes within /dev/ for my 4 dahdi channels (3FXS 1FXO if anyone is interested). After this I’ve added the following to the lxc config file, to allow the LXC to have access to these devices


# If you want to be lazy just add this line
#lxc.cgroup.devices.allow = c 196:* rwm

#Otherwise use the following
lxc.cgroup.devices.allow = c 196:0 rwm
lxc.cgroup.devices.allow = c 196:1 rwm
lxc.cgroup.devices.allow = c 196:2 rwm
lxc.cgroup.devices.allow = c 196:3 rwm
lxc.cgroup.devices.allow = c 196:4 rwm
lxc.cgroup.devices.allow = c 196:250 rwm
lxc.cgroup.devices.allow = c 196:253 rwm
lxc.cgroup.devices.allow = c 196:254 rwm
lxc.cgroup.devices.allow = c 196:255 rwm

This will obviously only work for the first 4 dahdi channels, but if you need more, just continue adding the 196:x lines, replacing x with the channel number, and also ensuring that you create the device nodes in the same way

As Rackspace have recently launched a ‘beta’ Cloudfiles service within the UK I thought I would run a few tests to compare it to Amazon’s S3 service running from Eire (or Southern Ireland).

I took a set of files, totalling 18.7GB, with file sizes ranging from between 1kb and 25MB, text files, and contents being mainly Photos (both JPEG and RAW (cannon and nikon), plain text files, GZiped Tarballs and a few Microsoft Word documents just for good measure.

The following python scripts were used:

Cloud Files
Upload

import cloudfiles
import sys,os
 
api_username="USERNAME"
api_key="KEY"
auth_url="https://lon.auth.api.rackspacecloud.com/v1.0"
dest_container="CONTAINER"
local_file_list = sys.stdin.readlines()
cf = cloudfiles.get_connection(api_username, api_key, authurl=auth_url)
containers = cf.get_all_containers()
for container in containers:
    if container.name == dest_container:
            backup_container = container
 
def upload_cf(local_file):
    u = backup_container.create_object(local_file)
    u.load_from_filename(local_file)
 
for local_file in local_file_list:
        local_file = local_file.rstrip()
        local_file_size = os.stat(local_file).st_size/1024
        print "uploading %s (%dK)" % (local_file, local_file_size)
        upload_cf(local_file)

Download

api_username="USERNAME"
api_key="KEY"
auth_url="https://lon.auth.api.rackspacecloud.com/v1.0"
dest_container="CONTAINER"
 
 
import cloudfiles
import sys,os
 
#Setup the connection
cf = cloudfiles.get_connection(api_username, api_key, authurl=auth_url)
 
#Get a list of containers
containers = cf.get_all_containers()
 
# Lets setup the container
for container in containers:
    if container.name == dest_container:
            backup_container = container
 
#Create the container if it does not exsit
try:
    backup_container
except NameError:
    backup_container = cf.create_container(dest_container)
 
# We've now got our container, lets get a file list
def build_remote_file_list(container):
    remote_file_list = container.list_objects_info()
    for remote_file in remote_file_list:
        f = open(remote_file['name'],'w')
        rf = container.get_object(remote_file['name'])
        print remote_file['name']
        for chunk in rf.stream():
            f.write(chunk)
        f.close()
remote_file_list = build_remote_file_list(backup_container)

s3
Upload

from boto.s3.connection import S3Connection
from boto.s3.key import Key
import sys,os
 
dest_container = "CONTAINER"
 
s3 = S3Connection('api','api_secret')
 
buckets = s3.get_all_buckets()
 
for container in buckets:
    if container.name == dest_container:
                backup_container = container
 
def build_remote_file_list(container):
    remote_file_list = container.list()
    for remote_file in remote_file_list:
        print remote_file
        f = open(remote_file,'w')
        rf = container.get_key(remote_file)
        #print remote_file['name'
        rf.get_file(f)
        f.close()
 
local_file_list = sys.stdin.readlines()
 
def upload_s3(local_file):
    k = Key(backup_container)
    k.key = local_file
    k.set_contents_from_filename(local_file)
 
for local_file in local_file_list:
        local_file = local_file.rstrip()
        local_file_size = os.stat(local_file).st_size/1024
        print "uploading %s (%dK)" % (local_file, local_file_size)
        upload_s3(local_file)

Download

from boto.s3.connection import S3Connection
from boto.s3.key import Key
import sys,os
 
dest_container = "CONTAINER"
 
s3 = S3Connection('api','apt_secret')
 
buckets = s3.get_all_buckets()
 
for container in buckets:
    if container.name == dest_container:
                backup_container = container
 
def build_remote_file_list(container):
    remote_file_list = container.list()
    for remote_file in remote_file_list:
        print remote_file.name
        f = open(remote_file.name,'w')
        rf = container.get_key(remote_file.name)
        #print remote_file['name'
        rf.get_file(f)
        f.close()
 
 
remote_file_list = build_remote_file_list(backup_container)

The test was preformed from a Linux host which has a 100MBit connection (Uncapped/unthrottled) in London, however the test was also preformed with almost identical results from a machine in Paris (also 100mbit). Tests were also run from other locations (Dallas Fort Worth – Texas, my home ISP (bethere.co.uk)) however these locations were limited to 25mbit and 24mbit , and both reached their maximum speeds. The tests were as follows:

The average speeds for the tests are as follows:
Cloudfiles
Download: 90Mbit/s
Upload: 85MBit/s
S3 Ireland
Download: ~40Mbit/s
Upload : 13Mbit/s

Observations

Below is a graph showing the different connection speeds achieved using CF & S3

As mentioned before this is a very unscientific test (and I’d say that these results have not been replicated from as many locations or as many times as I’d like to, so I would take them with a pinch of salt) , but it does appear that Rackspace cloudfiles UK is noticeably faster than S3 Ireland

One thing that I did quite want was to have my SMS messages migrated from my iPhone to the Desire. As the iPhone keeps the SMSes in a SQLite DB this wasn’t to hard. I’m going to post the procedure and the script I used later!