Just updated to the latest version from nethserver-testing and I see it’s growing and the more it grows the more I like it.
The user experience it much better than with the “old” GUI. It’s a lot more clearly, because the submenus opening sidewards. Colors and boxes have a very modern look for me.
The little hints are very helpfull. GUI-response is quick and flowing.
All in all, I’m deeply impressed how far it got already.
At the moment:
In dashboard I’d like to have a little more info, like diskspace, antivirus, raid status, users and backup.
In software center it’d be very usefull to have also the installed modules.
But I know it’s alpha state, so I think this will come with future updates.
This will push NS to a new level, I think. Keep it rolling!
I’m not inside how the cockpit develops/notice but when I go to the Applications, Software and Terminal menu, I get “oops” message. It must be because it’s still Alpha but that’s what happens to me.
On the dashboard, I think is missing lot of things that were in old GUI.
Backup status
Disk space
RAID
Multiwan
Antivirus database (maybe… I don’t know if it is necessary)
Also interfaces status can be helpful, because I have many problems with NIC on Fujitsu and an “OK” can be helpful in these cases.
All the other pages are very good and structured. Very good also certificates management. I don’t think it’s necessary to show an alert to limit access to IPs: it’s annoying for me… it’s can be good if the admin can hide it. And you can change notification colors (I don’t know if it’s already in this mode): yellow for basic advice and red for errors (also for number of alert).
I’m not asking a dead line, or better, a close one.
Many devices are supporting this version of Internet Protocols by years. CentOS and Shorewall supports too. Even Windows XP, with an addon. Or Vista, by default.
It’s not a matter of understand why it’s asked.
It’s a matter of understand why it’s not important for the project, currently, and which are things that are postponing this lacking feature.
The idea is to move the relevant info inside each module, so the backup status is reported inside the backup page.
The global UI should contain only system-wide data.
In the normal daily use, most users didn’t ever used IPv6.
Adding such feature is a huge huge huge work, and until now it seems it doesn’t worth the effort.
We will for sure study it for NS 8, but I can’t guarantee it will be there.
As to Hardware vs Virtualization: Most of my NethServers do run virtually (10+), only two are native on hardware.
That doesn’t mean I do not configure NUT as a network-client. That’s faster and more accurate than having the virtualization box shut down NethServer (Or Windows or whatever) using it’s native NUT client or whatever.
But I can also “see” the USV Status in the nethServer cockpit…
Sure I can see the USV Status in Zabbix or whatever monitoring I’m using, but if I’m in the NethServer Cockpit and would like to check the USV, it’s there!
Diggin a bit deeper into this I wondered, how this error could happen, if there is a full blown cockpit project, that utilizes integration tests. Their implementation of the uptime display also doesn’t show seconds, but it actualizes itself to the current time, which is nice.
The thought, that comes to my mind now, is, if we’re reinventing the wheel here…
IMHO and from my professional coding experience we definetly shouldn’t reinvent the wheel with a custom API for functions that already exist, especially under a shortage of participating developers and no integration tests on our side.
I discovered that the cockpit team already adressed the use-case of developing custom plugins/modules/pages with the starter-kit. It enables one to use the whole testing infrastructure…
Is there already any progress regarding the communication with the cockpit team?
Please share your thoughts on this and don’t forget: I think it’s absolutely great to integrate cockpit and Nethserver!
I couldn’t agree more: new code, new bugs! We tried to keep as much as possible close to upstream but after some months of study we were almost forced to rewrite many parts.
There are a couple of main reasons:
Cockpit is “too much” for our users. Cockpit target is the experienced system administrator who needs/wants access to all system functions, while our target is the inexperienced system administrator (usually from the Windows world) who doesn’t know much about Linux. This is why we need more simplicity than flexibility guiding the user on doing the right configuration choices.
There is no way to hack existing Cockpit page. Let’s see the hostname change as an example.
Normally when clicking on the hostname, the user can enter the new name which is set using hostnamectl, then the admin must reconfigure all dependent services.
In NethServer, after using hostnamectl we need to execute a bunch of scripts (events and templates) to propagate the configuration to the whole system.
I’d like to integrate the tests, but for now we couldn’t make it work.
I’m pretty sure that all the @dev_team would appreciate it!
We discussed with the team some time ago (you can find some report here in the forum), but we had two different goals.
Since now, our real contribution to upstream was about discussions, some reported issues and the Italian translation.
We made a basic starter-kit project for NethServer: GitHub - NethServer/nethserver-cockpit-empty: NethServer Cockpit Empty module, because our system is little different to the “ideal” cockpit system. Our starter kit is an all-in-one solution that provides a simple module with rpm, API and UI parts with events, templates etc…
The cockpit startet kit is very cool, we can inspire ourselves in particularly for the test part which is currently absent.
Posibility to select each update seperately works and fullfills partly a long time wish of some users called “cherrypicking of updates”
But it’s only possible for ns-modules IIUC, not for base- or upstream-updates. Correct ?
Ciao Giacomo, thanks for your thorough explanation!
I just took a look at how exactly cockpit solves the uptime display on their side. It appears to me as if they would directly access dbus('org.freedesktop.timedate1'); in the client js and do every processing of this locally and in a pretty non-extensible way. I appreciate their work, but I think we can make things a little better architecture-wise. I suppose thats what the PHP API was invented for… These problems could have also be solved on the client, but it doesn’t really matter (maybe only for the “which developer knows what languages” discussion)…
In my opinion tests should be on the top of the list (where is the list btw? )! Maybe i can help out with that, but let’s move that to a sperate thread…
