[
https://issues.apache.org/jira/browse/CLOUDSTACK-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16281862#comment-16281862
]
ASF GitHub Bot commented on CLOUDSTACK-10177:
---------------------------------------------
bwsw commented on issue #2355: CLOUDSTACK-10177: Only pass IPv6 address to
Security Group Python scr…
URL: https://github.com/apache/cloudstack/pull/2355#issuecomment-349971327
@wido I found your commit eaffe3a13bdbcc03ed4af1f1115c147f62e3de10 in
wido/ipv6-icmpv6all. Together with current PR, I believe, they make ipv6 in
4.10 functional, unfortunately your PR wido/ipv6-icmpv6all wasn't included in
4.10 by unknown reason.
I suppose it's wise to keep current PR, because together:
1. this PR (to merge to 4.11)
2. wido/ipv6-icmpv6all (merged to 4.11)
3. CLOUDSTACK-10138 (merged to 4.11)
they do all necessary IPv6+sg work. But I still feel that in
security_group.py code should include try-except:
```python
for ip in rule['ipv4']:
try:
if protocol == 'all':
execute('iptables -I ' + vmchain + ' -m state --state
NEW ' + direction + ' ' + ip + ' -j ' + action)
elif protocol != 'icmp':
execute('iptables -I ' + vmchain + ' -p ' + protocol + '
-m ' + protocol + ' --dport ' + range + ' -m state --state NEW ' + direction +
' ' + ip + ' -j ' + action)
else:
execute('iptables -I ' + vmchain + ' -p icmp --icmp-type
' + range + ' ' + direction + ' ' + ip + ' -j ' + action)
except:
pass
for ip in rule['ipv6']:
try:
if protocol == 'all':
execute('ip6tables -I ' + vmchain + ' -m state --state
NEW ' + direction + ' ' + ip + ' -j ' + action)
elif 'icmp' != protocol:
execute('ip6tables -I ' + vmchain + ' -p ' + protocol +
' -m ' + protocol + ' --dport ' + range + ' -m state --state NEW ' + direction
+ ' ' + ip + ' -j ' + action)
else:
if range == 'any':
execute('ip6tables -I ' + vmchain + ' -p icmpv6 ' +
direction + ' ' + ip + ' -j ' + action)
else:
execute('ip6tables -I ' + vmchain + ' -p icmpv6
--icmpv6-type ' + range + ' ' + direction + ' ' + ip + ' -j ' + action)
except:
pass
```
at least because user can pass wrong icmp type/code and we should handle it
at least skipping but not failing all security group configuration. So if you
could improve current PR with try-catch I think it's more reasonable than
diving into: https://github.com/apache/cloudstack/pull/2320 as it includes
several cherry-picks which already in master and it is quite messy and I
believe it shouldn't be merged to master. Just for those who willing to make
4.10 work.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> NPE when programming Security Groups with KVM
> ---------------------------------------------
>
> Key: CLOUDSTACK-10177
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10177
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
> Affects Versions: 4.10.0.0
> Environment: Ubuntu 16.04 - KVM
> Reporter: Wido den Hollander
> Labels: ipv6, kvm, security-groups
>
> On a Hypervisor we saw the programming of Security Groups fail and I am not
> sure yet why:
> {quote}2017-12-06 14:10:31,095 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-15:null) (logid:e68a57b9) Request:Seq
> 1-3318027025465216281: { Cmd , MgmtId: 90520741056852, via: 1, Ver: v1,
> Flags: 100111,
> [{"com.cloud.agent.api.SecurityGroupRulesCmd":{"guestIp":"62.221.192.7","vmName":"i-
> 4-6-VM","guestMac":"1e:00:4f:00:00:f9","signature":"4134ed9a39aa2aa85620780ce4b7bc27","seqNum":14,"vmId":6,"msId":90520741056852,"ingressRuleSet":[{"proto":"tcp","startPort":22,"endPort":22}],"egressRuleSet":[],"wait":0}}]
> }
> 2017-12-06 14:10:31,095 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-15:null) (logid:e68a57b9) Processing command:
> com.cloud.agent.api.SecurityGroupRulesCmd
> 2017-12-06 14:10:31,095 DEBUG [kvm.resource.LibvirtConnection]
> (agentRequest-Handler-15:null) (logid:e68a57b9) Looking for libvirtd
> connection at: qemu:///system
> 2017-12-06 14:10:31,098 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-15:null) (logid:e68a57b9) Executing:
> /usr/share/cloudstack-common/scripts/vm/network/security_group.py
> add_network_rules --vmname i-4-6-VM --vmid 6 --vmip 62.221.192.7 --vmip6 null
> --sig 413
> 4ed9a39aa2aa85620780ce4b7bc27 --seq 14 --vmmac 1e:00:4f:00:00:f9 --vif vnet6
> --brname cloudbr0 --nicsecips 0: --rules I:tcp:22:22:0.0.0.0/0,NEXT;
> 2017-12-06 14:10:31,098 WARN [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-15:null) (logid:e68a57b9) Exception:
> /usr/share/cloudstack-common/scripts/vm/network/security_group.py
> add_network_rules --vmname i-4-6-VM --vmid 6 --vmip 62.221.192.7 --vmip6 null
> --sig 4134ed9a39aa2aa85620780ce4b7bc27 --seq 14 --vmmac 1e:00:4f:00:00:f9
> --vif vnet6 --brname cloudbr0 --nicsecips 0: --rules
> I:tcp:22:22:0.0.0.0/0,NEXT;
> java.lang.NullPointerException
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1012)
> at com.cloud.utils.script.Script.execute(Script.java:214)
> at com.cloud.utils.script.Script.execute(Script.java:182)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.addNetworkRules(LibvirtComputingResource.java:3429)
> at
> com.cloud.hypervisor.kvm.resource.wrapper.LibvirtSecurityGroupRulesCommandWrapper.execute(LibvirtSecurityGroupRulesCommandWrapper.java:57)
> at
> com.cloud.hypervisor.kvm.resource.wrapper.LibvirtSecurityGroupRulesCommandWrapper.execute(LibvirtSecurityGroupRulesCommandWrapper.java:36)
> at
> com.cloud.hypervisor.kvm.resource.wrapper.LibvirtRequestWrapper.execute(LibvirtRequestWrapper.java:75)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1369)
> at com.cloud.agent.Agent.processRequest(Agent.java:525)
> at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:833)
> at com.cloud.utils.nio.Task.call(Task.java:83)
> at com.cloud.utils.nio.Task.call(Task.java:29)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2017-12-06 14:10:31,098 WARN
> [resource.wrapper.LibvirtSecurityGroupRulesCommandWrapper]
> (agentRequest-Handler-15:null) (logid:e68a57b9) Failed to program network
> rules for vm i-4-6-VM
> 2017-12-06 14:10:31,098 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-15:null) (logid:e68a57b9) Seq 1-3318027025465216281: {
> Ans: , MgmtId: 90520741056852, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.SecurityGroupRuleAnswer":{"logSequenceNumber":14,"vmId":6,"reason":"PROGRAMMING_FAILED","result":false,"details":"programming
> network rules failed","wait":0}}] }
> {quote}
> I see the vmip6 being null and after setting a IPv6 address for the Instance
> it suddenly worked.
> However, I was not yet able in the code to figure out why this is a NPE in
> com.cloud.utils.Script
> It has a issue with getting back output from ProcessBuilder.
> Creating this ticket to make sure it's tracked, but I don't know what is
> happening yet.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
