ThePrescription

  • Launchpad Entry: theprescription

  • Created: 2006-04-17 by Borisbatkin

  • Contributors: Borisbatkin

  • Packages affected:

Summary

We need to streamline the process of applying solutions to miscellaneous Linux problems. Copy-paste to the terminal window is not the answer.

Rationale

Currently there is a usability gap between finding the solution to the specific Linux problem, and actually solving it. Often times it involves copying and pasting reasonable amounts of shell commands into the terminal window. The process is tedious, error prone, and insecure; it does not provide any formalized way to leave feedback.

We need to get it down to one click in the web browser.

We can't just have a shell script running on demand in one click because it will result in major security risk.

We need a bit more usability then an “OK?” dialog. Reporting progress for the long scripts is essential. Asking confirmation every once in a while is a common practice too.

It all started with this thread. http://www.ubuntuforums.org/showthread.php?t=158925

Use cases

  • User wants to apply “how to install extra fonts” from Ubuntu staring guide ( http://ubuntuguide.org/#extrafonts ). He double-clicks on the special icon on the web page, sees the installation progress window, clicks “OK” on the completion dialog.

  • User wants to install support for i860 printer. He finds the solution at Ubuntu forums ( http://www.ubuntuforums.org/showthread.php?t=10540&highlight=canon+i860 ). He double-clicks on the special icon on the web pages, answers “Yes” on “Are you sure you want to run unconfirmed prescription?”. If printer runs fine he may later choose to answers “Yes” on the “Did the prescription help?” dialog.

  • Experienced user can't hear any sound in Quake-3. He finds the solution at http://www.linuxquestions.org/questions/showthread.php?t=260975 . He tries it and it works. He now wants the solution to be “one click” for everyone else. He makes a shell script, adds framework support and submits in the web interface. He then posts the link to the prescription at the place where he found a solution.

Scope

The prescription deals with short solutions to miscellaneous Linux problems, which can be easily addressed from the short (several lines, not several pages) shell script. It does not try to provide alternative to package installation solutions, but it may call them.

Design

The Prescription

The prescription is a combination of the shell script and the set of keys. User can only run the prescription if he has appropriate key, of if the prescription is unsigned. The prescription provider needs to register to obtain the unique key.

Each user can send feedback on the specific prescription. The Runtime will require a confirmation on running prescriptions with short or negative history.

The Runtime

The runtime is responsible for providing the GUI front end between the prescription and the user. It displays progress, confirmation, select, error, and feedback dialogs.

The runtime provides series of shell commands to report progress and errors, as well as to request confirmations.

The Runtime manages the key-chain. It involves downloading the keys on demand as well as specifying “trusted” and “compromised” keys.

Integration

The runtime can be called by the browser plug-in as well as by window manager. Double-clicking the prescription in the browser should cause “download and run” behavior.

Implementation

Key management

The idea behind the key management is that user can't automatically run any questionable prescription. Prescription is signed by the prescription provider key (PGP?).

Prescription from a known provider will run in one click.

User can choose to run the unsigned prescription, or to download the key. But he has to do that explicitly.

Key management is handled by the runtime.

Initial set of keys is provided during installation. That will help to differentiate between different versions of the packages. For example Kubuntu 5.10 specific key is not provided on Ubuntu 5.10, so that Kubuntu 5.10 specific prescription needs to be signed by Kubuntu key to run in one click.

Each prescription can be signed with multiple keys. Prescription will run automatically if at least one of the keys match. For example any prescription which is signed by Common 5.10 key will run in one click on both Ubuntu 5.10 and Kubuntu 5.10.

Version control

When prescription provider fixes the bug in the prescription, he automatically rolls up the version number. By default user only sees the feedback for the last version, but he can explicitly look at the rating history on the prescription web page.

Prescription file

Prescription file is a tar archive which contains prescription description file with unique prescription ID, the shell script, the keys. It can run locally without any Internet connection whatsoever.

When connection to centralized prescription database is available and enabled user can get certain additional features automatically:

  • Download newer version of the prescription
  • Display rating information
  • Leave feedback
  • Check prescription web page and user comments

The Runtime

The idea behind the runtime is that the default behavior provides reasonable usability level around the shell script without any modifications.

There is an additional limited set of GUI features which is available to the prescription provider. If the prescription requires custom GUI, it's the sign that the problem should be addressed in a manner other then prescription.

The Runtime consist of

  • The Web browser integration
  • Main window
  • Error reporting
  • Feedback dialog
  • Confirmation dialog
  • Select dialog
  • Key chain dialog
  • Rating dialog
  • Password dialog
  • Reboot dialog

The Web browser integration

User can double-click on the prescription to run it.

The prescription icon is different for the signed and the unsigned prescription. The prescription with the negative feedback has different icon too.

Main window

Main window provides information on the progress of the prescription. It consists of the main and the secondary progress bars and the status string.

The main progress bar is reporting the progress withing the shell script. It's handled automatically.

The secondary progress bar is for the user to report the progress. It stays hidden by default and only shows up if user sets it value by calling

prescription-progress “text on the bar” percentage_complete

or

prescription-progress “other text” elements_done total_elements

Prescription provider can change the status string by calling

prescription-status “status string text”

After the prescription is successfully completed, the “OK” and “Leave feedback” becomes available on the same prescription dialog.

If the prescription failed the error reporting dialog shows up automatically.

The runtime automatically detects if prescription-status and prescription-progress commands are used in the script, and creates the dialog of the appropriate size with all the necessary elements required.

Error reporting

Error reporting window consists of an error message with the description, an output log, “OK” and “Feedback” buttons.

Prescription provider can cause error dialog by calling

prescription-error “error description”

Calling prescription-error always terminates the prescription script.

Feedback dialog

Feedback dialog provides user with options of leaving

  • Positive feedback (prescription worked)
  • Negative feedback (prescription reported no errors but the solution did not work)
  • Bug report (log is attached)

User can also add user comments or go to the prescription web page. Prescription web page provides prescription information, rating, other user comments. Prescription provider can't force feedback dialog. However user can force prescription dialog for the last prescription. (Should we provide prescription history?)

Confirmation dialog

Confirmation dialog consists of the request, “Yes”, “No” and “Cancel” buttons. Prescription provider can use confirmation dialog by calling

prescription-yes-no “Are we there yet?”

or

prescription-yes-no-cancel “Quit smoking?”

Prescription provider specifies cancel option only if he needs to perform some additional operations on cancellation. By default pressing cancel will stop the prescription.

Selection dialog

Selection dialog consist of the request and the options. Prescription provider can use the selection dialog by calling

prescription-select “What's your favorite color?” “Red” “Green” “Blue”

or

prescription-select-cancel “Delete which account?” “User” “Root”

Prescription provider specifies cancel option only if he needs to perform some additional operations on cancellation. By default cancel will stop the prescription.

Key chain dialog

Key chain dialog is called when user tries to run the prescription, for which he does not have a key or when he ties to run unsigned prescription. It provides an option to download the key or to run the prescription unsigned.

Prescription provider can't force key chain dialog. It's handled automatically.

Rating dialog

Rating dialog is called when user tries to run the prescription with short or negative feedback. It provides an option to run the prescription, to look at the prescription's web page, or to cancel.

Prescription provider can't force rating dialog. It's handled automatically.

Password dialog

Prescription provider calls password dialog if the shell scrip needs to call sudo. Password dialog asks for the root password and feeds it into the sudo.

Prescription provider can force password dialog by calling

prescription-password

Prescription provider should call prescription-password at the beginning of the script after the necessary confirmations.

The runtime automatically detects if sudo and prescription-password are used in the script. If sudo is used in the script and there is no prescription-password statement, the password dialog will be called automatically at the beginning of the script.

Reboot dialog

Prescription provider calls reboot dialog if the shell script requires reboot to apply changes. Reboot dialog is the last dialog called in the script. It gives user an option to reboot later. (Do we need some sort of reboot reminder?)

Prescription provider can force reboot dialog by calling

prescription-reboot

Outstanding issues

Centralized prescription search engine, prescription database with access rights, global key management and distribution.

CategorySpec CategorySpec

Comments

  • Killer Kiwi: I think there is linkage/crossover here with what ThirdPartyApt is trying to achieve (i.e. prescriptions could be used to trigger apt install easily maybe be a prescription-apt-install) also the zenity package already provides many of the dialogues. 2 Kiwi: Boris Batkin: what would be the difference between sudo apt-install and prescription-apt-install?

  • Sound problems are generally broken down into two categories, 1) misconfiguration, 2) unsupported hardware. It is straightforward to compile a "database" of known issues and possible workarounds/resolutions for (1) and (2), but the problem quickly becomes exponentially difficult if the user has attempted to modify system-wide or user-specific conffiles. In this latter case, we need to restore to a known-good state, e.g., reloading ALSA modules after removing /var/lib/alsa/asound.state or moving system-wide/user-specific conffiles, before continuing. The question then becomes, "Do we allow said 'prescription' to modify a certain subset of files", namely ones that have been traditionally off-limit to maintainer scripts. For (2), there is no point and click solution possible; the user must seek assistance via the (currently) IRC channel, mailing list, forum, and so on.

  • * Actually, I think for (2), it may be possible the provide a prescription solution. There may exist a driver on sourceforge for the unsupported hardware that has yet to find its way into the supported/released kernel. It should be possible to create a prescription that downloads, compiles, and installs the third parrty driver -- MichaelRHead.

  • John Mccabe Dansted: Perhaps prescriptions should start out as just MIME types? This would also mean that users could use prescriptions from unsupported web-browsers, although they would require 2-3 clicks instead of one.

  • John Mccabe Dansted: Perhaps prescriptions should be signed with a particular Title/Purpose. If e.g. Prescription is signed with the title "Activate Telnet Server", and the users are asked "Do you want to: Activate Telnet Server" then users are less likely to be tricked into doing things like this that are legitimate yet potentially dangerous when they actually want to do something safer. 2 John: Boris Batkin: I can't think of the way to protect user from false signatures. So my idea is we give each prescription provider a key and allow user to leave feedback. So only few users can be tricked. I also don't see how I can automate signature verification. I.e. can't think of anything which prevent "Activate TelnetServer" from formating the HDD. Perhaps access restrictions of some kind? 3 Batin: John McCabe Dansted My concern was more that:

  • someone would write a script "Reformat HDD and Reinstall Windows",
  • the Ubuntu team go "yep that'll reformat the harddisk nice and good" and sign the package
  • some malicious attack links to the prescription claiming it fixes sound. I understand that Windows ActiveX controls have the problem that once a single dangerous ActiveX control has been signed, anyone can activate it and subvert the machine, I was thinking of ways of avoiding this. But... it also seems like it would be good to give the user an idea how dangerous the script is, e.g. apt-get [package] seems fairly safe. Encouraging prescription writers to explicitly limit the access rights of their

prescriptions with something like Plash or Systrace so that they are provably safe, where possible, would also be nice.

  • John Stowers: Have you seen EveryGUI. I believe there is a lot of synergy between the two projects, not with their design, but with the need they are trying to fill.

  • John Mccabe Dansted: Perhaps a Prescription should just be a signed Makefile that uses Zenity to interact with the user? This could make the implementation much simpler.

ThePrescription (last edited 2008-08-06 16:29:43 by localhost)