NS8 - public FQDN required?

@stephdl currently NS8 is not interesting to me.
However, writing ot that part of the site might be misleading. Or at least, might be to me. And if missing the availability of a public FDQN might lead NS8 not working, maybe should be written into system requirements.

1 Like

Here’s how I think it works–@stephdl or others, please correct me if I’m wrong here: When you create a cluster, NS8 asks for the VPN endpoint address. This address is encoded into the “join information.” Therefore, for another node to join the cluster (at least through the GUI), that VPN endpoint address must be something that prospective other nodes can reach–that can be an IP address (local or public), a local-only hostname, or a public FQDN, as long as any other nodes can reach it. AFAIK, that’s the only use for that piece of information.

If you’re only going to use a single node, that field can contain anything–its contents don’t matter. I agree that an edit to clarify the docs would be good, but I think it’s this that ought to be edited:

1 Like

I think this is @pike’s point: if you need to have a public FQDN for your NS8 host (as the section in the docs I quoted above, and he quoted in an earlier post, says), then that should be listed among the system requirements. I don’t know that I’d necessarily agree; “system requirements” is ordinarily taken to refer to hardware and software, not necessarily other configuration settings, but I do see the point.

Otherwise, if a public FQDN isn’t required (which it isn’t), the installation page should be clarified.

1 Like

fot that point, you simply need that the two servers can reach each others by the domain name

the ns7 I have act as my firewall on the local network, this is the host declaration in my hosts database

rocky9-pve=local
    Description=rocky on pve
    IpAddress=192.168.12.110
    MacAddress=56:d4:0c:08:d5:65
rocky9-pve.org=remote
    Description=
    IpAddress=192.168.12.110
    WildcardMode=enabled
rocky9-pve2=local
    Description=rocky on pve
    IpAddress=192.168.12.111
    MacAddress=12:e0:98:36:d4:9e
rocky9-pve2.org=remote
    Description=
    IpAddress=192.168.12.111
    WildcardMode=enabled

since my cluster gets the ip and the dns from my firewall they know each others, moreover I use wildcard so everything like *.rocky9-pve.org is know by everybody on my network, I do not bother to maintain a /etc/host on my network

another manner could be to fill on each server of the cluster a /etc/hosts with all domain and IP where you can find the servers, but it is a pain in the ass :smiley:

May or may not.
Today I install a single node, which might grow and… become part (or master) of a multinode. Same subnet? Same domain? Different location? I don’t know.
If this parameter is set and cannot be further changed, could be a bad idea write “anything but works”…

Create a server and a container/container farm orchestrator seems to me quite a different order of considerations…

I am sad :smiley:
When something new is rising I think it is the better time

2 Likes

just do it with two server on my lan

1 Like

Yes it’s possible to configure a cluster with LAN-only nodes but there’s still a missing key feature to make it effective: NS8 custom certificate

Custom TLS certificate upload is scheduled for some future release: Trello

TLS certificate today works only if Acme HTTP challenge requirements are met, so public IP + DNS record.

As almost any service in NS8 requires a TLS certificate, it quickly becomes a requirement for the whole system. However, when samba file server module is released we’ll find the rule exception.

1 Like

May I repeat that this requirement should be added into system requirements page?

I will admit that I think this is completly unreasonable!

NS8 is still Alpha!

My 2 cents
Andy

2 Likes

You’re totally right.

If you’re only going to use a single node, that field can contain anything–its contents don’t matter. I agree that an edit to clarify the docs would be good, but I think it’s this that ought to be edited:

I’m not so good with English, but I’m open to suggestions to better explain the sentence!

1 Like

Which is a reason good enough to spread misleading information?
If the public FDQN is mandatory for some scenarios, IMHO is far better for the sysadmin to know that among the requirements of the system, so any test done during this phase, even one (might be unadvisable but possible) which have a geographically split cluster scenario, will be done conscious of what’s needed.

Maybe you won’t feel what I’m trying to explain, Andy, and even my lack of consideration of the current status of some part of the project are not enough to avoid providing conscious feedback, even if it’s been percepted as unpleasant.

It’s reason entirely good enough to explain docs being incomplete and incorrect, and it’s hardly “spread[ing] misleading information” to fail to mention among system requirements that a system that’s intended to be remotely accessed should have a public domain name. Is it also “spread[ing] misleading information” to fail to mention that you need to have an Internet connection? A network connection at all? Connection to mains power? Where does it end, and at what point can they reasonably figure that anyone who would admin such a system already knows this?

There are two distinct questions here:

  • Must a NS8 system have a public FQDN?
  • Depending on the answer to the first, how (if at all) should the docs be changed?

On the first question, it’s clear that a public FQDN isn’t absolutely necessary–it’s entirely possible to install and use NS8 with a local domain name, a local IP address, a public IP address, or even a completely meaningless value, for the “VPN endpoint address.” But what you enter there will affect your ability to connect other systems in a cluster–if you enter something completely meaningless, you won’t be able to join other nodes (at least through the GUI). If you enter a local IP address, you’ll only be able to join nodes that are on the same network. And so forth. I think this could stand to be better documented than it is.

But does it need to be listed among the system requirements? I don’t think so. If it isn’t obvious to you that you (effectively) need a public FQDN to access a server from a remote network, IMO you have no business even playing with any flavor of Nethserver–this is, again IMO, on the same level as the requirement for mains power and a working network connection. And it certainly isn’t “misleading information” to not mention such obvious requirements, particularly for software that’s very much in a pre-release status, and even more so when they aren’t required for all installations.

I’d suggest something like this:

VPN endpoint address: This is the address of the leader node of your cluster, and must be reachable by any other nodes you may add to your cluster. Local network names and IP addresses will prevent you from adding systems to your cluster which aren’t on the same network as the leader node.

It could probably still be tweaked a bit, but I think it gets the idea that the VPN endpoint address only needs to be reachable from other cluster nodes.

3 Likes

If the node is behind NAT, the VPN endpoint address (host+port) can also resolve to an IP that is not assigned to any interface of the node itself.

In this scenario public DNS name and the host name can be completely different.

1 Like

Thank you, documentation updated!

1 Like

@pike

To be honest, it doesn’t even matter to me.
You can complain as much as you want about the FW in NS8 - so what?
I won’t be using it, except maybe for a single test vm in the cloud…

A server, or even a firewall, where one app, typically evebox, can block the whole box just isn’t professional or usable for me - at all!

I’m thinking more, that you’re providing misleading information / requirements for an Alpha “release”.
The firewall, as such, is even in NS7 very flakey, it’s still evebox which due to bad maintained lists often barfs and blocks the whole box. Even this week there was a post with that very reason, but in NS7…

I don’t see much difference with the FW in NS…

I am looking forward to have NS8 manage all needed services, yes!
But not firewalling, here I need something rock solid, which won’t barf due to a single app…

My 2 cents
Andy

2 Likes

More or less what NS7 needs too. Fake domain name could work but we need full domain records to make it workable

1 Like

https://ns8.nethserver.org/install.html
Paragraph has been rephrased omitting the part “public DNS record”.
However: FDQN with public DNS record is still required for geographically distributed cluster?

I complained and explained why in a another topic which is not this one. I recalled that explaining why I’d hope (even if not in the all happy bandwagon around the project) my questions and clarification will be considered bit more than stupid and useless. If I’m wrong, I think that my current “useless and stupid” time won’t spent anymore about that.

1 Like

You need a working network connection? Where’s that in the docs? You need mains power? Where’s that in the docs?

Ok, @danb35 loves me more than expected. Thank you for so much appreciacion. :slight_smile:

Me and you already know goals and costruction (well… at least the wishes)of the distro application server called NS8. Me, you and some other tens of thousands of fellows Nethserverians.

IMO for a total noob (of NethServer 7 and NS8) sysadmin should know in advance what avoid for hybrid deployment. Because without some more explanation, this could be a scenario where the “in house cluster” built from scratch can’t become hybrid due to the wrong setup assumption without a total reinstall. And considering that NS7 backup/restore procedure is FDQN-based…