Hi, I did start to configure hostname like prompted in this tutorial for ISP Config 3 installation on Ubuntu 20.04 : https://www.howtoforge.com/ispconfig-autoinstall-debian-ubuntu/ In file ect/hosts I did replace default hostname “localhost“ with e.g “aptest.mydomain.net apptest“ But in file ect/hostname, the hostname remained as “vps-NUMBER“ that is default server hostname generated by my hosting provider (OVH) Should I or not replace “vps-NUMBER“ with “apptest“ in file ect/hostname ? Regards
The hostname 'localhost' may not be replaced with a different name, each server needs to have a localhost line there. The line for the hostname of the server is a separate line beside the localhost line.
Ok, let's assume that on base of your reply, my file ect/hosts now contains both these lines : localhost aptest.mydomain.net apptest What to do next in file ect/hostname that actually only shows “vps-NUMBER“, a line that refers to my VPS default hostname at OVH ? Should I replace it with “apptest“, or should I proceed like done in ect/hosts file : add the line “apptest“ under the line “vps-NUMBER“ ? Regards
Here is how a typical /etc/hosts file looks like: Code: 1.2.3.4 server.somedomain.tld somedomain 127.0.0.1 localhost # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts replace it with the short hostname, in your case: apptest
Hi, After that hostname was changed in ect/hosts and ect/hostname files (like shown here below), it has been impossible to reboot my server using “systemctl reboot“ command line : instead of a reboot, ssh connection get unexpectedly closed with such closing message displayed in my terminal window : systemctl reboot - output message ******* START ********** root@apptest:~# Connection to vps-NUMBER.vps.ovh.net closed by remote host. Connection to vps-NUMBER.vps.ovh.net closed. ******* END ********** I then relaunched a ssh connection to my server, and run the ISP Config 3 auto-installer that has failed : https://www.howtoforge.com/ispconfig-autoinstall-debian-ubuntu/ This below is the output that was displayed : Auto-installer - output ******* START ********** WARNING! This script will reconfigure your complete server! It should be run on a freshly installed server and all current configuration that you have done will most likely be lost! Type 'yes' if you really want to continue: yes [INFO] Starting perfect server setup for Ubuntu 20.04.2 LTS [INFO] Checking hostname. [ERROR] The host name apptest of your server is no fully qualified domain name (xyz.domain.com). Please check it is correctly set. (/lib/os/class.ISPConfigDebianOS.inc.php:548) [ERROR] Exception occured: ISPConfigOSException -> Host name is no FQDN. (/ispconfig.ai.php:15) root@apptest:~# ******* END ********** //// QUESTION //// These below shows how hostname was changed on bases of your previous replies. I could also verify that changes were effective with both command line “hostname“ and “hostname -f“ May you then tell me what may prevent the auto-installation to succeed, and why does the ERROR MESSAGE says that “apptest“ is not FDQN ? This is content of my ect/hosts file : 11.22.333.444 apptest.mydomain.net apptest 127.0.0.1 localhost # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts 127.0.1.1 vps-63544ac5.vps.ovh.net vps-63544ac5 This is content of my ect/hosts file : apptest Regards
I guess you mean /etc/hostname file? Please post the result of the two commands: hostname hostname -f
If you reboot a host, ssh connections are disconnected since also the SSH server is shut down, like all other services. So it is expected that issuing reboot from an SSH connection gets connection closed message. If you want to see if the remote host really did reboot, log in again and issue command uptime . That should host has been up some minutes, if it was just rebooted. When wanting to see what happens during reboot, you must use a console session to see messages printed when shutting down and booting up.
You guessed right ! root@apptest:~# hostname apptest root@apptest:~# hostname -f apptest If I can't get further help on this forum, may I get in private touch with a developper, and grant him access to my server with new credentials, so that he may produce a short tutorial that explains how he solved such this issue ? Regards
Then your /etc/hosts file must still be incorrect. Did you check the file after the reboot? Maybe your hoster overwrote the file. In this case, you must contact your hoster and ask them how to set a FQDN permanently, this has to be done most likely in the virtualization system of the hoster then if its a vps and not a root server. You can contact the business support here https://www.ispconfig.org/get-support/?type=ispconfig if you need help by remote login. But business support is not available for free.
Just a quick clarification of the two files, hosts and hostname. Hosts is for setting IP addresses for hosts. Hostname is for setting the systems hostname. Changes made in hosts are not connected to the hostname other than you can define an ip address for the hostname. This means that changes in hosts do not propagate into the hostname file because they are not meant to. Under my Ubuntu servers there is a cloud config file located at /etc/cloud/cloud.cfg it had a setting in it for persistent hostname, this might be something you have.
Just adding a link to ipv6 thread (with several samples on hosts and netplan yaml file) that I think is useful if the OP @Keoz intends to implement ipv6 in his ISPConfig servers later on. https://www.howtoforge.com/community/threads/2-ipv6-addresses-which-one.86944/
Hi, /// SOLVED /// I found this info page on my hoster’s website, and it effectively points what is to be modified, so to have hostname changed permanently : https://docs.ovh.com/ie/en/public-cloud/changing_the_hostname_of_an_instance/ /// INSTALLATION/// Afterward, no more bugs occured to prevent the ISP Config installation (done successfully) ! Regards
