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

For more information about how hotplugging works today,
see ... the "overview"
link should be informative, and the section on full automation
versus user input relates to this discussion.  So far there's
no user input, and many subsystems don't hotplug yet.
That means that a lot of things are left undone.

> 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).

I tend to think of the hotplug system as being an interface to the native
system administration mechanism, so things like print spooler setup
don't get sucked in to it.  FWIW.

Both will need more work to cleanly handle things like plugging in a
USB printer, and getting it set up without the user needing to grot
around in some quirky sysadmin UI to find the "USB printer setup"
section (and then fill it in with information that's already available
to the system if it were smart enough to ask for it :).

> 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.

And, unfortunately, each Linux distro's sysadmin tools.

>     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...

Well, authorization -- not all systems are "closed" to the extent
that only authorized users can be authenticated!  :)

- Dave

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]