Why and when installer auto-generates host name?

[twhiting9275]

That is all.... Thank you

I have a valid hostname.

I have RDNS setup for said valid hostname

I do not need, or want for you to advertise your product , or change said hostname.

Your job is to install software, not alter my server configurations or hostname

 

[kristian]

It sounds like you faced what I did. It was frustrating. Here's the thread about it: https://forum.directadmin.com/threads/hostname-selection-during-install.67124/

 

[twhiting9275]

It is... I mean, it really is, especially when you take the time to set your server up before running that script (and have to do so for multiple servers).

 

[LawsHosting]

Is setting a DA_HOSTNAME variable that difficult? Just use your own da_setup.sh that sets the variable and triggers the main setup file

 

[twhiting9275]

Is setting a DA_HOSTNAME variable that difficult?

Is following standards that difficult? I mean, admins take the time to set hostnames, and they shouldn't have to adjust scripts on the whim of some software. That's just ridiculous

The point is this never should be done in the first place. Seriously. Never. This is just amateur level nonsense

 

[LawsHosting]

Is following standards that difficult?

Depends. If you talk about governments, that's a no

Some "admins" fail to set hostnames before anything else, then complain about why mail doesn't work, for example...... I just gave you a workaround to use.....

 

[Richard G]

I agree with @twhiting9275 because the reason of using the da.direct hostname is only to provide ssl records. I wonder why this is needed.
Only for beginners?
Like @twhiting9275 said, a good admin takes care everything is in good order and a decent hostname is created. I don't think most admins need this and the variables don't always work that easy.

Even I forgot that DA_HOSTNAME variable when I installed a new VPS lately or it didn't even work, or I used it in the questions alternative, but still I got that da.direct thing which most of us don't need.

And it causes issues, as I already fixed several problems with mail or ssl by customers here on the forums, which were caused because they did not use a decent FQDN hostname. Because it's also not mentioned in the docs that one should change this hostname to a FQDN hostname.

These "some admins" should learn how to setup a server with hostname (or mention it in the docs) before starting to call themselves admins.
And as said... the feature changelog said it was only done for SSL purposes.

IMHO it's better to build in a check for FQDN hostname, and if exist, use that, if not use the da.direct option.

 

[SimpleSonic]

Even I forgot that DA_HOSTNAME variable when I installed a new VPS lately or it didn't even work, or I used it in the questions alternative, but still I got that da.direct thing which most of us don't need.

And it causes issues, as I already fixed several problems with mail or ssl by customers here on the forums, which were caused because they did not use a decent FQDN hostname. Because it's also not mentioned in the docs that one should change this hostname to a FQDN hostname.

These "some admins" should learn how to setup a server with hostname (or mention it in the docs) before starting to call themselves admins.
And as said... the feature changelog said it was only done for SSL purposes.

IMHO it's better to build in a check for FQDN hostname, and if exist, use that, if not use the da.direct option.

Same. I think the install script should check and see if the current hostname is a FQDN and only change the hostname if it is not and even then I'm still not sure it's a good idea.

I do understand the thought behind it (ensuring valid SSL is installed on the hostname), but there has to be a better way.

Perhaps the install script asking to modify the hostname during install instead of just doing so?

 

[Jamie@DreamIT Host]

IMHO it's better to build in a check for FQDN hostname, and if exist, use that, if not use the da.direct option.

Yes, please. I've too have faced this issue recently.

 

[Richard G]

I do understand the thought behind it (ensuring valid SSL is installed on the hostname), but there has to be a better way.

I don't understand the thought. What's the benefit of SSL on the hostname while the hostname needs to be changed anyway afterwards?

 

[Active8]

I don't understand the thought. What's the benefit of SSL on the hostname while the hostname needs to be changed anyway afterwards?

+ 1

 

[SimpleSonic]

I don't understand the thought. What's the benefit of SSL on the hostname while the hostname needs to be changed anyway afterwards?

For new 'admins' that don't quite understand the need to set a valid hostname prior to installing a control panel.

Because let's be honest, with everyone pushing VPS servers like used car salesmen to everyone and their mother, rather than a shared hosting environment, whether or not they are capable of administering a server, we'll continue to have a need to simplify server related software installation scripts, etc.

However, making the installation more beginner friendly should not end up frustrating experienced admins in the process.

 

[Jamie@DreamIT Host]

For new 'admins' that don't quite understand the need to set a valid hostname prior to installing a control panel.

Because let's be honest, with everyone pushing VPS servers like used car salesmen to everyone and their mother, rather than a shared hosting environment, whether or not they are capable of administering a server, we'll continue to have a need to simplify server related software installation scripts, etc.

However, making the installation more beginner friendly should not end up frustrating experienced admins in the process.

A good alternative would be to perform a check then confirm with the user and have the option to default to Yes for inexperienced users.

This way, power users/admins (and the people who promote DirectAdmin) can save a couple of minutes from time to time (which is always appreciated).

Hope you're listening to our feedback @fln , thank you!

 

[Richard G]

For new 'admins' that don't quite understand the need to set a valid hostname prior to installing a control panel.

Still don't see the SSL reason part, and that was the reason it was done in the first place. I understand the hostname part a little but, because server was reachable by ip anyway, also if an incorrect hostname was set.
Maybe DA needs the ssl for some part of installation, I don't nkow.

A check would be nice, maybe we need to put in a feature request for it, but lets have a look at the explanation of @fln first or his thoughts about our idea.

 

[SimpleSonic]

Still don't see the SSL reason part, and that was the reason it was done in the first place. I understand the hostname part a little but, because server was reachable by ip anyway, also if an incorrect hostname was set.
Maybe DA needs the ssl for some part of installation, I don't nkow.

A check would be nice, maybe we need to put in a feature request for it, but lets have a look at the explanation of @fln first or his thoughts about our idea.

A beginner would install DA without a valid hostname and then complain about the web browser security error when trying to access the panel for the first time.

Automatically setting the hostname like this allows DA to immediately install a valid SSL certificate for the hostname to avoid this.

 

[Richard G]

A beginner would install DA without a valid hostname and then complain about the web browser security error when trying to access the panel for the first time.

Beginners should read the docs more carefully before they begin.
And now they still got issues. They can reach the panel and then complaint because services are not started, because they still are installed in the background or and also after that, SSL and mail issues will occur because they don't change the hostname and don't make any DNS zone for it.

If you advise them at the installation point to create a valid one and DA create automatically a zone entry for it again, that avoids the other issues.
Or refused DA to install without valid FQDN. Lots of Datacenters already provide default hostnames on servers and vps systems.

 

[fln]

@twhiting9275, quick recap https://forum.directadmin.com/threads/hostname-selection-during-install.67124/post-353071

...
TLDR; If hostname returns server and hostname -f returns server.example.net you will get an auto-generated hostname from the da.direct zone. Ensure you store FQDN in hostname and DA will use that if it resolves to your server IP.

DA installer does not always generate hostname. The problem is that different admins have different understanding what is "properly configured" hostname. DA prefers to use FQDN hostname which is not what is historically recommended by distro maintainers.

I suppose everyone voting for "properly configured" hostname detection is actually asking DA to start using locally configured non FQDN domain. Which would mean we installer still would need to swap it to fully FQDN hostname, because other parts of DA expects it to be like that.

 

[Richard G]

is actually asking DA to start using locally configured non FQDN domain

Not really, at least not me. When looking at the recap point 3.....

If uname -n contains . perform DNS lookup for it, iterate over the results if any of the returned IP addresses match server public or server local IP address use the server hostname if it does not match use auto generated from da.direct.

Now a FQDN hostname always has 2 dots, being something.domain.com for example, or more dots in case something like a .co.uk domain. Anyway to me a properly configured hostname is an FQDN hostname.

However, how does DA uses the DNs lookup? From DA or from where?
Also, since often a server is new, and no domain on it, most likely when an admin configures a hostname itself, it might not even resolve yet, because domain etc. is done once DA is setup.

So how would you expect the hostname to resolve, unless rDNS/PTR is setup -before- even the setup is started? Otherwise it can't propagate.
That confuses me.

Which probably was the reason, in spite of having a correcly setup fqdn hostname, still the da.direct name was used as I didn't setup the PTR record yet. So shouldn't point 3 be changed to check for 2 dots and use that hostname and do not use da.direct?
Or am I missing something here?

 

[fln]

The steps DA installer performs to pick between real hostname and auto-generated one:

1. If host name is configured via DA_HOSTNAME environment variable or /root/.use_hostname file - use it unconditionally.
2. If host name reported by the kernel (could be checked with command hostname) does not contain at least one . - use auto-generated host name.
3. If DNS lookup for the host name (could be checked with command getent hosts {hostname}) fails - use auto-generated host name. Note: the lookup is performed using standard system resolved, meaning that results from /etc/hosts file will be used if present!
4. Iterate through all results from the DNS lookup (both IPv4 and IPv6) if at least one of the IP address in the results matches the either server global IP address (detected simple request to DA servers) or local IP address (source IP used for request to DA servers) - use configured host name, otherwise use auto-generated host name.

As you can see the only critical part is host name being FQDN rather than a single word. Most distro installers already takes care to add host name entry with IP address to the hosts file. The host name does not need to be publicly available (as long as it is present in /etc/hosts it will work). Reverse entries does not matter at all.

A quick demo showing how locally configured host name being picked up by the DA installer:

# hostname qwe.rty
# echo "$(curl -s https://ifconfig.io) qwe.rty" >> /etc/hosts
# bash <(curl -fsSL https://download.directadmin.com/setup.sh) '{license-key}'
...
Here is the information given:
Admin User:         admin
Admin Email:        [email protected]
Update channel:     current
Network Device:     eth0
Server IP:          ...
Server IP Netmask:  /32
Server Hostname:    qwe.rty
...

Note: command curl -s https://ifconfig.io is here to detect your server IP address, you can replace it with real server IP.

---

Now a FQDN hostname always has 2 dots, being something.domain.com for example, or more dots in case something like a .co.uk domain. Anyway to me a properly configured hostname is an FQDN hostname.

One dot is enough. Server host name could be example.com.

However, how does DA uses the DNs lookup? From DA or from where?

Local system domain name lookup, taking into consideration system DNS configuration and /etc/hosts file (same as for example ping command would do).

Also, since often a server is new, and no domain on it, most likely when an admin configures a hostname itself, it might not even resolve yet, because domain etc. is done once DA is setup.

It does not matter, if hostname is not yet live an entry in /etc/hosts is enough.

If host name is already available (being served by some 3rd party DNS server or your domain registrar) it will work even without entry in /etc/hosts.

So how would you expect the hostname to resolve, unless rDNS/PTR is setup -before- even the setup is started? Otherwise it can't propagate.
That confuses me.

It has nothing to do with PTR (or reverse DNS) records. They are not checked and completely irrelevant for the DA installer decision of picking locally configured host name or auto-generated host name.

Which probably was the reason, in spite of having a correcly setup fqdn hostname, still the da.direct name was used as I didn't setup the PTR record yet.

No. If FQDN is set as server host name it will be used as long as this FQDN can be resolved locally. Quick test ping -c 4 $(hostname) if you see your server IP in the output DA installer will use locally configured host name.

 

[Richard G]

meaning that results from /etc/hosts file will be used if present!

I will doublecheck that next time, because I always set it up this way in /etc/hosts and /etc/HOSTNAME and I thought last time I still had to change the da.direct name to the real hostname in DA.
And I always do a reboot after changing hostname and date/time settings some other things like colors.
I must have been mistaken then. Which might be... having some memory leaks lately due to my age.

One dot is enough. Server host name could be example.com.

Oeps... In this case you are mistaken.
That is a domain name, not a hostname. Hostname is like server or mail or whatever. The FQDN hostname which is required for most things, contains the hostname and the domain name, so host.domain.tld which are 2 dots (minimal).
Check RFC 4703.

FQDN, or Fully Qualified Domain Name, is the full name of a system,
rather than just its hostname. For example, "venera" is a hostname,
and "venera.isi.edu" is an FQDN.

so server would be a hostname, but example.com would not be.

It does not matter, if hostname is not yet live an entry in /etc/hosts is enough.

In that case we don't need to worry and there should be no issue.

@twhiting9275 Did you use the /etc/hosts file and set the fqdn hostname up this way or did you only use the PTR/rDNS record before installing DA?