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@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@xxxxxxxxxxxx
