It seems I'm currently the only one interested on this topic, but I
will update the list anyway :)
I was able to implement solution b) quite easily by:
* installing ulogd2 on the network nodes
* modify rootwrap.d/*.filter, replacing for all "IpFilter" commands
"ip" with "/usr/local/sbin/ip_neutron_wrapper" script
The "ip_neutron_wrapper" script is a wrapper around "ip" that
basically check if a router namespace is created or deleted, and in
case starts/stop ulogd on that namespace. It's pretty simple:
#!/bin/bash
# This wrapper is used to ensure an instance of ulogd daemon is
# running on each router namespace that is created.
ULOGD=/usr/sbin/ulogd
if [ "$1" == "netns" -a "$2" == "add" ]
then
# A new namespace is created.
# Run the requested command.
ip $@
rc=$?
ns=$3
# Check if we are creating a router namespace
if [ -n "$ns" ] && expr match $ns qrouter- >& /dev/null
then
# Router namespace. Run ulogd
ip netns exec $ns $ULOGD -d -p /run/ulogd.$ns.pid -u ulog
fi
exit $rc
elif [ "$1" == "netns" -a "$2" == "delete" ]
then
# Namespace deleted, *first* kill ulogd, then remove the namespace
ns=$3
if [ -n "$ns" -a -f /run/ulogd.$ns.pid ]
then
kill $(cat /run/ulogd.$ns.pid)
fi
exec ip $@
else
exec ip $@
fi
This seems to work, but I haven't done any extensive testing.
Cheers,
Antonio
On Fri, Jul 31, 2015 at 5:48 PM, Antonio Messina
<antonio.s.mess...@gmail.com> wrote:
> I've tested briefly ulogd, and it basically works.
>
> The only issue is that the "ulogd" daemon needs to run on the
> qrouter-<uuid> namespace, therefore neutron should start ulogd daemon
> on a router namespace whenever is created (and deleted whenever the
> router is deleted).
>
> Alternative solutions:
>
> a) in case neutron supports "triggers" (but I don't think so), e.g.
> shell commands that are executed whenever a namespace is created,
> startup of ulogd could be executed by the trigger
> b) update rootwrap IpFilter to use a wrapper around ip instead of
> "ip". The wrapper should know what to do: run ulogd if "ip netns add"
> is called, kill it if "ip netns delete" is called
> c) [UGLY]: run a cron every tot seconds to ensure every qrouter-<uuid>
> namespace has an instance of ulogd running on it.
>
> Other suggestions?
>
> .a.
>
>
> On Mon, Jul 27, 2015 at 11:50 AM, Antonio Messina
> <antonio.s.mess...@gmail.com> wrote:
>> On Thu, Jul 23, 2015 at 3:54 PM, Alvise Dorigo <alvise.dor...@pd.infn.it>
>> wrote:
>>> If the VM doesn't have a floating IP, the Y IP address that is exposed on
>>> the internet (and therefore the one that will be commuticated to the
>>> security people) is the one of the OpenStack router.
>>>
>>> Given the private IP of the machine we are able to find the UUID of the VM
>>> (even if this was already deleted) and then the id of the relevant user who
>>> created it.
>>> But the problem is how to find this private IP address.
>>
>> Interesting: how do you do it? In Kilo, apparently, the ports are
>> deleted also from the DB, do you have some sort of trigger? And how is
>> the mapping between port and instance id done?
>>
>> For your question, I guess the only solution is to periodically save
>> the output of "conntrack -L" on the network node, to be run *within*
>> the router namespace.
>>
>> A possible solution (that I haven't tested yet), is to use ulogd
>> https://home.regit.org/2014/02/logging-connection-tracking-event-with-ulogd/
>>
>> .a.
>>
>> --
>> antonio.s.mess...@gmail.com
>> antonio.mess...@uzh.ch +41 (0)44 635 42 22
>> S3IT: Service and Support for Science IT http://www.s3it.uzh.ch/
>> University of Zurich
>> Winterthurerstrasse 190
>> CH-8057 Zurich Switzerland
>
>
>
> --
> antonio.s.mess...@gmail.com
> antonio.mess...@uzh.ch +41 (0)44 635 42 22
> S3IT: Service and Support for Science IT http://www.s3it.uzh.ch/
> University of Zurich
> Winterthurerstrasse 190
> CH-8057 Zurich Switzerland
--
antonio.s.mess...@gmail.com
antonio.mess...@uzh.ch +41 (0)44 635 42 22
S3IT: Service and Support for Science IT http://www.s3it.uzh.ch/
University of Zurich
Winterthurerstrasse 190
CH-8057 Zurich Switzerland
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
