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