Last updated on August 20th (last edit date visible on post). So there’s a gap.
The post is wikified (i.e. editable by any user), so if someone knows something is incomplete (s)he can fill it in.
Unofficial comparison tries to be objective/unbiased.
2 Likes
Hi @mrmarkuz
I would say it’s commonly agreed on, that in AD, a second DC serves the purpose of redundancy, in case one DC barfs.
Looking at here:
https://docs.nethserver.org/projects/ns8/en/latest/user_domains.html
I do see very contracdictory claims:
And a nice warning about the not synched SysVol volume…
But moments later this:
The replica DC is not accessible to the network, only to the internal Cluster network for Apps.
Just great! Apps. have redundant authentification, but as DC1 is down, no clients can log in, so no internal user can actually use these apps…
It does sound a bit like placing the cart in front of the donkey - the cart pulls the stuborn donkey…
SysVol Replication could be done with rsync, or other sync tools.
But then again, what for?
I do really think that file sharing and authentification (As AD is the only option, and file sharing is now more or less CIFS…) deserves a bit more attention.
And maybe also - and just as important - someone writing the docs who actually understands what redundancy means and implies in the context of AD and AD Replicas.
A simple Linux VM with AD as DC2 would serve some purpose, be accessible for both LAN clients and cluster applications, and provide authentification redundancy for LAN and other clients, including Apps.
→ This seems to make more sense to me at the moment than a DC which can’t provide redundancy in case DC1 barfs…
This NS8 AD Replica doesn’t really seem thought through - or serve any usable purpose.
Why is NS8 boasting over 100 Apps, but a simple File Server like any other Linux offers, is now no more important or really cared for - I still hope this mentality will change…
My 2 cents
Andy
5 Likes
Likewise the web server.
2 Likes
This is enlightening this overview but unfortunately not reliable. Difficult to make decisions on this basis.
As I already wrote: With a new product, it is up to the user to deal with whether the product provides the required functions. If this is clearly communicated, the help is rich, if not you can find out that if necessary. Whether you are driving this effort depends on how much you prefer the product. Otherwise you would choose a better documented product.
In this case, however, there was talk of migration from the start. In my understanding, this means not only the transfer of data but also of functions. It was also said that this would not apply to all functions. But not clear and detailed for which yes and for which not.
Even today this is not completely documented:
Limitations
The migration tool supports a limited set of applications. If an application is installed but not listed on the migration tool page, it will not be covered by the migration process.
The following configurations are not migrated:
- Custom templates
- Account provider password policy settings (see Account provider)
- System smart host settings, if the NS7 Email app is either not installed or not migrated
Additionally, shared folders will not be migrated if NS7 uses a remote account provider.
Which information page is meant by “migration tool page”? An information page on www.nethserver.org? I can’t find it there. What I find in the docs is cited above.
Or is an information text that is displayed in the migration app? So I only see it when I install a migration app on a system that I don’t even know whether I can use it useful? Because I just want to find out. Therefore I have never installed this app and called up. So far, only several NETH8 installations have been running as an experiment, but I have not yet changed any existing NethServer7 installation. In other words, I have to create a NethServer7 test installation, have to install all the services to which I wish for migration information and then I can safely install the migration app and see which options are viewed or named there? Mh …
Without having already checked there, I would still suspect that the information there is incomplete. Because the ad and files server will definitely be listed there - because it is generally migrated. But this always included the print server. But it apparently omitted as I had to read here.
To make this clear: I love this community for your willingness and help and admire the developers for their enthusiasm. But the community portal seems to be the wrong place to guess product information.
The post is wikified (i.e. editable by any user), so if someone knows something is incomplete (s)he can fill it in.
In my opinion, the creation, expansion and correction of a functional list is clearly the task of the developers. Without compromises. Only the developers completely know about the developed, eliminated or future functions of their product. Or someone else who is comparable to the development process. This may then complete the list promptly and ensure that it is also linked to the docs. Or do I expect too much?
Users can only contribute their experiences, which works of the functions and what they do not - and what they still miss. This is also an important contribution and where I can help. The list quoted is not a functional overview, but a “it works or not” overview (not even a download). This is something completely different.
As I currently understand this overview, it is the analogue for a reingineering process. The functions apparently have to be determined experimentally. So we have a case of “Open Source” but without “Open Functionality”. Do I have to understand that?
Unofficial comparison tries to be objective/unbiased.
I try to think neutral and to express myself that way. Unfortunately, this openness is often misinterpreted (the problem of my life). However, my contributions are only to be understood in the matter - never personally. Never. Maybe I should write that into my profile.
1 Like
Maybe it refers to GitHub - NethServer/nethserver-ns8-migration
1 Like
I got you.
How would you improve the migration process and inform the admin of that?
I got you.
How would you improve the migration process and inform the admin of that?
As far as I can see, (suspected) errors have so far been reported directly in the forum and then, if necessary, upgraded by the developers themselves to “bug”. I basically find this path correct.
A list to make mistakes or shortcomings clearly a good idea. In my opinion, the developers should also decide whether the respective entries are actually bugs or not. In this respect, for reasons of simplification, it makes sense to have the list led by the developers themselves. And if there is already something like that, a link to the forum would be nice. The separation between the forum and Github is not particularly practical for obtaining information. When I am looking for information, I do not look in the developer. Especially not as a possible end customer - that should also exist.
The above list helps interested parties (newcomers or NethServer 7 experienced) but only further insofar as you can refer to the entries mentioned. What other restrictions there. Nethserver 7 still gives - which have not yet been reported - the list cannot say anything about this. The developers, on the other hand, know what they develop and what options they offer or omit. You can’t be closer to the process. It would be desirable to inform about this. I only understand too well that documentation is annoying, but it is essential if you don’t just develop for yourself.
1 Like