August 2016 - Users - oVirt List Archives

qos problem in ovirt python sdk
by like.ma＠cs2c.com.cn 16 Aug '16

16 Aug '16

This is a multi-part message in MIME format. ------=_001_NextPart335580042548_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkknbSB1c2luZyBvdmlydDMuNi43LCBhbmQgaSB3YW50IHRvIHVzZSBRb1MgZnVu Y3Rpb24gYnkgcmVzdGFwaS4gQnV0IGkgZm91bnQgaSBjYW4ndCB1cGRhdGUgdGhlIHFvcyB0byB1 bmxpbWl0ZWQuIA0KRm9yIGV4YW1wbGUsIGkgYXNzaWduZWQgYSBxb3MgbmFtZWQgcW9zMSB0byBh IHZuaWMgcHJvZmlsZSBuYW1lZCB2cHJvZmlsZTEsIHRoZW4gaSB3YW50IHRvIHNldCB0aGUgcW9z IG9mIHZwcm9maWxlMSB0byB1bmxpbWl0ZWQsDQpzbyBpIHNldCB0aGUgcW9zIHRvIE5vbmUgaW4g c2RrIHdoZW4gdXBkYXRlIHZuaWMgcHJvZmlsZSwgYnV0IGFmdGVyIHVwZGF0ZSB0aGUgdm5pYyBw cm9maWxlIHN0aWxsIGhhcyBxb3MgbmFtZWQgcW9zMS4NCg0KU28sIGhvdyBzaG91bGQgaSBkbyBp ZiBpIHdhbnQgdG8gc2V0IHFvcyBvZiBhIHZuaWMgcHJvZmlsZSB0byB1bmxpbWl0ZWQ/DQoNCkxv b2sgZm9yd2FyZCB0byB5b3VyIGhlbHAhDQpUaGFua3MgDQoNCg0KDQpsaWtlLm1hQGNzMmMuY29t LmNuDQo= ------=_001_NextPart335580042548_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charse= t=3DGB2312"><style>body { line-height: 1.5; }body { font-size: 10.5pt; fon= t-family: =CE=A2=C8=ED=D1=C5=BA=DA; color: rgb(0, 0, 0); line-height: 1.5;= }</style></head><body>=0A<div><span></span><div style=3D"font-family: =CE= =A2=C8=ED=D1=C5=BA=DA, Tahoma; line-height: normal;"><div>Hello,<br><br></= div>I'm using ovirt3.6.7, and i want to use QoS function by restapi. But i= fount i can't update the qos to unlimited. </div></div><div style=3D= "font-family: =CE=A2=C8=ED=D1=C5=BA=DA, Tahoma; line-height: normal;">For = example, i assigned a qos named qos1 to a vnic profile named vprofile1, th= en i want to set the qos of vprofile1 to unlimited,</div><div style=3D"fon= t-family: =CE=A2=C8=ED=D1=C5=BA=DA, Tahoma; line-height: normal;">so i set= the qos to None in sdk when update vnic profile, but after update the vni= c profile still has qos named qos1.</div><div style=3D"font-family: =CE=A2= =C8=ED=D1=C5=BA=DA, Tahoma; line-height: normal;"><br></div><div style=3D"= font-family: =CE=A2=C8=ED=D1=C5=BA=DA, Tahoma; line-height: normal;">So, h= ow should i do if i want to set qos of a vnic profile to unlimited?</div><= div style=3D"font-family: =CE=A2=C8=ED=D1=C5=BA=DA, Tahoma; line-height: n= ormal;"><br></div><div style=3D"font-family: =CE=A2=C8=ED=D1=C5=BA=DA, Tah= oma; line-height: normal;">Look forward to your help!</div><div style=3D"f= ont-family: =CE=A2=C8=ED=D1=C5=BA=DA, Tahoma; line-height: normal;">Thanks=  </div>=0A<div><br></div><hr style=3D"width: 210px; height: 1px;" col= or=3D"#b5c4df" size=3D"1" align=3D"left">=0A<div><span><div style=3D"MARGI= N: 10px; FONT-FAMILY: verdana; FONT-SIZE: 10pt"><div>like.ma(a)cs2c.com.cn</= div></div></span></div>=0A</body></html> ------=_001_NextPart335580042548_=------

3 2

oVirt 4 with custom SSL-certificate and SPICE HTML5 browser client -> WebSocket error: Can't connect to websocket on URL: wss://ovirt.engine.fqdn:6100/
by aleksey.maksimov＠it-kb.ru 16 Aug '16

16 Aug '16

Hello oVirt guru`s ! I have successfully replaced the oVirt 4 site SSL-certificate according to the instructions from "Replacing oVirt SSL Certificate" section in "oVirt Administration Guide" http://www.ovirt.org/documentation/admin-guide/administration-guide/ 3 files have been replaced: /etc/pki/ovirt-engine/certs/apache.cer /etc/pki/ovirt-engine/keys/apache.key.nopass /etc/pki/ovirt-engine/apache-ca.pem Now the oVirt site using my certificate and everything works fine, but when I try to use SPICE HTML5 browser client in Firefox or Chrome I see a gray screen and message under the button "Toggle messages output": WebSocket error: Can't connect to websocket on URL: wss://ovirt.engine.fqdn:6100/eyJ...0=[object Event] Before replacing certificates SPICE HTML5 browser client works. Native SPICE client works fine. Tell me what to do with SPICE HTML5 browser client?

3 14

oVirt-shell command to move a disk
by Nicolas Ecarnot 16 Aug '16

16 Aug '16

Hello, I'm confused because though I'm using ovirt-shell to script many actions every day, and even after a large bunch of reading and testing, I can not find the correct syntax to move (offline/available) disks between storage domains. May you help me please? (oVirt 3.4.4) -- Nicolas Ecarnot

4 10

oVirt 4.0 and multipath.conf for HPE 3PAR. What do you advise?
by aleksey.maksimov＠it-kb.ru 16 Aug '16

16 Aug '16

Hello, oVirt guru's ! I installed oVirt 4.0 on several servers HP ProLiant DL360 G5 with QLogic/Emulex 4G dual-port HBAs. These servers have multipath connection to the storage system HP 3PAR 7200. Before installing oVirt to servers I set up the configuration file /etc/multipath.conf according to the vendor recommendations from document "HPE 3PAR Red Hat Enterprise Linux and Oracle Linux Implementation Guide (emr_na-c04448818-9.pdf)" https://blog.it-kb.ru/2016/06/12/configuring-device-mapper-multipathing-dm-… Before installing oVirt my multipath.conf was the: ---> start of /etc/multipath.conf <----- defaults { polling_interval 10 user_friendly_names no find_multipaths yes } blacklist { devnode "^cciss\/c[0-9]d[0-9]*" } multipaths { multipath { wwid 360002ac000000000000000160000cec9 alias 3par-vv2 } multipath { wwid 360002ac000000000000000170000cec9 alias 3par-vv1 } } devices { device { vendor "3PARdata" product "VV" path_grouping_policy group_by_prio path_selector "round-robin 0" path_checker tur features "0" hardware_handler "1 alua" prio alua failback immediate rr_weight uniform no_path_retry 18 rr_min_io_rq 1 detect_prio yes } } ---> end of /etc/multipath.conf <----- But after installing oVirt file multipath.conf has changed to: ---> start of /etc/multipath.conf <----- defaults { polling_interval 5 no_path_retry fail user_friendly_names no flush_on_last_del yes fast_io_fail_tmo 5 dev_loss_tmo 30 max_fds 4096 } devices { device { all_devs yes no_path_retry fail } } ---> end of /etc/multipath.conf <----- Now I'm not sure that this configuration is optimal. What do you advise?

3 3

restore db table
by Fernando Fuentes 16 Aug '16

16 Aug '16

1 1

Short SSL key sizes, and TLS 1.2 on vdsm
by Chris H 15 Aug '16

15 Aug '16

Hello, My RHEVM hypervisors (Red Hat Enterprise Virtualization Hypervisor release 7.2 (20160627.3.el7ev)) are failing corporate Nessus TCP/IP vulnerability scans spectacularly with the following. 1) "SSL Certificate Chain Contains RSA Keys Less Than 2048 bits": many ports in the 5900 range are presenting certificates signed by a key of 1024 bits. I can certainly see 1024-bit keys on the management server and the hypervisors: management ovirt-engine]# openssl x509 -in ca.pem -noout -text | grep Public-Key Public-Key: (1024 bit) hypervisor admin]# openssl x509 -in /etc/pki/vdsm/certs/cacert.pem -noout -text | grep Public-Key Public-Key: (1024 bit) Can anyone point me at directions on how to regenerate the key(s) with 2048 bits, and all certificates, preferably without breaking anything? The management server is running RHEL 6.8, rhevm-3.6.7.5. 2) "TLS Version 1.2 Protocol Detection": Port 54321 is failing because it doesn't support TLS v1.2 (and also because its certificate's key is less than 2048 bits). This port is used by "/usr/bin/python /usr/share/vdsm/vdsm". Can I enable TLS v1.2 in vdsm? It doesn't have to accept TLSv1.2 exclusively, it just has to have v1.2 available (and NOT SSLv2 or 3). If I firewall off these ports, I can't connect to VMs' consoles anymore, so hiding from the scanner isn't feasible for long. Please help point me in the right direction. Thanks, Chris -- *The Starflyer is real!*

1 0

LDAP-based domain not working after upgrade?
by Nicolás 15 Aug '16

15 Aug '16

Hi, We're running oVirt 4.0.1.1, and we're trying to grant a permission to a user on a VM. Thing is when we open the 'Permissions' subtab on that VM, we click on Add, the LDAP backend shows up but any value entered into the search box returns nothing, even when I know the values exist. This has been working on oVirt 3.x, we actually migrated to 4.x last week and didn't notice this issue. Additionally, there's no combobox to choose the permission to grant? All this is done with the admin@internal user, so I guess this is not a self-permission issue. Interesting thing is that I can successfully log-in to the user portal with a LDAP based user and manage all the VMs assigned to them. Just to see if there's been any configuration change, we also run the ovirt-engine-extension-aaa-ldap-setup tool, the configuration it returns is pretty similar to ours, and even the test commands (Login, Search) work successfully (I can see search returning user's data like name, surname, ...). We even applied this configuration to engine to see if it makes a difference but the result is the same, the search dialog returns nothing and neither I can see the permission to grant. Any hint about this? Thanks

4 14

xml config file being used in ovirt different from virsh?
by Bill Bill 15 Aug '16

15 Aug '16

--_000_CO2PR0801MB07431E23EE4A4AFFE56128E0A61F0CO2PR0801MB0743_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIGEgVk0gd2l0aCBuZXR3b3JrIGZpbHRlcmluZyBlbmFibGVkLCBzcGVjaWZpY2FsbHkg dGhlIGNsZWFuLXRyYWZmaWMgZmlsdGVyLg0KDQpUaHJvdWdoIHZpcnNoLCBJIG1vZGlmeSB0aGUg Y29uZmlndXJhdGlvbiB0byByZWZsZWN0IGNoYW5nZXMgbGlrZSB0aGlzOg0KDQogICAgIDxmaWx0 ZXJyZWYgZmlsdGVyPSdjbGVhbi10cmFmZmljJz4NCiAgICAgICAgPHBhcmFtZXRlciBuYW1lPSdJ UCcgdmFsdWU9JzE5Mi4xNjguMTAuMTAuJy8+DQogICAgICAgIDxwYXJhbWV0ZXIgbmFtZT0nSVAn IHZhbHVlPScxOTIuMTY4LjEwLjExJy8+DQogICAgICA8L2ZpbHRlcnJlZj4NCg0KVGhpcyBvbmx5 IGFsbG93cyB0aG9zZSB0d28gc3BlY2lmaWVkIElQ4oCZcyB0byBjb21tdW5pY2F0ZSBvbiB0aGUg Vk0uIEnigJl2ZSBkZWZpbmVkIHRoZSB4bWwgdGhyb3VnaCB2aXJzaC4NCg0KTm93LCBpZiBJIHN0 YXJ0IHRoZSBWTSBkaXJlY3RseSB0aHJvdWdoIHZpcnNoLCB0aG9zZSBydWxlcyBhcHBseSBhbmQg d29yayBjb3JyZWN0bHkuIEkgY2FuIGFkZCBhbnkgb3RoZXIgcmFuZG9tIElQIGZyb20gdGhlIHNh bWUgc3VibmV0IGFuZCBpdCBkb2VzIG5vdCB3b3JrLCBhcyBleHBlY3RlZC4gT25seSB0aGUgdHdv IElw4oCZcyBzcGVjaWZpZWQgYWJvdmUgd2lsbCByZXNwb25kLg0KDQpUaGlzIHVuZm9ydHVuYXRl bHksIG1ha2VzIHRoZSBWTSBhcHBlYXIgdG8gYmUgZG93biBmcm9tIHdpdGggdGhlIG92aXJ0IGRh c2hib2FyZCBpZiBpdOKAmXMgc3RhcnRlZCBtYW51YWxseSB0aHJvdWdoIHZpcnNoLg0KDQpJZiBJ IGVkaXQgdGhlIG1hY2hpbmUgdGhyb3VnaCB2aXJzaCBidXQgZG8gbm90IHN0YXJ0IGl0IGFuZCB0 aGVuIGdvIG9udG8gb1ZpcnQgdG8gc3RhcnQgdGhlIFZNLCBpdCBzZWVtcyB0aGUgY29uZmlndXJh dGlvbiBpcyBub3QgbG9hZGVkIOKAkyBkb2VzIG9WaXJ0IGxvYWQgYSBkaWZmZXJlbnQgY29uZmln dXJhdGlvbiBmaWxlIG90aGVyIHRoYW4gL2V0Yy9saWJ2aXJ0L3FlbXUvbWFjaGluZS54bWw/DQo= --_000_CO2PR0801MB07431E23EE4A4AFFE56128E0A61F0CO2PR0801MB0743_ Content-Type: text/html; charset="utf-8" Content-ID: <4B0D61C4EF4E6348BF40DF4B18975372(a)sct-15-1-485-2-msonline-outlook-1173a.templateTenant> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0iIzk1NEY3 MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBo YXZlIGEgVk0gd2l0aCBuZXR3b3JrIGZpbHRlcmluZyBlbmFibGVkLCBzcGVjaWZpY2FsbHkgdGhl IGNsZWFuLXRyYWZmaWMgZmlsdGVyLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhyb3VnaCB2aXJzaCwgSSBtb2Rp ZnkgdGhlIGNvbmZpZ3VyYXRpb24gdG8gcmVmbGVjdCBjaGFuZ2VzIGxpa2UgdGhpczo8L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7ZmlsdGVycmVmIGZpbHRlcj0nY2xl YW4tdHJhZmZpYycmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtwYXJhbWV0ZXIgbmFtZT0nSVAnIHZhbHVl PScxOTIuMTY4LjEwLjEwLicvJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7cGFyYW1ldGVyIG5hbWU9J0lQ JyB2YWx1ZT0nMTkyLjE2OC4xMC4xMScvJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L2ZpbHRlcnJlZiZndDs8L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+VGhpcyBv bmx5IGFsbG93cyB0aG9zZSB0d28gc3BlY2lmaWVkIElQ4oCZcyB0byBjb21tdW5pY2F0ZSBvbiB0 aGUgVk0uIEnigJl2ZSBkZWZpbmVkIHRoZSB4bWwgdGhyb3VnaCB2aXJzaC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyxzZXJpZiI+Tm93LCBpZiBJIHN0YXJ0IHRoZSBWTSBkaXJlY3RseSB0aHJvdWdoIHZpcnNoLCB0 aG9zZSBydWxlcyBhcHBseSBhbmQgd29yayBjb3JyZWN0bHkuIEkgY2FuIGFkZCBhbnkgb3RoZXIg cmFuZG9tIElQIGZyb20gdGhlIHNhbWUgc3VibmV0IGFuZCBpdCBkb2VzIG5vdCB3b3JrLCBhcyBl eHBlY3RlZC4NCiBPbmx5IHRoZSB0d28gSXDigJlzIHNwZWNpZmllZCBhYm92ZSB3aWxsIHJlc3Bv bmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPlRoaXMgdW5mb3J0dW5hdGVseSwgbWFrZXMgdGhlIFZN IGFwcGVhciB0byBiZSBkb3duIGZyb20gd2l0aCB0aGUgb3ZpcnQgZGFzaGJvYXJkIGlmIGl04oCZ cyBzdGFydGVkIG1hbnVhbGx5IHRocm91Z2ggdmlyc2guPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPklm IEkgZWRpdCB0aGUgbWFjaGluZSB0aHJvdWdoIHZpcnNoIGJ1dCBkbyBub3Qgc3RhcnQgaXQgYW5k IHRoZW4gZ28gb250byBvVmlydCB0byBzdGFydCB0aGUgVk0sIGl0IHNlZW1zIHRoZSBjb25maWd1 cmF0aW9uIGlzIG5vdCBsb2FkZWQg4oCTIGRvZXMgb1ZpcnQgbG9hZCBhIGRpZmZlcmVudCBjb25m aWd1cmF0aW9uDQogZmlsZSBvdGhlciB0aGFuIC9ldGMvbGlidmlydC9xZW11L21hY2hpbmUueG1s PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CO2PR0801MB07431E23EE4A4AFFE56128E0A61F0CO2PR0801MB0743_--

3 4

new internal SSO
by Fabrice Bacchella 15 Aug '16

15 Aug '16

--Apple-Mail=_138C94D8-E499-4C85-8D42-96B668C52119 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm currently fighting with the new mandatory SSO system introduced in = 4.0. It's also used internally as ovirt-engine is calling himself, as shown = in the apache log, to identity himself to himself: [2016-08-12 11:30:24] 10.83.16.34 "ovirt.prod.exalead.com" "POST = /ovirt-engine/sso/status HTTP/1.1" 256 401 + 163 "-" "Java/1.8.0_92" [2016-08-12 10:55:49] 10.83.16.34 "ovirt.prod.exalead.com" "POST = /ovirt-engine/sso/oauth/token HTTP/1.1" 237 401 + 163 "-" = "Java/1.8.0_92" But the sso will be acceded by human too: [2016-08-12 11:29:27] 192.168.205.59 "ovirt.prod.exalead.com" "GET = /ovirt-engine/sso/interactive-redirect-to-module HTTP/1.1" 5097 302 + - = "https://ovirt.prod.exalead.com/ovirt-engine/" "Mozilla/5.0 (Macintosh; = Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0" I'm using a custom apache configuration, as I need that to better = integrate ovirt in our running SSO and PKI setup. So under SSO I wonder which part needs to be protected using our own = SSO, and what part can be open to any access, and the internal security = of ovirt will manage it ? In https://bugzilla.redhat.com/show_bug.cgi?id=3D1342192, it seems for = me that = ^/ovirt-engine/sso/(interactive-login-negotiate|oauth/token-http-auth) = needs to be protected. Am i right ? In my log, I've seen access to: /ovirt-engine/sso/status /ovirt-engine/sso/oauth/token-info /ovirt-engine/webadmin/sso/oauth2-callback /ovirt-engine/webadmin/sso/login /ovirt-engine/sso/oauth/token /ovirt-engine/sso/oauth/authorize /ovirt-engine/sso/interactive-redirect-to-module /ovirt-engine/sso/interactive-login-next-auth /ovirt-engine/sso/interactive-login-negotiate/ovirt-auth= --Apple-Mail=_138C94D8-E499-4C85-8D42-96B668C52119 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D"">I'm currently fighting with the new mandatory SSO system = introduced in 4.0.<div class=3D""><br class=3D""></div><div = class=3D"">It's also used internally as ovirt-engine is calling himself, = as shown in the apache log, to identity himself to himself:</div><div = class=3D""><br class=3D""></div><div class=3D""><div style=3D"margin: = 0px; font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D""><span style=3D"font-variant-ligatures: no-common-ligatures" = class=3D"">[2016-08-12 11:30:24] 10.83.16.34 "<a = href=3D"http://ovirt.prod.exalead.com" = class=3D"">ovirt.prod.exalead.com</a>" "POST /ovirt-engine/sso/status = HTTP/1.1" 256 401 + 163 "-" "Java/1.8.0_92"</span></div></div><div = class=3D""><span style=3D"font-variant-ligatures: no-common-ligatures" = class=3D""><div style=3D"margin: 0px; font-size: 11px; line-height: = normal; font-family: Menlo;" class=3D""><span = style=3D"font-variant-ligatures: no-common-ligatures" = class=3D"">[2016-08-12 10:55:49] 10.83.16.34 "<a = href=3D"http://ovirt.prod.exalead.com" = class=3D"">ovirt.prod.exalead.com</a>" "POST = /ovirt-engine/sso/oauth/token HTTP/1.1" 237 401 + 163 "-" = "Java/1.8.0_92"</span></div><div class=3D""><span = style=3D"font-variant-ligatures: no-common-ligatures" class=3D""><br = class=3D""></span></div></span></div><div class=3D"">But the sso will be = acceded by human too:</div><div class=3D""><br class=3D""></div><div = class=3D""><div style=3D"margin: 0px; font-size: 11px; line-height: = normal; font-family: Menlo;" class=3D""><span = style=3D"font-variant-ligatures: no-common-ligatures" = class=3D"">[2016-08-12 11:29:27] 192.168.205.59 "<a = href=3D"http://ovirt.prod.exalead.com" = class=3D"">ovirt.prod.exalead.com</a>" "GET = /ovirt-engine/sso/interactive-redirect-to-module HTTP/1.1" 5097 302 + - = "<a href=3D"https://ovirt.prod.exalead.com/ovirt-engine/" = class=3D"">https://ovirt.prod.exalead.com/ovirt-engine/</a>" = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 = Firefox/47.0"</span></div></div><div class=3D""><span = style=3D"font-variant-ligatures: no-common-ligatures" class=3D""><br = class=3D""></span></div><div class=3D""><br class=3D""></div><div = class=3D"">I'm using a custom apache configuration, as I need that to = better integrate ovirt in our running SSO and PKI setup.</div><div = class=3D""><br class=3D""></div><div class=3D"">So under SSO I wonder = which part needs to be protected using our own SSO, and what part can be = open to any access, and the internal security of ovirt will manage it = ?</div><div class=3D""><br class=3D""></div><div class=3D"">In <a = href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1342192" = class=3D"">https://bugzilla.redhat.com/show_bug.cgi?id=3D1342192</a>, it = seems for me that <span style=3D"white-space: pre-wrap;" = class=3D"">^/ovirt-engine/sso/(interactive-login-negotiate|oauth/token-htt= p-auth) needs to be protected. Am i right ?</span></div><div = class=3D""><br class=3D""></div><div class=3D"">In my log, I've seen = access to:</div><div class=3D""><br class=3D"">/ovirt-engine/sso/status<br= class=3D"">/ovirt-engine/sso/oauth/token-info<br = class=3D"">/ovirt-engine/webadmin/sso/oauth2-callback<br = class=3D"">/ovirt-engine/webadmin/sso/login<br = class=3D"">/ovirt-engine/sso/oauth/token<br = class=3D"">/ovirt-engine/sso/oauth/authorize<br = class=3D"">/ovirt-engine/sso/interactive-redirect-to-module<br = class=3D"">/ovirt-engine/sso/interactive-login-next-auth<br = class=3D"">/ovirt-engine/sso/interactive-login-negotiate/ovirt-auth</div><= /body></html>= --Apple-Mail=_138C94D8-E499-4C85-8D42-96B668C52119--

2 2

unable to find valid certification path to requested target
by Bill Bill 15 Aug '16

15 Aug '16

--_000_CO2PR0801MB0743DBC3AD940D3496CE9880A6100CO2PR0801MB0743_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVjZW50bHkgdXBncmFkZWQgb3ZpcnQtZW5naW5lIGFuZCBub3cgY2Fubm90IGxvZyBpbi4gR2V0 dGluZyB0aGUgZXJyb3IgYmVsb3c6DQoNCg0Kc3VuLnNlY3VyaXR5LnZhbGlkYXRvci5WYWxpZGF0 b3JFeGNlcHRpb246IFBLSVggcGF0aCBidWlsZGluZyBmYWlsZWQ6IHN1bi5zZWN1cml0eS5wcm92 aWRlci5jZXJ0cGF0aC5TdW5DZXJ0UGF0aEJ1aWxkZXJFeGNlcHRpb246IHVuYWJsZSB0byBmaW5k IHZhbGlkIGNlcnRpZmljYXRpb24gcGF0aCB0byByZXF1ZXN0ZWQgdGFyZ2V0DQoNCg== --_000_CO2PR0801MB0743DBC3AD940D3496CE9880A6100CO2PR0801MB0743_ Content-Type: text/html; charset="utf-8" Content-ID: <87541A889A1A18439B925049574FD1FF(a)sct-15-1-485-2-msonline-outlook-1173a.templateTenant> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LndlbGNvbWUtdGl0bGUNCgl7bXNvLXN0eWxlLW5hbWU6d2VsY29tZS10aXRsZTt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0iIzk1NEY3MiI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVjZW50 bHkgdXBncmFkZWQgb3ZpcnQtZW5naW5lIGFuZCBub3cgY2Fubm90IGxvZyBpbi4gR2V0dGluZyB0 aGUgZXJyb3IgYmVsb3c6PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJ3ZWxjb21lLXRpdGxlIj5zdW4uc2VjdXJpdHku dmFsaWRhdG9yLlZhbGlkYXRvckV4Y2VwdGlvbjogUEtJWCBwYXRoIGJ1aWxkaW5nIGZhaWxlZDog c3VuLnNlY3VyaXR5LnByb3ZpZGVyLmNlcnRwYXRoLlN1bkNlcnRQYXRoQnVpbGRlckV4Y2VwdGlv bjogdW5hYmxlIHRvIGZpbmQgdmFsaWQgY2VydGlmaWNhdGlvbiBwYXRoIHRvIHJlcXVlc3RlZCB0 YXJnZXQ8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_CO2PR0801MB0743DBC3AD940D3496CE9880A6100CO2PR0801MB0743_--

2 1