Il 16/02/2016 18:43, Jim McLaren ha scritto:
One quick question. Would it be any harder for someone such as
yourself to write a panel with mojo as a framework, rather than
cockpit? IOW once a new server-manager has been written with
Mojolicious is it as easy to use thereafter?
I'll try to explain my point of view about cockpit as better as I can..
in any case, if something is not clear, feel free to ask.
First of all, some premises:
1) I don't want cockpit as the new S-M at any cost.. just trying it and
proposing it
2) SME's perl stack is not under any kind of discussion.
that said.. why cockpit..
1) it is a modern framework, already available on C7, mobile friendly
2) it has some features we don't need to deal with: authentication, for
example, or a dashboard to check the server status in real-time or,
again, a storage panel with advanced features (raid arrays creation to
mention the first that comes to my mind)
3) it natively supports docker
4) it is localization friendly/ready
5) it can be expanded with some custom modules
6) it is actively developed and maintained
7) it is (in)directly supported by RH
why not?
well.. the first and only cons I would say is that it works only on C7,
but IMO it's not a real problem.
a slightly annoying bug (already raised on the cockpit issue trasker) is
that a user with /sbin/nologin shell can still login, but can only watch
and can't touch anything (cockpit raises an error)
somebody with more technical skills can obviously add other "no-go"
reasons to the list :-)
I never saw cockpit before last Fosdem, 15 days ago.. tried it on a C7
VM, customized the login screen with colors/Koozali SME logo and info in
less than 15 mins.. amazing.
I created a kind of "SMEstain" server, pushing on a bare minimal C7 base
and lib rpm coming from Nethserver (can't use the e-smith-base and
e-smith-lib ones), already available for C7.. in my mind, all we need to
create custom plugins for Cockpit are just our dbs, the db command and
the events.. in few words, the e-smith stack.
NOTE: moving to C7 will not be easy and we have to deal with many issues
(systemd anyone), but from a "simple" web UI point of view, what I'm
using it's enough
why did I use NS rpms? well, apart of their C7 verion, NS' db command
has 2 methods very handy in my case.. the print/show options have a json
output version too, and json data is easy to read/parse
I managed in create a small plugin that reads/sets data from the
configuration db in minutes, using one of the API cockpit provides..
cockpit.spawn
it simply calls "db configuration showjson mykey", parse the output and
show the values in a simple form (IP address and Netmask).. user can
edit the values (a little validation is available, directly in the
client) and then save them using the "db configuration setprop mykey
prop1 value1 prop2 value2..."
so far, so good.. one of the features of cockpit is that the user logged
in can do exactly what he could do loggin into the shell.. IOW, some
functions are disabled/not available if you are not root
(this can be changed with sudoers etc )
I used the same approach to create two other panels: one for users, the
other for ibays.. the funny thing, as a non perl coder, is that just
knowing very little about SME's internals (the db command syntax), I was
able to create some panels.. the first prototype was made in less than 2
hours (I spent some time to find a grid jquery widget)
as Dani noticed on devinfo ML, the cockpit.spawn can be used to call any
kind of command, so it could be a big security hole..
he's right.. security comes before everything..
so I changed approach..
first of all I created a simple and rough webservice with perl-Dancer..
it runs bound to 127.0.0.1:3000 (i.e. it is not reachable from outside)
and, ATM (it's just a POC, isn't it?), can serve a very small number of
requests..
it just answer to four GET commands:
/accounts (gives the whole content of accounts db)
/accounts/key (gives the key output.. the same of db accounts show key)
/configuration (same as /accounts but with configuration db)
/configuration/key (same as above)
all output is in json format
I then modified my panel (the users one) to use cockpit.http api (2
lines editing) and now it works in a more secure way
answering to you, Jim: with cockpit it's a matter of hours if you are
used to jquery, angular and things like that
with mojo will be the same, but before you can do it, you need a
framework (as Dani said, we first need our framework to build our S-M on
top of it)
what I tried to explain in devinfo is that if we "convert" all our logic
(well, a part of it) in perl into a webservice (and this is where perl
moks are still needed), almost anyone can create his own S-M
why cockpit? well.. it is already available, it's a fact
the real SME's plus is that the paradigm db/actions/events/template is
quite simple.. once you know what you need to do, you're done.. we
"just" (ok, I know, it's not easy and I'm not saying that it will be
easy)need to have a webservice that can "replicate" what you usually do
in the CLI..
you can see the code attached to bug #9208.. the panels are simple html
files and js.
HTH, in any case I'm here
ciao
S.
_______________________________________________
Discussion about project organisation and overall direction
To unsubscribe, e-mail discussion-unsubscr...@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/discussion/
