I see the same like Paul and a fast fail would be nice. Cheers
__ Sven Vogel Lead Cloud Solution Architect EWERK DIGITAL GmbH Br?hl 24, D-04109 Leipzig P +49 341 42649 - 99 F +49 341 42649 - 98 s.vo...@ewerk.com www.ewerk.com Gesch?ftsf?hrer: Dr. Erik Wende, Hendrik Schubert, Tassilo M?schke Registergericht: Leipzig HRB 9065 Support: +49 341 42649 555 Zertifiziert nach: ISO/IEC 27001:2013 DIN EN ISO 9001:2015 DIN ISO/IEC 20000-1:2011 ISAE 3402 Typ II Assessed EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<https://www.linkedin.com/company/ewerk-group> | Xing<https://www.xing.com/company/ewerk> | Twitter<https://twitter.com/EWERK_Group> | Facebook<https://de-de.facebook.com/EWERK.IT/> Ausk?nfte und Angebote per Mail sind freibleibend und unverbindlich. Disclaimer Privacy: Der Inhalt dieser E-Mail (einschlie?lich etwaiger beigef?gter Dateien) ist vertraulich und nur f?r den Empf?nger bestimmt. Sollten Sie nicht der bestimmungsgem??e Empf?nger sein, ist Ihnen jegliche Offenlegung, Vervielf?ltigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverz?glich den Absender und l?schen Sie die E-Mail (einschlie?lich etwaiger beigef?gter Dateien) von Ihrem System. Vielen Dank. The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you. ________________________________ Von: Ron Wheeler <rwhee...@artifact-software.com.INVALID> Gesendet: Thursday, July 2, 2020 1:06:20 PM An: dev@cloudstack.apache.org <dev@cloudstack.apache.org> Betreff: Re: [DISCUSS] Management server default port conflict The point is to register so at least people know that the port numbers are used if one installs Cloudstack. If the Cloudstack team at least chooses a set of ports that are not currently registered, 1) other projects can avoid using/registering the same ports by mistake 2) other projects that want to use Clodstack ports will know that Cloudstack users will be unable to run their apps without some extra effort 3) If another project registers a Cloudstack port, system administrators will know *before* they try to go into production that they will have to find a solution to the problem rather than having some obscure error starting a system that passed all of the tests in the test environment. My main message is 1) Stop squating on other project's registered ports 2) Whether or not Cloudstack changes default ports, register the ports that Cloudstack uses so other projects can avoid squating on Cloudstack ports and system admins can see where the conflicts might be. 3) Try to get other projects to follow the rules 4) Change any documentation that shows user-created apps running on public ports when they should be running on private/dynamic ports https://tools.ietf.org/html/rfc6335#section-8.1.2 describes the use of port ranges. System Ports - 0-1023 - special ports User Ports - 1024-49151 - for registered port Dynamic ports - 49152-65535 - private applications and dynamic ports - demo apps should be shown running on these ports There is no shortage of public ports. Cloudstack is targeted at professional production environment and should be a model for other projects and show leadership in adherence to standards. Ron On 2020-07-02 5:03 a.m., Paul Angus wrote: > 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<http://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<http://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 >> >> -- Ron Wheeler Artifact Software 438-345-3369 rwhee...@artifact-software.com
