helloSystem / Utilities

Utilities written in PyQt5, meant for use with helloSystem
BSD 2-Clause "Simplified" License
28 stars 29 forks source link

Cosmetic issue in FreeBSD Installer setting Computer Name with FQDN #119

Closed SanPollo closed 2 years ago

SanPollo commented 2 years ago

Steps to reproduce:

  1. Run the FreeBSD Installer and click Continue until you reach the Create Local Computer Account page.

  2. Fill out the details including the fully qualified domain name in the Computer Name field.

  3. Tick the box next to Enable users to log in over the network (ssh).

Actual behaviour:

Under Enable users to log in over the network (ssh) it displays the FQDN with .local appended to it. e.g. daemon.mydomain.ro.local.

Expected behaviour:

.local. is only appended if the hostname provided by the user does not include the rest of the FQDN (e.g. daemon.local.)

fqdn

probonopd commented 2 years ago

Also the the trailing full stop should not added to the end of the name as it is a command, not a sentence, and this is confusing.

This is not a punctuation mark but actually part of the *.local. domain - it is beneficial to put it there, at least if I am not mistaken:

http://www.dns-sd.org/trailingdotsindomainnames.html

That website is maintained by Stuart Cheshire, the very genius behind Zeroconf (also known as Bonjour), so I'll take his word for it.

SanPollo commented 2 years ago

@probonopd I stand corrected, and have amended the bug report, however it still shouldn't append .local. to a FQDN i.e. it should say daemon.mydomain.ro. not daemon.mydomain.ro.local.

probonopd commented 2 years ago

Interesting point. Do people still expose machines directly to the public Internet without NAT, isn't that much too dangerous nowadays? Last time I have seen something like this was in the 90s in a university.

SanPollo commented 2 years ago

You're absolutely right, however on the corporate networks I have helped to administer (and my home network too as it's full of random servers and other devices!) a machine always has a FQDN even if it isn't accessible outside the network. Admittedly, on corporate Windows networks, the FQDN is not always set to an actual internet domain, but sometimes to a pseudo domain one such as localdomain.myorganisation.corp.

At home, for example, my domain is bromania.eu and this is the search domain that I have set up in DHCP server settings so whenever I ping a machine from a DHCP client it appends the .bromania.eu to the end of it (you can see it in /etc/resolv.conf for FreeBSD clients). Similarly, those machines with a static address also have bromania.eu as part of their FQDN (and in their search domains).

So, while only www.bromania.eu and wiki.bromania.eu are visible to the outside world, other machines like the netbook running helloSystem - daemon.bromania.eu - is only accessible inside. My DNS is also set up to make sure that any requests to www and wiki are sent via the internal IP and not routed via the internet.

This is just an example of how I do things. From a FreeBSD point of view, to the best of my knowledge the FQDN should be specified in the hostname option of /etc/rc.conf. Then typing hostname -s shows the short name, and hostname -f shows the FQDN. The man page is here.

And this leads me to another question - I noticed that in helloSystem, the hostname option in /etc/rc.conf is set to "FreeBSD" so the real hostname must be set elsewhere. I was just wondering the reason was for doing this?

EDIT: Corrected hostname syntax.

probonopd commented 2 years ago

You're absolutely right, however on the corporate networks I have helped to administer (and my home network too as it's full of random servers and other devices!) a machine always has a FQDN even if it isn't accessible outside the network.

True, didn't think of this. So we should not append .local. in case the hostname contains .. Does this sound about right?

And this leads me to another question - I noticed that in helloSystem, the hostname option in /etc/rc.conf is set to "FreeBSD" so the real hostname must be set elsewhere. I was just wondering the reason was for doing this?

For the Live system: https://github.com/helloSystem/ISO/blob/98b56318ce878a80b640db4478ef6fff6a2eb127/overlays/boot/boot/init_script#L191

SanPollo commented 2 years ago

True, didn't think of this. So we should not append .local. in case the hostname contains .. Does this sound about right?

This was what I was thinking. If I actually test this on the command line, though, hostname -s says daemon and hostname -f says daemon.bromania.eu so it's only a cosmetic issue in the installer.

For the Live system: https://github.com/helloSystem/ISO/blob/98b56318ce878a80b640db4478ef6fff6a2eb127/overlays/boot/boot/init_script#L191

On the live system this works well - I was impressed to see that my hostname was set to E402M. It is also correctly set in the installed version, and you can see this in at the Terminal prompt, and when using the hostname command.

I was just surprised to see that in the installed version, hostname is set to "FreeBSD" in /etc/rc.conf. I guess it is setting it in the same way as it would with the live system, but with a user-specific hostname. It works absolutely fine, I was just wondering if it would be better to set it in /etc/rc.conf to keep helloSystem closer to a standard FreeBSD installation?

I can also open a new issue for this if you like seeing as it is different to the issue I originally reported?

probonopd commented 2 years ago

Yes, please always open separate issues for everything that you think should be changed, so that ideally every issue can be closed by one commit (one change in a source code file). This helps a lot. Thanks!

For mere questions (when you are not sure that something needs to be changed) please use the Discussions forum.

But to answer your question, this is how the installer sets the hostname: https://github.com/helloSystem/ISO/blob/f4f8c43f0888c2c6e0de5621a1c0fce132411082/overlays/uzip/furybsd-live-settings/files/usr/local/bin/furybsd-install#L237

Changes in the hostname made via Applications -> Preferences -> Sharing end up in /etc/rc.conf.local, I just checked. Note the .local.