So, I rebuild a server from scratch (without restart), enabling IPv6. Then after installing directadmin, I notice directadmin.conf set ipv6=1 by default (but it did not add ipv6 for us in system file). I knew directadmin would not care to add IPV6 for us by default. That's ok.
But, with that option ipv6=1 enabled, when you execute something that related to DNS like adding a domain name, or create a reseller user that will of course add a default domain, you will get a timeout error like this which some people are reporting:
So I inspected the process via htop to see any stuck processes then I saw this process is the reason that cause timeout. It is used by directadmin to obtain IPv6 from ipify.org but failed. I believe the reason is IPv6 is enabled but not fully available yet.
The solution to avoid this timeout is to disable ipv6=0. When I set ipv6=0, then directadmin would not call that API and no more timeout.
My question to @smtalk, (hope that you reply) is there a reason to call that API to get public IPv6 address ? If you remove this API call, we would not have this timeout problem.
Now the main problem is if I want to add IPv6, I have to enable ipv6=1, then adding Ipv6 in directadmin system will have no trouble but the problem is, when I add domain, or dns record it would trigger time out error like above. The other solution is to restart the server once after rebuild a server and configuring IPv6 but I really want to avoid this restart as my aim is to do automated server deployment with directadmin using script. So this bug halt the automation script. So is it important to call this API when IPv6 is not reachable but it is enabled in the system?
In brief, of what I'm trying to say is... when we rebuild a server from scratch, we configure Ipv6 properly then it needs to be restarted once for IPv6 to work properly (reachable in network), but can directadmin don't care about this detection and just use normal ipv4 at the beginning? Maybe directadmin detected that my system is ipv6 by configuration ready but it did not detect whether it is working or not (It needs to be restarted first before it is fully working).
So, here is the log if I manually run this in my terminal
This command works only when my server is restarted once so the Ipv6 will work perfectly. Again I hope @smtalk can look into this issue as I have spent many weeks creating this automation script but this issue made me feel hopeless to continue working on this script. In the previous version of directadmin there was no issue like this.
Affected people:
1) Anyone with IPv6 system enabled but not reachable would have this problem (restart might not solve this issue if IPv6 is misconfigured). So maybe use another detection before calling the API? Preferably the offline detection is better than using 3rd party:
But, with that option ipv6=1 enabled, when you execute something that related to DNS like adding a domain name, or create a reseller user that will of course add a default domain, you will get a timeout error like this which some people are reporting:
So I inspected the process via htop to see any stuck processes then I saw this process is the reason that cause timeout. It is used by directadmin to obtain IPv6 from ipify.org but failed. I believe the reason is IPv6 is enabled but not fully available yet.
Code:
/usr/bin/wget --tries=4 --timeout=4 --inet6-only https://api64.ipify.org/
The solution to avoid this timeout is to disable ipv6=0. When I set ipv6=0, then directadmin would not call that API and no more timeout.
My question to @smtalk, (hope that you reply) is there a reason to call that API to get public IPv6 address ? If you remove this API call, we would not have this timeout problem.
Now the main problem is if I want to add IPv6, I have to enable ipv6=1, then adding Ipv6 in directadmin system will have no trouble but the problem is, when I add domain, or dns record it would trigger time out error like above. The other solution is to restart the server once after rebuild a server and configuring IPv6 but I really want to avoid this restart as my aim is to do automated server deployment with directadmin using script. So this bug halt the automation script. So is it important to call this API when IPv6 is not reachable but it is enabled in the system?
In brief, of what I'm trying to say is... when we rebuild a server from scratch, we configure Ipv6 properly then it needs to be restarted once for IPv6 to work properly (reachable in network), but can directadmin don't care about this detection and just use normal ipv4 at the beginning? Maybe directadmin detected that my system is ipv6 by configuration ready but it did not detect whether it is working or not (It needs to be restarted first before it is fully working).
So, here is the log if I manually run this in my terminal
Code:
root@server:~# /usr/bin/wget --tries=4 --timeout=4 --inet6-only https://api64.ipify.org/
--2021-08-19 12:48:20-- https://api64.ipify.org/
Resolving api64.ipify.org (api64.ipify.org)... 2607:f2d8:4010:c::2, 2607:f2d8:4010:8::2, 2607:f2d8:4010:b::2
Connecting to api64.ipify.org (api64.ipify.org)|2607:f2d8:4010:c::2|:443... failed: Connection timed out.
Connecting to api64.ipify.org (api64.ipify.org)|2607:f2d8:4010:8::2|:443... failed: Connection timed out.
Connecting to api64.ipify.org (api64.ipify.org)|2607:f2d8:4010:b::2|:443... failed: Connection timed out.
Retrying.
--2021-08-19 12:48:33-- (try: 2) https://api64.ipify.org/
Connecting to api64.ipify.org (api64.ipify.org)|2607:f2d8:4010:c::2|:443... failed: Connection timed out.
Connecting to api64.ipify.org (api64.ipify.org)|2607:f2d8:4010:8::2|:443... failed: Connection timed out.
Connecting to api64.ipify.org (api64.ipify.org)|2607:f2d8:4010:b::2|:443... failed: Connection timed out.
Retrying.
--2021-08-19 12:48:47-- (try: 3) https://api64.ipify.org/
Connecting to api64.ipify.org (api64.ipify.org)|2607:f2d8:4010:c::2|:443... failed: Connection timed out.
Connecting to api64.ipify.org (api64.ipify.org)|2607:f2d8:4010:8::2|:443... failed: Connection timed out.
Connecting to api64.ipify.org (api64.ipify.org)|2607:f2d8:4010:b::2|:443... failed: Connection timed out.
Retrying.
--2021-08-19 12:49:02-- (try: 4) https://api64.ipify.org/
Connecting to api64.ipify.org (api64.ipify.org)|2607:f2d8:4010:c::2|:443... failed: Connection timed out.
Connecting to api64.ipify.org (api64.ipify.org)|2607:f2d8:4010:8::2|:443... failed: Connection timed out.
Connecting to api64.ipify.org (api64.ipify.org)|2607:f2d8:4010:b::2|:443... failed: Connection timed out.
Giving up.
This command works only when my server is restarted once so the Ipv6 will work perfectly. Again I hope @smtalk can look into this issue as I have spent many weeks creating this automation script but this issue made me feel hopeless to continue working on this script. In the previous version of directadmin there was no issue like this.
Affected people:
1) Anyone with IPv6 system enabled but not reachable would have this problem (restart might not solve this issue if IPv6 is misconfigured). So maybe use another detection before calling the API? Preferably the offline detection is better than using 3rd party:
Code:
ip -6 a | grep inet6 | awk '/global/{print $2}' | cut -d/ -f1
Last edited: