cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: SystemVM ISO on KVM
Date Wed, 20 Feb 2013 01:49:56 GMT
On Feb 19, 2013 5:53 PM, "Dave Cahill" <dcahill@midokura.com> wrote:
>
> > On KVM the key is copied via the patch disk (/dev/vdb). If you were to
> mount that drive in your systemvm, it has an authorized_keys file that is
> copied by an init script.
>
> Weird - on my KVM setup, SSH key behavior seems to depend on the systemVM
> ISO. Initially, systemvm.iso wasn't being attached to the system VMs (ISO
> wasn't being found due to the cloud > cloudstack rename), and I couldn't
> SSH into the VMs at all. Then I got an old systemVM ISO attached, and
could
> access the VM using the SSH keys associated with that ISO. Then I got a
new
> systemVM ISO attached, and could access using the keys associated with the
> new ISO.
>
> Does the patchdisk override the system VM ISO, or the other way around? Is
> the patchdisk functionality / behavior documented anywhere? I'd like to
> understand it better.

No, but in the past the ssh key was not copied from the patch disk unless
the iso existed. you can look through /etc/init.d/cloud-early-config for
answers on the system VM. We used to have problems, but yours is the first
I've heard of since 4.0. I thought we resolved that so it would copy
regardless, but come to think of it perhaps your patch disk was messed up
due to the same reason why your systemvm.iso didn't work(was that a path
issue?). If so, you should wipe out the patch disk and it will be recreated
when you start the system vm again. I am hoping its an after effect of the
previous bug.

>
> > Can you file a bug for both of these issues?  They have come up a couple
> of times, and should probably be addressed.
>
> I'll certainly file a bug for the SSH keys being overwritten. I need to
dig
> a little more to understand the ISO vs patchdisk interaction for SSH keys,
> but if it turns out to be a bug, I'll file that too.
>
> Thanks,
> Dave.
>
> On Tue, Feb 19, 2013 at 11:55 PM, Marcus Sorensen <shadowsor@gmail.com
>wrote:
>
> > On xen the systemvm.iso should be updated on the management server. At
> > least I think that's how thy do it.
> >
> > On KVM the key is copied via the patch disk (/dev/vdb). If you were to
> > mount that drive in your systemvm, it has an authorized_keys file that
is
> > copied by an init script. This is kind of ugly, as it tends to litter
your
> > storage with patch disks, since they're technically not kept track of by
> > cloudstack. When I found this I triaged this somewhat by naming them
> > similar to the host, and then looking for any patch disk with a name
> > similar ton the VM when it gets deleted.
> > On Feb 19, 2013 2:07 AM, "Dave Cahill" <dcahill@midokura.com> wrote:
> >
> > > Hi,
> > >
> > > Working on CloudStack in development mode (using jetty to run the
> > > management server), I noticed that the Host's SSH keypairs and those
in
> > the
> > > system VM ISO easily get out of sync.
> > >
> > > After every database redeploy, the the management server generates a
new
> > > SSH keypair because the "ssh.privatekey" and "ssh.publickey"
> > configuration
> > > entries are gone from the database.
> > >
> > > Once these new keypairs are generated, the management server:
> > >
> > > * Writes the new keypair to disk on the management server node
> > > (~/.ssh/id_rsa)
> > >     As an aside, this overwrites the user's existing SSH keys; we
> > discussed
> > > this back in November [1], but didn't come to a conclusion
> > > * Writes the new keypair to the database ("ssh.privatekey" and
> > > "ssh.publickey" configuration entries)
> > > * Injects the new keypair into systemvm.iso on the management server
> > > * Overwrites /root/.ssh/id_rsa.cloud on the Host with the new keypair
> > (via
> > > the agent on the Host)
> > >
> > > In other words, it automatically overwrites the ssh keypair on the
Host,
> > > but doesn't automatically overwrite systemvm.iso on the Host as far
as I
> > > can see. This means the keypair and the systemvm ISO are out of sync
on
> > the
> > > Host, and sshing into system vms using /root/,ssh/id_rsa.cloud doesn't
> > > work.
> > >
> > > To get around this, I scp the new systemvm.iso across to the Host
after
> > > redeploying the database and starting the management server for the
first
> > > time, and before setting up the Host on the management server side.
> > >
> > > Is there a better way?
> > >
> > > Thanks,
> > > Dave.
> > >
> > > [1] [DISCUSS] SSH keys overwritten for user running management server
> > >
> > >
> >
http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201211.mbox/%3CCALytfWZEb8UUKQ--TZgcqPcsZ_EAoBiK+VtMLL0ZD17+W0QoQQ@mail.gmail.com%3E
> > >
> >

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message