> -----Original Message----- > From: Dave Cahill [mailto:dcah...@midokura.jp] > Sent: Wednesday, November 14, 2012 7:19 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: [DISCUSS] SSH keys overwritten for user running management > server > > Ah, interesting. > > Judging from the initial commit I sent on, it seems like the intent of the > "delete existing SSH key and recreate" logic was for the multiple > management server case. Would it make sense to use "reuse existing SSH > key" > in developer mode, since users would be unlikely to run a multiple > management server setup in development mode? This would have less > impact on the production management server upgrade path.
+1 reuse the existing ssh key in developer mode. > > > On Thu, Nov 15, 2012 at 12:08 PM, Chiradeep Vittal < > chiradeep.vit...@citrix.com> wrote: > > > Hmm, this commit (26e78bd0) introduces the devel flag. > > Previously if the user was not cloud then the ssh keys would be left > > intact. > > > > Certainly the upgrade case for production management servers will be > > impacted. > > > > On 11/14/12 6:48 PM, "Dave Cahill" <dcah...@midokura.jp> wrote: > > > > >Hi Chiradeep, > > > > > >I had a poke through commit logs, and my understanding was that this > > >commit from January 2011 is where the code went from reusing existing > > >keys to removing and updating them, but I may easily be missing > > >something. > > > > > >"bug 8199: always update the keypairs on disk to account for multiple > > >management servers" > > > > > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=b > > lobd > > >iff;f=server/src/com/cloud/server/ConfigurationServerImpl.java;h=23d2 > > >4a1df > > > >6b46185c481b0f2ab793453e2dc12c2;hp=3a6243b64822321fd5ae18c3f606c72 > 45f > > >ed80e > > > >6;hb=cc0ed77feed5e5adc7cfdf9e8babe58d696e148e;hpb=fd081dc5e74671b > a7e5 > > >f8dae > > >799443dd5b24d90f > > > > > >If we changed the filename, what would be the effects on the upgrade > path? > > >For example, if someone has an existing management server with keys > > >named id_rsa but not id_rsa.systemvm keys, I guess we could copy > > >id_rsa and id_rsa.pub to id_rsa.systemvm and id_rsa.systemvm.pub? > > > > > >Thanks, > > >Dave. > > > > > > > > > > > >On Thu, Nov 15, 2012 at 11:33 AM, Chiradeep Vittal < > > >chiradeep.vit...@citrix.com> wrote: > > > > > >> > > >> > > >> On 11/14/12 6:11 PM, "Satoshi Kobayashi" > > >> <satosh...@stratosphere.co.jp> > > >> wrote: > > >> > > >> >Hi Dave, > > >> > > > >> >2012/11/14 Dave Cahill <dcah...@midokura.jp>: > > >> >> Hi, > > >> >> > > >> >> I've recently been running the management server from source > > >> >> using > > >>mvn > > >> >>-pl > > >> >> :cloud-client-ui jetty:run, and I've come across an issue. > > >> >> > > >> >> If the "ssh.privatekey" configuration entry is not present in > > >> >> the management server db, then in ConfigurationServerImpl > > >> [snip] > > >> >> - Given what I know so far, I disagree with this option; the > > >> >>behaviour seems weird even for the "cloud" user, and someone > > >> >>will certainly > > >>try to > > >> >> run as their own user even if we recommend against it > > >> >> * The management server should back up old ssh keys before > > >> >> deleting > > >>them > > >> >> - Better than nothing, but non-ideal; unless the user realizes > > >> >>what happened, this will not help them > > >> >> * The management server should use existing ssh keys if > > >> >>available, instead of recreating > > >> >> - This sounds like a good option - may cause issues if the > > >> >>existing keypair is password-protected? > > >> >> * The management server should use a non-default filename for > > >> >>the ssh keys, e.g. id_rsa.systemvm and id_rsa.pub.systemvm, to > > >> >>avoid damaging > > >>existing > > >> >> SSH keys > > >> >> - This option seems ideal from my point of view, but may involve > > >>extra > > >> >>work > > >> > > > >> >+1 for a non-default filename ssh key idea. > > >> >I think that it is dangerous that a default ssh key is overwritten > > >> >even if it adopts other ideas. > > >> > > >> +1 for non-default filename. As Prasanna said, in the ant mode, it > > >> +never > > >> deleted the old key, it just reused it. > > >> Not sure how it got borked. > > >> > > >> > > > > > > > > >-- > > >Thanks, > > >Dave. > > > > > > > -- > Thanks, > Dave.
