Why and when installer auto-generates host name?

[fln]

That is a domain name, not a hostname.

Yes. However if you want DA to not auto-generate a host-name you need to set FQDN as your host name. If you set up host name and domain name separately it will not be used. Some examples:

DA will auto-generate host name on this server (will NOT use configured hostname) because its host name is set to server:

$ hostname
server
$ hostname -f
server.example.net

DA will NOT auto-generate host name on this server (will use configured hostname) because its hostname is set to server.example.net:

$ hostname
server.example.net
$ hostname -f
server.example.net

For any value set in the host name to be treated as FQDN it needs to have at least one . symbol. DA will not stop you using your domain name as FQDN, but we do not recommend it. My qwe.rty example in previous post was picked deliberately to stress out two points:

• qwe.rty has only one . symbol and would be recognized as domain name by most of the readers, this shows DA allow you yo use domain name as FQDN if you really wanted to.
• .rty is not a valid TLD, this shows DA does not care if your FQDN reachable globally (list of registered TLDs - https://www.iana.org/domains/root/db)

---

I think most of the people reading this thread wondering why DA auto-generated the host name instead of using already configured tripped on the check - does host name contain any . symbols.

If you enter something as server.example.net in the OS installer. It will set your host name to be server not to server.example.net. This means DA will discard your configured host name and will auto-generate IP based host name for you.

This way auto-generated host names are used 99% of the time. However if you know what you are doing and manually have changed host name to be FQDN DA will use it.

There is a big difference between server being aware of its FQDN and setting host name to be FQDN In my first example above if hostname -f reports server.example.net, but hostname reports server it means OS is able to derive FQDN but real host name is set to a simple string server.

 

[ikkeben]

There is a big difference between server being aware of its FQDN and setting host name to be FQDN In my first example above if hostname -f reports server.example.net, but hostname reports server it means OS is able to derive FQDN but real host name is set to a simple string server.

Can you test this old topic with that mailtester while i didn't solved it for all time

And afraid to break things while no time to solve or ..

mail sni domain = 1 but then with test on x509 error on FQDN TEST European Commission

Is important to have more info about this official test! TEST European Commission My Email Communications Security Assessment (MECSA) x509 Certificate FQDN error mx record to mail.domain.com in dns mailsni=1 Did all rebuild rewrite and updates! latest DA exim, dovecot, custombuild gui ...

forum.directadmin.com

 

[Richard G]

There is a big difference between server being aware of its FQDN and setting host name to be FQDN In my first example above if hostname -f reports server.example.net, but hostname reports server it means OS is able to derive FQDN but real host name is set to a simple string server.

Thank you for clarifying this.
In my case any command will always give the correct fqdn hostname. Maybe because I always set it via the OS hostname command, then check and edit the /etc/hosts file and also the /etc/HOSTNAME file so all are the same.

qwe.rty has only one . symbol and would be recognized as domain name by most of the readers, this shows DA allow you yo use domain name as FQDN if you really wanted to.

Well yes, but as you can see from the RFC example, a domain name is not a FQDN. So then DA indeed allows things as they should not be, causing issues anyway eventually. But oke that is your choice.

As long as hostnames don't get overwritten by DA installation when correctly setup, then all is fine as far as I'm concerned.

Just wondering what or how @twhiting9275 was doing it, since he got issues.

 

[twhiting9275]

DA installer does not always generate hostname

It does, though.. Unless you specifically instruct it NOT to. This is quite literally backwards. if a legitimate , verifiable hostname is setup, then DA should never alter it, ever.

No. If FQDN is set as server host name it will be used

incorrect. I've had this happen multiple times over the course of the past few months.

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?

I always hit up cloudflare/QUIC, depending on the domain and use, and modify the DNS once I decide on the new hostname. In fact, most of the time, it's within moments of the provider releasing the server (just have to wait for that IP)

DA takes me an hour or so to get to, usually, as I have to set other things up

 

[LawsHosting]

So if I understand: If /etc/hosts has serverNN in, the DA setup will use the da . direct addition and if /etc/hosts has serverNN . yourdomain . xxx in, it'll use that.......

If so, not that hard..

 

[Richard G]

So if I understand:

Correct, if the /etc/hosts has a FQDN hostname, so that is ful like server.domain.com or what is more often the case, just like with localhost:
127.0.0.1 localhost.localdomain localhost <server.ip.here> server.domain.com server
then DA should use that hostname, that's how I understood it too.

 

[twhiting9275]

Go figure, nobody paying attention to anything that's being said here

Once again, same issue. A PROPERLY configured hostname (server.domain.name), and DA changes it AGAIN

No, I shouldn't have to setup a variable to tell DA to not do this. That would require editing the script every time I need to use it. That's garbage.

NO, I shouldn't have to change my hostname back because something that had zero authorization, or permission to do so changed it in the first place

STOP
CHANGING
THINGS
WITHOUT
PERMISSION

 

[Richard G]

Once again, same issue. A PROPERLY configured hostname (server.domain.name), and DA changes it AGAIN

If that is the case, then it's not working as @fln explained and then it's a bug which needs to be solved.

 

[twhiting9275]

If that is the case, then it's not working as @fln explained and then it's a bug which needs to be solved.

I've always had proper hostnames setup. Always. I'm incredibly pedantic about that.

 

[woktron]

what a terrible way of doing things.

changed to a FQDN hostname with hostnamectl set-hostname
/etc/hosts has been adjusted
/etc/hostname has been adjusted

Confirmed with hostname, hostname -f and hostnamectl commands.

Still DA insists on changing the hostname and messes with resolv.conf. One of the prime benefits of DA in the past was that it did not make any changes to your OS, this now seems completely out of the window.

If you insist on scripting this, at least ask the user for permission before proceeding.