Minor issue with ns1= and ns2= values in directadmin.conf.

[HHawk79]

Hi all,

This minor issue has been troubling me for quite some time. However I didn't have the time before to fix this. This issue has been present for quite some time (several months) and no clue on how to solve it.

We use an automated script for setting up DirectAdmin servers. This always worked in the past without problems, however for quite a while it now setups the hostname (only for ns1= and ns2= values in directadmin.conf) incorrectly. As a results DNS-records are also not correct. I fixed this by hand after setting up a server, as I didn't have the time to investigate the cause. Now I do have a bit of time, so decided to try a few things to correct this, but without success unfortunately.

Every time I setup a new server e.g. with hostname ns1.domain.com it will create incorrect values in the directadmin.conf files like this:

ns1=ns1.ns1.domain.com
ns2=ns2.ns1.domain.com

As a result several things get setup incorrectly in DA e.g. DNS-records.

I tried using export to force DA_NS1 and DA_NS2, but it seems to be ignoring it. So far the only solution is to correct it afterwards by hand, but I rather have the server setup correctly automatically. Anyone has an idea where this is coming from?

It's been like this for a couple months (probably since an update with the Custombuild tool somewhere down the line), but I have no clue why it's adding the extra "ns1."-parts to the directadmin.conf file. As a result the DNS is a bit messed up, which can be corrected manually, however I rather it correctly from the start.

Other variables are correct in directadmin.conf though for example: servername (ns1.domain.com) is correct. It's only the values ns1= and ns2= which are incorrectly set.
I did notice the following parameters being empty from the start: DA_NS1 and DA_NS2. So I tried using "export" for the correct values, but that didn't work for me...

Maybe someone has an idea? Or something I can try or do to make it correct? At least before it starts to create DNS-records and such. Probably a long shot, but I really do not have an idea where this is coming from. I am guessing this issue started around 6 months ago (but that's just a guess).

Thanks in advance!


//edit
In DirectAdmin self, it will show also the incorrect "Name Server 1" and "Name Server 2" names (with double "ns1." in those lines) under "Admin" > "Server Manager" > "Name Servers". As a result of this, new (added) domains are setup with incorrect nameservers e.g.

Added record ns1.ns1.example.com. A 20.200.200.20 to satisfy example.com. NS ns1.ns1.example.com.
Added record ns2.ns1.example.com. A 20.200.200.20 to satisfy example.com. NS ns2.ns1.example.com.
Please check the zone for example.com to ensure the nameserver A records are correct.
User added to named.conf file successfully

Also when I correct the "Name Servers"-setting with the correct value and add a new domain, they are still setup with double "ns1."-values.
When I change the values correctly in the directadmin.conf and restart the directadmin service, the correct nameservers are shown under "Name Servers", but when I create a domain it will still add the double "ns1."-values to the new domain. Strange...

 

[Richard G]

Every time I setup a new server e.g. with hostname ns1.domain.com it will create incorrect values in the directadmin.conf files like this:

So this generates the first questions. Things like ns1 and ns2 and mail, smtp, www etc. are mostly default values. Why do you want to have your hostname use something which is already often used as default value for something else?
Why keep using ns1.domain.com as hostname if you see that this will cause problems every time? Why not change to server.domain.com or someothername.domain.com and keep away from default values used for other things?

Added record ns1.ns1.example.com.

Seems this is a bug, but I would really bet on it this is caused by using ns1 as hostname.

 

[HHawk79]

Huh?

We always setup servers with ns1.nameserver.com and ns2.nameserver.com. Never has this caused issues. We use this approach for Plesk, DirectAdmin and even LAMP servers. Always worked without issues. And also this only started a couple of months ago. Seems to be a bug or change in the code. Which I cannot find.

Will try to find out the cause for this.

 

[HHawk79]

Since changing the system we use to setup servers is a lot of work, I maybe can rename it for the time being and change the name back of the server when it's done.

Now the only question I have, is where does DirectAdmin collect the hostname from during the setup?
E.g. does it the hostname from /etc/sysconfig/network or elsewhere?

If I know this, I can create a workaround instead of modifying everything else (and thus breaking stuff more probably).

 

[HHawk79]

Going to try a different route instead of setting the server up with ns1.hostname.tld (like we always do) in our front-end, I am not setting it up with ns1 in front. When the setup is done, I will rename it back to ns1.hostname.tld in our front-end.

Let's see if that works.

 

[Richard G]

I am not setting it up with ns1 in front. When the setup is done, I will rename it back to ns1.hostname.tld in our front-end.

It's at least a way to see/proove if it's a bug DA which they can solve then.
Just for these kind of bugs I never use names which default are used for something else, to prevent these issue. Shortly ago on the forums the same here with a user using mail.domain.com as hostname.
Very strict, this should be possible, but also caused odd issues.

Hence the advise to use something else. Or like you want to do now, try temporarily to see if that is indeed the root cause of the issue so DA can fix it.

 

[HHawk79]

Thank you will check it out.
Hopefully the rename option will work for the time being.

 

[HHawk79]

Okay. So I setup the server with example.tld instead of ns1.example.tld. Seems to work okay, as everything is being setup correctly...
After that I rename the server to ns1.example.tld as this was always our method of working (and we also have ns3, ns5 servers for customers).

Anyways; I logged into the DA interface and tried to create the main domain example.tld (Domain Setup), but now I am getting an error: Sub-domain is forbidden. Ugh. So I cannot even add the hostname as domain and manage the DNS-records. Clicking on DNS Management gives me: There is no default domain; you should start with creating one first. But I cannot create the main domain, as it shows an error as well... Catch-22.

Also I do not understand that when I export the correct values for DA_NS1 and DA_NS2 before the installation of DirectAdmin, these entries are not being used whatsoever.

Anyways, I will see what I can do. I think something changed in the past few months. I did notice this before, but didn't think much of it, as we are getting less and less DA orders.

@smtalk is this a bug? Normally (and we always did it like this) we setup a server with hostname ns1.example.tld or ns3.example.tld (OpenVZ CT) and proceed from there. Our automation script did the rest, but now I am running into issues. Also creating a server without ns1/ns3 causes issues. This was never the case before. Something changed down the line.

Anyways, will have to check the automation script for DA only (as everything else is working; Plesk, LAMP, etc.). Just DA is causing issues...


//edit
I also created a support ticket. Maybe there is a workaround for setting up servers like ns1.example.com (which we always did). Also we get customers who want a new server and then want to use ns3.example.com. It seems creating servers in that way does not work anymore in DA.

 

[HHawk79]

Well guess I am not that wrong to use ns1.example.com as a hostname. See official documentation on DirectAdmin here: https://docs.directadmin.com/directadmin/general-usage/configuring-da.html#how-to-change-a-hostname

The value of your hostname should be in the form similar to:

server.domain.com

where you run/manage domain.com (usually something like your webhost domain). The value "server" or something like that needs to be in front of it (ns1., web1., server6., pegas., and host. are all valid).

NOTE: Never use just "domain.com" as the hostname as this will conflict with the email in your actual domain.com hosting account (with regards to how system accounts get their emails).

See also included screenshot.

So I am guessing it's a bug in DirectAdmin somewhere. Weird though that nobody else experienced this. This issue has been in there for quite a few months.

Regards


//edit
I found a work-around for the time being; I rename the hostname from ns1.ns1.example.com and ns2.ns1.example.com to values without the extra "ns1."-part in the following sections:

• Server Manager > Name Servers
• Server Manager > Administrator Settings

After that I rebooted the server and when I now add the "example.com" domain it's using the correct DNS-records.
Weird though that changing this in directadmin.conf didn't work as it should. But changing it in the interface seems to work though.

This is not ideal, but it does work apparently.

 

[Zhenyapan]

I hope you using "ns1.example.com" as example, not in production? In production you must use real domain names/subdomains that correctly resolved to your server.

 

[HHawk79]

Doh... I am not using real domains on a forum. ?

 

[Zhenyapan]

according your problem - I think you can modify your script to configure NS after DA installation.

 

[HHawk79]

according your problem - I think you can modify your script to configure NS after DA installation.

Already tried that; didn't work as expected.

Anyways, I already replied earlier today with a work-around solution. So setting up servers with, just an example, ns1.example-host.com (format) works like it always has been. I found it weird that Richard G stated that it was incorrect to setup servers with ns1.example-host.com (so ns1 in front). But I am guessing he was mistaken, as it was also mentioned in the original documentation by DirectAdmin (ns1 is allowed).

The only downside is that you have to change the settings (as mentioned) in the DA interface afterwards and reboot te server. After that DNS-records are created correctly. But that's just 1 minute work or so. Not a big issue. It didn't work when I changed the directadmin.conf manually through CLI though; the only workable solution is by doing this from the interface (in 2 locations, as described).

Anyways, I have also forwarded this information in the support ticket, though I doubt it will be resolved.

 

[Zhenyapan]

also third, not optimal, variant - restore admin backup inside which needed predefined settings.

 

[HHawk79]

also third, not optimal, variant - restore admin backup inside which needed predefined settings.

Restoring a back-up on a newly setup server? That's not a solution and really not a solution when you setup new servers (every time with a different hostname, IP-addresses, etc.).

My earlier mentioned work-around is way better.

 

[Richard G]

So I setup the server with example.tld instead of ns1.example.tld. Seems to work okay, as everything is being setup correctly...

But example.tld is not a hostname, I presume you ment server.example.tld as hostname? Because only example.com is a real no-go.

Well guess I am not that wrong to use ns1.example.com as a hostname.

No it's not wrong, I think I've seen it somewhere else even too. It's just that it's not really done default often and it can cause issues with DA as you could see. Probably caused by the installation script which does not know what to do with it.
To prevent this kind of issues, I never use names which are often used default for something, as I explained, but it's not wrong. My assumption that this was the cause of your problem was correct, in spite of the fact that your action to use that name was also correct.

Using domain.com (or example.com) as a hostname however is wrong. But I presume you didn't do that when mentioning example.com.

Seems you indeed discovered a DA issue here, which needs fixing, especially since they mention in their own docs it should be able to be used.
You can put that in the support ticket.

At least we're now 100% sure why the problem occured.

 

[HHawk79]

I already did.