ReactOS Update

From ReactOS Wiki
Jump to: navigation, search

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

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 TCPIP.SYS (network is NOT required for syncing! you can also Rsync from a local source - e.g. for testing or updating from CD-ROM)
  • 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 rosupdate.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 credentials (Like MacOS X does with its control panel).
      • If RunAs is unavailable 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, asks for your password
  • 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 sufficient warning (e.g. "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) (Sub-option 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 dialog box)
    • If a local source, ask for the path to the "INFO.UPD" (Or whatever the update data file (Think sort of like .inf file paths that are 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, go to 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 incidentally, could function as web-based update sites for ROS).
    • HTTPS connections are a resource drain on the server and prevent caching, 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 outdated, download the information to download and install the most up-to-date version.
    • If there are updates, present them as the only update and state that they need to install that to receive 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 (e.g. 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 until updated (There should be a user preference to disable this or to ask 1st).
    • Separate 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 separate 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 separately 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 priority), 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, then 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 there's 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 separate 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 (Slightly different version of 2):

  • Install (In \ROSBootUpdate, for instance) a minimal kernel and the files to be copied and put it in the FreeLoader boot menu (As "ReactOS 1 SP1 Installer," say) and make it default with a very short time delay.
  • 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, continue.
  • 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 component(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 changes
    • 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 sensitive/confidential information, compromise of the system at elevated privileges (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 the 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 self-signed, 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 separate 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 (e.g. 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.
  • A binary diff/patch utility

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 Windows Update 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)

Yes, I would like to be able to apply non-kernel level OS updates without reboot like DPkg/APT and RPM/whatever package management system. Erkinalp (talk) 18:37, 1 February 2014 (UTC)


Possible Method by Packages :

  • Use ReactOS Apps to manage the update of OS.
  • Check the release version of ReactOS.
  • Check if updates are available for this release. (if you check manually and no update is available, display "No update is available. Check later.")
  • If available, display a message "Update(s) are available. A restart is required.". Ask what to do ("Install now" / "Recall me in 1 hour" / "Recall me in 6 hours" / "Recall me tomorrow" / "Don't install for now")
  • If you accept, download the packages (like KB in Windows) in function of the release detected, in the same folder as Windows C:\ReactOS\SoftwareDistribution\Download
  • Display a progress bar
  • Made a restoration point or copy old files in a folder in case of issue, during the download.
  • When the download and the save are finalised, install the new packages.
  • Made a log file of the installation C:\ReactOS\Logs.
  • If there is a problem :
    • Stop the installation.
    • Display a message "The update(s) have been aborted. Error xxx."
    • Recopy the older files in a good place or restore the restoration point.
    • Reboot.
  • If all is fine :
    • Display a message "Update Successful. A manual restart is required." with two buttons, "Restart now" and another "Later", a countdown timer of 25 seconds will be displayed too, and if there is no answer, reboot after the countdown.