Search results

@DrWizzle Did you posted (and removed the post) that you experienced the same issues with DS and 1.690? If yes it's important to mention it.

Yep and on Alma 8 which I'm using on the DS server.

Ah personal plus license then. If it's a new installation then you're entitled to ticket support. Otherwise I hope somebody of devs here will fix it for you.

It's decreated as from Bind 9.16 but was still working. It was fully removed from 9.18. Anyway I can confirm it's a 1.690 issue as also with the other server on 1.689 it works flawlessly with creating and deleting. But on changing records it does not. So might still be something else.

So are you co-admin or do you mean you have a lifetime/legacy license? Because Debian 13 is not supported with legacy licenses.

@reonhoub2 do you have the dnssec-enable yes; option in any of your /etc/named.conf files? Edit: Also check if you change records. On 1.689 creating and deleting works fine but changing records doesn't work.

My previous post is due to the editting a bit unclear. The non creation of .db files on the DS slave was my fault and is fixed. Tested with 1.690, problem occurs, line and .db is added but on removal no erros on the DS servers. Tested with 1.689 looks like everything is working as designed after...

@exlhost have dnssec-validation yes; in my Directadmin, but I just checked and looks I do stil have dnssec-enable yes; in named.conf of the Directslave server. That did not give issues before. I now removed that line from the DS server and restarted named. Now it only has dnssec-validation auto...

Oke going back makes some differences. With 1.689 stil the .db file is not created on my Directslave, but on removal, the domain is removed from the directslave.inc file, which is not done when using 1.690. Also now there is an error in the DS error log which was not present before: Cant'...

Maybe send in a ticket? I presume you have a modern license.

No they just gave it free under GPL via github so others can make a fork and work on it, several did. The CSF devs stopped and will do nothing anymore also not on Github. Like @Active8 said DA has a fork itself and maintains itself now. So best is to keep the one from DA.

I would like to try if you have the command to downgrade safely to 1.689.

I rather not go back that far. What is the command to downgrade to 1.689?

Did something change in 1.690 with DNS or how multiserver sends dns commands in any way? Maybe the "Remove duplicate records when deleting a DNS record fix" changed something? It seems we (see Directslave thread) are experiencing odd behaviour of Directslave. The domain .db file are suddenly...

Even worse. I just tested for you and I got my testdomain in the directslave.inc file but the testdomain.nl.db file wasn't even created. Also no error in the error log. And I also found testdomains in the directslave.inc file which were created a couple of days ago when I changed the...

Check the directslave error log. I found recently after some OS or bind update that the /etc/named directory restored original permissions and owner from root. So now I changed it and now use a self created /etc/namedb directory with correct owner and permission and things work again. However...

Don't think so. I just tried to register with a test account and got this:

Yes if I'm correct the stats are done on the nightly tally. If you want to see results now you could use this line as root via SSH: echo 'action=tally&value=all' >> /usr/local/directadmin/data/task.queue Then wait until the task is ready and then result should be viewable.

Ah oke. Your explanation now makes morse sense to me indeed. Ofcourse there are various points of view and opinions. And for sure a legacy license holder is worth more than a webmin user, logically. Legacy license holders helped building the company. I totally agree with you on that. Also on the...

Then maybe you should be more clear what exactly you're saying because to me this looks as if you're saying "these things are all good for DA" when keeping the lifetime licenses or unblock MariaDB. It's not really specified what your point is and I'm not native English either but I might have...