Hardware: LXC container, host is a NUC
YunoHost version: 126.96.36.199
I have access to my server : As root through lxc-attach
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : yes
If yes, please explain:
yunohost dyndns update in an ipv6 only environment.
I applied a fix to to update my ipv6 in Yunohost DNS resolvers, see this post: [SOLVED] [dyndns update] ipv6 only.
The fix works fine.
A minor issue is that I get spammed by the following
root@hostname:~# cat /etc/cron.d/yunohost-dyndns SHELL=/bin/bash */10 * * * * root : YunoHost DynDNS update; sleep $((RANDOM\%60)); test -e /var/run/moulinette_yunohost.lock || yunohost dyndns update >> /dev/null
dyndns.py, the fix modified the definition of local function
But this local function is called twice to dig my domain from Yunohost DNS resolvers:
old_ipv4 = resolve_domain(domain, "A") old_ipv6 = resolve_domain(domain, "AAAA")
The second call raises no error as I already registered my ipv6.
The first call raises an error as there is no registered ipv4 for my domain in Yunohost DNS resolvers:
Error: Failed to resolve A for hostname.nohost.me
This error is raised by the following code at the end of function
raise YunohostError( "Failed to resolve %s for %s" % (rdtype, domain), raw_msg=True )
I believe this error is pertinent and should not be masked regarding the result of
According to me, there is no correlation between:
- “being able to dig Yunohost DNS resolver from ipv4”
- and “having no registered ipv4 in Yunohost DNS resolver”.
So, this annoys me because of my context, which is specific.
I patched my environment with a quick and dirty solution, in the
- in the call of
yunohost dyndns update, I redirected
- then I piped it into a
grepto filter my error
- and I redirected
stderrso that I receive an email in case of an other error
root@hostname:~# cat /etc/cron.d/yunohost-dyndns SHELL=/bin/bash */10 * * * * root : YunoHost DynDNS update; sleep $((RANDOM\%60)); test -e /var/run/moulinette_yunohost.lock || yunohost dyndns update 2>&1 1>/dev/null | grep -v 'Failed to resolve A for hostname.nohost.me' 1>&2
But I am not satisfied with this as I might have to apply this patch after every migration/upgrade.
So, the question I come up with is: “Is there a possibility to filter this error from within the moulinette?”