Abstract common LDAP code to module.

[puck]

Net::LDAP::Server::Test binds to IPv6 by default if IPv6 is enabled, but Net::LDAP uses 'localhost' which resolves to an IPv4 address. Even when I switched the call to Net::LDAP->new() to use ip6-localhost it failed elsewhere due to RT using 127.0.0.1.

[cbrandtbuffalo]

Hmm, this makes me wonder what else currently expects localhost to be '127.0.0.1' vs. '::1'. Assuming you ran RTs tests on your IPv6 enabled system, are the LDAP tests the only ones that failed?

[puck]

I'm running the tests on a dual stack system. The LDAP tests are the only ones that fail for me without this patch.

A quick grep on 5.0-trunk shows this:

puck@dirk:~/personal/RT/rt$ grep -r "127\.0\.0\.1" * | grep -v "t/data/emails"
docs/web_deployment.pod:    spawn-fcgi -u www-data -g www-data -a 127.0.0.1 -p 9000 \
docs/web_deployment.pod:            fastcgi_pass 127.0.0.1:9000;
lib/RT/Interface/Web.pm:to handle common problems such as localhost vs 127.0.0.1
lib/RT/Interface/Web.pm:    $uri->host('127.0.0.1') if $uri->host eq 'localhost';
sbin/rt-setup-fulltext-index:    $url = 'sphinx://127.0.0.1:3312/rt'
sbin/rt-setup-fulltext-index.in:    $url = 'sphinx://127.0.0.1:3312/rt'
t/fts/indexed_sphinx.t:        url            => "sphinx://127.0.0.1:$port/rt",
t/externalauth/ldap_escaping.t:            'server'          => "127.0.0.1:$ldap_port",
t/externalauth/ldap_privileged.t:            'server'          => "127.0.0.1:$ldap_port",
t/externalauth/ldap_group.t:            'server'          => "127.0.0.1:$ldap_port",
t/externalauth/ldap.t:            'server'          => "127.0.0.1:$ldap_port",
t/externalauth/ldap.t:            'server'          => "127.0.0.1:$ldap_port",
t/externalauth/ldap_email_login.t:            'server'          => "127.0.0.1:$ldap_port",
puck@dirk:~/personal/RT/rt$ 

[puck]

I can't remember what broke when I tried using ip6-localhost, but switching to that will cause breakage on hosts which don't have IPv6 enabled.

[puck]

Oh, and given the amount of repeated code, standing up a test LDAP server feels like a good thing to abstract into a module. :)

[cbrandtbuffalo]

Oh, and given the amount of repeated code, standing up a test LDAP server feels like a good thing to abstract into a module. :)

Yeah, that's a good thought. We have various helper modules for that reason, like lib/RT/Test.pm, lib/RT/Test/Email.pm, etc. Did you want to take a shot at updating your branch to move the that bit of LDAP server code to a module?

[puck]

That's what I get for opening my mouth. ;) I'm working on a new lib/RT/Test/LDAP.pm file. Fortunately this is trivial to run tests for!

[puck]

I've pushed a commit which creates RT::Test::LDAP and changes all the tests for LDAP (ExternalAuth and LDAPImport) to use it.

[sunnavy]

Correct me if I missed something, I think it's because Debian has net.ipv6.bindv6only set to 1 by default, so IPv4 can't be mapped to IPv6?

[mzagrabe]

Correct me if I missed something, I think it's because Debian has net.ipv6.bindv6only set to 1 by default, so IPv4 can't be mapped to IPv6?

Does it? I'm not seeing that being the default on any of my Debian systems.

z@gila:~$ cat /proc/sys/net/ipv6/bindv6only
0

[mzagrabe]

I should have also showed...

z@gila:~$ cat /proc/sys/net/ipv6/bindv6only
0
z@gila:~$ sudo rg bindv6 /etc
z@gila:~$ 

[sunnavy]

Hmm, does LDAP tests still fail for you? I thought IPv4 was supported when bindv6only is off via IPv4-mapped addresses.

I have both IPv4 and IPv6 addresses and tests work for me.

[puck]

On my ~20 year old Debian box that has been running Sid for most of that time, net.ipv6.bindv6only is set to 1. My somewhat newer laptop with Debian Bookworm (must upgrade to Trixie now), has it set to 0. This might be lies, but my Sid box has this claim in the sysctl.d file that sets this:

# When IPV6_V6ONLY is enabled, daemons interested in both IPv4 and IPv6
# connections must open two listening sockets.
# This is the default behaviour of all modern operating systems.

I work on packaging and RT on the Debian Sid box.

I could try disabling bindv6only, but also, my PR fixes this behaviour no matter what bindv6only is set to, and removes duplicated code.

[puck]

I'm also open to disabling bindvonly on the basis that it might be a historical quirk of the machine I use to do this work.

[sunnavy]

Assuming net.ipv6.bindv6only is defaulted to 0 now, I think we can safely skip forcing IPv4.

On the other hand, I still think abstracting the duplicated code into RT::Test::LDAP is a great idea. I'd be glad to merge the change once you've updated the code.

[puck]

Disabling net.ipv6.bindv6only allows the tests to pass for me.

I'm getting some interesting errors relating to DBIx::SearchBuilder with RT::Test::LDAP currently, so working on those, when it is ready I'll update this PR.

[puck]

Oops, I thought I was trying to merge into 5.0-trunk. I'll retry that rebase.

[puck]

It turns out the issue I was having with DBIx::SearchBuilder was fixed in 5b9c371 and I just hadn't rebased my branch for a while. I'm now passed that, and the tests are passing for me again.