cat /dev/brain | grep technology >> blog
I’ve recently written a Python module to graph some interesting Tokyo Tyrant metrics with Ganglia. It basically just parses the output of tcrmgr inform -st localhost, so you’ll probably need to update the pyconf file with the correct location of the tcrmgr command. But this module also gives you some neat things that tcrmgr doesn’t, like the current number of Get/Put/Out operations per second rather than just the total number of operations since the server was started.
Enjoy!
#!/bin/bash # # This script configures WordPress file permissions based on recommendations # from http://codex.wordpress.org/Hardening_WordPress#File_permissions # # Author: Michael Conigliaro <mike [at] conigliaro [dot] org> # WP_OWNER=changeme WP_GROUP=changeme WP_ROOT=/home/changeme WS_GROUP=changeme # reset to safe defaults find ${WP_ROOT} -exec chown ${WP_OWNER}:${WP_GROUP} {} \; find ${WP_ROOT} -type d -exec chmod 755 {} \; find ${WP_ROOT} -type f -exec chmod 644 {} \; # allow wordpress to manage wp-config.php (but prevent world access) chgrp ${WS_GROUP} ${WP_ROOT}/wp-config.php chmod 660 ${WP_ROOT}/wp-config.php # allow wordpress to manage .htaccess touch ${WP_ROOT}/.htaccess chgrp ${WS_GROUP} ${WP_ROOT}/.htaccess chmod 664 ${WP_ROOT}/.htaccess # allow wordpress to manage wp-content find ${WP_ROOT}/wp-content -exec chgrp ${WS_GROUP} {} \; find ${WP_ROOT}/wp-content -type d -exec chmod 775 {} \; find ${WP_ROOT}/wp-content -type f -exec chmod 664 {} \;
When using XML-RPC over SSL with Ruby, you may receive the following annoying warning:
warning: peer certificate won't be verified in this SSL session
There is a very simple (but very poorly documented) fix for this. After instantiating your XMLRPC::Client object…
server = XMLRPC::Client.new3( ... )
Add the following line:
server.instance_variable_get(:@http).instance_variable_get(:@ssl_context).instance_variable_set(:@verify_mode, OpenSSL::SSL::VERIFY_NONE)
Now do your XML-RPC calls as usual:
result = server.call( ... )
When setting up dual-master replication for Tokyo Tyrant, it won’t be long before you discover that old update logs hang around forever and eventually cause your disk to fill up. I found this sample script that attempts to remedy the problem, but I also found it pretty scary that it blindly deletes old logs without taking the replication delay into account. This means that (however unlikely it may be) it’s possible to delete logs prematurely. The script below uses the replication delay to figure out which logs are safe to delete, and it also allows you retain a certain number of old logs just in case. Stick this in a cron job, and you’re good to go:
#!/bin/bash # # This script queries a slave to see how far behind it is in its replication # (i.e. the 'delay'). This number is used to figure out which update logs are # safe to delete. # # Author: Michael Conigliaro <mike [at] conigliaro [dot] org> # SLAVE=ttslave.example.com ALWAYS_KEEP=1440 ULOG_DIR=/mnt/tokyo/data/ttserver.ulog # get all slave stats (exit on failure) OUTPUT=`tcrmgr inform -st $SLAVE` if [ $? -ne 0 ]; then exit 1 fi # use the delay value to figure out how many minutes worth of ulogs to keep DELAY=`printf "%s" "$OUTPUT" | grep delay | cut -f 2` OLDER_THAN=$((${DELAY/\.*/}/60+$ALWAYS_KEEP)) # delete old ulogs printf "delay=%ssec (sec), older_than=%s (mins)\n" $DELAY $OLDER_THAN find $ULOG_DIR -maxdepth 1 -name "*.ulog" -type f -mmin +${OLDER_THAN} -exec rm -v {} \;
I think I might be! After reading an article claiming that only 10% of programmers can write a binary search I decided to give it a shot. After about 20 minutes, I came up with this:
def bsearch(array, search, start_ix=0, end_ix=array.length) mid_ix = start_ix + ((end_ix-start_ix)/2).ceil if array[mid_ix] == search then puts "%d found at position %d" % [ search, mid_ix] elsif start_ix == mid_ix then puts "%d not found" % [ search ] elsif array[mid_ix] < search bsearch(array, search, mid_ix, end_ix) elsif array[mid_ix] > search then bsearch(array, search, start_ix, mid_ix) end end bsearch([10, 20, 30, 40, 50, 60, 70, 80, 90], ARGV[0].to_i)
It’s probably not by best work, and I’m pretty doubtful that I could have done it in the same amount of time under the stress of a job interview. But it works, and that’s good enough for me, considering that I haven’t been a full time programmer in quite some time and haven’t written anything like this since college. ;-)