Unexpected licensing error has occurred. Please open a support ticket.

A

Amitgarg2020

Verified User
Joined
Nov 14, 2020
Messages
7
license is expired

More details about licensing errors is available on the docs.directadmin.com. , In my account , i checked on main page clients/index.php ExpiryJan 18 2038 , When i enter in license key : and look at session clients/license_sessions.php?lid= it display expiry May 17 .. Why so? How can i fix that?
 
Do you have an up to date version of OS and directadmin?

Anyway, you can try to fix it like this:
Code: 
cd /usr/local/directadmin/scripts 
./getLicense.sh auto
systemctl restart directadmin
 
today i updated everything , after that i got this error , Anyways thanks for your help. I tried
systemctl restart directadmin command Now everything works fine. I manually Checked the license key. it was correct in license file.
I also Checked logs using journalctl
i got this error "directadmin[808]: getting dovecot journal cursor error=failed to get cursor: cannot assign requested address"

Please close this thread,
 
Hello, today happened the same to me, seems that restarting directadmin works for some time, but suddenly re-appear, and if i do:
Code: 
./getLicense.sh auto
I get:
Code: 
invalid license key length


I checked my ip and license is valid. Thanks.
 
@colevr Can you confirm you are running the latest DA version? This is always the first step in troubleshooting. The command is simply:


Code: 
da update
 
colevr said:
Hello, today happened the same to me, seems that restarting directadmin works for some time, but suddenly re-appear, and if i do:
Code: 
./getLicense.sh auto
I get:
Code: 
invalid license key length


I checked my ip and license is valid. Thanks.
Click to expand...
My error was Expired.
Anyways : Run This command after login to Root ..

systemctl restart directadmin

.. I hope this will work.
 
@Amitgarg2020 license can be expired due to outdated DA which try to use old licensing system, and can't update license.
I have few VPS where users didn't update their DA during 1-2 years and they received same errors.
 
DirectAdmin Sales said:
@colevr Can you confirm you are running the latest DA version? This is always the first step in troubleshooting. The command is simply:


Code: 
da update
Click to expand...

I'm seeing this too on server reboots using a Debian machine using a datacenter-provided license. Each time the machine is booted, I seem to get this error. DirectAdmin is up-to-date with the latest hotfix.

I resolve it after a server reboot with
Code: 
systemctl restart directadmin

Not a huge deal, but thought I'd add my case in the event that it helps.
 
@dwight_d license error on reboot could be caused by a bug in CSF firewall which on reboot temporarily breaks all already opened IPv6 connections. We have reported this issue to CSF but no response yet. In DA 1.650 we will auto-patch main CSF script to fix this issue and hope it will be fixed by CSF eventually. Not all systems are affected by it as it requires a specific timing and IPv6 stack to be enabled and available.
 
fln said:
@dwight_d license error on reboot could be caused by a bug in CSF firewall which on reboot temporarily breaks all already opened IPv6 connections. We have reported this issue to CSF but no response yet. In DA 1.650 we will auto-patch main CSF script to fix this issue and hope it will be fixed by CSF eventually. Not all systems are affected by it as it requires a specific timing and IPv6 stack to be enabled and available.
Click to expand...
That makes total sense, since I do run a dual-stack configuration. I’m guessing it showed up with the 14.18 CSF update? (unless it was a Debian system component update that introduced it– or just bad luck that it's attempting the connection over IPv6 more often now)

Thanks for the quick response. It’s easy enough to workaround for now, so no big deal. I appreciate you being proactive in reaching out to CSF to resolve this in any case.
 
Last edited:
Hi all,

I just installed a new VPS using Almalinux 8. DirectAdmin seems to be properly installed, however I cannot login into the panel. It says the license key is missing on the server (new "feature" since v1.650). I checked my license on https://license.directadmin.com/? and it's a valid license.

When I run
Code: 
./getLicense.sh auto
or
Code: 
./getLicense.sh <LicenseKey>
or
Code: 
da license-set '<LicenseKey>'
it always ends up with the message "invalid license key length". In the file /usr/local/directadmin/conf/license.key I can see the right license key.

But when I do
Code: 
journalctl -u directadmin
I see some unexpected messages:
directadmin[2516]: failed reading license file error=invalid license file=/usr/local/directadmin/conf/license.key
directadmin[2516]: license check failure error=missing license key

Rebooting the server and/or restarting DA does not solve this. The version of DA is latest, v.1.650

Can anyone help me with this..?
 
@fln Thank for your reaction, but I use a license provided by my VPS-provider, so I cannot open a ticket :-)
I contacted my provider and they helped me out.

The solution:
cd /usr/local/directadmin/scripts
./getLicense.sh<hashed LicenseKey>
systemctl restart directadmin

I don't know what hash is used, but I received the correct one :-)

Regards,
Danny
 
fln said:
@dwight_d license error on reboot could be caused by a bug in CSF firewall which on reboot temporarily breaks all already opened IPv6 connections. We have reported this issue to CSF but no response yet. In DA 1.650 we will auto-patch main CSF script to fix this issue and hope it will be fixed by CSF eventually. Not all systems are affected by it as it requires a specific timing and IPv6 stack to be enabled and available.
Click to expand...
still seeing this on 1.651 - no dual stack
 
i also got license error yesterday , but solved with restarting directadmin command. systemctl restart directadmin
 
The license check issues seems to occur after a server reboot. We had some contact with support and they pointed us to CSF.

We added and tested with these two rules in csf.allow:
Code: 
tcp|out|u=0 # Added by DirectAdmin
udp|out|u=0 # Added by DirectAdmin
I have not figured out why these rules work different compared to the TCP(6)_OUT rules but it seems to resolve the issue.

The above CSF uid based rules are also part of custombuild:
Code: 
cat /usr/local/directadmin/custombuild/build | grep "Allow all TCP/UDP outbound connections from root" -A5

    #Allow all TCP/UDP outbound connections from root
    if ! grep -q 'out|u=0' /etc/csf/csf.allow; then
        needs_restart=yes
        csf -a "tcp|out|u=0" "Added by DirectAdmin"
        csf -a "udp|out|u=0" "Added by DirectAdmin"
    fi

I'm not sure if this resolves your license check issues but you could give it a try.
 
tomputer said:
We added and tested with these two rules in csf.allow:
Click to expand...
These just allow root to send out mail. Shouldn't be needed (we always disable them again), because CSF should allow localhost mail outgoing anyway.

Check your /etc/named.conf file. On one of our servers, suddenly this was added:
recusion no;
In our /etc/resolv.conf we had 127.0.0.1 and then 1.1.1.1 and then the ip's of the datacenter.

However, when testing with nslookup, it stuck at 127.0.0.1 and the others were not used. I don't know why this line is put in there, but it should not be in there, unless you use specific ACL's so you can do lookups from localhost.

I always set:
allow-recursion { localnets; };
which limits lookups anyway to localnets (which includes localhost) and after removing the "recursion no" in named.conf and restarting named, the license was working again.

So take care you don't suddenly have a seperate "recusion no" line in there, which will also cause a licenses issue.
 
Richard G said:
These just allow root to send out mail. Shouldn't be needed (we always disable them again), because CSF should allow localhost mail outgoing anyway.
Click to expand...
These rules accept all outgoing udp/tcp packets from uid=0 (root), see the ALLOWOUT chain in iptables:
Code: 
Chain ALLOWOUT (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     udp  --  *      !lo     0.0.0.0/0            0.0.0.0/0            owner UID match 0
    0     0 ACCEPT     tcp  --  *      !lo     0.0.0.0/0            0.0.0.0/0            owner UID match 0
But I assume what you mean is that these rules were added to allow certain things (like outgoing mail).

Richard G said:
Check your /etc/named.conf file. On one of our servers, suddenly this was added:
recusion no;
In our /etc/resolv.conf we had 127.0.0.1 and then 1.1.1.1 and then the ip's of the datacenter.
Click to expand...
This is not the case on our servers, we don't have these 127.0.0.1 entries and use different resolvers.

I do not believe that bind/resolving are related to the license checks issues, at least not in our servers. We first noticed these license check issues around April this year, probably after a DirectAdmin and/or CSF update. You can test if it is CSF related if you disable CSF and reboot the server.
 
You must log in or register to reply here.
Back
Top