[Yahoo-eng-team] [Bug 1388351] [NEW] NoVNC does not work under python 2.7.4
Public bug reported:
noVNCproxy will not be functional if python version lower than 2.7.4.
It will raise exception as below:
parse = urlparse.urlparse(self.path)
if parse.scheme not in ('http', 'https'):
# From a bug in urlparse in Python 2.7.4 we cannot support
# special schemes (cf: http://bugs.python.org/issue9374)
if sys.version_info (2, 7, 4):
raise exception.NovaException(
_(We do not support scheme '%s' under Python 2.7.4,
)
This statement check is Incorrect. Not only because parse.schema will
always be '', but also this is not relevant to any python versions.
The reason is that
1) When user trigger webbrower novnc url such as
http://192.168.1.105:6080/vnc_auto.html?token=2d58d946-1469-48c5-9082-44ac6e1a59e5
basic python TCP modules will parse the request information in
BaseHTTPServer.py. for the HTTP command, URI, and the request version.
2) Since the request is to get the vnc_auto.html. the vnc module will
sent out the html to browser.
3) With the vnc_auto html page rendering, on page load method, it will make a
new request to /websockify.
path = WebUtil.getQueryVar('path', 'websockify');
.
rfb.connect(host, port, password, path);
4) The /websokify request(with token in the cookie) will flow to
websokify framework which following to
NovaProxyRequestHandler(websockify request handler) to make token
validations(rpc sent to nova consoleauth). The token is
5) After token validation passed, NovaProxyRequestHandler will proxy to
compute Host, vnc port(5900)
So by that means, the self.path in
NovaProxyRequestHandlerBase.new_websocket_client will always being
'/websockify'.
It will never return scheme if using urlparse.parse('/websockify') and not
relevant to any python versions.
With removing the check and exception(revert commit
https://review.openstack.org/#/c/125398/), the vnc function will be
function well.
Following is the right flow:
192.168.1.104 - - [01/Nov/2014 14:31:27] # requestline in BaseHTTPServer
py2.7.6: GET /vnc_auto.html?token=2d58d946-1469-48c5-9082-44ac6e1a59e5 HTTP/1.1
192.168.1.104 - - [01/Nov/2014 14:31:27] # self.path is
/vnc_auto.html?token=2d58d946-1469-48c5-9082-44ac6e1a59e5
192.168.1.104 - - [01/Nov/2014 14:31:27] # self.request_version HTTP/1.1
192.168.1.104 - - [01/Nov/2014 14:31:27] GET
/vnc_auto.html?token=2d58d946-1469-48c5-9082-44ac6e1a59e5 HTTP/1.1 200 -
2014-11-01 14:31:28.231 DEBUG nova.console.websocketproxy [-] 192.168.1.104:
new handler Process from (pid=15763) vmsg
/usr/local/lib/python2.7/dist-packages/websockify/websocket.py:824
192.168.1.104 - - [01/Nov/2014 14:31:28] # requestline in py2.7.6: GET
/websockify HTTP/1.1
192.168.1.104 - - [01/Nov/2014 14:31:28] # self.path is /websockify
192.168.1.104 - - [01/Nov/2014 14:31:28] # self.request_version HTTP/1.1
192.168.1.104 - - [01/Nov/2014 14:31:28] GET /websockify HTTP/1.1 101 -
192.168.1.104 - - [01/Nov/2014 14:31:28] 192.168.1.104: Plain non-SSL (ws://)
WebSocket connection
192.168.1.104 - - [01/Nov/2014 14:31:28] 192.168.1.104: Version hybi-13,
base64: 'False'
192.168.1.104 - - [01/Nov/2014 14:31:28] 192.168.1.104: Path: '/websockify'
2014-11-01 14:31:28.270 INFO nova.console.websocketproxy [-] self.path in
new_websocket_client in python276is /websockify
2014-11-01 14:31:28.271 INFO nova.console.websocketproxy [-] parse.scheme in
pythone276 is
2014-11-01 14:31:28.272 INFO nova.console.websocketproxy [-] parse.query in
new_websocket_client
2014-11-01 14:31:28.272 INFO nova.console.websocketproxy [-] token after
urlparse.parse_qs:
2014-11-01 14:31:28.273 INFO nova.console.websocketproxy [-] self.headers is
Host: 192.168.1.105:6080
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101
Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en,zh-cn;q=0.8,zh-tw;q=0.5,en-us;q=0.3
Accept-Encoding: gzip, deflate
Sec-WebSocket-Version: 13
Origin: http://192.168.1.105:6080
Sec-WebSocket-Protocol: binary, base64
Sec-WebSocket-Key: FxJXwRLEslPNU+nmcwIVzw==
Cookie: token=2d58d946-1469-48c5-9082-44ac6e1a59e5
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
2014-11-01 14:31:28.282 INFO oslo.messaging._drivers.impl_rabbit
[req-1404bf1a-b530-4708-be0c-007bafcbf998 None None] Connecting to AMQP server
on 127.0.0.1:5672
2014-11-01 14:31:28.300 INFO oslo.messaging._drivers.impl_rabbit
[req-1404bf1a-b530-4708-be0c-007bafcbf998 None None] Connected to AMQP server
on 127.0.0.1:5672
2014-11-01 14:31:28.305 INFO oslo.messaging._drivers.impl_rabbit
[req-1404bf1a-b530-4708-be0c-007bafcbf998 None None] Connecting to AMQP server
on 127.0.0.1:5672
2014-11-01 14:31:28.312 INFO oslo.messaging._drivers.impl_rabbit
[req-1404bf1a-b530-4708-be0c-007bafcbf998 None None] Connected to AMQP server
on 127.0.0.1:5672
2014-11-01 14:31:28.405 INFO
[Yahoo-eng-team] [Bug 1388062] Re: Flag in keystone.conf to remove password panel when using ldap for authentication
*** This bug is a duplicate of bug 1347354 *** https://bugs.launchpad.net/bugs/1347354 This sounds like a duplicate of bug 1347354, you can hide the panel by updating Horizon's keystone_policy.json file [1]. (keystone.conf is a Keystone file that Horizon would have no visibility into.) [1] https://github.com/openstack/horizon/blob/master/openstack_dashboard/conf/keystone_policy.json ** This bug has been marked a duplicate of bug 1347354 User keystone policy to check if user password can be updated -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1388062 Title: Flag in keystone.conf to remove password panel when using ldap for authentication Status in OpenStack Dashboard (Horizon): New Bug description: When using ldap for authentication, the password panel still is visible in Horizon. Therefore I suggest it would be good to have the ability to set a flag in the keystone.conf that if you're using LDAP for auth it disables the password panel. Generally most companies have their own portal where users change their password. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1388062/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1295186] Re: Horizon change password fails when Keystone+LDAP.
Going to close this since it can be configured already for the environments where users aren't allowed to change their own password. ** Changed in: horizon Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1295186 Title: Horizon change password fails when Keystone+LDAP. Status in OpenStack Dashboard (Horizon): Invalid Bug description: Description of problem: When using Keystone+LDAP, setting\change password on Horizon fails - Error: Unable to change password. Version-Release number of selected component (if applicable): RHEL 6.5 openstack-dashboard-2013.2.2-1.el6ost.noarch openstack-keystone-2013.2.2-1.el6ost.noarch How reproducible: Every time Steps to Reproduce: 1. Build setup 2. Configure keystone to use LDAP 3. Login with user to Horizon, click settings, change password Actual results: Can't change password - Error: Unable to change password. Expected results: As a user i'd prefer any of the below options rather than a none informative Error: Unable to change password. * If possible make Horizon/Keystone update LDAP and actually change the password. * If not possible to update LDAP, than notify user LDAP authentication in use, please change password on LDAP. Or gray out change password while LDAP in use. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1295186/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1388386] [NEW] libvirt: boot instance with utf-8 name results in UnicodeDecodeError
Public bug reported: With the libvirt driver and Juno 2014.2 code, try to boot a server via Horizon with name ＡＢＣ一丁七ÇàâｱｲｳДфэبتثअइउ€¥噂ソ十豹竹敷 results in: http://paste.openstack.org/show/128060/ This is new in Juno but was a latent issue since Icehouse, the Juno change was: https://github.com/openstack/nova/commit/60c90f73261efb8c73ecc02152307c81265cab13 The err variable is an i18n Message object and when we try to put the domain.XMLDesc(0) into the unicode _LE message object string it blows up in oslo.i18n because the encoding doesn't match. The fix is to wrap domain.XMLDesc(0) in oslo.utils.encodeutils.safe_decode. ** Affects: nova Importance: Undecided Assignee: Matt Riedemann (mriedem) Status: Triaged ** Tags: i18n icehouse-backport-potential juno-backport-potential libvirt ** Changed in: nova Status: New = Triaged -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1388386 Title: libvirt: boot instance with utf-8 name results in UnicodeDecodeError Status in OpenStack Compute (Nova): Triaged Bug description: With the libvirt driver and Juno 2014.2 code, try to boot a server via Horizon with name ＡＢＣ一丁七ÇàâｱｲｳДфэبتثअइउ€¥噂ソ十豹竹敷 results in: http://paste.openstack.org/show/128060/ This is new in Juno but was a latent issue since Icehouse, the Juno change was: https://github.com/openstack/nova/commit/60c90f73261efb8c73ecc02152307c81265cab13 The err variable is an i18n Message object and when we try to put the domain.XMLDesc(0) into the unicode _LE message object string it blows up in oslo.i18n because the encoding doesn't match. The fix is to wrap domain.XMLDesc(0) in oslo.utils.encodeutils.safe_decode. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1388386/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1388457] [NEW] Ability to add a contact email address on the Horizon Login Page
Public bug reported: I think it would be quite useful to have the ability to add a contact email address on the login page of Horizon. I was thinking this could be set by a variable within the local_settings.py under the Default OpenStack Dashboard configuration section. See attachment. ** Affects: horizon Importance: Undecided Status: New ** Attachment added: email_login_screen.png https://bugs.launchpad.net/bugs/1388457/+attachment/4250989/+files/email_login_screen.png -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1388457 Title: Ability to add a contact email address on the Horizon Login Page Status in OpenStack Dashboard (Horizon): New Bug description: I think it would be quite useful to have the ability to add a contact email address on the login page of Horizon. I was thinking this could be set by a variable within the local_settings.py under the Default OpenStack Dashboard configuration section. See attachment. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1388457/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1343271] Re: Error running keystone-manage token_flush
[Expired for Keystone because there has been no activity for 60 days.]
** Changed in: keystone
Status: Incomplete = Expired
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1343271
Title:
Error running keystone-manage token_flush
Status in OpenStack Identity (Keystone):
Expired
Bug description:
I have 1.3 million rows in my keystone.token table, so I'm trying to
trim this with the command keystone-manage token_flush. However, this
command fails with the following message:
keystone-manage token_flush
/usr/lib/python2.6/site-packages/keystone/openstack/common/db/sqlalchemy/session.py:424:
DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
m = re.match(operational_error.message)
The real error is the following:
2014-07-17 13:16:19.830 8982 TRACE keystone Traceback (most recent call last):
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/bin/keystone-manage, line 51, in module
2014-07-17 13:16:19.830 8982 TRACE keystone cli.main(argv=sys.argv,
config_files=config_files)
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/lib/python2.6/site-packages/keystone/cli.py, line 190, in main
2014-07-17 13:16:19.830 8982 TRACE keystone CONF.command.cmd_class.main()
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/lib/python2.6/site-packages/keystone/cli.py, line 154, in main
2014-07-17 13:16:19.830 8982 TRACE keystone
token_manager.driver.flush_expired_tokens()
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/lib/python2.6/site-packages/keystone/token/backends/sql.py, line 229, in
flush_expired_tokens
2014-07-17 13:16:19.830 8982 TRACE keystone
query.delete(synchronize_session=False)
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/lib64/python2.6/site-packages/sqlalchemy/orm/query.py, line 2603, in
delete
2014-07-17 13:16:19.830 8982 TRACE keystone delete_op.exec_()
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/lib64/python2.6/site-packages/sqlalchemy/orm/persistence.py, line 816,
in exec_
2014-07-17 13:16:19.830 8982 TRACE keystone self._do_exec()
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/lib64/python2.6/site-packages/sqlalchemy/orm/persistence.py, line 942,
in _do_exec
2014-07-17 13:16:19.830 8982 TRACE keystone params=self.query._params)
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/lib/python2.6/site-packages/keystone/openstack/common/db/sqlalchemy/session.py,
line 439, in _wrap
2014-07-17 13:16:19.830 8982 TRACE keystone return f(self, *args,
**kwargs)
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/lib/python2.6/site-packages/keystone/openstack/common/db/sqlalchemy/session.py,
line 709, in execute
2014-07-17 13:16:19.830 8982 TRACE keystone return super(Session,
self).execute(*args, **kwargs)
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/lib64/python2.6/site-packages/sqlalchemy/orm/session.py, line 934, in
execute
2014-07-17 13:16:19.830 8982 TRACE keystone clause, params or {})
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/lib64/python2.6/site-packages/sqlalchemy/engine/base.py, line 662, in
execute
2014-07-17 13:16:19.830 8982 TRACE keystone params)
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/lib64/python2.6/site-packages/sqlalchemy/engine/base.py, line 761, in
_execute_clauseelement
2014-07-17 13:16:19.830 8982 TRACE keystone compiled_sql, distilled_params
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/lib64/python2.6/site-packages/sqlalchemy/engine/base.py, line 874, in
_execute_context
2014-07-17 13:16:19.830 8982 TRACE keystone context)
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/lib64/python2.6/site-packages/sqlalchemy/engine/base.py, line 1024, in
_handle_dbapi_exception
2014-07-17 13:16:19.830 8982 TRACE keystone exc_info
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/lib64/python2.6/site-packages/sqlalchemy/util/compat.py, line 196, in
raise_from_cause
2014-07-17 13:16:19.830 8982 TRACE keystone reraise(type(exception),
exception, tb=exc_tb)
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/lib64/python2.6/site-packages/sqlalchemy/engine/base.py, line 867, in
_execute_context
2014-07-17 13:16:19.830 8982 TRACE keystone context)
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/lib64/python2.6/site-packages/sqlalchemy/engine/default.py, line 324, in
do_execute
2014-07-17 13:16:19.830 8982 TRACE keystone cursor.execute(statement,
parameters)
2014-07-17 13:16:19.830 8982 TRACE keystone File
/usr/lib64/python2.6/site-packages/MySQLdb/cursors.py, line 173, in execute
2014-07-17 13:16:19.830 8982 TRACE keystone self.errorhandler(self, exc,
value)
2014-07-17 13:16:19.830 8982 TRACE keystone File
