] Handling of adminPass is arguably broken (essex)
Hi,
Just noticed the following two projects:
https://github.com/rackspace/openstack-guest-agents-windows-xenserver
https://github.com/rackspace/openstack-guest-agents-unix
Would those be useful in creating an agent like Vish described?
It seems
Hi,
Just noticed the following two projects:
https://github.com/rackspace/openstack-guest-agents-windows-xenserver
https://github.com/rackspace/openstack-guest-agents-unix
Would those be useful in creating an agent like Vish described?
It seems they currently only support Xen? Haven't taken a
On Thu, Nov 01, 2012 at 11:03:14AM -0700, Vishvananda Ishaya wrote:
The new config drive code defaults to iso-9660, so that should work. The
vfat version should probably create a partition table.
Is that what Folsom is using? Or is it new-er than that?
--
Lars Kellogg-Stedman
On 11/02/2012 07:03 PM, Lars Kellogg-Stedman wrote:
On Thu, Nov 01, 2012 at 11:03:14AM -0700, Vishvananda Ishaya wrote:
The new config drive code defaults to iso-9660, so that should work. The
vfat version should probably create a partition table.
Is that what Folsom is using? Or is it
Honestly I think the entire idea of passing a password in to the instance at
boot
time is insecure and flawed.
I think that the use of a configuration drive is a reasonably way to
provide configuration information to an instance, and it's more secure
than the metadata server.
In any case,
On 11/1/12 9:36 AM, Lars Kellogg-Stedman l...@seas.harvard.edu wrote:
Honestly I think the entire idea of passing a password in to the
instance at boot
time is insecure and flawed.
I think that the use of a configuration drive is a reasonably way to
provide configuration information to an
On Thu, Nov 01, 2012 at 02:07:08PM +, Gabe Westmaas wrote:
(a) sounds like a bug in Horizon if that's not viewable immediately after
creating the instance.
Horizon doesn't display any information after booting an instance...it
takes you directly to the Instances screen. So not so much a
The best idea I've heard for a secure windows password
is the following:
a) put a public key on the instance via metadata or config drive (for ease of
use this could actually just be the ssh public key you normally use for
logging into the vm).
b) have a daemon in the windows instance
On Wed, Oct 31, 2012 at 09:09:14PM -0400, Lars Kellogg-Stedman wrote:
TL;DR: The way OpenStack handles the adminPass attribute during
metadata injection is not useful on operating systems without an
/etc/passwd and /etc/shadow. I would like to make the adminPass value
available on a Windows
On 11/01/2012 05:14 PM, Lars Kellogg-Stedman wrote:
On Wed, Oct 31, 2012 at 09:09:14PM -0400, Lars Kellogg-Stedman wrote:
TL;DR: The way OpenStack handles the adminPass attribute during
metadata injection is not useful on operating systems without an
/etc/passwd and /etc/shadow. I would like
On Nov 1, 2012, at 10:14 AM, Lars Kellogg-Stedman l...@seas.harvard.edu wrote:
On Wed, Oct 31, 2012 at 09:09:14PM -0400, Lars Kellogg-Stedman wrote:
TL;DR: The way OpenStack handles the adminPass attribute during
metadata injection is not useful on operating systems without an
/etc/passwd
TL;DR: The way OpenStack handles the adminPass attribute during
metadata injection is not useful on operating systems without an
/etc/passwd and /etc/shadow. I would like to make the adminPass value
available on a Windows instance, and this is my proposal for how to do
it.
I've been putting
Just fyi, the cloud-init format 'spec' has something similar that bypasses
the file injection (which is a bad/insecure/incompatible concept that
needs to be gotten rid of imho) by having the following syntax it
understands:
On Oct 31, 2012, at 7:04 PM, Lars Kellogg-Stedman l...@seas.harvard.edu wrote:
Injection via files on a configuration disk seems to me the best way
to handle security credentials like this, because disks in many cases
require privileges to mount on a system and the configuration script
can
14 matches
Mail list logo
