Building Cockpit together

edoardo_spadoni · February 12, 2019, 8:12am

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

giacomo · February 12, 2019, 9:48am

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.

pike · February 12, 2019, 11:41am

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

Andy_Wismer · February 13, 2019, 1:25pm

@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

dasois · February 20, 2019, 11:44am

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!

giacomo · February 20, 2019, 1:21pm

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.

edoardo_spadoni · February 20, 2019, 2:00pm

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.

flatspin · February 20, 2019, 3:25pm

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”
But it’s only possible for ns-modules IIUC, not for base- or upstream-updates. Correct ?

No probs so far. Thank you!!

alefattorini · February 20, 2019, 3:39pm

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

dasois · February 20, 2019, 4:52pm

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…

dasois · February 20, 2019, 5:34pm

Ciao Alessio,

thanks for welcoming me, I sent you a PM.

giacomo · February 21, 2019, 1:11pm

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

We are focusing now on 3 main tasks:

firewall configuration (without proxy and IPS parts). @davide_marini is leading the analysis and he carefully reports everything in the wiki: Firewall UI · NethServer/dev Wiki · GitHub
@edoardo_spadoni is focusing on the UI part, while @Amygos and me are working on the API one
@stephdl is blending Cockpit to user needs implementing the delegation part: Cockpit delegation UI · NethServer/dev Wiki · GitHub
next step is the mail module Home · NethServer/dev Wiki · GitHub @davidep is already doing some preliminary work on it

dasois · February 21, 2019, 2:16pm

Thanks for the explanation!
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?

edoardo_spadoni · February 21, 2019, 2:23pm

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

giacomo · February 22, 2019, 10:19am

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

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

dasois · February 22, 2019, 11:43am

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!

davidep · February 22, 2019, 5:28pm

Now there’s an Ejabberd Cockpit application on development: https://github.com/NethServer/nethserver-ejabberd/pull/20#issuecomment-466399364

According to Cockpit guidelines, we must rework our code to remove the “content-security-policy” directive from “manifest.json” files: https://github.com/search?q=org%3ANethServer++“content-security-policy”&type=Code

To make the Ejabberd Cockpit UI work without the blamed CSP “unsafe-inline” directive the JS code was separated from the HTML partials code.

<script> tag contents goes to app.js or other static JS file
style= HTML attributes cannot be used

We could fix the “nethserver-cockpit-empty” kickstart repo accordingly, starting from here for example:

github.com

NethServer/nethserver-cockpit-empty/blob/36b523480dffc423bd7f64589563880da18519d4/ui/views/dashboard.html#L3-L7


<script>
$('[i18n]').each(function () {
    $(this).text(_($(this).attr('i18n')))
});
</script>

What do you think?

giacomo · February 25, 2019, 8:16am

This seems a reasonable limitation to have better security, but does it work with VueJS? I have no idea, maybe @edoardo_spadoni can help us here.

If it works and doesn’t break existing things, go with with CSP enabled.

giacomo · February 26, 2019, 8:07am

You could start with some simple applications which need porting like fail2ban, UPS or nextcloud.

Take a look to GitHub - NethServer/nethserver-mattermost and GitHub - NethServer/nethserver-ejabberd for some inspiration!

Axel · February 27, 2019, 9:56am

Hello
some bad question…

Whats about securety with cockpit?
witch web browser ist save for using cockpit ?
did cockpit uses java ?

thx axel