Ah, it looks like from your URL, you are just appending to the generic function that's creating the API URL to send to CS. I see openfirewall=true and openfirewall=false in the final API output which means the API command sent to this function already has it appended.
If you can't find it while trying to grep for openfirewall in the javascript files, someone should be on after the Memorial weekend to respond. Will ________________________________________ From: Jason Davis [[email protected]] Sent: Saturday, May 26, 2012 8:53 PM To: [email protected] Subject: Re: Anyway to disable the firewall functionality provided by the virtual router in 3.0.x? No joy, tried in an incognito session in Chrome and in a fresh install of Firefox... Basically running into a clobbering senario where openfirewall gets set to false. command=createPortForwardingRule&response=json&sessionkey=1stoChDJGiJpYn0eeuvg9qViP6k%3D&openfirewall=true&privateport=5900&publicport=5900&protocol=tcp&openfirewall=false&ipaddressid=f1fc5afe-db69-4093-a51d-570d5888ddca&virtualmachineid=717573a7-4287-4cdb-ae67-a008941b4f78&_=1338089707415 On Sat, May 26, 2012 at 9:52 PM, Will Chan <[email protected]> wrote: > Try refreshing your UI in case the javascript was cached on your browser. > That, or try a different one just in case. > > ________________________________________ > From: Jason Davis [[email protected]] > Sent: Saturday, May 26, 2012 9:38 AM > To: [email protected] > Subject: Re: Anyway to disable the firewall functionality provided by the > virtual router in 3.0.x? > > Right, let me show you what I have done: > > sharedFunctions.js > > //API calls > function createURL(apiName, options) { > if (!options) options = {}; > var urlString = clientApiUrl + "?" + "command=" + apiName > +"&response=json&se$ > > urlString = urlString + '&openfirewall=true'; > > if (cloudStack.context && cloudStack.context.projects && > !options.ignoreProje$ > urlString = urlString + '&projectid=' + > cloudStack.context.projects[0].id; > } > > return urlString; > } > > I then restarted the cloud-management daemon on my management server and > then logged in through the UI using a user account. > > I then go and add a new portforward rule for my instance. Here is the > output of api-server.log > > > command=createPortForwardingRule&response=json&sessionkey=QmObgzdyeCnC0a6Uyy%2BVIYZelWM%3D&openfirewall=true&privateport=80&publicport=80&protocol=tcp&openfirewall=false&ipaddressid=f1fc5afe-db69-4093-a51d-570d5888ddca&virtualmachineid=717573a7-4287-4cdb-ae67-a008941b4f78&_=1338049749681 > > So, looks like I need to find where the other "openfirewall=false" is. I've > double checked that I don't have another occurrence in sharedFunctions.js > so my guess is that it is in another file. > > Where... I'm not certain :) > > > On Sat, May 26, 2012 at 9:07 AM, Will Chan <[email protected]> wrote: > > > You want openfirewall=true. Or simply remove it as the default is to > open > > it. > > > > Will > > > > ________________________________________ > > From: Jason Davis [[email protected]] > > Sent: Friday, May 25, 2012 2:09 PM > > To: [email protected] > > Subject: Re: Anyway to disable the firewall functionality provided by the > > virtual router in 3.0.x? > > > > Hmm, I've tested this and I can confirm that in my api-log that I am > > passing the openfirewall command but when testing with-in the UI, it > still > > doesn't seem to create the proper firewall rules for me. > > > > On Fri, May 25, 2012 at 1:43 PM, Jason Davis <[email protected]> wrote: > > > > > Thanks! I'll give that a go. > > > > > > > > > On Fri, May 25, 2012 at 1:39 PM, Brian Federle < > [email protected] > > >wrote: > > > > > >> One idea might be to modify the createURL function, which every server > > >> call uses to generate a URL for the API call. openfirewall=false could > > be > > >> passed there and will apply to all actions in the UI. > > >> > > >> > > >> > > >> createURL is in /ui/scripts/sharedFunctions.js; modify urlString to > add > > >> additional params: > > >> > > >> > > >> > > >> //API calls > > >> > > >> function createURL(apiName, options) { > > >> > > >> if (!options) options = {}; > > >> > > >> var urlString = clientApiUrl + "?" + "command=" + apiName > > >> +"&response=json&sessionkey=" + g_sessionKey; > > >> > > >> > > >> > > >> urlString = urlString + '&openfirewall=false'; > > >> > > >> ... > > >> > > >> } > > >> > > >> > > >> > > >> Hope that helps! > > >> > > >> ________________________________________ > > >> > > >> From: Jason Davis [[email protected]] > > >> > > >> Sent: Thursday, May 24, 2012 3:01 PM > > >> > > >> To: [email protected]<mailto: > > >> [email protected]> > > >> > > >> Subject: Re: Anyway to disable the firewall functionality provided by > > the > > >> virtual router in 3.0.x? > > >> > > >> > > >> > > >> Any hints to where this configuration would be done :) > > >> > > >> > > >> > > >> Sent from my iPhone > > >> > > >> > > >> > > >> On May 24, 2012, at 4:32 PM, Will Chan <[email protected]<mailto: > > >> [email protected]>> wrote: > > >> > > >> > > >> > > >> > Ok, glad you clarified it for me. In 2.2.11+, all > > >> XXXPortForwardingRule and XXXLoadBalancer API calls automatically > called > > >> the XXXFirewallRule API. You could always turn that off by passing > > >> openfirewall=false in the create commands. Subsequently, the UI had > > >> supported both ways of doing this as you know already by using the > > >> firewall.rule.ui setting so people did not have to deal with this > split. > > >> In 3.0.x, the API remains unchanged, but the UI no longer supports > this > > >> and the 3.0.x UI always makes calls with openfirewall=false. > > >> > > >> > > > >> > > >> > To achieve what you want, you would need to tweak the UI to make > API > > >> calls with openfirewall=true (or remove it since the default is true) > > and > > >> change the UI to no longer show the firewall portion. Changing the > > network > > >> offering turns off and on the service and if you disable the firewall > > from > > >> the network offering, you will end up disabling the port forwarding > > feature > > >> I believe. > > >> > > >> > > > >> > > >> > The other option is to re-introduce this back into the CloudStack. > > >> > > >> > > > >> > > >> > -----Original Message----- > > >> > > >> > From: Jason Davis [mailto:[email protected]]<mailto:[mailto: > > >> [email protected]]> > > >> > > >> > Sent: Thursday, May 24, 2012 1:49 PM > > >> > > >> > To: [email protected]<mailto: > > >> [email protected]> > > >> > > >> > Subject: Re: Anyway to disable the firewall functionality provided > by > > >> the virtual router in 3.0.x? > > >> > > >> > > > >> > > >> > Well, I want it to behave as it did in 2.2.14-3.0.0. > > >> > > >> > > > >> > > >> > ie: I can provide isolation through portforwarding ranges and have > the > > >> firewall disabled. My concern is that when I upgrade to 3.0.2 that > I'll > > >> have to essentially re-teach my end users how to gain remote access to > > >> their VM instances. > > >> > > >> > > > >> > > >> > In the documentation and in previous builds, you could turn the > > >> firewall off entirely via a global setting. This is the functionality > I > > am > > >> wishing to accomplish. > > >> > > >> > > > >> > > >> > No firewall, just services like portforwarding, dhcp, dns, > > >> loadbalancing, source nat, static nat in my network offering. > > >> > > >> > > > >> > > >> > On Thu, May 24, 2012 at 3:45 PM, Will Chan <[email protected] > > >> <mailto:[email protected]>> wrote: > > >> > > >> > > > >> > > >> >> Can you describe what you would like to do? I thought for a moment > > >> > > >> >> you simply wanted the UI to act in the same way as in 2.2.x. > > >> > > >> >> However, from your response, it looks like you want to remove the > > >> > > >> >> firewall feature from the virtual router altogether, including all > > the > > >> port forwarding feature? > > >> > > >> >> > > >> > > >> >> Will > > >> > > >> >> > > >> > > >> >> -----Original Message----- > > >> > > >> >> From: Jason Davis [mailto:[email protected]]<mailto:[mailto: > > >> [email protected]]> > > >> > > >> >> Sent: Thursday, May 24, 2012 1:32 PM > > >> > > >> >> To: [email protected]<mailto: > > >> [email protected]> > > >> > > >> >> Subject: Re: Anyway to disable the firewall functionality provided > by > > >> > > >> >> the virtual router in 3.0.x? > > >> > > >> >> > > >> > > >> >> Ah so if I create my network offering via the API then I can > achieve > > >> > > >> >> what I want? > > >> > > >> >> > > >> > > >> >> If that's so, good enough :) I am more than happy to do API calls. > > >> > > >> >> > > >> > > >> >> /me goes to RTFM > > >> > > >> >> > > >> > > >> >> On Thu, May 24, 2012 at 3:30 PM, Will Chan <[email protected] > > >> <mailto:[email protected]>> wrote: > > >> > > >> >> > > >> > > >> >>> Since 3.0.x, that feature was turned off from the default UI and > > >> > > >> >>> expect everyone to use the firewall feature. The API still honors > > >> > > >> >>> the old functionality so you can always custom change the UI to > > >> > > >> >>> reflect the same behavior in 2.2.x. > > >> > > >> >>> > > >> > > >> >>> Will > > >> > > >> >>> > > >> > > >> >>> -----Original Message----- > > >> > > >> >>> From: Jason Davis [mailto:[email protected]]<mailto:[mailto: > > >> [email protected]]> > > >> > > >> >>> Sent: Thursday, May 24, 2012 12:28 PM > > >> > > >> >>> To: [email protected]<mailto: > > >> [email protected]> > > >> > > >> >>> Subject: Anyway to disable the firewall functionality provided by > > >> > > >> >>> the virtual router in 3.0.x? > > >> > > >> >>> > > >> > > >> >>> So, in 2.2.x with advanced networking you could disable the > firewall > > >> > > >> >>> by setting the global setting firewall.rule.ui.enabled to false. > I > > >> > > >> >>> am trying to replicate this functionality in my upgraded > development > > >> > > >> >>> instance > > >> > > >> >>> (2.2.14->3.0.2) but this global setting no longer exists in the > UI. > > >> > > >> >>> > > >> > > >> >>> I've also tried to create a new isolated networking offering with > > >> > > >> >>> the firewall functionality disabled. However, anytime I try this > the > > >> > > >> >>> firewall setting ends up being enabled anyway. > > >> > > >> >>> > > >> > > >> >>> Thanks! > > >> > > >> >>> Jason > > >> > > >> >>> > > >> > > >> >> > > >> > > >> > > > > > >
