Building Cockpit together

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.

High

I like tehe Idea behind cockpit. It is modern an looks like more flexibel. But work step by step with the most importaned functions.

AD/LDAP
Mailserver and Sogo
Freepbx
Nextcloud
CA Certs
cryted file

I dont wont to be a bad guy
But why you are looking so deap in 2 the hardware?
RAID, UPS, …

There are a lot of good an running VM plattforms
Like Xenserver or XCP-NG
Proxmox…
or DockerContainers…

Same with Firewall (Untangel … )

Both are important and need a lot of work …

THX Axel

PS I love Nethserver and XCP-NG very good projects and comunitys …

the link for Guidelines and Scaffold are broken

2 Likes

@edoardo_spadoni do you know why?

Thanks for your suggestions.

People are still using HW to install NethServer, so we can’t avoid that.

I don’t know if it’s a cockpit matter

That part of the documentation was old, now the links work. :+1:

1 Like

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.

You already can do it from the “Settings” page.

Colors and design are from upstream project: https://www.patternfly.org/

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.

1 Like

I think i’ll get along with that. Like mirrors do.

@pike
@giacomo

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!

my 2 cents
Andy Wismer

1 Like

I just stepped into nethserver-cockpit and tried some things out. At first sight, it absolutely looks awesome!

I already discovered an issue with the uptime display, that I fixed.

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! :grinning:

3 Likes

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.

1 Like

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.

3 Likes

Tested update feature in ns-cockpit.

changelog feature is great:

Posibility to select each update seperately works and fullfills partly a long time wish of some users called “cherrypicking of updates” :+1:
But it’s only possible for ns-modules IIUC, not for base- or upstream-updates. Correct ? :thinking:

No probs so far. Thank you!!

Ehi Davide welcome here, I appreciate your contribution.
Your suggestions and knowledge are welcome. How would you like to help the project?

1 Like

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? :wink:)! Maybe i can help out with that, but let’s move that to a sperate thread…

Ciao Alessio,

thanks for welcoming me, I sent you a PM.

1 Like

My bad: we do not have a document describing the road map. You can find some info in the forum, we also talked a bit together at FOSDE, and finally some marginal notes ares on my private workstation :smiley:

We are focusing now on 3 main tasks:

2 Likes

Thanks for the explanation! :grinning:
Would it be a good idea to move this information to the Project feature of GitHub?
I also noticed that the issue-tab is disabled in the cockpit repository, is that intentional?

The issue tab is disabled because all issues are centralized here: GitHub - NethServer/dev: NethServer issue tracker

1 Like

Once we used the project board inside the cockpit repo to track the first alpha.
The problem is keeping it up to date, honestly I don’t have the time to do it :frowning:

Still, there is a NS board here: https://github.com/orgs/NethServer/projects/1

Okay, I understand that these things need fostering…
However this makes it difficult for new guys like my to find their way into the codebase and get an overview. Also a issue-list of not-too-hard bugs or easy features would be very helpful in order to find my way into the code. This is where a project board combined with a separate issue list would be very helpful!

3 Likes