It’s a very small, 50MB distribution of linux that is not that easy to install if you don’t have a linux box to start with. Despite the large number of Linux boxes that I once owned, I’ve replaced all of them with Mac OS. Fortunately, there is a simple way to install DSL on a USB boot drive from Mac OS, using VMWare Fusion.

You’ll need a 1GB USB drive. The smaller the drive is, the better. Some systems cannot boot off of very large USB drives. 512MB or 1GB is recommended.

Here’s the how to…

Download the latest copy of DSL from a mirror.

Do not use syslinux, but get the ISOLINUX version. This is the ISO named dsl-x.x.x where x.x.x is a version number. I used dsl-4.4.10.iso, although in retrospect I should have used the VMWare VMX Image. Either works.

Insert the pendrive and format it.

Mac OS will auto mount the pendrive. Open Disk Utiilty.
Format the device as MS DOS FAT and MBR.
One Partition.

Important: Unmount the pendrive before starting VMWare Fusion.

Create a new VMWare Fusion Virtual Machine

The general idea here is to create an empty VM using fusion, and to boot off of the ISO you have just downloaded.
It can be reasonably small. You do not need to allocate disk space on your HD.
Configure the VM as Linux/Ubuntu and to mount the CD.

Mount the pendrive as an “Alcor Micro Mass Storage” device. It will appear to your VM as /dev/sda.

Install DSL

When DSL boots up, at the “boot:” prompt, type “install”
Then, select “5″ for “USB Pendrive HDB boot install”

Answer yes to all prompts, and the install will (hopefully) complete.

Now What?

You’re done. DSL is great for password recovery, emergency repair, or system rescue. So long as your system supports booting from USB drives, you’re good to go!

For many years I’ve had a need for a module like this — A distributed blocking system which could operate across large web serving clusters and register hits in a central store. With rate limiting, incrementing counters on a single host is fairly useless when you have hundreds of servers behind a load balancer.

An attacker could hit many machines within the limit period before being detected, because there would be no central count. By keeping the counts in a memcache pool, all servers share the same data.

It won’t defend against attacks coming from random proxy addresses (say, Tor), and might unfairly count hundreds of users who live behind a single proxy (like corporate NAT), but it offers some protection against attacks coming from a single source IP.

The software is released under the Apache 2.0 Open Source License.

From the docs:

mod_memcache_block is an Apache module that allows you to block access to your servers using a block list stored in memcache. It also offers distributed rate limiting based on HTTP response code.

FEATURES

Distributed White and Black listing of IPs, ranges, and CIDR blocks
Configurable timeouts, memcache server listings
Support for continuous hasing using libmemcached’s Ketama
Windowded Rate limiting based on Response code (to block brute-force dictionary attacks against .htpasswd, for example)

REQUIREMENTS

libmemcached-0.25 or better
Memcached server
Apache 2.x (tested with 2.2.11)

Source code is available here:
http://github.com/netik/mod_memcache_block

If you would like to work on mod_memcache_block, contact me with your GitHub username and I’ll give you commit access on github.

Here’s a few examples of how this works:

find . -mtime 0   # find files modified within the past 24 hours
find . -mtime -1  # find files modified within the past 24 hours
find . -mtime 1   # find files modified between 24 and 48 hours ago
find . -mtime +1  # find files modified more than 48 hours ago
find . -mmin +5 -mmin -10 # find files modifed between 6 and 9 minutes ago

The argument to mtime is n*24 hours. If n is zero, though, things are very different. If you ask find for -mtime 0, you get everything that has been modified more than 24 hours ago, although the posix man page states that it should find files modified within the past 24 hours.

If you use -mtime +0, then you get everything modified between 24 hours ago and the current time. 

This is in  GNU find version 4.1.20, so you might get different results elsewhere.

This drove me nuts today while trying to help an engineer. Be careful when using find!