Activate running LDAP tests for GH actions

[kevinpapst]

Enables research on further issues. See #24

This is me, poking around in an existing CI system with existing tests which I hardly understand.

I cannot get the iptables rules to import, maybe some docker issue or something simple that I just don't see.
I don't have experience with iptables / iptables.restore, so I give up and wait for someone who has an idea.

At least the test results show that there is an issue in 8.1 that is covered by the tests, as the failures change:

• 7.3: Tests: 522, Assertions: 1330, Failures: 25, Skipped: 5.
• 7.4: Tests: 522, Assertions: 1330, Failures: 25, Skipped: 5.
• 8.0: Tests: 522, Assertions: 1327, Errors: 1, Failures: 24, Skipped: 5.
• 8.1: Tests: 522, Assertions: 795, Errors: 177, Failures: 16, Skipped: 1.

[Ocramius]

uh-oh, all the phpvfscomposer:// failures seem to be related to composer/composer:2.2.0 and similar releases. @asgrim do you have some pointers? You've seen that before...

[asgrim]

uh-oh, all the phpvfscomposer:// failures seem to be related to composer/composer:2.2.0 and similar releases. @asgrim do you have some pointers? You've seen that before...

Hmm, I don't see anything specifically that could be caused by the phpvfscomposer:// thing; you will of course see it in the stack trace, but that is expected; the failures I saw were very edge case, these just looks like regular test failures?

22) LaminasTest\Ldap\SearchTest::testReverseSortingWithSearchEntriesShortcut
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'e'
+'mylocation2'

Error: /github/workspace/test/SearchTest.php:377
phpvfscomposer:///github/workspace/vendor/phpunit/phpunit/phpunit:91

[kevinpapst]

This doesn't work, the rules are not accepted, no matter what I tried:

iptables-restore v1.8.4 (legacy): iptables-restore: unable to initialize table 'filter'
# Generated by iptables-save v1.4.21 on Fri Sep 29 15:37:54 2017

Error occurred at line: 2

I tested the rule on another system and it was successful, so my guess is that this is some kind of docker issue that I don't understand. I extracted the rules to a different file, just for the sake of testing, because nothing else worked....

All ReconnectTest issues are caused by this problem.

[kevinpapst]

This DB_CONFIG file doesn't exist at multiple locations and I couldn't find it on my Ubuntu systems as well. New Ubuntu system have the config extracted in the filesystem, maybe the file is obsolete nowadays?
Besides, the manpage says that the file only applies to bdb (Berkley) config backend. But we have hdb configured as backend. So I guess it can be safely removed.

[kevinpapst]

If you check the test failures, there are only 2 failing categories:

• ReconnectTest: this one is caused by the iptables problem (explained above: rules cannot be imported)
• SearchTest: seems to be a logical issue, maybe caused by a different OpenLDAP version/default configuration

[kevinpapst]

@heiglandreas @Maks3w both of you worked on the Laminas LDAP tests in the past. Could you probably spare some minutes and help me fixing the Github action integration of the LDAP rules for PHP 8.1?

[heiglandreas]

Sure. How, where and when?

[kevinpapst]

Well, background story: we are are stuck with a broken/non-working LDAP package on 8.1. As the LDAP functions changed their signatures in 8.1 we have to apply some critical changes, which obviously should be covered by tests.
These tests currently do not work after the migration from Travis to Github actions.

I was able to re-activate most tests. But there is one specific set of tests (which I documented above) in the integration testsuite that performs real connection tests. These connection tests rely on the import of iptable rules, which I cannot get to work. The import fails and after some hours of try&error I had to give up. Now I am hoping that someone can help me to fix the test problem , so I can afterwards start fixing the real issue with 8.1

EDIT: and thanks for your quick response 👍

[heiglandreas]

Looks like the reconnect-test issues are caused by the hack that we used previously to drop the flows for the LDAP-Port from the TCP-State table of the kernel does not work any more as it requires root access which we do not seem to have. And docker is much more restricted in what we can do to the actual kernel...

I'll see how we can find a way to get around that...

[heiglandreas]

It looks like the easiest would be to use a separate container for running the LDAP-Server as well as the webserver to initiate dropping the TCP-Connection to that server. That way the container can be ran with -cap-add SYS_ADMIN --cap-add NET_ADMIN (which might also solve the issues with setting the IP-Table rules) which should allow to actually drop the connection.

Drawback seems to be that

• it needs to be ran manually (see https://github.community/t/how-to-run-privileged-docker-container/16431) which is kinda dirty.
• It also means that we need to build and host a separate image somewhere and
• It means that we run one container for the whole of the matrix so we need to possibly handle the dropping more carefully to not drop the wrong connection. Or we need a way to start the container from the pre-install script. Any hints on that, anyone (@Ocramius, @MWOP, @asgrim)?

[Ocramius]

Q: why do we need privileged network access at all? Isn't an LDAP server just a normal TCP/UDP server listening on some port?

[heiglandreas]

If we want to continue testing that the lib works when network connections to the LDAP server are dropped (and other network quirkeries) we need to be able to acrually drop the connection on the server side. Which requires access to the networking stack which in turn requires privileged access.

So either we find a way to get privileged access or we drop the tests around failing networks.

[Ocramius]

Makes sense, thanks!

As for starting docker containers manually, I kinda do it all the time for work, but it isn't really laminas-ci friendly 😬

Laminas-ci allows to run some pre-start hooks, but those scripts are run from within the CI container 🤔

[kevinpapst]

What about being pragmatic here, grouping the test into two testsuites and concentrating on the ones we can adjust/fix now? Then the way would be open to address the PHP 8.1 issues.

If we keep on trying to fix these networks tests first, then Laminas LDAP might be incompatible with PHP 8.1 for weeks ahead...while falsly announcing that it is.

[kevinpapst]

As my suggestion with the two test suites was added by @heiglandreas we can close this PR now and work on #27