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 > _________________________________________ 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]
