While this was cherry-picked in trunk, the code was modified and is broken in
karmic and trunk:
self.run_in_target('chown', '-R', '%s:%s' % (self.vm.user,)*2,
'/home/%s/.ssh/' % (self.vm.user)).
see bug #436835
** Changed in: vm-builder (Ubuntu)
Status: Confirmed = Fix
added a branch link
** Branch linked: lp:~deshantm/vmbuilder/vmbuilder-deshantm
--
ssh keys for user are not owned by the user [Jaunty] [PATCH]
https://bugs.launchpad.net/bugs/354288
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
On Fri, Apr 3, 2009 at 6:27 PM, Todd Deshane desha...@gmail.com wrote:
First, the chown command takes, as the 2nd and 3rd arguments, the uid
and gid of the user. The user that needs to own the .ssh directory and
its contents is a user that is created within the chroot. While it is
possible to
I can't see a situation where the initial users's uid and gid wouldn't
be 1000.
This situation arises when vmbuilder is being used to build standard
images which are going to be used by other parties. For example, when
vmbuilder is used to build public images for Amazon EC2:
I see this issue as well.
Why not use os.chown instead of run_cmd in your patch?
** Changed in: vm-builder (Ubuntu)
Status: New = Confirmed
--
ssh keys for user are not owned by the user [Jaunty] [PATCH]
https://bugs.launchpad.net/bugs/354288
You received this bug notification because
At first I tried to go the os.chown way, but there were a few
complications that made the code less elegant.
First, the chown command takes, as the 2nd and 3rd arguments, the uid
and gid of the user. The user that needs to own the .ssh directory and
its contents is a user that is created within
** Attachment added: chown-ssh-keys-dapper.py.diff
http://launchpadlibrarian.net/24735899/chown-ssh-keys-dapper.py.diff
--
ssh keys for user are not owned by the user [Jaunty] [PATCH]
https://bugs.launchpad.net/bugs/354288
You received this bug notification because you are a member of
