Title: Installing and Configuring a Squid Proxy It seems people have troubles to distinguish between chapter "B.6. SPICE Proxy" and "B.7. Squid Proxy" of Installation guide, They tend to mixing up these two separated configurations into one, First one is meant to be for Spice traffic and There is no need to set any SSL since spice is not even able to authentication against proxy or establish SSL connection to the proxy. And the second one for proxying User Portal. I suggest to reconsider some clear separation line between these two chapters. (Even more confusion happens when websocket proxy is involved, in guides used for setting proxy for HTML5 Spice client). As well as I would reconsider Squid proxy configuration in chapter B.6 of Installation guide since It seems customers tend to follow the guide step by step. Spice proxy tunnels Spice traffic through proxy, That's all what it does right now, No Authentication, No Encryption to the Proxy from Client only which means Spice ports on the hosts must be accessible through the proxy from outside world. The rule we have in guide does open too many ports uselessly - basically all Safe_ports (in squid config terminology) which is range of 80, 21, 443, 70, 210, 280, 488, 591, 1025-65535 ports on all accesible ports. I would add two acl to the squid.conf: acl Spice_hosts dst A.B.C.D/M acl Spice_ports port 5634-6166 - where A.B.C.D/M are RHEVM hosts and 5634-6166 is raqnge of Spice ports on the hosts (This range is going to change in 3.4 I guess) and then I would change line: http_access deny CONNECT !SSL_ports to line: http_access allow CONNECT Spice_ports Spice_hosts and make sure I have line: http_access deny all (needs to be tested by someone else too)
Maybe a good idea is to provide final example squid.conf gile which can be taken and used as It is with small changes - substitute just right values. As well as It may be a good idea to provide a squid.conf for a case where proxying User portal and spice traffic cooexist on the same Squid proxy.
More observations: 1. In section "B.7.1. Installing and Configuring a Squid Proxy" Point 2. What is the "private.csr" file mentione in sentence: "To generate the signed certificate, copy the private.csr file to the oVirt engine machine," Shouldnt it be "proxy.req"? 2. n section "B.7.1. Installing and Configuring a Squid Proxy" Point 4. There is a snipnet from squid.conf but unfortunately the configuration lines are too long so it looks like It's a new line. For example "defaultsite=engine.example.com" and "sslcafile=/etc/squid/ca.pem name=engine" looks to be on a new line but It cannot be, is there a way to format it better?
3. In section "B.7.1. Installing and Configuring a Squid Proxy" Point 2. In the snippet: https_port 443 key=/etc/squid/proxy.key cert=/etc/squid/proxy.cer ssl-bump defaultsite=engine.example.com cache_peer engine.example.com parent 443 0 no-query originserver ssl sslcafile=/etc/squid/ca.pem name=engine cache_peer_access engine allow all ssl_bump allow all http_access allow all Isn't it better to replace directive "http_access allow all" with: http_access allow SSL_ports http_access deny all - No need to allow everythign I assume.
Changing status back to 'New' until re-assignment.
this is an automated message. oVirt 3.6.0 RC3 has been released and GA is targeted to next week, Nov 4th 2015. Please review this bug and if not a blocker, please postpone to a later release. All bugs not postponed on GA release will be automatically re-targeted to - 3.6.1 if severity >= high - 4.0 if severity < high
oVirt 4.0 Alpha has been released, moving to oVirt 4.0 Beta target.
The sections mentioned in this bug have since been updated and improved in the 3.5, 3.6, and 4.0 versions of the documentation. See bug 1172320 for SPICE proxy review and fixes. See bug 1155377 for Squid proxy review and fixes. I am closing this bug, based on the feedback from users and engineering in the bugs mentioned above.