almost effortless

Security audits are a necessity.

Unfortunately, due to the constantly changing array of exploits and threats coming at your Internet-facing server from all over the world, there's no best practices manual for a security audit. This is because no one knows exactly what level of openness is appropriate/optimal on a given application server.

But you gotta start somewhere. Because if you're just blithely running an un-hardened *nix server with stock configurations for service apps like Apache and ssh, you're pretty much giving away the store.

What follows is a short how-to dealing with how to get started, security-auditing-wise. It is by no means comprehensive and is only intended to provide a "leg up" for those who feel like they ought to be auditing their servers but aren't sure where to start. I'll be using Debian systems running the current stable release (i.e. Lenny) to demonstrate the techniques, but I'll try to keep things as OS agnostic as possible: most of the packaged software I describe below can be found in your generic, mainstream fedora repo.

The methodology will be to start from the outside and work inward. I recently saw a Linux Journal article that described doing things the opposite way (or at least that's the impression with which I was left), and that doesn't make much sense to me. From where I'm standing, it seems that if you're conducting a security audit, you ought to start out by looking at your server the same way everyone else does.

Accordingly, we'll begin from the outside and from as basic a perspective as possible: scanning ports and checking for known vulnerabilities and obvious mis-configurations. Once we've got a little perspective on how our server looks to the script kiddies and botnets of the world, we'll do some web-server specific scanning to attempt to detect vulnerable plugins, apache mis-configurations and application-level security holes. After that, we'll finish by checking for rootkits and doing some internal auditing.

OpenVAS: Port Probe and All-purpose scan
The first thing to do is to scan your ports.

The odds are good that if you've got a server out there on the Internet (in the DMZ of your intranet or in a hosting company's rack, for example) that it's got a bunch of open ports. You've probably got one or two listening for HTTP requests, one or two listening for SSH requests and so on. What you probably haven't got is a good idea of how those ports look to the world.

So the first part of any security audit is the portscan. In olden times, you'd use a combination of telnet and nmap for this: nmap would handle the port scanning and tell you which ports were listening/open and then you'd use your expert knowledge of various network protocols to use a telnet-like program to check out those ports and see what sort of access and information they were offering to the world.

There are, fortunately, labor-saving apps that will do the scanning and auditing for you. A few months back, you would have been using nessus, as it was the big name in F/OSS auditing. nessus, however, has gone commercial (proprietary and closed) and a new, open project (GPL) called OpenVAS has taken its place.

For anything other than security auditing, using commercial software is probably OK. At the very least it's not always counter-productive to use non-F/OSS for non-security-related tasks. In the case of security-related apps, however, it just doesn't make any sense to take a chance on using software that isn't available for public scrutiny.

At any rate, if you're familiar with the way that nessus works, you'll be happy to know that the big ideas and the general methodology/procedure behind using OpenVAS are essentially the same. If you're unfamilar with programs like nessus and OpenVAS, here's how they work, from an administrator/auditor's perspective:

1. Set up a server
2. Use a client to tell the server to probe the target site
3. View the audit report on the client

At present, if you're using the stock stable/unstable Debian repositories, you haven't got access to the packaged version of the OpenVAS server. That being the case, we're going to go ahead and get a little bit heroic here and do this the Cowboy Way (i.e. from source).

1. Dependencies and Source Files

Make sure that you've got the following packages (some of which the openvas developers list as dependencies, some of which you'll need to compile anything from source) before proceeding:
molluska:/opt/# aptitude install libgnutls-dev libpcap-dev libgpgme11 libgpgme11-dev libglib2.0 libglib2.0-dev build-essential bison

Now that that's handled, there are four "modules" that are required to run an OpenVAS server. The openvas developers say that you've got to install the modules in the following order:

1. openvas-libraries
2. openvas-libnasl
3. openvas-server
4. openvas-plugins

So that's what wer're going to do. I like to do this sort of thing in/opt, but it really doesn't matter where this happens.

Get the files:
molluska:/opt/openvas# wget http://wald.intevation.org/frs/download.php/572/openvas-libraries-2.0.2.tar.gz
molluska:/opt/openvas# wget http://wald.intevation.org/frs/download.php/561/openvas-libnasl-2.0.1.tar.gz
molluska:/opt/openvas# wget http://wald.intevation.org/frs/download.php/562/openvas-server-2.0.1.tar.gz
molluska:/opt/openvas# wget http://wald.intevation.org/frs/download.php/576/openvas-plugins-1.0.6.tar.gz
NB: these URL's are for the version that was current when this was written--no guarantees that they'll be there two hours from now.

2. ./configure && make && make install

Now, we start the compilation process which, thanks to our having resolved the dependencies enumerated above, should go off without a hitch:
molluska:/opt/openvas# tar -zxvf openvas-libraries-2.0.2.tar.gz
[...]
molluska:/opt/openvas# cd openvas-libraries-2.0.2
molluska:/opt/openvas/openvas-libraries-2.0.2# ./configure
[...]
molluska:/opt/openvas/openvas-libraries-2.0.2# make
[...]
molluska:/opt/openvas/openvas-libraries-2.0.2# make install

Once you've successfully installed the openvas libraries, you'll be prompted to modify /etc/ld.so.conf by adding the line "/usr/local/lib" to it and running ldconfig to update your linker. Do that, and then repeat the steps described above (untar, configure, make, make install) in the other three folders to finish installing the OpenVAS modules.

3. Add a User and Generate an SSL Cert

Once you've got everything installed, you'll need to create two things: an OpenVAS user and an SSL certificate. Fortunately, both of these tasks have been nearly fully automated and all you'll have do to get the job done is execute a couple of binaries (which should be on your path, now that you've installed everything according to the above instructions) and follow some on-screen prompts:

molluska:/opt/openvas# openvas-adduser
[...]
molluska:/opt/openvas# openvas-mkcert
[...]

And that's it. Make a note of the paths that the openvas-mkcert program gives you at the end of the certificate creation (as you might need to specify them at some later time; you won't need them again to follow these instructions).

4. Fire it up

Once you've got all your modules installed, your certificate created and your user added, it's time to fire up the server/daemon. The smartest way to do this is to pseudo-daemonize it and tail its output while it loads plugins:molluska:/# nohup openvasd &
[1] 4508
molluska:/# nohup: ignoring input and appending output to `nohup.out'
molluska:/# tail -f nohup.out

Should get you something like this:tail -f nohup.out
Loading the plugins... 714 (out of 10558)

...and so on. Once the plugins are all the way loaded, fire off a quick ps to make sure that the server is running and maybe a quick netstat to make sure you know what port it's listening at, and that's it: you're done with the server side of things and ready to move on to the client and auditing part.

molluska:/opt/openvas# ps aux |grep openvas
root     26129  1.1  0.2  16296    76 ?        S    06:29   1:46 openvasd: waiting for incoming connections
molluska:/opt/openvas# netstat -anp |grep openvas
tcp        0      0 0.0.0.0:9390            0.0.0.0:*               LISTEN      26129/openvasd: wai

Installing the OpenVas client is much easier.

While there is a packaged version of the OpenVAS client app, we're going to install one from source (mostly so our version of the server matches with our version of the client; this is mostly me being OCD, however, and you can probably get away with using the packaged version). To install the client, we'll follow the same steps as above, but on a different machine:

gonzo:/opt/openvas-client# wget http://wald.intevation.org/frs/download.php/575/openvas-client-2.0.3.tar.gz
[...]
gonzo:/opt/openvas-client# tar -zxvf openvas-client-2.0.3.tar.gz
[...]
gonzo:/opt/openvas-client# cd openvas-client-2.0.3
gonzo:/opt/openvas-client/openvas-client-2.0.3# ./configure
[...]
gonzo:/opt/openvas-client/openvas-client-2.0.3# make
[...]
gonzo:/opt/openvas-client/openvas-client-2.0.3# make install

NB: you may, depending on your client system, have to resolve some GTK dependencies and other build/compiler dependencies like the ones listed above: libgtk2.0-dev should solve most of your gtk problems, if you're running Debian Lenny.

Once the GUI client is installed, start it up:

toconnell@gonzo:~$ sudo aptitude install openvas-client
[...]
toconnell@gonzo:/opt/openvas-client/openvas-client-2.0.3/bin$ ./OpenVAS-Client &

Once the GUI client is up and running, click the connect icon at the top of the interface (looks like two gray tubes colliding) to open the window that allows you to specify your newly install server's location and settings. Fill in the blanks and connect:

Once your client is connected with your server, you're ready to fill in the blanks and start your first round of tests. This is fairly self-explanatory and, honestly, you wouldn't be reading this if you couldn't figure out simple GUI interfaces: specify your target (i.e. the server you're auditing), make sure that all the plugins are enabled and then click the life preserver to start the "Scan Assistant" and execute the scan. Follow the on-screen prompts: easy as apple pie.

The best thing to do, once your scan starts, is probably to go do something else and come back in a little bit: in my experience these scans can take anywhere from 15 to 45 minutes, depending on your server and your pipe: my server is an old Linksys NSLU2 and my pipe is a consumer-grade Speakeasy residential connection, so I'm used to waiting close to an hour for the scan to finish. Using corporate resources will result in less idle time.

Once the scan is done, you're treated to a report view. This is what we've been after all long. In it, you'll see a full run-down of what ports on your server are open and what open ports are listening for what. Additionally, you'll be treated to helpful recommendations about how to close security holes. And while closing those holes is beyond the scope of this article, I will say that almost every recommendation I've gotten from an OpenVAS report has been sane, been sensible and lead to a harder server.

nikto: Web-server Specific Auditing
The second thing to do, in order to perform a robust audit of your system, is to hit it with nikto (http://www.cirt.net/nikto2).

nikto, unlike OpenVAS doesn't require a server/client hook-up: just install the client with apt and fire off some tests, writing the output from those tests to plaintext files:

molluska:/# aptitude install nikto
molluska:/# nikto -h newathens.org -p 80 -output nikto_na80 && nikto -h newathens.org -p 443 -output nikto_na443

You'll get helpful output that points you towards an obvious solution like this:

+ mod_ssl/2.2.9 appears to be outdated (current is at least 2.8.30) (may depend on server version)

And you'll also get put on notice if you've got paths/folders/files with names that automatic exploiters and scripts tend to look for:

+ OSVDB-3092: GET /login/ : This might be interesting...

...to script kiddies and Chinese botnets.

You'll also get put on notice if you've got too much of your software's installation defaults hanging out in the open:

+ OSVDB-3233: GET /icons/README : Apache default file found.

Server-side Checks

chkrootkit
There are a few utilities that allow you to perform quick server-side audits of your security situation. Some of them, like rkhunter will run daily (like logwatch or apticron) and tell you if they've identified any new chinks in your armor. The first one to install and run is chkrootkit.

molly:/# aptitude install chkrootkit
[...]
molly:/# chkrootkit

This is a great place to start your internal audit because it'll tell you if you've picked up any known bugs and whether anything weird, filesystem-wise, appears to be going on with your computer.

The best use for this app is to give you a very quick idea of what sort of shape you're in. If you've got a system littered with suspicious files, odd-looking binaries, etc., you know exactly where to start plugging holes.

rkhunter
While we're on the subject of checking for root kits, let's do rkhunter:

molly:/# aptitude install rkhunter
[...]
molly:/# rkhunter --update
molly:/# rkhunter --check

This gets you a quick check of all your important binaries (to make sure they look like they're supposed to look, i.e. that they haven't been replaced by scripted exploits or an intruder with something that opens a back door) and a quick scan for known exploits of the rootkit variety. You'll also be told whether you're running inetd/xinetd (which tends to open ports in a manner whose security can be less than "ironclad") and other fun facts about potential vulnerabilities.

The best thing to do with this report is think long and hard about what ports/resources/pathways you actually want to make available to the Internet and then start disabling services. Once you've spent some time with that, you're pretty well on your way to having an idea of exactly how hard your server is and how much work you've got to do to keep it safe.

If anyone has any ideas about other utilities or techniques for security auditing, please feel encouraged to share them in the comments.

Generally speaking, I'm a Debian guy.

Sure, I'll mess around on the CentOS box under my desk on the production RHEL servers at work a little bit, but Red Hat is largely terra incognita for me and Debian is where I'm comfortable doing my admin thing and managing packages. I know apt. I am comfortable with apt. And while I wouldn't describe using yum as something that makes me uncomfortable, when I do have to use it, I find myself spending more time Googling and forum-searching than I'd like.

I'm beginning to accept that this is no one's fault but my own.

And so the purpose of this article, therefore, is not a.) to point fingers, b.) to compare apt to yum or c.) to explain yum from the perspective of someone who is accustomed to doing things the Debian way. The Internet is littered with stuff like that like the intersection of Paradise and Tropicana are littered with advertisements for escorts.

In this post you'll find some novice-level trouble-shooting tips, reminders and pointers for the casual yum user that are intended to help reduce the occurrence of forehead-slaps and to decrease the amount of time spent tailing logs and Googling obscure error messages.

1. Preemptive Troubleshooting.

It's not in the documentation, but I have noticed that a lot of dependency issues and version consistency problems are resolved by tossing off the following yum command and then trying again:

 # yum clean packages

It has become my general practice to do this before I do anything else. It's a nice preemptive step.

I've noticed that it's generally not the advice of performance-minded (read: impatient) admins to do the more scorched-Earth yum clean all, as this empties caches, dbcaches (i.e. sqlite files) and can causes longer check-update times.

2. filelists.xml.gz Download Times out.

Let's say you're doing a yum update or a yum upgrade and you get some output like this:

filelists.xml.gz          100% |=========================| 1.4 MB    00:01
filelists.xml.gz          100% |=========================| 1.3 MB    01:48
http://apt.sw.be/redhat/el5/en/i386/dag/repodata/filelists.xml.gz: [Errno 4] Socket Error: timed out
Trying other mirror.

There are good odds, especially if you're using non-standard repositories, that you copied/pasted some text into your yum.conf from somewhere out there on the Internets. If you did, there are even better odds that the text you copied includes something about using GPG to authenticate the repo. If you've got lines like that, you'll need the repository's key.

Generally speaking, you can navigate to a repository's http site and find the URL for their public key. Once you've got that, all it takes to import it is one of these:

# rpm --import http://dag.wieers.com/packages/RPM-GPG-KEY.dag.txt

3. Know your repositories

You can save a lot of backtracking/head-scratching time if, before searching for a package on a machine you don't visit that often, you toss off a quick yum repolist. This handy feature will spit out the names and statuses of all of the repositories in all the files in your /etc/yum.repos.d/ directory and prevent you from doing that thing where you don't realize that you've only got the default CentOS repositories enabled but can't seem to figure out why the eff your yum search for htop just turned up a big goose-egg.

4. Automatic Notifications

If, like me, you're coming at yum from a Debian perspective, one of the first things you'll do when you start administering an RPM-based system is to install the apticron-equivalent known as yum-updatesd (# yum install yum-updatesd.noarch). Something you might forget, however, is that the default behavior of yum-updatesd is to not send emails.

Don't forget to edit /etc/yum/yum-updatesd.conf such that

mit_via = dbus

looks like

mit_via = email

or you won't get those all-important package update emails.

And that's about all that's coming to mind right now.

If anyone else can think of some things that you consistently forget--and then suddenly remember, 20 minutes later--to do when you're working with yum, feel free to leave a comment.

This blog is going to end with a question that I have been unable, after countless minutes of Googling, to answer satisfactorily. It will start, however, with some givens.

I already know that if you want to alter the default settings for all profiles that will be created by a given Firefox installation in the future, you add the line for the preference that you want to effect those profiles to the file FIREFOX_ROOT/defaults/profile/prefs.js.

Similarly, I already also know that if you want to push a preference to all currently existing users on the machine, you add the line for that preference to FIREFOX_ROOT/deftauls/pref/firefox.js.

The caveat there, of course, is that if the user of the profile have already changed a preference in his personal prefs.js (i.e. the one in HOMEDIR/.mozilla/firefox/RANDOMALPHANUMERICS.USERNAME/prefs.js) and it conflicts with your preference in the (global) firefox.js, then you (the admin) are SOL, because the program will defer to the user's personal prefs.js file.

Which brings us to the question: is there a way (short of writing a script to parse individual user's personal prefs.js files and modify them as needed) to push a preference to all users of a given Firefox installation?

Full disclosure: I'm posing this question for two reasons. The first reason is that I'm sort of passive-aggressive with Firefox: ours is a very love-hate relationship. The second reason is that I honestly don't think that what I'm describing--i.e. adding a preference to one, "master" preferences file that effects all users of a given installation, regardless of their personal prefs.js file--can be done.

Am I missing something? Maybe even something truly forehead-slap-worthy that's at the top of all the documentation? Or is this a real limitation of the program?

Trevor's Links

Scarling

I've heard there's a big migration of ruby people to scala, and so the first thing I would say to the ruby people is that this is no panacea. It's not ruby on a JVM; it's an entirely new langauge, with much stronger java roots than any other language, so familiarity with java is probably more helpful than python or ruby. On the other hand, if ruby whetted your appetite for functional programming, scala has more of that than ruby and python combined, and seems to live up to its promise of exposing the wonders of java's scalability and rock-solid virtual machine and garbage collector.

20 Rails Development No-No's

Rails programmers: what's an example of one thing you find in other people's Rails code that you (almost) always consider to be wrong?

github's jquery-relatize_date

jQuery version of technoweenie's relative date js library.

PragDave: Twitter Should Move Away from Ruby

Oh dear. The chattering classes are at it, talking about how the Twitter folks are dissing Ruby by announcing the replacement of some Ruby code with Scala code. [Don't miss the comments!]

Building Sites Around Social Objects

Define Your Object. Define Your Verbs. Make the Objects Shareable. [I like the first 3 of these 5 principles.]

soundamus

A personalized feeds of new and upcoming music releases. [Amazing!]

Behind the scenes of EveryBlock.com

Adrian Holovaty, co-author of the Django web framework, takes you under the hood of EveryBlock.com, a Knight Foundation News Challenge startup which rounds up local news and information, and is powered 100% by Python and Django.

Posterous Co-Founder Sachin Agarwal

Garry and I both went to Stanford and majored in Computer Science. When I graduated, I worked at Apple on Final Cut Pro for 6 years which was all the way up to starting Posterous. I was building the real-time playback engine and effects architecture. That didn't have a direct impact on the formation of Posterous, except that we're definitely Apple people at heart, and we want to be the Apple of blogging. We want to make the simplest, most beautiful site out there, and make it accessible to the masses.

iPhone on Rails and ObjectiveResource

ObjectiveResource is an Objective-C port of Ruby on Rails' ActiveResource. It provides a way to serialize objects to and from Rails' standard RESTful web-services (via XML or JSON) and handles much of the complexity involved with invoking web-services of any language from the iPhone.

Slicehost iPhone App

A simple tool for managing your Slicehost account.

auto_html

auto_html is a Rails plugin that let users embed HTML by providing URL of links, images, youtube, vimeo, deezer,...

ricardochimal's taps at master

A simple database agnostic import/export app to transfer data to/from a remote database.

Timothy's Links

War (1/3) | ncomment blogspam

This is awesome.

Fox News Boycott -

This is mostly a solidarity bookmarking, but the site is actually useful, insofar as it contains a list of corporate sponsors of Fox News.

Dealing with impossible crises

Generally speaking, I skim life advice links from Reddit, chuckle to myself about how such a self-absorbed community of self-declared geniuses, free-thinkers and savants consistently manages to recommend self help 101 articles about basic life skills as if they were the original wise sayings of the Lord Buddha and move on. But this one's got two cherry pieces of advice and a fun anecdote about how you can +1 your fast talk skill: 1.) stay calm and polite, 2.) go into all conflicts assuming that you have already lost. Resolving oneself to failure and thus resetting the criteria for success according to your own rules is the original life skill.

How To Set Up A Postfix Autoresponder With Autoresponse | HowtoForge - Linux Howtos and Tutorials

This is a sweet little CLI autoresponder app for use with postfix that you can set up for all users on your box and modify at the line or via email. Effin' sweet.

Android tethering apps pulled from Market

While totally unsurprising, this is still mildly infuriating. The only thing that makes it less than intolerably annoying is the fact that Google is kind of on the level about it: T-mobile's TOS (which I agreed to obey at some point, I'm sure) forbid certain kinds of tethering, so Google had to pull the app. But the tether developer makes a good point: does this effect the whole market place? Or is market place going to be restricted by service provider in the future?

Associated Press Seeks More Control of Content on Web

Well, I guess that's it for the AP, then. It's probably for the best: they were really making a nuisance of themselves lately anyway (with that whole "Hope" poster biz) and we'll certainly be better off without them.

AdFreak: Viagra always has such wonderful gift ideas

There's nothing I love more than when Madison Avenue just straight goes for broke on a Mega Corp account and puts out an ad so utterly inane and puerile that you want to tell everyone you know about it. Call it a consciousness hack. And consider my private system exploited.

Schneier on Security: Who Should be in Charge of U.S. Cybersecurity?

This, for the record, is the ultimate talking point on Internet security: it's a network everyone uses that depends on an infrastructure managed and maintained by everyone and it is therefore everyone's responsibility to improve the quality and security of the network and its users. And this is why BS says the NSA shouldn't be Obama's go-to agency for "cybersecurity". They keep secrets. Secrets ruin the Internet. Don't believe me? Consider Microsoft's legacy of pissing in the pool in misguided and stupid attempts to deliver security through obscurity.

Sometimes you come across something in the Rails changelog that suggests a config change before upgrading to the next version. Sometimes you only have time to put some code together quickly, but you know that you really should go back and refactor it soon. How and where can you remind yourself about this stuff?

I'm not sure where I originally came across this concept, but I think it's worth sharing again anyway. I'll even give it a name this time. Time Bomb Tests: easy cheesy reminders you can put into your test suite. They'll sit there like little time bomb reminders - exploding only when you need them to.

 
# test/integration/time_bomb_test.rb
 
require 'test_helper'
 
class TimeBombTest < ActionController::IntegrationTest
 
  test "stuff to do with next rails upgrade" do
    flunk if Rails.version != '2.2.2'
    # rename application.rb to application_controller.rb
    # etc...
  end
 
  test "stuff I'm putting off today, but really should do eventually" do
    flunk if Time.now > Time.parse('5/1/2009')
    # optimize that thing marked HACK in the user model
    # etc...
  end
end
 

Update: Check out jeremymcanally's deprecate, which appears to have been partially inspired by this post. It allows you to deprecate (primarily) test code after a certain date, version, or other arbitrary condition is met.

Trevor's Links

Twitter on Scala

...it has been such a success that our plan for the long run is to move more and more of our architecture into Scala. The vast majority of our traffic is API requests, and we want most of those to be served by Scala, either at an edge cache layer or a web application layer. Hopefully by the end of 2009 the majority of users’ interactions with Twitter are going to be Scala-powered.

Twitter: blaming Ruby for their mistakes?

In conclusion... is Ruby a bad language for writing message queues in? Yes, there are much better choices. Message queues are a particularly performance critical piece of software... but message queues aren't something you should be writing yourself. This speaks much more to Twitter's culture of NIH than it does to Ruby as a language... Is Ruby a bad language for writing long-running processes? Absolutely not. JRuby provides state-of-the-art garbage collection algorithms available in the JVM to the Ruby world. These are the exact same technologies that are available in Scala. JRuby addresses all of their concerns for long-running processes, but they don't bother to mention it and instead just point out the problems of the de facto Ruby interpreter. [Very interesting comments.]

Obie Fernandez: My Reasoned Response about Scala at Twitter

I'm glad that Twitter is working to resolve its scaling issues. It's a service that I love and use on a daily basis and from which I have benefitted immensely. As far as I'm concerned, Twitter is a case-study in how Ruby on Rails does scale, even in their hands... My interest in the question of Ruby vs. Scala at Twitter had mostly consisted of curiosity and amusement, at least until last night.

Mending The Bitter Absence of Reasoned Technical Discussion

Social media (blogs, community news sites like Reddit and Hacker News, Twitter and such) have swept in to fill a vacuum between peer-reviewed academic journals and water cooler conversation amongst software engineers... in theory, we should be more informed as a professional than we ever have been... In practice, the conversations that are most widely heard in the tech community are full of inaccuracies, manufactured drama, ignorance, and unbridled opinion. In discussing these Internet-spanning debates with non-technical friends, comparisons to Hollywood tabloids come first to mind. It’s a time sink for an industry that should be a shining example of how to use the newest of media for constructive debate.

Chax

Chax is a collection of minor modifications and additions that make using Apple's iChat more enjoyable.

PyCon Keynote

Reddit's Steve Huffman and Alexis Ohanian. [They briefly discuss the infamous "gst" user around 15 minutes in.]

on url shorteners

URL shortening services have been around for a number of years. Their original purpose was to prevent cumbersome URLs from getting fragmented by broken email clients that felt the need to wrap everything to an 80 column screen. But it's 2009 now, and this problem no longer exists. Instead it's been replaced by the SMS-oriented 140 character constraints of sites like Twitter.

The Real World: A video of David's talk at FOWA Dublin - (37signals)

Execution and Perseverance are the keys to running a successful business.

The State of the Stack: A Ruby on Rails Benchmarking Report

New Relic helps more than 1500 organizations manage their Ruby on Rails applications. This gives us unique insight into how thousands of applications are deployed. Many of our customers have opted in to have their performance data shared with the Rails Core Team to aid in their ongoing work on the platform. In addition to that data we also aggregate information on the versions of OS, Ruby, and Rails used and the various plugins deployed.

DiggBar Launches Today!

Starting today, we’ll begin rolling out a new product we are calling the DiggBar. Before we dive into the details, check out this short video overview...

Google uncloaks once-secret server

Google is tight-lipped about its computing operations, but the company for the first time on Wednesday revealed the hardware at the core of its Internet might at a conference here about the increasingly prominent issue of data center efficiency.

Five Founders

Few know this, but one person, Paul Buchheit, is responsible for three of the best things Google has done. He was the original author of GMail, which is the most impressive thing Google has after search. He also wrote the first prototype of AdSense, and was the author of Google's mantra "Don't be evil."

Follow-up on "Get Satisfaction, Or Else..."

Customer support is my job, and I take it very seriously, and I am very, very good at it. To have another website undermine that job which leads to a customer with 1) a bad experience, 2) a bad impression of our company, 3) a bad impression of my work…well, it’s infuriating. Not only was I angry on the customer’s behalf, I was angry on behalf of our company to see our name and logo plastered all over a site we had never known about until then.

Ambient Intimacy

“Ambient intimacy” is a good term to describe how Twitter, Flickr, blogs, and other modern communications technologies keep us in touch with one another. The term I’ve been using for this is “passive communication.”

Hacker News on Daring Fireball's Complex

We advise startups to launch when they've added a quantum of utility: when there is at least some set of users who would be excited to hear about it, because they can now do something they couldn't do before.

stevenberlinjohnson.com: Old Growth Media And The Future Of News

...there are really two worst case scenarios that we’re concerned about right now, and it's important to distinguish between them. There is panic that newspapers are going to disappear as businesses. And then there’s panic that crucial information is going to disappear with them, that we’re going to suffer as culture because newspapers will no long be able to afford to generate the information we’ve relied on for so many years.

Get Satisfaction, Or Else...

We shouldn’t be forced to scour the internet finding sites that claim they are doing support for us when they’re not. It’s not fair to us and it’s not fair to customers to make something look like an official support site when it’s not. This should be entirely opt-in for a company and it’s not. In fact, it’s worse than that because if you don’t opt-in, they make negative claims about your company’s commitment to customers. [See also: http://news.ycombinator.com/item?id=540540]

2009 Rubyist's guide to a Mac OS X development environment

My hard drive kicked the bucket recently. From scratch, here’s how I quickly got my Ruby web development environment into ship-shape form The Thoughtbot Way. Many of these instructions are specific to Mac OS X 10.5 (Leopard). Some of them are opinionated (Vim over Textmate). Pick-and-choose what you need but this is everything that I use happily day-to-day right now.

redirect_to HTTP POST

...the problem is that redirect_to doesn't seem to preserve the HTTP method. This is ok for the faked-up methods eg using "_method=delete" but if the URL a person asked for was a POST it fails miserably with a routing error... [Checking out some of these solutions, but for now I'm just working around it by only storing the original request if it's a GET request.]

Timothy's Links

HugeURL

This is a triumph of the human spirit if I ever saw one.