On Feb 6, 2014, at 1:48 PM, Adam Young wrote:
> Those are for initializing the Keystone server. Create a user with the admin
> roles, then you disable the ADMIN_TOKEN in the conf file, and use a real
> user with a real token to do all other work. SERVICE_TOKEN is not a long term
> setting for
On 02/06/2014 10:53 AM, Daniel Ellison wrote:
On Feb 6, 2014, at 10:19 AM, Remo Mattei wrote:
Seems a permissions issue did you try a different user?
I just defined a new user with OS_SERVICE_TOKEN and OS_SERVICE_ENDPOINT set
(because that DOES work) and when I tried to get a user list as tha
Is this a production a dev devstack packstack that me help a little as well
Thanks
Inviato da iPhone ()
> Il giorno Feb 6, 2014, alle ore 8:53, Daniel Ellison ha
> scritto:
>
>> On Feb 6, 2014, at 11:31 AM, Daniel Ellison wrote:
>> Also, these are the variables which are set on login:
>>
>
As expected, it was user error. The Keystone endpoint URLs had been defined
incorrectly. The public URL had been set to the admin URL and the admin URL was
blank.
Mystery solved. Thanks for your input!
+Dan
___
Mailing list: http://lists.openstack.org
On Feb 6, 2014, at 11:31 AM, Daniel Ellison wrote:
> Also, these are the variables which are set on login:
>
>export OS_USERNAME=admin
>export OS_TENANT_NAME=admin
>export OS_PASSWORD=
>export OS_AUTH_URL=http://:5000/v2.0/
I just reset admin's password to that which is in the en
On Feb 6, 2014, at 11:09 AM, Craig Jellick wrote:
> If you're using the default policy.json file, this seems to be the
> expected behavior.
> The "list_user_projects" method has an access rule of "admin_or_owner".
> All the other calls you mentioned have a rule of "admin_required".
>
> So, I'd sa
I agree that’s why I was saying to try a different user. If you add a user it
will not be part of the admin anyhow, by default.
Remo
On Feb 6, 2014, at 11:09, Craig Jellick wrote:
> If you're using the default policy.json file, this seems to be the
> expected behavior.
> The "list_user_projec
If you're using the default policy.json file, this seems to be the
expected behavior.
The "list_user_projects" method has an access rule of "admin_or_owner".
All the other calls you mentioned have a rule of "admin_required".
So, I'd say that most likely the user you are using does not have the rol
Can you try to execute it as an admin from the CLI using the following variable:
#Paste the following:
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=admin
export OS_AUTH_URL="http://192.168.100.254:5000/v2.0/";
using your ip here
Bye
Remo
On Feb 6, 2014, at 10:53, Dani
On Feb 6, 2014, at 10:53 AM, Daniel Ellison wrote:
> On Feb 6, 2014, at 10:19 AM, Remo Mattei wrote:
>> Seems a permissions issue did you try a different user?
>
> I just defined a new user with OS_SERVICE_TOKEN and OS_SERVICE_ENDPOINT set
> (because that DOES work) and when I tried to get a us
On Feb 6, 2014, at 10:19 AM, Remo Mattei wrote:
> Seems a permissions issue did you try a different user?
I just defined a new user with OS_SERVICE_TOKEN and OS_SERVICE_ENDPOINT set
(because that DOES work) and when I tried to get a user list as that new user
it gave me the same error.
+Dan
__
Seems a permissions issue did you try a different user?
Remo
On Feb 6, 2014, at 10:09, Daniel Ellison wrote:
> Hey all,
>
> I've run into an issue with a Havana Keystone install on CentOS 6.3. When I
> issue a command such as:
>
>keystone user-list
>
> I get in response:
>
>Unable
Hey all,
I've run into an issue with a Havana Keystone install on CentOS 6.3. When I
issue a command such as:
keystone user-list
I get in response:
Unable to authorize user
This happens with service-list, endpoint-list, role-list, etc. Oddly, it does
NOT happen with tenant-list; I ge
13 matches
Mail list logo
