[NCLUG] Help w/udev rules

[Andrew Gilmore]

I had a similar problem, where my 8 bay iSCSI library would present
different bays in different orders on login/logout of the connection.

I ended up finding unique SCSI identifiers in the device ids, and added
lines like this to a udev rules file:

BUS=="scsi", SYSFS{vendor}=="TANDBERG", SYSFS{model}=="RDX", KERNEL=="sd?",
PROGRAM="scsi_id --whitelisted --replace-whitespace -p0x83 -d $tempnode",
RESULT=="1TANDBERGRDX_<ID>", SYMLINK+="rdxa"
BUS=="scsi", ENV{DEVTYPE}=="partition", KERNEL=="sd*", PROGRAM="scsi_id
--whitelisted --replace-whitespace -p0x83 -d /dev/$parent",
RESULT=="1TANDBERGRDX_<ID>", SYMLINK+="rdxa%n"

That way, although the system knows the device by /dev/sdf right now, I can
also eject  /dev/rda and get the right bay to eject, no matter what
cartridge is in the bay. I can also mkfs /dev/rdxa1 and know I'm not
blowing away my current backups (after kpartx -a).

I ended up hardcoding 8 different device ids into udev rules like this, and
that was a bit painful, but over now. If the library ever dies, or a drive
needs replacing, this will need to be updated.

I too would welcome more elegant solutions, but this one works.

Andrew

On Wed, Sep 25, 2013 at 12:00 PM, <nclug-request at lists.nclug.org> wrote:

>
>
> Today's Topics:
>
>    1. Re: Help w/udev rules (Maxwell Spangler)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 24 Sep 2013 13:34:41 -0600
> From: Maxwell Spangler <maxlists at maxwellspangler.com>
> To: Northern Colorado Linux Users Group <nclug at lists.nclug.org>
> Subject: Re: [NCLUG] Help w/udev rules
> Message-ID: <1380051281.23178.52.camel at elite.fossil>
> Content-Type: text/plain; charset="UTF-8"
>
>
> On Tue, 2013-09-24 at 00:30 -0600, Stephen Warren wrote:
>
> > On 09/24/2013 12:21 AM, Maxwell Spangler wrote:
> > > On a backup server I have two external USB docks.  I'm writing scripts
> > > so a user can install new offsite backup drives and tell the computer
> to
> > > make them available to receive backups.  Another script will copy the
> > > appropriate backup files to the drives.  For the backup script to work
> > > consistently, I want to present the removable storage in a predictable
> > > manner.
> > > ...
> >
> > This perhaps isn't an answer to your question, but I would instead
> > propose using partition or filesystem UUIDs to identify the block
> > devices, rather than attempting to make each device have a fixed name.
>
>
> Thanks to several posters who suggested the same: using filesystem
> labels and accessing offsite backup drives using device mapper entries
> in /dev/.
>
> However, I think using udev is the right approach for a couple of
> reasons.
>
> * I have two docks and they are not identical: one is slow USB2 and one
> is fast USB3.  I want the comfort and easy of being able to "quickly"
> copy 600G to the USB3 drive by mounting whatever drive is
> in /dev/usb3dock and knowing I'm using the faster dock.
>
> * All my drives will be labeled properly as offsite backup drives but I
> can't predict in which dock they will appear.  So a 2TB drive that
> yesterday was in the USB3 dock might get moved by someone on site (other
> than me) to the USB2 dock.  If I don't check, I might start using the
> slow dock, show up on site to collect it only to discover it has hours
> of copying left to complete.
>
> * If I do recognize a drive by filesystem label and want to walk the
> chain of tools to discover where it is I think I'll be doing the same
> amount of effort I've done with udev.
>
> When I stopped working on this late last night it appeared as though my
> udev solution was working perfectly and the only confusing thing was the
> debugging information in my script that scans for partitions on new
> devices.  When a udev event is triggered for /dev/sdf (one of my docks)
> it creates the /dev/usb3dock symlink I want, triggers my script to run,
> and then triggers 5 more udev events as partitions are found and
> additional /dev entries are made.  If I remove the debugging and ignore
> what's going on behind the scenes everything.. just works.
>
> Thanks for the input. If anyone has other ideas, please share.  I'm not
> a big fan of re-inventing the wheel.
> --
> Maxwell Spangler
> ========================================================================
> Linux System Administration / Virtualization / Development / Computing
> Services
> Photography / Graphics Design / Writing
> Fort Collins, Colorado
> http://www.maxwellspangler.com
>
>
> ------------------------------
>
> _______________________________________________
> NCLUG mailing list
> NCLUG at lists.nclug.org
> http://lists.nclug.org/mailman/listinfo/nclug
>
> To unsubscribe, subscribe, or modify
> your settings, go to:
> http://lists.nclug.org/mailman/listinfo/nclug
>
> When replying, please edit your Subject line so it is more specific
> than 'Re: Contents of LUG digest...'
>
> End of NCLUG Digest, Vol 395, Issue 2
> *************************************
>