Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 976394 - [RFE] Put the keystonerc_admin file in the current working directory for --all-in-one installs (or where client machine is same as local)
Summary: [RFE] Put the keystonerc_admin file in the current working directory for --al...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RDO
Classification: Community
Component: openstack-packstack
Version: unspecified
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: ---
Assignee: Martin Magr
QA Contact: yeylon@redhat.com
URL:
Whiteboard:
Depends On: 990590 990591
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-20 13:36 UTC by Perry Myers
Modified: 2016-04-27 01:58 UTC (History)
7 users (show)

Fixed In Version: openstack-packstack-2013.2.1-0.11.dev806.el6
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-30 23:06:56 UTC


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 48473 0 None None None Never

Description Perry Myers 2013-06-20 13:36:47 UTC
Description of problem:
A lot of users get hung up on looking for the keystonerc_admin file, which by default packstack puts onto the machine specified as the 'OpenStack Client', since that is the machine where the python client packages are installed.

I think it would be nicer for the users if in some cases we put that file in a more obvious location.  The logic I'm thinking is:

* If OpenStack Client host is == localhost (which would incidentally be the case in --allinone), place the keystonerc_admin file in both /root (which it does today) but also in the directory from where packstack is run

* If OpenStack Client host is != localhost, just put the keystonerc_admin file in /root on the remote host that is to be the client

Comment 1 Derek Higgins 2013-06-20 13:44:35 UTC
Also note, special consideration may need to be taken while writing out the second rc file if the current directory is world read or writeable.

Comment 2 Perry Myers 2013-06-20 13:56:28 UTC
How about ensuring that the file is owned by the current user running packstack and is set to 600 perms?

Comment 3 Sandro Mathys 2013-06-20 14:09:04 UTC
How about writing the file only once (in /root) and creating a symlink to it?

Comment 4 Arthur Berezin 2013-09-02 12:17:57 UTC
Perry, if the idea here is to let the user source keystone_rc form current directory, maybe we would want to to have a script in user's $PATH sourcing keystone_rc ? 
Putting keystone_rc to the directory where the user executes PackStack from could be a security risk as it contains customers' sensitive information.

Arthur

Comment 5 Perry Myers 2013-09-02 13:20:34 UTC
(In reply to Arthur Berezin from comment #4)
> Perry, if the idea here is to let the user source keystone_rc form current
> directory, maybe we would want to to have a script in user's $PATH sourcing
> keystone_rc ? 
> Putting keystone_rc to the directory where the user executes PackStack from
> could be a security risk as it contains customers' sensitive information.

Let me walk through what users have to do today, and you can see that this is just simply a convenience to eliminate a lot of confusion.

1. Run packstack from non-root user 
2. sudo cp /root/keystonerc_demo /root/keystonerc_admin .
3. source keystonerc_admin

Alternatively, the user needs to always perform 'user' operations by su'ing to root first, which is itself not a good idea.

The reason why I suggested this was because we were seeing a lot of questions like "I installed via packstack but I don't know where my rc files are?" even though we print out the location in the packstack output :)

Again, this is only for --allinone installs which by definition are for hobbyists, demos or PoCs.  The passwords in these rc files for an allinone install would be randomly generated, and all services are on a single box, so I don't think there is really any risk of exposing company secrets.  We would of course want to use as restrictive a umask as possible for the file (600 probably)

Comment 6 Arthur Berezin 2013-09-09 07:28:36 UTC
For PoCs/Allinones/Hobbyists/Demos this would be a good solution.

My feedback here is that most openstack deployment would be carried by Linux guys, sourcing a credentials file wouldn't be the "standard" Linux way of gaining permissions and ability to execute admin commands. 
I'm suggesting to have a command line tool, that would be under users' path, to gain openstack admin/user credential, something like "chroot", chopenstack or chos maybe ?

Comment 7 Perry Myers 2013-09-09 12:38:40 UTC
(In reply to Arthur Berezin from comment #6)
> For PoCs/Allinones/Hobbyists/Demos this would be a good solution.
> 
> My feedback here is that most openstack deployment would be carried by Linux
> guys, sourcing a credentials file wouldn't be the "standard" Linux way of
> gaining permissions and ability to execute admin commands. 
> I'm suggesting to have a command line tool, that would be under users' path,
> to gain openstack admin/user credential, something like "chroot",
> chopenstack or chos maybe ?

That's a much larger issue.  Sourcing an rc file is the standard way of getting permissions in upstream OpenStack.  Packstack is just mirroring what the upstream method is.

Comment 10 Stephen Wadeley 2015-10-07 08:07:19 UTC
(In reply to Perry Myers from comment #5)
> (In reply to Arthur Berezin from comment #4)
<snip>
> 
> The reason why I suggested this was because we were seeing a lot of
> questions like "I installed via packstack but I don't know where my rc files
> are?" even though we print out the location in the packstack output :)
> 

Hello, does the script actually test to see if the rc files *were* created?
I just ran `--allinone` and it had two errors, but still printed out the message:
File /root/keystonerc_admin has been created on OpenStack client host 1.2.3.4

(where 1.2.3.4 is the IP address of my host)

yet I cannot find the file. 

Happy to file new bug if required.

Thank you

Comment 11 Martin Magr 2015-10-07 08:55:16 UTC
Message is created and added to final messages when Puppet manifest is created. If packstack fails before the manifest is run, then file won't be created and message will still be printed. Feel free to file new bug.

Comment 12 Stephen Wadeley 2015-10-07 14:09:13 UTC
(In reply to Martin Magr from comment #11)
> Message is created and added to final messages when Puppet manifest is
> created. If packstack fails before the manifest is run, then file won't be
> created and message will still be printed. Feel free to file new bug.

Bug 1269535 - packstack script does not test to see if the rc files *were* created.

Thank you


Note You need to log in before you can comment on or make changes to this bug.