[Yum] Enhancing the potential of yum to support commercial enterprise...

[Robert G. Brown]

An observation.  For the convenience of those unfamiliar with my style,
a 

<summary>  

I think yum could use:

  a) At least two authentication mechanisms; userid/passwords as
discussed and another that uses a keypair or cookie assigned by the
repository manager and that could be read out of a 600 file e.g.
/etc/yum.key or $HOME/.yum.key.  This latter would permit nightly
updates from anywhere independent of source IP address in an automated
script on a user-specific and user-logging way without needing expect or
user presence.

  b) A fully userspace mode, that uses rpm's --relocate feature to
install rpm's built to be relocatable into paths in the user's
personally writeable space.  This latter would enable yum to be used by
vendors to distribute and update valuable data to ordinary users --
together with a) in a controlled and accountable way.

</summary>

To see how this would work, consider:

Vendor A produces a product that is basically data, for subscription or
sale.  This is perfectly consistent with the open source model -- the
data requires fairly regular updates to remain current and the vendor
performs a real service involving investment and work on their part to
their customers.  The data is valuable, and open access to the data is
quite reasonably provided only to customers who have purchased it,
controlled by e.g. an account userid and password.  Finally, the vendor
would LIKE to be able to make the update process automagical -- to have
customers' systems authenticate the customer, download the data update,
and run an auxiliary program or script to "install" it for use in what
might well be an open source application (although of course it might
not be).  

Thus this is very relevant to the open source model and possible
business applications thereof, where software is considered something
that should be openly available but data can have real resale value
consistent with the effort required to produce and support it.
"Valuable" data ranging from databases to music images are candidates
for subscription or single sale distribution that are potential content
for open or closed source software in linux or other rpm-ified unices.

Yum clearly could form a key component of a linux/unix/rpm distribution
mechanism for vendor A.  If vendor A packaged the data updates in rpm
form, rpm's can do "everything" required for a consistent update.  They
have incremental revisions, architectural variation, obsoletes and so
forth as intrinsic features, and even can be built to distribute
encrypted files that can only be locally decrypted with the appropriate
local key. They can encapsulate any number of files in a possibly
relocatable tree.  They can execute %post scripts to finish actually
connecting the new files to their associated software packages, if
necessary.  rpm's are "perfect" for this purpose by design; yum is
(almost) "perfect" for the distribution and automated update process.

The only elements that might be missing to fully support this scenario
are (as noted above but in more detail):

  a) Authentication -- the ability to permit access to a repository
based on a variety of mechanisms.  At minimum userid/passwd (as has been
discussed already on the list) but it would ALSO be lovely to have a
mechanism where a user maintains a public/private keypair or cookie in a
file, assigned by and recognized and logged by the vendor, that could be
used to authenticate user connections without an interactive session at
all, so that nightly or on-demand automagic updates don't require the
user to be present or an expect script.  The vendor assigned information
might also even include a window during which updates from the customer
can be delivered, permitting them to load balance!

This is not just valuable to potential data vendors.  It could also
obviate the need for the currently tedious and kernel-tainting vpn or
expert-friendly ssh tunnels for offsite users of e.g. Duke's or others'
private repositories (a cross I currently bear, as I'm just getting
ready to figure out how to hotwire yum so that all my old 7.3 hosts at
home can once again get to linux at duke, now that they are no longer
coming from a duke IP number).  It would be simply lovely to have a "yum
key" in /etc/yum.conf that identified me as me and let me get to the
restricted repositories.  It would also (I think) be nice for the keys
to come with a temporal "yum window" that permitted Seth to spread the
load of all the installs out in a very precise way (of course still
permitting immediate use as well from the command line).

  b) Userspace access, with relocation.  The ability to run yum from
userspace, updating into (home directory) local paths, with one or the
other of the aforementioned authentication mechanisms in place.  Note
that this is a slightly different application from those considered
before where userspace was rejected because the repositories in question
had large header lists and required large rpm caches and in any event
were updating root-owned paths.  This would use rpm's --relocate flag to
install the appropriately built rpm's into a selected path in the user's
home directory, most likely.

A specific example of this could be a vendor of a medical/drug database
for palm pilots, along with the palm software required to access the
database.  A customer purchases a subscription to the database.  The
database itself is quite volatile, with drugs being added and updated
information on toxicity and effectiveness being merged.  We all would
RATHER our doctors had access to the latest data, but the doctors (even
those that use linux) are likely to be fairly clueless about low level
tools, scripts, and anything complicated, so the vendor needs to sell
them a "completely encapsulated" solution for updating.

The actual software used to do the palm update on the linux side is all
open source -- it is just a matter of automagically retrieving the prc's
and prb's in the right place for jpilot or pilot-tools to be able to
manage them.  Yes, it could all be scripted, using e.g. wget and some
cooked-up authentication mechanism, but yum already IS the required
scripting done far better than one would ever likely do it alone, except
for the two features above.

Just a thought or a suggestion.  The public/private keypair idea I think
is worth pursuing independently just for Duke, if nobody else has a use
for it.  Adding userspace access (necessarily combined with a relocate
option into space the user can write, and with header and cache ditto)
is less useful locally but also shouldn't be horribly difficult.

  rg-still-holding-out-on-python-but-not-for-long-b

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu