Closed aellwein closed 3 years ago
Looks like the way to run tests has changed since I wrote the build script. @albertito, is this possible to run integration tests without docker and without root access?
P.S. Currently PKGBUILD does it like this
check() {
cd "${srcdir}/${pkgname}-git"
go test ${GOFLAGS} ./...
# run.sh replaces binary in the repo root so back it up.
mv chasquid chasquid.bkp
setsid -w ./test/run.sh
# https://blitiri.com.ar/git/r/chasquid/c/43573797379b6e9364e46bc01554698bdecd040d/
#setsid -w ./test/stress.sh
setsid -w ./cmd/chasquid-util/test.sh
setsid -w ./cmd/mda-lmtp/test.sh
setsid -w ./cmd/dovecot-auth-cli/test.sh
mv chasquid.bkp chasquid
}
@aellwein in meanwhile you can use makepkg --nocheck
to disable check()
function (consult manual if you use an AUR helper).
Looks like the way to run tests has changed since I wrote the build script. @albertito, is this possible to run integration tests without docker and without root access?
Thanks @aellwein for reporting this issue, and @foxcpp for taking a look!
The integration tests are runnable without root, and without Docker. But there are some portability compromises. Docker just ensures an environment that is viable for them. But I run them as a normal user and without Docker on my machine.\ I would expect that if they worked in Arch before, they should continue to run fine now, nothing has drastically changed.
Are those tests running as root? If so, maybe the workaround to make msmtp g-s
isn't not working, and thus causing the failure?
That's not something that changed in chasquid, it's been around for a while, but it could be that Arch' msmtp wasn't g+s
before, or that the semantics of cp
have changed and they're now preserving the sticky bit when copying as root?
I think the first step is figuring out what's causing the failure.
1) Are the tests running as root?
2) Can you ls -l test/util/.msmtp-bin
to see what are the permissions?
3) Is msmtp
built with non-glibc, or in any mode that would disable the $HOSTALIASES
env variable?
Tests are definitely not running as root.
That's good, the tests are mainly made to run as not-root anyway, so that rules out a class of potential issues.
My next suspect is that the $HOSTALIASES
mechanism isn't working correctly in this case.
Was msmtp built with a standard glibc, or is there anything peculiar about it?
You can try reproducing this by running:
( cd test/t-01-simple_local/; HOSTALIASES=hosts ../util/.msmtp-bin -C msmtprc someone@testserver < content )
On a system where the HOSTALIASES is working, you should get .msmtp-bin: cannot connect to testserver, port 1587: Connection refused
or something very similar. What do you see if you try that?
Also, what version of msmtp are you using?
I could not reproduce the issue using Arch-provided msmtp package (1.8.15). check() completes successfully and command you also outputs the expected output.
Thank you @foxcpp!
@aellwein can you tell us more about your build environment, so we can debug this further?
@albertito Sure, i'm on Arch x86_64, keeping it latest and as of now
Linux 5.12.14-arch1-1 #1 SMP PREEMPT Thu, 01 Jul 2021 07:26:06 +0000 x86_64 GNU/Linux
Go has the version go version go1.16.5 linux/amd64
.
The PKGBUILD revision in AUR tree is
* 0906963 - (HEAD -> master, origin/master, origin/HEAD) chasquid 1.6 (8 months ago) <fox.cpp>
The build dependencies installed by PKGBUILD are:
gsasl-1.10.0-1 libidn-1.37-1 msmtp-1.8.15-1
I use yay as my AUR helper. The full output of the installation is attached.
Feel free to tell me, what else you need.
Can you run the following? It should check if python3
accepts $HOSTALIASES
:
$ echo "testserver localhost" > /tmp/extra-hosts
$ HOSTALIASES=/tmp/extra-hosts python3 -c 'import socket; print(socket.gethostbyname("testserver"))'
If it works, it should print "127.0.0.1" or "::1", let us know what it shows.
If that is successful, then I think the next steps will involve downloading chasquid and running the check mentioned above to see if msmtp
is honouring $HOSTALIASES
.
I understand that at this point you were able to work around this issue using foxcpp's suggestion, right?
Thanks!
If it works, it should print "127.0.0.1" or "::1", let us know what it shows.
$ cat /tmp/extra-hosts testserver localhost $ HOSTALIASES=/tmp/extra-hosts python3 -c 'import socket; print(socket.gethostbyname("testserver"))' Traceback (most recent call last): File "<string>", line 1, in <module> socket.gaierror: [Errno -2] Name or service not known $ python3 --version Python 3.9.6
I understand that at this point you were able to work around this issue using foxcpp's suggestion, right?
Yes, thanks. I even managed to compile it and install via Makefile as described in the documentation, but i would rather prefer the solution on the package level, to keep track on updates.
If nscd is running, glibc will ignore HOSTALIASES environment variable on per-process level leading to chasquid integration tests failing.
systemctl status nscd
should tell you if that's the case.
➜ ~ systemctl status nscd
○ nscd.service - Name Service Cache Daemon
Loaded: loaded (/usr/lib/systemd/system/nscd.service; disabled; vendor preset: disabled)
Active: inactive (dead)
➜ ~ cat /etc/nsswitch.conf
# Name Service Switch configuration file.
# See nsswitch.conf(5) for details.
passwd: files systemd
group: files [SUCCESS=merge] systemd
shadow: files
publickey: files
hosts: files mymachines myhostname resolve [!UNAVAIL=return] dns
networks: files
protocols: files
services: files
ethers: files
rpc: files
@albertito It seems not only Python doesn't recognize the HOSTALIASES environment variable:
➜ ~ env HOSTALIASES=/tmp/extra-hosts host testserver
Host testserver not found: 3(NXDOMAIN)
Good call including the contents of nsswitch.conf
!
Look at this line:
hosts: files mymachines myhostname resolve [!UNAVAIL=return] dns
That means that systemd-resolved is in action, and intercepts all dns lookups (as it was designed). If it's up and responding, the normal dns lookups of libnss_dns
won't take place, and that's the one which expands $HOSTALIASES
.
So my suspicion is that systemd-resolved is intercepting the lookups, and not honouring $HOSTALIASES
.
If it isn't too much hassle, can you change that line in /etc/nsswitch.conf
to be:
hosts: files mymachines myhostname dns
and then run the python3 one-liner again, to see if it works when systemd-resolved is out of the path?
In any case, at this point I think I'm going to make the integration tests that rely on $HOSTALIASES skip if it's not working (instead of failing as they currently do).
I just verified this on my system. I started systemd-resolved and indeed HOSTALIASES is no longer working.
Thank you for checking! I wrote commit d78056aff5264 to skip the affected tests if $HOSTALIASES
is not working. You're both mentioned in the commit message, please let me know if you prefer to be credit differently.
The patch is currently in the next
branch; if there aren't any issues in the next couple of days, I'll merge it into master
as usual.
I've also tried with adjusting nsswitch.conf
and the python one-liner, looks good to me. 👍🏻
Thank you for the support! ❤️
The fix for this is now in the master
branch, and will be included in the next release.
Thanks a lot for your help and patience with resolving this!
I'm trying to install chasquid-1.6-1 on Arch Linux and i'm getting following error:
So it looks to me like some test is not passing while installation and therefore whole procedure fails.