FYI, the step-by-step workflow is more permanently summarized here: https://wiki.openmrs.org/x/gYqmAQ
-Darius On Mon, Nov 7, 2011 at 11:57 PM, Ben Wolfe <[email protected]> wrote: > I don't think encryption is important enough for v1. Add a warning saying > that you should do this either over ssl or on an internal network. Make a > ticket to encrypt both transfer and disk for us to work on for a later > project. (and maybe even add a note to projects.openmrs.org so we don't > forget it) > > Ben > > > On Tue, Nov 8, 2011 at 9:11 AM, Darius Jazayeri > <[email protected]>wrote: > >> For #4, I meant that the user shouldn't have to (or be allowed to) set >> the database properties (connection/driver/user/pass), because those should >> be pre-determined by the standalone that's containing the app. >> >> For #8, a progress bar is fine, though I'd add that in v2. :-) >> >> I was actually talking about encrypting the sqldump in case we have to >> write it to disk in /tmp for some reason, keeping the key in memory for the >> runtime of the install wizard. We might as well also encrypt over the wire >> if we're doing that. (Though if you're not using SSL, you'll have to pass >> the secret key over the wire unencrypted, so it doesn't actually prevent a >> targeted attack.) >> >> -Darius >> >> >> On Mon, Nov 7, 2011 at 6:59 PM, Burke Mamlin <[email protected]>wrote: >> >>> Sounds good. Pretty similar to what I was thinking. >>> >>> Is #4 (Install wizard should not ask you the typical series of questions >>> about db connect string, user/pass, root user/pass. Instead the standalone >>> should have set these to fixed values) because all the credentials on the >>> production system will be transferred? We're not suggesting that we'd have >>> fixed username/password for the test system containing production data, are >>> we? >>> >>> For #8, regarding "the user doesn't see this happening", how about a >>> progress bar in case the production system, the connection to it, or the >>> data transfer is slow? >>> >>> As far as encrypting the data being transferred, this would be great as >>> long as it can be done relatively easily, since it will be production data. >>> How about having the standalone generate a long (e.g., 1024-character) >>> random string, passing it to the production server, and then using that >>> string to encrypt & decrypt the data. That way, the key would only exist >>> in the memory of the standalone while it was transferring the data. >>> >>> Cheers, >>> >>> -Burke >>> >>> On Mon, Nov 7, 2011 at 9:22 PM, Darius Jazayeri <[email protected]>wrote: >>> >>>> Wyclif and I discussed on IRC, and came up with this: >>>> >>>> 1. User downloads standalone, unzips, and double clicks on the JAR >>>> 2. User chooses a "show me install wizard" option (needs a ticket) >>>> 3. Install wizard asks (a) Standard, (b) Custom, (c) Test an >>>> upgrade (requires uncommenting some code that already exists). User >>>> chooses >>>> (c). >>>> 4. Install wizard should *not* ask you the typical series of >>>> questions about db connect string, user/pass, root user/pass. Instead >>>> the >>>> standalone should have set these to fixed values. >>>> 5. Install wizard asks for the URL of the production server you >>>> want to test an upgrade for. >>>> 6. Test server verifies that the production server is reachable at >>>> that URL, and that it's running the Release Testing module. If either >>>> check >>>> fails, give an appropriate error message, and return to the previous >>>> step. >>>> 7. Test server asks user for username/password for the production >>>> server, and verifies that they're valid. If not, ask again. >>>> 8. Test server uses those credentials to fetch an appropriate sql >>>> dump, and zip file of modules. (It does this server-side, the user >>>> doesn't >>>> see this happening. To do: decide whether we need to encrypt the >>>> sqldump we >>>> write to a temp directory, or if the Release Testing module should >>>> de-identify it as it outputs it.) >>>> 9. Install wizard loads up the sql dump, and puts the modules in >>>> the right place. >>>> 10. Install wizard runs the liquibase update scripts >>>> 11. Finally, a login screen! >>>> >>>> -Darius >>>> >>>> On Mon, Nov 7, 2011 at 5:42 PM, Darius Jazayeri <[email protected]>wrote: >>>> >>>>> Hi Wyclif, >>>>> >>>>> I was wondering if you could give a step-by-step overview of the >>>>> process you're envisioning as our target from this sprint. >>>>> >>>>> 1. User downloads standalone 1.9-beta, unzips it, and double clicks on >>>>> the JAR >>>>> ...(what happens here)... >>>>> N. User sees a login window to a standalone instance whose DB is >>>>> populated with data from an existing install. >>>>> >>>>> -Darius >>>>> >>>> >>>> ------------------------------ >>>> Click here to >>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>> OpenMRS Developers' mailing list >>>> >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
