https://www.adminsub.net/tcp-udp-port-finder/9090
vs 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> 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> 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> >> 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> wrote: >> > >> > > On Tue, May 12, 2015 at 8:47 AM, Rafael Fonseca <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----- >> > > >> >> > > >> > >> > >
