Yesterday I started migrating a Nethserver 7 to NETH8. Before “finishing” the SAMBA/AD migration, I was asked which network (or which IPv4) I wanted to use for this (for the future AD or the transfer). The options were the IP or host network of the NETH8 host (192.168.88.x(/24)) or the IP or network of the cluster (10.88.0.1(/24)).
To ensure that the transfer did not fail (it takes long enough), I instinctively chose the local host network - its accessibility had been checked. The transfer is still running, but the AD now seems to be accessible (including the user shares)
Today I installed another completely new NETH8 (without migration) as a test and created an AD there. I noticed that its IP comes from the local cluster network by default.
Now I’m not sure whether I was wrong with my selection during the migration (host network) and whether I should have chosen the cluster network instead? I
I would like a configuration where problems don’t arise later due to this “special” decision or where I don’t have to expect any restrictions. For example, I think it would be difficult to move the AD to another node with the host network address.
Can this be changed later? Or do I have to go back to that point in the migration?
Now I’m confused. An AD with a cluster IP can be reached within the cluster (apps), but certainly from outside the cluster via (local) host IP and port, which are then passed on “inwards”. And the AD should of course be able to process “external” as well as “internal” requests. The NETH8 has been able to do this so far.
In this respect, both ADs (regardless of whether with a host network IP or cluster IP) would be accessible “externally”, but an AD with a host network IP would possibly no longer be accessible from the cluster network (another node) without contortions.
Moreover, with a host network IP for the AD, the big advantage would be lost that the AD connection to the cluster IP would stand in the way of moving to another host network. Up to now, changing the AD IP has always been discouraged.
If I have the choice (still have), I would prefer to use the cluster IP for the AD. Hence my question as to whether this can be changed without any problems or whether I have to go back to the last step. I have to make this decision right now.
You say that a Windows PC cannot join an AD in the cluster network? Why is that the standard configuration in NETH8?
I assume that we mean different things. I am talking about the IP that the AD uses internally, and that is now one from the cluster network. I am convinced that the AD can still be reached via the host address.
The last one is NOT migrated.
This is a fresh Install.
And I have in my entire professional life NEVER had a machine tell me what IP I am to use.
I tell a machine what IP it has to use, and that’s the way things are.
After all, I am root, the mashine has to obey!
What I would be interested to know:
Were your examples all Nethserver 7 migrations or did they also include newly installed NETH8 AD? Because newly installed ADs are apparently always set up with their cluster IP.
I had not yet connected Windows clients to the new AD with new NETH8 installations, but I did have external (non-NETH8) Nextcloud installations (LDAP), for example. At least there it worked without a problem.
I would therefore like to assume that I can also use the host IP with the current NETH8 to reach the AD, even if the AD uses a cluster IP internally. I would be surprised if it were anything else, because why assign the AD a cluster IP internally by default if the AD is then no longer accessible via the host IP?
It may be better to leave an AD with connected Windows clients on the previous IPs during migration for reasons of simplicity. In this case there are no Windows clients and I would like to take the “standard route” for various reasons.
So this time I’ll go the other way and see what happens. I just have to outsource the large data folder first because unfortunately there is no content-selective migration.
I always used the AD name for the LDAP clients. You never know what will be passed through from such a query, perhaps similar to the reverse proxy. Although ad.domain.tld already works with LDAP, Windows probably wants to have a number of AD names resolved.
Therefore, the local DNS forwards everything that ends in “/*.ad.domain.tld” to the internal DNS of the Nethserver. At least with Nethserver 7 it worked that way.
It’s true that the NS8 AD Setup will display the Cluster IP first.
It’s also true that a non migrated NS8 AD will be called DC1 by default.
This is an absolute No-Go for me.
I design and plan each and every one of my client networks, down to which IP is used for what kind of host.
And I did not write a paper about Naming Conventions for Hosts in a network to let a basic computer without a single jota of intelligence telling ME what I should do? No, I’m no fan of AI, but a machine with absolutly NO intelligence does NOT tell me what to do!
And I refuse to follow “stupid” suggestions, like NethSecurity 's default IP of 192.168.1.1 - an IP which no one should ever use!
I dare say the programmer who wrote that stupid pre-defination has less than a third my network experience…
(Why? Any router a co-worker - or your son - buys in a shop will probably use exactly that IP. This would typically cause an IP conflict, meaning no Internet at hpme, no DHCP or DNS working…)
I think because it’s the more secure setting.
It seems you just missed to enable the file server. There’s a info message that it will be configured with the VPN IP:
api-cli run module/samba1/set-ipaddress --data '{"ipaddress":"192.168.1.123"}'
If you set the samba IP to the host IP address, the fileserver link is shown and the samba icon should be visible again after a browser refresh.
To hide the file server just set the samba IP back to the wireguard VPN IP.
With 2 exceptions, all my NS8 are running on Debian 12 in Proxmox, all setup usig the quick single disk method. Debian 12 will allocate a measly 1 GB Swap partition - not enough.
I completely agree with you that you shouldn’t leave the choice of names, networks and IPs to the machine. For me, this is also a question of clarity.
However, I see things a little more differently with regard to the internal AD IP. This is only determined by external factors in that it comes from the cluster network (which I chose myself) and currently ends in “1”. As long as I can reach the AD via a local host IP (which I hope), I shouldn’t care about the internal IP, just as I don’t have to care about the other internal IPs of the other containers/apps because the orchestrator sets them. As long as the containers/apps are externally accessible, I can live with it. Here I’m more concerned that resorting to a local IP scheme will limit me, because the option of moving the host or container (perhaps the AD?) could perhaps be easier with a container IP on the AD than with an AD tied to the respective host network. Or am I making a mistake here? In any case, I don’t want to limit myself to the options that are obviously still being developed.
But I agree with you overall that more local IPs (or more NICs if necessary) would open up more possibilities and that NETH8 is already very “patronizing” in several places where it really bothers and basically doesn’t need to be there. But I’ve obviously decided to bite the bullet otherwise I wouldn’t be asking here. If the migration is successful, the apple will have time to ripen again - of course without worms if possible.
You are, a big one.
Setting the correct IP to a migrated node is a CLI operation taking a few seconds…
Development for AD is done at the company Microsoft, Samba tries to reverse engineer as best as they can. But real development? It has to follow Microsofts “guide lines”.
Andrew Tridgell did a great job so far with Samba, works very well yet still has it’s caveats and gotchas!
But none of this is defined at Nethesis!
