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> 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> > wrote: > > > > > 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----- > >>> > > >> > >>> > > > >>> > > >>> > >> > >> > > >
