Kelvin, While this workaround stops the interactive prompting by the daemon, it is bad security practice. As the ticket states, daemon users should be granted least privilege necessary to execute in order to limit damage in the event of a successful attack. Granting the daemon user password-less sudo access violates this best practice and effectively allows the management server to execute as root. Additionally, the SSL certificate generated by the script is an attack vector due to the use of a common password, "vmops.com". For both of these reasons, there is no workaround that does not compromise security.
Thanks, -John On Mar 4, 2013, at 6:40 PM, Kelven Yang <kelven.y...@citrix.com> wrote: > To work around this issue, try to add the user(to be used to start > management server) to sudoer list (without need for password) and comment > out "requiretty" in /etc/sudoers configuration. > > Kelven > > On 3/4/13 2:24 PM, "Edison Su" <edison...@citrix.com> wrote: > >> I even think db upgrade should be separated from mgt server. >> >>> -----Original Message----- >>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] >>> Sent: Monday, March 04, 2013 2:11 PM >>> To: cloudstack-dev@incubator.apache.org >>> Subject: Re: issue with 4.1 >>> >>> +1 (again) >>> >>> On 3/4/13 1:06 PM, "Alex Huang" <alex.hu...@citrix.com> wrote: >>> >>>> +1. It does not belong to the management server. >>>> >>>> --Alex >>>> >>>>> -----Original Message----- >>>>> From: John Burwell [mailto:jburw...@basho.com] >>>>> Sent: Monday, March 4, 2013 8:13 AM >>>>> To: cloudstack-dev@incubator.apache.org >>>>> Subject: Re: issue with 4.1 >>>>> >>>>> Chip, >>>>> >>>>> My recommendation in the ticket is to extract the script from the >>>>> management server to a external script provided as a connivence to end >>>>> users. If we encounter a situation where a certificate is not >>>>> present, provide a meaningful error message in the logs and exit. If >>>>> a user needs help generating an SSL certificate, they can use execute >>>>> the script with the appropriate parameters. Otherwise, they will >>>>> generate/procure one through external means. >>>>> >>>>> Thanks, >>>>> -John >>>>> >>>>> On Mar 4, 2013, at 10:59 AM, Chip Childers >>>>> <chip.child...@sungard.com> >>>>> wrote: >>>>> >>>>>> On Mon, Mar 04, 2013 at 08:51:03AM -0700, Marcus Sorensen wrote: >>>>>>> There's a bug for this, I think it's related to passwordless sudo >>>>>>> for cloud user on management server. >>>>>> >>>>>> Is this the one? >>>>>> >>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-1389 >>>>>> >>>>>>> >>>>>>> On Mon, Mar 4, 2013 at 6:52 AM, Sebastien Goasguen >>>>> <run...@gmail.com> wrote: >>>>>>>> Hi I am trying to test the latest 4.1 (and 4.1l10n branch). >>>>>>>> >>>>>>>> I am on OSX 10.8.2, I had to update to JDK 1.7 to get things >>> going. >>>>>>>> >>>>>>>> and after a 'clean install' I get stuck with: >>>>>>>> >>>>>>>> Password:WARN [utils.script.Script] (Script-1:) Interrupting >>>>> script. >>>>>>>> WARN [utils.script.Script] (Timer-2:) Timed out: sudo keytool >>>>> -genkey - >>>>> keystore /Users/sebastiengoasguen/Documents/incubator- >>>>> cloudstack/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB- >>>>> INF/classes/cloud.keystore -storepass vmops.com -keypass vmops.com - >>>>> keyalg RSA -validity 3650 -dname cn="Cloudstack >>>>> User",ou="168.1.20",o="168.1.20",c="Unknown" . Output is: >>>>>>>> WARN [cloud.server.ConfigurationServerImpl] (Timer-2:) Would use >>>>> fail-safe keystore to continue. >>>>>>>> java.io.IOException: Fail to generate certificate!: timeout >>>>>>>> at >>> com.cloud.server.ConfigurationServerImpl.generateDefaultKeystore(Conf >>>>> ig >>>>> urationServerImpl.java:491) >>>>>>>> at >>> com.cloud.server.ConfigurationServerImpl.updateSSLKeystore(Configurat >>>>> io >>>>> nServerImpl.java:512) >>>>>>>> at >>>>> >>>>> com.cloud.server.ConfigurationServerImpl.persistDefaultValues(Configur >>>>> ati >>>>> onServerImpl.java:269) >>>>>>>> at >>>>> com.cloud.server.ConfigurationServerImpl.configure(ConfigurationServe >>>>> rIm >>>>> pl.java:143) >>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>> Method) >>>>>>>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. >>>>> j >>>>> ava:57) >>>>>>>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces >>>>> sorImpl.java:43) >>>>>>>> at java.lang.reflect.Method.invoke(Method.java:601) >>>>>>>> at >>>>> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflecti >>>>> on( >>>>> AopUtils.java:319) >>>>>>>> at >>> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJo >>>>> i >>>>> npoint(ReflectiveMethodInvocation.java:183) >>>>>>>> at >>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed( >>>>> ReflectiveMethodInvocation.java:150) >>>>>>>> at >>> org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.p >>>>> r >>>>> oceed(MethodInvocationProceedingJoinPoint.java:80) >>>>>>>> at >>> com.cloud.utils.db.TransactionContextBuilder.AroundAnyMethod(Transact >>>>> io >>>>> nContextBuilder.java:37) >>>>>>>> at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown >>>>> Source) >>>>>>>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces >>>>> sorImpl.java:43) >>>>>>>> at java.lang.reflect.Method.invoke(Method.java:601) >>>>>>>> at >>> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMet >>>>> h >>>>> odWithGivenArgs(AbstractAspectJAdvice.java:621) >>>>>>>> at >>> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMet >>>>> h >>>>> od(AbstractAspectJAdvice.java:610) >>>>>>>> at >>> org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAro >>>>> u >>>>> ndAdvice.java:65) >>>>>>>> at >>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed( >>>>> ReflectiveMethodInvocation.java:172) >>>>>>>> at >>>>> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invok >>>>> e(E >>>>> xposeInvocationInterceptor.java:90) >>>>>>>> at >>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed( >>>>> ReflectiveMethodInvocation.java:172) >>>>>>>> at >>> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDyna >>>>> micAopProxy.java:202) >>>>>>>> at $Proxy388.configure(Unknown Source) >>>>>>>> at >>> com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(Co >>>>> mponentContext.java:110) >>>>>>>> at >>>>> com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java: >>>>> 50) >>>>>>>> at java.util.TimerThread.mainLoop(Timer.java:555) >>>>>>>> at java.util.TimerThread.run(Timer.java:505) >>>>>>>> INFO [cloud.server.ConfigurationServerImpl] (Timer-2:) >>>>>>>> Processing updateKeyPairs INFO >>>>>>>> [cloud.server.ConfigurationServerImpl] >>>>>>>> (Timer-2:) Keypairs already in database INFO >>>>>>>> [cloud.server.ConfigurationServerImpl] (Timer-2:) Keypairs >>>>>>>> already in database, skip updating local copy (not running as >>>>>>>> cloud user) INFO [cloud.server.ConfigurationServerImpl] >>>>>>>> (Timer-2:) Going to update systemvm iso with generated keypairs >>>>>>>> if needed >>>>>>>> Password: >>>>>>>> >>>>>>>> ? >>>>>>>> >>>>>>>> -sebastien >
