qos problem in ovirt python sdk
by like.ma＠cs2c.com.cn
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_=------
8 years, 3 months
oVirt-shell command to move a disk
by Nicolas Ecarnot
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
8 years, 3 months
oVirt 4.0 and multipath.conf for HPE 3PAR. What do you advise?
by aleksey.maksimov＠it-kb.ru
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-d...
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?
8 years, 3 months
restore db table
by Fernando Fuentes
Looks like running a remote reports wiped my reports table.
postgres=# \list
List of databases
Name | Owner | Encoding | Collate |
Ctype | Access privileges
----------------------+----------------------+----------+-------------+-------------+-----------------------
engine | engine | UTF8 | en_US.UTF-8 |
en_US.UTF-8 |
ovirt_engine_history | ovirt_engine_history | UTF8 | en_US.UTF-8 |
en_US.UTF-8 |
postgres | postgres | UTF8 | en_US.UTF-8 |
en_US.UTF-8 |
template0 | postgres | UTF8 | en_US.UTF-8 |
en_US.UTF-8 | =c/postgres +
| | | |
| postgres=CTc/postgres
template1 | postgres | UTF8 | en_US.UTF-8 |
en_US.UTF-8 | =c/postgres +
| | | |
| postgres=CTc/postgres
(5 rows)
postgres=# \c ovirt_engine_history;
You are now connected to database "ovirt_engine_history" as user
"postgres".
ovirt_engine_history=# \dt
No relations found.
ovirt_engine_history=#
Is there a way to just restore that table?
Regards,
--
Fernando Fuentes
ffuentes(a)txweather.org
http://www.txweather.org
8 years, 3 months
Short SSL key sizes, and TLS 1.2 on vdsm
by Chris H
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!*
8 years, 3 months
LDAP-based domain not working after upgrade?
by Nicolás
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
8 years, 3 months
xml config file being used in ovirt different from virsh?
by Bill Bill
--_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_--
8 years, 3 months
new internal SSO
by Fabrice Bacchella
--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--
8 years, 3 months
unable to find valid certification path to requested target
by Bill Bill
--_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_--
8 years, 3 months
