Re: [Openstack] IMPORTANT: Openstack List Migration (Please read)
Yes, but subscribing for that gets a page with The requested URL /mailman/subscribe/openstack was not found on this server. On 07/25/2013 08:52 AM, Damion Parry wrote: Hello, I happened to stumble across: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack HTH, Damion. On 25 Jul 2013, at 13:50, Sylvain Bauza sylvain.ba...@bull.net mailto:sylvain.ba...@bull.net wrote: Hi, Nope, I was talking about the openst...@lists.openstack.org ML, which I can't find on mailman. The link you gave me is about openstack-dev@, not openstack@. If Paul Hummel (or other) could tell us what to do to subscribe to the fresh new openst...@lists.openstack.org, it would be great :-) -Sylvain Le 25/07/2013 14:13, Paul Michali a écrit : From the main page, you click on the list name and it takes you to a link on how to subscribe/unsubscribe... http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev PCM (Paul Michali) MAIL p...@cisco.com mailto:p...@cisco.com IRC pcm_ (irc.freenode.net http://irc.freenode.net/) TW @pmichali On Jul 25, 2013, at 3:06 AM, Sylvain Bauza sylvain.ba...@bull.net mailto:sylvain.ba...@bull.net wrote: Hi Paul, Apologies if I missed any related info, but how to subscribe to the new lists.openstack.org http://lists.openstack.org/ list ? I can't find my way thru mailman [1] Thanks, -Sylvain [1] : http://lists.openstack.org/cgi-bin/mailman/listinfo Le 24/07/2013 18:19, Paul Hummer a écrit : Openstackers- You've probably seen talk of migrating this list from Launchpad to lists.openstack.org http://lists.openstack.org/. It's happening. This will affect you, and if you don't read through this, you could find yourself wondering where everyone went when you send emails to this list. Here's the timeline: 100UTC Friday - The Launchpad group ~openstack will be put in invite-only, so no new users will be able to sign up. At this point, I'll get a Launchpad Admin to provide all the data from the mailing list, and migrate it to lists.openstack.org http://lists.openstack.org/ 100UTC Saturday - The mailing list migration will be complete, and all users will be migrated over to lists.openstack.org http://lists.openstack.org/. From then on, openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net will be a dead list, and openst...@lists.openstack.org mailto:openst...@lists.openstack.org will be the actual list. If you continue to send emails to the Launchpad list, this will be you: http://i.imgur.com/MQUmmqo.gif If you have any questions, ask away. Cheers, Paul ___ Mailing list:https://launchpad.net/~openstack Post to :openstack@lists.launchpad.net Unsubscribe :https://launchpad.net/~openstack More help :https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] glance: Invalid Openstack Identity Credentials
On 07/24/2013 10:45 AM, Salvatore Orlando wrote:
Hav you tried checking the credentials that glance uses for validating
tokens with keystone?
They are defined in glance's conf files in the section:
[keystone_authtoken]
signing_dir = /var/cache/glance/api
make sure that the directory
/var/cache/glance/api
exists and has the certificates in it. A good test is to remove the
certifcates and hit the server again, as they are fetched on demand. If
there are no certificates there after another try, either glance can't
talk to Keystone or keystone is not handing out the certificates.
auth_uri = http://127.0.0.1:5000/
auth_host = 127.0.0.1
auth_port = 35357
auth_protocol = http
admin_tenant_name = service
admin_user = glance
admin_password = password
Salvatore
On 18 July 2013 22:16, Matt Davis mattd5...@gmail.com
mailto:mattd5...@gmail.com wrote:
Hello all,
I'm working on a deployment script to install and configure my
OpenStack services and I'm getting a strange result with glance.
It's surely a bug with my script messing up a config file line,
but I can't interpret the glance and keystone logs to track the
issue down. Here's the use case:
1) Install keystone following the directions in the Grizzly
installation guide for Ubuntu 12.04.
2) Install glance following the directions in the Grizzly
installation guide for Ubuntu 12.04.
3) Run glance image-list to see if I can get an empty list.
My result:
=
glance --os-username=admin --os-password=secrete --os-tenant-name
demo --os-auth-url=http://localhost:5000/v2.0 image-list
Request returned failure status.
Invalid OpenStack Identity credentials.
=
The glance API log is as follows:
=
2013-07-18 11:18:24.301 6306 DEBUG
glance.api.middleware.version_negotiation [-] Determining version
of request: GET //v1/images/detail Accept: process_request
/usr/lib/python2.7/dist-packages/glance/api/middleware/version_negotiation.py:46
2013-07-18 11:18:24.302 6306 DEBUG
glance.api.middleware.version_negotiation [-] Using url versioning
process_request
/usr/lib/python2.7/dist-packages/glance/api/middleware/version_negotiation.py:59
2013-07-18 11:18:24.302 6306 DEBUG
glance.api.middleware.version_negotiation [-] Matched version: v1
process_request
/usr/lib/python2.7/dist-packages/glance/api/middleware/version_negotiation.py:71
2013-07-18 11:18:24.302 6306 DEBUG
glance.api.middleware.version_negotiation [-] new uri
/v1/images/detail process_request
/usr/lib/python2.7/dist-packages/glance/api/middleware/version_negotiation.py:72
=
No entries are added to the glance registry log. If I tweak the
password to make the credentials invalid, I get this:
=
glance --os-username=admin --os-password=wrong_pw --os-tenant-name
demo --os-auth-url=http://localhost:5000/v2.0 image-list
Unable to communicate with identity service: {error: {message:
Invalid user / password, code: 401, title: Not
Authorized}}. (HTTP 401)
=
So keystone is definitely looking up my credentials and responding
differently when they match.
Any ideas as to where should I be looking for the issue?
Thanks for your time!
-Matt
___
Mailing list: https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
Post to : openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] glance: Invalid Openstack Identity Credentials
I wrote this up as a general answer. Hope it helps.
https://adam.younglogic.com/2013/07/troubleshooting-pki-middleware/
On 07/24/2013 11:44 AM, Adam Young wrote:
On 07/24/2013 10:45 AM, Salvatore Orlando wrote:
Hav you tried checking the credentials that glance uses for
validating tokens with keystone?
They are defined in glance's conf files in the section:
[keystone_authtoken]
signing_dir = /var/cache/glance/api
make sure that the directory
/var/cache/glance/api
exists and has the certificates in it. A good test is to remove the
certifcates and hit the server again, as they are fetched on demand.
If there are no certificates there after another try, either glance
can't talk to Keystone or keystone is not handing out the certificates.
auth_uri = http://127.0.0.1:5000/
auth_host = 127.0.0.1
auth_port = 35357
auth_protocol = http
admin_tenant_name = service
admin_user = glance
admin_password = password
Salvatore
On 18 July 2013 22:16, Matt Davis mattd5...@gmail.com
mailto:mattd5...@gmail.com wrote:
Hello all,
I'm working on a deployment script to install and configure my
OpenStack services and I'm getting a strange result with glance.
It's surely a bug with my script messing up a config file line,
but I can't interpret the glance and keystone logs to track the
issue down. Here's the use case:
1) Install keystone following the directions in the Grizzly
installation guide for Ubuntu 12.04.
2) Install glance following the directions in the Grizzly
installation guide for Ubuntu 12.04.
3) Run glance image-list to see if I can get an empty list.
My result:
=
glance --os-username=admin --os-password=secrete --os-tenant-name
demo --os-auth-url=http://localhost:5000/v2.0 image-list
Request returned failure status.
Invalid OpenStack Identity credentials.
=
The glance API log is as follows:
=
2013-07-18 11:18:24.301 6306 DEBUG
glance.api.middleware.version_negotiation [-] Determining version
of request: GET //v1/images/detail Accept: process_request
/usr/lib/python2.7/dist-packages/glance/api/middleware/version_negotiation.py:46
2013-07-18 11:18:24.302 6306 DEBUG
glance.api.middleware.version_negotiation [-] Using url
versioning process_request
/usr/lib/python2.7/dist-packages/glance/api/middleware/version_negotiation.py:59
2013-07-18 11:18:24.302 6306 DEBUG
glance.api.middleware.version_negotiation [-] Matched version: v1
process_request
/usr/lib/python2.7/dist-packages/glance/api/middleware/version_negotiation.py:71
2013-07-18 11:18:24.302 6306 DEBUG
glance.api.middleware.version_negotiation [-] new uri
/v1/images/detail process_request
/usr/lib/python2.7/dist-packages/glance/api/middleware/version_negotiation.py:72
=
No entries are added to the glance registry log. If I tweak the
password to make the credentials invalid, I get this:
=
glance --os-username=admin --os-password=wrong_pw
--os-tenant-name demo --os-auth-url=http://localhost:5000/v2.0
image-list
Unable to communicate with identity service: {error:
{message: Invalid user / password, code: 401, title: Not
Authorized}}. (HTTP 401)
=
So keystone is definitely looking up my credentials and
responding differently when they match.
Any ideas as to where should I be looking for the issue?
Thanks for your time!
-Matt
___
Mailing list: https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
Post to : openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list:https://launchpad.net/~openstack
Post to :openstack@lists.launchpad.net
Unsubscribe :https://launchpad.net/~openstack
More help :https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone client auth plugins
On 07/18/2013 12:33 AM, Alessio Ababilov wrote: Hi, Chmouel! I have seen your commit https://review.openstack.org/#/c/36427/2 introducing auth plugins to keystone client. I have developed a common API client library that already has auth plugin mechanism found in novaclient. The library can be used in keystone, nova, and glance clients, and now it is accepted to marconi client ( https://github.com/stackforge/python-marconiclient/tree/master/marconiclient/common/apiclient). The library has several important features: * reissue authentication request for expired tokens; * pluggable authentication; * rich exceptions hierarchy; * utils for building CLI tools; * share one token between sessions to different servers (nova, glance, keystone, etc) The library is ready to use in keystone client. Could you take a look on it, please? Alessio Ababilov Senior Software Engineer Grid Dynamics ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Would it be possible to move that code to Keystone Client? We'd love to use it, but the Keystone team is working on Auth, and to have the auth mechanisms spit out of our project will put a real burden on getting things working and fixed. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] can one user in multiple tenants?
The CLI keystone user-role-list should be returning that, so long as you
don't filter by tenant.
From an API perspective, you would call
/users/{user_id}/roles
http://docs.openstack.org/developer/keystone/api_curl_examples.html#get-users-user-id-roles
On 07/18/2013 04:04 AM, Peter Cheung wrote:
I understand now, the tenant is keystone user-get is the default
tenant ID. User can have many roles in different tenant.
But we don't have a command to list out all roles among all tenant for
a specific user.
take a look this screen:
http://peter.kingofcoders.com/?p=779
Date: Thu, 18 Jul 2013 00:15:52 -0400
From: ayo...@redhat.com
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] can one user in multiple tenants?
On 07/18/2013 12:12 AM, Peter Cheung wrote:
Hi all
1) can one user in multiple tenants? I think yes, but when i
keystone user-get, i can see only one tenant field.
User has a role assignemnt. The default role is Member, and they can
have this role in multiple tenants. You are seeing the default tenant
field.
2) how can i assign another tenant to a specific user? which
command can do that?
keystone user-role-add
Thanks
from Peter
___
Mailing list: https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
Post to : openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
More help : https://help.launchpad.net/ListHelp
___ Mailing list:
https://launchpad.net/~openstack Post to :
openstack@lists.launchpad.net Unsubscribe :
https://launchpad.net/~openstack More help :
https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] can one user in multiple tenants?
On 07/18/2013 12:12 AM, Peter Cheung wrote: Hi all 1) can one user in multiple tenants? I think yes, but when i keystone user-get, i can see only one tenant field. User has a role assignemnt. The default role is Member, and they can have this role in multiple tenants. You are seeing the default tenant field. 2) how can i assign another tenant to a specific user? which command can do that? keystone user-role-add Thanks from Peter ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [keystone] How to validate token without admin privileges
We are moving to an RBAC system for enforcing access to the APIs. So,
where as in the past we enforced is admin when checking a token, in
the future, you can specify your own policy rule.
PKI based Tokens can be verified without talking to Keystone. See the
auth_token middleware and cms.py files in python-keystoneclient to see
how that is done.
On 06/20/2013 04:36 PM, Janus Godard wrote:
Thanks Ravi and Haitao.
The only workaround I found is to create a new token from the one I
want to validate with:
curl -X POST -d '{ auth:{ token:{ id:non-admin-token },
tenantName:testproject }}' -H Content-Type:application/json -H
Accept: application/json http://localhost:5000/v2.0/tokens | python
-mjson.tool
But since it keeps creating tokens it could spam the db if there were
a lot of requests and it requires knowing the tenant name if one wants
to get the roles in the response.
On Thu, Jun 20, 2013 at 4:05 PM, Haitao Jiang jianghai...@gmail.com wrote:
Janus
I think you can use curl and Keystone API to validate your token:
curl -s -H X-Auth-Token: your token http://keystone:5000/v2.0 |
python -mjson.tool
I think you can also validate the token against a tenant by using belongsTo.
Maybe there are better ways.
Best
Haitao
On Thu, Jun 20, 2013 at 12:36 PM, Janus Godard jgv...@gmail.com wrote:
Hi,
I'm new to OpenStack. I'm looking at deploying two 3rd party services along
OpenStack and would like to use Keystone for they authentication mechanism.
Service A will authenticate and get a token from keystone and use it for
REST requests to service B. Those two services don't use WSGI, just the REST
API. Is there a way for service B to validate the token with keystone
without having an admin role or the admin token?
Sorry for the noob question. The only thing I found in the doc is the GET
method that requires admin permissions:
http://docs.openstack.org/api/openstack-identity-service/2.0/content/GET_validateToken_v2.0_tokens__tokenId__Token_Operations.html
And from what I read in the compute admin docs the OpenStack services seem
to rely on admin credentials or token.
Regards,
Janus
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone, pki tokens and memcache
On 06/17/2013 12:27 AM, Sam Morrison wrote: I'm currently looking into Grizzly and have been having some issues getting PKI tokens to work. If I have memcache as the token backend keystone issues uuid based tokens, if I have sql as the backend then it issues PKI tokens. Does this mean you can't use memcache backend if you want to use PKI tokens? Cheers, Sam ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp You are making additional configuration changes beyond the Backend. The config options for PKI vs UUID is defined in keystone/common/config.py 'token_format', group='signing', default=PKI The Backend is in the same place: 'driver', group='token', default='keystone.token.backends.sql.Token' So to set UUID tokens, in the config file, [signing] token_format=UUID or explicitly [signing] token_format=PKI ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone] Splitting the Identity Backend
OK, I think it makes sense. If we keep roles and role assignments in the same place, we don't have the ability to do more complex assignments. So the four backends would then be: Domains Identity (Users, groups) Assignments (could also be called mapping) Projects (Includes roles) Assuming that an existing user has a SQL Identity backend, it would work like this. Domains would be SQL only. The other pieces would be primarily SQL. An LDAP backend will get a variable name from paste. For each domain, the user can specify that any of the other pieces is supported by a specific LDAP backend. Otherwise, it will default to SQL. If an existing user is doing writable LDAP and wishes to contine, all they will gain is the SQL datastore with the domain data in it. This allows us to plug pam/sssd in as well. Those will be Identity only. On 05/21/2013 06:18 AM, David Chadwick wrote: Hi Adam I would propose splitting the backend into two conceptually distinct types of attributes, and then each of these high level types can be arbitrary split into different databases depending upon their sources of authority and who administers them. Your proposal would be just one specialisation of this more general model. The high level distinction I would make is between (read only) identity attributes and (writable) authorisation attributes. The latter are the ones used by the OpenStack services for making access control decisions, whilst the former are never used or seen by the OpenStack services, but are used by organisations to identify and group users into different sets. So HR databases and LDAP servers typically store these identity attributes. An attribute mapping function is needed to map between the former and the latter. We can then organise the user login function as follows: 1. A user logs in and is identified and authenticated, and a set of identity attributes are assigned to him by the authentication function. This could be from a read only LDAP service, or by a federated IDP. It should be pluggable and installation dependent. It could even be done by the user presenting an X.509 certificate and the information extracted from it. This part of Keystone should be highly flexible and adaptable to suit different deployment models. 2. The attribute mapping function maps from his identity attributes to his authz attributes. This can be a null mapping function if needed e.g. if the read only backend LDAP happens to store the users OpenStack projects and roles. But in most cases it will not be null. The mappings are set up by the Keystone administrator. 3. The users authz attributes are stored in his Keystone entry, which must be a writeable database owned by Keystone. Each time the user logins, his authz attributes will be updated to match his current identity attributes. So if an organisation promotes an employee, and changes his LDAP attributes, this could have the effect of automatically escalating his rights in Openstack. Conversely, if an employee is demoted, his rights in OpenStack could be automatically downgraded. It would all depend upon what the mapping rules were ie. whether they were fixed to a user's login ID (in which case his authz attributes would not change) or whether they depended upon his roles in his organisation (in which case they would automatically change). 4. The token is created based on his authz attributes as now, and everything continues as now. So taking the current mix of identity attributes that you identify below, they would be split as follows Domains, Roles, and Projects would be stored in Keystone's writeable database (as they are authz attributes) Groups and User Names (and Passwords) would be stored in the read only identity databases. Role assignments would be done by the attribute mapping function. If you want to split Domains into their own separate Keystone database, this fine, it does not effect the overall model. So, your proposal fits into this high level model, but this high level model provides much more flexibility to implementers and will allow for future expansion regards David On 20/05/2013 17:46, Adam Young wrote: Currently, the Identity backend has Domains, Users , Groups, Roles, Role Assignments and Projects. I've proposed splitting it into 3 distinct pieces. Domain, Identity, and Projects. Here is the rationale: Somewhere between a third and a half of the OpenStack deployments are using LDAP. However, the mapping from LDAP to Identity does not work. LDAP is almost always a read only datasource. While Keystone *can* manage these, it should also be possible to treat the users and groups piece as externally managed. In addition, several organizations have multiple LDAP servers. Not a huge number of servers, but more than one is a very common scenario due to a merger. Each of these should map to a domain. Thus, domain management has to be extracted out of the LDAP
Re: [Openstack] AuthN/AuthZ
On 05/16/2013 11:29 AM, Aaron Knister wrote: Thanks Adam. I was able to get that far after a *lot* of headache. AD's typical schema doesn't map to what OpenStack is expecting, particularly as far as the domain_id attribute is concerned. Sorry about that. I am not too fond of our Domain_id thing either, and working to rectify: When running Keystone under Apache HTTPD how does one use horizon? No change. You can report ports other that 5000/35357 for Keystone's service catalog if you want to have Keystone serve on 443. Or, you can have apache listen on the usual keystone ports. You will want Keystone on a separate machine from Horizon. On Wed, May 15, 2013 at 3:57 PM, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: Run Keystone in Apache HTPD, use Kerberos and the LDAP backend to talk to AD. On 05/14/2013 06:11 PM, Aaron Knister wrote: *bump* Here's the tl;dr version: - How have other folks handled integration of OpenStack with existing authN/authZ infrastructures? I'm particularly interested in the automatic mapping of existing LDAP groups to roles/tenants within openstack. - Are there plans to add support for the auth plugins to the *client modules and CLI tools going forward? I'd be interested in contributing this if it's on the roadmap and hasn't been done yet. - Are there plans to add support for auth plugins/external au th to Horizon? As above, I'm interested in implementing this if there's interest. - I see vague references in the documentation/*client code to using certificates for authentication (without the need for httpd external authentication) which would also eliminate the credentials-in-environment- variables issue. Is using PKI for authentication going to be supported? If so what's the status? Am I perhaps posting this to the wrong list? I didn't get any replies from my original post. Thanks! -Aaron On Tue, May 7, 2013 at 1:52 PM, Aaron Knister aaron.knis...@gmail.com mailto:aaron.knis...@gmail.com wrote: Hi Everyone, I'm looking for feedback and input about what other sites are doing for authentication and authorization with OpenStack. First, some background: I'm currently evaluating OpenStack (Grizzly), specifically working on integration with Active Directory. I'm unable to modify the schema to allow groupOfNames as a SUP of organizationalRole so I've implemented a workaround using openldap and several of its overlays backends to sit in front of AD. That all works just fine, however I really would like to be able to map AD groups to roles/tenants. I suspect I'll end up writing some code to do this-- shouldn't be too hard. Also on the subject of Active Directory, it's a show stopper for me to put un-encrypted AD credentials in environment variables to then pass to the various openstack CLI progs. My ideal workaround would be to use Kerberos authentication which I actually have working. I setup keystone to run under apache based on this documentation with some tweaks here and there: http://docs.openstack.org/developer/keystone/external-auth.html I created an openstack client auth plugin (based on the VOMS auth plugin) using requests_kerberos and this works well with the nova client, however none of the other client tools, including horizon, seem to support authentication plugins or the external authentication concept in general. So, here are my questions: - How have other folks handled integration of OpenStack with existing authN/authZ infrastructures? I'm particularly interested in the automatic mapping of existing LDAP groups to roles/tenants within openstack. - Are there plans to add support for the auth plugins to the *client modules and CLI tools going forward? I'd be interested in contributing this if it's on the roadmap and hasn't been done yet. - Are there plans to add support for auth plugins/external au th to Horizon? As above, I'm interested in implementing this if there's interest. - I see vague references in the documentation/*client code to using certificates for authentication (without the need for httpd external authentication) which would also eliminate the credentials-in-environment-variables issue. Is using PKI for authentication going to be supported? If so what's the status? Thanks in advance! -Aaron ___ Mailing list:https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to :openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe :https
[Openstack] [Keystone] Splitting the Identity Backend
Currently, the Identity backend has Domains, Users , Groups, Roles, Role Assignments and Projects. I've proposed splitting it into 3 distinct pieces. Domain, Identity, and Projects. Here is the rationale: Somewhere between a third and a half of the OpenStack deployments are using LDAP. However, the mapping from LDAP to Identity does not work. LDAP is almost always a read only datasource. While Keystone *can* manage these, it should also be possible to treat the users and groups piece as externally managed. In addition, several organizations have multiple LDAP servers. Not a huge number of servers, but more than one is a very common scenario due to a merger. Each of these should map to a domain. Thus, domain management has to be extracted out of the LDAP backend. Identity would contain users and groups. Projects would contain Projects, Roles, and Role Assignments. Domains would contain only domains. For people happily deploying SQL, nothing should change. A single Database instance can still serve all three backends. It should only mean removing some foreign key constraints. For people that are deploying the current LDAP code and are happy with the layout, we will continue to support the LDAP Project backend. Say an organization has two LDAP servers, and also maintains a public facing cloud backed by SQL. Each of the two LDAP servers would have configurations that correspond to the current layout, although limited only to the user and group subtrees. The domain registry would live in the SQL backend. It would have two entries for the LDAP servers, and these would be immutable. Dynamic domain allocation and deletion would work only for the domains backed by SQL. The main blueprint for this is: https://blueprints.launchpad.net/keystone/+spec/split-identity with supporting blueprints for pieces that can be completed interdependently. Comments welcome. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Grizzly] NoneType object unsubscriptable while setting up keystone
Look in the bug database, I think there is already an entry for this. user-list works in general, so it has to be something in your environment that is triggering it. If I remember correctly, you are likely using the Admin token. What are the openstack variables in your environment? On 05/14/2013 08:10 AM, Daniel wrote: Greetings, I am currently trying to install Grizzly on a single node running Red Hat Enterprise Linux Server release 6.4, using RedHat's RDO repository (http://repos.fedorapeople.org/repos/openstack/openstack-grizzly/epel-6/). The related keystone RPM is openstack-keystone-2013.1-1.el6.noarch. I have followed the instructions from the official documentation (http://docs.openstack.org/grizzly/openstack-compute/install/yum/content/install-keystone.html), without error up to the keystone-manage db_sync (included). After that point, keystone commands return the following error : 'NoneType' object is unsubscriptable. It would appear that the commands work at least in part, since I can see a user directly in the MySQL database after running a keystone user-create command, but I still can't list them : # keystone user-list 'NoneType' object is unsubscriptable The only changes I've made to the keystone.conf file apart from the log configuration are the connection and admin_token parameters. The mysql connection works correctly from the command line, and it would seem it works for the keystone utility as well since the database is populated. I've also found nothing remarkable in the keystone log file. As a side note, trying to install a full Openstack environment with the packstack utility failed with the same error. Where should I look to get more info on that error? Thanks in advance, Daniel. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] AuthN/AuthZ
Run Keystone in Apache HTPD, use Kerberos and the LDAP backend to talk to AD. On 05/14/2013 06:11 PM, Aaron Knister wrote: *bump* Here's the tl;dr version: - How have other folks handled integration of OpenStack with existing authN/authZ infrastructures? I'm particularly interested in the automatic mapping of existing LDAP groups to roles/tenants within openstack. - Are there plans to add support for the auth plugins to the *client modules and CLI tools going forward? I'd be interested in contributing this if it's on the roadmap and hasn't been done yet. - Are there plans to add support for auth plugins/external au th to Horizon? As above, I'm interested in implementing this if there's interest. - I see vague references in the documentation/*client code to using certificates for authentication (without the need for httpd external authentication) which would also eliminate the credentials-in-environment- variables issue. Is using PKI for authentication going to be supported? If so what's the status? Am I perhaps posting this to the wrong list? I didn't get any replies from my original post. Thanks! -Aaron On Tue, May 7, 2013 at 1:52 PM, Aaron Knister aaron.knis...@gmail.com mailto:aaron.knis...@gmail.com wrote: Hi Everyone, I'm looking for feedback and input about what other sites are doing for authentication and authorization with OpenStack. First, some background: I'm currently evaluating OpenStack (Grizzly), specifically working on integration with Active Directory. I'm unable to modify the schema to allow groupOfNames as a SUP of organizationalRole so I've implemented a workaround using openldap and several of its overlays backends to sit in front of AD. That all works just fine, however I really would like to be able to map AD groups to roles/tenants. I suspect I'll end up writing some code to do this-- shouldn't be too hard. Also on the subject of Active Directory, it's a show stopper for me to put un-encrypted AD credentials in environment variables to then pass to the various openstack CLI progs. My ideal workaround would be to use Kerberos authentication which I actually have working. I setup keystone to run under apache based on this documentation with some tweaks here and there: http://docs.openstack.org/developer/keystone/external-auth.html I created an openstack client auth plugin (based on the VOMS auth plugin) using requests_kerberos and this works well with the nova client, however none of the other client tools, including horizon, seem to support authentication plugins or the external authentication concept in general. So, here are my questions: - How have other folks handled integration of OpenStack with existing authN/authZ infrastructures? I'm particularly interested in the automatic mapping of existing LDAP groups to roles/tenants within openstack. - Are there plans to add support for the auth plugins to the *client modules and CLI tools going forward? I'd be interested in contributing this if it's on the roadmap and hasn't been done yet. - Are there plans to add support for auth plugins/external au th to Horizon? As above, I'm interested in implementing this if there's interest. - I see vague references in the documentation/*client code to using certificates for authentication (without the need for httpd external authentication) which would also eliminate the credentials-in-environment-variables issue. Is using PKI for authentication going to be supported? If so what's the status? Thanks in advance! -Aaron ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] keystone
Looks like you have typos in x.sh
On 05/14/2013 08:43 AM, Mahzad Zahedi wrote:
I have followed basic install guide openstack on ubuntu (grizzy) so
for configuration keystone first,
I have created openrc File and added below lines into it:
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=password
export OS_AUTH_URL=http://localhost:5000/v2.0/;
export SERVICE_ENDPOINT=http://localhost:35357/v2.0;
export SERVICE_TOKEN=password
and then again I have created a x.sh file for script that is
mentioned inside of install doc
#!/bin/bash
# Modify these variables as needed
ADMIN_PASSWORD=${ADMIN_PASSWORD:-password}
NOW , when running ./x.sh i have belo errors:
Invalid OpenStack Identity credentials.
./bash_script.sh: line 36: 2: command not found
Invalid OpenStack Identity credentials.
./bash_script.sh: line 38: 2: command not found
Invalid OpenStack Identity credentials.
Invalid OpenStack Identity credentials.
Invalid OpenStack Identity credentials.
usage: keystone user-create --name user-name [--tenant-id tenant-id]
[--pass pass] [--email email]
[--enabled true|false]
keystone user-create: error: argument --tenant-id: expected one argument
./bash_script.sh: line 45: 2: command not found
Invalid OpenStack Identity credentials.
./bash_script.sh: line 48: --tenant-id: command not found
Invalid OpenStack Identity credentials.
./bash_script.sh: line 51: password: command not found
Invalid OpenStack Identity credentials.
./bash_script.sh: line 54: --tenant-id: command not found
Invalid OpenStack Identity credentials.
Invalid OpenStack Identity credentials.
./bash_script.sh: line 58: 2: command not found
usage: keystone user-role-add --user user --role role [--tenant tenant]
keystone user-role-add: error: argument --user/--user-id/--user_id:
expected one argument
usage: keystone user-role-add --user user --role role [--tenant tenant]
keystone user-role-add: error: argument --tenant/--tenant-id: expected
one argument
usage: keystone user-role-add --user user --role role [--tenant tenant]
keystone user-role-add: error: argument --tenant/--tenant-id: expected
one argument
usage: keystone user-role-add --user user --role role [--tenant tenant]
keystone user-role-add: error: argument --tenant/--tenant-id: expected
one argument
./bash_script.sh: line 63: --role-id: command not found
usage: keystone user-role-add --user user --role role [--tenant tenant]
keystone user-role-add: error: argument --tenant/--tenant-id: expected
one argument
usage: keystone user-role-add --user user --role role [--tenant tenant]
keystone user-role-add: error: argument --tenant/--tenant-id: expected
one argument
Invalid OpenStack Identity credentials.
Invalid OpenStack Identity credentials.
Invalid OpenStack Identity credentials.
Invalid OpenStack Identity credentials.
./bash_script.sh: line 72: --description: command not found
usage: keystone service-create --name name --type type
[--description service-description]
keystone service-create: error: argument --description: expected one argument
./bash_script.sh: line 74: OpenStack EC2 service: command not found
Invalid OpenStack Identity credentials.
usage: keystone endpoint-create [--region endpoint-region] --service-id
service-id [--publicurl public-url]
[--adminurl admin-url]
[--internalurl internal-url]
keystone endpoint-create: error: argument --service-id/--service_id:
expected one argument
./bash_script.sh: line 77: --publicurl: command not found
./bash_script.sh: line 79: --internalurl: command not found
usage: keystone endpoint-create [--region endpoint-region] --service-id
service-id [--publicurl public-url]
[--adminurl admin-url]
[--internalurl internal-url]
keystone endpoint-create: error: argument --service-id/--service_id:
expected one argument
./bash_script.sh: line 81: --publicurl: command not found
./bash_script.sh: line 83: --internalurl: command not found
usage: keystone endpoint-create [--region endpoint-region] --service-id
service-id [--publicurl public-url]
[--adminurl admin-url]
[--internalurl internal-url]
keystone endpoint-create: error: argument --service-id/--service_id:
expected one argument
./bash_script.sh: line 85: --publicurl: command not found
usage: keystone endpoint-create [--region endpoint-region] --service-id
service-id [--publicurl public-url]
[--adminurl admin-url]
[--internalurl internal-url]
keystone endpoint-create: error: argument --service-id/--service_id:
expected one argument
./bash_script.sh: line 88: WARNING:: command not found
usage:
Re: [Openstack] Heat PTL candidacy
On 04/23/2013 10:15 AM, Steven Hardy wrote: Repost to correctly include openstack-dev on Cc On Tue, Apr 23, 2013 at 02:45:31PM +0100, Steven Hardy wrote: Hi! I'd like to propose myself as a candidate for the Heat PTL role, ref Thierry's nominations email [1] I've been professionally involved with software engineering for around 13 years, working in a variety of industries, from embedded/kernel development to big-enterprise customer-facing consulting. Having been involved with the Heat project from very near the start, I've been part of the strong core team who are making this project grow from a good idea into something people can actually use (and are using!). I have a deep understanding of our current code-base, and a clear view of our future roadmap (and the challenges we face!), so I believe I am in a good position to step into the role Steve Dake was unfortunately unable to continue with, and do what is required to enable the Heat project to deliver another successful release for Havana. Having attended the summit last week, I have to say I'm even more driven and enthusiastic about the project, so much great feedback and ideas from our users and potential contributors. I look forward to developing more features our users want, and encouraging much wider community participation in the project over the next few months. Thanks! Steve Hardy [1] http://lists.openstack.org/pipermail/openstack-dev/2013-April/007724.html +1. I've worked with Steve Hardy on getting the Heat/Keystone Delegation requirements clear. His professionalism and deep understanding are fantastic. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New site for questions http://ask.openstack.org
Is there a way I can get notified for any new Questions specific to Keystone? I'm a core dev on Keystone, and can probably answer some of the more esoteric stuff. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone]Question: Assignment of default role
Yes, this is new. We are removing the direct associtation between users and projects (Project members) and replacing it with a Role (_member_) The _ is there to ensure it does not conflict with existing roles. The two different ways of associating users to projects was causing problems. With RBAC, we can now enforce policy about project membership that we could not do before. On 02/21/2013 09:39 PM, Leo Toyoda wrote: Hi, everyone I'm using the master branch devstack. I hava a question about assignment of default role (Keystone). When I create a user to specify the tenant, '_member_' is assigned to the roles. $ keystone user-create --name test --tenant-id e61..7f6 --pass test --email t...@example.com +--+---+ | Property | Value| +--+---+ | email | te...@example.com | | enabled | True| |id| af1..8d2 | | name | test| | tenantId | e61..7f6 | +--+---+ $ keystone user-role-list --user test --tenant e61..7f6 +--+--+--+---+ |id| name | user_id | tenant_id | +--+--+--+---+ | 9fe..bab | _member_ | af1..8d2 | e61..7f6 | +--+--+--+---+ Then, assign the Member role to the user. Hitting assigned two roles of 'Member' and '_member_'. $ keystone user-role-add --user af1..8d2 --role 57d..d1f --tenant e61..7f6 $ keystone user-role-list --user af1..8d2 --tenant e61..7f6 +--+--+--+---+ |id| name | user_id | tenant_id | +--+--+--+---+ | 57d..d1f | Member | af1..8d2 | e61..7f6 | | 9fe..bab | _member_ | af1..8d2 | e61..7f6 | +--+--+--+---+ When I create a user without specifying a tenant, I assign 'Member' role. In this case, Only one role is assigned. $ keystone user-create --name test2 --pass test --email te...@example.com +--+---+ | Property | Value| +--+---+ | email | te...@example.com | | enabled | True | |id|c22..a6d | | name | test2| | tenantId | | +--+---+ $ keystone user-role-add --user c22..a6d --role 57d..d1f --tenant e61..7f6 $ keystone user-role-list --user c22..a6d --tenant e61..7f6 +--+--+--+---+ |id| name | user_id | tenant_id | +--+--+--+---+ | 57d..d1f | Member | c22..a6d | e61..7f6 | +--+--+--+---+ Is it expected behavior that two rolls are assigned? Thanks Leo Toyoda ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Swift][Keystone] Authentication problems with Swift and Keystone by Grizzly release
On 02/14/2013 09:38 AM, Heiko Krämer wrote:
Heyho Guys,
i'm testing Swift and Keystone (Grizzly).
!NOTE!
I'm posting only the importent stuff (output, responses, configs)
I've upgraded and migrate the database, the migration are working not
correct (kyestone-manage db_sync) because in the role table will create
a new column but with NULL values and this will break the auth (first
issue).
The next command of keystone they you will need is
keystone-manage pki_setup = done without errors but you will need to
change the rights of the generated files.
#
## Output / Log ###
My request to keystone are correct if i try to get a token with curl. I
get a token with all endpoints and other stuff.
token: {
expires: 2013-02-15T14:29:59Z,
id:
MIIL-wYJKoZIhvcNAQcCoIIL8DCCC+wCAQExCTAHBgUrDgMCGjCCCtgGCSqGSIb3DQEHAaCCCskEggrFeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMi0xNFQxNDoyOTo1OS44NDI0MjQiLCAiZXhwaXJlcyI6ICIyMDEzLTAyLTE1VDE0OjI5OjU5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiNTY5NzdiYjVhMDU1NDc2MWJmMGViOWQ2Y2E3NzBkNzUiLCAibmFtZSI6ICJ0ZXN0aW5nIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTAuMC4wLjE6ODc3NC92Mi81Njk3N2JiNWEwNTU0NzYxYmYwZWI5ZDZjYTc3MGQ3NSIsICJyZWdpb24iOiAidGVzdGluZyIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTAuMC4wLjE6ODc3NC92Mi81Njk3N2JiNWEwNTU0NzYxYmYwZWI5ZDZjYTc3MGQ3NSIsICJpZCI6ICJiOGQ3YTQzMWZjY2M0MWY2YTYzMzFjZTY3NjBlYjI1ZSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzg4LjE5OC42LjE1Mjo4Nzc0L3YyLzU2OTc3YmI1YTA1NTQ3NjFiZjBlYjlkNmNhNzcwZDc1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImNvbXB1dGUiLCAibmFtZSI6ICJub3ZhIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEwLjAuMC4xOjk2OTYiLCAicmVnaW9uIjogInRlc3RpbmciLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEwLjAuMC4xOjk2OTYiLCAiaWQiOiAiM2ZjNTcxNzUyMDA3NDY3OWI3MTlkM2VmNTlmZGViYzMiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMC4wLjAuMTo5Njk2In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogIm5ldHdvcmsiLCAibmFtZSI6ICJxdWFudHVtIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEwLjAuMC4xOjkyOTIvdjIiLCAicmVnaW9uIjogInRlc3RpbmciLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEwLjAuMC4xOjkyOTIvdjIiLCAiaWQiOiAiMWZlZTllNDQ1NjNjNDcwYzhkNjFmNjE5NDNjYmIxM2YiLCAicHVibGljVVJMIjogImh0dHA6Ly84OC4xOTguNi4xNTI6OTI5Mi92MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMC4wLjAuMTo4Nzc2L3YxLzU2OTc3YmI1YTA1NTQ3NjFiZjBlYjlkNmNhNzcwZDc1IiwgInJlZ2lvbiI6ICJ0ZXN0aW5nIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMC4wLjAuMTo4Nzc2L3YxLzU2OTc3YmI1YTA1NTQ3NjFiZjBlYjlkNmNhNzcwZDc1IiwgImlkIjogIjFmMjVlMDUwMjdmMTRmNGI5MDFmMWFmNjJiZTZhMzAwIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vODguMTk4LjYuMTUyOjg3NzYvdjEvNTY5NzdiYjVhMDU1NDc2MWJmMGViOWQ2Y2E3NzBkNzUifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAidm9sdW1lIiwgIm5hbWUiOiAiY2luZGVyIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEwLjAuMC4xOjg3NzMvc2VydmljZXMvQWRtaW4iLCAicmVnaW9uIjogInRlc3RpbmciLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEwLjAuMC4xOjg3NzMvc2VydmljZXMvQ2xvdWQiLCAiaWQiOiAiMWIyZTViZjkzNTI2NGI2ODljZmZkZWViMTk1ZDRjMWQiLCAicHVibGljVVJMIjogImh0dHA6Ly84OC4xOTguNi4xNTI6ODc3My9zZXJ2aWNlcy9DbG91ZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJlYzIiLCAibmFtZSI6ICJlYzIifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTAuMC4wLjE6ODA4MC92MSIsICJyZWdpb24iOiAidGVzdGluZyIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTAuMC4wLjE6ODA4MC92MS9BVVRIXzU2OTc3YmI1YTA1NTQ3NjFiZjBlYjlkNmNhNzcwZDc1IiwgImlkIjogIjI3YTEyYTBkMGI2ODQ2YjJhMDQzNjMwZmJlYzUwNmJhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vODguMTk4LjYuMTUyOjgwODAvdjEvQVVUSF81Njk3N2JiNWEwNTU0NzYxYmYwZWI5ZDZjYTc3MGQ3NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMC4wLjAuMTozNTM1Ny92Mi4wIiwgInJlZ2lvbiI6ICJ0ZXN0aW5nIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMC4wLjAuMTo1MDAwL3YyLjAiLCAiaWQiOiAiMDI2NWNmOTUyZDRmNGZhYWEyZjdlZGIzNGZlMGQxYTUiLCAicHVibGljVVJMIjogImh0dHA6Ly84OC4xOTguNi4xNTI6NTAwMC92Mi4wIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImlkZW50aXR5IiwgIm5hbWUiOiAia2V5c3RvbmUifV0sICJ1c2VyIjogeyJ1c2VybmFtZSI6ICJkbGVpZGlzY2giLCAicm9sZXNfbGlua3MiOiBbXSwgImlkIjogIjRjZDRhNzRlMTVlMTQ4MmY5ZmExNmY1MjRhZmQ4ZWJlIiwgInJvbGVzIjogW3sibmFtZSI6ICJhZG1pbiJ9LCB7Im5hbWUiOiAiS2V5c3RvbmVTZXJ2aWNlQWRtaW4ifSwgeyJuYW1lIjogIktleXN0b25lQWRtaW4ifV0sICJuYW1lIjogImRsZWlkaXNjaCJ9LCAibWV0YWRhdGEiOiB7ImlzX2FkbWluIjogMCwgInJvbGVzIjogWyI0NzA3YzJmNDg3ODg0MmM1ODUzMWJkN2U4MGU0ZDkzMCIsICI4ZjRmNGNhNmJmZGM0NWUwOTdjMTc1YmViNzUwNjU0ZCIsICI0Y2Y5OWU0ZGQ1YTg0NjZiOTlmZTRmZTIyNTAxYjg5NyJdfX19MYH-MIH8AgEBMFwwVzELMAkGA1UEBhMCVVMxDjAMBgNVBAgTBVVuc2V0MQ4wDAYDVQQHEwVVbnNldDEOMAwGA1UEChMFVW5zZXQxGDAWBgNVBAMTD3d3dy5leGFtcGxlLmNvbQIBATAHBgUrDgMCGjANBgkqhkiG9w0BAQEFAASBgD0cne0M65sCpOWFFSBqmA9rm14ecxkLtI9+fYJapMFIY3URuFxp8dWD2YPNeR7Jxw0lBcGLX418nG15G559pAqtk7-vKVV+X4tvJYRuHOt33fw37-b4hsX3ZEbdeif24j4eQEJKqDe2r7cLy8Iox2rCMjC2yKfZwjhIZdmNf7ZS,
issued_at: 2013-02-14T14:29:59.842424,
tenant: {
Re: [Openstack] keystone delegate Athentication
Actually, this isn't trusts, if I understand it correctly, but rather the REMOTE_USER patch that went in earlier. THe short version is that you run keystone in Apache, and set up strong authentication in Apache. REMOTE_USER is from the wsgi (Python CGI) contract. It is the variable set by Apache and sent to Keystone saying the username of the authenticated user. Will that work for you? On 02/06/2013 09:58 AM, Dolph Mathews wrote: Adam Young is working on introducing delegation in grizzly: https://blueprints.launchpad.net/keystone/+spec/trusts I'm sure he'd appreciate some help if you'd like to contribute! -Dolph On Wed, Feb 6, 2013 at 8:54 AM, Mballo Cherif cherif.mba...@gemalto.com mailto:cherif.mba...@gemalto.com wrote: Hi everybody ! I am wondering if it's possible to delegate keystone Authentication to an Authentication against a server (I have one Strong Authentication server) or an Identity Provider? If I make modification on keystoneclient code it may be possible? Any ideas? Please help me! Thanks ! Sherif! ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack] Keystone did not start - DevStack Installation
On 02/05/2013 08:00 AM, Antonio Tirri wrote: Hi all, actually i'm trying to install OpenStack through DevStack script. Unfortunately the installation is not successful because the keystone service doesn't start. This is the log of the script: 2013-02-05 13:19:05 + SCREEN_NAME=stack 2013-02-05 13:19:05 + SCREENRC=/opt/stack/devstack/stack-screenrc 2013-02-05 13:19:05 + [[ ! -e /opt/stack/devstack/stack-screenrc ]] 2013-02-05 13:19:05 + grep key /opt/stack/devstack/stack-screenrc 2013-02-05 13:19:05 ++ echo -ne '\015' 2013-02-05 13:19:05 + NL=$'\r' 2013-02-05 13:19:05 + echo 'screen -t key bash' 2013-02-05 13:19:05 + echo 'stuff cd /opt/stack/keystone /opt/stack/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug ' 2013-02-05 13:19:05 + screen -S stack -X screen -t key 2013-02-05 13:19:05 + sleep 1.5 2013-02-05 13:19:06 + [[ -n '' ]] 2013-02-05 13:19:06 + screen -S stack -p key -X stuff 'cd /opt/stack/keystone /opt/stack/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug || touch /opt/stack/status/stack/key.failure ' 2013-02-05 13:19:06 + echo 'Waiting for keystone to start...' 2013-02-05 13:19:06 Waiting for keystone to start... 2013-02-05 13:19:06 + timeout 60 sh -c 'while ! http_proxy= curl -s http://163.162.24.167:5000/v2.0/ /dev/null; do sleep 1; done' ]0;stack@openstack-controller: ~/devstackstack@openstack-controller:~/devstack$ 2013-02-05 13:20:06 + echo 'keystone did not start' 2013-02-05 13:20:06 keystone did not start 2013-02-05 13:20:06 + exit 1 2013-02-05 13:20:06 + clean 2013-02-05 13:20:06 + local r=1 2013-02-05 13:20:06 ++ jobs -p 2013-02-05 13:20:06 + kill 2013-02-05 13:20:06 + exit 1 How this problem can be solved? Antonio ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp screen -S stack -p key -X stuff 'cd /opt/stack/keystone /opt/stack/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug || touch /opt/stack/status/stack/key.failure Is the command that starts keystone. From the above, it not clear why it is failing. You should be able to run it interactively with: cd /opt/stack/keystone /opt/stack/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug And get more output. If it swallows all the output, look in /etc/keystone/logging.conf to see what it is set at. It might be sending it to a log file, such as /var/log/keystone ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack] Keystone did not start - DevStack Installation
You probably created /opt/stack/keystone/keystone.log as root at one point. Either delete it, or chown it to the stack user. On 02/05/2013 12:05 PM, Antonio Tirri wrote: Hi Adam, thanks for your answer. First of all, the full log of my script is here www.forumaltavilla.it/joomla/Documenti/log_devstack.txt http://www.forumaltavilla.it/joomla/Documenti/log_devstack.txt It seems that there are some problems in managing user permissions. Even if I included the stack user in /etc/sudoers adding the following line stack ALL=(ALL) NOPASSWD: ALL Moreover, i can't execute the script as root because, by default, it switch to the stack user. however, the output of the command /opt/stack/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug is stack@openstack-controller:~/keystone$ /opt/stack/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug Traceback (most recent call last): File /opt/stack/keystone/bin/keystone-all, line 82, in module config.setup_logging(CONF) File /opt/stack/keystone/keystone/config.py, line 41, in setup_logging logging.config.fileConfig(conf.log_config) File /usr/lib/python2.7/logging/config.py, line 78, in fileConfig handlers = _install_handlers(cp, formatters) File /usr/lib/python2.7/logging/config.py, line 156, in _install_handlers h = klass(*args) File /usr/lib/python2.7/logging/__init__.py, line 897, in __init__ StreamHandler.__init__(self, self._open()) File /usr/lib/python2.7/logging/__init__.py, line 916, in _open stream = open(self.baseFilename, self.mode) IOError: [Errno 13] Permission denied: '/opt/stack/keystone/keystone.log' while if i launch that command with sudo, it seems that it runs. Thank you, Antonio On 5 February 2013 17:04, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 02/05/2013 08:00 AM, Antonio Tirri wrote: Hi all, actually i'm trying to install OpenStack through DevStack script. Unfortunately the installation is not successful because the keystone service doesn't start. This is the log of the script: 2013-02-05 13:19:05 + SCREEN_NAME=stack 2013-02-05 13:19:05 + SCREENRC=/opt/stack/devstack/stack-screenrc 2013-02-05 13:19:05 + [[ ! -e /opt/stack/devstack/stack-screenrc ]] 2013-02-05 13:19:05 + grep key /opt/stack/devstack/stack-screenrc 2013-02-05 13:19:05 ++ echo -ne '\015' 2013-02-05 13:19:05 + NL=$'\r' 2013-02-05 13:19:05 + echo 'screen -t key bash' 2013-02-05 13:19:05 + echo 'stuff cd /opt/stack/keystone /opt/stack/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug ' 2013-02-05 13:19:05 + screen -S stack -X screen -t key 2013-02-05 13:19:05 + sleep 1.5 2013-02-05 13:19:06 + [[ -n '' ]] 2013-02-05 13:19:06 + screen -S stack -p key -X stuff 'cd /opt/stack/keystone /opt/stack/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug || touch /opt/stack/status/stack/key.failure ' 2013-02-05 13:19:06 + echo 'Waiting for keystone to start...' 2013-02-05 13:19:06 Waiting for keystone to start... 2013-02-05 13:19:06 + timeout 60 sh -c 'while ! http_proxy= curl -s http://163.162.24.167:5000/v2.0/ /dev/null; do sleep 1; done' ]0;stack@openstack-controller: ~/devstack stack@openstack-controller:~/devstack$ 2013-02-05 13:20:06 + echo 'keystone did not start' 2013-02-05 13:20:06 keystone did not start 2013-02-05 13:20:06 + exit 1 2013-02-05 13:20:06 + clean 2013-02-05 13:20:06 + local r=1 2013-02-05 13:20:06 ++ jobs -p 2013-02-05 13:20:06 + kill 2013-02-05 13:20:06 + exit 1 How this problem can be solved? Antonio ___ Mailing list:https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to :openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe :https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help :https://help.launchpad.net/ListHelp screen -S stack -p key -X stuff 'cd /opt/stack/keystone /opt/stack/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug || touch /opt/stack/status/stack/key.failure Is the command that starts keystone. From the above, it not clear why it is failing. You should be able to run it interactively with: cd /opt/stack/keystone /opt/stack/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug And get more output. If it swallows all the output, look in /etc/keystone/logging.conf to see what it is set
Re: [Openstack] [keystone] Why are we returing such a big payload in validate token?
On 01/31/2013 07:44 PM, Ali, Haneef wrote: Hi, As of now v3 validateToken response has tokens, service catalog, users, project , roles and domains. (i.e) Except for groups we are returning everything. We also discussed about the possibility of 100s of endpoints. ValidateToken is supposed to be a high frequency call . This is Validate token should not going be a high frequency call. The information is encapsulated inside the signed token for just that reason. I would agree with the sentiment, however, that we are cramming a lot of info into the token. TOkens should be scoped much, much more finely: by default one service or endpoint, and one tenant. The only thing that should require the full service catalog is the initial request of an unsigned token, and that should merely go back to the client. going to be a huge performance impact . What is the use case for such a big payload when compared with v2? If a service needs catalog , then the service can always ask for the catalog. Thanks Haneef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [keystone] Why are we returing such a big payload in validate token?
On 01/31/2013 10:57 PM, Vishvananda Ishaya wrote: On Jan 31, 2013, at 6:37 PM, Ali, Haneef haneef@hp.com mailto:haneef@hp.com wrote: Isn’t signed token an optional feature? If so validateToken is going to be a high frequency call. Also “Service Catalog” is a constant, the services can cache it. It doesn’t need to be part of validateToken. Service catalog is not a constant. That said the only time it is used is when a service needs to proxy a call to another service using the same token. If we had a reasonable way to make requests on behalf of other users we don't really need it as the service could just keep its own catalog and make requests on behalf of the requesting user. I'm working on it. It is called trusts and there is a WIP posted here: https://review.openstack.org/#/c/20289/ Blueprint is here: https://blueprints.launchpad.net/keystone/+spec/trusts Vish Thanks Haneef *From:*openstack-bounces+haneef.ali=hp@lists.launchpad.net mailto:openstack-bounces+haneef.ali=hp@lists.launchpad.net [mailto:openstack-bounces+haneef.ali=hp@lists.launchpad.net mailto:bounces+haneef.ali=hp@lists.launchpad.net]*On Behalf Of*Adam Young *Sent:*Thursday, January 31, 2013 6:25 PM *To:*openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:*Re: [Openstack] [keystone] Why are we returing such a big payload in validate token? On 01/31/2013 07:44 PM, Ali, Haneef wrote: Hi, As of now v3 validateToken response has “tokens, service catalog, users, project , roles and domains. (i.e) Except for groups we are returning everything. We also discussed about the possibility of 100s of endpoints. ValidateToken is supposed to be a high frequency call .This is Validate token should not going be a high frequency call. The information is encapsulated inside the signed token for just that reason. I would agree with the sentiment, however, that we are cramming a lot of info into the token. TOkens should be scoped much, much more finely: by default one service or endpoint, and one tenant. The only thing that should require the full service catalog is the initial request of an unsigned token, and that should merely go back to the client. going to be a huge performance impact . What is the use case for such a big payload when compared with v2? If a service needs catalog , then the service can always ask for the catalog. Thanks Haneef ___ Mailing list:https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to :openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe :https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help :https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Poll: H release cycle naming
On 01/24/2013 10:13 AM, Thierry Carrez wrote: It's that time of the year again... As is the tradition, we'd like the help of the community to help select the code name of the next release cycle of OpenStack. The Technical Committee narrowed the list of valid candidates to 4 names, and we'd like you to pick the one you prefer. So what will it be ? Hood, Havana, Harbor or Hatfield ? Please head to: https://launchpad.net/~openstack/+poll/h-release-naming to let us know what you prefer ! Poll ends Tuesday, January 29, 20:00 UTC. Note that you need to be a member of the ~openstack group in Launchpad to be able to vote, but all people on this list already are. I think we have overlooked the most obvious answer: Hillsboro: http://en.wikipedia.org/wiki/Hillsboro,_Oregon This is the Portland tech hub. Most of the Portland people at the conference probably work in Hillsboro. I'm not trying to ramrod it through as the solution, but it should at least be one of the options. Why was it ruled out? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Glance image upload Keystone error
On 01/23/2013 06:34 AM, Trinath Somanchi wrote:
Hi Stackers-
I have installed glance and Keystone and configured them.
Not sure how you installed, but you need to make sure the PKI
provisioning is done. You can do it by hand with the keystone_manage
command. Make sure you run it as the user that Keystone is going to run
as, as it creates the certificates and Keystone (ajnd only Keystone)
needs to be able to access those.
But When I upload a test image with glance, I got this error in
keystone logs
(sqlalchemy.engine.base.Engine): 2013-01-23 17:04:57,904 INFO
('106298a47e5a4d129c7b8571e188c51e', 1)
(keystone.common.cms): 2013-01-23 17:04:57,990 ERROR Signing error:
Error opening signer certificate /etc/keystone/ssl/certs/signing_cert.pem
140702974211744:error:02001002:system library:fopen:No such file or
directory:bss_file.c:398:fopen('/etc/keystone/ssl/certs/signing_cert.pem','r')
140702974211744:error:20074002:BIO routines:FILE_CTRL:system
lib:bss_file.c:400:
unable to load certificate
(root): 2013-01-23 17:04:57,991 ERROR Command 'openssl' returned
non-zero exit status 3
Traceback (most recent call last):
File
/usr/local/lib/python2.7/dist-packages/keystone-2013.1-py2.7.egg/keystone/common/wsgi.py,
line 215, in __call__
result = method(context, **params)
File
/usr/local/lib/python2.7/dist-packages/keystone-2013.1-py2.7.egg/keystone/token/controllers.py,
line 118, in authenticate
config.CONF.signing.keyfile)
File
/usr/local/lib/python2.7/dist-packages/keystone-2013.1-py2.7.egg/keystone/common/cms.py,
line 140, in cms_sign_token
output = cms_sign_text(text, signing_cert_file_name,
signing_key_file_name)
File
/usr/local/lib/python2.7/dist-packages/keystone-2013.1-py2.7.egg/keystone/common/cms.py,
line 135, in cms_sign_text
raise subprocess.CalledProcessError(retcode, openssl)
CalledProcessError: Command 'openssl' returned non-zero exit status 3
Kindly help me resolve the issue
--
Regards,
--
Trinath Somanchi,
+91 9866 235 130
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] keystone + LDAP username only with numbers
On 01/18/2013 08:18 AM, Marcelo Mariano Miziara wrote: Hello to everyone. First of all sorry for my bad english. Second, i'm implementing openstack here in my company, and we pretend to use it with ldap integration. I detected a problem when the username is only numbers (in our case we use our ID number to log in): PLease enter it as a bug. It looks like the HTML to Python parsing is breaking down. TypeError at /nova/ sequence item 1: expected string or Unicode, int found Request Method: GET Request URL: 100.10.10.51/horizon/nova/ http://100.10.10.51/horizon/nova/ Django Version: 1.4.1 Exception Type: TypeError Exception Value: sequence item 1: expected string or Unicode, int found Exception Location: /usr/lib/python2.7/dist-packages/novaclient/client.py in authenticate, line 316 Python Executable: /usr/bin/python Python Version: 2.7.3 Python Path: ['/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../..', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/share/openstack-dashboard/', '/usr/share/openstack-dashboard/openstack_dashboard'] Server time:Qui, 17 Jan 2013 12:37:11 + Then I created another user with letters in the user name and this error doesn't appear...but then I got another type of error that I'll discuss later...someone experienced this error, or am I doing something wrong? Thanks in advance, Marcelo M. Miziara Serviço Federal de Processamento de Dados - SERPRO CDEBW/CDTEC/SUPCD 55 (41) 3593 8277 marcelo.mizi...@serpro.gov.br http://mailto:marcelo.mizi...@serpro.gov.br - Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Logging Keystone x Remote Syslog
On 01/11/2013 07:31 AM, Alex Vitola wrote:
It's possible send to logs to remote server?
Logging is using the standard Python logging module:
In keystone/common/logging:
import logging
import logging.config
You should be able to configure this to use SysLog:
http://docs.python.org/2/library/logging.handlers.html#logging.handlers.SysLogHandler
Or an HTTP logger (Not necessarily recommended without reviewing the
security implications)
http://docs.python.org/2/library/logging.handlers.html#logging.handlers.HTTPHandler
Using AMQP might make sense IAW this post.
http://notes.variogr.am/post/143623387/broadcasting-your-logs-with-rabbitmq-and-python
Currently it is configured to send to the local file
I believe it is in the file below
/etc/keystone/logging.conf
[logger_root]
level=DEBUG
handlers=file
[handler_production]
class=handlers.SysLogHandler
level=ERROR
formatter=normal_with_name
args=(('localhost', handlers.SYSLOG_UDP_PORT), handlers.SysLogHandler.LOG_USER)
[handler_file]
class=FileHandler
level=DEBUG
formatter=normal_with_name
args=('/var/log/keystone/keystone.log', 'a')
att
Alex Vitola
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [keystone] IBM DB2 configuration
What I think we need is a simple way to run our current body of unit
tests, to include the sql Migration tests, against a Live database,
kindof the same way as I have et up for the live LDAP test.
The steps:
create a file under keystone/tests that doesn't trigger the nameing
scheme that matches for unit tests. Since I use _ldap_livetest.py for
LDAP, I would recommend _db_livetests.py.
That should then import test_backend_sql and test_sql upgrade. They
would pull in a custom config file that is .gitignored but that has the
DB connection info for DB2 etc. We could post sample ones for
smokestack etc to pull in for integration testing.
A user then could run against those test with ./run_tests.sh -x
_db_livetests
On 12/20/2012 11:55 AM, Dolph Mathews wrote:
(raising to the mailing list)
Which DB2 driver are you using? I was referring to:
http://code.google.com/p/ibm-db/wiki/README
... which shows an example connection string for sqlalchemy as:
db2 =
sqlalchemy.create_engine('ibm_db_sa://db2inst1:sec...@host.name.com:5/pydev
http://db2inst1:sec...@host.name.com:5/pydev')
-Dolph
On Thu, Dec 20, 2012 at 4:05 AM, Kevin-Yang
benbenzhufore...@gmail.com mailto:benbenzhufore...@gmail.com wrote:
Dolph,
Really appreciated for your response.
My VM configuration is:
OS -
Red Hat Enterprise Linux Server release 6.3 (Santiago)
DB2 -
Informational tokens are DB2 v9.7.0.0, s090521,
LINUXAMD6497, and Fix
Pack 0
ibm_db -
http://pypi.python.org/packages/source/i/ibm_db/ibm_db-2.0.0.tar.gz#md5=709c576c0ec2379ca15049f5c861beb1
ibm_db_sa -
When i changed from ibmdb - ibm_db_sa, I came with a
different error - Could not determine dialect for 'ibm_db_sa'.
##
Traceback (most recent call last):
File /usr/local/bin/keystone-manage, line 5, in module
pkg_resources.run_script('keystone==2012.2', 'keystone-manage')
File build/bdist.linux-x86_64/egg/pkg_resources.py, line 499,
in run_script
File build/bdist.linux-x86_64/egg/pkg_resources.py, line 1239,
in run_script
File
/usr/local/lib/python2.7/site-packages/keystone-2012.2-py2.7.egg/EGG-INFO/scripts/keystone-manage,
line 28, in module
cli.main(argv=sys.argv, config_files=config_files)
File
/usr/local/lib/python2.7/site-packages/keystone-2012.2-py2.7.egg/keystone/cli.py,
line 164, in main
return run(cmd, (args[:1] + args[2:]))
File
/usr/local/lib/python2.7/site-packages/keystone-2012.2-py2.7.egg/keystone/cli.py,
line 147, in run
return CMDS[cmd](argv=args).run()
File
/usr/local/lib/python2.7/site-packages/keystone-2012.2-py2.7.egg/keystone/cli.py,
line 35, in run
return self.main()
File
/usr/local/lib/python2.7/site-packages/keystone-2012.2-py2.7.egg/keystone/cli.py,
line 56, in main
driver.db_sync()
File
/usr/local/lib/python2.7/site-packages/keystone-2012.2-py2.7.egg/keystone/identity/backends/sql.py,
line 136, in db_sync
migration.db_sync()
File
/usr/local/lib/python2.7/site-packages/keystone-2012.2-py2.7.egg/keystone/common/sql/migration.py,
line 49, in db_sync
current_version = db_version()
File
/usr/local/lib/python2.7/site-packages/keystone-2012.2-py2.7.egg/keystone/common/sql/migration.py,
line 61, in db_version
return versioning_api.db_version(CONF.sql.connection, repo_path)
File string, line 2, in db_version
File
/usr/local/lib/python2.7/site-packages/migrate/versioning/util/__init__.py,
line 155, in with_engine
engine = construct_engine(url, **kw)
File
/usr/local/lib/python2.7/site-packages/migrate/versioning/util/__init__.py,
line 140, in construct_engine
return create_engine(engine, **kwargs)
File
build/bdist.linux-x86_64/egg/sqlalchemy/engine/__init__.py, line
338, in create_engine
File
build/bdist.linux-x86_64/egg/sqlalchemy/engine/strategies.py,
line 50, in create
File build/bdist.linux-x86_64/egg/sqlalchemy/engine/url.py,
line 123, in get_dialect
sqlalchemy.exc.ArgumentError: Could not determine dialect for
'ibm_db_sa'.
##
--
You received this bug notification because you are a bug assignee.
https://bugs.launchpad.net/bugs/987121
Title:
strict constraint for database table creation
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
OpenStack claims that any type of database supporting SQLAlchemy
can be taken as the database for OpenStack use.
In some databases, if a column is defined as UNIQUE, it must be
specified NOT NULL at the same time, e.g. IBM DB2, which is
SQLAlchemy supporting. I am
Re: [Openstack] LDAP + Keystone,, Error after authentication..
On 12/11/2012 04:15 AM, yasith tharindu wrote:
Hi Team;
I was trying to configure ldap + keystone but it seems not working. I
feel like authentication is successful but horizon return me python
error. Im unable to trace as its does not give any detail. Following
I have attached the error, ldap dump, keystone config. I would really
appreciate if you can note me down any configuration error.
My nova version is:: 2012.2 (2012.2-LOCALBRANCH:LOCALREVISION)
If its wrong password it returns, Invalid user name or password.
That sounds right
When type correct credentials but user not in the any of Group it
return You are not authorized for any projects.
Yes
When type correct credentials and the user is a member of a group (eg:
cn=demo,ou=Groups,dc=example,dc=com), It returns following error.
It looks like some poor error handling in Horizon, to start. The Key
error means token.tenant['name'] is not defined in the object. Which
probably means that it doesn't have a real token or something. I'm
guessing that token.tenant is None at this point.
Does it work from the Keystone CLI? Isolate your problem, is it
Keystone, or is it Horizon.
### The error
KeyError at /auth/login/
'name'
Request Method:POST
Request URL:https://192.168.25.240/auth/login/
Django Version:1.4.1
Exception Type:KeyError
Exception Value:
'name'
Exception
Location:/usr/lib/python2.7/dist-packages/openstack_auth/user.py in
create_user_from_token, line 25
Python Executable:/usr/bin/python
Python Version:2.7.3
Python Path:
['/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../..',
'/usr/share/openstack-dashboard/openstack_dashboard',
'/usr/lib/python2.7',
'/usr/lib/python2.7/plat-linux2',
'/usr/lib/python2.7/lib-tk',
'/usr/lib/python2.7/lib-old',
'/usr/lib/python2.7/lib-dynload',
'/usr/local/lib/python2.7/dist-packages',
'/usr/lib/python2.7/dist-packages',
'/usr/lib/pymodules/python2.7',
'/usr/share/openstack-dashboard/']
Environment:
Request Method: POST
Request URL: https://192.168.25.240/auth/login/
Django Version: 1.4.1
Python Version: 2.7.3
Installed Applications:
('openstack_dashboard',
'django.contrib.contenttypes',
'django.contrib.auth',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'django.contrib.humanize',
'compressor',
'horizon',
'horizon.dashboards.nova',
'horizon.dashboards.syspanel',
'horizon.dashboards.settings',
'openstack_auth')
Installed Middleware:
('django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'horizon.middleware.HorizonMiddleware',
'django.middleware.doc.XViewMiddleware',
'django.middleware.locale.LocaleMiddleware')
Traceback:
File /usr/lib/python2.7/dist-packages/django/core/handlers/base.py
in get_response
111. response = callback(request,
*callback_args, **callback_kwargs)
File
/usr/lib/python2.7/dist-packages/django/views/decorators/debug.py in
sensitive_post_parameters_wrapper
69. return view(request, *args, **kwargs)
File /usr/lib/python2.7/dist-packages/django/utils/decorators.py in
_wrapped_view
91. response = view_func(request, *args, **kwargs)
File
/usr/lib/python2.7/dist-packages/django/views/decorators/cache.py in
_wrapped_view_func
89. response = view_func(request, *args, **kwargs)
File /usr/lib/python2.7/dist-packages/openstack_auth/views.py in login
50.extra_context=extra_context)
File
/usr/lib/python2.7/dist-packages/django/views/decorators/debug.py in
sensitive_post_parameters_wrapper
69. return view(request, *args, **kwargs)
File /usr/lib/python2.7/dist-packages/django/utils/decorators.py in
_wrapped_view
91. response = view_func(request, *args, **kwargs)
File
/usr/lib/python2.7/dist-packages/django/views/decorators/cache.py in
_wrapped_view_func
89. response = view_func(request, *args, **kwargs)
File /usr/lib/python2.7/dist-packages/django/contrib/auth/views.py
in login
36. if form.is_valid():
File /usr/lib/python2.7/dist-packages/django/forms/forms.py in is_valid
124. return self.is_bound and not bool(self.errors)
File /usr/lib/python2.7/dist-packages/django/forms/forms.py in
_get_errors
115. self.full_clean()
File /usr/lib/python2.7/dist-packages/django/forms/forms.py in
full_clean
271. self._clean_form()
File /usr/lib/python2.7/dist-packages/django/forms/forms.py in
_clean_form
299. self.cleaned_data = self.clean()
File
/usr/lib/python2.7/dist-packages/django/views/decorators/debug.py in
sensitive_variables_wrapper
34. return func(*args, **kwargs)
File
Re: [Openstack] S3 Token
On 12/11/2012 01:40 AM, Chmouel Boudjnah wrote: On Mon, Dec 10, 2012 at 4:17 AM, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: As a Keystone core developer, I have to say that I don't see it as a huge burden to keep it in place. We want to maintain API backward compatability, and removing it would break that. We should deprecate it and get people to sign off on a complete removal before taking it out of keystone. Thanks for the feedback guy, if that's not much of troubles to keep it in keystone we can leave it there. Cheers, Chmouel. That being said, it probably could use better unit test coverage. Feel free to contribute code fragments toward that. http://admiyo.fedorapeople.org/openstack/covhtml/keystone_contrib_ec2_core.html ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] S3 Token
On 12/11/2012 11:11 AM, Adam Young wrote: On 12/11/2012 01:40 AM, Chmouel Boudjnah wrote: On Mon, Dec 10, 2012 at 4:17 AM, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: As a Keystone core developer, I have to say that I don't see it as a huge burden to keep it in place. We want to maintain API backward compatability, and removing it would break that. We should deprecate it and get people to sign off on a complete removal before taking it out of keystone. Thanks for the feedback guy, if that's not much of troubles to keep it in keystone we can leave it there. Cheers, Chmouel. That being said, it probably could use better unit test coverage. Feel free to contribute code fragments toward that. http://admiyo.fedorapeople.org/openstack/covhtml/keystone_contrib_ec2_core.html Make that: http://admiyo.fedorapeople.org/openstack/covhtml/keystone_contrib_s3_core.html ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] S3 Token
On 12/08/2012 08:22 AM, Chmouel Boudjnah wrote: Hi, I'm working on removing the swift+keystone middleware from keystone, we have moved it already as keystoneauth since last OpenStack release into the main swift repository. One thing that left in keystone is the s3_token middleware. Since in OpenStack/Swift we are not supporting third party API this could not be moved there. The options : 1) Keep s3token in keystone As a Keystone core developer, I have to say that I don't see it as a huge burden to keep it in place. We want to maintain API backward compatability, and removing it would break that. We should deprecate it and get people to sign off on a complete removal before taking it out of keystone. 2) Remove s3token from keystone and try to convince the swift3 maintainer to integrate it. 3) Try to figure out if there is actually people using this and if not just nuke it. 4) move s3token to its own repo on github somewhere. i personally would vote for number three, I don't think much people using this (i.e: swift+keystone+s3) or at least I didn't hear many feedback about the middleware. Chmouel. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [devstack] keystone failed to get-token
On 12/03/2012 05:57 AM, benzwt benzwt wrote: I gitted the devstack with version 6540d8910194bb523601ffdd06cdf4c2126e3fd0 I ran it but it returned glance: error: argument --os-auth-token: expected one argument after tracing the code I found that it was due to line 1662 in stack.sh as the keystone failed to get-token, the value of --os-auth-token is empty You have to find out why Keystone failed.I usually do something like: . openrc keystone token-get And look at the log messages from the Keystone. If you look in the screens (run screen -x) , Keystone is usually screen 3 (ctrl-a 3). ctrl-d to detach afterwards. can somebody helps me ? Best regards, reynolds ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Keystone] LDAP Backend for Catalog
Right now, only the Identity submodule has an LDAP backend. This is user, tenants, and roles. Is there any requirement for the Catalog to have an LDAP back end? Endpoints and Services do not necessarily map directly to the LDAP view of machines, but could probably be made to fit. I will start investigating the feasibility if there is any demand for it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Configuring keystone with ldap
On 11/29/2012 11:47 PM, yasith tharindu wrote: I was trying to enable enable keystone with ldap. but always return me with a this error. *Error: *Invalid user name or password. and no log trace can be found. All I can say is it looks correct enough, but you obviosuly have a problem in your LDAP to Keystone configuration. Authentication to LDAP is done using a simple bind, based on what you have for the user_tree_dn. Make sure you can do that same bind from a command line LDAP tool. my keystone config as following [ldap] url = ldap://ldap.example.org http://ldap.example.org tree_dn = dc=ldap,dc=example,dc=org user_tree_dn = ou=user,dc=ldap,dc=example,dc=org tenant_tree_dn = ou=group,dc=ldap,dc=example,dc=org user = uid=ldapuser,ou=user,dc=ldap,dc=example,dc=org password = password suffix = dc=ldap,dc=example,dc=org user_name_attribute = uid [identity] driver = keystone.identity.backends.ldap.Identity I have few questions. what am i missing here. what is the purpose of role_tree_dn config does that necessarily needed. can we enable logs. there are many groups under tenant_tree_dn do I have to setup which group to look at. Is there a sample ldap ldif file and keystone config to loook at? Thanks -- Thanks.. Regards... Blog: http://www.yasith.info Twitter : http://twitter.com/yasithnd LinkedIn : http://www.linkedin.com/in/yasithnd GPG Key ID : *57CEE66E* ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
On 11/10/2012 10:58 AM, David Chadwick wrote: I agree with the vast majority of what Jorge says below. The idea I would like to bounce around is that of the unscoped token. What does it mean conceptually? What is its purpose? Why do we need it? Why should a user be given an unscoped token to exchange at a later time for a scoped token? My view is as follows: i) a user is authenticated and identified, and from this, keystone can see that the user has access to a number of different tenants and services. Keystone creates an unscoped token to encapsulate this. Note that the unscoped token is scoped to the services/tenants available to this user, and consequently it is different for each identified user. Thus it does have some scope i.e. it cannot be swapped for access to any service by any tenant. ii) the user must choose which service/tenant he wishes to activate. This is in line with the principle of least privileges. iii) the user informs keystone which service(s) and tenant(s) he wishes to access and Keystone swaps the unscoped token for one that is scoped to the choice of the user. The issue then becomes, what is the allowable scope of a scoped token? Jorge below believes it should cover multiple services/endpoints/tenants. So one must then ask, what is the difference between the most widely scoped scoped-token and the unscoped token? Surely they will have the same scope won't they? In which case there is no need for both concepts. let's compare with Kerberos: In my view an unscoped token is comparaable with a ticket granting ticket: it cannot be used with any service other than the KDC, and it can only be used to get service tickets. A service ticket can only be used with a specific service. If that service gets compromised, any tickets it has are useless for access to other resources. If an unscoped token can be used against a wide array of services, we have just provided a path for an elevation of privileges attack. If I know that a service consumes tokens which can be used on a wide number of other services, I can target my attacks against that service in order to get access everywhere. If we are going to provide this functionality, it should be turned off by default. Comments please regards David On 23/10/2012 06:25, Jorge Williams wrote: Here's my view: On making the default token a configuration option: Like the idea. Disabling the option by default. That's fine too. On scoping a token to a specific endpoint: That's fine, though I believe that that's in the API today. Currently, the way that we scope tokens to endpoints is by validating against the service catalog. I'm not sure if the default middleware checks for this yet, but the Repose middleware does. If you try to use a token in an endpoint that's not in the service catalog the request fails -- well, if the check is turned on. Obviously, I'd like the idea of scoping a single token to multiple tenants / endpoints. I don't like the idea of calling tokens sloppy tokens -- it's confusing. All you have to say is that a token has a scope -- and the scope of the token is the set of resources that the token can provide access to. You can limit the scope of a token to a tenant, to a endpoint, to a set of endpoints or tenants etc -- what limits you place on the scope of an individual token should be up to the operator. Keep in mind that as we start digging into delegation and fine grained authorization (after Grizzly, I'm sure), we'll end up with tokens that have a scope of a subset of resources in a single or multiple tenants. So calling them sloppy now is just confusing. Simply stating that a token has a scope (as I've defined above) should suffice. This is part of the reason why I've never liked the term unscoped token, because an unscoped token does have a scope. It just so happens that the scope of that token is the resource that provides a list of available tenants. -jOrGe W. On Oct 22, 2012, at 9:57 PM, Adam Young wrote: Are you guys +1 ing the original Idea, my suggestion to make it optional, the fact that I think we should call these sloppy tokens? On 10/22/2012 03:40 PM, Jorge Williams wrote: +1 here too. At the end of the day, we'd like the identity API to be flexible enough to allow the token to be scoped in a manner that the deployer sees fit. What the keystone implementation does by default is a different matter -- and disabling multiple tenant scope by default would be fine by me. -jOrGe W. On Oct 21, 2012, at 11:10 AM, Joe Savak wrote: +1. ;) So the issue is that the v2 API contract allows a token to be scoped to multiple tenants. For v3, I'd like to have the same flexibility. I don't see security issues, as if a token were to be sniffed you can change the password of the account using it and use those creds to scope tokens to any tenant you wish. Scope should always be kept as limited as possible. Personally, I don't feel like limiting the tenant
Re: [Openstack] [keystone] Domain Name Spaces
On 10/30/2012 06:43 AM, David Chadwick wrote: On 27/10/2012 00:17, Henry Nash wrote: So to pick up on a couple of the areas of contention: a) Roles. I agree that role names must stay globally unique. One way of thinking about this is that it is not actually keystone that is creating the role name space it is the other services (Nova etc.) by specifying roles in their policy files. Until those services support domain specific segmentation, then role names stay global. I addressed this issue in my Federation design doc (in Appendix 2). Here is the text to save you having to look it up (note that an attribute is simply a generalisation of role and is needed in the broader authz context. Roles are too limiting.) Attributes may be globally defined, e.g. visa attributes, or locally defined e.g. member of club X. Globally defined attributes are often specified in international standards and may be used in several different domains and federations. Their syntax and semantics are fixed, regardless of which Attribute Authority (AA) issues them. Local attributes are defined by their issuing attribute authority and usually are only valid in the domain or federation in which the AA is a member. For locally identifiable attributes the attribute authority (issuer) must be globally identifiable (in the federation). The attribute then becomes globally identifiable through hierarchical naming (AA.attribute). Whilst in a non-federated world the service provider (e.g. Swift) can unilaterally define the roles it wants, in a federated world the attributes have to be mutually agreed between the issuer (AA) and the consumer (e.g. Swift). To address this issue I proposed a role mapping (attribute mapping) service that is run by Keystone, and it maps between the role/attribute required by the service, and the actual attribute issued by the AA. For example, say Swift requires the role of Admin to be assigned to addministrators, whereas company X, the attribute authority, assigns the LDAP attribute title=OpenStack Cloud Administrator to its admin staff. Keystone will use its attribute mapping service to map between these values. b) Will multi-domains make it more complicated in terms of authorisation - e.g. will the users have to input a Domain Name into Horizon the whole time? The first thing I would say is that if the cloud administrator has create multiple domains, then the keystone API should indeed require the domain specification. Again, in our federated design document we have the concept of a realm, which is similar to that of a domain, only in the federated case it indicates the place where the user will be authenticated and obtain (some of) his authz attributes from. The user can indicate the realm/domain name on the command line, but if it is missing, Keystone replies with a list of domains that it knows about and asks the user to choose one from the list. I think this is the Key point. Domain/Realm means who accepts responsibility for the user. And that responsibility needs to be unambiguous. However, that should not mean it should be laborious for a Horizon user. In the case where a Cloud Provider has created domains to encapsulate each of their customers - then if they want to let those customer use horizon as the UI, then I would think they want to be able to give each customer a unique URL which will point to a Horizon that knows which domain to go to. this is certainly a possibility. regards David Maybe the url contains the Domain Name or ID in the path, and Horizon pulls this out of its own url (assuming that's possible) and hence the user is never given an option to chose a domain. A Cloud Admin would use a non domain qualified url to get to Horizon (basically as it is now) and hence be able to see the different domains. Likewise, in the case of where the Cloud Provider has not chosen to create any individual domains (and is just running the cloud in the default domain), then the non domain qualified url would be used to a Horizon that only showed one, default domain and hence no choice is required. Henry On 26 Oct 2012, at 17:31, heckj wrote: Bringing conversation for domains in Keystone to the broader mailing lists. On Oct 26, 2012, at 5:18 AM, Dolph Mathews dolph.math...@gmail.com mailto:dolph.math...@gmail.com wrote: I think this discussion would be great for both mailing lists. -Dolph On Fri, Oct 26, 2012 at 5:18 AM, Henry Nash henry.n...@mac.com mailto:henry.n...@mac.com wrote: Hi Not sure where best to have this discussion - here, as a comment to the v3api doc, or elsewhere - appreciate some guidance and will transfer this to the right place At the Summit we started a discussion on whether things like user name, tenant name etc. should be globally unique or unique within a domain. I'd like to widen that discussion to try and a) agree a direction, b) agree some changes to our current spec.
Re: [Openstack] [keystone] Domain Name Spaces
On 10/26/2012 07:17 PM, Henry Nash wrote: So to pick up on a couple of the areas of contention: a) Roles. I agree that role names must stay globally unique. One way of thinking about this is that it is not actually keystone that is creating the role name space it is the other services (Nova etc.) by specifying roles in their policy files. Until those services support domain specific segmentation, then role names stay global. b) Will multi-domains make it more complicated in terms of authorisation - e.g. will the users have to input a Domain Name into Horizon the whole time? The first thing I would say is that if the cloud administrator has create multiple domains, then the keystone API should indeed require the domain specification. However, that should not mean it should be laborious for a Horizon user. In the case where a Cloud Provider has created domains to encapsulate each of their customers - then if they want to let those customer use horizon as the UI, then I would think they want to be able to give each customer a unique URL which will point to a Horizon that knows which domain to go to. Yes, I think that this is the solution. It will involve HTTPD virtual hosts, and horizon can then get an additional config parameter keystone_domain as part of the wsgi config. Maybe the url contains the Domain Name or ID in the path, and Horizon pulls this out of its own url (assuming that's possible) and hence the user is never given an option to chose a domain. A Cloud Admin would use a non domain qualified url to get to Horizon (basically as it is now) and hence be able to see the different domains. Likewise, in the case of where the Cloud Provider has not chosen to create any individual domains (and is just running the cloud in the default domain), then the non domain qualified url would be used to a Horizon that only showed one, default domain and hence no choice is required. Henry On 26 Oct 2012, at 17:31, heckj wrote: Bringing conversation for domains in Keystone to the broader mailing lists. On Oct 26, 2012, at 5:18 AM, Dolph Mathews dolph.math...@gmail.com mailto:dolph.math...@gmail.com wrote: I think this discussion would be great for both mailing lists. -Dolph On Fri, Oct 26, 2012 at 5:18 AM, Henry Nash henry.n...@mac.com mailto:henry.n...@mac.com wrote: Hi Not sure where best to have this discussion - here, as a comment to the v3api doc, or elsewhere - appreciate some guidance and will transfer this to the right place At the Summit we started a discussion on whether things like user name, tenant name etc. should be globally unique or unique within a domain. I'd like to widen that discussion to try and a) agree a direction, b) agree some changes to our current spec. Here's my view as an opening gambit: - When a Keystone instance is first started, there is only one, default, Domain. The Cloud Provider does not need to create any new domains, all projects can exist in this default domain, as will the users etc. There is one, global, name space. Clients using the v2 API will work just fine. +1 Very much what we were thinking for the initial implemenation and rollout to make it backwards compatible with the V2 (non-domain) core API - If the Cloud Provider wants to provide their customers with regions they can administer themselves and be self-contained, then they create a Domain for each customer. It should be possible for users/roles to be scoped to a Domain so that (effectively) administrative duties can be delegated to some users in that Domain. So far so good - all this can be done with the v3 API. Not clear on if you're referring to endpoint regions, or just describing domain isolation? I believe you're describing the key use cases behind the domains mechanism to begin with - user and project partitioning to allow for administration of those to be clearly owned and managed appropriately. - We still have work to do to make sure items in other OS projects that reference tenants (e.g. Images) can take a Domain or Project ID, but we'll get to that soon enough Everything will continue to work with projects, but once middleware starts providing a DOMAIN_ID and DOMAIN_NAME to the underlying service, it'll be up to them to take advantage of it. Images per domain is an excellent example use case. - However, Cloud Providers want to start enabling enterprise customers to run more and more of the workloads in OpenStack clouds - over and above, the smaller sized companies that are doing this today. For this to work, the encapsulation of a Domain need, I think, to be able to be stricter - and this is where the name space comes into play. I think we need to allow for a Domain to have its own namespace (i.e. users, roles, projects etc.) as an option. I see this as a first step to
Re: [Openstack-qa-team] Changes with ids/uuids?
On 10/25/2012 12:49 PM, Daryl Walleck wrote: You hit the nail on the head. I got a bit jumpy and ended up filing a bug to Keystone and got that same response, which explains the token. I suppose the flavor id change was intentional as well, but I would've expected it to be a uuid instead of a very large int. You now own the bug report that I will point people at when this issue comes up in the future. Hopefully they will search before filing From: openstack-qa-team-bounces+daryl.walleck=rackspace@lists.launchpad.net [openstack-qa-team-bounces+daryl.walleck=rackspace@lists.launchpad.net] on behalf of Jay Pipes [jaypi...@gmail.com] Sent: Thursday, October 25, 2012 11:38 AM To: openstack-qa-team@lists.launchpad.net; ayo...@redhat.com Subject: Re: [Openstack-qa-team] Changes with ids/uuids? On 10/25/2012 01:13 AM, Daryl Walleck wrote: While spinning up a new devstack tonight I noticed some very odd behavior. Keystone is suddenly giving me back a 3000+ character auth token, and the ids for flavors I'm creating are extremely large ints (uuids I could see, but not this). Does anyone have any insight into if either of these changes were intentional? I believe you have run into the change that Keystone recently made that switched to using PKI by default for token authentication in the services. Adam, can you verify this is the case, and a remedy for Daryl? Thanks much! -jay -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
Re: [Openstack-qa-team] Changes with ids/uuids?
On 10/25/2012 01:41 PM, David Kranz wrote: Going forward, such changes should really be announced to the dev list. There is no reason people need to be left to trip over them. Good point. It was announced that it was coming for a while, and it should be a slide in replacement. But we should have specified the date. -David On 10/25/2012 1:13 PM, Adam Young wrote: On 10/25/2012 12:49 PM, Daryl Walleck wrote: You hit the nail on the head. I got a bit jumpy and ended up filing a bug to Keystone and got that same response, which explains the token. I suppose the flavor id change was intentional as well, but I would've expected it to be a uuid instead of a very large int. You now own the bug report that I will point people at when this issue comes up in the future. Hopefully they will search before filing From: openstack-qa-team-bounces+daryl.walleck=rackspace@lists.launchpad.net [openstack-qa-team-bounces+daryl.walleck=rackspace@lists.launchpad.net] on behalf of Jay Pipes [jaypi...@gmail.com] Sent: Thursday, October 25, 2012 11:38 AM To: openstack-qa-team@lists.launchpad.net; ayo...@redhat.com Subject: Re: [Openstack-qa-team] Changes with ids/uuids? On 10/25/2012 01:13 AM, Daryl Walleck wrote: While spinning up a new devstack tonight I noticed some very odd behavior. Keystone is suddenly giving me back a 3000+ character auth token, and the ids for flavors I'm creating are extremely large ints (uuids I could see, but not this). Does anyone have any insight into if either of these changes were intentional? I believe you have run into the change that Keystone recently made that switched to using PKI by default for token authentication in the services. Adam, can you verify this is the case, and a remedy for Daryl? Thanks much! -jay -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [SWIFT] Proxies Sizing for 90.000 / 200.000 RPM
On 10/24/2012 07:45 PM, heckj wrote: John brought the concern over auth_token middleware up to me directly - I don't know of anyone that's driven the keystone middleware to these rates and determined where the bottlenecks are other than folks deploying swift and driving high performance numbers. The concern that John detailed to me is how the middleware handles memcache connections, which is directly impacted by how you're deploying it. From John: Specifically, I'm concerned with the way auth_token handles memcache connections. I'm not sure how well it will work in swift with eventlet. If the memcache module being used caches sockets, then concurrency in eventlet (different greenthreads) will cause problems. Eventlet detects and prevents concurrent access to the same socket (for good reason--data from the socket may be delivered to the wrong listener). We should probably disable memcache for PKI tokens I haven't driven any system this hard to suss out the issues, but there's the nut of it - how to keep from cascading that load out to validation of authorization tokens. The middleware is assuming that eventlet and any needed patching has already been done when it's invoked (i.e. no monkeypatching in there), and loads the memcache module and uses whatever it has in there directly. This is all assuming you're using the current standard of UUID based tokens. Keystone is also supporting PKI based tokens, which removes the need to constantly make the validation call, but at the computational cost of unspinning the decryption around the signed token. I don't know of any load numbers and analysis with that backing set up at this time, and would expect that any initial analysis would lead to some clear performance optimizations that may be needed. The fork is the expensive part, but it should also parallelize fairly well. One reason we chose this approach is that it seems to fit in best with how Eventlet works: a fork means there should be no reason to do a real thread, and thus it can use greenlets and processes. But we won't know until we try to scale it. PKI tokens just went default, so we should find out soon. - joe On Oct 24, 2012, at 1:20 PM, Alejandro Comisario alejandro.comisa...@mercadolibre.com mailto:alejandro.comisa...@mercadolibre.com wrote: Thanks Josh, and Thanks John. I know it was an exciting Summit! Congrats to everyone ! John, let me give you extra data and something that i've already said, that might me wrong. First, the request size that will compose the 90.000RPM - 200.000 RPM will be from 90% 20K objects, and 10% 150/200K objects. Second, all the GET requests, are going to be public, configured through ACL, so, if the GET requests are public (so, no X-Auth-Token is passed) why should i be worried about the keystone middleware ? Just to clarify, because i really want to understand what my real metrics are so i can know where to tune in case i need to. Thanks ! * * *---* *Alejandrito* On Wed, Oct 24, 2012 at 3:28 PM, John Dickinson m...@not.mn mailto:m...@not.mn wrote: Sorry for the delay. You've got an interesting problem, and we were all quite busy last week with the summit. First, the standard caveat: Your performance is going to be highly dependent on your particular workload and your particular hardware deployment. 3500 req/sec in two different deployments may be very different based on the size of the requests, the spread of the data requested, and the type of requests. Your experience may vary, etc, etc. However, for an attempt to answer your question... 6 proxies for 3500 req/sec doesn't sound unreasonable. It's in line with other numbers I've seen from people and what I've seen from other large scale deployments. You are basically looking at about 600 req/sec/proxy. My first concern is not the swift workload, but how keystone handles the authentication of the tokens. A quick glance at the keystone source seems to indicate that keystone's auth_token middleware is using a standard memcached module that may not play well with concurrent connections in eventlet. Specifically, sockets cannot be reused concurrently by different greenthreads. You may find that the token validation in the auth_token middleware fails under any sort of load. This would need to be verified by your testing or an examination of the memcache module being used. An alternative would be to look at the way swift implements it's memcache connections in an eventlet-friendly way (see swift/common/memcache.py:_get_conns() in the swift codebase). --John On Oct 11, 2012, at 4:28 PM, Alejandro Comisario alejandro.comisa...@mercadolibre.com mailto:alejandro.comisa...@mercadolibre.com wrote: Hi Stackers ! This is the thing, today we have a 24 datanodes (3 copies, 90TB usables) each datanode has 2 intel hexacores CPU with
Re: [Openstack] Fwd: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
On 10/23/2012 01:25 AM, Jorge Williams wrote: Here's my view: On making the default token a configuration option: Like the idea. Disabling the option by default. That's fine too. On scoping a token to a specific endpoint: That's fine, though I believe that that's in the API today. Currently, the way that we scope tokens to endpoints is by validating against the service catalog. I'm not sure if the default middleware checks for this yet, but the Repose middleware does. If you try to use a token in an endpoint that's not in the service catalog the request fails -- well, if the check is turned on. Obviously, I'd like the idea of scoping a single token to multiple tenants / endpoints. I don't like the idea of calling tokens sloppy tokens -- it's confusing. All you have to say is that a token has a scope -- and the scope of the token is the set of resources that the token can provide access to. You can limit the scope of a token to a tenant, to a endpoint, to a set of endpoints or tenants etc -- what limits you place on the scope of an individual token should be up to the operator. Keep in mind that as we start digging into delegation and fine grained authorization (after Grizzly, I'm sure), we'll end up with tokens that have a scope of a subset of resources in a single or multiple tenants. So calling them sloppy now is just confusing. Simply stating that a token has a scope (as I've defined above) should suffice. This is part of the reason why I've never liked the term unscoped token, because an unscoped token does have a scope. It just so happens that the scope of that token is the resource that provides a list of available tenants. This is a pretty good distinction. What we were calling Unscoped is, to me, the equivalent of a TGT in Kerberos: a starting point, that has not been specified to any resources. I'd be willing to entertain a different name than Unscoped. Let me throw out Starting Tokens as a straw man, and we can beat it up to come up with a better term. Sloppy was never meant seriously, but more a way to tweak the noses of the project members named Joe. -jOrGe W. On Oct 22, 2012, at 9:57 PM, Adam Young wrote: Are you guys +1 ing the original Idea, my suggestion to make it optional, the fact that I think we should call these sloppy tokens? On 10/22/2012 03:40 PM, Jorge Williams wrote: +1 here too. At the end of the day, we'd like the identity API to be flexible enough to allow the token to be scoped in a manner that the deployer sees fit. What the keystone implementation does by default is a different matter -- and disabling multiple tenant scope by default would be fine by me. -jOrGe W. On Oct 21, 2012, at 11:10 AM, Joe Savak wrote: +1. ;) So the issue is that the v2 API contract allows a token to be scoped to multiple tenants. For v3, I'd like to have the same flexibility. I don't see security issues, as if a token were to be sniffed you can change the password of the account using it and use those creds to scope tokens to any tenant you wish. Scope should always be kept as limited as possible. Personally, I don't feel like limiting the tenant list makes much difference. THe more I think about it, the real benefit comes from limiting the endpoints. On Oct 20, 2012, at 21:07, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 10/20/2012 01:50 PM, heckj wrote: I sent this to the openstack-dev list, and thought I'd double post this onto the openstack list at Launchpad for additional feedback. -joe Begin forwarded message: *From: *heckj he...@mac.com mailto:he...@mac.com *Subject: **[openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API* *Date: *October 19, 2012 1:51:16 PM PDT *To: *OpenStack Development Mailing List openstack-...@lists.openstack.org mailto:openstack-...@lists.openstack.org *Reply-To: *OpenStack Development Mailing List openstack-...@lists.openstack.org mailto:openstack-...@lists.openstack.org The topic of what a token can or can't represent for the upcoming V3 Keystone API came up - and I wanted to share the conversation a bit more broadly to get feedback. A bit of history: In the V2 API, when you authenticated with just a username and password, the token that was provided wasn't entirely clearly defined. The reference implementation that Keystone used was to create what's been called an 'unscoped' token - which was generally limited to only being able to get a list of possible tenants/projects and the capability of getting a token specific to a user tenant/project (what's been called a scoped token) Likewise, the reference implementation of the rest of the OpenStack projects all require a tenant information to be included within the token as that token was the identity refernce inforoamtion - and most OpenStack services were wanting to know the tenant associated with the token
Re: [Openstack] Keystone-dev question
On 10/22/2012 02:16 PM, Ken Thomas wrote: Greetings all, I'm working on a keystone bug (to get my feet wetter) and I have a couple of questions. Could someone please take a look at comment #2 in https://bugs.launchpad.net/python-keystoneclient/+bug/1031245 (Get a User by Name) and let me know what y'all think? Thanks, Ken ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Done! ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Fwd: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
Are you guys +1 ing the original Idea, my suggestion to make it optional, the fact that I think we should call these sloppy tokens? On 10/22/2012 03:40 PM, Jorge Williams wrote: +1 here too. At the end of the day, we'd like the identity API to be flexible enough to allow the token to be scoped in a manner that the deployer sees fit. What the keystone implementation does by default is a different matter -- and disabling multiple tenant scope by default would be fine by me. -jOrGe W. On Oct 21, 2012, at 11:10 AM, Joe Savak wrote: +1. ;) So the issue is that the v2 API contract allows a token to be scoped to multiple tenants. For v3, I'd like to have the same flexibility. I don't see security issues, as if a token were to be sniffed you can change the password of the account using it and use those creds to scope tokens to any tenant you wish. Scope should always be kept as limited as possible. Personally, I don't feel like limiting the tenant list makes much difference. THe more I think about it, the real benefit comes from limiting the endpoints. On Oct 20, 2012, at 21:07, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 10/20/2012 01:50 PM, heckj wrote: I sent this to the openstack-dev list, and thought I'd double post this onto the openstack list at Launchpad for additional feedback. -joe Begin forwarded message: *From: *heckj he...@mac.com mailto:he...@mac.com *Subject: **[openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API* *Date: *October 19, 2012 1:51:16 PM PDT *To: *OpenStack Development Mailing List openstack-...@lists.openstack.org mailto:openstack-...@lists.openstack.org *Reply-To: *OpenStack Development Mailing List openstack-...@lists.openstack.org mailto:openstack-...@lists.openstack.org The topic of what a token can or can't represent for the upcoming V3 Keystone API came up - and I wanted to share the conversation a bit more broadly to get feedback. A bit of history: In the V2 API, when you authenticated with just a username and password, the token that was provided wasn't entirely clearly defined. The reference implementation that Keystone used was to create what's been called an 'unscoped' token - which was generally limited to only being able to get a list of possible tenants/projects and the capability of getting a token specific to a user tenant/project (what's been called a scoped token) Likewise, the reference implementation of the rest of the OpenStack projects all require a tenant information to be included within the token as that token was the identity refernce inforoamtion - and most OpenStack services were wanting to know the tenant associated with the token for authorization/ownership purposes. Apparently Rackspace's internal implementation provided a token that was immediately valid for all possible tenants to which the user was associated, and presumably their internal implementations of openstack do whatever work is appropriate to discern and provide that information to the various openstack services. The quandary: In the V3 API, we started off with, and currently define the token as being specifically mandated to a single tenant, with a new requirement that if you authorize with just a username and password, a default tenant is used. If for some reason you have no tenant associated with the userid, the authorization is to be refused. If the user is associated with more than one tenant/project, it's possible to use the token to get a list of other tenants/projects and request a new token specific to one of those other tenant/projects, but the implementation is expected to respect and provide a default. I would like to make default tenant a configuration option, and have it disabled by default. Unscoped tokens are a very useful construct. In the case where the user has many roles across a multitude of projects, it is possible to create huge tokens. I would prefer unscoped tokens to remain, and to be associated with no tenant. The only operation Keystone should provide with them is the ability to enumerate tenants, so something like Horizon can then request an appropriately scoped token. I am also in favor of limiting the scope of a token to an endpoint. Even more-so than tenants, scoping a token to an end point increases security. Once a token has been scoped to an endpoint, it can only be used on that endpoint. If an endpoint gets compromised, the damage is limited to resources that endpoint already has access to. This, in conjunction with pre-auths, could allow a user to perform an action with a minimum of risk in a public cloud environment. A few folks from Rackspace touched on this at the very tail end of the V3 API review session on Thursday, bringing up that they had an issue with the token being scoped to a single tenant. Since this has significant implications to both security
Re: [Openstack] Fwd: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
On 10/20/2012 01:50 PM, heckj wrote: I sent this to the openstack-dev list, and thought I'd double post this onto the openstack list at Launchpad for additional feedback. -joe Begin forwarded message: *From: *heckj he...@mac.com mailto:he...@mac.com *Subject: **[openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API* *Date: *October 19, 2012 1:51:16 PM PDT *To: *OpenStack Development Mailing List openstack-...@lists.openstack.org mailto:openstack-...@lists.openstack.org *Reply-To: *OpenStack Development Mailing List openstack-...@lists.openstack.org mailto:openstack-...@lists.openstack.org The topic of what a token can or can't represent for the upcoming V3 Keystone API came up - and I wanted to share the conversation a bit more broadly to get feedback. A bit of history: In the V2 API, when you authenticated with just a username and password, the token that was provided wasn't entirely clearly defined. The reference implementation that Keystone used was to create what's been called an 'unscoped' token - which was generally limited to only being able to get a list of possible tenants/projects and the capability of getting a token specific to a user tenant/project (what's been called a scoped token) Likewise, the reference implementation of the rest of the OpenStack projects all require a tenant information to be included within the token as that token was the identity refernce inforoamtion - and most OpenStack services were wanting to know the tenant associated with the token for authorization/ownership purposes. Apparently Rackspace's internal implementation provided a token that was immediately valid for all possible tenants to which the user was associated, and presumably their internal implementations of openstack do whatever work is appropriate to discern and provide that information to the various openstack services. The quandary: In the V3 API, we started off with, and currently define the token as being specifically mandated to a single tenant, with a new requirement that if you authorize with just a username and password, a default tenant is used. If for some reason you have no tenant associated with the userid, the authorization is to be refused. If the user is associated with more than one tenant/project, it's possible to use the token to get a list of other tenants/projects and request a new token specific to one of those other tenant/projects, but the implementation is expected to respect and provide a default. I would like to make default tenant a configuration option, and have it disabled by default. Unscoped tokens are a very useful construct. In the case where the user has many roles across a multitude of projects, it is possible to create huge tokens. I would prefer unscoped tokens to remain, and to be associated with no tenant. The only operation Keystone should provide with them is the ability to enumerate tenants, so something like Horizon can then request an appropriately scoped token. I am also in favor of limiting the scope of a token to an endpoint. Even more-so than tenants, scoping a token to an end point increases security. Once a token has been scoped to an endpoint, it can only be used on that endpoint. If an endpoint gets compromised, the damage is limited to resources that endpoint already has access to. This, in conjunction with pre-auths, could allow a user to perform an action with a minimum of risk in a public cloud environment. A few folks from Rackspace touched on this at the very tail end of the V3 API review session on Thursday, bringing up that they had an issue with the token being scoped to a single tenant. Since this has significant implications to both security and a potential user experience flow, I wanted to bring the issue up across the broader community for discussion. The request outstanding: Rackspace folks are requesting that the token not be limited to a single tenant/project, but instead provides a list of potential tenants against which the token should be considered valid. I would like the world to know that we are affectionately calling such tokens sloppy tokens and Joe Savak has adopted the nickname of Sloppy Joe for championing them. Allowing it as an option is fine, but I would not recommend that this become the norm, or that we enable this feature by default. Brief (maybe shoddy) analysis: This would potentially imply changes to what gets passed as a part of the authentication reference in the context passed using auth_token middleware - multiple tenants possible instead of the currently expected single value - so using that as information for create() style mechanisms would need to provide some alternative means of clearly defining what tenant/project should be owner. It would provide anyone compromising that particular token with a broader spectrum of impact on a replay style attack. Likewise,
Re: [Openstack] A simple guide to install OpenStack Folsom
On 10/10/2012 05:27 AM, Skible OpenStack wrote: Le 10/10/2012 11:23, Alan Pevec a écrit : On Wed, Oct 10, 2012 at 11:10 AM, Skible OpenStack skible.openst...@gmail.com wrote: I am counting on our your feedback to enhance my work and contribute it to the OpenStack Eco System. I wonder about https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/tree/master/Scripts which say: # Mainly inspired by https://github.com/openstack/keystone/blob/master/tools/sample_data.sh Why not submit that as an improvement to Keystone? I'd like to propose consolidation of all keystone initialization scripts around (Keyston's sample_data.sh, Devstack's keystone_data.sh, scripts like yours) and move to Lorin's YAML config (see https://lists.launchpad.net/openstack/msg17204.html) I'm just not sure yet if additional dependency on YAML is worth it. Cheers, Alan Hi Alan, That's a very good idea. I personally prefer scripting over YAML since it is simpler and easier to use. devstack's script is way fat to me, it adds things i don't need so i had put it on a diet to come out with a much simpler and easier script. I will see how i can submit my work to keystone people. As you would submite anything, of course: Open a bug on launchpad, describe the problem, and then submit a patch, with Bug id in the commit message. We'll see it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] FreeIPA LDAP + Keystone question: How to assign roles to user?
Role is grouped in the collection under the Tenant, with the userid in the members attribute for that role. On 09/24/2012 03:18 AM, ?? wrote: Openstack services need user account with 'admin' role. But I could not figure out how FreeIPA propagate 'role' into Keystone. That's why I'm asking the question in mailing list. On Sep 24, 2012, at 11:30 AM, spring wrote: Thanks qiujian! By using this configuration, can we log in through dashboard? If I want to implement that, is there any other configuration I have to do? 2012/9/24 ?? qiuj...@meituan.com mailto:qiuj...@meituan.com BTW, here is my configuration: [ldap] url = ldap://10.64.11.199 tree_dn = cn=accounts,dc=mydomain,dc=com user_tree_dn = cn=users,cn=accounts,dc=mydomain,dc=com user_objectclass = person user_name_attribute = uid user_id_attribute = uid tenant_tree_dn = cn=groups,cn=accounts,dc=mydomain,dc=com tenant_objectclass = posixgroup tenant_id_attribute = cn tenant_name_attribute = cn tenant_member_attribute = member role_tree_dn = cn=groups,cn=accounts,dc=mydomain,dc=com role_objectclass = posixgroup role_id_attribute = cn role_name_attribute = cn role_member_attribute = member user = uid=sudo,cn=sysaccounts,cn=etc,dc=mydomain,dc=com password = mysudopassword suffix = cn=mydomain,cn=com [identity] driver = keystone.identity.backends.ldap.Identity It seems that keystone LDAP requires role nodes the children of tenant nodes. But FreeIPA has a flat structure. -- ?? ??? - ? ??:1381129925 ??:qiuj...@meituan.com mailto:qiuj...@meituan.com On Sep 22, 2012, at 12:27 PM, ?? wrote: Hi, I was working on using LDAP of FreeIP as backend of Keystone. User and tenants information can be fetched from LDAP. However, I could not figure out how to assign roles to users in specific tenants. I'm wondering whether someone can help? I noticed that Mr. Adam Young had post a blog about this topic: http://adam.younglogic.com/2012/09/ldaps-against-a-freeipa-server/ However, it did not show how to import roles in LDAP. I'm wondering whether there is any progress about this? Many thanks. keystone in use was the latest master branch on github on Sep 21, 2012. Jian Qiu ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp -- Huang Shuquan (???) Software Institute of Nanjing University Nanjing, P.R.China Mobile: 86 137 7086 4433 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone: LDAP identity driver 'list resource' support
On 09/10/2012 11:29 AM, boden wrote: I've been munking with the latest Keystone LDAP identity driver and based on what I'm seeing the driver does not support the 'list' resource based methods. For example 'list users', 'list tenants'... For example, config your keystone.conf up to use an LDAP backend which contains the supported DIT structure for the driver and then fire up keystone. Hit keystone with a GET /users or GET /tenants request and 500/501 errors. Switch your identity driver back to the SQL identity driver and retry -- all is well and you can list users and tenants. Looking at the code it appears the ldap identity driver does not implement the list_*() methods (list_users(), list_roles()...) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp That is correct. I thought we already had a ticket for this one, but it does not appear to be so. Please go ahead and open one. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone: LDAP identity driver 'list resource' support
On 09/10/2012 02:28 PM, Joseph Heck wrote: Hey Boden, It's not scheduled to be fixed in the Folsom release, the linkages to milestones and such indicate that. The original developer that proposed a patch disappeared in that flow, so it stagnated. Adam just picked it up and assigned it to himself though to dig around on it - so perhaps he can provide more detail there. In retrospect, the patch is trivial, and it seems to fit a need. We should be able to sneak it in. I'm trying to test the CLI right now, but the unit tests look good. -joe On Sep 10, 2012, at 10:31 AM, boden bo...@linux.vnet.ibm.com wrote: Thanks... Is this defect going to get resolved in the folsom time-frame? Looks like the target milestone was set to none and the defect has been inactive for 2.5 months. On 9/10/2012 12:43 PM, Dolph Mathews wrote: You thought correct: https://bugs.launchpad.net/keystone/+bug/983304 -Dolph On Mon, Sep 10, 2012 at 11:32 AM, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 09/10/2012 11:29 AM, boden wrote: I've been munking with the latest Keystone LDAP identity driver and based on what I'm seeing the driver does not support the 'list' resource based methods. For example 'list users', 'list tenants'... For example, config your keystone.conf up to use an LDAP backend which contains the supported DIT structure for the driver and then fire up keystone. Hit keystone with a GET /users or GET /tenants request and 500/501 errors. Switch your identity driver back to the SQL identity driver and retry -- all is well and you can list users and tenants. Looking at the code it appears the ldap identity driver does not implement the list_*() methods (list_users(), list_roles()...) _ Mailing list: https://launchpad.net/~__openstack https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~__openstack https://launchpad.net/~openstack More help : https://help.launchpad.net/__ListHelp https://help.launchpad.net/ListHelp That is correct. I thought we already had a ticket for this one, but it does not appear to be so. Please go ahead and open one. _ Mailing list: https://launchpad.net/~__openstack https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~__openstack https://launchpad.net/~openstack More help : https://help.launchpad.net/__ListHelp https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone: LDAP identity driver 'list resource' support
On 09/10/2012 03:55 PM, Adam Young wrote: On 09/10/2012 02:28 PM, Joseph Heck wrote: Hey Boden, It's not scheduled to be fixed in the Folsom release, the linkages to milestones and such indicate that. The original developer that proposed a patch disappeared in that flow, so it stagnated. Adam just picked it up and assigned it to himself though to dig around on it - so perhaps he can provide more detail there. In retrospect, the patch is trivial, and it seems to fit a need. We should be able to sneak it in. I'm trying to test the CLI right now, but the unit tests look good. Please review. https://review.openstack.org/#/c/12726/ -joe On Sep 10, 2012, at 10:31 AM, boden bo...@linux.vnet.ibm.com wrote: Thanks... Is this defect going to get resolved in the folsom time-frame? Looks like the target milestone was set to none and the defect has been inactive for 2.5 months. On 9/10/2012 12:43 PM, Dolph Mathews wrote: You thought correct: https://bugs.launchpad.net/keystone/+bug/983304 -Dolph On Mon, Sep 10, 2012 at 11:32 AM, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 09/10/2012 11:29 AM, boden wrote: I've been munking with the latest Keystone LDAP identity driver and based on what I'm seeing the driver does not support the 'list' resource based methods. For example 'list users', 'list tenants'... For example, config your keystone.conf up to use an LDAP backend which contains the supported DIT structure for the driver and then fire up keystone. Hit keystone with a GET /users or GET /tenants request and 500/501 errors. Switch your identity driver back to the SQL identity driver and retry -- all is well and you can list users and tenants. Looking at the code it appears the ldap identity driver does not implement the list_*() methods (list_users(), list_roles()...) _ Mailing list: https://launchpad.net/~__openstack https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~__openstack https://launchpad.net/~openstack More help : https://help.launchpad.net/__ListHelp https://help.launchpad.net/ListHelp That is correct. I thought we already had a ticket for this one, but it does not appear to be so. Please go ahead and open one. _ Mailing list: https://launchpad.net/~__openstack https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~__openstack https://launchpad.net/~openstack More help : https://help.launchpad.net/__ListHelp https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Cannot submit topic for Summit.
I've been through the sequence to submit a topic proposal for the summit a handful of times. I submit, and it says You are not logged in. And yes, I logged back in afterwards. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone] LDAP integratiom
On 09/06/2012 05:23 PM, Ivan Kolodyazhny wrote: Hi Everyone, Keystone uses python-ldap library to communicate with LDAP server. There are to points where Keystone communicates with LDAP server: keystone.common ldap and keystone.identity.backends.ldap packages. According to the current Keystone architecture it is solid application w/o extensions or plugins. So it will be useful to add python-ldap library to pip-requires file. This dependency is already resolved in the test-requires with comment: 'Optional backend: LDAP'. LDAP support is optional, which is why it is not currently in pip-requires, but I suspect that, as it grows in visibility, it will make sense to include it. It would be helpful to report things like this as a bug and to provide a patch. Best regards, Ivan Kolodyazhny ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone] LDAP integratiom
On 09/07/2012 10:31 AM, Dolph Mathews wrote: pip-requires/test-requires is aimed at developers and is broken up into two files more-so for documentation/organization purposes. IMO, including LDAP as a dependency should be solved by real packaging (e.g. $ apt-get install keystone keystone-ldap). True, and now that I think of it, I would agree that a pip-requires would not make sense here. Where it would make sense is in devstack. And I have a ticket for that already. https://bugs.launchpad.net/devstack/+bug/1021319 My thinking is that if we add ldap to the supported list, keystone would be configured to use LDAP as the identity store. -Dolph On Fri, Sep 7, 2012 at 8:30 AM, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 09/06/2012 05:23 PM, Ivan Kolodyazhny wrote: Hi Everyone, Keystone uses python-ldap library to communicate with LDAP server. There are to points where Keystone communicates with LDAP server: keystone.common ldap and keystone.identity.backends.ldap packages. According to the current Keystone architecture it is solid application w/o extensions or plugins. So it will be useful to add python-ldap library to pip-requires file. This dependency is already resolved in the test-requires with comment: 'Optional backend: LDAP'. LDAP support is optional, which is why it is not currently in pip-requires, but I suspect that, as it grows in visibility, it will make sense to include it. It would be helpful to report things like this as a bug and to provide a patch. Best regards, Ivan Kolodyazhny ___ Mailing list:https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to :openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe :https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help :https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone] Creating tenant failed when using ldap as identity backend: 'attribute type undefined'
Interesting. We have this outstanding bug report
https://code.launchpad.net/bugs/980085
I would appreciate it if you could add what you found to the bug report.
On 09/06/2012 03:50 AM, Yanping Xie wrote:
Hi, All
I have resolved this problem by add 'enabled' attribute to
class groupOfNames of ldap schema, thanks all the same.
*attributetype ( 2.5.4.66 NAME 'enabled'*
*DESC 'RFC2256: enabled of a group'*
*EQUALITY booleanMatch*
*SYNTAX 1.3.6.1.4.1.1466.115.121.1.7*
*SINGLE-VALUE )*
objectclass ( 2.5.6.9 NAME 'groupOfNames'
DESC 'RFC2256: a group of names (DNs)'
SUP top STRUCTURAL
MUST ( member $ cn )
MAY ( businessCategory $ seeAlso $ owner $ ou $ o $
description $ *enabled *) )
2012/9/5 Yanping Xie irs...@gmail.com mailto:irs...@gmail.com
Hi, all
I am trying to setup keystone to use ldap as backend, but failed
on creating the first tenant.
# keystone tenant-create --name=admin
An unexpected error prevented the server from fulfilling your
request. {'info': 'enabled: attribute type undefined', 'desc':
'Undefined attribute type'} (HTTP 500)
Here is my keystone config about ldap(snippets from keystone.log):
--
ldap.tenant_member_attribute = member
ldap.tenant_name_attribute = ou
ldap.tenant_objectclass= groupOfNames
ldap.tenant_tree_dn= ou=Group,dc=example,dc=com
ldap.url = ldap://182.xxx.29.250
ldap.use_dumb_member = False
ldap.user = cn=Manager,dc=example,dc=com
ldap.user_id_attribute = cn
ldap.user_name_attribute = sn
ldap.user_objectclass = inetOrgPerson
ldap.user_tree_dn = ou=User,dc=example,dc=com
--
Ldap server migration file to initialize ldap:
--
dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
dc: example
o: The Example Corporation
dn: ou=Group,dc=example,dc=com
ou: Group
objectClass: top
objectClass: organizationalUnit
dn: ou=User,dc=example,dc=com
ou: User
objectClass: top
objectClass: organizationalUnit
dn: ou=Role,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
--
Related keytone log is as follows:
---
2012-09-05 18:45:33DEBUG [keystone.common.ldap.core] LDAP
init: url=ldap://182.xxx.29.250
2012-09-05 18:45:33DEBUG [keystone.common.ldap.core] LDAP
bind: dn=cn=Manager,dc=example,dc=com
2012-09-05 18:45:33DEBUG [keystone.common.ldap.core] LDAP add:
dn=cn=7ab0c10b9fc04f89affb66e1650fc694,ou=Group,dc=example,dc=com,
attrs=[('objectClass', ['groupOfNames']), (
'enabled', ['TRUE']), ('ou', ['admin']), ('member',
['cn=dumb,dc=nonexistent'])]
2012-09-05 18:45:33ERROR [root] {'info': 'enabled: attribute
type undefined', 'desc': 'Undefined attribute type'}
Traceback (most recent call last):
File /usr/lib/python2.6/site-packages/keystone/common/wsgi.py,
line 204, in __call__
result = method(context, **params)
File
/usr/lib/python2.6/site-packages/keystone/identity/core.py, line
397, in create_tenant
context, tenant_ref['id'], tenant_ref)
File
/usr/lib/python2.6/site-packages/keystone/common/manager.py,
line 47, in _wrapper
return f(*args, **kw)
File
/usr/lib/python2.6/site-packages/keystone/identity/backends/ldap/core.py,
line 208, in create_tenant
return self.tenant.create(tenant)
File
/usr/lib/python2.6/site-packages/keystone/identity/backends/ldap/core.py,
line 492, in create
return super(TenantApi, self).create(data)
File
/usr/lib/python2.6/site-packages/keystone/common/ldap/core.py,
line 179, in create
conn.add_s(self._id_to_dn(values['id']), attrs)
File
/usr/lib/python2.6/site-packages/keystone/common/ldap/core.py,
line 310, in add_s
return self.conn.add_s(dn, ldap_attrs)
File /usr/lib64/python2.6/site-packages/ldap/ldapobject.py,
line 194, in add_s
return self.result(msgid,all=1,timeout=self.timeout)
File /usr/lib64/python2.6/site-packages/ldap/ldapobject.py,
line 436, in result
res_type,res_data,res_msgid = self.result2(msgid,all,timeout)
File /usr/lib64/python2.6/site-packages/ldap/ldapobject.py,
line 440, in result2
res_type, res_data, res_msgid, srv_ctrls =
Re: [Openstack] Keystone PKI support
On 09/04/2012 09:36 AM, boden wrote: Hi, I'm trying to better understand the current status of PKI (http://wiki.openstack.org/PKI) and delegated authZ from a folsom perspective. I can see the blueprint targets folsom-rc1, is marked as implemented (https://blueprints.launchpad.net/keystone/+spec/pki) and I've browsed some of the related code dropped into master. However its not clear to me exactly where this PKI support stands as I haven't found any docs on setting up the services to use it, nor am I seeing PKI based tokens used when I run with the latest keystone code. Is it safe to assume PKI will be supported for folsom and we will see some updated docs in due time? If so will there be any known limitations? Thx much ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp The PKI token code is very new. As such, It has not been enabled by default. There are changes that have gone in to the master branch that are not available on Folsom 3 that are necessary to the proper functioning of PKI. I wrote to the Fedora cloud mailing list a quicjk blurb on testing them. http://www.spinics.net/linux/fedora/fedora-cloud/msg01644.html I will write up some more detailed steps for general usage. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] ldaps support in keystone?
On 08/22/2012 09:38 AM, Yanping Xie wrote: Hi, all Could I ask if ldaps is supported in keystone? I do know that ldap is supported in keystone, but I couldn't find any information about ladps support in keystone via google nor openstack doc. Could anyone give some explicit information about that? Thanks. Best Regards. Yanping ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp LDAPS is not currently supported. Since this is This is the second time I've been asked this today, I am filing a ticket for it: https://bugs.launchpad.net/keystone/+bug/1040115 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keyring support in openstack
On 08/22/2012 07:15 PM, Bhuvaneswaran A wrote: On Mon, Jul 30, 2012 at 5:48 PM, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 07/30/2012 06:00 PM, Doug Hellmann wrote: On Mon, Jul 30, 2012 at 5:30 PM, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 07/30/2012 05:17 PM, Kevin L. Mitchell wrote: On Mon, 2012-07-30 at 13:50 -0700, Bhuvaneswaran A wrote: The wiki mentions the password being saved using keyring.backend.UncryptedFileKeyring. Does that mean the password is saved in cleartext? Is the file protected in some way besides filesystem permissions? As mentioned in wiki page, the password is stored in base64 format. Which means it's stored in cleartext. That is Not Good(tm) :) Can Keyring be used to store a token instead? That would A) be better than password and B) avoid a Keystone hit. Don't tokens expire? Yes, they do, but that is no reason not to put them in the keyring, With the PKI tokens, you will be able to query a token's expiry without going across the wire. Adam, can you please file a ticket to use keyring to store tokens for keystone? I'll work on it. https://bugs.launchpad.net/keystone/+bug/1040361 -- Regards, Bhuvaneswaran A www.livecipher.com http://www.livecipher.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] implementing custom keystone module
On 08/21/2012 05:10 PM, pat wrote: Hello, I want to implement custom keystone authentication module. I went through the What are you trying to do? There is a good chance that one of the other modules can be a good example. documentation and I'm not sure where to start :-\ Please, could you point me to specific page describing this? Thanks. And one more: please, could you point me to document which describes relation between keystone and WSGI? And WSGI is a standard for writing Web applicaions in Python. Keystone complies with the WSGI contract. THus, while Keystone is usually run in the Eventlet web container, it can run in Apache HTTPD as well. Both are WSGI containers. yes, I've never used python :-) Thanks for help. Pat P.S. I've googled a lot, but keystone is too common world :-( Google for Openstack Keystone and you will have more success. Freehosting PIPNI - http://www.pipni.cz/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] keystone initialization problem
OK, SERVICE_TOKEN is the same as --token You can follow the steps here: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_OpenStack_Preview/ Specifically: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_OpenStack_Preview/1/html/Getting_Started_Guide/ch02.html#id3165390 || *|export SERVICE_TOKEN=$(openssl rand -hex 10)|* || *|export SERVICE_ENDPOINT=http://127.0.0.1:35357/v2.0|* || *|echo $SERVICE_TOKEN /tmp/ks_admin_token|* || *|sudo openstack-config --set /etc/keystone/keystone.conf \|* *|DEFAULT admin_token $SERVICE_TOKEN|* and that should be the admin_token value that you have. If nothing is in the log, it probably means you have not actually hit the right server. On 08/17/2012 05:47 PM, Dolph Mathews wrote: The admin_token value from keystone.conf is not a real token; it exists as a string in memory and has no context, user or actual roles associated with it (hence it does not appear in your token table). As for your actual issue, I don't see anything obviously wrong with what's below. Is logging enabled working, otherwise? Have you tried verbose = True and debug = True? Have you tried running that command from the compute node itself, rather than over the internet IP? What happens when you curl / GET / whatever http://internet_ip of the controller node:35357/v2.0 and/or http://127.0.0.1:35357/v2.0 ? -Dolph On Fri, Aug 17, 2012 at 3:26 PM, Xin Zhao xz...@bnl.gov mailto:xz...@bnl.gov wrote: Hello, I newly install keystone on the RHEL6 machine, but it is not working. The following command fails: $ keystone --token admin_token string from keystone.conf --endpoint http://internet_ip of the controller node:35357/v2.0 tenant-create --name openstackDemo --description Default Tenant --enabled true Unable to communicate with identity service: (403, 'Forbidden'). (HTTP 400) There is no relevant log in the keystone.log file. Here is the instruction I follow: http://docs.openstack.org/essex/openstack-compute/install/yum/content/setting-up-tenants-users-and-roles.html This is done on the controller node itself. I can telnet to internet_ip of the controller node:35357. I can also log into mysql DB as keystone user, although there is no admin_token entry in any of the keystone tables. Any idea what is going wrong here? Thanks, Xin ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] The Return of Hyper-V
On 08/13/2012 11:26 AM, Peter Pouliot wrote: Hello Everyone, I would like to take this moment to make everyone aware of the following: https://review.openstack.org/#/c/11276/ I would like to thank the following individuals, who have given so much to help this project progress to this state. Without their efforts this project would be dead in the water. Jordan Rinke: Thank you for doing the original work to bring back base Essex functionality and your effort help jump start this community and for that I am grateful. You are one of the original champions of Hyper-V. Alessandro Pilotti (CloudBase Solutions): Thank you for all the tremendous amount of code you produced. We would not have the feature set, unit tests or the Folsom integration without the many hours you graciously contributed to the project. I am truly grateful for the effort you produced. At times I thought this project was going to fail. Without your effort it most certainly would have. Pedro Navarro Perez: Thank you reaching out to me at the OpenStack summit and being the first hyper-v community member. Your efforts on Volume Attach/Detach and boot from volume are greatly appreciated. Thank you for the collaboration with other members to test, troubleshoot and advance our efforts. Your effort over this weekend helping Alessandro to this point was necessary for this submission to occur. Jose Castro Leon: Jose, thank you for your assistance testing. Given all that is going on these days at CERN, you still found time to help us test Hyper-V. To Vish, Monty and Stef, thank you for all of your guidance in this process. Hopefully because of your help and wisdom it will be a quick and painless approval and integration process. And last and most importantly: To Hashir Abdi, my colleague at Microsoft. I am grateful for you believing in this project. From the early days in the Interop lab, you saw the true potential. Thank you for the hours you have spent making sure that this project progressed forward. We have busy days ahead. Once again, thank you everyone for your assistance. p Peter J. Pouliot, CISSP Senior SDET, OpenStack Microsoft New England Research Development Center One Memorial Drive,Cambridge, MA 02142 ppoul...@microsoft.com mailto:ppoul...@microsoft.com | Tel: +1(857) 453 6436 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Well done, Peter and company. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone: 'PKI Signed Tokens' lack support for revocation
On 08/01/2012 09:19 PM, Maru Newby wrote: I see that support for PKI Signed Tokens has been added to Keystone without support for token revocation. I tried to raise this issue on the bug report: https://bugs.launchpad.net/keystone/+bug/1003962/comments/4 And the review: https://review.openstack.org/#/c/7754/ I'm curious as to whether anybody shares my concern and if there is a specific reason why nobody responded to my question as to why revocation is not required for this new token scheme. Anybody? I have written up a blueprint for PKI token revocation. Please provide feedback. https://blueprints.launchpad.net/keystone/+spec/pki-revoke Thanks, Maru ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone: 'PKI Signed Tokens' lack support for revocation
On 08/02/2012 10:54 PM, Nathanael Burton wrote: Adam, I haven't yet had a chance to review how the new PKI signed tokens is implemented, but what you're describing sounds quite similar to online certificate status protocol (OCSP) but for tokens. Yes, I don't really have new idea here, just reimplementaiton of ideas from other projects. Nate On Aug 2, 2012 10:24 PM, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 08/01/2012 11:05 PM, Maru Newby wrote: Hi Adam, I apologize if my questions were answered before. I wasn't aware that what I perceive as a very serious security concern was openly discussed. The arguments against revocation support, as you've described them, seem to be: - it's complicated/messy/expensive to implement and/or execute - Kerberos doesn't need it, so why would we? I'm not sure why either of these arguments would justify the potential security hole that a lack of revocation represents, but I suppose a 'short enough' token lifespan could minimize that hole. But how short a span are you suggesting as being acceptable? The delay between when a user's access permissions change (whether roles, password or even account deactivation) and when the ticket reflects that change is my concern. The default in Keystone has been 24h, which is clearly too long. Something on the order of 5 minutes would be ideal, but then ticket issuance could become the bottleneck. Validity that's much longer could be a real problem, though. Maybe not at the cloud administration level, but for a given project I can imagine someone being fired and their access being revoked. How long is an acceptable period for that ticket to still be valid? How much damage could be done by someone who should no longer have access to an account if their access cannot be revoked, by anyone, at all? I realize that I had been thinking about the revocation list as something that needs to be broadcast. This is certainly not the case. A much better approach would be for the Keystone server to have a list of revoked tokens exposed in an URL. Then, as service like Glance or Nova can query the Revocation list on a simple schedule. The time out would be configurable, of course. There is a question about what to do if the keystone server cannot be reached during that interval. Since the current behavior is for authentication to fail, I suppose we would continue doing that, but also wait a random amount of time and then requery the Keystone server. In the future, I would like to make the set of Keystone servers a configurable list, and the policy for revocation checking should be able to vary per server: some Keystone servers in a federated approach might not be accessible. In those cases, it might be necessary for one Keystone server to proxy the revocation list for another server. Let me know if this scheme makes sense to you. If so, we can write it up as an additional blueprint. It should not be that hard to implement. I'm hearing that you, as the implementer of this feature, don't consider the lack of revocation to be an issue. What am I missing? Is support for revocation so repugnant that the potential security hole is preferable? I can see that from a developer's perspective, but I don't understand why someone deploying Keystone wouldn't avoid PKI tokens until revocation support became available. Thanks, Maru On 2012-08-01, at 9:47 PM, Adam Young wrote: On 08/01/2012 09:19 PM, Maru Newby wrote: I see that support for PKI Signed Tokens has been added to Keystone without support for token revocation. I tried to raise this issue on the bug report: https://bugs.launchpad.net/keystone/+bug/1003962/comments/4 And the review: https://review.openstack.org/#/c/7754/ I'm curious as to whether anybody shares my concern and if there is a specific reason why nobody responded to my question as to why revocation is not required for this new token scheme. Anybody? It was discussed back when I wrote the Blueprint. While it is possible to do revocations with PKI, it is expensive and requires a lot of extra checking. Revocation is a policy decision, and the assumption is that people that are going to use PKI tokens are comfortable with out revocation. Kerberos service tickets have the same limitation, and Kerberos has been in deployment that way for close to 25 years. Assuming that PKI ticket lifespan is short enough, revocation should not be required. What will be tricky is to balance the needs of long lived tokens (delayed operations, long running operations) against the needs for reasonable token timeout. PKI Token revocation would look like CRLs
Re: [Openstack] Keystone: 'PKI Signed Tokens' lack support for revocation
On 08/02/2012 01:56 AM, Joseph Heck wrote: Hey Maru, I think you're putting too many words in Adam's mouth here. First, Adam didnt assert is wasnt valuable, useful, or nessecary - simply that it wasnt in the first cut and not in the list that we agreed was critically essential to an initial implementation. As you noted, its a complex and somewhat tricky issue to get right. There's always room for more participation to correct the flaws you see in the existing system - the beauty of open source. I would love to see continued work on the signing and revocation work to drive in these features that mean so much to you. I'd be happy to open a blueprint if you can stand behind it, define what you think it required, and commit to the work to implement that revocation mechanism. Implying negative emotions on Adam's part when he's been one driving the implementation and doing the work is simply inappropriate. Please consider the blueprint route, definition of a viable solution, and work to make it happen instead of name calling and asserting how the developers doing the work are screwing up. Thanks for the support Joe. I don't think Maru was being too harsh. So long as he doesn't start calling me Sir as that is always an followed by you are making a scene. - joe On Aug 1, 2012, at 8:05 PM, Maru Newby mne...@internap.com mailto:mne...@internap.com wrote: Hi Adam, I apologize if my questions were answered before. I wasn't aware that what I perceive as a very serious security concern was openly discussed. The arguments against revocation support, as you've described them, seem to be: - it's complicated/messy/expensive to implement and/or execute - Kerberos doesn't need it, so why would we? I'm not sure why either of these arguments would justify the potential security hole that a lack of revocation represents, but I suppose a 'short enough' token lifespan could minimize that hole. But how short a span are you suggesting as being acceptable? The delay between when a user's access permissions change (whether roles, password or even account deactivation) and when the ticket reflects that change is my concern. The default in Keystone has been 24h, which is clearly too long. Something on the order of 5 minutes would be ideal, but then ticket issuance could become the bottleneck. Validity that's much longer could be a real problem, though. Maybe not at the cloud administration level, but for a given project I can imagine someone being fired and their access being revoked. How long is an acceptable period for that ticket to still be valid? How much damage could be done by someone who should no longer have access to an account if their access cannot be revoked, by anyone, at all? I'm hearing that you, as the implementer of this feature, don't consider the lack of revocation to be an issue. What am I missing? Is support for revocation so repugnant that the potential security hole is preferable? I can see that from a developer's perspective, but I don't understand why someone deploying Keystone wouldn't avoid PKI tokens until revocation support became available. I think you have valid concerns. Realistically, I think 5 minutes is too short, and for many operations, 24 hours would be the right granularity. However, The timespan of the tokens is configurable, and the policy of the deploying organization should dictate. Remember, this is the administrative interface for virtual machines, and not the applications running in them. Removing someone from access to creating/rebooting/destroying virtual machines is a much more deliberate decision than banning someone from a public forum. Aside from someone getting fired, I am not sure how essential it is that we have rapid revocation of tokens. And firing someone is usually part of the whole escort from the building routine. So, let me put the onus on you: make the argument for rapid revocation of tokens. Thanks, Maru On 2012-08-01, at 9:47 PM, Adam Young wrote: On 08/01/2012 09:19 PM, Maru Newby wrote: I see that support for PKI Signed Tokens has been added to Keystone without support for token revocation. I tried to raise this issue on the bug report: https://bugs.launchpad.net/keystone/+bug/1003962/comments/4 And the review: https://review.openstack.org/#/c/7754/ I'm curious as to whether anybody shares my concern and if there is a specific reason why nobody responded to my question as to why revocation is not required for this new token scheme. Anybody? It was discussed back when I wrote the Blueprint. While it is possible to do revocations with PKI, it is expensive and requires a lot of extra checking. Revocation is a policy decision, and the assumption is that people that are going to use PKI tokens are comfortable with out revocation. Kerberos service tickets have the same limitation, and Kerberos has been in deployment that way for close to 25
[Openstack] Fwd: Re: Keystone: 'PKI Signed Tokens' lack support for revocation
Origianlly respoded just to Christopher. Forwarding this on to a the main list. First of all, let me say thanks to everyone participating in the discussion. This is the only way we are going to identify all of the issues and come up with a decent implementation. I knew this would be a touchy subject when we first started designing it, and suspected that it would take some form of commit before the discussion hit the majority of the community. On 08/02/2012 02:20 PM, Christopher MacGown wrote: On Thursday, August 2, 2012 at 6:59 AM, Adam Young wrote: So, let me put the onus on you: make the argument for rapid revocation of tokens. If you are deploying OpenStack and providing access to third parties, and for whatever reason you terminate a relationship with that third party — whether they cancel, you've banned them, you've removed a user from a tenant/project — you want that third party to immediately lose access to whatever capability they had prior to that termination. Leaving non-affiliated users with access to resources is a serious security risk that would make OpenStack unusable in a regulated environment. In those cases, you probably want to continue on with online token checking, regardless of UUID/PKI. That ability will not go away. We probably do need a configuration option for auth_token that indicates whether it should verify with PKI or not, but my guess is that the real policy will be dictated by keystone. Perhaps what we really need is for the remote services to query this value from the keystone server. It could do the check when it origianally fetches certificates. The certificates themselves could be shorter lived (say 24 hours) and refreshed when they expire. Automatic Management of the certificates probably should also be configurable, with many organizations preferring to use Puppet etc. I suspect that we are going to want a more nuanced policy/mechanism long term, something along the lines of: Tenant specific PKI tickets are short lived, say 5 minutes. Non-tenant specific tickets are used to get tenant specific tickets. Long running tasks will call back to Keystone to verify ticket validity using UUID tokens. If we start doing something along the lines of Federation as I've started https://blueprints.launchpad.net/keystone/+spec/federation You would also have the option of revoking the signing certificate for a whole domain, which would be an effective way to deny access to a swath of people, say on a breach of contract. In large organziations, there is always going to be some non-zero delay between the decision to revocation authorization and the implementation of that decision. With LDAP replication, at a minimum you have the replication delay. The question is what that acceptable delay is in a given scenario. It may not be the same even for all use cases even in a large organization. -- Christopher MacGown, CTO Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (415) 300-0944 http://www.pistoncloud.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone: 'PKI Signed Tokens' lack support for revocation
On 08/01/2012 11:05 PM, Maru Newby wrote: Hi Adam, I apologize if my questions were answered before. I wasn't aware that what I perceive as a very serious security concern was openly discussed. The arguments against revocation support, as you've described them, seem to be: - it's complicated/messy/expensive to implement and/or execute - Kerberos doesn't need it, so why would we? I'm not sure why either of these arguments would justify the potential security hole that a lack of revocation represents, but I suppose a 'short enough' token lifespan could minimize that hole. But how short a span are you suggesting as being acceptable? The delay between when a user's access permissions change (whether roles, password or even account deactivation) and when the ticket reflects that change is my concern. The default in Keystone has been 24h, which is clearly too long. Something on the order of 5 minutes would be ideal, but then ticket issuance could become the bottleneck. Validity that's much longer could be a real problem, though. Maybe not at the cloud administration level, but for a given project I can imagine someone being fired and their access being revoked. How long is an acceptable period for that ticket to still be valid? How much damage could be done by someone who should no longer have access to an account if their access cannot be revoked, by anyone, at all? I realize that I had been thinking about the revocation list as something that needs to be broadcast. This is certainly not the case. A much better approach would be for the Keystone server to have a list of revoked tokens exposed in an URL. Then, as service like Glance or Nova can query the Revocation list on a simple schedule. The time out would be configurable, of course. There is a question about what to do if the keystone server cannot be reached during that interval. Since the current behavior is for authentication to fail, I suppose we would continue doing that, but also wait a random amount of time and then requery the Keystone server. In the future, I would like to make the set of Keystone servers a configurable list, and the policy for revocation checking should be able to vary per server: some Keystone servers in a federated approach might not be accessible. In those cases, it might be necessary for one Keystone server to proxy the revocation list for another server. Let me know if this scheme makes sense to you. If so, we can write it up as an additional blueprint. It should not be that hard to implement. I'm hearing that you, as the implementer of this feature, don't consider the lack of revocation to be an issue. What am I missing? Is support for revocation so repugnant that the potential security hole is preferable? I can see that from a developer's perspective, but I don't understand why someone deploying Keystone wouldn't avoid PKI tokens until revocation support became available. Thanks, Maru On 2012-08-01, at 9:47 PM, Adam Young wrote: On 08/01/2012 09:19 PM, Maru Newby wrote: I see that support for PKI Signed Tokens has been added to Keystone without support for token revocation. I tried to raise this issue on the bug report: https://bugs.launchpad.net/keystone/+bug/1003962/comments/4 And the review: https://review.openstack.org/#/c/7754/ I'm curious as to whether anybody shares my concern and if there is a specific reason why nobody responded to my question as to why revocation is not required for this new token scheme. Anybody? It was discussed back when I wrote the Blueprint. While it is possible to do revocations with PKI, it is expensive and requires a lot of extra checking. Revocation is a policy decision, and the assumption is that people that are going to use PKI tokens are comfortable with out revocation. Kerberos service tickets have the same limitation, and Kerberos has been in deployment that way for close to 25 years. Assuming that PKI ticket lifespan is short enough, revocation should not be required. What will be tricky is to balance the needs of long lived tokens (delayed operations, long running operations) against the needs for reasonable token timeout. PKI Token revocation would look like CRLs in the Certificate world. While they are used, they are clunky. Each time a token gets revoked, a blast message would have to go out to all registered parties informing them of the revocation. Keystone does not yet have a message queue interface, so doing that is prohibitive in the first implementation. Note that users can get disabled, and token chaining will no longer work: you won't be able to use a token to get a new token from Keystone. Thanks, Maru ___ Mailing list:https://launchpad.net/~openstack Post to :openstack@lists.launchpad.net Unsubscribe :https://launchpad.net/~openstack More help :https://help.launchpad.net
Re: [Openstack] Keystone: 'PKI Signed Tokens' lack support for revocation
On 08/01/2012 09:19 PM, Maru Newby wrote: I see that support for PKI Signed Tokens has been added to Keystone without support for token revocation. I tried to raise this issue on the bug report: https://bugs.launchpad.net/keystone/+bug/1003962/comments/4 And the review: https://review.openstack.org/#/c/7754/ I'm curious as to whether anybody shares my concern and if there is a specific reason why nobody responded to my question as to why revocation is not required for this new token scheme. Anybody? It was discussed back when I wrote the Blueprint. While it is possible to do revocations with PKI, it is expensive and requires a lot of extra checking. Revocation is a policy decision, and the assumption is that people that are going to use PKI tokens are comfortable with out revocation. Kerberos service tickets have the same limitation, and Kerberos has been in deployment that way for close to 25 years. Assuming that PKI ticket lifespan is short enough, revocation should not be required. What will be tricky is to balance the needs of long lived tokens (delayed operations, long running operations) against the needs for reasonable token timeout. PKI Token revocation would look like CRLs in the Certificate world. While they are used, they are clunky. Each time a token gets revoked, a blast message would have to go out to all registered parties informing them of the revocation. Keystone does not yet have a message queue interface, so doing that is prohibitive in the first implementation. Note that users can get disabled, and token chaining will no longer work: you won't be able to use a token to get a new token from Keystone. Thanks, Maru ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Hiding complexity of paste config files from operators
On 07/30/2012 05:12 AM, Thierry Carrez wrote: Lorin Hochstein wrote: I wanted to discuss the usability of the paste config files from an operator's point of view. The paste config files are opaque to administrators who are trying to stand an OpenStack cloud for the first time, since they expose a lot of implementation details about the middleware. I can follow the instructions in the Install and Deploy guide, but I have no idea what the options I don't edit are, and if the documentation has deviated from the implementation, I'm pretty much stuck. [...] This was mentioned in the Making configuration easier session on the DevOps track at the last design summit. You can find the notes at: http://etherpad.openstack.org/FolsomMakingConfigurationEasier In particular, it was identified that paste configs were evil, failing to properly separate service/code configuration from end-user configuration. Assuming that the *-paste.ini files always need to be there, is there some way we could avoid requiring admins to edit these files, and instead make it more like editing the .conf files? For example, could the paste.ini files be generated from the corresponding .conf file as needed? I would not assume that *-paste.ini files always need to be there... Paste is a pain point if we are to support Python 3 one day, so it's also on the black list of the (still inexistant) OpenStack Python3 advocacy group. So I'd rather investigate a solution that solves our two problems, rather than adding a layer on top of the current broken solution... That said I'm not really a specialist of Paste alternatives. It seems to me that there is nothing that you can do in Paste that you cannot do in straight python. THe advantage of Paste is hat it is viewed as a Config file, not as code and thus is a file that end system administrators can use. A paste file is nothing more than an assignment to a variable name from a string that is done at run time. For example, the Keystone config file has a paste fragment in it: [app:public_version_service] paste.app_factory = keystone.service:public_version_app_factory This same code could be performed inside the Python code base with pretty much the same code interpred as Python. The issue is that we would then want to allow a value such as this to be overridden: For example, specifying the driver for the token api is done: [token] driver = keystone.token.backends.kvs.Token Since most of these cases have reasonable defaults, they should be left out of the paste files. What needs to be available is solid documentation of the values that can be overridden this way. Any keys that are not defaulted, but are not really designed to be overloaded should be modified so that they are defaulted, and then the keys removed from the paste file. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keyring support in openstack
On 07/30/2012 05:17 PM, Kevin L. Mitchell wrote: On Mon, 2012-07-30 at 13:50 -0700, Bhuvaneswaran A wrote: The wiki mentions the password being saved using keyring.backend.UncryptedFileKeyring. Does that mean the password is saved in cleartext? Is the file protected in some way besides filesystem permissions? As mentioned in wiki page, the password is stored in base64 format. Which means it's stored in cleartext. That is Not Good(tm) :) Can Keyring be used to store a token instead? That would A) be better than password and B) avoid a Keystone hit. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Performing HPCC Benchmark on OpenStack Cloud
On 07/30/2012 10:22 AM, Reza Bakhshayeshi wrote: Hi I want to run HPCC benchmark on OpenStack cloud, I want you to help me to make the results more real. How can we impute the results to OpenStack and not to my computers? Do I really need a server farm to perform the test? And I think I have to run for example HPL on running instances and not on the main servers, is this correct? Please suggest me more rules and conditions. Best Regards ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp You need to to an apples-to-apples comparison. Using the same hardware, and a different deployment mechanism, perhaps Rocks. https://wiki.rocksclusters.org/wiki/index.php/Main_Page You need a low latency interconnect, like Infiniband in order for the results to really mean much more than Yes it runs. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keyring support in openstack
On 07/30/2012 06:00 PM, Doug Hellmann wrote: On Mon, Jul 30, 2012 at 5:30 PM, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 07/30/2012 05:17 PM, Kevin L. Mitchell wrote: On Mon, 2012-07-30 at 13:50 -0700, Bhuvaneswaran A wrote: The wiki mentions the password being saved using keyring.backend.UncryptedFileKeyring. Does that mean the password is saved in cleartext? Is the file protected in some way besides filesystem permissions? As mentioned in wiki page, the password is stored in base64 format. Which means it's stored in cleartext. That is Not Good(tm) :) Can Keyring be used to store a token instead? That would A) be better than password and B) avoid a Keystone hit. Don't tokens expire? Yes, they do, but that is no reason not to put them in the keyring, With the PKI tokens, you will be able to query a token's expiry without going across the wire. Doug ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [keystone] Multi-tenants per user, authentication tokens and global roles
On 07/26/2012 08:30 PM, Ryan Lane wrote: I'm working on upgrading to essex, which means I need to start using keystone. My use case seems to not fit keystone very well, though... In my environment, one user can be a member of many projects (some users are in up to 20-30 projects). Management of projects is done nearly completely though the web interface, and users may work on resources in multiple projects at the same time. Our web interface can show all or a subset of user's project's resources in the same view. In Nova, using the EC2 API, I could query all resources for a user on their behalf using an admin user, or I could use their access/secret key and change the tenant for requesting each project. From what I can tell in Keystone, when a user authenticates, they get a token directly linked with a tenant. If I want to do API calls on a user's behalf in a tenant, I must authenticate them for that tenant. It seems there's no way for me to make requests on a user's behalf for multiple projects without authenticating them for every single tenant. Is this the case? Is there any way for me to handle this? I'd really like to avoid authenticating a user 30 times on login, then needing to store all 30 of their tokens. Not in Essex. When we discussed the Domains blueprint, one issue that I brought up was nested groups/projects. That would solve your problem. It is not currently being developed. I have another issue as well. My environment is meant to be integrated and more of a private-style cloud. We have a group of administrators that should be able to manage all instances, networks, etc. In Nova's auth there were global groups. In Keystone there are no global groups. Will this ever be added into keystone? It's really annoying to need to constantly add/remove ourselves from projects to manage them. Again, this is really a group nesting problem. I am not sure if the domain blueprint would help you out here: https://review.openstack.org/#/c/8114/ https://blueprints.launchpad.net/keystone/+spec/keystone-domains http://etherpad.openstack.org/keystone-domains - Ryan ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone] Quotas: LDAP Help
On 07/25/2012 10:19 AM, Ionuț Arțăriși wrote: On 07/17/2012 11:33 PM, Joseph Heck wrote: That's the general area I was going to head with the Active Directory backend I'm hacking on. Chris Hoge of UOregon presented today (@ OSCON) on a local keystone hack that they did to enable LDAP AuthN + a fail back to SQL based system for their scientific computing cluster - follows a very similar model. -joe On Jul 17, 2012, at 2:16 PM, Tim Bell tim.b...@cern.ch wrote: +1 The corporate LDAP should be read-only for a source of user, roles and attributes. Updating the corporate LDAP is not an option in many environments which can significantly benefit from the structured directory information available. Thus, at minimum, allow a r/o LDAP and local DB store for any openstack specific information that needs updating. Tim -Original Message- From: openstack-bounces+tim.bell=cern...@lists.launchpad.net [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf Of Ryan Lane Sent: 17 July 2012 20:43 To: Adam Young Cc: Joseph Heck; openstack Subject: Re: [Openstack] [Keystone] Quotas: LDAP Help I haven't been thinking about quotas, so bear with me here. A few thoughts: Certain deployments might not be able to touch the LDAP backend. I am thinking specifically where there is a corporate AD/LDAP server. I tried to keep the scheme dependency simple enough that it could be layered onto a read-only scenario. If we put quotas into LDAP, it might break on those deployments. Many, many deployments won't be able to. Applications should generally assume they are read-only in regards to LDAP. I can see that we don't want to define them in the Nova database, as Swift might not have access to that, and swift is going to be one of the primary consumers of Quotas. I am Assuming Quantum will have them as well. As you are aware, there is no metadata storage in the LDAP driver, instead it is generated from the tenant and role information on the fly. There is no place to store metadata in groupOfNames which is the lowest( common denominator) grouping used for Tenants. Probably the most correct thing to do would be to use a seeAlso that points to where the quota data is stored. Let's try not to force things into attributes if possible. When LDAP is used, is the SQL backend not used at all? Why not store quota info in Keystone's SQL backend, but pull user info from LDAP, when enabled? We should only consider storing something in LDAP if it's going to be reused by other applications. LDAP has a strict schema for exactly this purpose. If the quota information isn't directly usable by other applications we shouldn't store it in LDAP. Many applications with an LDAP backend also have an SQL backend, and use the SQL as primary storage for most things, and as a cache for LDAP, if it's used. I think this is likely a sane approach here, as well. - Ryan ___ Hi, I just wanted to add a bit to this thread. We're currently working on a hybrid backend between LDAP and SQL. I have a working version for a specific setup in which the user accounts are stored in LDAP, but tenants and roles are all stored in SQL together with other openstack user accounts such as the nova admin account. I basically just Frankensteined the two backends together for user processing and left everything else to be handled by the SQL backend. I'd like to hear other people's opinion on this or alternative implementations. Are tenants completely in the SQL DB? If so, how to you list tenants for a given user? Do you copy users from LDAP to SQL for anything? https://gist.github.com/3176390 -Ionuț ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] 回复： Keystone client could not behave well, call for help
On 07/22/2012 09:12 AM, 延生 付 wrote: reply: 'HTTP/1.1 503 Service Unavailable\r\n' This seems to be the main problem. The error message /string indices must be integers, not str /seems to be a bug in trying to parse the error page. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Identity API v3 - Why allow multi-tenant users?
The idea of a Domain is that it is a single administrative entity, such as a company. When a person joins a company, they get an email adddress. THat address does not change regardless of the position they hold. Tenants are administrative groupings below that. It is unfortunate that we used the name tenants for this, as it actually contradicts the usual meaning of the term. We will be shortly switching back to using the term projects, and I think that is clearer. It certainly makes sense for a user to belong to one domain, but have access to a project controlled in another domain. Here is a scenario. Joe's Sporting Goods and Local Bank are both companies that have a presense in a coud provider. Each has their own domain. t...@localbank.com is going to set up a Point of Sale system for Joe. So Joe creates a project called joes-point-of-sale and provides access to user t...@localbank.com. On 07/18/2012 02:46 AM, Matt Joyce wrote: I could see service users and security / operations teams having a need to span many domains. -Matt On Tue, Jul 17, 2012 at 11:24 PM, Tim Bell tim.b...@cern.ch mailto:tim.b...@cern.ch wrote: I thought that the v3 API supports domains as a group of tenants which would make the question rather different. Thus, I guess the question is A.Should there be users in multiple tenants in a single domain ? B.Should there be users in multiple domains ? There are clear use cases for A (such as researchers working on multiple projects sharing project quotas) For B, it is less clear as if I am a domain administrator, I do not want to be told that I cannot allocate user X since another domain has already taken it. On the other hand, there is a clear architectural benefit from having the concept of identity (and authentication) split off from roles and projects. Tim *From:*openstack-bounces+tim.bell=cern...@lists.launchpad.net mailto:cern...@lists.launchpad.net [mailto:openstack-bounces+tim.bell mailto:openstack-bounces%2Btim.bell=cern...@lists.launchpad.net mailto:cern...@lists.launchpad.net] *On Behalf Of *John Postlethwait *Sent:* 18 July 2012 07:42 *To:* Rouault, Jason (Cloud Services) *Cc:* openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] Identity API v3 - Why allow multi-tenant users? Forcing a user to remember different usernames and/or passwords for each project they are a part of, when it is possible they are part of N projects, really isn't an acceptable option in my opinion. I believe that regardless of the engineering complexities, the end users shouldn't have to feel pain in order to make engineering the solutions and features they interact with easier. Software is for end users (in their various forms) and as such we need to take that into account when we make decisions. While no functionality is lost per se, there is a major end-user impact, and that should be reason enough to implement it... John Postlethwait Nebula, Inc. 206-999-4492 tel:206-999-4492 On Tuesday, July 17, 2012 at 4:15 PM, Rouault, Jason (Cloud Services) wrote: One benefit is the user does not need to have multiple sets of credentials to interact with multiple projects. Jason *From:*openstack-bounces+jason.rouault=hp@lists.launchpad.net mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net mailto:hp@lists.launchpad.net] *On Behalf Of *Adam Young *Sent:* Tuesday, July 17, 2012 11:55 AM *To:* openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] Identity API v3 - Why allow multi-tenant users? On 05/29/2012 01:18 PM, Caitlin Bestler wrote: One of the major complication I see in the API is that users can be associated with multiple tenants. What is the benefit of this? What functionality would be lost if a human user merely had to use a different account with each tenant? There are numerous issues with multi-tenant users. For example, if a user is associated with multiple tenants, who resets the user's password? ___ Mailing list:https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to :openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe :https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help :https://help.launchpad.net/ListHelp Did you ever get an answer? This has been discussed in depth
Re: [Openstack] Change user password (not admin)
On 06/06/2012 07:24 PM, Sam Morrison wrote: Hi, There has been a first attempt at this in keystone. See https://review.openstack.org/#/c/7437/ And bug: https://bugs.launchpad.net/keystone/+bug/996922 It needs more work to make it secure though. WHat do you think it needs? Please open a bug report. We will try to incorperate into the next API. Cheers, Sam On Thu, Jun 7, 2012 at 7:13 AM, Kiall Mac Innes ki...@managedit.ie wrote: On Wed, Jun 6, 2012 at 7:55 PM, Gabriel Hurley gabriel.hur...@nebula.com wrote: Feel free to have at it with them again. ;-) Feel free to add my +1 next time it comes up! Users being unable to change their own passwords simply seems wrong to me! Thanks, Kiall ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] enforce admin_required with LDAP admin user
You need an admin token and to go against port 35357 for those types of
operations. A basic user does not have permission to do so. It has
nothing to do with LDAP.
On 05/22/2012 11:47 AM, Sharif Islam wrote:
I think my LDAP bind is working by tenant-list and user-list gives me
admin_required error.
Looks like the LDAP admin user does not have any roles. is that the issue?
# keystone discover
Keystone found at http://localhost:5000/v2.0/
- supports version v2.0 (beta) here http://149.165.159.121:5000/v2.0/
root@i121:~# keystone service-list
++--+--+-+
| id | name | type | description |
++--+--+-+
++--+--+-+
root@i121:~# keystone user-list
No handlers could be found for logger keystoneclient.client
You are not authorized to perform the requested action: admin_required
(HTTP 403)
root@i121:~# keystone tenant-list
No handlers could be found for logger keystoneclient.client
You are not authorized to perform the requested action: admin_required
(HTTP 403)
keystone.common.ldap.core): 2012-05-22 11:36:02,263 DEBUG LDAP init:
url=ldap://ldap.project.org
(keystone.common.ldap.core): 2012-05-22 11:36:02,263 DEBUG LDAP bind:
dn=uid=user,ou=People,dc=project,dc=org
(keystone.common.ldap.core): 2012-05-22 11:36:02,271 DEBUG LDAP search:
dn=ou=ostenants,dc=project,dc=org, scope=1,
query=((member=uid=admin,ou=People,dc=project,dc=org)(objectClass=groupOfNames))
(root): 2012-05-22 11:36:02,425 DEBUG TOKEN_REF {'id':
'dfc4b2ecexxxd014x280d91efeecda06', 'expires': datetime.datetime(2012, 5, 23,
15, 36, 2, 274565), 'user': {'id': 'admin', 'name': 'admin'}, 'tenant': {'id':
'admin', 'name': 'admin'}, 'metadata': {}}
(eventlet.wsgi.server): 2012-05-22 11:36:02,426 DEBUG 127.0.0.1 - - [22/May/2012
11:36:02] POST /v2.0/tokens HTTP/1.1 200 1762 0.166139
(keystone.policy.backends.rules): 2012-05-22 11:36:02,439 DEBUG enforce
admin_required: {'tenant_id': u'admin', 'user_id': u'admin', 'roles': []}
--sharif
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] debugging a db migration script
On 07/16/2012 11:59 PM, Jim Fehlig wrote: I'm working on a patch that adds a column to the compute_nodes table in the nova db, but it seems my db migration script fails when calling 'db sync' in stack.sh. I tried running the command manually, same failure: stack@virt71:~ /opt/stack/nova/bin/nova-manage --debug -v db sync2012-07-16 21:42:52 DEBUG nova.utils [-] backend module 'nova.db.sqlalchemy.migration' from '/opt/stack/nova/nova/db/sqlalchemy/migration.pyc' from (pid=19230) __get_backend /opt/stack/nova/nova/utils.py:484 /usr/lib64/python2.6/site-packages/sqlalchemy/pool.py:681: SADeprecationWarning: The 'listeners' argument to Pool (and create_engine()) is deprecated. Use event.listen(). Pool.__init__(self, creator, **kw) /usr/lib64/python2.6/site-packages/sqlalchemy/pool.py:159: SADeprecationWarning: Pool.add_listener is deprecated. Use event.listen() self.add_listener(l) Command failed, please check log for more info I can't find anything useful in any log (/var/log/*, /opt/stack/log/*). I ran the above in strace and saw my migration script was opened and then shortly thereafter writing of Command failed, please check log for more info and exit(1) :). The patch also adds a 'hypervisor_type' column to the instances table, and that migration script succeeds! Any hints for debugging a db migration script? Thanks, Jim ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp I just went through this with a Keystone change. What I would suggest is: 1. Get a blank Database. 2. Run the DB migration without your scripts. 3. Get the SQL you want to run to work correctly from that step. 4. Add in a Database appropriate SQL script that has exactly your SQL from above. 5. Run the whole migration. Yes, it is a labor intensive and painful as it sounds. You want to make sure that you have exactly the preconditions that your script expects. What I had to do was actually go back and modify earlier DB init code due to the SQL alchemy column definition changing. Note this change: https://review.openstack.org/#/c/7754/9/keystone/common/sql/migrate_repo/versions/001_add_initial_tables.py I now have to explicitly create the token table to make sure it is the state it would be today. Since my code had modified the token table, had I not done this, by the end of stage 1 SQL processing, the database would have had this table in stage 2 state. Then I Went and added a SQL script for modifying the table. Since I was altering a a table without dumping the data in it, it was a non-trivial change that SQL Alchemy couldn't handl (AFAICT). Instead, I added a SQL script: https://review.openstack.org/#/c/7754/9/keystone/common/sql/migrate_repo/versions/002_mysql_upgrade.sql Make sure you have a comparable Downgrade script, too. https://review.openstack.org/#/c/7754/9/keystone/common/sql/migrate_repo/versions/002_mysql_downgrade.sql For Keystone, we run the upgrade using a stand alone executable keystone/bin/keystone-manage. In nove, it looks like there is bin/nova-manage to do the same thing. I am running using Eclipse and PyDev as my development environment, and using the integrated debugger to step through the code. Makes it a lot less painful to debug. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone] Quotas: LDAP Help
On 07/17/2012 11:18 AM, Everett Toews wrote: On Mon, Jul 16, 2012 at 7:20 PM, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: Usually a Quota is a limitation on a resource. I suspect that the problem here is we have not nailed down the resource objects that you would then apply a quota to. If, for example, we were talking about disk quotas, we could look at the LDAP schema's that are in place for disks, automount, and so forth. For network or CPU quotas, the concepts don't really exist. My immediate thought is that maybe these things are not really Keystone quantities to manage. Nova has the database that deals with the actual quantities of disk and so forth. BUt I know that LDAP is the system of record for Hosts in many systems, so the Data from LDAP needs to feed into Nova somehow I led the session on quotas at the Folsom Summit where the consensus was that, because this data was tied to Tenants, it should be stored in Keystone. We've also discussed it on the mailing list at http://markmail.org/message/vlk6otl2yggjeouc and http://markmail.org/message/7agsnjo3n4il56ar (where you'll find links to the Summit etherpad, spec, and blueprint). I searched around a bit for an objectclass that handled generic quotas but couldn't find one. I really wouldn't want us to write our own objectclass either as it's simply not flexible enough. I don't think we want to necessarily nail down the resource objects we want to apply a quota to. Each OpenStack project is going to need its own quotas and I suspect there are going to be many additions to those quotas over the next 2 years so we something that can handle anything. If we just store some JSON in the backend then that will meet our needs nicely. This is how metadata is stored in the SQL backend. I simply reused that and it was pretty effective. Can you post your code to a GIthub repo and send out a link to the commit so that I could take a look? It would be much more clear to discuss with actual code in front of me. My branch is at https://github.com/everett-toews/keystone/tree/quotas The SQL implementation is at https://github.com/everett-toews/keystone/blob/quotas/keystone/identity/backends/sql.py Everett I haven't been thinking about quotas, so bear with me here. A few thoughts: Certain deployments might not be able to touch the LDAP backend. I am thinking specifically where there is a corporate AD/LDAP server. I tried to keep the scheme dependency simple enough that it could be layered onto a read-only scenario. If we put quotas into LDAP, it might break on those deployments. I'm trying to get an approach to Federation and delegation for Keystone. Imagine where a company has a signing certificate that allows it validate the users for only their own tenancy. In these cases, the end user organization then would have the ability to control their own quotas. One reason to do the PKI signed tokens was to minimize the number of calls going to Keystone. This adds yet another one. The quotas could be added to the signed auth token, but it is already huge, I'd hate to cram more data in there. A serialized object block defers a lot of problems, but they will bite us later. For example, there is already a ticket for enabled which does not have the text string normalized. Doing one for Quotas misses validation of both resource names and the units used. For example, are disk quotas in bytes, megabytes, or Gigs? Are all of those acceptable? If so, how do we define which one to use. I realize you might have nailed this down in your code, or at least design, but then the code is the contract. This design seems to address some of those issues. http://wiki.openstack.org/Boson I can see that we don't want to define them in the Nova database, as Swift might not have access to that, and swift is going to be one of the primary consumers of Quotas. I am Assuming Quantum will have them as well. As you are aware, there is no metadata storage in the LDAP driver, instead it is generated from the tenant and role information on the fly. There is no place to store metadata in groupOfNames which is the lowest( common denominator) grouping used for Tenants. Probably the most correct thing to do would be to use a seeAlso that points to where the quota data is stored. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] debugging a db migration script
On 07/17/2012 11:42 AM, Jim Fehlig wrote: Hengqing Hu wrote: There is a test in nova: You can run run_tests.sh in your nova root like this: ./run_tests.sh -v test_migrations Thanks for the tip! To set a breakpoint, you can either run python -m pdb run_tests.py or modify your code and put in : import pdb; pdb.set_trace() If there is something wrong in the migration script, it will show up in the console. Indeed. And easy to fix problems once you know the errors :). Regards, Jim On 07/17/2012 11:59 AM, Jim Fehlig wrote: I'm working on a patch that adds a column to the compute_nodes table in the nova db, but it seems my db migration script fails when calling 'db sync' in stack.sh. I tried running the command manually, same failure: stack@virt71:~ /opt/stack/nova/bin/nova-manage --debug -v db sync2012-07-16 21:42:52 DEBUG nova.utils [-] backend module 'nova.db.sqlalchemy.migration' from '/opt/stack/nova/nova/db/sqlalchemy/migration.pyc' from (pid=19230) __get_backend /opt/stack/nova/nova/utils.py:484 /usr/lib64/python2.6/site-packages/sqlalchemy/pool.py:681: SADeprecationWarning: The 'listeners' argument to Pool (and create_engine()) is deprecated. Use event.listen(). Pool.__init__(self, creator, **kw) /usr/lib64/python2.6/site-packages/sqlalchemy/pool.py:159: SADeprecationWarning: Pool.add_listener is deprecated. Use event.listen() self.add_listener(l) Command failed, please check log for more info I can't find anything useful in any log (/var/log/*, /opt/stack/log/*). I ran the above in strace and saw my migration script was opened and then shortly thereafter writing of Command failed, please check log for more info and exit(1) :). The patch also adds a 'hypervisor_type' column to the instances table, and that migration script succeeds! Any hints for debugging a db migration script? Thanks, Jim ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Identity API v3 - Why allow multi-tenant users?
On 05/29/2012 01:18 PM, Caitlin Bestler wrote: One of the major complication I see in the API is that users can be associated with multiple tenants. What is the benefit of this? What functionality would be lost if a human user merely had to use a different account with each tenant? There are numerous issues with multi-tenant users. For example, if a user is associated with multiple tenants, who resets the user's password? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Did you ever get an answer? This has been discussed in depth. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone] Quotas: LDAP Help
On 07/17/2012 02:42 PM, Ryan Lane wrote: I haven't been thinking about quotas, so bear with me here. A few thoughts: Certain deployments might not be able to touch the LDAP backend. I am thinking specifically where there is a corporate AD/LDAP server. I tried to keep the scheme dependency simple enough that it could be layered onto a read-only scenario. If we put quotas into LDAP, it might break on those deployments. Many, many deployments won't be able to. Applications should generally assume they are read-only in regards to LDAP. I can see that we don't want to define them in the Nova database, as Swift might not have access to that, and swift is going to be one of the primary consumers of Quotas. I am Assuming Quantum will have them as well. As you are aware, there is no metadata storage in the LDAP driver, instead it is generated from the tenant and role information on the fly. There is no place to store metadata in groupOfNames which is the lowest( common denominator) grouping used for Tenants. Probably the most correct thing to do would be to use a seeAlso that points to where the quota data is stored. Let's try not to force things into attributes if possible. When LDAP is used, is the SQL backend not used at all? Why not store quota info in Keystone's SQL backend, but pull user info from LDAP, when enabled? We should only consider storing something in LDAP if it's going to be reused by other applications. LDAP has a strict schema for exactly this purpose. If the quota information isn't directly usable by other applications we shouldn't store it in LDAP. Many applications with an LDAP backend also have an SQL backend, and use the SQL as primary storage for most things, and as a cache for LDAP, if it's used. I think this is likely a sane approach here, as well. - Ryan Yes, it is possible to use LDAP for Identity and SQL for the other things, like Tokens and Policy. Quotas could be done the same way. You just have to extract the Quotas calls out of the Identity Provider. It might make sense to go in Policy, or into its own driver. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [INTERNAL ONLY (NDA)] Fwd: Reqs for OpenStack from Intel IT - Redhat/OpenStack discussions
On 07/17/2012 02:53 PM, Adam Young wrote: On 07/17/2012 02:01 PM, Perry Myers wrote: CONFIDENTIAL/INTERNAL ONLY (NDA) Please do not forward this spreadsheet outside of this list. Please do not talk about any of these features externally as Something Intel has asked for. We can talk about the features themselves upstream, but the context of Intel asking for them needs to be kept internal. I'd like to get input from the team on the contents of this spreadsheet. Specifically for each item here, I think we need to know things like: * already a blueprint or launchpad bug for this? Link please * feasibility/complexity of the change (e.g. could be done for Folsom Milestone 3, needs to be deferred to 'G', probably not even possible in 'G', never going to happen) Basically this list constitutes what Intel believes needs to be closed from a feature gap perspective, to make OpenStack ready for the enterprise. And we need to be able to go back to them next week with our thoughts on each of these items. I don't think that we'd be expected to bear the development load of all of this, but we'll need to be Intel's advocates here in terms of upstream engagement. Respond with thoughts via email on this thread and then once we've gotten enough information captured, I can synthesize and put into the spreadsheet so that Mark and I can go back to Intel to provide them with feedback. Perry line 16 jumps out at me: TLS everywhere. The thing is, Eventlet with SSL doesn't make sense, so what should we do for a default? One bug here: https://bugs.launchpad.net/python-keystoneclient/+bug/1012591/ I have a Patch in for Keystone HTTPD: https://review.openstack.org/#/c/9735/ line 19 On Federation...I have some ideas WRT Keystone and signing certs. I'll write up my ideas in their own document. line 20: Multifactor is already on the bug list. Make that Blueprint: https://blueprints.launchpad.net/keystone/+spec/multi-factor-authn line 21 RBAC seems to be stalled. I can ping the driver behind it to see where we are. https://blueprints.launchpad.net/keystone/+spec/rbac-keystone http://etherpad.openstack.org/FolsomRBAC line 22 Quota Support: I was just looking into it. There is a patch brewing for the SQL backends, but there is no clear way to map it to LDAP. Not sure I agree that it should be per user: the discussion at the summit started off with per user and then dropped it. http://etherpad.openstack.org/SwiftQuotas http://markmail.org/message/7agsnjo3n4il56ar https://blueprints.launchpad.net/keystone/+spec/store-quota-data line 14 OpenID That is a one solution to SSO, but not necessarily a good one. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone] API Question
On 07/17/2012 03:47 PM, Matt Joyce wrote: As a non admin user. Querying the keystone v2 API is there a way for me to get a list of the tenants that I am a member of? Or is that only a v3 thing? -Matt I was just looking into it, and there is no such API yet. The underlying Identity provider call is get_tenants_for_user and there does not seem to be a route set up that calls that. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone] API Question
On 07/17/2012 03:55 PM, Matt Joyce wrote: On Tue, Jul 17, 2012 at 12:55 PM, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 07/17/2012 03:47 PM, Matt Joyce wrote: As a non admin user. Querying the keystone v2 API is there a way for me to get a list of the tenants that I am a member of? Or is that only a v3 thing? -Matt I was just looking into it, and there is no such API yet. The underlying Identity provider call is get_tenants_for_user and there does not seem to be a route set up that calls that. 8( --- sad panda face. That would have been a very useful call for me right now. I hope we have something by folsom ( albeit s/tenant/project/ig ) -Matt You can try this one out: https://github.com/admiyo/keystone/commit/997f9cb76fa908afebf434bef4905add085823ca ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone] API Question
On 07/17/2012 04:05 PM, Matt Joyce wrote: curl -H X-Auth-Token:123456789001234http://localhost:5000/v2.0/tenants that seems to do the trick for me for now. Ah, I see that is hooked up to: get_tenants_for_token, I was looking for the wrong API. That then calls: tenant_ids = self.identity_api.get_tenants_for_user(context, user_ref['id']) I'm not sure that this is the right semantics for it, but it looks like it does what you want. On Tue, Jul 17, 2012 at 1:03 PM, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 07/17/2012 03:55 PM, Matt Joyce wrote: On Tue, Jul 17, 2012 at 12:55 PM, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 07/17/2012 03:47 PM, Matt Joyce wrote: As a non admin user. Querying the keystone v2 API is there a way for me to get a list of the tenants that I am a member of? Or is that only a v3 thing? -Matt I was just looking into it, and there is no such API yet. The underlying Identity provider call is get_tenants_for_user and there does not seem to be a route set up that calls that. 8( --- sad panda face. That would have been a very useful call for me right now. I hope we have something by folsom ( albeit s/tenant/project/ig ) -Matt You can try this one out: https://github.com/admiyo/keystone/commit/997f9cb76fa908afebf434bef4905add085823ca ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone] API Question
On 07/17/2012 06:06 PM, Matt Joyce wrote:
Anyone by any chance know how to read out the auth_token or raw_token
that is acquired in keystoneclient when it performs a client.Client()
Authenticate?
The token is just a UUID, randomly generated.
In the PKI proposal, it is a base64 encoding of a Signed document in CMS
format.
I'd love to be able to read that. And it's totally not documented
anywhere if it exists.
-Matt
On Tue, Jul 17, 2012 at 2:19 PM, Matt Joyce
matt.jo...@cloudscaling.com mailto:matt.jo...@cloudscaling.com wrote:
Works for me. =D
On Tue, Jul 17, 2012 at 1:51 PM, Dolph Mathews
dolph.math...@gmail.com mailto:dolph.math...@gmail.com wrote:
Adam speaks lies ;)
Here's a regular user requesting a list of tenants on port
5000 (notice they only get back 1 tenant):
GET http://localhost:5000/v2.0/tenants
==
X-Auth-Token: a6094f62e38c4fafa57e6edf7bd04961
200 OK
==
Status: 200
Content-Length: 133
Content-Location: http://localhost:5000/v2.0/tenants
Vary: X-Auth-Token
Date: Tue, 17 Jul 2012 20:49:16 GMT
Content-Type: application/json
{
tenants: [
{
enabled: true,
description: null,
name: my-project,
id: 2cf2efb1da5c4d5b8c97d8055ff3b5d8
}
],
tenants_links: []
}
Here's an admin API call for all tenants in the system (notice
there is an additional tenant the above user did not have
access to):
GET http://localhost:35357/v2.0/tenants
===
X-Auth-Token: ADMIN
200 OK
==
Status: 200
Content-Length: 236
Content-Location: http://localhost:35357/v2.0/tenants
Vary: X-Auth-Token
Date: Tue, 17 Jul 2012 20:49:22 GMT
Content-Type: application/json
{
tenants: [
{
enabled: true,
description: null,
name: my-project,
id: 2cf2efb1da5c4d5b8c97d8055ff3b5d8
},
{
enabled: true,
description: null,
name: project-x,
id: 1213c2511f364264b1dfea9a56a225e0
}
],
tenants_links: []
}
-Dolph
On Tue, Jul 17, 2012 at 2:55 PM, Matt Joyce
matt.jo...@cloudscaling.com
mailto:matt.jo...@cloudscaling.com wrote:
On Tue, Jul 17, 2012 at 12:55 PM, Adam Young
ayo...@redhat.com mailto:ayo...@redhat.com wrote:
On 07/17/2012 03:47 PM, Matt Joyce wrote:
As a non admin user. Querying the keystone v2 API
is there a way for me to get a list of the tenants
that I am a member of? Or is that only a v3 thing?
-Matt
I was just looking into it, and there is no such API
yet. The underlying Identity provider call is
get_tenants_for_user and there does not seem to be a
route set up that calls that.
8( --- sad panda face.
That would have been a very useful call for me right now.
I hope we have something by folsom ( albeit
s/tenant/project/ig )
-Matt
___
Mailing list: https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
Post to : openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Routing ReST API Calls by URL
On 07/13/2012 05:39 PM, Nathanael Burton wrote: Dan, Adam Young was advocating for something like this. I don't know if a consensus was ever reached, but I thought it was a good idea. https://lists.launchpad.net/openstack/msg10864.html Nate Dan, Here's my proposed scheme. http://wiki.openstack.org/URLs I have submitted a patch for running Keystone in Apache: https://review.openstack.org/#/c/9735/ This assumes that you put admin on https://hostname/admin and so on. For Nova, there is a pretty good write up here: http://www.rackspace.com/blog/enabling-ssl-for-the-openstack-api/ Which pretty much takes the same approach. Glance needs some work to fit into that scheme, too, as I recall. The Client pieces need to be flexible enough to call with the suburls. For example, look at this patch: https://review.openstack.org/#/c/7156/ On Jul 13, 2012 5:31 PM, Dan Sneddon d...@cloudscaling.com mailto:d...@cloudscaling.com wrote: I am attempting to find a workable solution for the following use case, and would like to get feedback from the community about it. There are some situations when it is required to put a proxy in front of multiple API endpoints and route by URL. This allows for more flexible routing/filtering in load balancers and firewalls, and makes it possible to differentiate between services in unified HTTP logs. In the current OpenStack model a typical API endpoint looks something like this: http(s)://hostname:port/api version/account/container/object In essence, separate services have similar URLs, and are separated by the port number. It is difficult to use a request-header-aware proxy to route to a particular endpoint, since there is no clear differentiation between service URLs if the hostname and port are the same. With standard HTTP, this can be handled by using several different hostnames pointing to the same IP. This is particularly a problem with SSL certificates, which need to match the hostname. If the URLs contained a service identifier at the beginning of the URL, this would allow a proxy to make decisions about where to route requests based on the beginning of the URL, for example the URL above would become: http(s)://hostname:port/service/api version/account/container/object e.g. https://api-host:443/compute/v2.0/... https://api-host:443/auth/v2.0/... etc. It seems that the API services are compatible with this through the use of the urlmap configuration by including both versions of the URL: [composite:osapi_compute] use = call:nova.api.openstack.urlmap:urlmap_factory /: oscomputeversions /v1.1: openstack_compute_api_v2 /v2: openstack_compute_api_v2 /compute/: oscomputeversions /compute/v1.1: openstack_compute_api_v2 /compute/v2: openstack_compute_api_v2 Is allowing both forms of this URL in all services likely to break anything down the line? Does this seem like a common enough use case that it should be considered as an addition to the default configuration? Also, as services change (such as nova-volume being replaced by cinder) is there a set of generic service descriptors defined that can be used to abstract from the particular name of the service? Some of these are obvious, like network, but it would be nice to be consistent across versions and instances. Thank you for your feedback, -- Dan Sneddon Senior Engineer, Cloudscaling d...@cloudscaling.com mailto:d...@cloudscaling.com - @dxs on Twitter ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] UnifiedCLI suggestion
On 06/28/2012 11:54 AM, Dean Troyer wrote: On Mon, Jun 25, 2012 at 5:28 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Mon, Jun 25, 2012 at 6:19 PM, Ken Thomas k...@yahoo-inc.com wrote: [...] I've already submitted the keystone changes for review (https://review.openstack.org/#/c/8958/3/keystoneclient/shell.py) and I'd be happy to make the same change to UnifiedCLI as well. Thanks, Ken! That sounds like a good change to make. If you add me as a reviewer on the patch, I'll make sure to look at the changes. I created a blueprint for this: https://blueprints.launchpad.net/python-openstackclient/+spec/password-prompt linking back to the keystone blueprint. That looks like a good solution. Thanks Ken dt Probably would be better to have a deliberate command line flag for it, so automated scripts don't hang. Something like --prompt ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone] Quotas: LDAP Help
On 07/16/2012 07:31 PM, Everett Toews wrote:
Hi All,
I've got a working implementation of quotas in Keystone. However it's
only working for the KVS and SQL backends right now and I need it to
work with LDAP before submitting it for review. I have limited
experience with LDAP and only from an ops perspective, I've never
developed any application code against an LDAP backed app, so I'm here
asking for help.
My original plan was to just piggy back on the metadata code in the
LDAP backend (like I did with SQL). But, as you can see from
get_metadata [1] and create_metadata [2], it's not really there. Since
that's not possible I'll need to build something myself but I'm not
too sure what's the best way to go about doing that. Based on a bit of
research, I've come up with a couple of options.
Option 1 - Separate Quota ou
Looking at ldap/core.py, I could create a new QuotaApi class with the
fields
DEFAULT_OU = 'ou=Quota'
DEFAULT_STRUCTURAL_CLASSES = []
DEFAULT_OBJECTCLASS = '???'
DEFAULT_ID_ATTR = 'cn'
DEFAULT_MEMBER_ATTRIBUTE = 'cn'
options_name = 'quota'
attribute_mapping = {'quota': 'cn'}
model = models.Quota
The idea being that quota information is an ou associated with a
tenant (somehow). I'm not sure how best to store the quota data itself
in this case. Could it just be stored as JSON in the cn? I'm not sure
if that's a good idea or a bad idea but I suspect bad...
That does not sound right.
Option 2 - Metadata Attribute on Tenant
Quotas are just an attribute of a Tenant so why not just add a single
'quotas' attribute to the Tenant ou. Then the quotas JSON could be
stored in this attribute. This seems like a simple and
straight-forward solution but I don't know how to add this attribute
via an objectclass to Tenant.
How would I add a quotas attribute to the Tenant ou?
How would I reference that attribute?
Is there an existing attribute on Tenant where I could reasonably
store the quotas JSON instead of adding another one?
Usually a Quota is a limitation on a resource. I suspect that the
problem here is we have not nailed down the resource objects that you
would then apply a quota to. If, for example, we were talking about
disk quotas, we could look at the LDAP schema's that are in place for
disks, automount, and so forth. For network or CPU quotas, the concepts
don't really exist.
My immediate thought is that maybe these things are not really Keystone
quantities to manage. Nova has the database that deals with the actual
quantities of disk and so forth. BUt I know that LDAP is the system of
record for Hosts in many systems, so the Data from LDAP needs to feed
into Nova somehow
Can you post your code to a GIthub repo and send out a link to the
commit so that I could take a look? It would be much more clear to
discuss with actual code in front of me.
Thoughts or feedback on these options? Are there any other options I'm
missing?
Thanks,
Everett
[1]
https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap/core.py#L140-147
[2]
https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap/core.py#L205-206
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
[Openstack] Keystone Federation
I am contemplating writing up a post-Folsom Blueprint for Keystone Federation and /or replication, and would like to solicit input from the community. With Signed tokens, we can provide the name of the Keystone server that signed the token. With this comes the need to verify that the specified Keystone server is a valid server. The logical way would be to check it against the service catalog. I think the flow should go something like this: when you start up a service like glance it should have a Keystone server specified. When a token comes in with Keystone server that it does not recognize, it queries the known Keystone server's service catalog to see if the keystone server is a registered endpoint. This service catalog can get cached for some short amount of time to ensure we don't trigger a flurry of activity on a series of bogus requests. When a new Keystone server comes on line, it gets registered with an existing Keystone server. At this point, it requests its token signing certificate. Once it recieves the signing cert, an AMQP message then goes out to the other Keystone servers announcing the new keystone service. Retirement of a Keystone server would be done in a similar way. There are three scenarios I could see: 1) No one Keystone server would hold a complete user or tenant list. Instead, each would hold a subset of the tenants. A user might exist in multiple Keystone databases if they are enrolled in multiple tenants, some of which are in one Keystone, some of which are in another. 2) The entire user database is synchronized across all of the keystone instances. 3) The Keystone instances use a single shared DBMS and are automatically synchronized. Federation is just for redundancy and scaling. I don't want to build this just to build it. I'd like to know if A) there is a real need for Keystone Federation and B) If anyone else has thought through the problem and encountered issues I have not enumerated. If there is enough interest, I will edit the discussion into a blueprint. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone Federation
On 07/05/2012 03:12 PM, Matt Joyce wrote: Don't know if we want it. So the justifications are: 1. Redundancy 2. Scalability 3. Separation of concerns. For example, I could see a Set up where there are two Keystone servers with different back ends, one using the corporate LDAP for in house use, one using a MySQL database for partners. I could see variations where a Keystone instance gets deployed inside a corporate firewall, using a strict auth mechanism like Kerberos or Smart Cards, and those tokens are used to talk to a remove Openstack install. Again, just for a subset of users. But we may want to consider the idea of satellite read only keystone servers. Not sure we can do strict read only, if the satellite serverws are responsible for issuing out tokens. Mind you that may just be solving problems we don't even have yet. -Matt On Thu, Jul 5, 2012 at 11:26 AM, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: I am contemplating writing up a post-Folsom Blueprint for Keystone Federation and /or replication, and would like to solicit input from the community. With Signed tokens, we can provide the name of the Keystone server that signed the token. With this comes the need to verify that the specified Keystone server is a valid server. The logical way would be to check it against the service catalog. I think the flow should go something like this: when you start up a service like glance it should have a Keystone server specified. When a token comes in with Keystone server that it does not recognize, it queries the known Keystone server's service catalog to see if the keystone server is a registered endpoint. This service catalog can get cached for some short amount of time to ensure we don't trigger a flurry of activity on a series of bogus requests. When a new Keystone server comes on line, it gets registered with an existing Keystone server. At this point, it requests its token signing certificate. Once it recieves the signing cert, an AMQP message then goes out to the other Keystone servers announcing the new keystone service. Retirement of a Keystone server would be done in a similar way. There are three scenarios I could see: 1) No one Keystone server would hold a complete user or tenant list. Instead, each would hold a subset of the tenants. A user might exist in multiple Keystone databases if they are enrolled in multiple tenants, some of which are in one Keystone, some of which are in another. 2) The entire user database is synchronized across all of the keystone instances. 3) The Keystone instances use a single shared DBMS and are automatically synchronized. Federation is just for redundancy and scaling. I don't want to build this just to build it. I'd like to know if A) there is a real need for Keystone Federation and B) If anyone else has thought through the problem and encountered issues I have not enumerated. If there is enough interest, I will edit the discussion into a blueprint. ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] PKI Token Generation
The discussion during the Keystone meeting today had a couple of key points I'd like to address. The Current token length is 32 characters long. An example: e50d580692d644cfb8bec0246aede2c2 With PKI Signed tokens, they will be much longer MIICgAYJKoZIhvcNAQcCoIICcTCCAm0CAQExCTAHBgUrDgMCGjCCAWEGCSqGSIb3\ DQEHAaCCAVIEggFOeyJhY2Nlc3MiOiB7InRva2VuIjogeyJleHBpcmVzIjogIjIw\ MTItMDYtMDJUMTQ6NDc6MzRaIiwgImlkIjogInBsYWNlaG9sZGVyIiwgInRlbmFu\ dCI6IHsiZW5hYmxlZCI6IHRydWUsICJkZXNjcmlwdGlvbiI6IG51bGwsICJuYW1l\ IjogInRlbmFudF9uYW1lMSIsICJpZCI6ICJ0ZW5hbnRfaWQxIn19LCAidXNlciI6\ IHsidXNlcm5hbWUiOiAidXNlcl9uYW1lMSIsICJyb2xlc19saW5rcyI6IFsicm9s\ ZTEiLCJyb2xlMiJdLCAiaWQiOiAidXNlcl9pZDEiLCAicm9sZXMiOiBbeyJuYW1l\ IjogInJvbGUxIn0sIHsibmFtZSI6ICJyb2xlMiJ9XSwgIm5hbWUiOiAidXNlcl9u\ YW1lMSJ9fX0NCjGB9zCB9AIBATBUME8xFTATBgNVBAoTDFJlZCBIYXQsIEluYzER\ MA8GA1UEBxMIV2VzdGZvcmQxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxCzAJBgNV\ BAYTAlVTAgEBMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIGAUcweczLJw0SMQhli\ qVSFTWnPKzCnh9qaAxY+29YKFIGYmsX4x+Eh+3D4-xND0gqpdh-CD-Fe7dwsAP4K\ YHCj4W13Z0EyucgXiIbdY+XBaUInYowNmBqMRzOXMO8UGOjYMEgFvRJApb6sS4PN\ wlctpz0dJe2rTELD28EmckkApeU= However, nothing in the API comments on the token length. You cannot assume that even under the current scheme they will be 32 characters long. the code for just the token generation has been split from the auth_token changes. You can see it here: https://github.com/admiyo/keystone/tree/pki-token-generation It is not up for code review yet as there are still a few changes required. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OVF vs. bare container formats for qcow2 images
On 04/01/2012 11:15 AM, Lorin Hochstein wrote: On Mar 29, 2012, at 12:40 PM, Daniel P. Berrange wrote: On Wed, Mar 28, 2012 at 04:41:28PM -0400, Lorin Hochstein wrote: All: Given that I have a qcow2 image from somewhere (e.g., downloaded it from a uec-images.ubuntu.com http://uec-images.ubuntu.com, created one from a raw image using qemu-img) that i want to add to glance: 1. How can I tell whether it's an ovf or bare container format? You are mixing up terminology here. Disk image formats are things like raw, qcow2, vmdk, etc. OVF refers to the format of a metadata file provided alongside the disk image, which describes various requirements for running the image. The two are not tied together at all, merely complementary to each other. Thanks, that clears things up. I was confused by this language, which sounded to me like the metadata was embedded in the disk image file: http://glance.openstack.org/formats.html The container format refers to whether the virtual machine image is in a file format that also contains metadata about the actual virtual machine. In addition, the docs have examples like this, which clearly aren't meaningful: http://glance.openstack.org/glance.html#important-information-about-uploading-images Just to add to the confusion the OVF can contain both the metadata file and the disk image file in a single archived file. An OVF package consists of several files, placed in one directory. A one-file alternative is the OVA package, which is a TAR file with the OVF directory inside. http://en.wikipedia.org/wiki/Open_Virtualization_Format#Technical_description I think that what you are reading above refers to the single file alternative. $ glance add name=My Image is_public=true \ container_format=ovf disk_format=raw /tmp/images/myimage.iso I'll propose a change to the docs for that. Whenever I add a qcow2 image to glance, I always choose ovf, even though it's probably bare, because I saw an example somewhere, and it just works, so I keep doing it. But I don't know how to inspect a binary file to determine what its container is (if file image.qcow2 says it's a QEMU QCOW2 Image (v2), does that mean it's bare?). In particular, why does the user need to specify this information? If you simply have a single someimage.qcow2 file, then you simply have a disk image. Thus there is no OVF metadata involved at all. eg, this is the (qcow2) disk image: http://uec-images.ubuntu.com/precise/current/precise-server-cloudimg-amd64-disk1.img While this is an OVF metadata file that optionally accompanies the disk image http://uec-images.ubuntu.com/precise/current/precise-server-cloudimg-amd64.ovf Gotcha. It's not clear to me how you would specify the OVF metadata file when adding an image file to glance. Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com https://www.nimbisservices.com/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Devstack]Keystone authentication problem when installing
Can you post your localrc file? YOu can blank out the passwords. Also, what distribution? On 06/27/2012 09:30 PM, Ke Wu wrote: Hi, I can't find a mailing list of devstack so I choose to ask here, hope this doesn't spam you guys. I was trying to build Devstack on my VM (Ubuntu 12.04 server) to start a new environment for Horizon development. Everything went well until it hit the point to start Keystone service, the error msg was: Expecting authentication method via either a service token, --token or env[SERVICE_TOKEN], or credentials, --os_username or env[OS_USERNAME]. + NOVA_USER_ID= ++ get_field 1 ++ read data ++ grep ' service ' ++ keystone tenant-list Expecting authentication method via either a service token, --token or env[SERVICE_TOKEN], or credentials, --os_username or env[OS_USERNAME]. + NOVA_TENANT_ID= ++ keystone ec2-credentials-create --user --tenant_id usage: keystone ec2-credentials-create [--user_id user-id] [--tenant_id tenant-id] keystone ec2-credentials-create: error: argument --user_id: expected one argument + CREDS= ++ failed ++ local r=2 ++ set +o xtrace Anybody has an idea why this happened? Thanks! -Ke Wu ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [keystone] Keystone on port 5000 - proposing change default port to 8770
That is for admin, 5000 is for normal usage. Personally, I'd like to see all of the custom ports go away and we use an URL scheme as proposed: http://wiki.openstack.org/URLs On 06/20/2012 08:56 PM, Mellquist, Peter wrote: What happened to 35357? In general, new port #s should be applied through IANA and when approved then made public. Peter. -Original Message- From: openstack-bounces+peter.mellquist=hp@lists.launchpad.net [mailto:openstack-bounces+peter.mellquist=hp@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Wednesday, June 20, 2012 4:16 PM To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Subject: [Openstack] [keystone] Keystone on port 5000 - proposing change default port to 8770 At the risk of a terrible public tar and feathering... I've learned that port 5000 (which Keystone is using for it's default public-token-auth stuff) is commonly blocked by many firewalls, as it's been registered as a Microsoft uPnP port. I thought I'd go ahead and propose changing the default to 8770. I picked this number because it's close to the Nova ports in common use (8773, 8774, 8775, and 8776). And yes, I'll submit updates to all REST docs, XML docs, devstack, and the code. So... how many people do I need to worry about murdering me for this next design summit? -joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [keystone] v3 API draft (update and questions to the community)
On 06/12/2012 04:24 AM, Gabriel Hurley wrote: Mark, Apparently you must have missed my lightning talk at the Essex summit... ;-) (http://gabrielhurley.github.com/slides/openstack/apis_like_orms/index.html) Filtering, pagination, and many other API features are *critical* for a rich dashboard experience. If you want to talk specifics, the entire Horizon team would be happy to have a long chat with you. Yes and no. The reality is that it is a trade off. Server side, you pay by doing a network round trip, and having to determine ahead of time the mechanisms for sorting, caching, paging, etc. The real problem is that the parsing of the results can blow out the stack space in the browser. That said, we have also considered the case you propose where you effectively request everything and handle it on the client-side... however, I see that as a tremendously lazy solution. On the service-provider end you have access to powerful database methods that can do these operations in fractions of the time the client-side can (especially with good indexes, etc.). And if you've ever worked in mobile applications you'll know that minimizing data across the wire is crucial. The only argument I've heard in favor of that is basically it's easier for us not to add API features. At the expense of loading your Database. Serverside paging and filtering both require one of two things: caching or additional Database queries, and both increase your server footprint. For small datasets, or for limited queries, this is not a problem, but for scalability you want to limit the work you do on the server. For Keystone using the LDAP backend, caching and pagination are extremely expensive, and not something I would like to support. an LDAP query is not guaranteed to come back in any particular order, so you can't just do the SQL trick of executing the query at offset + window size. You have to do the equivalent of a Cursor, and this places serious load on the LDAP server, the Keystone server, and possibly impacts other apps dependand on LDAP. To speak on the specific feature of pagination, the problem of 'corruption' by simultaneous writers is no excuse for not implementing it. You think Google, Facebook, Flickr, etc. etc. etc. don't have this problem? If you consume their feeds you'll notice you can fetch offset-based pagination with ease. You'd never expect to see a navigation element at the bottom of Google search results that said take me to results starting with the letter m. There is a major difference. We are working with data that has to be ACID. Google, Facebook and flickr do not. Before you migrate a VM, you need to know if the host meets the criteria for the VM. If it changes between when you check and when you reserve the space for the VM, you have just over committed. Get it right eventually does not work for management apps. None of this is a case of someone might use it. The Horizon team has been loudly asking for these features for 8+ months now. And not just from Keystone but from all the projects. I have a list a mile long of API features we need to really deliver a compelling experience. I was just adding some items to it today, in fact. The rest of your points I have no strong feelings on and generally agree, but when it comes to API features... I feel *very* strongly. Note that I am not saying don't do pagination as I agree, it is essential for good user experience. What I am stating is that we need to be smart about the techniques and technologies we choose, as there is always an upside and a downside. All the best, - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Mark Nottingham Sent: Monday, June 11, 2012 10:27 PM To: Joseph Heck Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Subject: Re: [Openstack] [keystone] v3 API draft (update and questions to the community) On 11/06/2012, at 6:58 AM, Joseph Heck wrote: First - what's the current thought of support for PATCH vs PUT in updating REST resources? Are there any issues with clients being able to use a PATCH verb? It's not something I'm super familiar with, so I'm looking for feedback from the community here. Ideally, I'd like to support the semantics of the PATCH HTTP verb, and possibly just assert no support for the PUT verb to be clear about intended functionality. Is that going to throw anyone for a loop? I answered a question about PATCH before; don't want to repeat myself, but it should be workable. Happy to chat more about it if you have specific questions. Second - filtering/searching for resources. The draft includes a section labelled Query By Name, which is probably mis-labelled, as it's intended to cover the general idea of passing in query parameters to general listing resource endpoints to
[Openstack] noVNC and EPEL
I have a working noVNC RPM for both F17 and EPEL. Well...I think it is working...everything is set as best as I can tell to what it should be. However, I have not been able to get a VNC console on a VM from the Web UI. I have been able to do so using noVNC, so we have a partial solution. I've been advised that misconfiguration of the compute nodes is often at fault for noVNC not working: sleepsonthefloor ayoung: it is very common for people to misconfigure flags on the compute hosts sleepsonthefloor FLAGS.vncserver_proxyclient_address and FLAGS.novncproxy_base_url My packages are at: http://admiyo.fedorapeople.org/noVNC/ Paidrig pixelbeat Brady has tweaked them and gotten them blessed into the Fedora and EPEL system. With the RPM installed, the steps to get novnc_server (not the Nova proxy) working are: 1. Generate a key. I put this in /etc/nova: openssl req -new -x509 -days 365 -nodes -out self.pem -keyout self.pem 2. Figure out the port for the vnc server you want. This will depend on the VM. In general, the first VM you spin up will have 9000, the next 9001. You can brute force the search using qemu-syst 21809 qemu 13u IPv4 178192 0t0 TCP localhost:vnc-server (LISTEN) qemu-syst 26373 qemu 11u IPv43446722 0t0 TCP localhost:5901 (LISTEN) Note that the first line lists the port by service name (vnc-server) out of /etc/services (technically the NSSwitch services database, but we all probably have that set to files.) I ensured I could connect to the server using the tiger-vnc package and vncviewer. 3. Run the novnc server. In the upstream, this is launch.sh. For Fedora we've given it the slightly more descriptive name novnc_server. cd /usr/share/novnc novnc_server --cert /etc/nova/self.pem --vnc localhost:5901 4. Get the self signed cert into your browser by pointing at the server using https://hostname:6080. This will kick you into the invalid certificate dialog. Accept the Cert and it will forward you to noVNC. No password is required: click connect and you should be viewing the appropriate VM. I have not been able to get the Horizon Dashboard to noVNC integration working. I suspect that the correct command line should be something like: nova-novncproxy --flagfile=/etc/nova/nova.conf --web=/usr/share/novnc/ --cert=/etc/nova/self.pem --log-file=/var/log/nova/novnc.log But no connections go through. Nothing shows up in the log (and I have confirmed that is not due to permissions). Nothing shows up on the command line, either except the startup information: [root@ayoung-stack2 novnc]# nova-novncproxy --flagfile=/etc/nova/nova.conf --web=/usr/share/novnc/ --cert=/etc/nova/self.pem --log-file=/var/log/nova/novnc.log WebSocket server settings: - Listen on 0.0.0.0:6080 - Flash security policy server - Web server. Web root: /usr/share/novnc - SSL/TLS support - proxying from 0.0.0.0:6080 to ignore:ignore For Fedora, we cannot ship the binary Flash blob. I've been working under the assumtion that the Nova noVNC proxy uses the browsers websocket support ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Signed Tokens
On 06/01/2012 05:56 PM, Adam Young wrote: The signed tokens work has been updated. I think this is the final architecture. https://github.com/admiyo/keystone/commits/signed-tokens-5 Not all of the unit tests run. Some of the Memcache tests are suspect, and I wonder if we even need memcache support for tokens in the middle ware. I think we don't. Also, the Diablo tokens are not supported. I think we can safely deprecate them for Folsom. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Responses to Guang Yee's comments on Git hub: keystone/config.py line 156 gyee: Maybe token_signing instead of signing? Signing still sound too generic: ayoung:This is a generic signing cert, although it is only used for tokens, it could be used for something else as well. I think signing is appropriate keystone/middleware/auth_token.p line 146: gyee:May want to do os.umask() to protect the signing dir. ayoung: agreed. line 597: gyee: You are assuming openssl is available. May want to do a sanity check first. ayoung: the Packages will 'Require' Openssl, and we will put it into the package list for Devstack as well. gyee: May want to introduce some timeout logic to force process termination in case it hangs or did not finish on time. ayoung: We are not consuming entropy with the signing or verification process, so hanging is likely not an issue. I don't think Eventlet makes that kind of code easy to write, either. If we see signs of hanging, then we will deal with it. keystone/service.py line 505: gyee: certfile.close ayoung: yes ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Websocket support long term
On 06/04/2012 09:55 AM, Jay Pipes wrote: On 05/30/2012 09:28 PM, Adam Young wrote: The recent discussion about node.js made me rethink the state of Websocket support for Apache and Openstack. A quick recap: 1) neither mod_wsgi nor mod_proxy support Web sockets. 2) There is a Websocket Module for Apache, but using it requires an additional apache module. 3) There is websocket support in Eventlet. 4) The argument for node.js is the same for Eventlet: rapid dispatch to support a large number of connections 5) noVNC currently uses websockify, and uses a simplistic web server to proxy over VNC traffic. The more I think about it, the more I think that the simplest, and most correct path forward is to use the websocket Apache module, and to write an additional module that will hook it up to Eventlet. Eventlet can listen on a local Port (127.0.0.1 only) and Apache will map that to a suburl. I'll code name it mod_websocket_proxy for now. snip Adam, other than the NoVNC piece in Nova and the Horizon project in general, where do you see the need for Websockets in OpenStack? I could easily be mistaken (happens a lot!), but I see Websockets as a great tool for client-side and UI interaction, and not so much useful in the eventlet servers that we use for so many OpenStack services (nova-api, swift-proxy, glance-api, glance-registry, keystone-api, etc). Could you elaborate how you see Websockets (and your proposed mod_websocket_proxy) being useful to OpenStack services outside of horizon and noVNC? Jay, This is predominantly for Horizon. For other communication, I think AMQP suffices, but we might want to revisit that assumption in the future. I think that demand for Websockets is what is driving the push toward Node.js. It is a natural complement to an event driven webserver. While I think the quetion of noVNC itself justifies investigating Websocket approaches, I can see the need for Websocket style development where: 1. We need to traverse firewalls 2. We need the application to predominantly post data to the browser Thus far we would otherwise choose AMQP for notifications, but it doesn't seem to be the right solution for these cases. So, what are these cases? Log streaming seems to be the first case: a long running task generating a lot of events, and a user wants to track what is happening as quickly as they occur. This covers a lot of use cases. Thanks! -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Need testing of devstack change on different platforms.
A couple changes in the larger Linux world will affect devstack. In F17, we've already seen a change in the response format of ifconfig which breaks devstack. Upon closer inspection, it appears ifconfig itself is deprecated, and the correct solution is to use the ip command instead. https://review.openstack.org/#/c/8018/ I've tested this on F17 and the output is the same on F16. Getting this change in will help future proof devstack, but I'd like a little bit more testing, especially if people are running devstack on platforms other than those that are officially sanctioned and supported. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
