Unfortunately there's no supported way to remove it. Reinstalling XS is required. :-(
Best regards, Kirk On 09/10/2014 11:10 PM, Carlos Reátegui wrote: > Is there a way to uninstall the CSP? > > Although, I do remember encountering a problem adding hosts without the CSP > on a different setup. > > > On Sep 10, 2014, at 11:02 PM, Kirk Kosinski <[email protected]> wrote: > >> I (vaguely) recall seeing something like this. I think you aren't >> supposed to install the CSP on hosts in a basic zone without SG. Some >> but not all iptables get programmed for some reason, and it doesn't >> work. I would check if it works on a host without CSP. It definitely >> isn't needed in such a configuration anyway. >> >> Best regards, >> Kirk >> >> On 09/10/2014 10:26 PM, Jayapal Reddy Uradi wrote: >>> Hi, >>> >>> iptables rules are configured on the host that means CSP is there. >>> >>> The setup is basic shared network with out security groups but there are >>> SG rules configured for the VM in the host and there is no ingress/egress >>> rules config option. >>> Not sure about with out SG configuring rules for VM is a bug. >>> >>> Thanks, >>> Jayapal >>> >>> >>> On 11-Sep-2014, at 10:27 AM, Kirk Kosinski <[email protected]> >>> wrote: >>> >>>> Hi, Carlos. Did you install the CSP on your XS hosts? Also is Open >>>> vSwitch enabled or disabled? >>>> >>>> Best regards, >>>> Kirk >>>> >>>> On 09/10/2014 02:55 PM, Carlos Reategui wrote: >>>>> Hi All, >>>>> This is a problem I have had for a while and worked around but would like >>>>> to get a proper solution for. I have configured a basic shared network >>>>> without security groups. The hosts are Xen 6.0.2. I am currently on 4.3 >>>>> but had this problem previously on 4.1.x and 4.2.x also. >>>>> >>>>> The problem is that the iptables firewall is not getting configured >>>>> properly on the hosts and therefore I am unable to connect to any of the >>>>> VM's on that particular host. My current solution is to have a crontab >>>>> every 5 minutes issue an "/etc/init.d/iptables stop". The reason I have >>>>> to >>>>> have it on a cron is that every time I create a new instance, the >>>>> cloudstack management server also sends a command to configure the >>>>> firewall >>>>> which also turns it back on (I guess I could also put an exit near the >>>>> top >>>>> of the iptables script but that is still a workaround). My network >>>>> offering does not have security groups so, as expected, I don't have a >>>>> means to edit ingress/egress rules. >>>>> >>>>> Has anyone else run into this? Is this a bug or something that I have not >>>>> properly configured? >>>>> >>>>> Here is the output of the firewall on one of the hosts after creating a >>>>> new >>>>> instance: >>>>> # iptables -L -n >>>>> Chain INPUT (policy ACCEPT) >>>>> target prot opt source destination >>>>> >>>>> Chain FORWARD (policy ACCEPT) >>>>> target prot opt source destination >>>>> BRIDGE-FIREWALL all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV >>>>> match --physdev-is-bridged >>>>> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match >>>>> --physdev-out eth2+ --physdev-is-bridged >>>>> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match >>>>> --physdev-out eth6+ --physdev-is-bridged >>>>> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match >>>>> --physdev-out eth5+ --physdev-is-bridged >>>>> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match >>>>> --physdev-out eth7+ --physdev-is-bridged >>>>> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match >>>>> --physdev-out eth3+ --physdev-is-bridged >>>>> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match >>>>> --physdev-out eth1+ --physdev-is-bridged >>>>> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match >>>>> --physdev-out eth4+ --physdev-is-bridged >>>>> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match >>>>> --physdev-out bond0+ --physdev-is-bridged >>>>> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match >>>>> --physdev-out eth0+ --physdev-is-bridged >>>>> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match >>>>> --physdev-out bond1+ --physdev-is-bridged >>>>> DROP all -- 0.0.0.0/0 0.0.0.0/0 >>>>> >>>>> Chain OUTPUT (policy ACCEPT) >>>>> target prot opt source destination >>>>> >>>>> Chain BRIDGE-DEFAULT-FIREWALL (1 references) >>>>> target prot opt source destination >>>>> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state >>>>> RELATED,ESTABLISHED >>>>> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match >>>>> --physdev-is-bridged udp spt:68 dpt:67 >>>>> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match >>>>> --physdev-is-bridged udp spt:67 dpt:68 >>>>> >>>>> Chain BRIDGE-FIREWALL (1 references) >>>>> target prot opt source destination >>>>> BRIDGE-DEFAULT-FIREWALL all -- 0.0.0.0/0 0.0.0.0/0 >>>>> i-3-93-def all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV >>>>> match >>>>> --physdev-in vif20.0 --physdev-is-bridged >>>>> i-3-93-def all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV >>>>> match >>>>> --physdev-out vif20.0 --physdev-is-bridged >>>>> >>>>> Chain i-3-93-VM (1 references) >>>>> target prot opt source destination >>>>> >>>>> Chain i-3-93-VM-eg (1 references) >>>>> target prot opt source destination >>>>> >>>>> Chain i-3-93-def (2 references) >>>>> target prot opt source destination >>>>> RETURN udp -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match >>>>> --physdev-in vif20.0 --physdev-is-bridged set i-3-93-VM src udp dpt:53 >>>>> DROP all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match >>>>> --physdev-in vif20.0 --physdev-is-bridged !set i-3-93-VM src >>>>> DROP all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match >>>>> --physdev-out vif20.0 --physdev-is-bridged !set i-3-93-VM dst >>>>> i-3-93-VM-eg all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV >>>>> match --physdev-in vif20.0 --physdev-is-bridged set i-3-93-VM src >>>>> i-3-93-VM all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match >>>>> --physdev-out vif20.0 --physdev-is-bridged >>>>> >>>>> Thanks, >>>>> Carlos >>>>> >>> >
