Agree with Ron. Besides the change in cloudstack documents, it would be nice to check all cloudstack ports (8080, 8250, 9090, 8096/integration, 9595/prometheus) and display error messages before starting java thread when start service cloudstack-management. It helps users to find the root cause and stop services to free the ports.
-Wei On Thu, 2 Jul 2020 at 04:42, Ron Wheeler <rwhee...@artifact-software.com.invalid> wrote: > Is there any hope of getting projects to follow the rules? > > One would think that Cloudstack developers would be the most likely to > understand networking, the Internet and system administration. > > Ron > > On 2020-07-01 12:53 p.m., Andrija Panic wrote: > > (true that, Ron...) > > > > On Wed, 1 Jul 2020, 15:27 Ron Wheeler, > > <rwhee...@artifact-software.com.invalid> wrote: > > > >> If the open source community just got their act together and registered > >> their ports and stopped using ports registered to other projects, this > >> would not happen. > >> > >> There is no shortage of available ports, there is just a complete lack > >> of professionalism in the community and it causes unnecessary headaches > >> for users. > >> > >> Stop using ports registered to other projects. > >> Register the ports for Cloudstack and encourage/insist that others do so > >> as well. > >> Publicly shame projects and products that use ports that they have not > >> registered. > >> To set a good example, in documentation and examples stop using ports in > >> the registered range for applications that should use ports in the > >> private/dynamic range. > >> > >> > >> Ron > >> > >> > >> On 2020-07-01 7:36 a.m., Abhishek Kumar wrote: > >>> +1 with adding documentation. > >>> > >>> And maybe we should also refactor the port check logic and error > >> message. Currently, code just tries to connect the socket for the port > and > >> if it fails that with the message, > >>> Detected that another management node with the same IP XX.XX.XX.XX is > >> already running, please check your cluster configuration > >>> Instead of the cockpit, it can be any other service/process. Should we > >> try to get details of that service in the logs, exception message so the > >> user can make changes? > >>> Regards, > >>> Abhishek > >>> ________________________________ > >>> From: Rohit Yadav <rohit.ya...@shapeblue.com> > >>> Sent: 01 July 2020 13:04 > >>> To: dev@cloudstack.apache.org <dev@cloudstack.apache.org>; > >> us...@cloudstack.apache.org <us...@cloudstack.apache.org> > >>> Subject: Re: [DISCUSS] Management server default port conflict > >>> > >>> I think we can document in our CloudStack qig/release/install notes to > >> say users must disable cockpit on CentOS8. Here are my 2paisas; > >>> * Most users using CentOS (7/8) won't use a single-host specific > >> management tool/UI such as cockpit; they would probably use some fleet > >> management software or automate using ansible/puppet/ceph etc. > >>> * Last time I checked the minimal CentOS-8 ISO does not install > >> cockpit or that it is enabled by default (service does not run by > default > >> until you active the port 9090 target) > >>> * Some users may have monitoring scripts/tools or security rules > >> that expect port 9090 to be used by CloudStack, so it's probably safer > to > >> ask users to change port for cockpit than CloudStack by default > >>> Regards. > >>> > >>> ________________________________ > >>> From: Abhishek Kumar <abhishek.ku...@shapeblue.com> > >>> Sent: Wednesday, July 1, 2020 11:14 > >>> To: dev@cloudstack.apache.org <dev@cloudstack.apache.org>; > >> us...@cloudstack.apache.org <us...@cloudstack.apache.org> > >>> Subject: [DISCUSS] Management server default port conflict > >>> > >>> Hi all, > >>> > >>> I would like to know everyone's opinion regarding an issue seen with > >> CloudStack on CentOS8 (https://github.com/apache/cloudstack/pull/4068). > >> CentOS8 comes with cockpit (https://cockpit-project.org/) installed > which > >> uses port 9090, although it is not active by default. CloudStack > management > >> server also needs port 9090. And when CloudStack management server is > >> started with systemd it triggers the start of cockpit first and > management > >> server fails to start, > >>> > >>> 2020-06-25 07:20:51,707 ERROR [c.c.c.ClusterManagerImpl] (main:null) > >> (logid:) Detected that another management node with the same IP > 10.10.2.167 > >> is already running, please check your cluster configuration > >>> 2020-06-25 07:20:51,708 ERROR [o.a.c.s.l.CloudStackExtendedLifeCycle] > >> (main:null) (logid:) Failed to configure ClusterManagerImpl > >>> javax.naming.ConfigurationException: Detected that another management > >> node with the same IP 10.10.2.167 is already running, please check your > >> cluster configuration > >>> at > >> > com.cloud.cluster.ClusterManagerImpl.checkConflicts(ClusterManagerImpl.java:1192) > >>> at > >> > com.cloud.cluster.ClusterManagerImpl.configure(ClusterManagerImpl.java:1065) > >>> at > >> > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle$3.with(CloudStackExtendedLifeCycle.java:114) > >>> at > >> > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.with(CloudStackExtendedLifeCycle.java:153) > >>> at > >> > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.configure(CloudStackExtendedLifeCycle.java:110) > >>> at > >> > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55) > >>> at > >> > org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:182) > >>> at > >> > org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:53) > >>> at > >> > org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:360) > >>> at > >> > org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:158) > >>> at > >> > org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:122) > >>> at > >> > org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:894) > >>> at > >> > org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:553) > >>> at > >> > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:144) > >>> at > >> > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:121) > >>> at > >> > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:244) > >>> at > >> > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:249) > >>> at > >> > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:249) > >>> at > >> > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:232) > >>> at > >> > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSet.java:116) > >>> at > >> > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:78) > >>> at > >> > org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37) > >>> at > >> > org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:70) > >>> at > >> > org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.<init>(CloudStackSpringContext.java:57) > >>> at > >> > org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.<init>(CloudStackSpringContext.java:61) > >>> at > >> > org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized(CloudStackContextLoaderListener.java:51) > >>> at > >> > org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:930) > >>> at > >> > org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:553) > >>> at > >> > org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:889) > >>> at > >> > org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:356) > >>> at > >> > org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1445) > >>> at > >> > org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1409) > >>> at > >> > org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:822) > >>> at > >> > org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:275) > >>> at > >> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524) > >>> at > >> > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72) > >>> at > >> > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) > >>> at > >> > org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:110) > >>> at > >> > org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97) > >>> at > >> > org.eclipse.jetty.server.handler.gzip.GzipHandler.doStart(GzipHandler.java:425) > >>> at > >> > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72) > >>> at > >> > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) > >>> at > >> > org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117) > >>> at > >> > org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97) > >>> at > >> > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72) > >>> at > >> > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) > >>> at org.eclipse.jetty.server.Server.start(Server.java:407) > >>> > >>> Therefore, in your opinion how this should be handled? Should we > >> document that CS management server needs port 9090 free by default and > any > >> other process using it should be moved a different port or the > management > >> server port should be moved in case of CentOS8, either in code or > >> documentation to change cluster.servlet.port in db.properties? > >>> Regards, > >>> Abhishek > >>> > >>> abhishek.ku...@shapeblue.com > >>> www.shapeblue.com<http://www.shapeblue.com> > >>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK > >>> @shapeblue > >>> > >>> > >>> > >>> > >>> rohit.ya...@shapeblue.com > >>> www.shapeblue.com<http://www.shapeblue.com> > >>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK > >>> @shapeblue > >>> > >>> > >>> > >>> > >>> abhishek.ku...@shapeblue.com > >>> www.shapeblue.com > >>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK > >>> @shapeblue > >>> > >>> > >>> > >> -- > >> Ron Wheeler > >> Artifact Software > >> 438-345-3369 > >> rwhee...@artifact-software.com > >> > >> > > -- > Ron Wheeler > Artifact Software > 438-345-3369 > rwhee...@artifact-software.com > >
