Hi,
A bit late to this party. My 3 pence:
+1 for making things more configurable (e.g. IP/port binding)
-1 for auto-configuring any sort of proxies or making any sort of assumptions
on behalf of the sysadmin - this is the stuff that pisses off sysadmins
actually
-1 for changing default ports
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áteg
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 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 wrote:
> I understand, but it's the sort of thing most admins will disable o
On Tue, May 12, 2015 at 5:26 PM, Rafael Fonseca
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:
>
>
It's not really about 'not good enough', but most s
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
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:
pyth
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
wrote:
> There are some handy tools to get the sense of having likely issue
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 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
> pas
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
f
Hi Lazlo,
I hadn't seen that JIRA issue yet :)
I am indeed working in packaging and have taken a different approach, which
provides for much cleaner distro support.
I'm currently finishing up on having the exact same installer working for
both centos7 and fedora2x without any need for special cust
Hi Rafael,
There is a ticket for fedora packaging: CLOUDSTACK-8163 I have sent patches
with that issue ID. There are quite a lot of things to do...
Are you working on the management server packaging?
Why does the management service have to start as a separate service? It
could be just a webapp und
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'
On Tue, May 12, 2015 at 8:47 AM, Rafael Fonseca 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 comp
603 0540 | M: +44 7711 418 784 | T:
> @CloudyAngus
> paul.an...@shapeblue.com
>
> -Original Message-
> From: Erik Weber [mailto:terbol...@gmail.com]
> Sent: 12 May 2015 14:17
> To: dev
> Subject: Re: Cloudstack Repackaging / Distro support
>
> It's easier to
That is easy enough to check at install time :)
If we want to avoid that scenario the following could be done:
- Check if anything is using port 80 at config time, warn and don't config
anything if it is
- Load/Unload the redirect rule on tomcat startup, this will make port 80
available to other p
On Tue, May 12, 2015 at 3:30 PM, Rafael Fonseca
wrote:
> Keeping a couple of config files for httpd/nginx should be quite easy, we
> could configure it optionally (with a prompt) when running the
> cloud-setup-management script, for instance.
> We can optionally also just configure a redirect rul
Keeping a couple of config files for httpd/nginx should be quite easy, we
could configure it optionally (with a prompt) when running the
cloud-setup-management script, for instance.
We can optionally also just configure a redirect rule for port 80 on the
same prompt if user doesn't want proxying, t
-Original Message-
From: Erik Weber [mailto:terbol...@gmail.com]
Sent: 12 May 2015 14:17
To: dev
Subject: Re: Cloudstack Repackaging / Distro support
It's easier to maintain a playbook/cookbook/manifest than a site-config (that
rarely should change)? :-)
--
Erik
On Tue, May 12, 20
It's easier to maintain a playbook/cookbook/manifest than a site-config
(that rarely should change)? :-)
--
Erik
On Tue, May 12, 2015 at 3:14 PM, Jeff Moody wrote:
> Also a good idea, but would be yet another package to be
> maintained...albeit a small one.
> Might be easier to release a pair
Also a good idea, but would be yet another package to be maintained...albeit a
small one.
Might be easier to release a pair of Ansible playbooks/Chef cookbooks/Puppet
manifests/etc.
On Tue, 2015-05-12 at 15:11 +0200, Erik Weber wrote:
> How about bundling the httpd/nginx configuration in a separ
How about bundling the httpd/nginx configuration in a separate optional
package?
I have no idea for a name, but it could depend on either httpd and nginx,
and include a site config that works out of the box.
Should work great for those who need an easy setup, and still allow those
who set up exter
I'd say a safe middle-ground might be providing a working proxy config
for Apache and for nginx in the docs or share directories and then
pointing to those in the documentation as references to get the API
proxied on 80/443.
I do agree with leaving the default on 8080 as that's the default for
Tom
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 gui
-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 a
Wido,
If we were to recommend proxying with httpd, shouldn't cloudstack provide
that as well out of the box?
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, ha
On Tue, May 12, 2015 at 11:51 AM, Rafael Fonseca
wrote:
> I guess the rationale behind putting it on 8080 is because this is the
> default for tomcat :)
> Also, by default, unprivileged accounts (non-root) are unable to listen on
> ports under 1024 like 80/443 (which is the reason of tomcat shipp
I guess the rationale behind putting it on 8080 is because this is the
default for tomcat :)
Also, by default, unprivileged accounts (non-root) are unable to listen on
ports under 1024 like 80/443 (which is the reason of tomcat shipping it by
default on 8080) this is easily fixable by daemonizing i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/12/2015 11:37 AM, Erik Weber wrote:
> On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
> wrote:
>
>> Hi all,
>>
>> I'm reworking the packaging system in cloudstack, and would like
>> to gather your opinion on the following:
>>
>> - Fedora 2
On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
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
30 matches
Mail list logo
