I renamed the ‘Register’ page to the ‘Log’ page because the former was misleading. While I used the term as a noun (a list or record) it is more typically used online in its verb form (as in ‘to enroll’). Given the context, I decided that ‘log’ was less confusing. I refuse to use the term ‘blog’, since that term more often than not refers to useless narcissistic ramblings made specifically with a public audience in mind. In my case, my ‘log’ is as much for me as anyone else.

Edit 07/26/14:

Can someone tell me why this is the most popular page on this site? I’m very confused.

I needed alligator clips to connected some wires from a heater to the terminals of a power source but didn’t have any. The solution I came up with was to solder small metal binder clips on the ends of the wires instead.

To prepare the binder clip, I scrubbed the bottom, nearly flat side with steel wool and applied flux to the surface. I wetted the entire bottom of the cleaned surface with solder. I also pre-tinned the wired. Connecting the two went smoothly, simply heating both simultaneously with the iron until the solder melted on both and merged to a single junction. I’m really happy with this solution since I rarely have alligator clips handy whereas the opposite is true of binder clips.

pyK-Control 2400 is a serial port controller and communicator for the Keithley 2400 SourceMeter written in python using the GTK+3 framework.  It’s main purpose is to configure and run current or voltage sweeps from a convenient software interface. The current release, 1.0 alpha, has been tested in Debian GNU/Linux and Windows XP.

More information can be found on the pyK-Control 2400 project page.

The helloNULL web server is a headless system, i.e. it does not run a windowing/desktop environment. One feature that is therefore lacking is the automatic mounting of USB flash drives upon plugging them in. For example, in the Debian/XFCE environment of my mobile desktop, a flash drive will be mounted to /media/label upon plugging in to the port, where ‘label’ is the drive label. This post will show you how to duplicate that functionality on a terminal-only system using udev rules and a simple script.

When a USB drive is plugged in udev handles initiating the device and by using udev rules, it is possible to specify a script to be run whenever this event occurs. In Debian, udev rules are written in text files under /etc/udev/rules.d/. Each file in that directory is parsed by order of filename. Rules that run scripts should begin with a  number in the 80’s. Our script can be called /etc/udev/rules.d/81-custom.rules and should contain the following code:

# Custom udev rules. Note that udev rules are run in order based
# on the filename. Rules in filenames that start with numbers
# are run before this one.
# This rule detects USB drives that are added to the system so
# that they can be mounted automagically by the script.
# It is based off of the replies to a question on superuser.com.
# http://superuser.com/questions/53978/ubuntu-automatically-mount-external-drives-to-media-label-on-boot-without-a-u

ENV{ID_FS_USAGE}=="filesystem", SUBSYSTEMS=="usb", ACTION=="add", RUN+="/root/auto-usb.sh mount %k"
ENV{ID_FS_USAGE}=="filesystem", SUBSYSTEMS=="usb", ACTION=="remove", RUN+="/root/auto-usb.sh cleanup %k"

The first rule will trigger whenever a usb device (SUBSYSTEMS) is added (ACTION) and the device contains a filesystem (ENV{ID_FS_USAGE}). The second rule is similar but triggers upon a ‘remove’ event. In either case, udev will add the script (RUN) specified to the list of scripts to be run for that event. Our script has two functions, mount and cleanup, depending on the event. In the former case, our script will need to know the kernel name of the device (e.g. sda1) to use for the mount command. The auto-log.sh script looks like this:

#!/bin/bash
#
# This script is called by a udev rule whenever a usb drive is
# plugged into the system or removed from the system.
# Usage:
# auto-usb.sh MODE DEVICE
# where MODE is either mount or cleanup
# and DEVICE is the device basename, i.e. /dev/DEVICE

if [ "$1" = "mount" ]; then
    # The ID_FS_LABEL enviroment variable is only available
    # When this script is caleld by udev
    mkdir -p "/media/$ID_FS_LABEL"
    $(mount | grep -q "/media/$ID_FS_LABEL") || mount /dev/$2 "/media/$ID_FS_LABEL"
elif [ "$1" = "cleanup" ]; then
    rmdir "/media/$ID_FS_LABEL"
else
    echo "ERROR: Mode $1 should be 'mount' or 'cleanup'."
fi

This is pretty straight-forward. In the case of mounting a usb drive, the device name is created from the passed argument while the mount point is generated from the disk label taken from an environment variable. The same environment variable is used to remove the mount point when the disk is removed. The proper way to remove the drive is with the eject command, like this:

That’s it! This is perhaps not the most robust solution but should work for most cases. Put the 81-custom.rules file in your /etc/udev/rules.d/ directory and the auto-usb.sh script in your /root directory (or wherever you want). Don’t forget to give the auto-usb.sh script execute permissions.

Edit 06/03/2013: I changed my mount line to give read-write permissions to the plugdev group. The plugdev group is for users who are allowed to mount and unmount removable devices. On my system, all people-users (as opposed to system accounts) are members of the plugdev group. This means that any real person logged in can access the mounted USB drive. The new mount line looks like this:

$(mount | grep -q "/medial/$ID_FS_LABEL") || mount -o gid=plugdev,dmask=007,fmask=117 /dev/$2 "/media/$ID_FS_LABEL"

Edit 12/16/2013: I discovered that my mount command from the 06/03/2013 change only works right for file systems of type vfat and would fail if the usb drive connected was formatted as ext3, for example. The problem is the options specified (gid, etc.) which aren’t valid for ext3 and ext4 filesystems which preserve permissions. The solution I decided on was to specify two different udev rules, one for each type of file system. Different mount options will be set in an environment variable depending on the file system detected. Then in my auto-usb.sh script, this environment variable is put directly into the mount call.

New udev lines:

# the mount options are different depending on the file system type
ENV{ID_FS_USAGE}=="filesystem", ENV{ID_FS_TYPE}=="vfat", SUBSYSTEMS=="usb", ACTION=="add", ENV{MOUNT_OPTIONS}="-o gid=plugdev,dmask=007,fmask=117", RUN+="/root/auto-usb.sh mount %k"
ENV{ID_FS_USAGE}=="filesystem", ENV{ID_FS_TYPE}=="ext?", SUBSYSTEMS=="usb", ACTION=="add", ENV{MOUNT_OPTIONS}="", RUN+="/root/auto-usb.sh mount %k"

New auto-usb.sh lines:

$(mount | grep -q "/media/$ID_FS_LABEL") || mount $MOUNT_OPTIONS /dev/$2 "/media/$ID_FS_LABEL"

I thought I’d share this technique I use to update the dns records for hellonull.com automatically from the web server every 5 minutes. In the event that my ISP issues me a new IP address, my site will hopefully only be down for 5 minutes.

First, you must obtain the dynamic dns (ddns) update password for your domain from Namecheap. At the time of this post, this was done by clicking the ‘Dynamic DNS’ link from the left hand menu, once your domain was already selected. When you enable dynamic DNS, a password will be generated that looks like a long string of random letters and numbers. Copy this down.

Next, put this password into the updateddns.sh script (below) and edit the wget commands to point to your hosts (@, www, etc.) and domain (hellonull.com). Make this script executable. It’s a good idea to make the owner of this script root and save it in a protected location, like /root because it contains ‘plain-text’ passwords. Anyone who is able to access the script is able to read the password and is therefore able to change your site’s DNS records.

#!/bin/sh
# This script updates the dynamic DNS record for several domains
# hosted on this server. It is run automatically by cron. The crontab
# file that makes this happen is stored in /etc/cron.d/ddns.
# While this script can execute as any user, it should be owned by
# root because it contains 'plain text' passwords.
# Each host (as in host.hellonull.com) must get updated individually.
# In addition, all subdomain records must be updated individually.

logFile="/var/log/updateNamecheapDDNS.log"

# this is the password as generated by namecheap
pass="You'll have to look at the original or get new ones"

# add a wget line for each host and subdomain
wget -a $logFile -O /dev/null "https://dynamicdns.park-your-domain.com/update?host=www&domain=hellonull.com&password=$pass"
wget -a $logFile -O /dev/null "https://dynamicdns.park-your-domain.com/update?host=@&domain=hellonull.com&password=$pass"
wget -a $logFile -O /dev/null "https://dynamicdns.park-your-domain.com/update?host=teachingwiki&domain=hellonull.com&password=$pass"

If you run the updateddns.sh script it should update your DNS records. To automate the process simply schedule the script using cron. I added a crontab file called ddns in /etc/cron.d which executes the script every 5 minutes.

# use this file to schedule ddns updates
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# every 5 minutes
*/5 * * * * root /root/updateddns.sh >/dev/null 2>&1

In my previous post, I discussed how to get the draw() event to fire for Gtk3 widgets in order to draw on them using cairo, specifically the GtkLayout and GtkDrawingArea widgets. Since that time I’ve had some success writing code to plot data from a connected source meter (through the RS232 port) in real time. I got stuck again trying to save the image drawn on the GtkLayout to a file. Most of the material I found on the internet wasn’t up to date and not relevant for the GTK3 framework. Finally I figured out how to save the image and it’s pretty easy to do too.

The solution is to get a GdkPixbuf from the widget’s GdkWindow and use the GdkPixbuf’s .savev() method to write the image to disk. For some reason, when I use the .get_window() method of GtkWidget’s, I don’t get a GdkWindow returned but rather a GdkX11Window object (gtk.gdk.X11Window). I’m not sure why there’s a difference but it seems to be ok to feed this into the Gdk.pixbuf_get_from_window() function. Please note that you must use the .savev() method of the pixbuf. Most sources online use the .save() method but that seems to be gone in Gtk3 (or perhaps there is no python binding?).

For example, assume you have a GtkLayout stored in the variable layout (I find mine with layout = self.builder.get_object(‘mylayout’) – because I’m using Glade). To capture an image of the layout and whatever you’ve drawn on it, you would do the following:

pixbuf = Gdk.pixbuf_get_from_window(layout.get_window(), 0, 0, width, height)
pixbuf.savev("foobar.png","png", [], [])

In this example, width and height need to be the width and height of the widget. The rectangular area defined by (0,0) to (width, height) is saved. In my case, I did something like this:

rect = layout.get_allocation()
width = rect.width
height = rect.height

In the .savev() method, the first argument is the file name, the second is the type, and the third and forth options are arrays of options and their settings. I pass empty arrays because I don’t set any options.

Note that this works with GtkLayout and should work with GtkDrawingArea and GtkWindow. For other widgets, the window returned by .get_window() seems to be that of the parent GtkWindow. If you want to capture an image of those wigdets, you’ll need to specify the x,y position of their top left corners in the Gdk.pixbuf_get_from_window() call.

layout