Named zone rewrite throws Sockets::getServerIPv6: Script error

N

Niels90

Verified User
Joined
Apr 22, 2016
Messages
22
Dear all,

We are experiencing an issue with DirectAdmin version 1.680 in conjunction with IPv6, specifically when running the following command:


/usr/local/directadmin/directadmin taskq --run "action=rewrite&value=named" --debug 2000
When running this command, we receive the following error:


Sockets::getServerIPv6: Script error:
File /etc/bind/******.db.temp.494401.wzzAE22y7G appears OK to named-checkzone
Although the temporary zone file appears to be OK according to named-checkzone, DirectAdmin seems to generate an error related to Sockets::getServerIPv6. This may indicate a problem retrieving or recognizing the server's IPv6 address during the DNS configuration rewrite.

We haven't observed this behavior before in version 1.679, so it's likely a regression in version 1.680.

Can you please let us know if this is a known issue? If so, is there a solution or temporary workaround available?
 
@Niels90, there are no changes related to the server IPv6 address detection for quite a while. I think it is unlikely to be related to the latest DA release. Please open a support ticket and we will check it out.

You can try debugging the issue manually by checking if the /usr/local/directadmin/scripts/get_main_ip6.sh returns any errors. Example:

Code: 
# /usr/local/directadmin/scripts/get_main_ip6.sh && echo success || echo failure
2001:db8::123
success

Note, the extra echo success/failure message here shows if script exited with an error or not.
 
fln said:
@Niels90, there are no changes related to the server IPv6 address detection for quite a while. I think it is unlikely to be related to the latest DA release. Please open a support ticket and we will check it out.

You can try debugging the issue manually by checking if the /usr/local/directadmin/scripts/get_main_ip6.sh returns any errors. Example:

Code: 
# /usr/local/directadmin/scripts/get_main_ip6.sh && echo success || echo failure
2001:db8::123
success

Note, the extra echo success/failure message here shows if script exited with an error or not.
Click to expand...

root@web01:~# /usr/local/directadmin/scripts/get_main_ip6.sh && echo success || echo failure
failure
root@web01:~#
 
zEitEr said:
Try this one to see what is wrong:

Bash: 
bash -x /usr/local/directadmin/scripts/get_main_ip6.sh
Click to expand...

root@web01:~# bash -x /usr/local/directadmin/scripts/get_main_ip6.sh
++ ip route get to 2001:db8::
++ grep -m 1 -o 'src [0-9a-f:]*'
++ cut -d ' ' -f 2
+ ipv6_addr=
+ '[' -z '' ']'
+ exit 1
 
zEitEr said:
Your server does not seem to have IPv6 on the network, does it?

Code: 
ip -6 add li
?

Code: 
ip -6 ro li
?
Click to expand...

Bash: 
root@web01:~# ip -6 add li
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a06:900:201:bb01::951/96 scope global deprecated
       valid_lft forever preferred_lft 0sec
    inet6 2a06:900:201:bb01::896/96 scope global deprecated
       valid_lft forever preferred_lft 0sec
    inet6 2a06:900:201:bb01::596/96 scope global deprecated
       valid_lft forever preferred_lft 0sec
    inet6 2a06:900:201:bb01::521/96 scope global deprecated
       valid_lft forever preferred_lft 0sec
    inet6 2a06:900:201:bb01::496/96 scope global deprecated
       valid_lft forever preferred_lft 0sec
    inet6 2a06:900:201:bb01::141/96 scope global deprecated
       valid_lft forever preferred_lft 0sec
    inet6 fe80::ec4:7aff:fee4:9260/64 scope link
       valid_lft forever preferred_lft forever
root@web01:~# ip -6 ro li
::1 dev lo proto kernel metric 256 pref medium
2a06:900:201:bb01::/96 dev eno1 proto kernel metric 256 pref medium
fe80::/64 dev eno1 proto kernel metric 256 pref medium
default via 2a06:900:201:bb01::1 dev eno1 metric 1024 pref medium
root@web01:~#
 
OK, it seems IPv6 is configured correct. If this is the case you might open a ticket with DA support for a further investigation.
 
We've paired IPv4 with IPv6 on our server, but we've since received the following error:

/usr/local/directadmin/directadmin taskq --run "action=rewrite&value=named" --debug 2000

Sockets::getServerIPv6: Script error:
File /etc/bind/xxxx.db.temp.588744.xHWHMmFvz0 appear

Does anyone know what exactly is wrong here and what the solution should be?
IPv6 has already been added to the server.

Can you explain the cause of this error and how to resolve it correctly?
 
Hello,

The mentioned error does not look familiar to me. Would it help if you temporary reset the specific DNS zone to a default state in DirectAdmin (just create a backup of the file first to be able to restore its content after the test)?
 
zEitEr said:
Hallo,

De genoemde fout komt me niet bekend voor. Zou het helpen als je de specifieke DNS-zone tijdelijk terugzet naar de standaardstatus in DirectAdmin (maak eerst een back-up van het bestand om de inhoud ervan na de test te kunnen herstellen)?
Click to expand...
I have completely removed and re-added the DNS zone but this does not solve the problem
 
Niels90 said:
I have completely removed and re-added the DNS zone but this does not solve the problem
Click to expand...

I'd rather go deeper with troubleshooting running this and that script in a debug mode hoping to find some new clues.

Probably you need someone to check it on your server. You might open a ticket with DirectAdmin support and let them check it for you. I am available for this job too.
 
Your scope global on ipv6 is set deprecated so the kernel will not choose those ip's for outgoing traffic so the check: ip -6 route get 2001:db8:: will fail as there is no selectable route.

Try this tho delete an address and add it as a preferred
ip -6 addr del 2a06:900:201:bb01::951/96 dev eno1
ip -6 addr add 2a06:900:201:bb01::951/96 dev eno1 preferred_lft forever

Next try bash -x /usr/local/directadmin/scripts/get_main_ip6.sh again.
 
sysdev said:
ip -6 addr add 2a06:900:201:bb01::951/96 dev eno1 preferred_lft forever
Click to expand...
Are you sure that is correct? Because he has a /64 subnet and this is a /96. Should it not be like this then?
ip -6 addr add 2a06:900:201:bb01::951/64 dev eno1 preferred_lft forever

But this is OS change, this will not change the DA ip's right? So should the ip not also be disconnected from the ipv4 first and then maybe deleted from DA and then added again with the /64?
 
Richard G said:
Are you sure that is correct? Because he has a /64 subnet and this is a /96. Should it not be like this then?
ip -6 addr add 2a06:900:201:bb01::951/64 dev eno1 preferred_lft forever

But this is OS change, this will not change the DA ip's right? So should the ip not also be disconnected from the ipv4 first and then maybe deleted from DA and then added again with the /64?
Click to expand...
According the output he has a weird /96, or am I blind? :)
 
sysdev said:
According the output he has a weird /96, or am I blind? :)
Click to expand...
Oh sorry, you don't know that part.
This is what I'm talking about, but we had a pm exchange in which I pointed that out and then he told me he in fact had a /64 subnet and he also did not understand where that /96 came from. ;)
Unless I understood him wrongly? @Niels90 can you confirm or did you just add a /64 to test and you have in fact a /96?
 
sysdev said:
According the output he has a weird /96, or am I blind? :)
Click to expand...
I see the same, but would that be part of the issue here, an incorrectly configured CIDR in his IPv6? On my servers I've only really ever known /64 with IPv6 and /56 with my static IP from ISP. /96 is a very odd subnet amount.
 
You must log in or register to reply here.
Back
Top