How about having the installer check if 9090 is in use and ask for an alternative port if so.
I guess this would mean you first have to make the port configurable. During upgrades the check would not be made and leave the config as is. > On May 12, 2015, at 2:09 PM, Rafael Fonseca <rsafons...@gmail.com> wrote: > > Marcus, it has not made it to CentOS/RedHat Server yet, but it's on Fedora > Server, not desktop.. on by default. > > I can give a hand with those python scripts next week hopefully :) > > On Tue, May 12, 2015 at 9:04 PM, Marcus <shadow...@gmail.com > <mailto:shadow...@gmail.com>> wrote: > >> I understand, but it's the sort of thing most admins will disable or remove >> in their kickstart as a liability. RedHat has had default system management >> services like this before and they were not well received (I forget the >> name of the remote system management utility that shipped with RHEL4/5). If >> it does make it from the desktop to the server as a default service though, >> then I agree we will have to address it as a part of our CentOS management >> server support. >> >> Don't get me started on the python config scripts, they've been a pain, >> honestly. Particularly on the hypervisor side, it opens a bunch of ports >> that not everyone needs, edits libvirt configs, and conflicts with >> configuration management. They're great in the interest of someone spinning >> up a quick proof of concept or small environment, but larger environments >> usually manage their own configs and the python scripts touch all sorts of >> things and require a post-agent reconfigure. If we make the ports >> configurable, the script should probably just not bother touching the >> firewall and let an admin do it, or prompt during cloud-setup-management. >> >> On Tue, May 12, 2015 at 10:32 AM, Rafael Fonseca <rsafons...@gmail.com >> <mailto:rsafons...@gmail.com>> >> wrote: >> >>> And unfortunately, I don't think it's currently configurable even if you >>> change the config file.. it's hardcoded in: >>> >>> framework/cluster/src/com/cloud/cluster/ClusterServiceServletAdapter.java >>> framework/cluster/src/com/cloud/cluster/ClusterServiceServletImpl.java >>> >>> and in the firewall config in: >>> python/lib/cloudutils/serviceConfig.py >>> >>> needs to be rectified also :) >>> >>> The thing about cockpit is that it is enabled and on by default in the >> most >>> fedora 21, and might also be so for other distros with systemd in the >>> future, since it's a management interface for systemd. >>> >>> >>> >>> On Tue, May 12, 2015 at 7:21 PM, Rafael Fonseca <rsafons...@gmail.com >>> <mailto:rsafons...@gmail.com>> >>> wrote: >>> >>>> >>>> https://www.adminsub.net/tcp-udp-port-finder/9090 >>>> <https://www.adminsub.net/tcp-udp-port-finder/9090> >>>> >>>> vs >>>> >>>> https://www.adminsub.net/tcp-udp-port-finder/9190 >>>> <https://www.adminsub.net/tcp-udp-port-finder/9190> >>>> >>>> The latter would most likely hurt the less to a broad user base :) >>>> >>>> On Tue, May 12, 2015 at 7:20 PM, Rafael Fonseca <rsafons...@gmail.com >>>> <mailto:rsafons...@gmail.com>> >>>> wrote: >>>> >>>>> There are some handy tools to get the sense of having likely issues >> with >>>>> other services :) >>>>> >>>>> >>>>> On Tue, May 12, 2015 at 7:15 PM, Marcus <shadow...@gmail.com >>>>> <mailto:shadow...@gmail.com>> wrote: >>>>> >>>>>> I don't think we are recommending a reverse proxy (are we?), it was >>> just >>>>>> brought up as a solution if someone wants port 80 to go to >> cloudstack. >>>>>> At >>>>>> past jobs we put Apache on 80, and used it solely to host CS api docs >>> for >>>>>> the version of the API that the management server was running, as >> well >>>>>> as a >>>>>> few other utilities that were management server specific. >>>>>> >>>>>> Many shops also front CloudStack with a load balancer, in which case >>> they >>>>>> generally don't care what port it runs on. >>>>>> >>>>>> I'm not sure it's worth changing 9090, either, but I think it's less >> of >>>>>> an >>>>>> issue to do so. The best option is simply to make sure it is >>>>>> configurable, >>>>>> so in the event someone wants to run two services they can adjust the >>>>>> port >>>>>> (or use another IP). I don't know how many people care about or will >>> run >>>>>> cockpit, or any other service that will conflict on 8080, 9090, 8250 >> or >>>>>> any >>>>>> other port we make up, and it seems like a losing battle to try to >>> guess >>>>>> that. In the end I guess I lean toward not inconveniencing our >> existing >>>>>> user base by changing ports, to avoid a minor and fairly expected >>>>>> inconvenience that a new setup might experience port conflicts with >>>>>> unrelated services on common app ports. >>>>>> >>>>>> On Tue, May 12, 2015 at 8:26 AM, Rafael Fonseca < >> rsafons...@gmail.com <mailto:rsafons...@gmail.com>> >>>>>> wrote: >>>>>> >>>>>>> That is a good point David, but ideally, if we are recommending the >>>>>> use of >>>>>>> a reverse proxy because our out of the box solution isn't good >> enough >>>>>> for >>>>>>> production, i'd propose either: >>>>>>> >>>>>>> - Fix the performance problems with tomcat and make it production >>>>>> worthy >>>>>>> (in what concerns the application server, i'd say its better to >> have >>>>>> this >>>>>>> one locked down, to make sure user is using tested configs and lib >>>>>> versions >>>>>>> and to NOT depend on distro provided scripts, install locations, >>> libs, >>>>>> etc, >>>>>>> since this is a basic requirement to get things going); >>>>>>> >>>>>>> AND/OR >>>>>>> >>>>>>> - Suggest that a reverse proxy is recommended and provide automatic >>>>>>> configuration for the most common ones (like httpd and nginx) and >> not >>>>>>> necessarily have them shipped with the product. >>>>>>> >>>>>>> I'm usually also against providing locked configs, but ideally, >> there >>>>>>> should be some more automated sane defaults for a few things with >>>>>> OPTION to >>>>>>> change.. instead of just having to to everything by yourself if we >>>>>> don't >>>>>>> provide a default/automation . >>>>>>> >>>>>>> I'm keen with doing everything myself, but a lot of people aren't.. >>>>>>> >>>>>>> I will also provide some fixes for performance soon, i've already >>>>>>> identified a few ;) >>>>>>> >>>>>>> :) >>>>>>> >>>>>>> On Tue, May 12, 2015 at 4:37 PM, David Nalley <da...@gnsa.us >>>>>>> <mailto:da...@gnsa.us>> >> wrote: >>>>>>> >>>>>>>> On Tue, May 12, 2015 at 8:47 AM, Rafael Fonseca < >>>>>> rsafons...@gmail.com <mailto:rsafons...@gmail.com>> >>>>>>>> wrote: >>>>>>>>> I'll stay away from touching port 80 for now, but isn't saving >>>>>> work to >>>>>>>> the >>>>>>>>> admin one of cloudstack's main goals? >>>>>>>>> >>>>>>>>> That is also the main reason to package this stuff and have >> rules >>>>>> for >>>>>>>>> configuration :) >>>>>>>>> >>>>>>>>> I do see a lot of people complaining that cloudstack is hard to >>>>>> setup >>>>>>> and >>>>>>>>> has very long setup guides and a lot of stuff doesn't work on >>>>>> certain >>>>>>>>> environments... i aim to put an end to that.. hopefully even >> the >>>>>>> dumbest >>>>>>>>> sysadmin will be able to get it up and running without much >>> effort >>>>>> by >>>>>>> the >>>>>>>>> time i'm done :) . The effort reduction is also always valid >> for >>>>>>>>> experienced sysadmins and developers ;) >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Sorta - we want to do enough sanely that people can get going, >> but >>>>>> not >>>>>>>> so much that it locks people into specific configurations with no >>>>>>>> option to change them. If an nginx shop suddenly found httpd >>> deployed >>>>>>>> because of using CloudStack, well, that would be a surprise. We >>> don't >>>>>>>> really want it to be a black box. >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, May 12, 2015 at 1:16 PM, Wido den Hollander < >>>>>> w...@widodh.nl> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>>>> Hash: SHA1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 05/12/2015 12:03 PM, Rafael Fonseca wrote: >>>>>>>>>>> Wido, >>>>>>>>>>> >>>>>>>>>>> If we were to recommend proxying with httpd, shouldn't >>>>>> cloudstack >>>>>>>>>>> provide that as well out of the box? >>>>>>>>>> >>>>>>>>>> I'd stay away from that. Providing that out of the box means >>> doing >>>>>>>>>> more stuff which an admin should do. >>>>>>>>>> >>>>>>>>>> Wido >>>>>>>>>> >>>>>>>>>>> Btw, there isn't really a big performance gain by proxying >>>>>> through >>>>>>>>>>> httpd nowadays, the new version of the packaging also >> includes >>>>>>>>>>> using tomcat8, which has an improved http/nio connector, >> have >>> a >>>>>>>>>>> look here for some performance benchmarks :) -> >>>>>>>>>>> >>>>>>>> >>>>>> >> http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-a >>>>>>>>>> lways-use-apache-httpd-front-apache-tomcat-improve-perform >>>>>>>>>>> >>>>>>>>>>> What i think is that if we are going to suggest configuring >>>>>> httpd >>>>>>>>>>> on the same box we should do it automatically, if not, >> tomcat >>>>>> can >>>>>>>>>>> still run on port 80 by default and user can reverse proxy >>> from >>>>>> any >>>>>>>>>>> other machine :) >>>>>>>>>>> >>>>>>>>>>> Also, if we're sticking to tomcat, we should have scripts >>> build >>>>>>>>>>> the APR/native connector for improved performance :) >>>>>>>>>>> http://tomcat.apache.org/native-doc/ >>>>>>>>>>> >>>>>>>>>>> This would be an improvement independent from using or not >>>>>>>>>>> httpd/nginx in front of tomcat. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, May 12, 2015 at 11:45 AM, Wido den Hollander >>>>>>>>>>> <w...@widodh.nl> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 05/12/2015 11:37 AM, Erik Weber wrote: >>>>>>>>>>>>>> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca >>>>>>>>>>>>>> <rsafons...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm reworking the packaging system in cloudstack, and >>> would >>>>>>>>>>>>>>> like to gather your opinion on the following: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Fedora 2x runs systemd's cockpit on port 9090 by >> default >>>>>>>>>>>>>>> This is a deal breaker for the cluster servlet port on >>> this >>>>>>>>>>>>>>> OS, the two possibilities would be to either pack >> changes >>>>>>>>>>>>>>> to fedora's config on rpm install or simply change the >>>>>>>>>>>>>>> servlet port to another one that does not clash on any >>>>>>>>>>>>>>> distro.. any comments/suggestions? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Tomcat is not listening on port 80 Tomcat is using >> port >>>>>>>>>>>>>>> 8080, which makes the user have to specify that in the >>>>>>>>>>>>>>> browser.. should we change it? In ubuntu it's already >>>>>>>>>>>>>>> running under jsvc, so it shouldn't be a problem.. same >>> can >>>>>>>>>>>>>>> be arranged for centos/other distros. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is it possible to ask the user for this during >> installation >>>>>>>>>>>>>> and default to either 80 or 8080? I know Debian has a way >>> to >>>>>>>>>>>>>> interact with the user during install, not sure about >>>>>>>>>>>>>> RedHat. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't know the rationale behind putting it on port 8080 >>> in >>>>>>>>>>>>>> the first place, but personally I don't see a problem >>> moving >>>>>>>>>>>>>> it to port 80. >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'd say to stick to 8080 and recommend anybody to use >> Apache / >>>>>>>>>>> Nginx to proxy towards Tomcat. >>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> - No link on the tomcat root (http://management-server/ >>> can >>>>>>>>>>>>>>> link internally to http://management-server/client , >> this >>>>>>>>>>>>>>> makes it easier for new users who don't know the URL for >>>>>>>>>>>>>>> the UI :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Sounds like a good idea to me, I always forget to add >>> /client >>>>>>>>>>>>>> when I browse to new installations. >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> -----BEGIN PGP SIGNATURE----- >>>>>>>>>> Version: GnuPG v1 >>>>>>>>>> >>>>>>>>>> >> iQIcBAEBAgAGBQJVUeEFAAoJEAGbWC3bPspCupwQAJjU6Akq18N9QcPYiOK60NR5 >>>>>>>>>> >> P9+MF0UFvu1N5nHJxYwEHjIqwuzN9957xqx6LK0nhyDMN8ECadvZXweT5XhXbh+5 >>>>>>>>>> >> G7D1Wqilav7GqGiye+4zV2CLRUI8KBPrUMFHwk4C4o1SqE6YxiX7E8/WY+cx2nt2 >>>>>>>>>> >> LRAwPIvc3IL5QRIbiDfFm19mJRExBvHIZCYsMAPMgag2p85HOzuGxQ/NCcME7nna >>>>>>>>>> >> ODlHkjrPaWF66vZtyMA289R1e0Bab7hbElirCsA0VoTP3gbrwNriDf1KSfmOzIJD >>>>>>>>>> >> VyaSq2kcDIrWYWjuXxtjhIKdxCCkopgqRvjjiEDCQ3LVDaMsh4PSjhl2SuSU24l4 >>>>>>>>>> >> mX6DZXjnt+3U01FOj9Bc76K28hawB3+7qqYPEsWlboi7Jz5hn0j04Kn9wRa+ZbfF >>>>>>>>>> >> 8t1DUpdPDtWd+HsyV/fdKXKY1X4Q/P3SatrqVZBymnyT/l/ENvqYLzLcNXHN9NSl >>>>>>>>>> >> 8o0+vhmTJRdbK9QoNeB8QtmtU+VB4iyC6x5tfwgqLvRNsSep3mpEgrKVa3h1Ssaz >>>>>>>>>> >> 14ChxYSNktOLJM3JuKBHqzSM0lxOHOT7wkiSXiXlCpbaoVRLcge7U4PjJW/GCSrE >>>>>>>>>> >> a/BAUYQzSKBAS/OpZHFizmQ0J7ASXaFDlBwy5XBfV+4nZjtClVR4oN9VHAJJ8d2X >>>>>>>>>> Fl89s3wdH0L/ag6Sd/oj >>>>>>>>>> =nbJY >>>>>>>>>> -----END PGP SIGNATURE-----
