Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?

[Owen Taylor <otaylor redhat com>]

jg pa dec com (Jim Gettys) writes:

> Owen:
> 
> This is certainly true: but not sufficient...

I wasn't trying to give a complete solution, just trying to dispell
any notion that interactivity with hotplug events would necessarily
involve popping up a root shell on the current login users desktop :-)
 
> Here's the sequence as I understand it:
> 
> 1) new device gets plugged in.
> 2) system has to figure out what driver to use.
> 3) if it has seen it before, presumably it can consult some sort of database
>    to help hook it up, both by whatever driver parameters it needs, and to hook
>    it up to a user level program it activates.  We're done at this point.
> 4) if the system has never seen it before, we have to somehow ask the user
>    what to do.
> 5) the driver finally gets loaded, with the user specified configuration
>    information that might be required.
> 6) record the necessary driver configuration, and go to 3).
> 
> So what we need is a convention whereby the hotplug framework activates
> a GUI component talking to the user somewhere on the network to get
> the configuration data required, and a way to communicate that configuration
> information back to the hotplug system to record for future use (and completion
> of the first hot plug event for that device).
> 
> So the hotplug scripts (running as root) have to be able to initiate the
> GUI talking to the user, and get data back from there.  And it isn't
> necessarily on the same system, as hotplug is not all about human interface
> devices: it is also used for disk drives, tapes, etc, and eventually pluggable
> processors, memory etc.
>
> So we have two problems:
>     o A convention of how to know who is administering this system.  It may
>     be this is something just for the hotplug folks to worry about.
>     o How to securely  get the right configuration back and forth from the user;
> this is the authentication problem, in concert with how to get data back
> and forth...

I think it probably makes sense to reduce the communication to one of
notification.

 - In response to the hotplug event, if the device can't
   be configured automatically, record that data, and
   notify the appropriate user(s).

 - When the user gets the notification, present them with the
   option to run a config tool, which would then complete
   the configuration.

This has various advantages; principally.

 - It's flexible (notification could be sending an email
   saying "go to this URL to configure your new printer.)

 - It reduces the authentication problem to a known and 
   solved problem. (Can user X do Y.)
   
In terms of how to do notification, you can go from simple to complex:

 - Watch a file in a timeout. (We had hotplug for USB storage
   devices in Red Hat 7.1 working quite nicely by watching
   /etc/fstab for changes; kudzu added new entries in 
   response to hotplug events. magicdev noticed the
   changes, signaled mc which added icons on the desktop.)

 - Local messaginge daemon; if you keep it simple, use unix
   perms, don't worry to much about quality-of-service, etc,
   it doesn't need to be a big project.

 - Networked based messaging; jabber, etc. May make
   sense to piggyback off an existing solution. But then
   you get the problem that you are talking about something
   big that everybody needs to adopt.

Anyways, just my random thoughts on the issue. My main observation is
that I think it's a mistake to think of this as "hotplug script pops
up a configuration dialog" even if it might appear like that to the
user in the simplest case.

Regards,
                                        Owen