Virtualmin - potential FQDN issues on install

A potential issue with a fresh install of Virtualmin on Thursday, November 17 2022 at 6 P.M. EST

Installed on VM with 2 cores, 4 GB RAM and 500 GB Storage

– Software Versions -
Operating system Ubuntu Linux 22.04.1
Webmin version 2.001
Usermin version 1.860
Virtualmin version 7.3-1
Authentic theme version 20.01.1:5
Perl version 5.034000
Path to Perl /usr/bin/perl
Python version 3.10.6
Path to Python /bin/python3
BIND version 9.18
Postfix version 3.6.4
Mail injection command /usr/lib/sendmail -t
Apache version 2.4.52
PHP versions 8.1.2
Logrotate version 3.19.0
MariaDB version 10.6.7
ProFTPD version 1.37
SpamAssassin version 3.4.6

This is in reference to Original post

I have been on the road quite a bit for the past little over a month and why I was not able to follow up until now.

Let me also apologize in advance for the quality of the video, I have already put so much time into this, but I do hope it conveys the heart of the matter.

While my original issue did not seem to happen, I still see an issue that the configuration tool flagged last time last month that is not flagging now, I will mark them in video timestamps here.

Here is the video on youtube - Video

I start off by showing the network configuration, hosts configuration, and hostname of the system.

I go from there to show the system is completely up to date from there I start the Virtualmin GPL install (I do have a pro license, but am not using it right now)

After the installation is finished, I change the configuration for the antivirus scanner to use a private mirror (with all the re-installs, I ran into the rate limit for ClamAV definition downloads.)

From here I move onto the web dashboard to complete the Post Installation Wizard at
Post Install Wizard
at this point, it is supposed to pull the FQDN of the system and has been so for the past 5+ years of installing Virtualmin with Ubuntu up to this point.

At Post Install Wizard 2
even though I don’t use this, it does the same thing, this is supposed to be the FQDN here. Instead, it is just the hostname with 2 periods after it.

At Re-Check Configuration
While it succeeds here, it failed me in the past, I will show you later what I had to change, and something new I noticed as well.

At Network > Hostname and DNS Client
Normally, a 127.0.0.1 is added in front of the public DNS servers here, and before (in the original post) when doing this it
“fixed” the FQDN on the dashboard (at least until reboot), but doing this now does not seem to fix that at all.

At Dashboard
The system hostname (usually this is the FQDN, but now it is the hostname with two dots after it) While the command from the last post
hostnamectl set-hostname fqdn
does seem to fix this issue, I want to just be sure that there are indeed no further issues since my install(s) seem to be doing strange things with the hostname and two periods after it. Though it is still confusing since from what I understand:

Hostname is only the first part of the FQDN and that command seems to change the hostname of the system to the FQDN. The reason I am so confused is this is not working at all how it has been for the last 5+ years for me. I do apologize if this is how it is supposed to be working now.

At Postfix Mail Server > General Options
An area that failed the “Re-Check Configuration” before and still has errors in it that the configuration check is missing. There is a blank between localhost.thedallasnewera.com and localhost. Along with at the end there is host6.. again (the hostname with 2 periods) Looking at previous installs on 20.04 and Virtualmin 6, there still is a blank here, but localhost is the last entry here, there is no hostname after localhost. Don’t know if this helps or just muddles things more.

With my limited knowledge and relying on the configuration check feature to tell me that there are issues, where there were errors before, and I still see the same issue now, but the configuration check is not flagging them as issues anymore. My question is, since I am relying on the configuration tool to tell me if there are any issues, with this new install, do you see these as issues or is this “normal” now?

I do apologize it took so long to get back to this and put up a video of the issues I think I have been having. I do appreciate all the help. I just do not want to migrate everything over to a new system with potential issues. I also apologize again that it took me so long to post this after I created the video. Youtube took forever to finalize the edit I performed and I got busy again.

Thank you

@a10sth,

I’d be happy to discuss further the issues you are having and work towards a solution. My rates are reasonable if you’re interested.

*** Professional, Affordable, Trusted Technical Assistance – tpnAssist.com ***

I have fixed a few issues recently on Virtualmin install.sh script related to setting the hostname upon initial installation.

After reading through out your post and checking the video (thanks for it, great work!) I can see another improvement that should be done in addition to those changes that were already made (but not yet pushed to the users).

Currently the problem is that hostname -f command can return FQDN, while /etc/hostname contain something else. We will make sure to always set fully FQDN after running the detection upon initial install.

The work-around in your case for now would be to manually run before running install.sh:

hostname not-FQDN              # where not-FQDN is host6
hostnamectl set-hostname FQDN  # where FQDN is host6.yourdom.com

Note: Running install.sh script will ask you again to enter FQDN, this is intentional and necessary with the current code, so you should also put host6.yourdom.com when asked.

Give it a try with a new clean install and tell me if that solves the problem for you. We will fix that in Virtualmin install.sh script (version 7.0.2 or higher), so it will be done automatically.

thank you so much llia, a few things I want to go over quickly.

this does seem to change the /etc/hostname from the system hostname to the FQDN

Last night, after I posted this, I did a clean install of 20.04 and installed all upgrades, configured network, hostname and hosts file. From there I performed a do-release-upgrade

After that, I still ended up in the same situation. There are some things about the new “Live” installer that I like and don’t like. I went this long roundabout way to see if it was contributing to the issue, and it does not seem to be.

As long as I have the /etc/hosts file set up correctly, the installer has “NEVER” asked this question, if you review the video, the only question it asks is if I want to proceed with the installation.

In the setup I performed last night I made 2 snapshots, 1 before the upgrade to 22.04 and 1 before running the install.sh

I am going to restore to the last one before the installation and run the install script as such:

/bin/sh install.sh --hostname host6.thedallasnewera.com
or
/bin/sh install.sh --hostname

since I do not know yet if it requires the FQDN as part of the command or just alone to tell the installer to ask for the FQDN

I thought about this as well and thought to manually “give” the installer the FQDN…

there still seems to be the issue of the installer not adding 127.0.0.1 being added to the network configuration above the public DNS servers…

I have included all these since they are all possible install issues

We set it to the actual, detected IP address.

I have already made patches to always set hostname, even if hostname -f returns FQDN at the first place. Before we didn’t do it, nor ran systemctl set-hostname command.

If you run the following commands on your system, what output do you get?

defaultdev=$(ip ro ls|grep default|head -1|awk '{print $5}')
ip -f inet addr show dev "$defaultdev" | grep 'inet ' | awk '{print $2}' | head -1 | cut -d"/" -f1 | cut -f1

returned nothing

returned the local static IP address of the system

I am about to roll this back and try what I mentioned above.

I just got done setting up with the following command

The installer did not ask for the FQDN during install

I rolled back and am trying

My first hurdle on the post installer for DNS configuration is showing the FQDN now, I will complete the setup for this and get back to you in a few.

The funny thing is, and you can see this in the video as well, at the end of the install, it gives you the URLs you can go to perform the post-install, it uses the FQDN here for all of my installs so far.

OK,

This is still changing the Hostname of the system from host6 to the FQDN (/etc/hostname)

In all previous installs up to now, it has not done this (/etc/hostname stayed the hostname, not the FQDN). Is the correct going forward or is this incorrect?

Do I no longer need 127.0.0.1 listed as the first DNS server under Hostname and DNS Client? It is currently not listed at all.

I do apologize, I just would like clarification since this is different that I have set up this system going back to Ubuntu 16.04 While I do know that some of the network configuration files on ubuntu itself has changed from 18.04 to 20.04, the base configuration I have performed for the past 5+ years has fundamentally not changed.

thank you,

Host name should be FQDN.

It should point to the system, preferably to the local static (external or intranet) IP address.

Try this and let me know if everything work for you as expected.


Although, I am not exactly sure if it’s needed to also additionally add 127.0.0.1 FQDN line to /etc/hosts file. I think setting 127.0.0.1 localhost should always be there, and we already add actual system IP address.
Hopefully, @Jamie or @Joe could clarify if also adding 127.0.0.1 FQDN to /etc/hosts would be needed as well, considering that we already set 1.2.3.4 FQDN, where 1.2.3.4 is actual system IP address.

In other words, this is what we currently have after initial installation (IPv6 entries were removed):

127.0.0.1    localhost
127.0.1.1    ubuntu22-pro
10.211.55.50 ubuntu22-pro.virtualmin.dev ubuntu22-pro

The question is, if it has to be:

127.0.0.1    localhost
127.0.1.1    ubuntu22-pro.virtualmin.dev ubuntu22-pro
10.211.55.50 ubuntu22-pro.virtualmin.dev ubuntu22-pro

I don’t know. I think the 127.0.1.1 stuff was added to deal with some quirk on Debian/Ubuntu systems, but I don’t remember what it was…so long ago.

I don’t think I ever liked it working that way. If it’s no longer needed to get hostname working right, I’m fine dropping it, as long as it gets tested.

when I am talking about 127.0.0.1 address I am actually talking about it in a different place than you are.

New install using 22.04 and new VM 7 installer:

Prior to VM7 installer with Ubuntu 20.04 and prior:
new VM 7 installer with ubuntu 22.04

This is the location I am speaking about the current installer not adding the 127.0.0.1 address.

I will try the installer you have posted above and get back to you in a few.

one thing I did not include in the pictures since you have said that the hostname should be the FQDN is that in the prior installs, the hostname is only the hostname here as well not the FQDN. I only took snapshots of the area I was trying to emphasize for the 127.0.0.1.

Thank you,

That’s completely unrelated to hosts. That’s resolv.conf, which determines DNS servers.

We removed that from the default install, because it confused more people than it helped. It assumes Virtualmin is managing DNS locally, which is becoming less and less common as more non-technical folks are using Virtualmin, and as cloud DNS options become more popular with technical users.

It was to make Preview Site work before DNS propagates, among other things, but they’re all pretty minor improvements, while configuring it that way caused a lot of grief and confusion for people not hosting DNS locally. So, it’s gone.

1 Like

It’s also worth noting that most modern systems overwrite that file on every boot, via some automated process (there are a few ways it can happen, we’d have to configure all of them). DHCP was covered in the past, but now there’s also a systemd thing, cloud-init, and custom things that hosting providers do. It’s a mess.

Since I am using it that way should I be adding it back?

As for the updated installer, it works the same as me using the current installer as:
bash install.sh --hostname host6.domain.tld

Thank you both for all the quick help and question answered. I will be waiting for Joe to answer the last question and I will move forward with the clean install/migration.

Thank you again!

You can, if you prefer that behavior.

As I said, it is mostly for the Preview Site feature, and there are some other bits and pieces that will be able to work before DNS propagation if you enable it. If you get your DNS right early (i.e. you delegate your zones as soon as you create them, but before you do anything with them in Virtualmin) there is no difference in how things will work. It’s not something I do on my systems even when they host DNS locally.

thank you Joe and Ilia

@Ilia

I hope this doesn’t come across as being nit-picking but shouldn’t it be virtualmin-install.sh with two ‘l’ not one? Again please don’t take this as a criticism, it’s just to help people like me who are new to VM to do things correctly.
Thanks

Yes, right. Fixed.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.