Description of problem: this part of engine-setup to configure websocket proxy is horrible. useless uuid EOF (paste) displayed, user unfriendly, confusing text. 1. uuid lines (-=451b80dc-996f-432e-9e4f-2b29ef6d1141=-) should be dropped, ordinary user doesn't care, no need to display 2. following '3.' part is... i was staring at the console for many seconds to guess what it does want from me. ~~~ 3. Certificate will be available at /etc/pki/ovirt-engine/certs/websocket-proxy.cer on the engine host, please copy that content here when required Please input WSP certificate chain that matches certificate request, (issuer is not mandatory, from intermediate and upper) type '--=451b80dc-996f-432e-9e4f-2b29ef6d1141=--' in own line to mark end. ~~~ fyi, i didn't know what 'input WSP certificate chain' means, so i just typed 'foobar', <enter>, hmmm nothing, ok let's put '--=451b80dc-996f-432e-9e4f-2b29ef6d1141=--', <enter>, voila, it finished. but /etc/pki/ovirt-engine/certs/websocket-proxy.cer now contains 'foobar', hehe. 1. the user is already logged on the machine where he deploys the websocket proxy. 2. i have never seen any cli app to ask for long text to be pasted as the user is logged here (websocket machine) and there (engine machine), just inform him to copy cert (already signed) from engine to the host. then check for existence of the file, check its content with openssl. i would expect more from enterprise product. imho this is fail. wouldn't be possible to just download certs via http? it's not secret anyway. we already offer ca.crt for download: <LocationMatch ^/(ovirt-engine($|/)|api($|/)|RHEVManagerWeb/|OvirtEngineWeb/|ca.crt$|engine.ssh.key.txt$|rhevm.ssh.key.txt$)> ProxyPassMatch ajp://127.0.0.1:8702 timeout=3600 retry=5 Version-Release number of selected component (if applicable): ovirt-engine-setup-base-3.5.0-0.0.master.20140629172257.git0b16ed7.el6.noarch ovirt-engine-setup-plugin-ovirt-engine-common-3.5.0-0.0.master.20140629172257.git0b16ed7.el6.noarch ovirt-engine-setup-plugin-websocket-proxy-3.5.0-0.0.master.20140629172257.git0b16ed7.el6.noarch ovirt-engine-setup-plugin-ovirt-engine-3.5.0-0.0.master.20140629172257.git0b16ed7.el6.noarch How reproducible: 100% Steps to Reproduce: 1. engine-setup (just for websocket proxy) 2. see '3.' and guess (for brave people, use vnc so you cannot paste anything) 3. Actual results: confusing, user unfriendly, horrible Expected results: either download cert via http or inform user to copy cert from engine to websocket host to specific path Additional info: fyi, you already ask the user to save content of the csr to specific path location, so...
Cut & paste issue (probably some bogus character while pasting) caused me to re-setup websocket proxy couple of time. If this would be released it would be big shame.
same thing for remote installation of ovirt-engine-reports
this is really weird, confusing and annoying even if you asked user to give you root password and then you copied it for him, it would be better than this (we are asking for root password of vdsm, so why not engine?) - you can ask user if he wants to give you root password in order to scp certificate (and do everything else you need to do), or he likes to copy-paste things (ideally through spice console or some remote management of physical server)
Following [1], closing this as duplicate of: "sudo engine-setup", should NOT be required. Please reopen if still relevant, with specific details, such as bug #1115993. Thanks! [1] http://lists.ovirt.org/pipermail/users/2014-July/026439.html *** This bug has been marked as a duplicate of bug 949377 ***
Sorry this cannot be duplicate, this is about "howto", how is it designed - the part about SSL keys - not about some sudo/permissions of the engine-setup itself. This is relevant only to separate deployments of websocket proxy, reports... maybe something else?
Unacceptable part of this BZ: - cut & paste of certificate into console
What about to download final signed cert from engine host like it is already done for engine cert itself? But you would need to keep some naming convention of filenames, also it would be nice if you would double-check the downloaded cert (is it really signed correctly etc...)?
(In reply to Jiri Belka from comment #5) > Sorry this cannot be duplicate, this is about "howto", how is it designed - > the part about SSL keys - not about some sudo/permissions of the > engine-setup itself. That bug does not talk about sudo/permissions - it specifically talks about what you also talked about in the above-referenced mail - make setup a GUI. > This is relevant only to separate deployments of > websocket proxy, reports... maybe something else? So? I can easily see a future where everything is done by the web interface, one host or separate ones, just as you asked for. Easily see, not sure I can easily make it happen... (In reply to Jiri Belka from comment #6) > Unacceptable part of this BZ: > > - cut & paste of certificate into console You already opened bug #1115993 for this. Not sure what else you refer to. (In reply to Jiri Belka from comment #7) > What about to download final signed cert from engine host like it is already > done for engine cert itself? But you would need to keep some naming > convention of filenames, also it would be nice if you would double-check the > downloaded cert (is it really signed correctly etc...)? Makes sense, not sure it's relevant to this bug, or even to the bug #1115993.
> (In reply to Jiri Belka from comment #7) > > What about to download final signed cert from engine host like it is already > > done for engine cert itself? But you would need to keep some naming > > convention of filenames, also it would be nice if you would double-check the > > downloaded cert (is it really signed correctly etc...)? > > Makes sense, not sure it's relevant to this bug, or even to the bug #1115993. This BZ is about cut & paste of certificate into engine-setup. This has confused me and my colleague and it will confuse everybody else. Everybody who heard from me about cut & paste into console app was laughing. Till we would have setup of separate apps on remote hosts from UI, we need to solve this cut & paste confusion for now. With BZ1115993 admin can just copy file via network to engine host, it is just printed on engine-output right now. I don't know what ideal solution for current way is but what is right now (cut & paste) is IMHO wrong.
(In reply to Jiri Belka from comment #9) > > (In reply to Jiri Belka from comment #7) > > > What about to download final signed cert from engine host like it is already > > > done for engine cert itself? But you would need to keep some naming > > > convention of filenames, also it would be nice if you would double-check the > > > downloaded cert (is it really signed correctly etc...)? > > > > Makes sense, not sure it's relevant to this bug, or even to the bug #1115993. > > This BZ is about cut & paste of certificate into engine-setup. This has > confused me and my colleague and it will confuse everybody else. Everybody > who heard from me about cut & paste into console app was laughing. (I wouldn't laugh if you talked with me - my first 4 years in Linux only included copy/paste between consoles, my 386SX with 4MB RAM ran X so slowly that I almost never tried. And actually almost never needed - multiple virtual consoles with copy/paste was very useful) > > Till we would have setup of separate apps on remote hosts from UI, we need > to solve this cut & paste confusion for now. > > With BZ1115993 admin can just copy file via network to engine host, it is > just printed on engine-output right now. > > I don't know what ideal solution for current way is but what is right now > (cut & paste) is IMHO wrong. If you think that copying files is enough, please close as duplicate of bug #1115993. Otherwise please state clearly what you want, and change the summary accordingly. Thanks.
Summary: * This BZ depends on BZ1115993. * TBD - change all relevant part expecting cut & paste to work with files: - csr -> copy from host to engine host - final signed cert -> copy from from engine to websocket host Thus no more cut & paste in interactive console app. That would make me more happy ;)
What's about if, before starting step 3, we let the user choose if he prefer to copy and paste the CRS and the signed cert via the interactive console or if he prefer to copy the file using the command we provide?
I personally would just kill it ;) If you still want to keep cut & paste functionality then: 1. Instruct more clearly that only part between 'BEGIN' and 'END' from cert file is needed 2. Every line of the pasted input should be prefixed with '>' (as it is for long input) 3. No start|stop string, this is annoying, start is part with 'BEGIN', end is one with 'END'. 4. Cert itself should be verified before accepted, now one can write whatever and finish the input and it would be accepted. My 2 cents.
Simone, did you try the changed code in automated setup? Both inline=True and False? Is generated answer file enough for unattended setup? Also, previous code seems to be able to use WSP_CERTIFICATE_CHAIN if supplied in env to allow automation while new code does not - but I didn't test that. I am now working on same bug for Reports. I think I'll drop there the inline=True option because I do not see a good reason to keep both. I also think I'll keep csr in non-temp file (in /etc/pki).
I also moved this code in Reports to run at customization - perhaps better to do that also in wsp.
> I also > think I'll keep csr in non-temp file (in /etc/pki). On a second thought I'll give up this one. I intended to do that instead of the temp file (and not in addition), but I want to do that during customization phase, and filetransaction will not actually write it there till later (at transaction begin).
(In reply to Yedidyah Bar David from comment #16) > > I also > > think I'll keep csr in non-temp file (in /etc/pki). > > On a second thought I'll give up this one. I intended to do that instead of > the temp file (and not in addition), but I want to do that during > customization phase, and filetransaction will not actually write it there > till later (at transaction begin). Alon explicitly recommended to do it via a temp files for security concerns. See comment 1 on https://bugzilla.redhat.com/1115993
ok, rhevm-setup-plugin-websocket-proxy-3.5.0-0.13.beta.el6ev.noarch tested both inline and files mode.
oVirt 3.5 has been released and should include the fix for this issue.