Categories
Opensource

Debugging SELinux errors, and writing custom policies

Sometimes you find yourself trying to debug a problem with SELinux, specially during software development or while packaging new software features.

I have found this with neutron agents to happen quite often, as new system interactions are developed. Disabling selinux during development is generally a bad idea, because you’ll discover such problems later in time and under higher pressure (release deadlines).

Here I show a recipe, from Kashyap Chamarthy, to find out what rules are missing, and generate a possible SELinux policy:

Make sure selinux is enabled

sudo su -
setenforce 1

Clear your audit log, and supposing the problem was in neutron-dhcp-agent, restart it.

 > /var/log/audit/audit.log
systemctl restart neutron-dhcp-agent

Wait for the problem to be reproduced..

Find what you got, and create a reference policy

cat /var/log/audit/audit.log
cat /var/log/audit/audit.log | audit2allow -R

At that point, report a bug so you get those policies incorporated in advance. Give a good description of what’s blocked by the policies, and why does it need to be unblocked. Now you can generate a policy, and install it locally:

You can generate a SELinux loadable module to move on without disabling the whole SELinux:

cat /var/log/audit/audit.log | audit2allow -a -M neutron

And you can also install it in runtime

semodule -i neutron.pp

Restart neutron-dhcp-agent (or re-trigger the problem to make sure it’s fixed)

systemctl restart neutron-dhcp-agent
Categories
Network Opensource Openstack

Neutron security_group_rules_for_devices RPC rewrite

During scalability tests with openstack/neutron we found that the

During scalability tests with openstack/neutron we found that the security_group_rules_for_devices RPC, which is transmitted from neutron-server to the neutron L2 agents during port changes, grew exponentially.

We filled a spec for juno-3, the effort leaded by shihanzhang and me can be tracked here:

I have written a test and a little -dirty- benchmark (https://review.openstack.org/#/c/115575/1/neutron/tests/unit/test_security_groups_rpc.py line 418) to check the results and make sure the new RPC actually performs better.

Here are the results:

Message size (Y) vs. number of ports (X) graph:

RPC execution time in seconds (Y) vs. number of ports (X):

Categories
Network Openstack

Using multiple external networks in OpenStack Neutron

This document talks about the reference implementation.

Starting on Icehouse release, a single neutron network node using ML2+ovs or OVS, can handle several external networks. I haven’t found a lot of documentation about it, but basically, here’s how to do it, assuming this: you start from a single external network, which is connected to ‘br-ex’‘  you want to attach the new external network to ‘‘eth1’. In the network node (were neutron-l3-agent, neutron-dhcp-agent, etc.. run): Create a second OVS bridge, which will provide connectivity to the new external network:

ovs-vsctl add-br br-eth1
ovs-vsctl add-port br-eth1 eth1
ip link set eth1 up

(Optionally) If you want to plug a virtual interface into this bridge and add a local IP on the node to this network for testing:

ovs-vsctl add-port br-eth1 vi1 -- set Interface vi1 \ 
                                  type=internal
ip addr add 192.168.1.253/24 dev vi1

Edit your /etc/neutron/l3_agent.ini , and set/change:

gateway_external_network_id =
external_network_bridge =

This change tells the l3 agent that it must relay on the physnet<->bridge mappings at /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini it will automatically patch those bridges and router interfaces around. For example, in tunneling mode, it will patch br-int to the external bridges, and set the external ‘‘q’‘router interfaces on br-int. Edit your /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini to map ‘‘logical physical nets’ to ‘‘external bridges’

bridge_mappings = physnet1:br-ex,physnet2:br-eth1

Restart your neutron-l3-agent and your neutron-openvswitch-agent

neutron net-create ext_net \
            --provider:network_type flat \
            --provider:physical_network physnet1 \
            --router:external=True

neutron net-create ext_net2 \
                    --provider:network_type flat \
                    --provider:physical_network physnet2 \
                    --router:external=True

And for example create a couple of internal subnets and routers:

And for example create a couple of internal subnets and routers:

# for the first external net
neutron subnet-create ext_net \
          --gateway 172.16.0.1 172.16.0.0/24 \
          --enable_dhcp=False

# here the allocation pool goes explicit. all the IPs available..
neutron router-create router1
neutron router-gateway-set router1 ext_net
neutron net-create privnet
neutron subnet-create privnet \
                 --gateway 192.168.123.1 192.168.123.0/24 \
                 --name privnet_subnet
neutron router-interface-add router1 privnet_subnet

# for the second external net
neutron subnet-create ext_net2 \
  --allocation-pool start=192.168.1.200,end=192.168.1.222 \
  --gateway=192.168.1.1 --enable_dhcp=False 192.168.1.0/24
neutron router-create router2
neutron router-gateway-set router2 ext_net2
neutron net-create privnet2
neutron subnet-create privnet2 --gateway 192.168.125.1 192.168.125.0/24 --name privnet2_subnet
neutron router-interface-add router2 privnet2_subnet
Categories
Opensource Projects

KiCad Win32 full scripting support

Brian Sidebotham and and Dick Hollenbeck just did it!,

Long story short: A few months ago we suffered as soon as we discovered that the standard python binaries for win32 were MSVC built, and they had runtime discrepancies with some modules or executables built from mingw (wxpython support), that always ended execution with a segmentation fault.

At that time I was getting “a little” busy, but dick & brian kept working. They discovered that python has no support to build outside MSVC on windows(really, it doesn’t), so dick started python-a-mingw-us project, which cmake-compiles python 2.7.4 and builds a set of win32 binary installers or python 2.7.4, fully mingw runtime compatible. After that, Brian kept working on his kicad winbuilder, yesterday he announced that he got it working in full : wxpython, scripting, everything.