[meego-fi] Re: Requesting help with a small scripting task for Summit preparations
- From: Jarkko Kniivilä <jkniiv@xxxxxxxxx>
- To: Jarkko Moilanen <jarkko.moilanen@xxxxxxxxxxxxxxx>, Topi Santakivi <topi.santakivi@xxxxxxxxx>
- Date: Sat, 9 Apr 2011 19:09:47 +0300
Moi to all,
I managed to finalize a version of the MeeGo FI developer content
copier scripts. Please find attached two small .tar.bz2 archives with
files for /etc/service (runit service directory) and /etc/udev/rules.d
(udev rules). To install, just extract these archives with 'tar -jxf
archivename.tar.bz2 -C /'. You may want to review the contents first
but these shouldn't overwrite anything in a pristine installation of
Ubuntu Maverick (10.10).
Theory of operation is as follows. The udev rules make sure that 1)
usb storage devices connected to specified models of usb hubs won't be
automounted by the udisks daemon
(/etc/udev/rules.d/99-meegofi-no-automount.rules), and that 2) these
same storage devices when added or removed will fire or kill the
content copier service respectivly
(/etc/udev/rules.d/10-meegofi-copier-start-stop.rules).
The content copier service -- or rather services because there is one
for each 10 possibl block device from sdb1 to sdk1 -- is implemented
with rsync and runit. In runit lingo the services are normally marked
down (there is an empty file name "down" in each service directory)
but are triggered to run once for each udev "add" action of matching
usb block devices (i.e. for those usb sticks we decide to attach to
the specific hubs identified by vendor and product id). Accordingly
the services are forced down when there is a udev "remove" action.
Specifically the runit per service "run" script looks like this:
#!/bin/dash
sourcedir=/home/jkniiv/MeeGo.FI-stick
# [...] Some setup like mounting and trapping the TERM signal
DISPLAY=:2 gtkrsync -rtv --progress --no-inc-recursive ${sourcedir}/
/mnt/${devbase}/
The udev line triggering this is:
KERNEL=="sd*", SUBSYSTEM=="block", ATTRS{idVendor}=="1a40",
ATTRS{idProduct}=="0101", ACTION=="add", RUN="/usr/bin/sv o
meegofi.copy.to.%k"
So for instance if there is a new usb stick called /dev/sdb1 that
matches the criteria of being attached to a hub with the vendor and
product codes above, udev will run "/usr/bin/sv o
meegofi.copy.to.sdb1", which translates to "start the SerVice
meegofi.copy.to.sdb1 Once". When the stick is subsequently removed
from the hub, udev will run "/usr/bin/sv d meegofi.copy.to.sdb1" which
will TERMinate the copying process if its still going on.
There is a matching per service "finish" script that unmounts the
volume after "run" has finished. Naturally this won't occur if
somebody yanks the stick out amidst copying, in which case one must
unmount the devices manually. In fact one should always check out the
printout of 'mount' after a set of copying has completed. If there is
a problem, one should "mkfs.vfat -F 32" the sticks and let the copying
start over by detaching and attaching the sticks.
Now bear with me, but there is still one small matter to discuss, that
is how to monitor the progress. I decided it was best to (ab)use X for
this. Yes, the services are run as root but this shouldn't be a
problem if we choose our tools right. First, there are two graphical
frontends for rsync -- grsync and gtkrsync. Only the latter is suitabl
for scripting as it takes all of its parameters from command line and
passes them to rsync as is. The user can only ok or cancel the
operation but not change it in any way.
Yet, where do we send our ten windows while they are showing their
copying action? Not to the main display, i hope, or there is a risk of
prematurely killing some copying tasks. What I decided to do is to run
another X server, in this case the nested one called Xephyr. It
becomes the display number 2 by the following invocation:
$ Xephyr :2 -screen 1280x800 &
We need a window manager too and 'awesome' as a tiling manager is
sufficiently different from GNOME/Metacity that you won't mistake the
copying windows for those run under your own credentials.
$ DISPLAY=:2 awesome &
So finally here is the list of prerequisites for running this arrangement:
# aptitude install runit gtkrsync awesome xserver-xephyr
Happy hacking, regards,
// Jarkko aka 'jibun'
On Tue, Apr 5, 2011 at 19:00, Jarkko Moilanen
<jarkko.moilanen@xxxxxxxxxxxxxxx> wrote:
> Great!
>
> 2011/4/5 Jarkko Kniivilä <jkniiv@xxxxxxxxx>
>>
>> Moi,
>>
>> I'm willing to try. I hav a four-port hub, so I can try to script with
>> that. Hopefully I will hav a version ready by the next volunteer meeting
>> (Apr 11) so we can test it with the 10-port one (which based on the
>> lsusb-output you provided seems to hav a four-port and a seven-port one
>> chained together).
>>
> Yeah, the hw implementation of USB hub seems to be that....something :) I'm
> not an expert on this.
>
>>
>> I think we need the copying to be spawned into background and include some
>> logging so I think we should employ DJB daemontools[1] or Gerrit Pape's
>> runit[2], whichever happens to be more convenient. Copying itself could be
>> via rsync or unison as to be the most robust possible. Finally I would write
>> the udev script in python or perl.
>
> You seem to have a plan, so I'd go with that.
>>
>> Btw, I hope the hub has an external power supply as the USB 2.0 default
>> ampeerage of 500mA is probably not enuff for 10 usb sticks to be pounded
>> simultaneously. :)
>>
> It haz own power supply.
> Thanks for the input :) And see you the 11th.
> /Jarkko
>
>>
>> Cheers,
>>
>> // Jarkko Kn. aka 'jibun'
>>
>> [1] http://cr.yp.to/daemontools.html
>> [2] http://smarden.org/runit/
>>
>>
>> On Mon, Apr 4, 2011 at 13:13, Topi Santakivi <topi.santakivi@xxxxxxxxx>
>> wrote:
>>>
>>> Hi.
>>>
>>> The summit is coming in < 2 weeks from. We'll be offering
>>> a developer USB stick containing tools, MeeGo images
>>> and additional information to all attendants.
>>>
>>> There are 350 USB sticks coming by mail, and we'll have
>>> to copy the content to the sticks semi-manually, using 2
>>> 10-port USB hubs.
>>>
>>> To help with that task, there's a need for a bit scripting.
>>>
>>> Here's what's needed:
>>>
>>> 1. Create a udev rule saying
>>> "When a USB stick is attached to the hub, copy loads of
>>> data into it"
>>>
>>> 2. Copying part with an one-liner command or a script.
>>>
>>> udev info for the hub:
>>> http://piratepad.net/1qAl8xTFxr
>>>
>>> A great guide on udev rules:
>>> http://www.reactivated.net/writing_udev_rules.html
>>>
>>> Any takers?:)
>>>
>>> BR,
>>> Topi
>>>
>>
>>
>>
>> --
>> Jarkko Kniivilä < jibun | jkniiv >
>> FIN-13100 HÄMEENLINNA
>>
>> "Panta rhei kai oumen menei" -- Herakleitos
>
>
>
> --
> ---------------
> Community Manager (MNFI, Meego Network Finland)
> Organizer (TMN, Tampere Meego Network)
> Email: jarkko dot moilanen at meegonetwork dot fi
> Location: Tampere, Finland
>
> More info: http://meegonetwork.fi
> Discussions: irc.freenode.net#meego-fi
> http://meego.ajatukseni.net/
>
--
Jarkko Kniivilä < jibun | jkniiv >
FIN-13100 HÄMEENLINNA
"Panta rhei kai oumen menei" -- Herakleitos
Other related posts:
