There’s a big difference between a Facebook Group and having your own clubhouse. A Facebook Group is like the Teen Paranormal Romance section of Barnes & Noble. It’s just a specialty area within Facebook that ultimately belongs to Facebook.

A Facebook Group doesn’t really belong to you. It belongs to the store it is a part of, and you can visit all you like during business hours as long as you don’t disturb the other customers, and maybe buy something every once in a while.

But when you build your own space with forum software, it truly does belong to you. You get your clubhouse, built exactly the way you and your friends wanted, with whatever rules and norms your community deems appropriate.

I was fascinated to read exactly this metaphor in Mehan Jayasuriya’s NYU master’s thesis Online, Underground: The Untold Story of the Original Social Media Revolution (pdf).

I came of age in Racine, Wisconsin, a rust-belt town of roughly 70,000 people that had once been a regional manufacturing hub. By the time I was a teenager, in the late 1990s, the town had fallen on hard times, its downtown filled with empty storefronts and boarded-up windows. Like most American teenagers who grow up outside of major urban areas, my friends and I spent our free time bored out of our skulls, aimlessly wandering a landscape that had little to offer us in the way of culture.

That all changed when we discovered punk rock, an art form that seemed to give voice to our suburban frustration, angst and boredom. It helped that punk culture was accessible to us in nearly every way: the music was easy to play, the CDs were affordably priced (unlike the major-label releases sold at the local mall), the shows were inclusive and cheap to attend. Soon, we were playing in punk bands, buying records via mail order and sneaking out to attend shows. There was just one problem: in order to do most of this, we had to drive to Milwaukee, the closest midsize city. Live music, to the extent that it could be said to exist in Racine, was the exclusive domain of adults, something that happened in the back rooms of a handful of dank bars. Why couldn’t we have an all-ages arts space in Racine, one that could serve as the locus of our budding punk community?

There were, of course, a number of reasons why such a thing didn’t exist. Luckily, being teenagers, none of us had the good sense to assess the practicality of our idea. Soon, a couple of enterprising friends had pooled together a few hundred dollars and found a landlord willing to rent a vacant downtown storefront to a group of minors. The Tokyo-A-Go-Go was born.

I can still recall the shared sense of excitement we felt once the bare-bones space — essentially, a concrete-walled room outfitted with a cheap PA system — was up and running. Racine bands finally had a place to play in their own hometown and local kids finally had a place to hang out, hand out flyers and political tracts and discuss the unimportant matters of the day. Best of all, it was a space that members of our community had built without any outside help and subsequently, one where we all felt a collective sense of ownership. The venue’s coronation came when some touring bands from out of state scheduled a stop in Racine to play at the venue. Surely, this was a sign that we had built something of lasting value.

Of course, we hadn’t. As you might already have guessed, the Tokyo-A-Go-Go didn’t last very long. If I remember correctly, it was gone in a matter of weeks. To this day, there are conflicting reports about what finally did in the venue. Some say that a building inspector showed up and demanded that the place be shut down immediately. Others pinpoint the night that a kid accidentally pushed a friend through the room’s front window as the moment the experiment ended (despite their initial fundraising success, the kids who ran the club were, apparently, unable to raise enough money to repair the window).

Whatever the reason for its demise, the Tokyo-A-Go-Go taught us all a valuable lesson. If the cost of building something is low enough and the benefits of building it are great enough, you can simply build it yourself. This is, of course, the equation that so many bored kids who came before had arrived at, the “do it yourself” or “DIY” ethos on which punk culture was built. It doesn’t matter how small or how niche your community is — if that community wants its own space badly enough, it will find a way build it. Of course, this is easier done in places like Racine, Wisconsin where the transaction costs of setting up shop are low and the benefits, in providing a home to a community that lacks one, are high.

I was reminded of this lesson a few years later when I started spending a lot of time on online messageboards. This was the early 2000s, when it was becoming increasingly easy to find vibrant online communities dedicated to seemingly any topic. Such messageboards provided me with virtual spaces not unlike the Tokyo-AGo-Go, places where like-minded people would congregate to discuss shared interests. However, unlike the Tokyo-A-Go-Go, messageboards allowed me to connect with people in other small towns or even big cities, to gauge what was considered cool in other parts of the country or world, to feel as if I was a part of a much larger community. It was like stepping into a stadium-sized version of the Tokyo-A-Go-Go, one that was populated by people from all around the globe.

I honestly go in expecting the worst from a lot of dry, academic studies but this one is unusually genuine and heartfelt. If you liked the above excerpt, download the PDF and give it a deeper read.

Mehan’s history of the online messageboard captures a lot of what I love about the Discourse project, and underscores our effort to ensure that these amazing communities have great 100% free open source forum software to rely on — now and forever.

There are six servers here, all variously numbered Tie Fighters — derived from our internal code name for the project while it was a secret throughout 2012. As you read below, bear in mind that most of the work in hosting www.discourse.org is carried out by Tie Fighters 2, 3, 4 and 5.

Tie Fighter 1

This is a very beefy server that we bought first with the idea that we’d do a lot of virtualization on one large, expensive, many-core server.

• Intel Xeon E5-2680 2.7 GHz / 3.5 GHz 8-core turbo
• 128 GB DDR3 1333MHz ECC Reg (8 x 16GB)
• 2 × Intel 710 Series 100 GB SSD in RAID 1
• 6 × Seagate Constellation 1 TB 2.5″ HDD in RAID 10
• LSI 3Ware 9750 8i SAS RAID Controller

Specs:

• 8 x 2.5″ hot-swap drive bays
• Dual gigabit ethernet
• Integrated IPMI 2.0 ethernet
• 330W gold efficiency power supply
• SuperMicro X9SRE-3F mobo
• SuperMicro 1017R-MTF case

We didn’t build this one, but purchased it from PogoLinux where it is known as the Iris 1168.

Tie Fighter 2, 3, 4, 5

Turns out that Ruby is … kind of hard to virtualize effectively, so we ended up abandoning that big iron strategy and going with lots of cheaper, smaller, faster boxes running on bare metal. Hence these:

• Intel Xeon E3-1280 V2 Ivy Bridge 3.6 Ghz / 4.0 Ghz quad-core turbo
• 32 GB DDR3 1600MHz ECC Reg (4 x 8 GB)
• 2 × Samsung 830 512 GB SSD in software mirror

Specs:

• 4 x 2.5″ hot-swap drive bays
• Dual gigabit ethernet
• Integrated IPMI 2.0 ethernet
• 330W gold efficiency power supply
• SuperMicro X9SCM-F-O mobo
• SuperMicro CSE-111TQ-563CB case

I built these four, which I documented in Building Servers for Fun and Prof… OK, Maybe Just for Fun. It’s not difficult, but it is a good idea to amortize the build effort across several servers so you get a decent return for your hours invested.

Tie Fighter 10 and 11

Finally, we realized that we needed a special routing server to handle HAProxy routing duties. Redundancy is essential for a router, because if this thing goes down, nothing will be accessible. So we looked into a “twin” server that has two complete servers inside sharing one power supply. Each one has the following specs:

• Intel Xeon E5606 2.13 GHz quad-core
• 6 GB DDR3 1333 MHz ECC Reg (3 x 2 GB)
• 2 × Intel 520 60 GB SSD in software mirror

Specs:

• 2 x 3.5″ hot-swap drive bays
• Dual gigabit ethernet
• Integrated IPMI 2.0 ethernet
• 1200W gold efficiency power supply (shared)
• SuperMicro X8DTT motherboard
• SuperMicro 808T-1200B twin case

We didn’t build this one either, we also purchased it from PogoLinux where it is known as the Iris 1125.

What about redundancy?

We have good live redundancy with Tie 1 – 5; losing Tie 3 wouldn’t even be noticed from the outside. The most common failure points for servers are hard drives and PSUs, so just in case, we also keep the following “cold spare” parts on hand, sitting on a shelf at the bottom of the rack:

• Intel 710 100 GB SSD spare for Tie 1
• Seagate Constellation 1 TB 2.5″ spare for Tie 1
• Samsung 830 512 GB SSD spare for Tie 2 – 5
• Intel 520 60 GB SSD spare for Tie 10 + 11
• SuperMicro 1200W spare PSU for Tie 10 + 11
• SuperMicro 330W spare PSU for Tie 1 – 5

It’s OK for the routing servers to be different, since they are almost fixed function devices, but if I could go back and do it over again, I’d spend the money we paid for Tie 1 on three more servers like Tie 2 – 5 instead. The performance would be better, and the greater consistency between servers would simplify things.

Networking

We use an Asus RT-N16 router (with WiFi disabled and antennas detached) flashed with TomatoUSB as an inexpensive, open source OpenVPN access box to all the IPMI KVM-over-Internet dedicated ethernet management ports on each server. IPMI 2.0 really works!

The networking duties are handled by two rack mounted NetGear GS724T-300 ProSafe 24-port gigabit ethernet smart switches. One is simply standing by in the rack as a hot spare, because if the switch fails, we’d really be screwed.

But… is it webscale?

During our launch peak loads, the servers were barely awake. We are ridiculously overprovisioned at the moment, and I do mean ridiculously. But that’s OK, because hardware is cheap, and programmers are expensive. We have plenty of room to scale for our partners and the eventual hosting service we plan to offer. If we do need to add more Tie Fighters, we still have a ton of space in the full rack, and ample power available at 15 amps. These servers are all Sandy and Ivy Bridge CPUs, so all quite efficient — the whole rack uses between 3 and 4 amps in typical daily work.

As for software, we’re still hashing out the exact configuration details, but I’ll be sure to post a future blog entry about that too. I can tell you that all our servers run Ubuntu Server 12.04 LTS, and it’s working great for us!

Discourse has a great, supportive community on GitHub and meta.discourse, and we’re here to help. This is our first guide to setting up a local Ruby on Rails environment, custom tailored to begin dabbling in Discourse.

Step 1: VirtualBox

For those who don’t do it on a regular basis, It can be intimidating to set up a *nix flavored environment. For us, the path of least resistance lies in the safety of a Virtual Machine, a doorway into an entirely different operating system. We recommend VirtualBox. It’s free, open source, and runs on Windows, Linux, Mac and Solaris. Download a copy from the VirtualBox site here:

www.virtualbox.org/wiki/Downloads

As of this writing, 4.2.10 is the latest and works for us. After you’ve downloaded and installed it, there are a couple of things to know which will help your VM’s performance.

1. Use a Solid State Drive (SSD). A VM emulates an entire system. There’s a performance cost to this emulation, a little in CPU and memory, but mostly in disk I/O. You can get big improvements in VM speeds by moving from traditional disks to a solid state drive.

2. Have two drives. If you install VirtualBox to run from your primary drive, and you run a VM that also resides on that primary drive, they’re going to fight for hard drive resources. The more your primary disk is tied up, contending between the management of resources necessary to run VirtualBox and the emulated resources inside the VM, the slower your performance is going to be. If you can, try keeping your working directory (of Discourse and the VM) off of the primary disk. In a perfect world, your secondary disk would also be a SSD!

3. Increase the VM memory. The VM image we set up defaults to 1 GB of memory, which makes it friendly to run on 4 GB machines. But this is the practical minimum — performance will be a lot better if you can ramp the VM memory up to 2 GB or even 4 GB. To do so, change your system’s DISCOURSE_VM_MEM environment variable to the desired amount of memory.

Also, we recommend a development machine with about 8 GB of physical memory. VMs are hungry and eat ram like Hippos eat marbles.

Step 2: Vagrant

With VirtualBox installed, it’s now time to bring a VM to life. Discourse maintains all the information necessary to wire up a VM within the Discourse codebase itself!

It does this through the magic of Vagrant, another free open-source tool which is used to both package and initialize a VM with all the necessary configurations in place. Thanks to Vagrant, there’s no need to figure out if you have the correct version of Ruby, or if Rails is up-to-date, or even how to install nginx, thin, or any of the other bits and pieces that make up Discourse.

It’s all in Vagrant, stored within the Vagrantfile, and comes up with with the ease of a single command line. For the purposes of working with Discourse, you’ll need Vagrant 1.1.2 or higher. Download it from the Vagrant download page:

downloads.vagrantup.com

Install should be self-explanatory. Go ahead and do that now. We’ll wait.

Step 3: Git

Source control is vital, not only as a means of tracking changes and protecting yourself from change, but also perhaps more importantly as a way to make collaboration and contribution easy.

First timers to Git can find it is a bit intimidating, even if you have previous experience with Subversion et al. If you want the easiest experience to start, we recommend the official GitHub clients:

• GitHub for Windows
• GitHub for Mac

Once installed, head to the Discourse repository on GitHub and click the Clone in Windows / Mac button:

This will pull a copy of the repo down to your machine, and your GitHub tool will load it into its local repositories. Clicking on the “repositories” section on the left, under “local” will take you to all your cloned repos. To peek inside the repo, click the blue arrow, just to the right of the thumbtack:

The complexities of Git will need an entirely new blog post, so we’ll leave that to the experts. For now, three tips:

1. If possible, set up your working folder on a disk other than where you installed VirtualBox. Do this through the tools option along the top of the GitHub application (look for the gear icon in the screenshot above).

2. Hover over the repo to see the current working folder for the project:

   
   

3. To open a command shell in the project, right click the project and select open a shell here, or use the project tools (gear icon) menu again.

Keep those last two points in mind, because you’ll need them for the next section!

Now that you have cloned the Discourse project locally, you also have our official Vagrant configuration along with it. This will drive the VM in VirtualBox. Let’s put all the pieces of this puzzle together, shall we?

Step 4: Running the VM and Connecting to It

Using the GitHub for Windows or Mac tools (gear) menu for the project, select open a shell here.

This will give you a command prompt at the current project folder. From there, type:

vagrant up

This will kick the VM into motion. Vagrant will connect to the official Discourse site, download the VM image we’ve prepared (note: this may take a while), extract it, and enable all the subsystems necessary to bring the environment to life. VirtualBox may prompt you a few times, so go ahead and accept its requests.

Once the VM is up, you’ll be back at the command prompt.

Now, it’s time to connect to the VM and start up the Rails server. From the shell you already have open in the project folder, type:

vagrant ssh

Once inside, a few more commands is all it will take. Change to the vagrant directory:

cd /vagrant

Now it’s time to interact with Ruby on Rails. Invoke the Rails installer, like so:

bundle install

Next, tell Ruby on Rails to migrate the development database schema into your local repo. We do this via rake, which is Ruby’s version of make, boasting Ant-like features.

bundle exec rake db:migrate

At long last, it’s time to bring up the Rails server, ready to accept HTTP requests.

bundle exec rails s

Our VM config causes this Rails server to begin listening for requests on port 4000. So once the server is up, open up a web browser on your local workstation and navigate to http://localhost:4000

Voila! As you can see in the screenshot above, Discourse is indeed running locally off of port 4000, and in the background, you can see the guts of Discourse working away within the SSH client that you used to launch the server.

The initial request may take a while as Discourse begins to initialize its subsystems and start the caching processes; first page loads of 5 to 10 seconds are not uncommon. However, if you’re seeing page load times well beyond this, let us know what your PC configuration is. The Discourse community is actively looking for tweaks and improvements for better VM performance.

Step 5: Shutting Down

When you’re done for the day, Ctrl+C will kill the Rails server, exiting you back to the command prompt from within the VM. To finish up, type:

exit
vagrant halt

This will exit your SSH session, then end the VM and free up its resources.

Congratulations! You now have a working copy of Discourse, ready for you to hack away at any time, and a complete Ruby on Rails environment to facilitate said hacking.

Now go forth and hack — and please consider contributing any cool stuff you build back to the project as pull requests!