Do you need to simulate file uploads while testing in Rails & RSpec? Well, It's easy to do. Let's pretend you're using rails 3.0.9 and you want to test uploading a picture, which will be stored as an record of an Image model. Let's also assume that you can pass an uploaded file directly to your model. Here's what your model might look like:

class Image < ActiveRecord::Base
  attr_accessor :file
  before_create :save file

  def save_file
    File.open(Rails.root.join('public', 'images', file.original_filename), 'w') do |file|
       file.write(file.read)
     end
  end
end

To simulate a file upload in your test, save a real file in a directory somewhere(we'll use spec/fixtures/images), and then create a new Image record and pass it a ActionDispatch::Http::UploadedFile object (which rails uses to handle uploaded files).

file = File.new(Rails.root + 'spec/fixtures/images/rails.png')
@image = Image.new(:file => ActionDispatch::Http::UploadedFile.new(:tempfile => file, :filename => File.basename(file))
file.close
@image.save

That's it! Now your Image record has a valid file, just like the real thing. If you're using factory_girl for testing, you can automatically create a record with a file already "uploaded" to it:

Factory.define :image do |o|
  file = File.new(Rails.root + 'spec/fixtures/images/rails.png')
  file.rewind
  o.file ActionDispatch::Http::UploadedFile.new(:tempfile => file, :filename => File.basename(file))
end

@image = Factory(:image)

Shorewall is a great little firewall that's excellent for use in many linux distributions. It is highly configurable and a great alternative to working with iptables directly. It's especially easy to install on debian-based distros such as ubuntu, mint, mepis, etc. I'll be using ubuntu in this tutorial. Be sure to perform the steps of this guide on the physical machine as root. If you're doing this over ssh/terminal, you may get locked out during the configuration process. Let's get started!

Step 1 - Install Shorewall

Let's switch to root and install Shorewall using apt:

su -
apt-get install shorewall

Step 2 - Configure

Shorewall can be used in several different firewall configurations. If your linux machine is a dedicated server used for services like Apache or Samba, you'll be using a 1-interface configuration. If your linux machine is going to act as a router and firewall to an internal network, you'll be using a 2-interface configuration, and so on. Let's pretend our server is used for hosting websites, so we'll set up a 1-interface Shorewall configuration.

Shorewall's configuration files are stored in /etc/shorewall. Shorewall also comes with several example configurations you can use to get up and running quickly. Let's copy over the 1-interface example configuration files to get things going:

cp /usr/share/doc/shorewall/examples/one-interface/* /etc/shorewall

This will copy several files over to /etc/shorewall. Let's learn more about what these files do. Shorewall uses several configuration files. Here's a brief summary of each one:

• zones - allows you to define specific zones that will used when defining policies and rules
• interfaces - specifies which hardware devices and settings are assigned to each zone 
• policy - contains general access rules and catchalls for traffic going to/from your zones
• rules - defines allowed/restricted protocols, ports, etc. that are allowed to/from your zones

The two most important files here are policy and rules. Let's take a look at the policy file:

#SOURCE         DEST            POLICY          LOG LEVEL       LIMIT:BURST
$FW             net             ACCEPT
net             all             DROP            info
# The FOLLOWING POLICY MUST BE LAST
all             all             REJECT          info 

$FW is your firewalled network, in our case it's the server. net is the internet. The last line is important because it's the catchall. It tells Shorewall to reject all traffic that it doesn't know how to handle.

Next, let's look at the rules file. This defines which ports and protocols shorewall will handle.

#############################################################################################################
#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE          
#                                                       PORT    PORT(S)         DEST            LIMIT         

# Drop Ping from the "bad" net zone.. and prevent your log from being flooded..
Ping(DROP)      net             $FW

# Allow the internet to connect to web server
ACCEPT          net             $FW             tcp     80

# Allow telnet and ssh, port range 22-23
ACCEPT          net             $FW             tcp     22:23

# Allow Outgoing SMTP Traffic on Multiple ports
ACCEPT          $FW             net             tcp     25,26,465,587

These rules will allow several types of traffic. Shorewall also comes with many handy macros(as seen with the Ping macro above) that predefine several different protocols and services. They're located in /usr/share/shorewall. You can also create your own macros.

Step 3 - Start 'er up

Once you have your configuration all set up, start Shorewall.

shorewall start

That's it! You're now safe and sound behind a firewall. Don't you feel better?

Additional Resources

This is just a tiny showcase of Shorewall's features. You can do many other cool things with it as well. Be sure to check out the links below.

• Shorewall Official Website
• Shorewall Configuration File Tips and Tricks
• Standalone Shorewall Firewall Guide
• Two-Interface Shorewall Firewall Guide

Gitolite is a git repository manager that lets users access git repositories on your server. The best part about gitolite is that you only need one linux user account, and you can change user access permissions to different repositories on the fly. You can also restrict access to a repository based on an individual commit, branch, tag, etc. This makes gitolite a great tool for corporate environments or if you want to allow a client to check out the latest source code you're developing for them.

Gitolite runs great on any linux server, such as Ubuntu, Mint, Mepis, Fedora, etc. This tutorial assumes you have git installed on your server and know how to use ssh and how SSH public key authentication works. In this tutorial, we'll be using two computers, the server(where all the repositories will be stored) and the workstation(where you will push/pull git repositories). I'm assuming that the workstation is also a unix/linux machine. Of course, you can use windows as well. Also, the workstation and server can be located on the same machine.

Step 1- Set up git user and create ssh public key

# On The Server
sudo useradd git # Create git user
sudo passwd git # Create git user's password. Remember This.
sudo su git # switch to git user 
echo "PATH=$HOME/bin:$PATH" > ~/.bashrc # Allows you to set up gitolite

# On Workstation as bob (This can also be a user on the same server as gitolite)
ssh-keygen # Generate follow steps, use NO password
scp ~/.ssh/id_rsa.pub git@[host]:bob.pub # copy your pubkey to the git user's home directory, this will be used when 
installing gitolite. Substitute "localhost" for [host] if bob is a user on the same machine as git.

Step 2 - Install gitolite

Now we're going to install gitolite from Sitaram's official github repository. Start by logging in as the git user on your server.

# Install gitolite
git clone git://github.com/sitaramc/gitolite.git
gitolite/src/gl-system-install # install gitolite 
gl-setup ~/bob.pub # use bob's pubkey so he can administer gitolite

Step 3 - Configure gitolite-admin

Gitolite administration is done in a git repository called gitolite-admin, stored in the git user's default repo directory(~/repositories). In order to make changes to gitolite, the administrator (bob) needs to clone this repository to his account, make the changes, and push them back to the server. As bob, Let's go ahead and do this.

git clone git@[host]:gitolite-admin.git

Since gitolite-admin is a git repository itself, you can administer it from multiple machines, and you can also specify who has administrative access to gitolite, just like any other repo. Nice!

Step 4 - Adding Users

Let's add a user to gitolite. This user will be named alice, and we're going to give her read access to the myrepo repository. Since all gitolite authentication is done with ssh public keys, alice will need to give you her public key. Let's assume you have placed her public key in a file called alice.pub, stored in your home directory.

cd ~/gitolite-admin # change to the gitolite admin repository
cp ~/alice.pub keydir # copy alice's public key to gitolite-admin

Next, let's specify alice's permissions in the gitolite configuration file, stored in conf/gitolite.conf:

repo myrepo
        RW+    =   bob # let bob read, write, and rewind
        R        =   alice

Save your changes to this file, make a commit, push your changes to gitolite, and you're done! Alice now has read access to the repository.

Cloning a repository for the first time

Since alice now has read access to myrepo, she needs to clone it to her workstation. Here's what alice will type in:

git clone [user]@[host]:[repo].git # ie: git clone git@myserver.com:myrepo.git

Limiting access to a specific branch, tag, etc.

You can also limit access to a repository based on a particular branch, tag, commit, etc.

repo @myrepo
    RW  alice$               = alice # let alice read/write to the 'alice' branch
    RW  ali-                = alice # let alice read/write to any branch that starts with 'ali' 
    RW  refs/tags/v[0-9]   = alice # let alice read/write to any tag v0-v9

This is just the tip of the iceberg! Gitolite allows you to use macros for user/repository groups, and much more. Be sure to check out the official documentation below.

Additional Resources

• Gitolite's Official Documentation
• Another Great Install Guide from Progit