7:42 a.m.
Hello,
I' m trying without success to import a qcow2 file into ovirt. I tried on a ISCSI
datadomain and an nfs datadomain.
I struggled quite a lot to have the "test connection" succed ( I write a small
shell script to "deploy" letsencryt certificates into ovirt engine)
Doc is not clear on the fact that certificates for imageio-proxy are different than for
main engine…
Now, the upload fails with
Transfer was stopped by system. Reason: failed to add image ticket to
ovirt-imageio-proxy.
Image gets stuck in "transfer paused by system"
Any idea ?
ovrit is up to date: 4.2.4 on both engine and hosts.
4:31 p.m.
On Tue, Jul 3, 2018 at 11:47 PM Nir Soffer <nsoffer(a)redhat.com> wrote:
Can you share the contents of:
/etc/ovirt-imageio-proxy/ovirt-imageio-proxy.conf
And the proxy log at
/var/log/ovirt-imageio-proxy/image-proxy.log
Showing the time of the error (failed to add image ticket to
ovirt-imageio-proxy.)
Nir
2:53 a.m.
Thanks for getting back to me.
I wanted to "protect" my ovirt installation with letsencrypt certificates ( to
have a "green" bar in my chrome browser.)
I set up a bastion host where I configured letsencrypt.
I copied the certificates over the ovirt engine machine and ran the script
"convert.sh" ( see attachement). ( still need to automate it to handle
certificate renew..)
Once this was in place, the test connection button ( in upload image UI) gave me
"green" "Connection to ovirt-imageio-proxy was successful."
Here a copy of engine.log and ovirt-imageio-proxy log files. The ssl paths are dumped in
the log file
Thanks for your support
Etienne
________________________________
De : Nir Soffer <nsoffer(a)redhat.com>
Envoyé : mardi 3 juillet 2018 23:31
À : Etienne Charlier
Cc : users(a)ovirt.org; Daniel Erez
Objet : Re: [ovirt-users] Cannot import a qcow2 image
On Tue, Jul 3, 2018 at 11:47 PM Nir Soffer
<nsoffer@redhat.com<mailto:nsoffer@redhat.com>> wrote:
On Tue, 3 Jul 2018, 15:44 ,
<etienne.charlier@reduspaceservices.eu<mailto:etienne.charlier@reduspaceservices.eu>>
wrote:
Hello,
I' m trying without success to import a qcow2 file into ovirt. I tried on a ISCSI
datadomain and an nfs datadomain.
I struggled quite a lot to have the "test connection" succed ( I write a small
shell script to "deploy" letsencryt certificates into ovirt engine)
Doc is not clear on the fact that certificates for imageio-proxy are different than for
main engine...
Now, the upload fails with
Transfer was stopped by system. Reason: failed to add image ticket to
ovirt-imageio-proxy.
Image gets stuck in "transfer paused by system"
Any idea ?
you probably have bad cretificate configuration in the proxy. Why not use the default
certificates generated by engine setup? This is how we test the proxy.
Can you share the contents of:
/etc/ovirt-imageio-proxy/ovirt-imageio-proxy.conf
And the proxy log at
/var/log/ovirt-imageio-proxy/image-proxy.log
Showing the time of the error (failed to add image ticket to ovirt-imageio-proxy.)
Nir
ovrit is up to date: 4.2.4 on both engine and hosts.
_______________________________________________
Users mailing list -- users@ovirt.org<mailto:users@ovirt.org>
To unsubscribe send an email to users-leave@ovirt.org<mailto:users-leave@ovirt.org>
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/FTC3PBZCRRT...
10:50 a.m.
On Wed, Jul 4, 2018 at 11:08 AM Etienne Charlier <
Etienne.Charlier(a)reduspaceservices.eu> wrote:
I think there is a misconception here. Using the engine builtin CA is more
secure than any other
CA, not less secure. You don't protect anything by using another CA.
What you really need to do is to import the engine CA certificate to your
browser, and this is also
required for communicating with the proxy.
Unless you know what you are doing, replacing the certificates with your
own is going to be
hard.
This means that the proxy is configured to use the new CA, but this is not
enough
to upload. The proxy has its own certificates, and they must be signed by
the new
CA.
So to use your own certificates, you have to regenerate both the engine
certificates,
and the proxy certificates, and this process is not easy or documented yet.
If you created everything correctly, you need to configure the proxy to use
the new
certificates.
Finally, you need to restart ovirt-imgaeio-proxy, since it does not
support reloading
certificates or configuration changes yet.
I think the best solution for you is to use engine builtin PKI, managed by
engine-setup.
To "protect" your ovirt installation, add the engine CA to your browser
using this link:
https://my.engine/ovirt-engine/services/pki-resource?resource=ca-certific...
You save this file locally, and then you import this certificate into your
browser.
Using Chrome, you do:
1. go to: Settings > Advanced > Manage Certificates > Authorities
2. click "Import"
3. select the certificate
4. check "Trust this certificate for identifying web sites"
5. confirm
6. restart the browser
1:14 a.m.
On Wed, Jul 4, 2018 at 6:50 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
Well, not sure I agree, but not sure that's the point...
The engine-internal CA is only protected by a unix ACL, on the engine
machine. So if you manage to get root on it, you can do anything with the
engine CA.
Most reasonable CAs (including hopefully most organization-internal ones)
have more than one level in the authority chain, with the root cert's key
being kept offline in some safe, so it's harder to break.
Should not be - we have this doc, and should update it as needed:
[1] https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL/
Actually it's indeed somewhat out-of-date. See also:
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1385617
which should be the only thing missing in:
[3]
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/...
which is somewhat more up-to-date than [1] (has websocket-proxy).
Isn't this what above bug [2] is about? You wrote there that it's ok to
configure the proxy to use same key/cert as apache.
Thanks,
--
Didi
8:46 a.m.
Thanks a lot for your support!
A reinstalled a fresh ovirt-engine and managed to import the certificate.
A managed to upload an image even with the self signed certificates configured.
I think a "simple" way to allow letsencrypt certificates to be used for
"external access" web UI, API..; could be useful
Anyway, thanks for your support
Etienne
9:20 a.m.
On Thu, Jul 5, 2018 at 4:55 PM <etienne.charlier(a)reduspaceservices.eu>
wrote:
I agree.
Didi, can we integrate with letsencrypt to have engine/imageio certificates
respected by browsers without additional configuration?
The need to import the CA into your browser is to upload images is a big
user
experience issue. We see users failing to do it again and again.
Nir
1:35 a.m.
From a user point of view ...
Letsencrypt or another certificate authority ... it should not matter...
Just having one set of files ( cer/key/ca-chain) with a clear name referenced from
"all config files" would be the easiest...
Once you get the certs from you provider, you just overwrite the files with your own ,
restart the services and "that's it" ;-)
Letsencrypt renewing does not have to be handled on ovirt host (on a bastion host where
LE is configured, a simple script can be run to update the certs and restart the
services...)
My 0.02€
Etienne
3:34 a.m.
On Fri, Jul 6, 2018 at 9:35 AM, <etienne.charlier(a)reduspaceservices.eu>
wrote:
Please realize that the engine CA is _mainly_ used to sign hosts' keys.
We do not want to let the user do this with a 3rd party (well, until we
fix bz 1134219 <https://bugzilla.redhat.com/show_bug.cgi?id=1134219>;, see
my other reply). Signing all the other keys is only
done "because we can" :-), to simplify things by default.
That's the one-line summary of:
https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL/
<https://bugzilla.redhat.com/show_bug.cgi?id=1134219>
or at least that's the intention.
Indeed.
--
Didi
3:29 a.m.
On Thu, Jul 5, 2018 at 5:20 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
I never looked specifically at this. We do have these open bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1336873
https://bugzilla.redhat.com/show_bug.cgi?id=1134219
If we want to specifically handle LE, please open a bug. Not sure we should.
I guess we have here two different issues:
1. By default, we (by default) generate a different key/cert pair for
imageio,
rather than use the one for httpd. So a user accepting the cert for httpd
still
fails to use the cert for imageio, until it's accepted as well. Perhaps we
should
use by default the same pair? No idea why we decided to use a separate pair.
Please open an RFE to use the same pair as httpd.
2. The procedure to use a 3rd-party CA does not mention imageio. That's
already
discussed earlier in this thread.
Best regards,
--
Didi
2:42 a.m.
Hello,
A few comments from a novice...:
* Internal "stuff" ( ca & certificates used to secure traffic between
engine and hosts) should stay internal; users/admin shouldn't be aware of this.
* visible "stuff" ( ca & certs used to protect UI and API) should be easily
modifiable
One way of fulfilling those "requirements":
** One set of key/cert files shared between "all" public endpoints ( API, UI,
WEBsockets, ImageIo....)
** Easily replaceable ( eg: known file location and a matter of reloading services after
having updated the files)
IMHO, letstencrypt specific stuff is not needed: we could write a "plugin" for
acme.sh (running on another bastion host) responsible for pushing the renewed certs on
engine vm when needed.
2431
days inactive
2437
days old
11 comments
4 participants
participants (4)
-
Etienne Charlier -
etienne.charlier＠reduspaceservices.eu
-
Nir Soffer -
Yedidyah Bar David