I like Wei's idea - fast fail with explanation is usually best. Re ports in general... You can register ports with IANA, but IANA has a number of ports where it has allowed more that one protocol to register the same port number, so they don't seem to follow their own rules either.
paul.an...@shapeblue.com www.shapeblue.com 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue -----Original Message----- From: Wei ZHOU <ustcweiz...@gmail.com> Sent: 02 July 2020 07:44 To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Management server default port conflict 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.w > ith(CloudStackExtendedLifeCycle.java:114) > >>> at > >> > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.wit > h(CloudStackExtendedLifeCycle.java:153) > >>> at > >> > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.con > figure(CloudStackExtendedLifeCycle.java:110) > >>> at > >> > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.sta > rt(CloudStackExtendedLifeCycle.java:55) > >>> at > >> > org.springframework.context.support.DefaultLifecycleProcessor.doStart( > DefaultLifecycleProcessor.java:182) > >>> at > >> > org.springframework.context.support.DefaultLifecycleProcessor.access$2 > 00(DefaultLifecycleProcessor.java:53) > >>> at > >> > org.springframework.context.support.DefaultLifecycleProcessor$Lifecycl > eGroup.start(DefaultLifecycleProcessor.java:360) > >>> at > >> > org.springframework.context.support.DefaultLifecycleProcessor.startBea > ns(DefaultLifecycleProcessor.java:158) > >>> at > >> > org.springframework.context.support.DefaultLifecycleProcessor.onRefres > h(DefaultLifecycleProcessor.java:122) > >>> at > >> > org.springframework.context.support.AbstractApplicationContext.finishR > efresh(AbstractApplicationContext.java:894) > >>> at > >> > org.springframework.context.support.AbstractApplicationContext.refresh > (AbstractApplicationContext.java:553) > >>> at > >> > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition > Set.loadContext(DefaultModuleDefinitionSet.java:144) > >>> at > >> > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition > Set$2.with(DefaultModuleDefinitionSet.java:121) > >>> at > >> > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition > Set.withModule(DefaultModuleDefinitionSet.java:244) > >>> at > >> > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition > Set.withModule(DefaultModuleDefinitionSet.java:249) > >>> at > >> > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition > Set.withModule(DefaultModuleDefinitionSet.java:249) > >>> at > >> > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition > Set.withModule(DefaultModuleDefinitionSet.java:232) > >>> at > >> > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition > Set.loadContexts(DefaultModuleDefinitionSet.java:116) > >>> at > >> > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinition > Set.load(DefaultModuleDefinitionSet.java:78) > >>> at > >> > org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory. > loadModules(ModuleBasedContextFactory.java:37) > >>> at > >> > org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.in > it(CloudStackSpringContext.java:70) > >>> at > >> > org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.<i > nit>(CloudStackSpringContext.java:57) > >>> at > >> > org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.<i > nit>(CloudStackSpringContext.java:61) > >>> at > >> > org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListene > r.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(ContextHa > ndler.java:889) > >>> at > >> > org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletCo > ntextHandler.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(ServletContext > Handler.java:275) > >>> at > >> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:5 > >> 24) > >>> at > >> > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeC > ycle.java:72) > >>> at > >> > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLif > eCycle.java:169) > >>> at > >> > org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerL > ifeCycle.java:110) > >>> at > >> > org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandl > er.java:97) > >>> at > >> > org.eclipse.jetty.server.handler.gzip.GzipHandler.doStart(GzipHandler. > java:425) > >>> at > >> > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeC > ycle.java:72) > >>> at > >> > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLif > eCycle.java:169) > >>> at > >> > org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerL > ifeCycle.java:117) > >>> at > >> > org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandl > er.java:97) > >>> at > >> > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeC > ycle.java:72) > >>> at > >> > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLif > eCycle.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 > >
