Closed tilleyc closed 3 years ago
Also worth noting, I originally was attempting to create a Docker container that would run cvdupdate and serve it via nginx, and it was also failing in this manner, though I've not tested the fix within this architecture yet.
I tried to reproduce the issue in a centos 7 docker container, after setting
yum install -y python3
pip3 install cvdupdate
export LC_ALL=en_US.utf-8
export LANG=en_US.utf-8
cvd update
No DNS issues on my side. But if setting a resolver timeout fixes it for you that seems like a fine change. I tried with your suggested change and that also worked fine. Care to put in a PR?
Thanks @tilleyc!
Bit of an odd one pertaining to https://github.com/Cisco-Talos/cvdupdate/blob/main/cvdupdate/cvdupdate.py#L401 ....
System Type: VM OS: CentOS 7.9.2009 Python Version: 3.6.8 (default available via
yum install python3
) pip3 Version: 9.0.3 (default available viayum install python3
) Dependency versions:Issue Encountered After installing cvdupdate, trying to run and produce updates results in DNS Timeout occurring, even though dig/nslookup from host system returns TXT record without issue. Here is the exact error encountered when running
python3 -m cvdupdate update -V -D
:Steps to Reproduce
yum install -y python3
pip3 install cvdupdate
python3 -m cvdupdate update
Mitigation On the above linked line (https://github.com/Cisco-Talos/cvdupdate/blob/main/cvdupdate/cvdupdate.py#L401), this function is where the error is coming from. I specified a direct value for timeout for the resolver object by inserting a line after 409, as follows:
our_resolver.timeout = 10
. The actual lookup still happens in sub 1 second time, but for some reason couldn't return anything and would timeout without this timeout being specified.Other Notes I realize I could have maybe made a pull request for this (and can still if we determine that's what we want to do), but this seemed a rather specific and peculiar issue to run into. If I install cvdupdate on my Mac natively, it also installs dnspython 2.1.0, and doesn't encounter this issue - it works right away. If nothing else, it may be a good idea to just declare a default timeout value to avoid whatever bug this is. I have tested with other values, such as 5 (which appeared to be the default given the error produced), and it still works fine. Perhaps this could also be another configuration option too?