Stephan Sokolow's Blog

Have you ever had a cronjob that needs to run as root, but you can’t do so easily because of the following reasons?

• /etc/crontab is managed by your package manager
• vixie-cron ignores /etc/cron.d/
• Root’s private “crontab -e” crontab is easily overlooked when backing up /etc
• It needs some odd interval like “every 3 days”

Well, if your interval is evenly divisible into days, (“every 2 days” is OK, “every 1.5 days” is not) then I have just the solution. Create a new cron script in /etc/cron.daily, make it executable, and put the following inside it (For our example, I’ll use two days as the interval and “emerge –sync” as the command):

#!/bin/bash

TODAY=`date +%j`
if [ $((${TODAY#0} % 2)) == 0 ]; then
        /usr/bin/emerge --sync > /dev/null
fi

It’s that simple. Here’s how it works:

1. Once per day, the cron daemon calls the script
2. The script calls `date +%j` and gets the “day of the year” (between 1 and 365, inclusive, or 1 and 366 if it’s a leap year)
3. It then strips off any leading zeros to prevent “invalid number for given base” errors. (“085” would be “invalid octal” by bash syntax.)
4. The script does a “modulo 2” operation on it (takes the remainder of integer division by 2)
5. If there is no remainder, then the current date satisfies the “every second day” requirement and the command is run.

Because I chose the evenly-numbered days using “== 0”, a non-leap year will end with a two-day interval, rather than a leap year ending with the command being called two days in a row. Use “!= 0” if you want to change this behaviour.

The “> /dev/null” ensures that only stderr messages (usually only errors) generate status emails. I use that to keep my admin mailbox uncluttered.

UPDATE: Oops. I forgot that bash is one of the many languages which uses a zero prefix to indicate octal. I’ve corrected the example.

Yes, there is a legitimate reason for removing devices, and a special way to do it. In my case, I needed to because my cheap USB numpad exported two evdev-compatible devices with the same name. This confused evdev-plug… especially since one of them is completely inert.

The trick is to find the modalias for the troublesome interface in question. That will uniquely identify that evdev interface file leaving the other one untouched. Assuming the device node is /dev/input/event6, this should do the trick:

udevinfo -a -p `udevinfo -q path -n /dev/input/event6` | grep 'ATTRS{modalias}=="usb'

Take the output of that line and substitute it into this udev rule: (See my previous post for details))

BUS=="usb", ATTRS{modalias}=="usb:v1267p0103d0101dc00dsc00dp00ic03isc00ip00", OPTIONS="ignore_device"

It should be pretty self-explanatory.

UPDATE: On a related note, if you are using one of those Mouse+Keyboard USB-to-PS/2 bridges and don’t mind the lack of “Plug and Play”-like flexibility, the simplest way to select one of the two devices is to use something like this:

Driver      "evdev"
Option      "Name" "CHESEN PS2 to USB Converter"
Option      "Phys" "*/input0"

You can get the values for Name and Phys using

cat /proc/bus/input/devices

As programs start to take advantage of the evdev interface for input devices, it’s only a matter of time before you trip over the default permissions. The big problem is that you can’t just edit the default udev rule for /dev/input/event*, because that would also allow any other user on the system to read your keystrokes. Your passwords, for example.

If you’re like me, you’re probably trying to alter the permissions for a device which can’t be used to input sensitive data anyway. For example, a joystick or gamepad. In such a case, the solution is to override the permissions for just that device. In such a case, letting any user read the permissions is actually a benefit, because you could run your media player as a different user than your normal login name (if you’re feeling paranoid) and still control it via whatever joystick-control module it offers. (XMMS, Audacious 1.3 alpha, and MPlayer all offer such an option)

Anyway, down to business. First, find some uniquely-identifying information for your device. If it’s a USB device, that would be your vendor and product IDs, which can be retrieved using lsusb:

ssokolow@darkstar ~ $ sudo lsusb
Password:
Bus 004 Device 002: ID 046d:08d7 Logitech, Inc.
Bus 004 Device 001: ID 0000:0000
Bus 002 Device 015: ID 045e:0026 Microsoft Corp. SideWinder GamePad Pro
Bus 002 Device 014: ID 046d:c00c Logitech, Inc. Optical Wheel Mouse
Bus 002 Device 005: ID 05e3:0604 Genesys Logic, Inc. USB 1.1 Hub
Bus 002 Device 001: ID 0000:0000
Bus 005 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
ssokolow@darkstar ~ $

Now, udev will normally stop parsing rules when it finds a match, but there is a nice little trick that can be used to alter only the permissions, without having to override the default settings. (thereby ensuring that any changes to the defaults will still apply) In my case, this is what I did…

ssokolow@darkstar ~ $ sudo echo >> /etc/udev/rules.d/10-local.rules << EOF
BUS=="usb", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="0026", MODE:="0644"
EOF
ssokolow@darkstar ~ $

Important: Don’t copy and paste this. My blogging software “helps me” by taking a page out of Microsoft’s book and substituting typographical quotes. (even inside <code> blocks)

For those who don’t know, >> tells the shell to append rather than create if the file already exists and << specifies that we will be using a Here Document. The trick to this is the “:=” assignment operator used for MODE. It tells udev that this assignment should be final without stopping the rule processing. That is, the defaults will be used, but the permissions specified by them will be ignored.

If you need something a little different. For example, giving specialized names to device nodes, or working with a non-USB device, there are also tools to make that nice and easy. Give the following resources a try and you’ll see what I mean:

• HOWTO Customizing UDEV @ Gentoo-Wiki (Note: SYSFS is the old name for the ATTRS keyword)
• The udev manpage (KDE users can read it right in Konqueror)

Happy hacking. 🙂

UPDATE: Newer example for G15Daemon hotplug now available.