Hi Wei, The original logic is, is the user don't want to generate sslkeystore, we would use the default keystore; otherwise we would use the user generated one.
The reason is, in the deployment environment, each user should have it's own ssl keystore; but for developer, it just doesn't matter, but we still need one default keystore. So here, we strongly recommended to generate ssl keystore, but developer can ignore the information. And in any case, we won't want ssl keystore to be the exactly same in the all the deployment... So that's default keystore, is just a "fall-back" keystore, and not recommended. I suppose your solution should be OK for developer to continue using default keystore and customer would still have to generated the keystore right? But if customer have to generated the keystore anyway, why they need to start server-nonssl.xml first? Should be the same process I think? --Sheng On Mon, Nov 11, 2013 at 9:15 AM, Wei Zhou <w.z...@leaseweb.com> wrote: > Hi Sheng, > > > > As the cloudmanagementserver.keystore is not valid after RPM installation, > I remove the file from cloudstack installations (including DEBs and RPMs). > > For someone who use server-ssl.xml, as cloudmanagementserver.keystore is > not installed by default, they need to start with server-nonssl.xml at > first so that CloudStack will generate the keystore. > > > > Thanks for your Email! > > > > Kind Regards, > > > > Wei ZHOU > > Innovation Engineer Cloud, LeaseWeb B.V. > > w.z...@leaseweb.com > > > > *From:* Sheng Yang [mailto:sh...@yasker.org] > *Sent:* 09 November 2013 01:27 > *To:* Wei Zhou; <dev@cloudstack.apache.org> > *Subject:* Regarding the ssl key store change > > > > Hi Wei, > > > > I found this change in the MASTER. > > > > commit 57ba367f3c985e80ea1b34267e298b481a353298 > > Author: Wei Zhou <w.z...@leaseweb.com> > > Date: Thu Nov 7 11:09:06 2013 +0100 > > > > CLOUDSTACK-5042: change cloud.keystore to > cloudmanagementserver.keystore and install it (cherry picked from commit > de448ec4792eda5b47d79b26e9cb8ce96a2b22f4) > > > > IIUC, this would means there is no SSL keystore generation for the new > management servers? That doesn't sound right... > > > > --Sheng >
