Can’t access the server via hostname

markwwd

New member
Joined
Mar 29, 2022
Messages
12
I have a VPS setup at Hetzner with Rocky Linux 8 installed.

I did a clean install and I can’t login via http://my.domain.com:2222

Login via server IP and via http://mydomain.com:2222 works.

I never had this issue and it seems to me that it came up with the new “background” installation script.

Can anyone elaborate? I have tried literally everything from support articles.
 
I did a clean install and I can’t login via http://my.domain.com:2222

Login via server IP and via http://mydomain.com:2222 works.


Can anyone elaborate? I have tried literally everything from support articles.
SSL on hostname?
Do a search here in forum or whith duckduck go "help directadmin ssl on hostname".

Also look howto ask for help and support, you didn't post versions DA and also no errors you see in browser and server log file.
Even you didn't post how you test your hostname is correctly set, where you did read "literally everything from support articles" ;)
 
Last edited:
SSL on hostname?
Do a search here in forum or whith duckduck go "help directadmin ssl on hostname".
Nope, can't install Easy Encrypt's SSL via:

cd /usr/local/directadmin/scripts
./letsencrypt.sh request_single hostname 4096

It's saying that it cannot connect to the hostname or something like that..
 
Dns configured and verified? What’s the output of hostnamectl ?
Static hostname: my.domain.com

I've installed DA the same as the previous 100x times. I just can't figure it out what the hell.. ports are open, the domain works, the IP works.. it's just the hostname..
 
Resolved!

The issue was in the DNS zone file. When you clean install the latest version of DA and add a domain name, you can't actually access it via hostname address until you fix the DNS zone file for your main domain name, which is adding A record for the hostname.

THIS SHOULD NOT BE IGNORED, since it's clearly a mistake made in either the setup.sh or somewhere else.

@staff
 
you can't actually access it via hostname address until you fix the DNS zone file for your main domain name, which is adding A record for the hostname.
That is odd. Normally on new install DA always created a seperate DNS record for the hostname, which so then also contained the required A record.
So you don't have a seperate DNS record for your hostname?

If no, and you -did- setup the hostname for your server correctly -before- installation, then this has to be looked at by DA.
 
That is odd. Normally on new install DA always created a seperate DNS record for the hostname, which so then also contained the required A record.
So you don't have a seperate DNS record for your hostname?

If no, and you -did- setup the hostname for your server correctly -before- installation, then this has to be looked at by DA.
In previous versions of DA, the A record for the hostname was auto-inserted while installing it from a fresh OS. I have been struggling with this for 2 days straight, because I never even thought of the record missing in the DNS zone.

You don't actually have to set-up anything before installation of DA because auto install from the script should automatically take care of the basics, like this.
 
In previous versions of DA, the A record for the hostname was auto-inserted while installing it from a fresh OS.
Yes in fact it created a DNS entry for the hostname, same as you create a domain, but then for the hostname.

However, for auto install to detect this, the hostname should already be present and working correctly before installation.
Since you did more installations before, I presume you did this correctly.

If DA is not creating that dns zone (or A record) for the hostname, it seems clearly a bug to me so you might want to send in a ticket for that. Or maybe @smtalk can have a look over here to see why that did not happen and maybe confirm this is a bug.
 
Yes in fact it created a DNS entry for the hostname, same as you create a domain, but then for the hostname.

However, for auto install to detect this, the hostname should already be present and working correctly before installation.
Since you did more installations before, I presume you did this correctly.

If DA is not creating that dns zone (or A record) for the hostname, it seems clearly a bug to me so you might want to send in a ticket for that. Or maybe @smtalk can have a look over here to see why that did not happen and maybe confirm this is a bug.
Static hostname was set before installation and there were 0 errors during install.

I also want to note, that "Check php for disable_functions" warning is still present, even after you submit "Secure PHP" in the CustomBuild under "Update Software Configuration".

I hope some takes a peak at this, I never had that warning.. not on CentOS 7, 8 (& Stream), Rocky Linux 8, Alma Linux 8
 
"Check php for disable_functions" warning is still present,
If that is coming from CSF, yes that is known but that is a CSF issue. Already spoken about on the forums. It's due to the fact that CSF does look at /usr/local/lib/php.ini and not on /usr/local/phpXX/lib/php.ini for php.ini files, causing this notice. That has to be fixed by CSF.
 
If that is coming from CSF, yes that is known but that is a CSF issue. Already spoken about on the forums. It's due to the fact that CSF does look at /usr/local/lib/php.ini and not on /usr/local/phpXX/lib/php.ini for php.ini files, causing this notice. That has to be fixed by CSF.
Thanks for this information! Was just finding out about this.
 
I found this because I am having what appears to be the exact same issue. This is my first ever DirectAdmin install. I have several cPanel servers and I am investigating DirectAdmin by first using it on a server that will replace the one that does our internal site, before deciding if I want to replace cPanel on all of our shared hosting servers.

I cannot access via the hostname. the browser just doesn't load. This is still over http. During setup it detected an address I am not familiar with and I can access it though that. I got the URL from the output of the setup script. If I had to guess, I am about 98% sure it is the result of doing a reverse DNS lookup on the IP address. I have not yet had the data center change the PTR record for the IP.

I can confirm that the public DNS is set correctly as is the hostname on the server, and that doing DNS queries return the proper IP. However, to throw a wrench into the works we don't use nor intend to use DNS on the DirectAdmin server. All of our DNS is AWS Route 53 and we also have dedicated email servers. I am a strong believer in not loading down our shared hosting web servers with DNS and Email. So I am guessing that the mentions of DNS in this thread are about internal DNS and not public DNS.

So my question I guess is, how can I solve this and not use internal DNS? This "bug" is obviously still an issue because I am still having it in March 2024 on a fresh install. Also, being a total noob to DirectAdmin, I would really appreciate it if someone could give less generalized instructions on how I need to fix this. I have not even gotten comfortable with the navigation yet.

Thank you in advance.

EDIT: I just checked in `/var/named` and there are no zone files at all. As I said a fresh install. So not sure what to do with the "you can't actually access it via hostname address until you fix the DNS zone file for your main domain name, which is adding A record for the hostname" on the post that says RESOLVED.
 
Last edited:
So not sure what to do with the "you can't actually access it via hostname address until you fix the DNS zone file for your main domain name, which is adding A record for the hostname" on the post that says RESOLVED.
There are 2 ways to solve this. You can add an A record for your hostname in the domain name indeed.

But it's also possible to create the hostname zone in DNS Adminstration as admin. Then there will be a seperate db zone in the /var/named directory for the hostname.

However, if you don't use internal DNS, then in your external DNS provider you have to put an a record for your hostname in the domain name.

This "bug" is obviously still an issue
No it's not because it's not a bug.
It's a logic result of using an external nameserver, because it's normal that external nameservers can't guess your DNS zones. Same for your domain, you also have to enter that in your external DNS, so it would be odd if that would not be the same for your hostname record.
 
However, if you don't use internal DNS, then in your external DNS provider you have to put an a record for your hostname in the domain name.

Based on this I think you are missing where I stated "I can confirm that the public DNS is set correctly as is the hostname on the server, and that doing DNS queries return the proper IP."

No it's not because it's not a bug.
It's a logic result of using an external nameserver, because it's normal that external nameservers can't guess your DNS zones. Same for your domain, you also have to enter that in your external DNS, so it would be odd if that would not be the same for your hostname record.

I use both external DNS and external Mail with WHM/cPanel on all my servers. There is even an option in the setting to allow for this. So I would consider the bug that it wants to use internal DNS regardless and it is not checking public DNS at all, considering itself fully authoritative on any zone it hosts. One should not have to keep two copies of DNS, trying to always keep the internal one true with the external. That is always going to break something.

I guess this changes my question to "should I just abandon DirectAdmin" as based on the last answer I am left with the impression it is not going to handle external DNS and Mail very well?
 
I think you are missing where I stated
No I didn't miss that. I though you fixed it now, because of what you wrote in your Edit section.

So I would consider the bug that it wants to use internal DNS regardless and it is not checking public DNS at all, considering itself fully authoritative on any zone it hosts.
No it's not considering itself as fully authoritative, an authoritative nameserver is something different.
It's using itself as a local caching nameserver. It's required for internal functions of DA. It's either that or put everything in an /etc/hosts file which is not the way it's done in Linux with all panels.

Since you can choose to user either your own nameservers or external nameservers, your statement that it would always break something is incorrect. Everything, including external mail is working with many hosters using external nameservers perfectly. That is all only a question of setting up DNS and MX correctly.

If you say you configured your internal and external DNS correctly, then things should work without any issue. But I don't know what's going on and can't investigate either without more data.
I get the impression you missed something somewhere, just because it's a different panel. For example, cPanel can detect automatically if an external or internal mailserver is used. With DA you have to make changes for that.
And we also got docs for that.

So what exactly is the problem. With DA you can also use external mail and external nameservers, just like with CP. That this wouldn't work with DA is a bit of a short sighted conclusion because that is just not true.
In another panel things work a bit different, in Plesk it would be also different, but also possible, but it might take a short learning curve.
So I think you are missing some things because you're a first time user with DA.

Also to communicate with external nameservers/dns there is for example the option activating the LEGO system which takes care of all required DNS records are copied to external dns systems.
Maybe it's a good idea to have a look at this too.
 
If you say you configured your internal and external DNS correctly,

I have the external DNS configured correctly. It was configured prior to running the setup script, with the exception of the PTR record for the IP it is hosted on. I have done nothing with internal, as I can't find any domains or zones anywhere.

I am going to give some specifics to make it more clear.

The admin loads fine from http://server-172-102-243-9.da.direct:2222/ (I think it got that domain from the reverse DNS on the IP) but will not load at all from https://chevelle.prime42.net:2222/. If you query both server-172-102-243-9.da.direct and chevelle.prime42.net you get the same IP address:

Code:
❯ dig server-172-102-243-9.da.direct +short
172.102.243.9
❯ dig chevelle.prime42.net +short
172.102.243.9

Also, this is my hostname info, which was set prior to running the setup script.

Code:
╭╴ HOST: chevelle | USER: root | PATH: /var/named
╰──╢ ? 08:35 AM ║ #» hostnamectl
 Static hostname: chevelle.prime42.net
       Icon name: computer-vm
         Chassis: vm ?
      Machine ID: 435c3fe9a0084436a4fc16169a56f0c2
         Boot ID: d54f9341f23544af945ae8a30f242d79
  Virtualization: kvm
Operating System: CloudLinux 9.3 (Aleksandr Viktorenko)      
     CPE OS Name: cpe:/o:cloudlinux:cloudlinux:9::baseos
          Kernel: Linux 5.14.0-362.8.1.el9_3.x86_64
    Architecture: x86-64
 Hardware Vendor: QEMU
  Hardware Model: Standard PC _i440FX + PIIX, 1996_
Firmware Version: rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org


Since neither server-172-102-243-9.da.direct nor chevelle.prime42.net have a DNS zone on the server I don't understand why the one it autodetected and told me to visit in the setup script:

1. was detected and given for login to begin with
2. works when what is set as hostname was not picked up
3. why I would need to add an internal DNS zone just to get the admin interface to load on port 2222

I have setup nor changed nothing at this point. I have run the setup. Logged in at the URL it gave me, and am frustrated that I cannot login at the URL that is setup in DNS at Route 53 and matches the machine hostname. Surely you can see how for a first time user a brick wall like this is a exercise in frustration and is really a bad experience for evaluating if I am going to shift to it. At least cPanel honors what is in public DNS even it if continues to create zone files, they are just ignored.

So what is my next step to allow login to http://chevelle.prime42.net:2222 so that the web server will actually respond as if it knows that vhost exists?
 
Back
Top