Difference between revisions of "ReactOS Update"

From ReactOS Wiki
Jump to: navigation, search
(Package Management)
Line 119: Line 119:
  
 
As Linux and MS Windows have developed a method of updating over some time now - are there any shortfalls in currently adopted methods? We should aim to devise an update mechanism that takes the best aspects of WindowsUpdate and linux package management (such as rpm). The package management utility should have a duty to keep track of orphaned packages/files/libraries. --[[User:Rebroad|Rebroad]] 17:59, 31 Mar 2005 (CEST)
 
As Linux and MS Windows have developed a method of updating over some time now - are there any shortfalls in currently adopted methods? We should aim to devise an update mechanism that takes the best aspects of WindowsUpdate and linux package management (such as rpm). The package management utility should have a duty to keep track of orphaned packages/files/libraries. --[[User:Rebroad|Rebroad]] 17:59, 31 Mar 2005 (CEST)
 +
 +
Perhaps, this article, and [ReactOS_Package_Manager] could somehow be combined? Aren't they basically the same thing, expect that the update notification would be an extension of the package manager - similar to Ubuntu linux I'm currently using, the notification icon pops up when updates are available, which then spawns the package management utility to install them (and download also if it hasn't already done so). --[[User:Rebroad|Rebroad]] 00:01, 1 Apr 2005 (CEST)

Revision as of 22:01, 31 March 2005

As ReactOS grows further in usability and functionality, it would be prudent to have a utility, ReactOSUpdate, to download and install updates without in an easy and fast way for end users, with a nice "ReactOS Update" button to make it look like Windows. :-)


What about rsync for retrieving updates in system directories?

rsync-update concept #1

we would probably need a second directory where the reactos core system files get stored too. this might be something like "dllcache" from windows (the installation routine only needs to install these system files twice). rsync updates the files in dllCache. a reimplementation of SFC would then copy the new files to their usual destination after reboot.

what do we need?

  • networking and TcpIpDotSys (network is NOT required for syncing! you can also rsync from a local source - e.g. for testing or updating from cdrom)
  • rsync for our platform (already available)
  • A version of SFC
  • a (secure!) rsync server providing us with files

ReactOS Update (ReactUpdate) concept #2

Have a local app called rosupate.exe (or similar) that lives in the \ReactOS or \ReactOS\system32 directory and, when launched would follow this process:

  • Checks itself to ensure it hasn't been tampered with (Digital Signature/checksum).
  • Checks against it's ACL if the UserID invoking it has the right to do so.
    • If not, it can prompt with a RunAs box to enter valid credentails (Like MacOS X does with it's control panel).
      • If RunAs is unavailible or unimplemented, gives an error along the lines of "Your user account has not been granted permission to run ReactOS Update".
    • If the UserID is allowed, it silently continues to the next step
  • Check if there's a previous update/restart pending.
    • If so, state that for some other reason the system should be restarted before any updating is attempted (Maybe give an option to go ahead anyway, with with sufficent warning (EG. "It is strongly recommended you restart your system before attempting to update ReactOS")).
    • If not keep going.
  • Ask the user how they want to update: Over the Internet (Recommended) (Suboption of a local update server), or via a local update source.
    • If over the Internet normally, continue.
      • If a local update server, ask for the name/IP (If not preselected by the Administrator), and if required credentials (Using a standard connect dailog box)
    • If a local source, ask for the path to the "INFO.UPD" (Or whatever the update data file (Think sortof like .inf file paths thatare always requested for always requested on driver installs) is called in the end). If this is the case, in the following steps, read "The local media" instead of a remote server where network transactions are being discussed.
  • I'm not sure about this step: How for it to determine the ReactOS update sites DNS and/or IP and not be liable to spoofing. The best thing I can come up with is if the DNS is going to change, have the old one only offer an update to ReactOSUpdate that will redirect it to the correct one.
    • If using a locally specified update server, goto the one supplied by the user.
  • Open an HTTPS connection to the update site (Probably something like rosupdate.reactos.org, update.reactos.org, os.update.reactos.org, etc. which incedentally, could function as web-based update sites for ROS).
    • HTTPS connections are a resource drain on the server and prevent cache-ing, which is important for large downloads. Besides, you don't really need them if the files themselves are signed.
  • Report the ReactOSUpdate application version number and if the server reports it ourdated, download the information to download and install the most up-do-date version.
    • If there are update, present them as the only update and state that they need to install that to recive other updates.
    • If not, continue on.
  • Download from the server the list of all the files that have updates, the new versions, sizes, and other metadata (Full list later down the page)
  • Format and present this to the user in the application.
    • If any updates are of immediately serious import (EG. There's a very easily exploited TCP/IP buffer overflow giving SYSTEM access and there's a rapidly spreading worm (Blaster-like) that exploits this) ReactOSUpdate may take immediate action (Block the affected ports, stop the affected services, or completely kill certain parts of the system untill updated (There should be a user preference to disable this or to ask 1st).
    • Seperate the updates into different sections based on their importance, but also by size, time to download, etc.
    • Also have tabs (Or a different means) to seperate the updates which need to be installed in their own session, independent of others
    • Have an option, selected by default, to delete the updates after installation.
      • A further option, download the updates but don't install them automatically.
    • Have an option, preferably selected by default, to not accept any network connections before the updates have been run for the first time (to solve the "I can't update without getting blaster" problem after you run an installation or image)
  • The user then selects the updates to install and indicates to continue
    • Check that no updates which need to be installed seperately are selected with others
      • If so, give an error listing the 2 options and allowing to continue with one or the other (Default to the one with the higher criticality), go back and review the selections, or cancel the update.
    • If the download size is significant compared to the speed of their connection to the update server, warn against significant delays and possible toll charged.
    • If neither of these apply, the keep going.
  • Warn the user that once the updates are downloaded, the system will need to be restart and that all unsaved work will be lost, etc, etc. Give them fair warning and the ability to gracefully back out (If there are updates of vital import this could be blocked/bypassed, or "strongly recommended" to continue).
  • Over secured connection (HTTPS or SFTP for example) download the selected updates to a directory on the hard disk (\ReactOS\Downloaded Updates, for example) and verify them.
    • If any fail verification, delete and redownload
  • When all the updates are downloaded install them using one of the following methods (Note, I have no idea which is best or even possible, I'll leave that for someone else to determine)

Method 1:

  • Overwrite the files as they stand.
  • Verify the new ones.
  • Request a reboot.

Method 2:

  • Move the files to a seperate directory.
  • Have the kernel load a program (Probably under the BootExecute key in the Registry) that will load on early startup
  • Request a reboot.
  • Once the program loads it kills the old copies, moves the new ones over, and makes a log somewhere.

Method 2.1 (Slighly different version of 2):

  • Install (In \ROSBootUpdate, for instance) a minimal kernel and the files to be copied and put it in the FreeLoader bootmenu (As "ReactOS 1 SP1 Installer", say) and make it default with a very short timedelay.
  • When loaded, check itself and the files to be sure they're correct.
    • If they are invalid, state as much with possible reasons why, and jump to the 4th from last step (In this revision).
    • If all are valid, contine.
  • Locate the directories and files to be replaced.
  • Erase the old files and copy the new ones over.
  • Remove the update entry from FreeLdr.ini
  • Add to the BootExecute key of the Registry a command to remove the \ROSBootUpdate directory and itself.
  • Restart.

Update Metadata

  • English (Or whatever language is specified ;)) description of the componment(s) affected.
  • New and currently installed versions
  • Sizes of update downloads
    • Compute the approximate download time locally (Maybe using the time it took to download the updates list as a factor?).
  • Severity (Examples/definitions in subpoints)
    • New feature
      • Support for IPX/SPX
    • Trivial bug
      • Misspelled "ReactOS" in something
    • Minor bug
      • Pressing "OK" somewhere doesn't save chnages
    • Moderate bug
      • Pressing "OK" somewhere freezes the Desktop/Shell
    • Severe bug
      • ReactOS can be crashed by pressing "OK" somewhere, by sending a malformed TCP packet the system gives a BSOD
    • Critical bug
      • A very easily exploitable hole or other bug which can lead to compromise of sensetive/confidential information, compromise of the system at elevated privledges (Administrator or SYSTEM), or corruption of vital files/directories.
    • Extremely Critical bug
      • Same as Critical, but with evidence of "In the wild" use (Virus with Blaster-like proportions)
        • Will default to stopping the affected part (If possible) during/before update.
  • Reboot required? (Should aim to need only for kernel changes).
  • Individual installation required?

What's needed

  • Networking / TCPIP.SYS (Ideally)
  • A local DLL with crypto functions (checksum, digital signatures, etc)
    • WINE is working on one
  • An HTTPS/SFTP client in the OS
  • An HTTPS/SFTP server
    • Probably Apache and something else for SFTP
  • A valid SSL certificate
    • Possibly selfsigned, or from VeriSign, Thawte, or similar.
  • Probably as ROS grows more popular a dedicated line for this server (Which should also become a dedicated and formidable server), or regional update servers.
    • Appropriate, probably a seperate DNS (os.update.reactos.org). Later as popularity, complexity and hence updates and downloads grow, local mirrors (os.update.reactos.org.nl, .ru, .us, .mx, .au, etc), if you can update from version to version via ROSUpdate (EG. 0.6.0 > 0.7.0) then probably sub-servers for those updates alone (070.os.update.reactos.org), and possibly multiple servers in the same area (philadelphia.os.update.reactos.us, eastfalls.philadelphia.pa.update.reactos.us). I know these scenarios are FAR into the future if they will ever occur, but it's good to have a plan.

Package Management

As Linux and MS Windows have developed a method of updating over some time now - are there any shortfalls in currently adopted methods? We should aim to devise an update mechanism that takes the best aspects of WindowsUpdate and linux package management (such as rpm). The package management utility should have a duty to keep track of orphaned packages/files/libraries. --Rebroad 17:59, 31 Mar 2005 (CEST)

Perhaps, this article, and [ReactOS_Package_Manager] could somehow be combined? Aren't they basically the same thing, expect that the update notification would be an extension of the package manager - similar to Ubuntu linux I'm currently using, the notification icon pops up when updates are available, which then spawns the package management utility to install them (and download also if it hasn't already done so). --Rebroad 00:01, 1 Apr 2005 (CEST)