[apparmor] [patch] Test libapparmor test_multi tests against logparser.py

[Christian Boltz]

Hello,

Am Montag, 10. August 2015 schrieb Steve Beattie:
> [I haven't gotten to reviewing this patch yet, but was grabbing it to
> look at later and wanted to respond to a couple of the comments...]

Any progress on the patch review?
If nobody objects, I'll commit as Acked-by <timeout> on friday.

> On Sun, Jul 19, 2015 at 01:20:20PM +0200, Christian Boltz wrote:
> > An interesting special case are exec events with network details:
> >     testcase01.in, testcase12.in, testcase13.in
> > 
> > Are those really real-world events (family="family" and
> > sock_type="unknown(1234)" look a bit strange) or some handmade,
> > invalid logs?
> 
> Yes, some of the original test messages that the log parsing component
> of libapparmor were entirely synthetic. I purged/fixed some of them
> because in fact they weren't accurate, but others have likely lived
> on. It's hard to exactly tell the history across (a) movement of the
> log parsing stuff within the repository, (b) a conversion from svn to
> bzr, and (c) a move from a private svn tree to a public one.

Good to know.

> > BTW: libapparmor from 2.9.2 fails on the dmesg-based tests (I didn't
> > test with the current 2.9 branch).
> 
> Umm, what? I'm not exactly sure what you mean by this. I do know that
> my personal jenkins infrastructure triggers builds off of every trunk
> and 2.9 branch commit and as part of the binary builds involved,
> make check gets run in the libapparmor tree and fails the build if
> the tests fail.  (In fact the tests get run at least three times per
> x86 architecture+ubuntu release; once for the build tree that has
> python disabled, and once for each supported python 2 and 3 release;
> the python bindings are also exercised for the latter.)
> 
> I also verified manually that the succeed from unpacking the apparmor
> 2.9.2 tarball and running:
> 
>   cd apparmor-2.9.2/libraries/libapparmor/ ; ./autogen.sh && \
>     ./configure --with-perl --with-python --prefix=/usr && make &&
> make check
> 
> So I'd like to know what's different about your environment that's
> causing them to fail. (To be fair, there are a lot of sharp edges
> hiding in there -- thanks, autotools! -- particularly around
> exercising the python bindings and ensuring that the same python
> version is used to drive the tests as was used to create the tested
> objects.)

As discussed on IRC, I don't remember the exact failure.

Running your set of commands on the current 2.9 branch resulted in 

...
config.status: creating swig/python/test/test_python.py
chmod +x test_python.py
FAIL: test_python.py
============================================================================
Testsuite summary for 
============================================================================
# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See swig/python/test/test-suite.log
============================================================================
Makefile:540: die Regel für Ziel »test-suite.log« scheiterte
make[5]: *** [test-suite.log] Fehler 1
make[5]: Verzeichnis »/home/cb/apparmor/2.9-branch/libraries/libapparmor/swig/python/test« wird verlassen
...

and test-suite.log says

...
FAIL: test_python.py
====================

Traceback (most recent call last):
  File "./test_python.py", line 13, in <module>
    import ctypes
  File "/usr/lib64/python3.4/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ImportError: /usr/lib64/python3.4/lib-dynload/_ctypes.cpython-34m.so: undefined symbol: _PyTraceback_Add
FAIL test_python.py (exit status: 1)



That could be a side effect of my outdated tumbleweed installation (and
installing some newer packages which didn't cause dependency issues, but
could still introduce problems because of the gcc5 update etc.).
I should really find some time to update to the latest version...

In other words: if it works for you, feel free to ignore this for now.


Regards,

Christian Boltz
-- 
> gibt es einen Unterschied zwischen NAT und Masquerading?
Ja, bei "Masquerading" vertippe ich mich laufend, deshalb schreibe ich
lieber "NAT".        [> Thorsten Haude und Patrick Hess in suse-linux]