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 <[email protected]> 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" <[email protected]> wrote: > >> I even think db upgrade should be separated from mgt server. >> >>> -----Original Message----- >>> From: Chiradeep Vittal [mailto:[email protected]] >>> Sent: Monday, March 04, 2013 2:11 PM >>> To: [email protected] >>> Subject: Re: issue with 4.1 >>> >>> +1 (again) >>> >>> On 3/4/13 1:06 PM, "Alex Huang" <[email protected]> wrote: >>> >>>> +1. It does not belong to the management server. >>>> >>>> --Alex >>>> >>>>> -----Original Message----- >>>>> From: John Burwell [mailto:[email protected]] >>>>> Sent: Monday, March 4, 2013 8:13 AM >>>>> To: [email protected] >>>>> 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 >>>>> <[email protected]> >>>>> 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 >>>>> <[email protected]> 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 >
