We should allow configurability, but, in the future, we should also register the port. - you'll note Bacula, for instance, doesn't have any clashes. http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=111
On Tue, May 12, 2015 at 5:15 PM, Carlos Reátegui <create...@gmail.com> wrote: > 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----- >
