When attempting to install Bundler for Ruby on Ubuntu 10.04, I got the following error:

shell> sudo gem install bundler
ERROR: Error installing bundler:
bundler requires RubyGems version >= 1.3.6


Running sudo gem -v I saw that I had 1.3.5. To get around this, simply install the available updater gem, then run it:

shell> sudo gem install rubygems-update
shell> sudo /var/lib/gems/1.8/bin/update_rubygems


Now running gem -v I see that I have 1.8.15 and I am able to install bundler:

shell> gem install bundler
Fetching: bundler-1.0.21.gem (100%)
Successfully installed bundler-1.0.21
1 gem installed
Installing ri documentation for bundler-1.0.21...
Installing RDoc documentation for bundler-1.0.21...


Here's a handy little command to delete every file in a directory except for the N most recent files. It is helpful for including in a log rotation or db backup script.

find /path/to/files/ -maxdepth 1 -type -f -name '*' -print0 | xargs -r0 ls -t | tail -n +5 | tr '\n' '\0' | xargs -r0 rm

Breaking down and explaining each section of the command, we have:

find /path/to/files/ -maxdepth 1 -type -f -name '*' -print0

This will list all files in the specified directory. The reason we use 'find' rather than 'ls' is because we need the full path of the files when later passing the argument list to the 'rm' command. We specify a 'maxdepth' so we only search within the current directory. We also specify a 'type' of 'f' so that we only find files and not other items like directories, sockets, or symbolic links. It's probably best not to use '*' as your 'find' expression, as it could be dangerous if you accidentally point it to the wrong directory. Use something like '*.sql.gz' or '*.log' or whatever suits you. Also note that we are using '-print0' so that the subsequent commands will be able to handle spaces and other special characters in filenames (see http://en.wikipedia.org/wiki/Xargs#The_separator_problem)

xargs -r0 ls -t

This will sort the list returned by the 'find' command in descending order by timestamp (newest to oldest). The '-r' parameter instructs xargs not to run of no files are found by the first 'find' command. The '-0' parameter gets around the separator problem described in the previous step.

tail -n +5

This will filter the list to only show from the 5th line onward. So if you want to keep the 10 most recent files, use +10 as your argument.

tr '\n' '\0'

This is similar to using '-print0' with the 'find' command above. We need to clean up the output so that the subsequent xargs command can handle potential spaces in the filenames. So we use the 'tr' command to translate newlines to the null character.

xargs -r0 rm

Finally, this command will delete the files returned by the combination of the previous commands.

When developing some discography software for a website, I came across the need to sort a list of releases differently depending on their release date. I wanted to sort future releases in ascending order (oldest to newest) and sort past releases in descending order (newest to oldest). This isn't an easy task, but after many hours of trial and error, I finally figured it out with some MySQL trickery.

Given the following MySQL Database table named releases:

+-------------+------------------+------+-----+---------+----------------+
| Field       | Type             | Null | Key | Default | Extra          |
+-------------+------------------+------+-----+---------+----------------+
| id          | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| title       | varchar(256)     | NO   |     | NULL    |                |
| releasedate | date             | NO   |     | NULL    |                |
+-------------+------------------+------+-----+---------+----------------+

I accomplished the dynamic ORDER BY clause by using the following query:

SELECT id,
       title,
       releasedate,
       UNIX_TIMESTAMP(releasedate) AS releasedate_unix,
       CASE WHEN releasedate > NOW() THEN 0 ELSE 1 END AS futureorpast
FROM releases
ORDER BY futureorpast ASC,
         CASE WHEN releasedate_unix > UNIX_TIMESTAMP(NOW()) THEN
            releasedate_unix
         ELSE
            (releasedate_unix * -1)
         END

Now for an explanation. First, we need to "seperate" the results into two sets: future releases and past releases. This is accomplished by calculating the futureorpast column upon which we can sort, so future releases are assigned a value of 0 while past releases are assigned a value of 1. These are then sorted with future releases coming first, because obviously 0 comes before 1.

Next comes the tricky part: we want to sort future releases by ASC but past release by DESC. This is unable to be accomplished using dynamic ASC/DESC in a CASE clause because you can only calculate values using CASE, not clauses. The trick then is to convert the date column into a unix timestamp so that we have an integer, and then take the inverse of that integer on the values we want to sort in reverse.

Using this technique I was able to sort a subset of results in one direction and another subset of the same results in a different direction. I'm not sure if this is the best way to accomplish this, so if anyone has other suggestions on how to accomplish this, I'd love to hear them!

I do a lot of command line work on my OS X machine, so the history saves me a lot of time running repeat commands and also refreshing my memory on commands that I haven't run in a while. Unfortunately, the default history length in OS X is 500 commands. That seems like a lot, but when you're running 50+ commands a day it can push older commands off the list pretty quickly. This is easily solved by setting the HISTFILESIZE in your .bash_profile file.

First, to find out what HISTFILESIZE is currently set at, run the following command from Terminal:

echo $HISTFILESIZE

To change this value, simply add the following line to your .bash_profile file (found in /Users/yourname/):

HISTFILESIZE=2000

This increases your bash history to 2000 items. It will take effect next time you open a Terminal window.

After installing eAccelerator on a CentOS 5.5 server running PHP 5.2.10, a bunch of websites began failing with open_basedir errors like so:

[Fri Jul 16 17:53:50 2010] [error] [client XX.XX.XXX.XXX] PHP Warning: require() [function.require]: open_basedir restriction in effect. File() is not within the allowed path(s): (/home/username/) in /home/username/public_html/wp-settings.php on line 19, referer: http://www.server.com/

After doing some research it turns out that a default option that is compiled into eAccelerator is incompatible with open_basedir. The fix is easy enough, simply re-compile with the --without-eaccelerator-use-inode option like so:

make clean
phpize
./configure --without-eaccelerator-use-inode
make
make install

After re-compiling and installing, make sure you clear out the existing eAccelerator files before restarting Apache:

rm -rf /var/cache/eaccelerator/*
apachectl restart

eAccelerator states that the next version will have this compile option set by default.

Reference:

• http://eaccelerator.net/ticket/414
• http://eaccelerator.net/ticket/104

Global find & replace is easy in MySQL:

UPDATE table_name SET column_name = replace(column_name, "searchString", "replaceString");

While my upgrade to OS x 10.6 Snow Leopard has been mostly smooth, there are a few annoying bugs I've come across. This one has to do with audio - upon reboot, audio gets set to mute no matter what settings I had the volume on before. Not a big problem, but annoying none the less. Here's how to fix it:

1. In Finder, navigate to Macintosh HD > Library > Preferences > Audio
2. Delete the following files:
   •      com.apple.audio.DeviceSettings.plist
   •      com.apple.audio.SystemSettings.plist
3. Open System Preferences > Sound
4. Set your sound to your preferred settings
5. Exit System Preferences and Reboot

There you go! After deleting those files, they will be re-created when you go into System Preferences and your audio will no longer be muted upon reboot.

If you have a chkdsk or scandisk scheduled to run on a drive after your next reboot, normally you'd be able to cancel it by pressing any key 10 seconds before the scan starts. Unfortunately, my bluetooth keyboard/mouse combo didn't seem to work at this stage of bootup, so I was unable to cancel any scan. After some research I found out that the scheduled scan is simply a registry entry and that if you remove it, the scan wouldn't execute next time you reboot. Here's how:

1. Start > Run > regedt32
2. Navigate to HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager
3. Open the BootExecute key
4. Remove the line that says: autocheck autochk /r \??\E: where "E:" is your drive letter
5. Exit Regedit and reboot, and no scan will execute

As many of you know, most of the information from within Iran is coming from on-the-ground new-media and social networking sites such as Twitter, YouTube, and Facebook. This is happening despite crackdowns on communications networks by the Iranian government. The way this information is able to escape the firewalls of Iran is via proxies which relay and "hide" the destination of the communications so that it becomes difficult to block. This allows those on the ground in Iran to communicate with the world instantly and effectively, without fear of government crackdown. But it is a constant arms race. As soon as a relay becomes known by the Iranian government it gets shut down. The only way to keep the lines of communication open are to strengthen the distributed Tor network by adding more relays and bridges, making it more difficult for the Iranian government to block them all.

There have already been great write-ups on how you can contribute to the distributed proxy network Tor:
http://anonygreen.wordpress.com/2009/06/18/how-to-setup-a-tor-relay-or-tor-bridge/
http://smokingfish.blogspot.com/2009/06/brief-introduction-to-tor-and-why-its.html

Please read over those documents for an overview. I wanted to provide detailed instructions on how to get a Tor network set up quickly, easily, and cheaply for those of you who would like to contribute. You can provide invaluable assistance to the people of Iran for as little as 15 minutes of your time and $20/month.

First off, this document assumes you have some system administration knowledge with Linux (Fedora) and are comfortable installing and configuring packages from the command line. If that's you, you can have a Tor relay up and running in about 15 minutes.

Key:
Shell commands are in purple
Config file settings are in blue

1. Register at Slicehost

   Slicehost is a VPS provider that allows you to quickly build/deploy webservers very cheaply. Sign up here and purchase the cheapest $20 slice to get started. Pick Fedora 10 as your Linux Distribution. Do not pick Fedora 11, as it is incompatible with the current version of Tor. Once you are registered, Slicehost will email you your IP and root password. It can take a few minutes to build your new slice, so be patient.

2. Slice Security

   Log in to your new slice. Please note that this document covers the bare minimum of commands to get Tor up and running. You should follow due diligence when it comes to securing your new slice, something which is outside the scope of this document. Common practice security configurations are recommended. Security is your own responsibility, and I will not be held liable for any security issues with your slice. There are a few bare-minimum security things you should do to your slice:

   Change the root password:
       passwd root

   Create your own account & set password:
       adduser yourusername
       passwd yourusername

   Disable root login to ssh
       vim /etc/ssh/sshd_config
       Change to this: PermitRootLogin no
       service sshd restart

   These steps are the BARE MINIMUM you should do to secure your slice.

3. Update Your System

   yum -y update

4. Install Prerequisites

   yum install wget vim-enhanced gcc make libevent libevent-devel openssl openssl-devel zlib zlib-devel rpm-build

5. Download Tor & Signature

   
   wget https://www.torproject.org/dist/rpm/tor-0.2.1.16.rc-tor.0.fc10.src.rpm
   wget https://www.torproject.org/dist/rpm/tor-0.2.1.16.rc-tor.0.fc10.src.rpm.asc
   

6. Verify Packages

   Follow directions at http://www.torproject.org/verifying-signatures.html.en to verify that you have an authentic RPM and not a fake.

7. Build & Install Tor

   
   rpmbuild --rebuild tor-0.2.1.16.rc-tor.0.fc10.src.rpm
   rpm -i rpmbuild/RPMS/x86_64/tor-0.2.1.16.rc-tor.0.fc10.x86_64.rpm
   

8. Configure Tor

   vim /etc/tor/torrc

   Change the following settings, substituting your own values for Nickname and Address:
   
   DataDirectory /var/lib/tor
   ORPort 9001
   DirPort 9030
   Nickname YOUR_NICKNAME
   Address YOUR.IP.ADDRESS.XX
   
   Save & Exit

9. Set Bandwidth Limits for Tor

   These settings are largely dependent on which slice you have purchased. The ones you see below are for a 20GB slice, and they allow 2GB of transfer per day, so you should be well within the 20GB slice limit of 100GB/month. If you have purchased a larger slice, these settings can be increased accordingly. Be careful here, incorrect settings can push you over your monthly bandwidth limit very quickly! I did over 12GB of transfer in a little over 8 hours before limiting bandwidth with these settings.

   vim /etc/tor/torrc
   
   RelayBandwidthRate 64 KBytes
   RelayBandwidthBurst 128 KBytes
   AccountingStart day 12:00
   AccountingMax 2 GB
   
   Save & Exit. The AccountingStart and AccountingMax settings will limit 2GB max transfer per day, resetting at 12:00 every day. The RelayBandwidthRate and RelayBandwidthBurst settings throttle the bandwidth so that you don't reach AccountingMax after only a few hours. Normally AccountingStart and AccountingMax would be enough to stay within your bandwidth limits, but I want my relay to be available all day rather than reaching AccountingMax and shutting down after a few hours.

10. Configure Your Firewall

    iptables-save > /etc/sysconfig/iptables.default
    iptables-save > /etc/sysconfig/iptables.test
    vim /etc/sysconfig/iptables.test
    
    Insert the following settings:
    
    # tor ORPort & DirPort
    -A INPUT -p tcp --dport 9001 -j ACCEPT
    -A INPUT -p tcp --dport 9030 -j ACCEPT

    
    # tor Allow all outbound traffic
    -A OUTPUT -j ACCEPT
    
    Save & Exit.
    
    iptables-restore < /etc/sysconfig/iptables.test
    iptables -L (verify the rules are correct)
    iptables-save > /etc/sysconfig/iptables
    

11. Increase the number of open file descriptors

    vim /etc/security/limits.conf

    Add this line:

    _tor hard nofile 32768

    Save & Exit

12. Start up the Tor Service

    service tor start

If everything starts correctly, you should see output like this:
Starting tor: Jun 21 15:44:04.219 [notice] Tor v0.2.1.15-rc. This is experimental software. Do not rely on it for strong anonymity. (Running on Linux x86_64)
Jun 21 15:44:04.219 [notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.
Jun 21 15:44:04.223 [notice] Initialized libevent version 1.4.5-stable using method epoll. Good.
Jun 21 15:44:04.223 [notice] Opening OR listener on 0.0.0.0:9001
Jun 21 15:44:04.223 [notice] Opening Directory listener on 0.0.0.0:9030
Jun 21 15:44:04.223 [notice] Opening Socks listener on 127.0.0.1:9050
/usr/bin/torctl start: tor started [ OK ]

Also, you should view the tor.log and verify that you see the following (after 20-minutes):

cat /var/log/tor/tor.log

Jun 21 15:44:13.835 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Jun 21 15:44:13.835 [notice] Bootstrapped 100%: Done.
Jun 21 15:44:13.835 [notice] Now checking whether ORPort XXX.XXX.XXX.XXX:9001 and DirPort XXX.XXX.XXX.XXX:9030 are reachable.. (this may take up to 20 minutes -- look for log messages indicating success)
Jun 21 15:44:18.492 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
Jun 21 15:44:18.492 [notice] Not advertising DirPort (Reason: AccountingMax enabled)
Jun 21 15:44:26.804 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jun 21 15:44:43.813 [notice] Performing bandwidth self-test.. done.

If you see some errors or it doesn't start correctly, post in the comments and I'll see if I can help you out. Here are some references to help you get it going:
http://www.torproject.org/docs/tor-doc-unix.html.en#installing
http://www.torproject.org/docs/tor-doc-relay.html.en

That's it! You now have a fully functioning Tor Relay and are helping the Iranian people get news and information out to the rest of the world. The cool thing about Slicehost is that you can easily upgrade your Slice with the click of a button to allow more bandwidth, RAM, and other resources. They also have a Clone option so that once you have your initial Tor slice running, you can clone it multiple times so that you can have multiple Tor servers at a time.

More good reads on Tor and its effect in Iran:
http://blog.torproject.org/blog/measuring-tor-and-iran
http://p10.hostingprod.com/@spyblog.org.uk/blog/2009/06/tor-relays-and-exit-nodes-for-iran-and-for-the-rest-of-us.html

Update 1 - Preventing Abuse by BitTorrent Users

A couple of days after setting up my Tor slice, I received a Digital Millennium Copyright Act (“DMCA”) notice that my relay was hosting copyrighted material and that I would be required to remove it or face having my Slice shut down. Turns out that there are people out there using BitTorrent over the Tor network to transfer copyrighted material. Philosophical debates about BitTorrent and copyright law aside, the whole reason why I am running Tor is to help those in Iran stay connected -- not to assist in the distribution of copyrighted material. So, after a few minutes of research, I found out we can prevent Tor being used by BitTorrent by adjusting your ExitPolicy:

vim /etc/tor/torrc

Add the following:
ExitPolicy reject *:1214
ExitPolicy reject *:4661-4666
ExitPolicy reject *:6346-6429
ExitPolicy reject *:6881-6999

Save & Exit
Restart Tor: service tor restart

You should also probably follow the advice at http://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment

References:
http://www.torproject.org/faq.html.en#ExitPolicies - Exit Policies in Tor
https://www.torproject.org/eff/tor-dmca-response.html - DCMA Response Template
http://www.orient-lodge.com/node/3622?dsq=11687593 - A Slicehost user who also received a DCMA notice
http://www.chrisbrunner.com/?p=119 - Why You Shouldn’t Run BitTorrent Over Tor

Update 2 - Slicehost Responds

After making the adjustments above, I notified Slicehost of my changes and they have responded:
Thank you for your response. We will go ahead and consider this matter resolved. Thank you for your attention to this matter.
Gotta give them credit for understanding that we're trying to help people in Iran -- not to pirate movies. Thanks Slicehost!

Update 3 - Upgraded to 0.2.1.16 & Config Adjustments

I received some configuration recommendations from Andrew Lewman of The Tor Project, and have updated the steps above accordingly.

To get the ID of an element using Dojo Framework, you need to use the dojo.attr function.

Given the following HTML:

<img src="/path/to/imageA.jpg" id="myImage1" />
<img src="/path/to/imageB.jpg" id="myImage2" />
<img src="/path/to/imageC.jpg" id="myImage3" />

You can get the IDs of each image in Dojo like so:

dojo.query("img").forEach(function(currentNode) {
    var theElementId = dojo.attr(currentNode, "id");
    console.log("id: ", theElementId); // debug
});

If you have debugging on and something like Firebug, the console output would be like so:

id: myImage1
id: myImage2
id: myImage3