So I installed a pre-made image (Rocky based) and here are the things I would change/improve/fix in a future version:
Erm… No migration tool mentioned in documentation exists yet.
Documentation fix: No mention of default password in the section of install using a pre-built image.
Documentation fix: Several other things that are in “install from scratch” possibly need to be copied to pre-built image section OR make a common section for what is… common.
There is no clear explanation of why someone would need to install Cockpit or not and how it differs (what it manages) differently than cluster admin pages. If this gives a unified way of changing hostname and IP irrelevant of underlying distro, maybe this should become the preferred way to configure these, esp. for pre-built images instead of referring to distro documentation.
Again a documentation thing, it needs to be made clear where is which user used. For example NS8 cluster has a default “admin” user, where for Cockpit, you need the root user (or some other user you add). Actually after “installation” section in documentation, there is no step that actually logs you in the cluster admin, it just expects you know how to do it.
NS7 System Dashboard (I mean the main info page) has way more functionality and information than any details in Cluster Admin.
Cluster config backup to a local provider? (NFS etc.)
Not sure why smarthost deserves such a central setting spot (which was my question also in NS7… why was it not part of the mail configuration?).
In migration from NS7, there should be cleaner notes on the state the migration leaves the existing NS7 server. Also for failed migration. It is a very sensitive and important matter and no details should be considered “implied” or “understood from context”.
That’s it for now. Keep up the great work.
(as for me, I am not sure I will try to migrate anything before beta2)
The migration tool has been installed in your NethServer 7x in the last updates…
That’s where the migration needs to be started!
→ At the moment I have No Idea where / how to start the migration, my own testing starts this weekend!
It seems installed, but nothing in Cockpit. Need to read more on migration, sorry, can’t help you more (yet)!
I thought it wasn’t necessary. Do you have a suggestion for it?
Same as for 4
Be patient!
This could be an idea.
See my answer on the post linked above.
How would you improve the inline doc inside the tool?
We are really happy to add more info and to refactor current labels!
Thanks!
The tool is not automatically installed.
You need to install it from the Software Center or command line (if you prefer: yum install nethserver-ns8-migration)
Irrelevant thing: I don’t know how you make those smart quotes in this forum software. You do it manually?
So I have to revert to numbers (as I read all replies - so not referencing my original numbering):
Migration tool indeed shows up today. Didn’t, when I posted yesterday (and after refreshing for possible updates).
About the clarification you want on doc improvement.
First of all, everything is necessary. No info is “too much info”, as you don’t know who reads it.
My experience in my position has shown me this much. (I am 25+ years an IT pro and maybe half of them managing IT infrastructure and teams). I like to use the term “stupid proof”.
So, if you ask me, Cockpit (that seems to manage the actual “backbone” OS, outside NS boundaries), has to be pre-installed and not be enabled manually AND used to manage actual basic setup for pre-built images at least. This because, ok if you add NS8 on an existing Linux setup, hostname, IP and such are already configured, but with prebuilt images an “elementary admin” way would be nice. OR make sure to have a “first-run” script, to force user to supply required information.
I think for pre-built images, an admin user has to be pre-configured in OS level (NOT root) and share same password in shell login, Cockpit and Cluster Manager.
IIRC in shell and Cockpit I needed to use root and Cluster Manager used admin.
I am very patient. I just wanted to know that a rich dashboard is indeed in the roadmap.
Backup to local provider is hardly my idea. NS7 does it, so I expect to be available again.
Not sure where you answer in the other post about why smart-host needs its own “main” config section (also was like that in NS7), instead of being a tiny part of mail subsystem configuration. Is it because it is also needed, possibly for report emails? (even if no mail module is installed)
I have no idea of the inline doc of the migration tool, as I haven’t run it yet. But whatever is in there, should be in the offline docs too and people know what to expect in all migration cases (and issues). It is vital, given the sensitivity of the process.
Love how things are starting to be more alive (for the rest of us - surely the dev team was already very active), keep strong as a public beta means a flood of new feedback on things you may have not thought/encountered in closed alpha.
I agree, but I’m too inside the project: I hope someone less involved could help on it!
I do not want Cockpit on my installation! Too much unused deps: to do basi network stuff the CLI is enough for most sysadmin.
The problem here is: I fear that we add Cockpit we should also support stuff about the distro …
This is wrong from a security perspective: admin and rootare different users and should remain the same. root manages the OS, admin manages the cluster.
You are still free to create an administrative user for the cluster called root, but IMHO it’s a bad practice.
Fair enough: we already have the card Trello, I just expanded it a bit.
It’s needed by the app. Example: you have a server with only Nextcloud installed, Nextcloud needs to deliver mail to user for share links.
The smart host config is propagated to all installed app (Nextcloud, Mattermost, etc).
Fair enough. I would volunteer, but I cannot commit right now (due to RL).
You are probably right. Yet there should be a method to FORCE the admin set what has to be set and generally the defaults shouldn’t be used (DHCP and default hostname - always talking about pre-built images). Most small business servers (and actually most of everything) come with an initial setup script.
This is very true. Yet it would help with the original setup.
Remember, I am talking about pre-built images. These are irrelevant for existing OS that install NS8 over it.
In the setup process mentioned above, it could be added to force the use of separate admins/passwords, but right now it is a bit confusing.
Since we talk about security, right now the prebuilt image forces you to edit (cluster) admin password, but never even mentions that somewhere back there (in the OS), is a root user with a known default password (and if you don’t login to a shell, you never even find out). This is a big yikes.
Yes I saw that page of course, but needs to be expanded indeed.
All good (actually great) for a first public beta.
I am sure by next beta, you will start getting more feedback on the actual use of the clusters and modules. This beta had to “take the hit” on install issues and how things “look” from the perspective of a sysadmin.
At least for the host name setup we are going to implement it in the cluster admin UI, as first configuration step. It is an installation check point for any installation method (see Trello card).
A feature request would be a first step configuration screen on cluster-admin for FQDN, IP configuration, Timezone, Keyboard layout… (prefilled with current values and with helper/sample comment of expected value type/format). Yes, it can be done at O.S. installation or later on for qemu disk images, for instance… but I think users will find it more convenient.
Another thought, if feasable and not too bold or noob, would be a default FQDN to reach the configuration page (aka cluster-admin) without knowing the IP address, like some soho routers do… (if no major DNS problems)
IIRC, there was a request to show cluster IP and web address to reach it on the console (banner / motd…). That information is shown on journald but not on console login where would be a more useful place.
Minimum hardware requirements for a single node installation:
2 vCPU/cores
2GB RAM
20GB disk
Clearly document hardware requirements. HDD seems to be a no go (processes taking too long, hanging or ending in failed state). Why I tried with HDD? plenty of space on HDD, not so much on SSD on personal computer with virtual machines for testing.
EDIT: not advocating for HDD use, that wasn’t the point.
Note: would have prefered to have more time to test it before commenting …but don’t have the luxury. Did some tests, maybe a month ago or so, with debian qemu image on virtual machine manager and was unable to join a node to cluster (maybe some of the network configuration that is done automatically on VMM), on cluster admin the node showed as joined but status was offline/unreachable or something of that sort, apparently an error while creating wireguard interface on node 2… after many tries an no time to spend on it desisted to test ns8 beta1 any further.
What’s missing there is administration of the server itself. Things like software updates, power control, network configuration, hostname (this one is pretty critical to many other elements in NS8), etc. The messaging I’m hearing has been, “this is a function of the base OS, not our problem.” And if that’s Neth’s position, it represents a radical departure of the UX compared to the last 20+ years.
I use Neth, and SME before it, and e-smith before that, as an easy-to-administer all-in-one server. I don’t much care, unlike some others, what technology is used to make that happen (so long as it is, or can be made, reasonably secure). But when you give me a dashboard that can’t admin the server, that’s a massive change, and IMO a huge drawback.
IMVHO this might collide with the trans-distro current approach, even with the multi-node setup.
Not all nodes might use the same distro
Not all nodes might use the same timezone, default language, and so on
Currently NethServer should mess “a lot less” with operating system than NS7, which heavily relied on (NS Module = CentOS7/systemd daemon/service); currently, every module should be a container.
I personally find too thin the 2GB ram requirement, even for minimum. It’s like CentOS Stream, who declares 2gb as minimum ram adding “system will run with 1 GB but performance will be affected”… however CentOS stream do not consider that containers will run on that.
@dnutan flash storage today is accessible for bigger size, even workstation class (which is far more reliable than consumer class). However, as tb/dollar ratio, you can’t still beat the price (and reliability) of mechanical drives, and for specific tasks i’d still consider HDD storage as a possible path.
Issue is that… if i cannot change par container storage settings i won’t be able to tell the system “this file server container goes here, this mailserver container goes there”. Even a multiple software RAID setup for better ratio performance space won’t be that easy.
Stepping away from system management via NS will cut out a lot of possible system administration path. Which is great for VPS/hosting server, but on bare metal… meh.
I can hear the solution “use virtualization and create multiple nodes”. It will work, but again… my little old obsession: overhead.
thank @dnutan@danb35@michelandre@pike@Andy_Wismer for your tests, feelings, returns you have done or you will do.
This is important because sometimes developers are in their ivory tower and we need to meet the reality of your needs. however system administrator need to meet the reality of developers that is man power. NS8 it is more of 2 years of development and it is not over.
I note several things also for me, firstable that I work alway with machine way faster or powerful than yours because to develop something it is hundred/thousand attempts and I have no time to waste, however I will have to test also on VM less powerful on spinning drive because from time to time, a container could not have finished to start and I start to request on it. This is easy to fix but it must be found by an issue.
Relative to container hypervisor it is true that even if the press shout it is light, multi platform, we will need recent computer/server, each new generation of operating system will push your old hardware to the bin. I recall NS6 only X64, some people with X86 were disappointed but it is life.
Relative to spinning drive we are coming to an end, the moore law is quite over now for CPU, we cannot go faster now but the new area of improvement is the input and output to save/read the data, datacenter are going straight to SSD, I think that my next Raid array will be full SATA ssd…actually it costs still 50% more than spinning drive. We cannot stop speed and progress … ok except if we stop electricity and we go back to stone age but it is another talk.
Relative to system management inside cluster admin, talks are needed, feature request could be done, time must be found to make it but yes the multi linux distro supported could complicate a bit the things but I know that smart developers always could find a solution to transform a developer’s toy like NS8 to a system administrator’s toy.
So do not be much angry or disappointed, I think we need you to make things going in the right direction, this project has alway listened you, me, but yes also the reality of the man power could delay some features.
Yes, that’s expected. As it stands now, you essentially support two distros. That’s naturally more work than one distro, but it isn’t “every Linux distro ever,” and it doesn’t appear that Neth is wanting to go that way. If that continues to be the case, that should at least limit the problem.
Not in the least–particularly when I’m now at a point where I can do those things manually if needed. But I do think it’s a big regression, and something that ought to be rethought.
Why three different distros? Why not agree on one? Even though NS8 is running on my Proxmox under Alma Linux without any major problems, I can well imagine that in the end it will come down to Debian against the background of all the annoyances around the behavior of RHEL.
this was much easier, until RHEL, not sure if its Redhat or IBM decided to do their thing.
so to future proof the solution againstl such kind of situaion, the solution was made into a distro agnostic system, that way, even if rocky tommorrow wakes up and is discontinued, we can still rely or alma linux, or debian etc.
some of these distro also have advantage or disadvantages on each other, similar to how right now NS7 can not deploy some solutions easily because it has very outdated packages than all other os distros
Good…, then also two versions for me. Even though I personally see ALMA Linux as a long-term candidate for failure in light of recent events. Even if SUSE has announced to step in with a million expenditure there. But that’s all still up in the air. Let’s also think about the developers of NS 8, who are doing this more or less on a voluntary basis. Why should they “torture” themselves with three different operating systems, when there is a practicable solution for everyone with Debian, which takes all of our digital future planning into account?
I myself am not a professional IT person and do this more as a hobby. But I don’t feel like rebuilding my servers every two or three years just because of unreliable candidates like RHEL.
1: NethServer is a base for a payed product for Nethesis, which is helping also with revenues with the subscription.
2: Nethservice (tweaked and enhanced SME Server) become Nethserver several years ago, on top of CentOS6; at the time, CentOS was simply a too good to be missed distro, so was during CentOS7. But who would see the IBM acquisition of RedHat so many years ago? Or even Redhat hire prominent CentOS developers. So who has the dare to gaze in the crystal ball the Debian destiny in 5 years? Will be Software in the Public Interest inc still be founded in the future? In few years the change of path of two projects (CentOS and Shorewall) put Nethserver in critical spot and decision time for transitioning to the future… This without considering Debian something less than an interesting and viable development path…
3: Until the latest source-cut decision from IBM/RedHat, CentOS has been considered nothing more than totally stable and reliable distro. Even with the rolling approach of Stream (which lead to more frequent but less traumatic upgrade sessions, compared than 5 to 6 or 6 to 7) was quite well received as results. Still less interesting than the previous arrangement, but worked. Communities however did not enjoy the “joke” thrown to CentOS8, then started leaving the nest. In my personal opinion, this might helped the revenue path required by the stakeholder IBM, reducing the size of the users but also cutting off loud, quarry and unpaying adopters. Some would says that companies want to decide who are they customers, even they don’t admit that.
Being distro-agnostic might serve to several things, including the habit and knowhow to realize layers between the interface and the OS, gaining speed for transition in fewer months between the current underlying OS and the future underlying OS, with the plus of using backup procedures… only for the container orchestrators and all the containers related.
As a goal (my personal opinion) the backup/restore procedure could be the faster way for changing server, virtualizator, OS, even from old metal to ESXi to new metal with PVE and totally different linux distro virtualized. NethServer as application and not as OS will lead to shorter development.
I mean… It’s just like having higher level of programming language: you care of what you need, not to create in assembly all tools you need, then the compiler will adapt your code to the hardware when it will change.
NS8 is a paratigm shift. And a huge challenge.
The tool is not automatically installed.
