#udev

While getting gamepad input working for Ctesiphon, I decided to figure out how to get my damn keyboard to stop being detected as a damn joystick on Linux, causing endless confusion for Steam and all sorts of games.

Apparently some genius at Ducky didn't fill out the keyboard's HID descriptor properly, and it's wrong in precisely the right way for Linux's generic HID device driver to think the first interface of five on the device is a joystick (I'm not sure why it thinks this, the type is actually Undefined but whatever)

All the information I could find on StartPage pointed me in the direction of "fixing" the broken HID descriptor but the documentation for the format is a huge pain in the butt to find. Along the way though, I established that the interface being detected as a joystick isn't really responsible for anything important so I just made a udev rule to deauthorize it:

This link explains in detail exactly what you need to do (and to boot, it's older than all the advice I've seen regarding the HID descriptor) :

Also, shout out to whoever wrote the man page for udev clearly explaining the difference between ATTRS and ATTR because that was crucial to getting the rule applied correctly.

it will load 'udev', then i ask it to load 'udev-trigger' and it says "ok" and shows the prompt for whether to load 'modules' but is locked up completely.

as for why ? i have no clue - there's reports of bizarre edge cases in udev from a few years ago and bugs w/ the nouveau driver, but i'm running in a qemu vm and using vmware gpu emulation (not that it's doing anything beside acting as a framebuffer device)

LDM – Lightweight Device Mounter

Montare i dischi non è mai stato cosi facile grazie a questo è un piccolo programma di LemonBoy. LDM è un programma di montaggio che segue la filosofia UNIX ed è programmato in C e basato su udev e libmount. L’utente può utilizzare umount per smontare i dispositivi o il comando ldmc con l’opzione -r. ldmc -r Per installare il programma: Archlinux pacman -S ldm Voidlinux xbps-install -S…

La Policía Nacional ha detenido a once personas acusadas de encubrir al presunto asesino se su pareja en Elche

Agentes de la Policía Nacional de la Comisaría de Elche han detenido a once personas, siete mujeres y cuatro hombres, acusados presuntamente de dar cobertura y apoyo al presunto asesino de su pareja el pasado 25 de diciembre de 2021 en la ciudad de Elche. Según la investigación llevada a cabo por agentes de la UDEV de la Brigada de Policía Judicial de la Comisaría de la Policía Nacional en Elche…

I've been searching for a long time, and I finally figured out how to generate a libnotify event from a udev rule without hardcoding the username into the rule or script. The answer is actually pretty simple, and I'm very surprised I couldn't find the answer on any wiki or forum.

There was this ArchWiki entry which is no help at all. The author seemed to think you could insert a $USER variable into here "once you understand the example". What? If your generic example contains hardcoded elements it's a horrible example! /vent

Moving on.

I thought I might be able to use this blog's tutorial on how to start systemd services from udev for my purposes, but that quickly got very complicated and confusing. It took me an embarrasingly long time to realize this approach still requires a hardcoded username implemented somewhere. Womp womp.

I got the basic framework for my solution with the help of hackaday. They still hardcode the user, but thinking about what they did here caused me to arrive at the solution.

In their for loop, they iterate through every instance of their notification daemon. While I was cleaning up their useless use of grep, I wondered what that for loop actually accomplishes; are they expecting to have more than one instance of their notification daemon running? That doesn't make sense. My notification daemon of choice, dunst, doesn't even let you run it more than once per user. At which point it occurred to me, if this script is run as root, I can repurpose this for loop to iterate the search for a notification daemon through logged in users! I had to look up the who command as I had never seen it before, and from here the problem is solved. I no longer need to figure out which users to run notify-send as, I run it for every logged in user. Which makes sense for hardware events- all logged in users should be getting these notifications.

Now if only I could find a way to not hardcode the notification daemon.

/usr/local/bin/power_notify

#!/bin/sh # Display a notification for each logged in user user_notify() { users=$(who | awk '{print $1}') for user in $users; do # find DBUS session bus pid=$(pgrep -u $user dunst) export DBUS_SESSION_BUS_ADDRESS=$(sed -z -e '/DBUS_SESSION_BUS_ADDRESS/!d' \ -e 's/DBUS_SESSION_BUS_ADDRESS=//' /proc/$pid/environ) su -c - $user "$@" done } # udev 99-lowbat.rules case "$1" in "low") user_notify "notify-send -u normal 'Low Battery'" ;; "critical") user_notify "notify-send -u critical 'Low Battery' 'Find power soon!'" ;; "suspend") user_notify "notify-send -u critical 'Suspend Imminent' 'The system is going down in two minutes!'" sleep 120 systemctl suspend ;; "hibernate") echo "not implemented" ;; esac

/etc/udev/rules.d/99-lowbat.rules

My team is a combination of UNIX, Linux, and Database Administrators. There is usually a day or two where I have to interact closely with the database administrators for either setting up servers or assisting in providing more storage for them on already built servers.

We have mostly virtual machines running our informix databases. This is generally fine because we used cooked file systems and those are straight forward to setup. However, it’s a whole other ball game on new physical servers where we are not used cooked file systems. Basically, they want everything in “raw chunks”, similar to how we do our Oracle database servers.

Basically, I took the time to use multipath to manage the LUN’s presented to the server and name them accordingly. Example.

multipaths { multipath { wwid 360000970000195700675533030383046 alias ifxdwdba } ... (much more here, spanning to ifxdwdbz) }

So I figured this was fine and then I spent the time to script out a way to carve each of these LUN's up they wanted (long story short, these luns are 1TB each, and they wanted 20GB partitions each). Before I handed it off, I needed to come up with a way to give them full ownership of the devices as their user.

# cd /dev/mapper # for x in $(ls | egrep -v 'mpatha|control'); do printf "%s %s\n" "$x" \ "$(udevadm info --query=all --name=/dev/mapper/$x | grep -i dm_uuid| \ cut -d'=' -f 2)" >> /tmp/info; done # for x in $(cat /tmp/info) ; do echo "KERNEL==\"dm-*\",ENV{DM_UUID}==\"$x\",OWNER=\"informix\",GROUP=\"informix\",MODE=\"0660\"" >> /etc/udev/rules.d/99-informix.rules ; done # udevadm control --reload-rules

This seemed to work and they were in business. Or so I thought.

Turns out that Informix is picky on the storage you give it. It expects character devices, not block devices. My initial thought was that all disks should just be block devices and that character devices were for things like printers, sound cards, etc, not for disks. Informix doesn't care; it wants its storage to be "raw", and the "raw" way to do it is to be a character device.

An easy way around this is to do something like raw /dev/raw/raw1 /dev/dm-7. However, that's tiring, especially with lots of partitions. And plus, you can't dictate the name of the "raw" devices we're making. So I decided there needed to be a better way, for me and my database admins.

At the bottom of my udev rules, I put similar rules to this (note, you will need to run the command yourself and find the "result" first).

ACTION=="add",KERNEL=="dm-*",PROGRAM=="/usr/lib/udev/scsi_id -g -u -d %N",RESULT=="360000970000195700675533030383046",RUN+="/usr/local/sbin/udevlinker %n %N" ... (others) ACTION=="add",KERNEL=="raw*",OWNER="informix",GROUP="informix",MODE="0660"

Basically what the %n means is "minor" number. Each device on a system gets a major and a minor number. Major being the device type, minor being the number of the device. The %N variable is the full path of the block device. If you actually look, the minor numbers are represented on the dm-* devices in /dev.

Normally the RUN that others use is the raw command directly. Instead, I used a script of my own. On top of that, I ensured any "raw" devices that get added to the system, the informix user will own them.

#!/bin/bash # /usr/local/sbin/udevlinker MINOR=$1 BLPATH=$2 DMNAME=$(ls -l /dev/mapper | awk "/dm-$MINOR$/ { print \$9 }") /bin/mkdir -p /dev/ifx /bin/raw /dev/raw/raw$MINOR $BLPATH /bin/ln -sf /dev/raw/raw$MINOR /dev/ifx/$DMNAME

The script above is the one in question. I ensured that it would take in the minor number and the block device path. It would also take the time to look at the minor number and compare it to the list of multipath symlinks in /dev/mapper and find the appropriate name. That way, I can make a symbolic link in /dev/ifx that leads to the correct /dev/raw/* device.

Once I had put everything together, I ran udevadm control --reload-rules and then udevadm trigger --action=add. This was a success. The raw devices got created and the symbolic links did too.

# ls -l /dev/ifx | head total 0 lrwxrwxrwx. 1 root root 13 May 12 00:26 ifxdwdba -> /dev/raw/raw8 lrwxrwxrwx. 1 root root 14 May 12 00:26 ifxdwdba1 -> /dev/raw/raw54 lrwxrwxrwx. 1 root root 15 May 12 00:26 ifxdwdba10 -> /dev/raw/raw111 lrwxrwxrwx. 1 root root 15 May 12 00:26 ifxdwdba11 -> /dev/raw/raw114 lrwxrwxrwx. 1 root root 15 May 12 00:26 ifxdwdba12 -> /dev/raw/raw125 lrwxrwxrwx. 1 root root 15 May 12 00:26 ifxdwdba13 -> /dev/raw/raw130 lrwxrwxrwx. 1 root root 15 May 12 00:26 ifxdwdba14 -> /dev/raw/raw137 lrwxrwxrwx. 1 root root 15 May 12 00:26 ifxdwdba15 -> /dev/raw/raw151 lrwxrwxrwx. 1 root root 15 May 12 00:26 ifxdwdba16 -> /dev/raw/raw152 # ls -l /dev/raw | head total 0 crw-rw----. 1 informix informix 162, 100 May 12 00:26 raw100 crw-rw----. 1 informix informix 162, 101 May 12 00:26 raw101 crw-rw----. 1 informix informix 162, 102 May 12 00:26 raw102 crw-rw----. 1 informix informix 162, 103 May 12 00:26 raw103 crw-rw----. 1 informix informix 162, 104 May 12 00:26 raw104 crw-rw----. 1 informix informix 162, 105 May 12 00:26 raw105 crw-rw----. 1 informix informix 162, 106 May 12 00:26 raw106 crw-rw----. 1 informix informix 162, 107 May 12 00:26 raw107 crw-rw----. 1 informix informix 162, 108 May 12 00:26 raw108

However, there was one small problem. When the system is booting up, there is no proper multipath names in mapper by the time udev is doing its job. This means the symbolic link that gets created is literally named the same as the raw device we're linking to.

There's two options. I could enable rc.local (since this is on RHEL 7) or make a one-shot. Either way, we can get the same accomplished. I made a one-shot like this.

# cat /etc/systemd/system/udevlinker.service [Unit] Description=udev linker After=network.target remote-fs.target nss-lookup.target [Service] Type=oneshot User=root ExecStart=/bin/sh -c 'sleep 3 ; /bin/rm /dev/ifx/* ; /usr/sbin/udevadm trigger --action=add' [Install] WantedBy=multi-user.target

This ensured that after all of these targets were reached, I would go and re-run the udev trigger after deleting all of the "bad" links. This definitely helps on reboots.

For my RHEL 6 guys or people who want to use rc.local, you can do similar.

sleep 3 /bin/rm /dev/ifx/* /usr/sbin/udevadm trigger --action=add