[devinfo] some ideas from Fosdem..

[Stefano Zamboni]

Hi all

a few guys from Koozali are here, in Bruxelles, attending at Fosdem..
many, many, tooo many interesting things to see/listen to/discuss..

anyway..
few days ago I started playing with C7 and SME..
today, following a link, I installed cockpit
(http://cockpit-project.org/) on a minimal C7 setup.. 3 minutes and I'm
done..

well... let me say.. amazing, simply amazing..

now.. we have to think about the future, haven't we?

some points:
- as for Charlie's mail here, perl in C7 doesn't support suid
- we have to completely rewrite and redesign server-manager
- we must try to involve as much devs as possible just to keep us alive
- we have to move towards uptodate needs: SSO, AD integration..
- we'd really try to stay upstream compliant as much as we can..

so.. whould it be possible to start thinking about the future from:
- C7 base
- cockpit management UI
- Samba 4 (integrated with openldap)
?

the main advantages:
- cockpit is something actively developed from upstream and it will be
included in all future releases of upstream distro
- it's documented
- its UI is rational, user friendly
- it includes many features now available only via CLI or console (raid
devices creation too)
- samba 4 will permit to fully integrate SME with windows and osx clients
- cockpit supports natively docker containers

ok.. this is just a thinking loud email

if you are just curious to test it:
- install a minimal c7
- yum --enablerepo=extras install cockpit
- systemctl start cockpit
- in the client machine, go to server_address:9090

you're done

ciao
S.

we'd just focus ourselves on make UI interface looks like we prefer
--
Stefano Zamboni
email: ***@mind-at-work.it
PEC: ***@c-posta.it
mobile: [phone]

_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at http://lists.contribs.org/mailman/public/devinfo/

[Terry Fage]

Honestly guys I am absolutely a babe in the woods on this stuff anmd that is
probably an exageration, doesn't mean I don't suppoort whatever you want to
offer up as a try and see..

I am well up for that...

Can but sit on the sidelines, cheer and clap :-) and try and follow what you
are doing..

If I can do anything to help, ask or better still just say do this and report..

Terry - who wishes he spent more time learninbg instead of surfing, waves that
is not the internet :-)

Post by Stefano Zamboni
- as for Charlie's mail here, perl in C7 doesn't support suid

This is true.

Post by Stefano Zamboni
- we have to completely rewrite and redesign server-manager

This is not true.
We have a problem to solve.
*One* way to solve the problem is to use a setuid program written in C as
an intermediate between apache and the perl server-manager scripts. We
could use links to that script in place of the symlinks we currently use
(symlinks in /etc/e-smith/web/panels/manager/cgi-bin, scripts in
/etc/e-smith/web/functions). See below for example code.
None if this is to say that we shouldn't consider a UI change. But don't
start with a false premise.
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main (int argc, char *argv[])
{
const char str1[] = "/etc/e-smith/web/functions/";
char * p;
p = strrchr(argv[0], '/');
if (p)
{
p++;
}
else
{
p = argv[0];
}
char *res;
res = malloc(strlen(str1) + strlen(p) + 1);
strcpy(res, str1);
strcat(res, p);
argv[0] = res;
setuid(0);
execvp(argv[0], &argv[0]);
return 42;
}
_______________________________________________
Server Development Discussion
Searchable archive at http://lists.contribs.org/mailman/public/devinfo/

_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at http://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

Post by Stefano Zamboni
- as for Charlie's mail here, perl in C7 doesn't support suid

This is true.

glad to know :-)

Post by Stefano Zamboni
- we have to completely rewrite and redesign server-manager

This is not true.
We have a problem to solve.

yes, we have many problems to solve.. the perl suid is just one of them..
and I'm quite sure that moving our server-manager to C7 will make us
find many others..

but.. but now we need to change server-manager.. not just a cosmetic
change, but a radical different new one..
for example, we need something that can be easily enhanced with external
contribs, without the need to create new pages just to add 1 field

I suppose that moving/redoing it with mojo will need a complete redesign
and re-thinking.. am I wrong?
the question is.. can we give cockpit a try? it already does/have many
things we now just don't have and need..
if we just move our packages to a new OS base, just to make things work
will need way too much time and resources we don't have.

Charlie, since I think you are one of the few guys here that can not
just say no but also explain in a more detailed way why we can't use
cockpit and why, on the other hand, cockpit could be a good starting point.
Obviously, I home many others will add something to this discussion, not
just you.

saying just "no" without any reason won't make us go anywhere, just
stand still.

thank you in advance fro your time and attention.

Ciao
Stefano
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at http://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

Post by Stefano Zamboni
but a radical different new one..

No there is nothing radically different in using our own simple setuid
wrapper program in place of the one currently provided by the
perl-suidperl rpm.

but doing so we are just porting our server-manager to C7.. and this is
not what we want..

Post by Stefano Zamboni
for example, we need something that can be easily enhanced with external
contribs, without the need to create new pages just to add 1 field

Perhaps this is so. But this is a problem which is completely independent
of the change to using RHEL7 as base.

yes.. this is indipendent form moving to a new OS..
C7 is very different from C6.. moving to it will imply a big work
about your "perhaps this is so": it is, not perhaps.. we need a new
server-manager we need something pluggable.. we can't expect that to
add/edit some properties to an entity (say the password strength or
their expiration) we have a different panel, with a different menu item..

Post by Stefano Zamboni
I suppose that moving/redoing it with mojo will need a complete redesign and
re-thinking.. am I wrong?

I believe so. Mojo would allow a complete redesign and rethinking if we
wish to do that.

we need to do that.. people is starting using other distro because our
server-manager is old, not user friendly..
and we have a bunch of properties that are available just via CLI..
people are migrating.. do we want it?

But it doesn't require that. Mojo could also be used to
write server-manager panels which replace existing panels, or add new
panels to the existing server-manager.

so, in your opinion, we'd just migrate our server-manager to C7 and then
starting converting it?
so, IIUC, release a SME10 with an old interface? sure? if you're meaning
so, it's a suicide, IMO

Post by Stefano Zamboni
the question is.. can we give cockpit a try?

Of course you can give cockpit a try. But don't do it under the false
premise that it is necessary because of issues with perl under c7.

no, it's not necessary because of perl issues, it's necessary because we
must move forward.. and I don't mind if we'll use cockpit or mojo or
$whatever, the only secure thing is that if we don't change radically
our server-manager, we'll have no appeal at all, and nowadays people
chooses a linux distro (even if server oriented, not desktop) with
eyes.. actual server-manager simply sucks

Post by Stefano Zamboni
if we just move our packages to a new OS base, just to make things work
will need way too much time and resources we don't have.

I suspect that isn't true.

well, have we time and resource? who is gonna do it?

Post by Stefano Zamboni
Charlie, since I think you are one of the few guys here that can not just say
no but also explain in a more detailed way why we can't use cockpit and why,
on the other hand, cockpit could be a good starting point.

I don't know enough about cockpit to give you an opinion on it.

ok, point taken.. now, would you mind to try it? and to give an eye to
its documentation?

Post by Stefano Zamboni
Obviously, I home many others will add something to this discussion, not just
you.
saying just "no" without any reason won't make us go anywhere, just stand
still.

I didn't say "no". I just advised you not to jump to false conclusions
about our existing code.

our existing code, regarding to all the logic (events, templates,
gragments, db, actions and so on) is not under any kind of discussion
we just need to get rid of our interface.. it's a matter of surviving

anyway, since this ML accepts attachments from now (thank you Dani), I
finally can attach a file :-)

S.

[Daniel Berteaud]

Post by Stefano Zamboni

Post by Stefano Zamboni
but a radical different new one..

No there is nothing radically different in using our own simple setuid
wrapper program in place of the one currently provided by the
perl-suidperl rpm.

but doing so we are just porting our server-manager to C7.. and this
is not what we want..

Server-manager rewrite and porting to C7 are completly different issues.
We can start rewriting the S-M on SME9, and start porting SME to C7 at
the same time. There's just no need to link both projects.

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Stefano Zamboni]

Post by Daniel Berteaud
Server-manager rewrite and porting to C7 are completly different
issues. We can start rewriting the S-M on SME9, and start porting SME
to C7 at the same time. There's just no need to link both projects. ++

is rewriting our S-M on SME9 worth it? this will imply that many of the
new features available on the new OS won't be available

another related (for me, at least) question.. I'd like to move our logic
(db, events.. the e-smith layer) to C7 without S-M?

I'd like to test a POC I have in mind

S.

P.S: it quite sad seeing that, ATM, we're just 3 guys here.. we'd really
ask purselves if all of it is real worth it..
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Daniel Berteaud]

Post by Stefano Zamboni

Post by Daniel Berteaud
Server-manager rewrite and porting to C7 are completly different
issues. We can start rewriting the S-M on SME9, and start porting SME
to C7 at the same time. There's just no need to link both projects. ++

is rewriting our S-M on SME9 worth it? this will imply that many of
the new features available on the new OS won't be available

I think it does worth it. SME9 is far from being EOL.

Post by Stefano Zamboni
another related (for me, at least) question.. I'd like to move our
logic (db, events.. the e-smith layer) to C7 without S-M?

IMHO, this is the first (and for now, the only) thing to do. If we want
SME ported on C7, first make the engines work. Then check for the interface.

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[brian read]

Post by Stefano Zamboni

Post by Daniel Berteaud
Server-manager rewrite and porting to C7 are completly different
issues. We can start rewriting the S-M on SME9, and start porting SME
to C7 at the same time. There's just no need to link both projects. ++

is rewriting our S-M on SME9 worth it? this will imply that many of
the new features available on the new OS won't be available
another related (for me, at least) question.. I'd like to move our
logic (db, events.. the e-smith layer) to C7 without S-M?
I'd like to test a POC I have in mind
S.
P.S: it quite sad seeing that, ATM, we're just 3 guys here.. we'd
really ask purselves if all of it is real worth it..

I'm following this with interest, but have nothing to add at the moment,
although I'd def be up for some development work in line with my abilities.

Post by Stefano Zamboni
_______________________________________________
Server Development Discussion
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[RV Lardin]

Hi to all,

As Stephano strongly asked us to quit our lurker's positions...
;)

Post by Stefano Zamboni
our existing code, regarding to all the logic (events, templates,
fragments, db, actions and so on) is not under any kind of discussion

Ok, that's the point on which we can start, since everyone here agrees.
;)

Post by Stefano Zamboni
we just need to get rid of our interface.. it's a matter of surviving

Difficult to follow you just on "cosmetics" matters. SME solved, in the
past, large evolutions of the underlaying OS (and a full change of this
OS, too) like systemd, netfilter, ... And it *did* adapts its code.
That's the definition of "surviving" ?

If the three of you, talking here, agree that it is time to reconsider
the GUI of our distro (The "Server-Manager", aka S-M), this must be
relevant.

For me, before choosing a tool, we have to describe the mechanism
between the "trigger" (an action in the S-M) and the "logic of our
existing code".

My main concern would not be "cosmetic" but "logical". For example,
user-management seems very complex, because of the number of entry
concerned :
- login /pass
- mail aliases
- group belonging / group aliases
- groups belonging / shares available (R/W)
- remote access (ssh / ftp)
- vpn (certificates)
- ...

It seems very difficult for a beginner to have a complete perception of
all those domains. A multi-entry interface seems to be needed, for a
global vision. Or a survey to follow ? Or something much more graphic,
as a "Mind Mapping" ?

May be we can start by a short redefinition of the goal of the S-M.

Is it a quick and instant access for beginners, advanced users
preferring to use the command line instead ?

Or, at the opposite, should we avoid anything that has to be done by
command-line, centralizing all actions in the S-M ?
This will be my first opinion, but we often forget to build a S-M entry
for small actions (direct use of db for mail Black-Listing, for example).

Shall we think about a multi-level access (simple / expert) ?

Is there an implicit combination of actions (in the S-M) and the way
SME-Server code reacts ? I mean : is it realistic to arrange the way of
performing an action in S-M to reflect the inner logic inside the box ?

It could be a good way to combine first vision of new users discovering
our distro and a largest pedagogic approach (for dev candidates) ?

Enough for today, sorry for being long but ... Stephano's fault !
:D

Wishing the best for all of you,
RV.
--
FIREWALL-SERVICES SAS, La sécurité des réseaux.
Société de Services en Logiciels Libres
membre du groupement ProLibre.net
48, ch Pargade
33850 LEOGNAN
Tel/Fax : [phone]
Mail: ***@Firewall-Services.com
Web : http://www.firewall-services.com
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[stephane de Labrusse]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by RV Lardin
My main concern would not be "cosmetic" but "logical". For
example, user-management seems very complex, because of the number
of entry concerned : - login /pass - mail aliases - group belonging
/ group aliases - groups belonging / shares available (R/W) -
remote access (ssh / ftp) - vpn (certificates) - ...

The difficulty comes that all these settings must be find across
several other panels and (optional by definition) contribs. You can
find a lot of (near identical) Menu, simply because we (as
contributor) cannot integrate our code in the official Panel, except
after a long discussion.

For Example I mean about the Ibay Panel and the contrib I developed
smeserver-NFS, mostly the code is duplicated. I can take also example
about smeserver-webhosting whose I simply add a panel for apache
settings only available by db commands. smeserver-remoteaccess is also
another good candidate, it should be integrated in the user
panel....etc...etc

Post by RV Lardin
It seems very difficult for a beginner to have a complete
perception of all those domains. A multi-entry interface seems to
be needed, for a global vision. Or a survey to follow ? Or
something much more graphic, as a "Mind Mapping" ?

In fact the approach of one menu, with pages that we can (hardly)
create by formagick, is a realy old way to do. We must add the tab
system as a tree to sort the setting pages.

- From my point of view a plugin system can be created, all pages of
code found in a specific folder must create some Tab page with your
settings. This means One menu in the panel and several Tabs of
settings. Of course we must let opened the panels (and think how we
can do it) to let the contributors add directly their code in the
official panel.

One example, I did smeserver-transmission and I want to make a panel
to allow users to use it, I must recreate now all the users panel, but
in fact I could just add a new tab in the user panel for managing
transmission. This is much more efficient.

Another thing really interesting for a contributor, will be to code
some routine for creating a table panel, sorting the key properties
from a type(like if you want to do the Ibay panel, the user/group
panel). Actually doing this need to have a good understanding of perl.

Post by RV Lardin
May be we can start by a short redefinition of the goal of the
S-M.
Is it a quick and instant access for beginners, advanced users
preferring to use the command line instead ?
Or, at the opposite, should we avoid anything that has to be done
by command-line, centralizing all actions in the S-M ? This will be
my first opinion, but we often forget to build a S-M entry for
small actions (direct use of db for mail Black-Listing, for
example).
Shall we think about a multi-level access (simple / expert) ?

Actually when you look after our competitors they give to the end-user
the control of the server, sure that now the less qualified can manage
a Linux server. Quite all settings are exposed to the system
administrator.

I'm sure it is the way to go, if we don't do that, they simply will go
elsewhere.

It can be imagined some expandable advanced fields with settings
inside...of course actually, from what I know, formagick doesn't allow i
t.

Post by RV Lardin
Is there an implicit combination of actions (in the S-M) and the
way SME-Server code reacts ? I mean : is it realistic to arrange
the way of performing an action in S-M to reflect the inner logic
inside the box ?
It could be a good way to combine first vision of new users
discovering our distro and a largest pedagogic approach (for dev
candidates) ?

Don't make me wrong, all I'm talking, don't come from my imagination,
others have already implemented it. I have already coded some
features/modules, take a look to my github, you will find a lot of
interesting things.

- --

Cordialement

Stéphane de Labrusse
Membre de l'Aru2L http://www.aru2L.org
Membre de l'ApriL http://www.apriL.org


PORTABLE : 06 29 19 12 99
DOMICILE : 05 65 78 90 72
WEB : http://geekeries.de-labrusse.fr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlavw/MACgkQ1CTfJUQAIe7/kACdEcWhzu3BtO/hst95RMVQNH7C
yQ0An22KVyCgwUjZf5xDLR3OtA/Febnn
=7zAR
-----END PGP SIGNATURE-----
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

Post by stephane de Labrusse
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by RV Lardin
My main concern would not be "cosmetic" but "logical". For
example, user-management seems very complex, because of the number
of entry concerned : - login /pass - mail aliases - group belonging
/ group aliases - groups belonging / shares available (R/W) -
remote access (ssh / ftp) - vpn (certificates) - ...

The difficulty comes that all these settings must be find across
several other panels and (optional by definition) contribs. You can
find a lot of (near identical) Menu, simply because we (as
contributor) cannot integrate our code in the official Panel, except
after a long discussion.

[cut]

I think that Steph gave the best answer

chapeau et merci, Stephane

S.
--
Stefano Zamboni
email: ***@mind-at-work.it
PEC: ***@c-posta.it
mobile: [phone]

_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Daniel Berteaud]

Post by Stefano Zamboni
I suppose that moving/redoing it with mojo will need a complete redesign
and re-thinking.. am I wrong?
the question is.. can we give cockpit a try? it already does/have many
things we now just don't have and need..
if we just move our packages to a new OS base, just to make things work
will need way too much time and resources we don't have.

Cockpit directly use a lot of systemd API (over DBUS). I don't think it'll be easy (or even feasible) to adapt it to work with our DB/templates engine.

++
--
Daniel Berteaud
FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Technopôle Montesquieu
33650 MARTILLAC
Tel : [phone]
Fax : [phone]
Visio: https://vroom.im/dani
Web : http://www.firewall-services.com


_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at http://lists

[Hsing-Foo Wang]

Post by Daniel Berteaud
Cockpit directly use a lot of systemd API (over DBUS). I don't think it'll be easy (or even feasible) to adapt it to work with our DB/templates engine.

Well, our DB/Template system is key….
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at http://lists.contribs.org/mailman/pu

[Stefano Zamboni]

Post by Hsing-Foo Wang

Post by Daniel Berteaud
Cockpit directly use a lot of systemd API (over DBUS). I don't think it'll be easy (or even feasible) to adapt it to work with our DB/templates engine.

Well, our DB/Template system is key….

sure, but can we just try and invest some time to check?
S.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at http://lists.contribs.org/mailman/public/de

[Stefano Zamboni]

Post by Daniel Berteaud
Cockpit directly use a lot of systemd API (over DBUS). I don't think it'll be easy (or even feasible) to adapt it to work with our DB/templates engine.
++

ok, this is at least an answer with a reason :-)

please, take a look here
http://stef.thewalter.net/making-rest-calls-from-javascript-in-cockpit.html

this is how NS interface works, but it is in PHP

moreover, please note that (IIUC) every original module can be
overridden putting a module with the same name into the user home dir
and, as you can see in the linked page and in another one you'll find on
the same site, we can create custom modules.

formagick is dead, so we would not spend a minute to port server-manager
to C7, wouldn't we?

we have 2 choices:
- create something on our own, likely leading SME to the death (no time,
no resources, no one is maybe interested in developing something that is
used just by us)
- change totally the approach and use something which is actively
developed and supported, and that may become a standard in the near
future.. it won't be easy, but maybe we'll find someone else interested
in developing.. just think about how many SME users just use it as a web
server for the webapps they develop.. maybe people with skills in js,
jquery and all this kind of stuff

today morning, jocking at the hotel bar with John and Steph, I created
in 15 min this:


cool, indeed.. I bet that just posting this picture in the forums asking
for people skilled with js, REST, jquery and so on somebody will come out..

seriously.. are we gonna start a debating on the necessity to change
server-manager?
and.. instead of spending some hours just to compile needed rpms or to
make our things work on C7, why can't we just start trying to make our
code/approach with a new tool?
moreover: we MUST use something that can abtract developers.. something
that use techologies widely adopted, not a nicle one.

finally, please.. if you (generally speaking) have some documented and
argumented reasons, please tell, explain, just demonstrate why NO is the
answer.. but I kindly ask everyone not to answer "no, it won't work".

thank you all

Ciao
S.

[Stefano Zamboni]

Post by Stefano Zamboni
today morning, jocking at the hotel bar with John and Steph, I created

well no embedded image..

I attach it now

[Stefano Zamboni]

formagick is dead, so we would not spend a minute to port server-manager to
C7, wouldn't we?

Formmagick works without change in C7. As I have noted previously, we need
to find and/or build many perl modules to match the different perl
version, and we need to do something a little bit differently to get root
permission.

doing so, we're just wasting time

formagick is the showstopper for developers, meaning that it's obsolete
nowadays or, at least, in the way we are using it
if we want people to get involved in developing, we have (I'd say must)
get rid of it

- create something on our own, likely leading SME to the death (no time, no
resources, no one is maybe interested in developing something that is used
just by us)
- change totally the approach and use something which is actively developed
and supported, and that may become a standard in the near future..

option 3, make incremental improvements to what we already have, solving
particular problems as we identify them.
Gradually replacing FormMagick with something more usable would be part of
the incremental change. But it doesn't need to be replaced everywhere in
one go.

Charlie.. if we just release a new SME on C7 with the old web interface,
we're dead
can you just spend a little time checking and comparing how the web
interfaces of NS, Zentyal, Clearos look like?
do you really thing that our product will be a competitor to them just
looking at the web interface?

S.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Daniel Berteaud]

Post by Stefano Zamboni
Charlie.. if we just release a new SME on C7 with the old web
interface, we're dead
can you just spend a little time checking and comparing how the web
interfaces of NS, Zentyal, Clearos look like?
do you really thing that our product will be a competitor to them just
looking at the web interface?

There's nothing to argue about this: yes the current S-M looks old, is
not dev friendly and have tons of problems. It needs to be redesigned, but:

- We just have not enough resources. Charlie has posted a panel example
using Mojo on BZ. I'd like to take a look at it
- It's not related to C7, so either we write it before SME10, and we'll
have the new S-M on SME10, or we write it after, so we have to think
about porting the actual S-M on C7

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Hsing-Foo Wang]

Post by Daniel Berteaud
- We just have not enough resources. Charlie has posted a panel example
using Mojo on BZ. I'd like to take a look at it
- It's not related to C7, so either we write it before SME10, and we'll
have the new S-M on SME10, or we write it after, so we have to think
about porting the actual S-M on C7

Why are we focussed on Mojolisious? There must be tons of frameworks out there that are much easier for (newbie) dev. THAT would help us.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Daniel Berteaud]

Post by Hsing-Foo Wang

Post by Daniel Berteaud
- We just have not enough resources. Charlie has posted a panel example
using Mojo on BZ. I'd like to take a look at it
- It's not related to C7, so either we write it before SME10, and we'll
have the new S-M on SME10, or we write it after, so we have to think
about porting the actual S-M on C7

Why are we focussed on Mojolisious? There must be tons of frameworks out there that are much easier for (newbie) dev. THAT would help us.

Do you have any proposal ? Charlie has suggested Mojo years ago, and,
for having worked with it on some projects, I also think it's great.

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Stefano Zamboni]

Post by Daniel Berteaud
Do you have any proposal ? Charlie has suggested Mojo years ago, and,
for having worked with it on some projects, I also think it's great. ++

that's a good thing.. Just a simple question: how big is mojo's dev
community? why is it not (apparently) so popular as other frameworks?

and a direct question to Charlie: do you know any mojo skilled dev that
may be interested in developing on SME?

we have our engine.. it must be modified to expose some API that might
be used from any kind of framework.. once the APIs are done, we don't
need a SME guru to create a web interface.. and if we choose a widely
used framework and language, we likely can attract more people

S.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Daniel Berteaud]

Post by Stefano Zamboni

Post by Daniel Berteaud
Do you have any proposal ? Charlie has suggested Mojo years ago, and,
for having worked with it on some projects, I also think it's great. ++

that's a good thing.. Just a simple question: how big is mojo's dev
community? why is it not (apparently) so popular as other frameworks?

I don't have any number, but big enough to be sustainable IMHO. At
least, unlike FormMagick, it's actively developped, has good
documentation, tons of plugins etc..

Post by Stefano Zamboni
we have our engine.. it must be modified to expose some API that might
be used from any kind of framework..

The perl API for SME database can be used already with Mojo (or any
other perl based framework). They might need some improvments, but this
is yet another topic :-)

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Stefano Zamboni]

And any programmer can learn perl.

True, sadly true
We need people to keep SME alive
Do you really think that we (this project) have the appeal to make someone start programming in perl for free?

We have some people which knows very well how SME works and are good perl monks

We need a framework that (like cockpit, but there are others) is just html, js, css
it's easier to find people that are able to work with that tools and a big knowledge of SME internals is not required
Ideally, we could tell a young guy "we need a page that calls this api with those parameters.. input must be validated following these rules"
And having the page done.

All css driven, no tables.. something that looks like 2016 not only outside (the look), but inside (the code)

[Daniel Berteaud]

Post by Stefano Zamboni
True, sadly true
We need people to keep SME alive
Do you really think that we (this project) have the appeal to make someone start programming in perl for free?

We need to choose a language. Are you suggesting we'd better go with PHP
? I don't think so (and I know at least Charlie doesn't think so either :-D)

Post by Stefano Zamboni
We have some people which knows very well how SME works and are good perl monks
We need a framework that (like cockpit, but there are others) is just html, js, css

No framework can be only HTML, JS, CSS: those are just for the frontend.
We'll always need skills in this area, no matter what the backend will
use. Even with Mojo, the logic is perl, but the templates are mostly
pure HTML/JS/CSS (there can be some perl variables in there, but very,
very minimal. Take a look at Bug 9203)

Post by Stefano Zamboni
it's easier to find people that are able to work with that tools and a big knowledge of SME internals is not required
Ideally, we could tell a young guy "we need a page that calls this api with those parameters.. input must be validated following these rules"
And having the page done.
All css driven, no tables.. something that looks like 2016 not only outside (the look), but inside (the code)

I think we should do this:

- Rewrite all the panels, one by one, using a more flexible backend
framework (Mojo, as I don't see any alternative suggested)
- Each time a panel is rewritten, provide two set of templates: one for
the old look (so we can keep some visual coherency while the rewrite
happens), and a new, more modern one (I'd choose bootstrap as it's the
only frontend framework I ever used)

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Stefano Zamboni]

Post by Daniel Berteaud

Post by Stefano Zamboni
True, sadly true
We need people to keep SME alive
Do you really think that we (this project) have the appeal to make someone start programming in perl for free?

We need to choose a language. Are you suggesting we'd better go with PHP
? I don't think so (and I know at least Charlie doesn't think so either :-D)

no.. the backend must stay in perl, just improved..

please read here:
http://cockpit-project.org/guide/latest/cockpit-spawn.html

and this code snippet taken from an example plugin for cockpit

<script>
var address = $("#address");
var output = $("#output");
var result = $("#result");

$("#ping").on("click", ping_run);

function ping_run() {
var proc = cockpit.spawn(["ping", "-c", "4", address.val()]);
proc.done(ping_success);
proc.stream(ping_output);
proc.fail(ping_fail);

result.empty();
output.empty();
}

function ping_success() {
result.css("color", "green");
result.text("success");
}

function ping_fail() {
status.css("color", "red");
status.text("fail");
}

function ping_output(data) {
output.append(document.createTextNode(data));
}
</script>

taken from here:
http://stef.thewalter.net/creating-plugins-for-the-cockpit-user-interface.html

cockpit can also interact via Json/REST:

see :
http://stef.thewalter.net/making-rest-calls-from-javascript-in-cockpit.html
and
http://cockpit-project.org/guide/latest/cockpit-http.html

that said, and adding that I'm not a programmer/developer, IIUC callling
our events can be made from cockpit without even knowing nothing but the
name of events and the parameters
and, if you just take a look at the code I pasted above, you use only js..

I'd love to create a POC.. I just need the minimun installed on C7 (I
think that e-smith-base and e-smith-lib are enough).
I made some tests, arriving to have db command working and template
expanding too, but I have to use full paths to the commands/files

we could have people working on the core libs to add/edit what is needed
and people that only need API documentation that work on the frontend.

is it feasible? is there anyone interested just to give it a try?

S.

Post by Daniel Berteaud

Post by Stefano Zamboni
We have some people which knows very well how SME works and are good perl monks
We need a framework that (like cockpit, but there are others) is just html, js, css

No framework can be only HTML, JS, CSS: those are just for the frontend.
We'll always need skills in this area, no matter what the backend will
use. Even with Mojo, the logic is perl, but the templates are mostly
pure HTML/JS/CSS (there can be some perl variables in there, but very,
very minimal. Take a look at Bug 9203)

Post by Stefano Zamboni
it's easier to find people that are able to work with that tools and a big knowledge of SME internals is not required
Ideally, we could tell a young guy "we need a page that calls this api with those parameters.. input must be validated following these rules"
And having the page done.
All css driven, no tables.. something that looks like 2016 not only outside (the look), but inside (the code)

- Rewrite all the panels, one by one, using a more flexible backend
framework (Mojo, as I don't see any alternative suggested)
- Each time a panel is rewritten, provide two set of templates: one for
the old look (so we can keep some visual coherency while the rewrite
happens), and a new, more modern one (I'd choose bootstrap as it's the
only frontend framework I ever used)
++
_______________________________________________
Server Development Discussion
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Daniel Berteaud]

Post by Stefano Zamboni
http://cockpit-project.org/guide/latest/cockpit-spawn.html
and this code snippet taken from an example plugin for cockpit
that said, and adding that I'm not a programmer/developer, IIUC
callling our events can be made from cockpit without even knowing
nothing but the name of events and the parameters
and, if you just take a look at the code I pasted above, you use only js..

Wow ! Arbitrary command execution seems crazy security wise. I wonder
what fail-safe measures are in place here.

Anyway, this just move the most of the logic from the backend to the
frontend, so yes, JS only, but much more complicated JS. Not sure it's a
real win. For me it's not, as I'm more comfortable with perl.

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Stefano Zamboni]

Post by Daniel Berteaud
Wow ! Arbitrary command execution seems crazy security wise. I wonder
what fail-safe measures are in place here. Anyway, this just move the
most of the logic from the backend to the frontend, so yes, JS only,
but much more complicated JS. Not sure it's a real win. For me it's
not, as I'm more comfortable with perl. ++

please, read the fine documentation on how cockpit works.. cockipt is
just like a CLI regarding permission..

you can't just execute arbitrary code since the code must be on the server

S.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[John Crisp]

Post by Daniel Berteaud

Post by Stefano Zamboni
All css driven, no tables.. something that looks like 2016 not only outside (the look), but inside (the code)

- Rewrite all the panels, one by one, using a more flexible backend
framework (Mojo, as I don't see any alternative suggested)
- Each time a panel is rewritten, provide two set of templates: one for
the old look (so we can keep some visual coherency while the rewrite
happens), and a new, more modern one (I'd choose bootstrap as it's the
only frontend framework I ever used)

Have a look at this - admin theme built on bootstrap with jquery et al:

http://www.bootstrapstage.com/devoops/

Demo to see what sort of things you can do:

http://www.reetspetit.com/KoozaliServerManager/devoops/

There are loads of themes out there, or design your own
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

cockpit isn't just html/js/css. I had a quick look on github and found
lots and lots of .c and .h files.
The front end which runs in the browser might be all html/js/css, but
there still needs to be a backend which will interact with the the system.

see my other email in answer to Dani

S.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Hsing-Foo Wang]

Le 01/02/2016 11:46, Hsing-Foo Wang a écrit :


On 01/02/16 11:43, "Daniel Berteaud" <devinfo-***@lists.contribs.org on behalf of ***@firewall-services.com> wrote:



- We just have not enough resources. Charlie has posted a panel example
using Mojo on BZ. I'd like to take a look at it
- It's not related to C7, so either we write it before SME10, and we'll
have the new S-M on SME10, or we write it after, so we have to think
about porting the actual S-M on C7


Why are we focussed on Mojolisious? There must be tons of frameworks out there that are much easier for (newbie) dev. THAT would help us.


Do you have any proposal ? Charlie has suggested Mojo years ago, and, for having worked with it on some projects, I also think it's great.

No, because I am not a programmer nor a system architect. But you did hit the nail on the head
. It’s only you and Charlie that love it, and we do need to open up our dev team with more common and well known tools to new students and devs.

[Daniel Berteaud]

Post by Hsing-Foo Wang
No, because I am not a programmer nor a system architect. But you did
hit the nail on the head
. It’s only you and Charlie that love it, and
we do need to open up our dev team with more common and well known
tools to new students and devs.

So those dev should raise their hands now. We can't wait indefinitely
for hypothetical future contributors.

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Hsing-Foo Wang]

No, because I am not a programmer nor a system architect. But you did hit the nail on the head
. It’s only you and Charlie that love it, and we do need to open up our dev team with more common and well known tools to new students and devs.






So those dev should raise their hands now. We can't wait indefinitely for hypothetical future contributors.

There are none left besides you and Charlie. Chicken and egg
..

[Stefano Zamboni]

Post by Daniel Berteaud
So those dev should raise their hands now. We can't wait
indefinitely for hypothetical future contributors.
There are none left besides you and Charlie. Chicken and egg…..

Please, let's try to stay IT.. such kind of arguing is nothing but useless

TIA
S.

[Stefano Zamboni]

Post by Daniel Berteaud
There's nothing to argue about this: yes the current S-M looks old, is
- We just have not enough resources. Charlie has posted a panel example
using Mojo on BZ. I'd like to take a look at it
- It's not related to C7, so either we write it before SME10, and we'll
have the new S-M on SME10, or we write it after, so we have to think
about porting the actual S-M on C7

why can't we "just" rethink both the things in the same time?
for example.. in NS they modified standard db command to give output in
json format..
json can be used by any modern web framework..

having to work on 2 separated projects in different time is, IMO, a
waste of time

S.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Daniel Berteaud]

Post by Stefano Zamboni
why can't we "just" rethink both the things in the same time?

The question should rather be "Why would we rethink both at the same
time". They are orthogonal problems which can, and should be solved
separately.

Post by Stefano Zamboni
for example.. in NS they modified standard db command to give output
in json format..
json can be used by any modern web framework..

We can work on this if it proves to be useful.

Post by Stefano Zamboni
having to work on 2 separated projects in different time is, IMO, a
waste of time

I don't think so. Two smaller projects have more chances to succeed (at
least one of them) than one huge. There's no effort duplication as they
do not overlap.

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Stefano Zamboni]

Post by Daniel Berteaud

Post by Stefano Zamboni
for example.. in NS they modified standard db command to give output
in json format..
json can be used by any modern web framework..

We can work on this if it proves to be useful.

are you serious?
json is nowadays maybe the most used way to format and exchange data..
it does work, sure

Post by Daniel Berteaud

Post by Stefano Zamboni
having to work on 2 separated projects in different time is, IMO, a
waste of time

I don't think so. Two smaller projects have more chances to succeed (at
least one of them) than one huge. There's no effort duplication as they
do not overlap.

they overlaps.. because our UI is bound to the underlying OS.. having a
new OS that gives us natively some features is a fact we can't simply ignore

for example, you can't use cockpit on SME9/C6

and cockpit is not only bound to systemd api.. it can also exec CLI
commands (see
http://stef.thewalter.net/creating-plugins-for-the-cockpit-user-interface.html)
just in my imagination, I'm thinking to call an event passing it an
argument and some data in json format

S.

_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Daniel Berteaud]

Post by Stefano Zamboni

Post by Daniel Berteaud
We can work on this if it proves to be useful.

are you serious?

Of course I am. If you're in doubt, I'm always either funny or serious
(and sometimes both). If what I say is not funny, then it must be
serious ;-)

Post by Stefano Zamboni
json is nowadays maybe the most used way to format and exchange data..
it does work, sure

I know that. I meant, if it proves to be useful *in this context*. For
now, I see no benefit in using JSON compared to our DB API (both would
end in perl hashs or hashrefs) but it doesn't mean I won't change my mind.

Post by Stefano Zamboni
they overlaps.. because our UI is bound to the underlying OS.. having
a new OS that gives us natively some features is a fact we can't
simply ignore
for example, you can't use cockpit on SME9/C6

Ok, that's the kind of things which need to be looked at. I'm not sure
cockpit is the right tool for us, but if you can prototype something,
I'll have a look.

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Stefano Zamboni]

I think that was said about C6, and maybe C5. But maybe it's true now.
We'll see.

Well, sincerely I don't want to see at all

You can't look at a user interface in isolation. You also need to look
at
it in terms of what it does, and in terms of how it does what it does.
If you just want things to look different, then that can be done with
HTML and CSS. If you are changing the scope of what can be done, or how
it
is done, then there is a lot more work to be done.
Keep investigating.

We have many features but a gui that sucks
People is migrating to other solutions because of it (I know, since I am on NS forums too)

But the features we have are nothing special. . There are competitors that integrate AD and other functions we lack or we could have but we're stuck on sw that need to be patched and compiled every time

[Stephane de Labrusse]

The real problem with formagick is that it is obsolete.... Do we need to work on it and use it for a new system....i hope no....do we need to find something new....i would say yes.

Post by Stefano Zamboni
- as for Charlie's mail here, perl in C7 doesn't support suid

This is true.

Post by Stefano Zamboni
- we have to completely rewrite and redesign server-manager

This is not true.
We have a problem to solve.
*One* way to solve the problem is to use a setuid program written in C
as
an intermediate between apache and the perl server-manager scripts. We
could use links to that script in place of the symlinks we currently
use
(symlinks in /etc/e-smith/web/panels/manager/cgi-bin, scripts in
/etc/e-smith/web/functions). See below for example code.
None if this is to say that we shouldn't consider a UI change. But
don't
start with a false premise.
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main (int argc, char *argv[])
{
const char str1[] = "/etc/e-smith/web/functions/";
char * p;
p = strrchr(argv[0], '/');
if (p)
{
p++;
}
else
{
p = argv[0];
}
char *res;
res = malloc(strlen(str1) + strlen(p) + 1);
strcpy(res, str1);
strcat(res, p);
argv[0] = res;
setuid(0);
execvp(argv[0], &argv[0]);
return 42;
}
_______________________________________________
Server Development Discussion
Searchable archive at http://lists.contribs.org/mailman/public/devinfo/

[John Crisp]

Post by Stefano Zamboni
Hi all
a few guys from Koozali are here, in Bruxelles, attending at Fosdem..
many, many, tooo many interesting things to see/listen to/discuss..

Should use a more modern framework -FORMMagick is a blocker to a lot of
people

Server manager should be responsive for mobile

Coded in language in common use today - possibly attracting newer developers

Templates and config for the manager should still be generated by core
SME templating functions/api

Cockpit is just one suggestion (easily integrates with S4 and docker out
of the box) but there are alternatives like bootstrap/ devoops
http://www.bootstrapstage.com/devoops/ and probably more if we look

Have a look at these sort of things Tony played about with at the end of
2014 (nearly a year and half ago)

http://www.reetspetit.com/KoozaliServerManager

This is probably the nicest example :

http://www.reetspetit.com/KoozaliServerManager/koozali_test/

Just click Sign In

The thoughts were can we use an existing framework where we can still
use the SME functions to generate templates for the manager. Whatever is
used is going to need a lot of rewriting. But using an established
framework my interest other developers.

My only reservation is the possible loss of elinks and the text based
manager which is extremely useful.


_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[John Crisp]

Post by John Crisp
Cockpit is just one suggestion (easily integrates with S4 and docker out
of the box) but there are alternatives like bootstrap/ devoops
http://www.bootstrapstage.com/devoops/ and probably more if we look

Cockpit and devoops are not alternatives. One is a system management
suite, and the other is just a theme for a GUI toolkit.

Yes I understand the difference. There are different ways of skinning
the same cat. The question was how do we update the server manager. Do
we replace it en masse - e.g. cockpit etc, or use a different backend
framework e.g. Mojo etc with say a management theme on top

Both look great, no question. But it is no simple task to bolt a new look
on top of the existing UI. You might end up building something totally new
from the ground up. Are you ready to do that? If you are going to do that,
would you be better starting with Nethserver, Zentyal or ClearOS? Or just
settling with what they already offer?

Maybe we DO build something new. Everyone else has, and that is half the
problem. Yes, new fangdangled UIs don't a good system make necessarily.
But they do attract more users and developers.

Unfortunately, in this day and age, image sells.

Should we use something from some else ? Possibly. We just haven't
looked down that road yet.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[John Crisp]

Post by Stefano Zamboni
Hi all
a few guys from Koozali are here, in Bruxelles, attending at Fosdem..
many, many, tooo many interesting things to see/listen to/discuss..

Another point is keeping things simple.

Make most stuff pluggable.

You NEED:

Core OS
Email
Authentication services
Server-manager
e-smith type functions for template generation et al
(have I missed something ?)

You can choose to add/use:

File sharing
Web services
Webmail/Groupware
Everything else and the kitchen sink

The more we reduce the core items, the less we need to maintain on a day
to day basis.


_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Jean-Philippe Pialasse]

Post by John Crisp
Make most stuff pluggable.

This is as Stephane did explain "avec Brio" the most blocking part of the current manager.

The aspect is neither a blocking problem, as a lot could be done with css, js and html5.

The problem not that much the number of pages on a new install, than its growth without any logic or almost when you add contribs.

I do not see a way to make this more plug gable with the current formmagick. Am I to correct ?

Post by John Crisp
Core OS
Email
Authentication services
Server-manager
e-smith type functions for template generation et al
(have I missed something ?)

SME server code has been broken up that way for a very long time. If you
want a smaller base install with fewer services running, that's not hard
to do.

To be used to is not a reason not to change. However, again, the initial breakdown is not the main problem.

Post by John Crisp
File sharing
Web services
Webmail/Groupware
Everything else and the kitchen sink
The more we reduce the core items, the less we need to maintain on a day
to day basis.

I don't think that's true. There might be good reasons for more modular
deployment than we have now, but I don't think that's one of them.

This is a choice that we have to leave to the admin. I find it easier to me to install SME and deactivate myself services I do not need than installing a centos and the services i need and to configure them.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman

[Stefano Zamboni]

Post by Jean-Philippe Pialasse
I do not see a way to make this more plug gable with the current formmagick. Am I to correct ?

that's the point

Post by Jean-Philippe Pialasse

SME server code has been broken up that way for a very long time. If you
want a smaller base install with fewer services running, that's not hard
to do.

To be used to is not a reason not to change. However, again, the initial breakdown is not the main problem.

I would add that no one is asking for a revolution.. we have a solid
core.. it "just" must be improved in some ways

Post by Jean-Philippe Pialasse
This is a choice that we have to leave to the admin. I find it easier to me to install SME and deactivate myself services I do not need than installing a centos and the services i need and to configure them.

yes, configuring a SME is easier than configuring a CentOS (if not, why
are we discussing about SME? :-))
anyway, you seems to me a skilled user
think about an unexperinced guys installing SME on a VPS.. I'd prefer
him to have a minimal core and install what he needs that onstalling all
the stuff and then start poking around to disable services..

S.

_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

I don't think that's true. There might be good reasons for more modular
deployment than we have now, but I don't think that's one of them.
_______________________________________________

well.. for example, a SME installed on a VPS using an internal dummy
interface won't likely need all the samba stuff
it means less packages to install and less packages to keep updated

the all in one approach is good, but it'd be an option.. maybe the
default one, but we'd choose since the beginning what to install..
installing a bunch of services and then just disable most of them is not
a good thing IMO

S.

_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[John Crisp]

Post by Stefano Zamboni

I don't think that's true. There might be good reasons for more modular
deployment than we have now, but I don't think that's one of them.
_______________________________________________

well.. for example, a SME installed on a VPS using an internal dummy
interface won't likely need all the samba stuff
it means less packages to install and less packages to keep updated

Yup though I take the point that it depends on what we should consider
'core' that we maintain, and what we consider a 'extra/contrib' that we
do not

Post by Stefano Zamboni
the all in one approach is good, but it'd be an option.. maybe the
default one, but we'd choose since the beginning what to install..
installing a bunch of services and then just disable most of them is not
a good thing IMO

Yup

Look at what various distros do in their installers.

A simplified list of install choices would be good

Is this a VPS (dummy networking, maybe no LVM etc)
Do you want IMAP mail/POP mail/Both
Do you want web services
Do you want groupware
Do you want print services
Do you want file sharing

Blah....

Save the effort of then installing a contrib to make it easy to turn
them off (how many leave stuff running because they can't/won't use the
CLI and turn stuff off ?)

Possibly reduce the security footprint by not installing unneeded packages.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Hsing-Foo Wang]

Post by John Crisp
Yup though I take the point that it depends on what we should consider
'core' that we maintain, and what we consider a 'extra/contrib' that we
do not

My advice would be:

SME Server Core
SME Server modules/plugins
Community modules/plugins

As I indicated before, time for a SME App market...

_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

Post by Hsing-Foo Wang
SME Server Core
SME Server modules/plugins
Community modules/plugins
As I indicated before, time for a SME App market...

that's another point we'd discuss.. but it's more a Board topic than a
devinfo one.

S.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

Ah, so when John said "the less we need to maintain on a day to day basis"
(that crucial context was trimmed away from the follow up thread, BTW), he
was talking about "we" as sysadmins, not "we" as developers. We as
developers need to maintain it all whether it is only sometimes installed
or whether it is always installed.

well.. all our contribs are mantained even if some of them are not in
use.. aren't they? :-)

in any case, I think that we should think about a more modular system
and a more plug-in friendly approach

S.


_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[stephane de Labrusse]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I don't think that's true. There might be good reasons for more
modular deployment than we have now, but I don't think that's one
of them.

Simply to install sme on a cloud server,It is a really good reason,
no need samba on a soyoustart, online.net, amazone (and much more) serve
r


- --

Cordialement

Stéphane de Labrusse
Membre de l'Aru2L http://www.aru2L.org
Membre de l'ApriL http://www.apriL.org


PORTABLE : 06 29 19 12 99
DOMICILE : 05 65 78 90 72
WEB : http://geekeries.de-labrusse.fr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlay89EACgkQ1CTfJUQAIe5nVACeNsr0YVQkDzLxprsm7xPPtKen
JWEAn21e5DPyZOAu2q1DZmAsathP86o3
=M74e
-----END PGP SIGNATURE-----
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Marco Hess]

Sorry of this is a duplicate post as I am not sure my previous post
got through to the list because I seem to have used a wrong identity.

Anyway as a long time lurker on this list I am watching this
discussion on a 'next generation' server manager.

To me something seems to be missing in the arguments between 'mojo'
and 'cockpit'. Admittedly I know very little about either of them so I
apologize if I am barking up the wrong tree or step on anybodies toes.

But a key issue seems to me is that while 'mojo' is (possibly) a
fantastic framework. It is just that. A framework for web development.
And the same applies to any other frameworks suggested. Bootstrap is
just a HTML/CSS framework and Devoops is just a 'theme' on bootstrap.

If a 'server-manager' interface is to be developed with 'mojo' (or any
of these frameworks) it is essentially a new 'web app' development
project from scratch.

Similar to how the original server manger was developed on the basis
of the FormMagick 'framework'.

This smells to me that we end up on our own to develop this for SME.
In the end this is something unique to SME and a lot of effort would
have to go in with creating such an 'app' and develop the 'plugin'
capabilities and API's needed.

Not to mention the ongoing maintenance.

'cockpit' on the other hand, is already a 'server-manager' in its own
right and had 'plug-in' capabilities. 'All we need to do' (famous last
words) is to hook the SME template handling into 'cockpit'.

Just based on 'gut feel' 'cockpit' seems a better way forward to me as
it is already an app with plugin capability and would provide an
ability to also leverage a number of existing features to
monitor/manage an SME server that we don't have to develop as well as
leveraging ongoing development in server management outside of SME
like Docker.

Just my 2c worth.

Cheers,

Marco


_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

Post by Marco Hess
But a key issue seems to me is that while 'mojo' is (possibly) a
fantastic framework. It is just that. A framework for web development.
And the same applies to any other frameworks suggested. Bootstrap is
just a HTML/CSS framework and Devoops is just a 'theme' on bootstrap.
If a 'server-manager' interface is to be developed with 'mojo' (or any
of these frameworks) it is essentially a new 'web app' development
project from scratch.
Similar to how the original server manger was developed on the basis
of the FormMagick 'framework'.
This smells to me that we end up on our own to develop this for SME.
In the end this is something unique to SME and a lot of effort would
have to go in with creating such an 'app' and develop the 'plugin'
capabilities and API's needed.

and this is undoubtly true
we'd develop something unique using a "less popular" framework in a not
so widely used language..

doing so, the development will be on the shoulders of few people..

Post by Marco Hess
Not to mention the ongoing maintenance.
'cockpit' on the other hand, is already a 'server-manager' in its own
right and had 'plug-in' capabilities. 'All we need to do' (famous last
words) is to hook the SME template handling into 'cockpit'.
Just based on 'gut feel' 'cockpit' seems a better way forward to me as
it is already an app with plugin capability and would provide an
ability to also leverage a number of existing features to
monitor/manage an SME server that we don't have to develop as well as
leveraging ongoing development in server management outside of SME
like Docker.
Just my 2c worth.

a big advantage of cockpit is that it will be the default in the
upstream distro, that is actively (I admit, too actively ATM) developed
and that plugins can be written by people that even don't know anything
about SME internals..
I'd try to make an example:
think about the users page..
- we need a function to retry the users list in json
- the plugin page will call it at load time, retrieve the json,
interpretate it and plublish it in the best way
- a little form to insert a new user data or edit an existing user
- we need a function which will take care of insert the values into
accounts db and then call the rigth event..

from my NS machine:
[***@neth ~]# config showjson httpd-admin
{
"props" : {
"SSL" : "enabled",
"ForcedLoginModule" : "",
"access" : "public",
"status" : "enabled",
"favicon" : "favicon.png",
"colors" : "",
"logo" : "",
"TCPPort" : "5061"
},
"name" : "httpd-admin",
"type" : "service"
}
[***@neth ~]# config printjson httpd-admin
{"props":{"SSL":"enabled","ForcedLoginModule":"","access":"public","status":"enabled","favicon":"favicon.png","colors":"","logo":"","TCPPort":"5061"},"name":"httpd-admin","type":"service"}[***@neth
~]#


ideally we caould have a small group of people just working on the perl
core and other guys working just on the web part

the funny part is that everyone can create such a page/plugin, because
all the needed info are just
- to retrieve the list use this call
- to save the values use this call with these parameters

obiously all the data validation must be rethought.. surely there are js
functions (in jquery for sure) to validate email, ip addresses and so on..

am I just dreaming or am I missing something so big to become invisible?

once I manage in having e-smith-base and e-smith-lib working on C7 (with
all the env variables available) I'll create a POC

S.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

Any data validation in js is just a UI convenience. Validation *must* be
done in the back-end - you can't trust the data which comes in a request.

I apologize: often I forget to explain my thoughts and so I leave some
space for misunderstandings.

what I meant is that there must be a validation in the UI (and this can
be done using jquery and its plugins) AND in the back-end (and we
already have it)

I know it would be a kind of logic duplication, but having a good
validation on the client (and almost in RT) is a good thing.

S.


_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

Can you explain what you mean by "almost in RT"?

I explain what I meant starting from our S-M

let's say I want to add a new user account

I have a form to fill, it:
- contains some mandatory fiends
- some of them require proper data format (tel number, for example)
- at least one of them (username) need to be unique in our accounts db

when I filled all the fileds, I just press "save" button, data are sent
via POST to the web server and there are validated.. if something is
wrong, data are pushed back to the browser, with an error

this is old styled and deprecated since epoch now

in a modern web interface, data validation is done on client side too,
and it is done in real time: if you try to push the Save button with
some mandatory fields with no value, it won't work.. if you try to
insert a unexpected value in a field that, for exampe, expects an IP
address, you are warned immediately..
back to our new user interface, once you've compiled the username field,
once you move to the next field I can just make a call to db accounts
and see if this value is already present.

this doesn't mean that we have to rely on client validation at all, but
this is how a modern and usable web interface must work in 2016.

ideally (just thinking loud), we'd move all our data validation rules
actually in the web page logic into some "validator objects".. something
that I can simply call from a single line of code

db validate account myArray

where account is the type of object I'm manipulating and myArray is an
array with all the fields that must be validated.. this kind of object
should just answer with the validation result, which will be used by the
web page.

Ciao
S.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

RT stands for Real Time

Post by Stefano Zamboni

Post by Stefano Zamboni
what I meant is that there must be a validation in the UI (and this

can be

Post by Stefano Zamboni
done using jquery and its plugins) AND in the back-end (and we

already have

Post by Stefano Zamboni
it)
I know it would be a kind of logic duplication, but having a good

validation

Post by Stefano Zamboni
on the client (and almost in RT) is a good thing.

Can you explain what you mean by "almost in RT"?

Thanks for the followup. it's interesting. But it doesn't tell me what
you
mean by "RT" or "almost in RT".
Do you mean "round trip"? If so, what does "almost in round trip" mean?

[brian read]

I think RT means "Real Time" and in "in Real time" - i.e.(I guess)
errors returned to the user in the client at the moment the data is
submitted.

what I meant is that there must be a validation in the UI (and this can be
done using jquery and its plugins) AND in the back-end (and we already have
it)
I know it would be a kind of logic duplication, but having a good validation
on the client (and almost in RT) is a good thing.

Can you explain what you mean by "almost in RT"?

Thanks for the followup. it's interesting. But it doesn't tell me what you
mean by "RT" or "almost in RT".
Do you mean "round trip"? If so, what does "almost in round trip" mean?
_______________________________________________
Server Development Discussion
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

I think RT means "Real Time" and in "in Real time" - i.e.(I guess) errors
returned to the user in the client at the moment the data is submitted.

Thanks. Got it now.
That's a slightly different definition of "real time" to the one used when
specifying/designing operating systems.
Here's an interesting tool for specifying jQuery and form submit
http://qtfk.github.io/Mojolicious-Plugin-Jam/
http://qtfk.github.io/Mojolicious-Plugin-Jam/Form/Field/

well.. glad to know that naw all is clear and that there are no problems
to have the same features with mojo

Charlie, since you told me that my POC won't be interesting/relevant
without data validation, I kindly ask you to provide the same POC I'm
working to (i.e. the user management panel) done with mojo..
the features that must be available are:
- user accounts retrying from accounts db
- their pubblication in a fine, responsive and eye catching interface
- account creation, with data validation
- account editing, with data validation
- account locking/unlocking
- account deletion

ATM, since I'm working just on a bare C7 with some rpms from NS (I use
the standard db commands, nothin NS' specific), I have no events to
call, but I can easily simulate any king of event firing.

as you say that mojo is easy and it can just work on SME9 (and this
makes things a little easier), I think that a perl master like you won't
have any issue and that you can show it in a breif time (let's say 15
days starting from today)

Thank you

S.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Daniel Berteaud]

Post by Stefano Zamboni
well.. glad to know that naw all is clear and that there are no
problems to have the same features with mojo
Charlie, since you told me that my POC won't be interesting/relevant
without data validation, I kindly ask you to provide the same POC I'm
working to (i.e. the user management panel) done with mojo..
- user accounts retrying from accounts db
- their pubblication in a fine, responsive and eye catching interface
- account creation, with data validation
- account editing, with data validation
- account locking/unlocking
- account deletion

Well, AFAIK, all those features are not yet implemented in your POC ;-)

I'd like to hack a Mojo POC so we can compare both approachs, give me a
few days. I think I get what you like with cockpit: it's the way to
easily retrieve data from the client side in JS. I have no problem with
it, and I think we could do the same (or even better) in Mojo.

I agree that an JSON API to query / update the DB would be useful. I
don't like the way it's done in cockpit (IMHO, allowing arbitrary
command execution from a web panel is crazy security wise), but I think
there are ideas to take from this. In which way I think we can do a
better job: we could define a clearer API, and restrict what can be
done. Eg, to read data:

{
"action": "get",
"database": "accounts"
"filter": { "type": "user" }
}

Or to modify

{
"action": "set_prop",
"database": "accounts",
"entry": { "key": "user1", "ForwardAddress": "***@bar.com" },
"run_event": "user-modify",
"event_arg": "user1"
}

The response would be a JSON object easy to parse on the client to
display the status report.

(These are just an examples, we'd need to define a clear API, which is
not something I'm very good at, but I should be able to propose
something working, even if not perfect)

Such a JSON API could also be used for a native mobile app if someone is
interested ;-)

For sure, this would require a bit more work, but IMHO, it worths the
effort:

* We can already look at it on SME9, no need to wait for SME10 to
start working (we're not quite there yet, even if we've done some progress)
* No arbitrary commands spawned by a web client
* Easier to control which user can do what (= natively provide the
equivalent of the userpanel contrib)
* More control on what is logged

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Stefano Zamboni]

Post by Daniel Berteaud

Post by Stefano Zamboni
well.. glad to know that naw all is clear and that there are no
problems to have the same features with mojo
Charlie, since you told me that my POC won't be interesting/relevant
without data validation, I kindly ask you to provide the same POC I'm
working to (i.e. the user management panel) done with mojo..
- user accounts retrying from accounts db
- their pubblication in a fine, responsive and eye catching interface
- account creation, with data validation
- account editing, with data validation
- account locking/unlocking
- account deletion

Well, AFAIK, all those features are not yet implemented in your POC ;-)

the first 2 item are :-)

the others are WIP

Post by Daniel Berteaud
I'd like to hack a Mojo POC so we can compare both approachs, give me a
few days. I think I get what you like with cockpit: it's the way to
easily retrieve data from the client side in JS. I have no problem with
it, and I think we could do the same (or even better) in Mojo.

interesting.. are you saying that with mojo all I need is a simple html
file with some js inside? really?
I mean: have we already such a feature just installing mojo? and no one
told us? :-)
moreover, are you saying that a "man of the street" coder, with no perl
knowledge, can do it?
if so, why this come out only now?

Post by Daniel Berteaud
I agree that an JSON API to query / update the DB would be useful. I
don't like the way it's done in cockpit (IMHO, allowing arbitrary
command execution from a web panel is crazy security wise),

again.. I really think you'd take a look at how cockpit works inside..
even if still a WIP, it is available also on RHEL (not only CentOS).. do
you really think that if it were so unsure RH's guys just consider it?

Post by Daniel Berteaud
but I think
there are ideas to take from this. In which way I think we can do a
better job: we could define a clearer API, and restrict what can be
{
"action": "get",
"database": "accounts"
"filter": { "type": "user" }
}
Or to modify
{
"action": "set_prop",
"database": "accounts",
"run_event": "user-modify",
"event_arg": "user1"
}
The response would be a JSON object easy to parse on the client to
display the status report.
(These are just an examples, we'd need to define a clear API, which is
not something I'm very good at, but I should be able to propose
something working, even if not perfect)

this is interesting.. this could be just coded into a single .js file
used by our panels
BTW, once one user is logged in, as for our server-manager, he has the
control, full stop.

Post by Daniel Berteaud
Such a JSON API could also be used for a native mobile app if someone is
interested ;-)

oh.. finally someone start to think about the present and not only to
the past

Post by Daniel Berteaud
For sure, this would require a bit more work, but IMHO, it worths the
* We can already look at it on SME9, no need to wait for SME10 to
start working (we're not quite there yet, even if we've done some progress)
* No arbitrary commands spawned by a web client
* Easier to control which user can do what (= natively provide the
equivalent of the userpanel contrib)
* More control on what is logged

an idea, using the REST approach, could be to create a web server
instance bound to localhost running with the needed privileges and use
the cockpit.http client to dialog with it
we already have the tools for the web UI, we need "just and only" to
adapt our core libraries.. we don't need to recreate a new web app..
that said, if the perl monks here just start to work on the core, even a
few numer of men can do the work.. the web GUI will be easily developed
by other guys that even doesn't know that there's a programming language
called "perl"..

it's up to you (generally speaking): open the development to a wider
number of people or just keep it closed to a less than an handfull guys
and let things die.

S.

_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Daniel Berteaud]

Post by Stefano Zamboni
interesting.. are you saying that with mojo all I need is a simple
html file with some js inside? really?

I mean we can write once a framework using Mojo, such that writting a
new panel can be limited to some HTML templates, and some JS. But this
part would need to be written.

Post by Stefano Zamboni
again.. I really think you'd take a look at how cockpit works inside..
even if still a WIP, it is available also on RHEL (not only CentOS)..
do you really think that if it were so unsure RH's guys just consider it?

I don't know, all I can say is that looking at your POC, you can run
arbitrary commands from the client. The documentation is...light on this
part (to say the least):
http://cockpit-project.org/guide/latest/privileges.html
It's not clear to me if the user needs a shell on the server or not.

Post by Stefano Zamboni
BTW, once one user is logged in, as for our server-manager, he has the
control, full stop.

I don't agree. If we re-think the server-manager, we should include a
user portal into the core. Any valid user should be able to log into the
server-manager. The admin has full access. Simple users just sees their
own settings (we have to define what they can change). Admin can
delegate more access to specific users/groups (the userpanel
functionnality should be builtin)

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone] <tel:[phone]>
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Stefano Zamboni]

Post by Daniel Berteaud

Post by Stefano Zamboni
interesting.. are you saying that with mojo all I need is a simple
html file with some js inside? really?

I mean we can write once a framework using Mojo, such that writting a
new panel can be limited to some HTML templates, and some JS. But this
part would need to be written.

so we must write our framework.. just making a simple guess, how much
time? 1 year? 2? 3?
who is gonna write it? can a poor man coder like me with near to 0 perl
skills be part of the game?

and, once we have the framework, we still must write all our panels..
yes.. in the same way we can do right now with cockpit, just 2 or 3
years later..
in the mean while, if we'll still alive, we have a full featured
enterprise class server distro with a 1990 style UI..

I'm not a business man, but from my point of view this is the strangest
way I ever heard to suicide.

Post by Daniel Berteaud

Post by Stefano Zamboni
again.. I really think you'd take a look at how cockpit works inside..
even if still a WIP, it is available also on RHEL (not only CentOS)..
do you really think that if it were so unsure RH's guys just consider it?

I don't know, all I can say is that looking at your POC, you can run
arbitrary commands from the client. The documentation is...light on this
http://cockpit-project.org/guide/latest/privileges.html
It's not clear to me if the user needs a shell on the server or not.

every user with a login can login on cockpit, and he will have just the
same priviledges he has if he log in on console

just for test, I created an user via cockpit's own panel:
szamboni:x:1000:1000:stefano zamboni:/home/szamboni:/bin/bash
this user can log in on cockpit, but many features are disabled/not
available

changing its shell to /sbin/nologin will still give it access

Post by Daniel Berteaud

Post by Stefano Zamboni
BTW, once one user is logged in, as for our server-manager, he has the
control, full stop.

I don't agree. If we re-think the server-manager, we should include a
user portal into the core. Any valid user should be able to log into the
server-manager. The admin has full access. Simple users just sees their
own settings (we have to define what they can change). Admin can
delegate more access to specific users/groups (the userpanel
functionnality should be builtin)

cockpit can do it, using sudo, restricting access to a group of users,
using symbolic links..
we already have it, we'd just try to use it, instead of make a war.. ATM
there's no valid reason to NOT adopt it.. only guessing and "well, we
can do the same with mojo"

S.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Daniel Berteaud]

Post by Stefano Zamboni
so we must write our framework.. just making a simple guess, how much
time? 1 year? 2? 3?

I have no idea yet.

Post by Stefano Zamboni
who is gonna write it? can a poor man coder like me with near to 0
perl skills be part of the game?

Writing code needs coder skills, nothing new here, and nothing specific
to perl. See below as for why this won't change with cockpit.

Post by Stefano Zamboni
and, once we have the framework, we still must write all our panels..
yes.. in the same way we can do right now with cockpit, just 2 or 3
years later..

No, we can have it even quicker than with cockpit. Simply because we can
start working on our current SME9 base. Cockpit is only able to run on
EL7, so to start working on it (other than creating a POC), we need a
base SME10 working. We don't have it yet. We don't even know the amount
of work it needs (and my guess is: a lot)

Post by Stefano Zamboni
in the mean while, if we'll still alive, we have a full featured
enterprise class server distro with a 1990 style UI..
I'm not a business man, but from my point of view this is the
strangest way I ever heard to suicide.

So, basically, you say that every solution which is not based on cockpit
is suicide ? Come on, lets discuss technical pros and cons without being
dramatic.

Post by Stefano Zamboni
every user with a login can login on cockpit, and he will have just
the same priviledges he has if he log in on console

That's one problem. I want users to have access to a user portal where
they can change their own settings. I don't want them to be able to open
a console (Most users should just have rssh as shell). I don't want them
to be able to modify any settings in the accounts DB, just a subset of
their own props.
Not saying this is not possible, yes it'd be by making a complex db
command, running suid (through a C wrapper as there's no perl-suid
anymore), and checking permissions of the user invoking it. But it'd be
complex. Oh, and it'd need perl skills, and time and...same as my
proposal in fact ;-)

Post by Stefano Zamboni
szamboni:x:1000:1000:stefano zamboni:/home/szamboni:/bin/bash
this user can log in on cockpit, but many features are disabled/not
available
changing its shell to /sbin/nologin will still give it access

Are you saying that even user with no shell can run arbitrary commands
(under their own privilege of course) remotely ? That'd be a major
security issue.

Post by Stefano Zamboni
cockpit can do it, using sudo, restricting access to a group of users,
using symbolic links..
we already have it, we'd just try to use it, instead of make a war..
ATM there's no valid reason to NOT adopt it.. only guessing and "well,
we can do the same with mojo"

Not making a war, but we need to think before we jump. What you're doing
with cockpit is good, you're exploring if it can fit our needs by
creating a POC. In fact, the best thing which can be done. But it's
faaaaaar to early to say ok, lets rewrite everything using it. I have
already exposed several drawbacks for cockpit. Every solutions will have
some. We need to select the one with the fewest.

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Stefano Zamboni]

Post by Daniel Berteaud

Post by Stefano Zamboni
so we must write our framework.. just making a simple guess, how much
time? 1 year? 2? 3?

I have no idea yet.

well, with your experience and considering our (community) manpower, you
can just make a guess

Post by Daniel Berteaud

Post by Stefano Zamboni
who is gonna write it? can a poor man coder like me with near to 0
perl skills be part of the game?

Writing code needs coder skills, nothing new here, and nothing specific
to perl. See below as for why this won't change with cockpit.

programming with cockpit "just" need js/jquery/json/nodejs skills, which
are "a bit" more common nowadays than perl's one.. aren't they?

Post by Daniel Berteaud

Post by Stefano Zamboni
and, once we have the framework, we still must write all our panels..
yes.. in the same way we can do right now with cockpit, just 2 or 3
years later..

No, we can have it even quicker than with cockpit. Simply because we can
start working on our current SME9 base. Cockpit is only able to run on
EL7, so to start working on it (other than creating a POC), we need a
base SME10 working. We don't have it yet. We don't even know the amount
of work it needs (and my guess is: a lot)

to really work on cockpit and C7 we need base and lib rpm.. meaning that
once I can call a signal event, read a db, write on it, the logic is ready

obviously all the part of converting/migrating our init scripts and
templates to the new OS is still needed, but it is in any case
moreover, from a commercial/business point of view, I'd rather prefer to
have SME 10 with the new web interface.. not a re-styled one with a
css.. and not in 2020.

SME9 can be a solid base to develop all the core features needed

Post by Daniel Berteaud

Post by Stefano Zamboni
in the mean while, if we'll still alive, we have a full featured
enterprise class server distro with a 1990 style UI..
I'm not a business man, but from my point of view this is the
strangest way I ever heard to suicide.

So, basically, you say that every solution which is not based on cockpit
is suicide ? Come on, lets discuss technical pros and cons without being
dramatic.

no, I'm saying that if we need 2 years to have the new interface, we're
already dead.. and rewriting our own framework means re-invent the wheel
cockipt has a community.. if there's a bug (a security one) we can just
raise a bug there, concentrating ourselves to other things.
with our own code, we have to write it from the ground, and I suspect
that it won't be simple..
and our *own* framework will be likely useless outside SME, so the
general interest toward it will be very low, like the number of
developers that will step in.
php? no, unsecure (with millions of developers)
cockpit? no, unsecure (with an active development and interest from main
linux distro)
our own framework in perl, based on mojo? yes.. probaly secure after
years of tuning and development done by less than 5 person..

Post by Daniel Berteaud

Post by Stefano Zamboni
every user with a login can login on cockpit, and he will have just
the same priviledges he has if he log in on console

That's one problem. I want users to have access to a user portal where
they can change their own settings. I don't want them to be able to open
a console (Most users should just have rssh as shell). I don't want them
to be able to modify any settings in the accounts DB, just a subset of
their own props.

well.. first of all if you think that there's a security bug, just test
it, demonstrate and let's open an issue there..

Post by Daniel Berteaud
Not saying this is not possible, yes it'd be by making a complex db
command, running suid (through a C wrapper as there's no perl-suid
anymore), and checking permissions of the user invoking it. But it'd be
complex. Oh, and it'd need perl skills, and time and...same as my
proposal in fact ;-)

you're still thinking in how things work now

Post by Daniel Berteaud

Post by Stefano Zamboni
szamboni:x:1000:1000:stefano zamboni:/home/szamboni:/bin/bash
this user can log in on cockpit, but many features are disabled/not
available
changing its shell to /sbin/nologin will still give it access

Are you saying that even user with no shell can run arbitrary commands
(under their own privilege of course) remotely ? That'd be a major
security issue.

no.. even if a user with nologin shell can log in, he can't execute any
kind of command (see attachment)

anyway, I agree that an user with nologin should not authenticate.. I'll
report the thing and see what they say me
AFAICT, there's no rssh rpm available on C7 (just tested briefly.. nor
in the centos' repos nor in epel)

Post by Daniel Berteaud

Post by Stefano Zamboni
cockpit can do it, using sudo, restricting access to a group of users,
using symbolic links..
we already have it, we'd just try to use it, instead of make a war..
ATM there's no valid reason to NOT adopt it.. only guessing and "well,
we can do the same with mojo"

Not making a war, but we need to think before we jump. What you're doing
with cockpit is good, you're exploring if it can fit our needs by
creating a POC. In fact, the best thing which can be done. But it's
faaaaaar to early to say ok, lets rewrite everything using it. I have
already exposed several drawbacks for cockpit. Every solutions will have
some. We need to select the one with the fewest.

citing "back to the future", you're not thinking fourth dimensionally :-)
one dimension you are "just" forgetting is *time*

if we need 3 years to have something cool, secure, ours, well.. we just
trying a new way to commercially suicide ourselves.

think about Bugatti Veyron.. commercially speaking it was one of the
biggest flop in the history.. 5 years and a mountain of millions.. the
cars sold can't just arrive near to the amount spent..
if Bugatti were not part of VW, they're just dead since epoch.

the right tool is the one that can make you build things in a good and
secure way in a relatively small amount of time.

there are people that sells services based on SME.. will they have to
wait 3 years to have SME10? don't you think that if it will be the case,
they just start to see if there's something to migrate to? can we afford
the loosing of coders, users, interest? I don't think so
we had the possibility of make Samba4 working in SME9.. we lost it.. no,
we just thrown it in the trash.. and then, people that want to integrate
SME into a lan where there are windows servers *can't* do it (well..
they can.. they only have to replicate all users on both sides.. scaring
and just absurd in 2016)
how much time can we loose? how many other occasions?

[Daniel Berteaud]

Post by Stefano Zamboni
well, with your experience and considering our (community) manpower,
you can just make a guess

We're just talking about ideas, nothing is defined yet, so no, I can't
estimate anything atm. Having a minimal POC running is probably a matter
of a few hours, which I'll try to find ASAP.

Post by Stefano Zamboni
programming with cockpit "just" need js/jquery/json/nodejs skills,
which are "a bit" more common nowadays than perl's one.. aren't they?

Well, maybe. I'm not even sure. I mean, here, in this community, who has
those skills ? In fact, I don't see in which situation someone would
only write a panel without anything else on the server-side (so perl
skills will always be needed).

Post by Stefano Zamboni
to really work on cockpit and C7 we need base and lib rpm.. meaning
that once I can call a signal event, read a db, write on it, the logic
is ready

Ok, it'll be ready. Ready to wait for the rest of the system to be
ready. Something working on SME9 would mean it could be used sooner,
have more feedback, show more active development.

Post by Stefano Zamboni
no, I'm saying that if we need 2 years to have the new interface,
we're already dead..

What did I say last time about being dramatic ? ;-)

Post by Stefano Zamboni
cockipt has a community.. if there's a bug (a security one) we can
just raise a bug there, concentrating ourselves to other things.

I'm not too worried about bugs (although, cockpit core being in C,
fixing bugs will be harder). I'm worried about the whole design, I'm not
sure it'll be any easier for us to work with.

Post by Stefano Zamboni
well.. first of all if you think that there's a security bug, just
test it, demonstrate and let's open an issue there..

The problem here is the design: we either can't have a user portal, or
we're exposed to security issues. I'm not sure which one is true (the
documentation is lacking), but unless I missed something, it's one or
the other. Or maybe you can tell me: how an unprivileged user could
modify only some of its own props in the account DB without being able
to modify the others ? I see no other way than rewritting the db command
to check for permissions. Which will be complex. And require perl
skills. And time. So no, cockpit most likely won't be a solution we can
use as-is.

Post by Stefano Zamboni
you're still thinking in how things work now

Of course I am, because, unless we're talking about rewritting
everything, things are going to work more or less the same way they do
now won't they ?

Post by Stefano Zamboni
one dimension you are "just" forgetting is *time*

I don't think I forgot anything. I'm too well aware that we lack
manpower. But doing things in a hurry because it seems to be fatser is
not always a good solution. The time gained at some point can be lost at
some other because of design issues. IMHO, we should start a wiki page
where we list the features and goal we want to achieve.

Post by Stefano Zamboni
if we need 3 years to have something cool, secure, ours, well.. we
just trying a new way to commercially suicide ourselves.

(too dramatic)
And that's an argument against using cockpit. If you want to go with
cockpit, it won't be ready before SME10 is, that's a fact. SME10 will
take a lot of time and effort to be ready (and is another project, not
directly related to the new S-M)

Post by Stefano Zamboni
there are people that sells services based on SME.. will they have to
wait 3 years to have SME10? don't you think that if it will be the
case, they just start to see if there's something to migrate to? can
we afford the loosing of coders, users, interest? I don't think so

The time it'll take to have SME10 ready is unrelated to the new S-M
effort. I even think designing and writting the new S-M is a small task
compared to having SME10 finalized.

Post by Stefano Zamboni
people that want to integrate SME into a lan where there are windows
servers *can't* do it (well.. they can.. they only have to replicate
all users on both sides.. scaring and just absurd in 2016)

I have no problem joining latest Windows servers to the good old NT4
domain controller. I don't have to replicate anything. But that's
unrelated to this discussion.

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Stefano Zamboni]

Post by Daniel Berteaud

Post by Stefano Zamboni
well, with your experience and considering our (community) manpower,
you can just make a guess

We're just talking about ideas, nothing is defined yet, so no, I can't
estimate anything atm. Having a minimal POC running is probably a matter
of a few hours, which I'll try to find ASAP.

well.. a POC of what? of the new framework with a usable panel? really? :-)

cool

I guess that you are referring to a POC with mojo to demonstrate that
things can be done.. no doubt about it..
but, as you said, the way is to have an homemade framework.. we can't
make a comparison..
I created panels that work inside a framework using its features, you
won't, IIUC

Post by Daniel Berteaud

Post by Stefano Zamboni
programming with cockpit "just" need js/jquery/json/nodejs skills,
which are "a bit" more common nowadays than perl's one.. aren't they?

Well, maybe. I'm not even sure. I mean, here, in this community, who has
those skills ? In fact, I don't see in which situation someone would
only write a panel without anything else on the server-side (so perl
skills will always be needed).

touchè..
let's say I want to announce "out there" something like
"hi there.. we're starting developing some modules for cockpit to create
a new server manager for SME, are you interested?" on our forums (but
not only)
do you think that announcing something like "hi there.. we're starting
to develop a framework with mojo to be able, in the future, to create
the new server manager for SME, are you interested?" will have the same
appeal?

don't you think that maybe many of our users just use SME as a web
server to serve or just develop web app? and that many of them maybe are
using jquery, angularjs and so on?
ands what about people using nodejs? cockpit uses some libraries from
node.. there's no node instance, anyway.

we need perl skills, sure.. if we just concentrate them into the core,
to have modern api to be used from anykind of web app capable of using
json/rest, we're done.. we'd have 10 different kind of S-M, people could
create and sell customized solutions

no.. we want to create our own toy in our backyard.. in 2016.. with
everybody out there just sharing code and ideas and projects on github,
we want something homemade, stored on our CVS

Post by Daniel Berteaud

Post by Stefano Zamboni
to really work on cockpit and C7 we need base and lib rpm.. meaning
that once I can call a signal event, read a db, write on it, the logic
is ready

Ok, it'll be ready. Ready to wait for the rest of the system to be
ready. Something working on SME9 would mean it could be used sooner,
have more feedback, show more active development.

ok..
<premise>
as I said, english is not my language, so I apologize since now if in
the next lines I could sound harsh or rude or impolite.. I'll try to do
my best to avoid it, but I can't promise that I will succeed
no personal attack, no flame, no offence, I promise
I'd add also that diplomacy is not on my chords, even if in the past
here, via private emails or just on the forums I acted as a peace maker.
</premise>

some things here (in this community) are not clear to me and this distro
is just laying (dying ?)

here we have some *facts*:
- this ML is almost dead for 99% of the time (archives are out there
there).. it sounds to me like that *there's no* active development and
the only activity is aimed to bug fixing.. this makes SME just laying
and makes people leave (no interests, no enthusiasm, no fun)
- to make something move it's necessary, how I'm used to say, to "drop a
bomb".. it happened when Filippo told us about NS fork, it's happening
now, again.. and this is happening *not* since I wrote my first email
"/SME on centos7 - let's start playing/" (almost ignored), but since I
just wrote about my playing with cockpit.. from that moment, this ML has
become a beehive.. isn't it? there was a sudden acceleration toward C7
- our product is a rock solid one
- our server manager, in a single word definition, sucks
- people are leaving us: users (going to other products that maybe offer
the same features but with a more modern eye catching interface) and
developers.. those are leaving because of our being stuck on formagik
and the objective difficulty to work in an environment where new ideas
are simply.. chocked.. for example, the code to add dummy interface
capability just to make SME available on VPS (real world usage,
nowadays) took more than 2 years to be accepted (see #7200)
- the need of a new, modern UI, was stated with #6821, more than 3 years
ago.. since then, *not* a single line of code has been written.. ask
yourself why and give yourself an answer (hint: formagick is a PITA)
- the proposal of using mojo was made more than 2 years ago (see #7819):
since then, *not* a single line of code.. since now..
- we need to involve more people: investors and developers.. the first
must be abstracted by the opportunity of have a investment return, the
latter with something that is, simply, interesting.
and in this case money is not to make us rich persons, but just to pay
the bills and (but this is simply fantasy dreams) pay the coders.
- we need to improve our products to give answers to people demanding
for features nowadays not negligible, like Samba4 and AD interaction,
multiwan and so on

the items above are, simply, facts.. you (and everybody else, of course)
can obviously confute them, and you'll be welcome.. but in (not only)
mine opinion, they are *facts*.

now.. I'm a board member, just like you Dani.. the board is in charge
for (citing from the costitution act)

"/To this end, the corporation shall foster the creation, distribution,
and maintenance of a free integrated, all-in-one server operating system
with bundled applications designed for homes, small businesses,
medium-size businesses, and non-profit organizations, and it will be
licensed under the GNU General Public License. The server operating
system will be focused on simplicity, stability and security, designed
to be operated by people with no technical background, while providing a
platform for technical users to extend./"

and I'm seriously convinced that we must take decisions.. we can't
simply wait and see what happens, because I see this product is sinking
and no one seems to be really interested in moving forward.. maybe I'm
wrong, but (*my personal opinion*) there are some interests in keeping
the status quo i.e. moving de facto all our packages to C7 and keep
everything just how is it now.

what about mojo? I have no doubts, *no one*, that it's a good product,
rock solid and so on.. but we need to find something usable by a wider
base of coders..
in the past Charlie (but not only him) said NO many times to the idea of
converting our S-M to php.. all of us agreed, sure.. but the FACT is
that we're still using the same S-M we had in SME 6.. if not exactly the
same, done with the same approach.

question (and I beg your pardon, but I pretend an answer): why mojo
become so interesting *now*? why are there people writing code and
POCs using it *now* if till 10 days ago almost no one was interested in
it? why? why the cockpit proposal was so scaring?

when Filippo told us about their fork, many argumentations were "oh,
dear, why did you change qmail with postfix?", "why did you choose php
for the web UI? I won't use it"..
the relevant *fact* is that they *did* something.. we're still here, still.

if you or anybody else is really convinced and sure that mojo is the way
to go, well, show me/us, here (devinfo ML and bugzilla) that it is
really easy to use, that permits to have result in a reasonable amount
of time and that it's interesting.. something that will abtract
developers' curiosity.

we (the board) needs *facts*.

there are people that are interested in SME developing, infact we have
hundreds of custom values in our dbs, but almost *no one* (except,
maybe, Steph) worked on web interface to make them visible because
creating a web page now is not trivial and will just make our S-M more
unusable.. and just thinking to add some features (the password
expiration panel, for example) to the core pages sounds absurd because
of the approach often found here and in bugzilla.. using the
smeserver-password contrib as an example, I was told "/no, it won't be
in the core since we non't need to set password expiration here in
$whatever_country/".. well, here (italy) we must, and password's
expitation policy is a good thing, aimed to security.. so, why not?

the *fact* is that everytime someone propose a change, the first answer
is "no", often with *no reason*, followed by months of silence.

we have a Space Shuttle
(Loading Image...) in
our hands but with the cockpit of a piper
(Loading Image...)..
just compare the images..

SME's perl core is a rock, and *no one* is asking for something
different.. it just needs some improvements to be available in another
way from another tool like cockpit..

cockpit: I personally started to play with it last saturday, 10 days
ago, in a cafeteria, at Fosdem. *I never saw it before*.. in 15 mins I
branded it, in 3 hours I created my first trivial plugin that gets
values from a SME's db, shows them and saves them.. just using the db
command.. it tooks me more time just to have a working environment.

but since I start talking about it... wowowowowow!!! I see now that
"mojo is the way", "cockpit is unsecure".. and other things that make me
think that the reasons not to move on are not technical but political..

the funny thing is that we offer SME to te people saying "why would you
start from a bare minimal centos setup and become crazy to install,
config and make all the things you need just work in a secure and easy
manner? just use SME.. easy, reliable, fast, secure"..
and now you (generally speaking) are telling me that instead of start
working/collaborating on an existing framework integrated with the OS
we'd start to create something from ground zero reinventing the wheel..

now, if mojo is the way to go, I expect that somebody will tell me/us
exactly *why*, with an argumented answer and with *facts*.. and if so, I
will expect an argumented list of reasons why we can't/should not move
to cockpit too.

Post by Daniel Berteaud

Post by Stefano Zamboni
no, I'm saying that if we need 2 years to have the new interface,
we're already dead..

What did I say last time about being dramatic ? ;-)

Dani.. if we're talking about phylosophy, no problem at all.
we are on the board, we must give directions, take decisions.. and in
this perspective, 2 years is a sucide
please, stop thinking like a sysadmin ad start thinking in a business
perspective, thank you

Post by Daniel Berteaud

Post by Stefano Zamboni
cockipt has a community.. if there's a bug (a security one) we can
just raise a bug there, concentrating ourselves to other things.

I'm not too worried about bugs (although, cockpit core being in C,
fixing bugs will be harder). I'm worried about the whole design, I'm not
sure it'll be any easier for us to work with.

well.. first of all, maybe it is not perfect, but it is just real and in
active development
comparing a *real* thing with just ideas (our framework) doesn't make
sense to me

Post by Daniel Berteaud

Post by Stefano Zamboni
well.. first of all if you think that there's a security bug, just
test it, demonstrate and let's open an issue there..

The problem here is the design: we either can't have a user portal, or
we're exposed to security issues. I'm not sure which one is true (the
documentation is lacking), but unless I missed something, it's one or
the other. Or maybe you can tell me: how an unprivileged user could
modify only some of its own props in the account DB without being able
to modify the others ? I see no other way than rewritting the db command
to check for permissions. Which will be complex. And require perl
skills. And time. So no, cockpit most likely won't be a solution we can
use as-is.

again (maybe my english is faulty): we have few resources but skilled in
perl.. instead of wasting their energies working on:
- porting everything to C7
- creating from 0 a new framework, test is, document it, debug it
- creating the new S-M

they should just concentrate theirselves on porting and enhancing our core

Post by Daniel Berteaud

Post by Stefano Zamboni
you're still thinking in how things work now

Of course I am, because, unless we're talking about rewritting
everything, things are going to work more or less the same way they do
now won't they ?

well.. take a look at my user panel for cockpit and compare it with the
relevant part of code needed now to just publish the user table..
do you think they are the same? do you think that the needed effort is
the same?

Post by Daniel Berteaud

Post by Stefano Zamboni
one dimension you are "just" forgetting is *time*

I don't think I forgot anything. I'm too well aware that we lack
manpower. But doing things in a hurry because it seems to be fatser is
not always a good solution. The time gained at some point can be lost at
some other because of design issues. IMHO, we should start a wiki page
where we list the features and goal we want to achieve.

this sounds reasonable

Post by Daniel Berteaud

Post by Stefano Zamboni
if we need 3 years to have something cool, secure, ours, well.. we
just trying a new way to commercially suicide ourselves.

(too dramatic)
And that's an argument against using cockpit. If you want to go with
cockpit, it won't be ready before SME10 is, that's a fact. SME10 will
take a lot of time and effort to be ready (and is another project, not
directly related to the new S-M)

SME10 must be released with the new interface.. from a business
perspective, anything different is just, again, shooting on our feet.

Post by Daniel Berteaud

Post by Stefano Zamboni
there are people that sells services based on SME.. will they have to
wait 3 years to have SME10? don't you think that if it will be the
case, they just start to see if there's something to migrate to? can
we afford the loosing of coders, users, interest? I don't think so

The time it'll take to have SME10 ready is unrelated to the new S-M
effort. I even think designing and writting the new S-M is a small task
compared to having SME10 finalized.

ok.. so, please, don't waste your time on S-M and just concentrate
yourself on the other issues :-)

Post by Daniel Berteaud

Post by Stefano Zamboni
people that want to integrate SME into a lan where there are windows
servers *can't* do it (well.. they can.. they only have to replicate
all users on both sides.. scaring and just absurd in 2016)

I have no problem joining latest Windows servers to the good old NT4
domain controller. I don't have to replicate anything. But that's
unrelated to this discussion.

the fact that you don't personally need AD is unrelevant..
times where I can go to a customer and say him "ok, I'll install you a
SME that will take care of everything" are gone..
now I go to customers that have windows servers with AD and they need
some features they can't simply afford (money) or they don't want to be
M$ made (exchange anybody?).. I can't go there and tell "ok.. we have 2
options.. A) remove your server and use SME for everything B) install
SME and replicate all the settings on both sides", because it is simply
impossible..
For example, a feature NS has and is very usefull is AD integration: I
can join NS to an AD domain and offer services to the users.
Samba4 and AD and other features are a must.
once I finished my POC with cockpit, I'll start to work on S4.. I kindly
ask everybody, since now, to not start saying "oh, dear, S4 is a PITA,
uneeded, I don't need it, M$ is crap" and so on

here I talking not as a developer or as a sysadmin, here I'm talking as
a board member.
And I'm keeping the discussion here to have *technical facts and answers*

features offered by SME nowadays can be found on appliances like nas you
take from the shelves in the local store..
we had some plus in the past comparing with our competitors, now we have
not.

@HSF, would you mind to create a wiki page about features? TIA

S.

[Stefano Zamboni]

for your info:

https://github.com/cockpit-project/cockpit/issues/3166

S.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Daniel Berteaud]

Post by Stefano Zamboni
and I'm seriously convinced that we must take decisions..

Stefano, I agree, of course we must take decisions. But we must take
informed, well planned decisions. We can't just jump on something
without exploring alternatives, or without facing problems it might
have. I don't say cockpit won't be what we'll choose, I've just pointed
our several issues I see with it (and which are not details IMHO).

Now please, lets focus on *technical* aspects of this subject. I'm not
interested in "not doing this is suicide" (well, it's not that I'm not
interested, but it's off topic for devinfo ML)

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Stefano Zamboni]

Post by Daniel Berteaud
Stefano, I agree, of course we must take decisions. But we must take
informed, well planned decisions. We can't just jump on something
without exploring alternatives, or without facing problems it might
have. I don't say cockpit won't be what we'll choose, I've just pointed
our several issues I see with it (and which are not details IMHO).
Now please, lets focus on *technical* aspects of this subject. I'm not
interested in "not doing this is suicide" (well, it's not that I'm not
interested, but it's off topic for devinfo ML)

thank you for your aswer to my last email

now, would you mind to ask at some question I posted?
'cause often people ask for informations and never have any kind of
answer.. I'm not in hurry, take the time you need

thank you for your consideration, patience and time

S.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

Post by Stefano Zamboni
now, would you mind to ask at some question I posted?

sed s/to ask at/to answer to

S.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Marco Hess]

For those of you that were not sure what I meant with 'Hear, Hear' to
Stefano's length post I just want to clarify that it is an expression of
whole heartedly support and agreement and we should all have a good look
and think about what Stefano says in that post.

My career has and is in electronics engineering and embedded software
development and I do have a few years up my sleeve with that and have done
many projects of varying level of complexity over the years in a variety of
roles. As side projects I also have developed some web applications so I
know a bit about various web frame works in PHP and Ruby on Rails.

I use SME as my office server in my small consultancy business and as such
I have developed some contribs for SME that I wanted/needed such as the
smeserver-git contrib. So I have a bit of perspective about developing for
the current server-manager as well.

The key thing that I love about SME is the core template system and how
easy it is to install and how it just works.

So even for a simple server for just some web app or some other specialised
service that I need, I prefer to grab an SME install to start with. Over
the years I tried various other distributions also including minimalist
server versions of Ubuntu, Fedora, Centos and I find them all them too hard
to setup/maintain for even simple jobs.

I guess we all know that or we would not be on this list.

So that template handling system is the absolute core of SME and is really
what make SME tick.

The next is then how to drive that template system. The current
server-manager is a complete PITA and has many problems in terms of ease of
extending that never is really extending but a often needs a new contrib
with some new links and pages in server manager and with some level of
duplication in these different pages. I think that just adds to user
confusion as things are no longer logically grouped ot where you expect
them. And all this without mentioning that you need a) quite a bit of in
depth knowledge to get the right contribs that can just extend the server
manager to make it usable (like I find myself always installing the remote
user access contrib and a cron contrib as a minimum and why those type of
contribs have not become 'standard' is beyond me) and then b) you need
quite a bit of CLI based sleuthing to get these contribs installed and
configured right with only CLI type commands that are often poorly
documented (if even that).

I don't think anybody disagrees here that we need something new.

Coming back to my limited experience in webapp development I have been
there and done that. Learning curves for a potentially new language to use
and just the size of modern framework API's, styles, conventions, are huge
to get anywhere near fluent in it. Not to mention the issues around getting
your head around REST, HTML, CSS, SASS, AJAX, response layouts, etc. and
not to mention the issues around browser compatibility which is a real
pain.

So if you think about doing a new server-manager from scratch, think again.
And then we have not even started on the design of the app architecture so
we know what we are aiming for, how it all fits together, and how it can be
easily maintained and extended with plugins, API documentation for plugin
developers, etc.

For these reasons alone, developing a new server-manager from scratch is
complete madness.

I dare the proponents of Mojo to show us a real non trivial app that they
actually developed and honestly report on the time/effort it took them and
the rest of the team to get started and actually develop such an app from
start to finish.

And even then, if we simply look at the modern time were we find ourselves,
mixed environments is the thing. Even MS supports Linux based boxes in
there Azure environments.

This is where a solution as cockpit or like cockpit comes into its strength
as it allows integration and use of SME in such mixed environments in a
consistent and integrated manner. And mostly also because there is already
a whole active community already working on all the REST, HTML, CSS, SASS,
AJAX, response layouts, etc. stuff to make cockpit work.

Lets get out of this 'no' saying, forget about doing something from scratch
and start looking for opportunities and ways to leverage cockpit where we
can while we focus on the core of what is right about SME.

Keep it simple and don't reinvent the wheel.

Cheers,

Marco

Hear, Hear!

Post by Stefano Zamboni
well, with your experience and considering our (community) manpower,
you can just make a guess
We're just talking about ideas, nothing is defined yet, so no, I can't
estimate anything atm. Having a minimal POC running is probably a matter
of a few hours, which I'll try to find ASAP.
well.. a POC of what? of the new framework with a usable panel? really? :-)
cool
I guess that you are referring to a POC with mojo to demonstrate that
things can be done.. no doubt about it..
but, as you said, the way is to have an homemade framework.. we can't
make a comparison..
I created panels that work inside a framework using its features, you
won't, IIUC
programming with cockpit "just" need js/jquery/json/nodejs skills,
which are "a bit" more common nowadays than perl's one.. aren't they?
Well, maybe. I'm not even sure. I mean, here, in this community, who has
those skills ? In fact, I don't see in which situation someone would
only write a panel without anything else on the server-side (so perl
skills will always be needed).
touchÚ..
let's say I want to announce "out there" something like
"hi there.. we're starting developing some modules for cockpit to create
a new server manager for SME, are you interested?" on our forums (but not
only)
do you think that announcing something like "hi there.. we're starting
to develop a framework with mojo to be able, in the future, to create the
new server manager for SME, are you interested?" will have the same appeal?
don't you think that maybe many of our users just use SME as a web server
to serve or just develop web app? and that many of them maybe are using
jquery, angularjs and so on?
ands what about people using nodejs? cockpit uses some libraries from
node.. there's no node instance, anyway.
we need perl skills, sure.. if we just concentrate them into the core, to
have modern api to be used from anykind of web app capable of using
json/rest, we're done.. we'd have 10 different kind of S-M, people could
create and sell customized solutions
no.. we want to create our own toy in our backyard.. in 2016.. with
everybody out there just sharing code and ideas and projects on github, we
want something homemade, stored on our CVS
to really work on cockpit and C7 we need base and lib rpm.. meaning
that once I can call a signal event, read a db, write on it, the logic
is ready
Ok, it'll be ready. Ready to wait for the rest of the system to be
ready. Something working on SME9 would mean it could be used sooner,
have more feedback, show more active development.
ok..
<premise>
as I said, english is not my language, so I apologize since now if in the
next lines I could sound harsh or rude or impolite.. I'll try to do my best
to avoid it, but I can't promise that I will succeed
no personal attack, no flame, no offence, I promise
I'd add also that diplomacy is not on my chords, even if in the past
here, via private emails or just on the forums I acted as a peace maker.
</premise>
some things here (in this community) are not clear to me and this distro
is just laying (dying ?)
- this ML is almost dead for 99% of the time (archives are out there
there).. it sounds to me like that *there's no* active development and the
only activity is aimed to bug fixing.. this makes SME just laying and makes
people leave (no interests, no enthusiasm, no fun)
- to make something move it's necessary, how I'm used to say, to "drop a
bomb".. it happened when Filippo told us about NS fork, it's happening now,
again.. and this is happening *not* since I wrote my first email "*SME
on centos7 - let's start playing*" (almost ignored), but since I just
wrote about my playing with cockpit.. from that moment, this ML has become
a beehive.. isn't it? there was a sudden acceleration toward C7
- our product is a rock solid one
- our server manager, in a single word definition, sucks
- people are leaving us: users (going to other products that maybe offer
the same features but with a more modern eye catching interface) and
developers.. those are leaving because of our being stuck on formagik and
the objective difficulty to work in an environment where new ideas are
simply.. chocked.. for example, the code to add dummy interface capability
just to make SME available on VPS (real world usage, nowadays) took more
than 2 years to be accepted (see #7200)
- the need of a new, modern UI, was stated with #6821, more than 3 years
ago.. since then, *not* a single line of code has been written.. ask
yourself why and give yourself an answer (hint: formagick is a PITA)
since then, *not* a single line of code.. since now..
- we need to involve more people: investors and developers.. the first
must be abstracted by the opportunity of have a investment return, the
latter with something that is, simply, interesting.
and in this case money is not to make us rich persons, but just to pay
the bills and (but this is simply fantasy dreams) pay the coders.
- we need to improve our products to give answers to people demanding for
features nowadays not negligible, like Samba4 and AD interaction, multiwan
and so on
the items above are, simply, facts.. you (and everybody else, of course)
can obviously confute them, and you'll be welcome.. but in (not only) mine
opinion, they are *facts*.
now.. I'm a board member, just like you Dani.. the board is in charge for
(citing from the costitution act)
"*To this end, the corporation shall foster the creation, distribution,
and maintenance of a free integrated, all-in-one server operating system
with bundled applications designed for homes, small businesses, medium-size
businesses, and non-profit organizations, and it will be licensed under the
GNU General Public License. The server operating system will be focused on
simplicity, stability and security, designed to be operated by people with
no technical background, while providing a platform for technical users to
extend.*"
and I'm seriously convinced that we must take decisions.. we can't simply
wait and see what happens, because I see this product is sinking and no one
seems to be really interested in moving forward.. maybe I'm wrong, but (*my
personal opinion*) there are some interests in keeping the status quo i.e.
moving de facto all our packages to C7 and keep everything just how is it
now.
what about mojo? I have no doubts, *no one*, that it's a good product,
rock solid and so on.. but we need to find something usable by a wider base
of coders..
in the past Charlie (but not only him) said NO many times to the idea of
converting our S-M to php.. all of us agreed, sure.. but the FACT is that
we're still using the same S-M we had in SME 6.. if not exactly the same,
done with the same approach.
question (and I beg your pardon, but I pretend an answer): why mojo
become so interesting *now*? why are there people writing code and POCs
using it *now* if till 10 days ago almost no one was interested in it? why?
why the cockpit proposal was so scaring?
when Filippo told us about their fork, many argumentations were "oh,
dear, why did you change qmail with postfix?", "why did you choose php for
the web UI? I won't use it"..
the relevant *fact* is that they *did* something.. we're still here, still.
if you or anybody else is really convinced and sure that mojo is the way
to go, well, show me/us, here (devinfo ML and bugzilla) that it is really
easy to use, that permits to have result in a reasonable amount of time and
that it's interesting.. something that will abtract developers' curiosity.
we (the board) needs *facts*.
there are people that are interested in SME developing, infact we have
hundreds of custom values in our dbs, but almost *no one* (except, maybe,
Steph) worked on web interface to make them visible because creating a web
page now is not trivial and will just make our S-M more unusable.. and just
thinking to add some features (the password expiration panel, for example)
to the core pages sounds absurd because of the approach often found here
and in bugzilla.. using the smeserver-password contrib as an example, I was
told "*no, it won't be in the core since we non't need to set password
expiration here in $whatever_country*".. well, here (italy) we must, and
password's expitation policy is a good thing, aimed to security.. so, why
not?
the *fact* is that everytime someone propose a change, the first answer
is "no", often with *no reason*, followed by months of silence.
we have a Space Shuttle (
http://apod.nasa.gov/apod/image/1204/EndeavourFlightDeck_cooper_960.jpg)
in our hands but with the cockpit of a piper (
<http://www.redlandsflyingclub.org/RFC_files/050625-5-Cockpit-lr.jpg>
http://www.redlandsflyingclub.org/RFC_files/050625-5-Cockpit-lr.jpg)..
just compare the images..
SME's perl core is a rock, and *no one* is asking for something
different.. it just needs some improvements to be available in another way
from another tool like cockpit..
cockpit: I personally started to play with it last saturday, 10 days ago,
in a cafeteria, at Fosdem. *I never saw it before*.. in 15 mins I
branded it, in 3 hours I created my first trivial plugin that gets values
from a SME's db, shows them and saves them.. just using the db command.. it
tooks me more time just to have a working environment.
but since I start talking about it... wowowowowow!!! I see now that "mojo
is the way", "cockpit is unsecure".. and other things that make me think
that the reasons not to move on are not technical but political..
the funny thing is that we offer SME to te people saying "why would you
start from a bare minimal centos setup and become crazy to install, config
and make all the things you need just work in a secure and easy manner?
just use SME.. easy, reliable, fast, secure"..
and now you (generally speaking) are telling me that instead of start
working/collaborating on an existing framework integrated with the OS we'd
start to create something from ground zero reinventing the wheel..
now, if mojo is the way to go, I expect that somebody will tell me/us
exactly *why*, with an argumented answer and with *facts*.. and if so, I
will expect an argumented list of reasons why we can't/should not move to
cockpit too.
no, I'm saying that if we need 2 years to have the new interface,
we're already dead..
What did I say last time about being dramatic ? ;-)
Dani.. if we're talking about phylosophy, no problem at all.
we are on the board, we must give directions, take decisions.. and in
this perspective, 2 years is a sucide
please, stop thinking like a sysadmin ad start thinking in a business
perspective, thank you
cockipt has a community.. if there's a bug (a security one) we can
just raise a bug there, concentrating ourselves to other things.
I'm not too worried about bugs (although, cockpit core being in C,
fixing bugs will be harder). I'm worried about the whole design, I'm not
sure it'll be any easier for us to work with.
well.. first of all, maybe it is not perfect, but it is just real and in
active development
comparing a *real* thing with just ideas (our framework) doesn't make
sense to me
well.. first of all if you think that there's a security bug, just
test it, demonstrate and let's open an issue there..
The problem here is the design: we either can't have a user portal, or
we're exposed to security issues. I'm not sure which one is true (the
documentation is lacking), but unless I missed something, it's one or
the other. Or maybe you can tell me: how an unprivileged user could
modify only some of its own props in the account DB without being able
to modify the others ? I see no other way than rewritting the db command
to check for permissions. Which will be complex. And require perl
skills. And time. So no, cockpit most likely won't be a solution we can
use as-is.
again (maybe my english is faulty): we have few resources but skilled in
- porting everything to C7
- creating from 0 a new framework, test is, document it, debug it
- creating the new S-M
they should just concentrate theirselves on porting and enhancing our core
you're still thinking in how things work now
Of course I am, because, unless we're talking about rewritting
everything, things are going to work more or less the same way they do
now won't they ?
well.. take a look at my user panel for cockpit and compare it with the
relevant part of code needed now to just publish the user table..
do you think they are the same? do you think that the needed effort is
the same?
one dimension you are "just" forgetting is *time*
I don't think I forgot anything. I'm too well aware that we lack
manpower. But doing things in a hurry because it seems to be fatser is
not always a good solution. The time gained at some point can be lost at
some other because of design issues. IMHO, we should start a wiki page
where we list the features and goal we want to achieve.
this sounds reasonable
if we need 3 years to have something cool, secure, ours, well.. we
just trying a new way to commercially suicide ourselves.
(too dramatic)
And that's an argument against using cockpit. If you want to go with
cockpit, it won't be ready before SME10 is, that's a fact. SME10 will
take a lot of time and effort to be ready (and is another project, not
directly related to the new S-M)
SME10 must be released with the new interface.. from a business
perspective, anything different is just, again, shooting on our feet.
there are people that sells services based on SME.. will they have to
wait 3 years to have SME10? don't you think that if it will be the
case, they just start to see if there's something to migrate to? can
we afford the loosing of coders, users, interest? I don't think so
The time it'll take to have SME10 ready is unrelated to the new S-M
effort. I even think designing and writting the new S-M is a small task
compared to having SME10 finalized.
ok.. so, please, don't waste your time on S-M and just concentrate
yourself on the other issues :-)
people that want to integrate SME into a lan where there are windows
servers *can't* do it (well.. they can.. they only have to replicate
all users on both sides.. scaring and just absurd in 2016)
I have no problem joining latest Windows servers to the good old NT4
domain controller. I don't have to replicate anything. But that's
unrelated to this discussion.
the fact that you don't personally need AD is unrelevant..
times where I can go to a customer and say him "ok, I'll install you a
SME that will take care of everything" are gone..
now I go to customers that have windows servers with AD and they need
some features they can't simply afford (money) or they don't want to be M$
made (exchange anybody?).. I can't go there and tell "ok.. we have 2
options.. A) remove your server and use SME for everything B) install SME
and replicate all the settings on both sides", because it is simply
impossible..
For example, a feature NS has and is very usefull is AD integration: I
can join NS to an AD domain and offer services to the users.
Samba4 and AD and other features are a must.
once I finished my POC with cockpit, I'll start to work on S4.. I kindly
ask everybody, since now, to not start saying "oh, dear, S4 is a PITA,
uneeded, I don't need it, M$ is crap" and so on
here I talking not as a developer or as a sysadmin, here I'm talking as a
board member.
And I'm keeping the discussion here to have *technical facts and answers*
features offered by SME nowadays can be found on appliances like nas you
take from the shelves in the local store..
we had some plus in the past comparing with our competitors, now we have
not.
@HSF, would you mind to create a wiki page about features? TIA
S.
_______________________________________________
Server Development Discussion
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

--
Marco Hess
Through IP Pty. Ltd. - AUSTRALIA
p: [phone] | f: [phone]

[Hsing-Foo Wang]

Well said, good discussion.

And even then, if we simply look at the modern time were we find ourselves, mixed environments is the thing. Even MS supports Linux based boxes in there Azure environments.

This is where a solution as cockpit or like cockpit comes into its strength as it allows integration and use of SME in such mixed environments in a consistent and integrated manner. And mostly also because there is already a whole active community already working on all the REST, HTML, CSS, SASS, AJAX, response layouts, etc. stuff to make cockpit work.

Lets get out of this 'no' saying, forget about doing something from scratch and start looking for opportunities and ways to leverage cockpit where we can while we focus on the core of what is right about SME.

Keep it simple and don't reinvent the wheel.

Cheers,

Marco

[Daniel Berteaud]

Post by Marco Hess
I dare the proponents of Mojo to show us a real non trivial app that
they actually developed

I've written https://vroom.im using Mojolicious
(https://github.com/dani/vroom if you want the sources). Mostly a POC,
so not very polished (also 'cause I'm not a JS/CSS/HTML guy).
I've also written a more complete portal to manage remote PBX
administration (unfortunately I can't publish the sources for this one).

Post by Marco Hess
and honestly report on the time/effort it took them and the rest of
the team

I can't compare. Mojo made it easy and pleasant to write, but that's
subjective.

Post by Marco Hess
And even then, if we simply look at the modern time were we find
ourselves, mixed environments is the thing. Even MS supports Linux
based boxes in there Azure environments.

I don't see how this is related to our discussion, which is about
selecting the components, and designing a new/improved S-M

Post by Marco Hess
This is where a solution as cockpit or like cockpit comes into its
strength as it allows integration and use of SME in such mixed
environments in a consistent and integrated manner. And mostly also
because there is already a whole active community already working on
all the REST, HTML, CSS, SASS, AJAX, response layouts, etc. stuff to
make cockpit work.

Cockpit has an active community, and that's undoubtedly a very good
point. Is it enough to jump and rewrite everything yet ? I don't think so.

Post by Marco Hess
Lets get out of this 'no' saying,

I've already said I wasn't strongly against the cockpit approach. I have
just pointed issues with it (which BTW have been ignored). What I'm
strongly against is choosing a solution without studying other
possibilities.

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Daniel Berteaud]

Ok, I'll try to respond to some of your questions :-)

Post by Stefano Zamboni
don't you think that maybe many of our users just use SME as a web
server to serve or just develop web app? and that many of them maybe
are using jquery, angularjs and so on?

Maybe that's the case. I don't know. I don't know either if those will
help with the new S-M. I don't think you know either.

Post by Stefano Zamboni
- to make something move it's necessary, how I'm used to say, to "drop
a bomb"..

Yes, and I'm thankful you've started this discussion.

Post by Stefano Zamboni
- people are leaving us: users (going to other products that maybe
offer the same features but with a more modern eye catching interface)
and developers.. those are leaving because of our being stuck on formagik

Formmagick is not ideal, but saying it's because of it people are
leaving....I wouldn't go that far.

Post by Stefano Zamboni
for example, the code to add dummy interface capability just to make
SME available on VPS (real world usage, nowadays) took more than 2
years to be accepted (see #7200)

The problem is not to accept the feature. It's the time it took for a
dev to look at the proposal, enhance it, push the changes etc... It has
nothing to do with rejecting new ideas. We just can't integrate any code
without some review, and we're not enough doing this.

Post by Stefano Zamboni
- the need of a new, modern UI, was stated with #6821, more than 3
years ago.. since then, *not* a single line of code has been written..
ask yourself why and give yourself an answer

Lack of developers ready to spend time on this

Post by Stefano Zamboni
- the proposal of using mojo was made more than 2 years ago (see
#7819): since then, *not* a single line of code.. since now..

That's on my plate for a long time, but I've been busy with a lot of
other stuff, including moving the whole Koozali infrastructure, building
new ISO, fixing bugs (which is less exciting as working on a new
projects, but has to be done too).

Post by Stefano Zamboni
- we need to improve our products to give answers to people demanding
for features nowadays not negligible, like Samba4 and AD interaction,
multiwan and so on

This is OT for the new S-M.

Post by Stefano Zamboni
no one seems to be really interested in moving forward.. maybe I'm wrong,

Clearly you're wrong. This would imply saying all the time I spend on
SME (which is something around 50 hours of my spare time per month,
sometimes much more) means nothing. And that's just for me, others are
spending a lot of time and energy too.

Post by Stefano Zamboni
but (*my personal opinion*) there are some interests in keeping the
status quo i.e. moving de facto all our packages to C7 and keep
everything just how is it now.

No, there's no particular interest, but it's how things must be done. We
first rebuild everything against el7, then see where things break, and
fix accordingly. New features (like the new new S-M we're talking about)
should not be linked to this.

Post by Stefano Zamboni
why mojo become so interesting *now*? why are there people writing
code and POCs using it *now* if till 10 days ago almost no one was
interested in it? why?

It's no more (nor less) interesting than it was 3 years ago when Charlie
proposed it. You just kicked our asses :-)

Post by Stefano Zamboni
why the cockpit proposal was so scaring?

Already explained several time the issues I see with it. To summarize

- It's limited to el7, while I really think it'd be better to start
working on sme9
- It's written in C, which will make bug fixing harder if we found some
- It seems strange to be able to exec arbitrary commands from a web
client. For me, it's an important security concern
- As the logic of cockpit is to exec arbitrary commands as the user
logged in, it'll be harder to have a user portal: only root can alter
our various DB. This means we'll have to write code to handle it. The
amount of code it'll need is unknown yet. Just to say, it can't be used
"as is", it's not the magic solution which will require almost no work.
There's also the problem of users without a shell.

Those are just a few issues I saw without going too deeply. It doesn't
mean we won't be able to work with it, but we can't dismiss it either.
There are probably other problems hidden.

Post by Stefano Zamboni
we have a Space Shuttle
(http://apod.nasa.gov/apod/image/1204/EndeavourFlightDeck_cooper_960.jpg)
in our hands but with the cockpit of a piper
(http://www.redlandsflyingclub.org/RFC_files/050625-5-Cockpit-lr.jpg).. just
compare the images..

Indeed, one seems *much* easier to use than the other ;-)

Post by Stefano Zamboni
I see now that "mojo is the way", "cockpit is unsecure".. and other
things that make me think that the reasons not to move on are not
technical but political..

You don't know me enough in that case. I don't give a %*$&# about
politic. I'm only interested in technical. That's exactly why I've
pointed *technical* problems I saw. It would be a huge mistake on my
part not to point technical concerns as soon as possible.

Post by Stefano Zamboni
we are on the board, we must give directions, take decisions.. and in
this perspective, 2 years is a sucide
please, stop thinking like a sysadmin ad start thinking in a business
perspective, thank you

No, this is for the board list. Here, we're on the dev info list, so I
put my sysadmin hat on, and I only look at the technical aspects of the
problem.

Post by Stefano Zamboni
SME10 must be released with the new interface.

No argument against this. I just think it'd be better if we can start
developing the new interface on SME9, which is already here. It'll be
ready for SME10 at the same time.

Post by Stefano Zamboni
ok.. so, please, don't waste your time on S-M and just concentrate
yourself on the other issues :-)

As one of the main maintainers of the distro, as well as the author of a
lot of contribs, I think I'd rather participate in the new S-M
conversations.


I hope I've answered your questions.

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Stefano Zamboni]

Post by Daniel Berteaud
Ok, I'll try to respond to some of your questions :-)

Thank you Dani :-)

Post by Daniel Berteaud
Maybe that's the case. I don't know. I don't know either if those will
help with the new S-M. I don't think you know either.

well.. we ever know until we ask publicly..

Post by Daniel Berteaud

Post by Stefano Zamboni
- to make something move it's necessary, how I'm used to say, to "drop
a bomb"..

Yes, and I'm thankful you've started this discussion.

:-)
I admit: you made me smile :-D
thank you..

Post by Daniel Berteaud
Formmagick is not ideal, but saying it's because of it people are
leaving....I wouldn't go that far.

well, formagick is just one part of the problem

Post by Daniel Berteaud
The problem is not to accept the feature. It's the time it took for a
dev to look at the proposal, enhance it, push the changes etc... It has
nothing to do with rejecting new ideas. We just can't integrate any code
without some review, and we're not enough doing this.

alt.. this is true, but not the truth.. #7200 is just an example of
needed features being "blocked" for a long time and with debating, at
least without any declared and clear reason

Post by Daniel Berteaud
Lack of developers ready to spend time on this

maybe because trying to edit pur S-M is just a nightmare?

Post by Daniel Berteaud

Post by Stefano Zamboni
- the proposal of using mojo was made more than 2 years ago (see
#7819): since then, *not* a single line of code.. since now..

That's on my plate for a long time, but I've been busy with a lot of
other stuff, including moving the whole Koozali infrastructure, building
new ISO, fixing bugs (which is less exciting as working on a new
projects, but has to be done too).

Dani: you're not the only one that proposed/sustained mojo.. we haven't
seen a single line of code for years..
not a POC, not an example, not a "hei, guys.. time to start with mojo,
isn't it?"

Post by Daniel Berteaud

Post by Stefano Zamboni
- we need to improve our products to give answers to people demanding
for features nowadays not negligible, like Samba4 and AD interaction,
multiwan and so on

This is OT for the new S-M.

this is unrelated to S-M but strictly related to the approach and
attitude we often feel here..

Post by Daniel Berteaud

Post by Stefano Zamboni
no one seems to be really interested in moving forward.. maybe I'm wrong,

Clearly you're wrong. This would imply saying all the time I spend on
SME (which is something around 50 hours of my spare time per month,
sometimes much more) means nothing. And that's just for me, others are
spending a lot of time and energy too.

don't feel under the judgement.. your work here is under everyone's eyes
and *no one* can say you aren't working for SME
and "moving forward" is not related to moving to the last O.S.

Post by Daniel Berteaud

Post by Stefano Zamboni
but (*my personal opinion*) there are some interests in keeping the
status quo i.e. moving de facto all our packages to C7 and keep
everything just how is it now.

No, there's no particular interest, but it's how things must be done. We
first rebuild everything against el7, then see where things break, and
fix accordingly. New features (like the new new S-M we're talking about)
should not be linked to this.

again, if we just start from the idea that the S-M must be redone, we
have "just" to move to C7 everything that is not related to actual S-M..
meaning that once the smeserver-X package is available for C7, all the
relevant web content can be ignored.. the only thing to save is the
code.. the logic inside.. we don't have to care if that page will work,
it's just a waste of time

Post by Daniel Berteaud

Post by Stefano Zamboni
why mojo become so interesting *now*? why are there people writing
code and POCs using it *now* if till 10 days ago almost no one was
interested in it? why?

It's no more (nor less) interesting than it was 3 years ago when Charlie
proposed it. You just kicked our asses :-)

does it sounds absurd to me only? :-)
in 3 years no interest.. even from whom proposed it.. it it clear that
the argument is not interesting itself, also because, in this time, no
one else just asked or started playing.
interestingly (does this word even exists..?) my work on cockpit has
been followed and found interesting from many people (even if they don't
write here...)

Post by Daniel Berteaud

Post by Stefano Zamboni
why the cockpit proposal was so scaring?

Already explained several time the issues I see with it. To summarize
- It's limited to el7, while I really think it'd be better to start
working on sme9

you are right..
we'd start to convert all our logic in a webservice that listen on
localhost and can execute only a few of commands: db set/get/delete..
this can be done starting from SME 9 and this must be done in any case
(mojo or not).
the idea is to have the possibility to create a S-M with any
language/framework/technology capable of interact with a webservice..
tomorrow, someone could just wake up, install mono libraries on SME and
create his own S-M in asp.net
this is the way, mojo or not.. because if we bound ourselves to
something like formagick we are simply mad.

Post by Daniel Berteaud
- It's written in C, which will make bug fixing harder if we found some

if we found a bug, we can report there and someone will take care of fix
it.. moreover, the more we use it (and the world use it), the best it
will be..

Post by Daniel Berteaud
- It seems strange to be able to exec arbitrary commands from a web
client. For me, it's an important security concern

ok, this point is clear to me.. if we don't use the cockpit.spawn
feature but the cockpit.http one and we just make calls to a webservice
running on localhost, we surely lock the thing, aren't we?
just consider that you need to edit the cose of the page to execute a
command.. if you are able to do so, you're just a poweruser, maybe
root.. if I were an attacker, once I have the privileges I won't spend a
second to deal with cockpit..

Post by Daniel Berteaud
- As the logic of cockpit is to exec arbitrary commands as the user
logged in, it'll be harder to have a user portal: only root can alter
our various DB.

I thought about it.
first of all, you can restrict login to a group of users
(http://cockpit-project.org/guide/latest/cockpit.conf.5.html)
then we could play with sudoers file.. which is templated
finally, we can play with symbolic links, giving access to users just
what we want/prefer

maybe it's not perfect, but it is a start.. and I'm quite sure that in
the future the delegation will be available on cockpit too as a native
feature

Post by Daniel Berteaud
This means we'll have to write code to handle it. The
amount of code it'll need is unknown yet. Just to say, it can't be used
"as is", it's not the magic solution which will require almost no work.
There's also the problem of users without a shell.

*no one* told that cockpit is a 0 effort tool, never.. but it permits to
concentrate the few resources we have on some topics and leave the work
of generating pages to other people, less skilled and, let me say, more
enthusiastic
regarding the nologin users, I posted the link to my question on
cockpit's issue manager

Post by Daniel Berteaud
Those are just a few issues I saw without going too deeply. It doesn't
mean we won't be able to work with it, but we can't dismiss it either.
There are probably other problems hidden.

of course.. and just using it we could find and solve more of them..
we'd help cockpit's team to improve the product
the alternative is to recreate from 0 something that must be thought,
coded, tested, debugged.. and all of it just to have something to
start.. IMO the effort will be quite bigger, but I'd be wrong

Post by Daniel Berteaud

Post by Stefano Zamboni
we have a Space Shuttle
(http://apod.nasa.gov/apod/image/1204/EndeavourFlightDeck_cooper_960.jpg)
in our hands but with the cockpit of a piper
(http://www.redlandsflyingclub.org/RFC_files/050625-5-Cockpit-lr.jpg).. just
compare the images..

Indeed, one seems *much* easier to use than the other ;-)

yes, sure.. for a skilled user.. I usually don't use S-M or, just in
case, I use it from the shell, via elinks
but we need something to "sell" to the other guys.. and with our S-M we
have nothing to "sell"..

Post by Daniel Berteaud

Post by Stefano Zamboni
I see now that "mojo is the way", "cockpit is unsecure".. and other
things that make me think that the reasons not to move on are not
technical but political..

You don't know me enough in that case. I don't give a %*$&# about
politic. I'm only interested in technical. That's exactly why I've
pointed *technical* problems I saw. It would be a huge mistake on my
part not to point technical concerns as soon as possible.

ok, point taken..

Post by Daniel Berteaud

Post by Stefano Zamboni
we are on the board, we must give directions, take decisions.. and in
this perspective, 2 years is a sucide
please, stop thinking like a sysadmin ad start thinking in a business
perspective, thank you

No, this is for the board list. Here, we're on the dev info list, so I
put my sysadmin hat on, and I only look at the technical aspects of the
problem.

ok.. you're right.. we'd start discussing on board's ML too

Post by Daniel Berteaud

Post by Stefano Zamboni
SME10 must be released with the new interface.

No argument against this. I just think it'd be better if we can start
developing the new interface on SME9, which is already here. It'll be
ready for SME10 at the same time.

see above..

Post by Daniel Berteaud

Post by Stefano Zamboni
ok.. so, please, don't waste your time on S-M and just concentrate
yourself on the other issues :-)

As one of the main maintainers of the distro, as well as the author of a
lot of contribs, I think I'd rather participate in the new S-M
conversations.

:-)

Post by Daniel Berteaud
I hope I've answered your questions.

well, yes, you gave me your opinion, and that's important.. now I'll
wait for someone else opinion

ciao
S.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Marco Hess]

Suddenly things become awfully quiet (again) on this list.....

Is this discussion continuing on the 'board' list or did everybody run away?


_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

As Daniel said, things move if somebody start to kick asses..
It seems that if you just stop doing so, everything stops.
The first question I'm asking myself is "does it make any sense?"
The sad part is that I made some qurstions and, as always, nobody (but Dani) cares to give answers..
They told me that mojo is the way.. I really expect to see something in the near future.. if not, I will start kicking again and will look for support in the forums and elsewhere.

Post by Marco Hess
Suddenly things become awfully quiet (again) on this list.....
Is this discussion continuing on the 'board' list or did everybody run away?
_______________________________________________
Server Development Discussion
Searchable archive at
https://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

Post by Marco Hess
Is this discussion continuing on the 'board' list

ATM the board has not been directly involved, but will be in the near future.

[Stefano Zamboni]

Post by Daniel Berteaud
Are you saying that even user with no shell can run arbitrary commands
(under their own privilege of course) remotely ? That'd be a major
security issue.

just forgot to tell: my panel doesn't work for such user
S.

_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

Found it on rpmforge

Post by Stefano Zamboni

Post by Daniel Berteaud
Are you saying that even user with no shell can run arbitrary

commands

Post by Daniel Berteaud
(under their own privilege of course) remotely ? That'd be a major
security issue.

just forgot to tell: my panel doesn't work for such user
S.
_______________________________________________
Server Development Discussion
Searchable archive at
https://lists.contribs.org/mailman/public/devinfo/

[Jean-Paul Leclère]

can a poor man coder like me with near to 0 perl skills be part of the
game?

As I was in old time when I discovered e-smith... Only for this question
my response is definitively YES. Suggesting the opposite doesn't seem
simply real. I doubt anybody could be a reliable SME Web UI coder
without even understanding SME perl scripts.

But this discussion about a new Web UI is rewarding and meaningful...
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at h

[Stefano Zamboni]

Post by Jean-Paul Leclère

can a poor man coder like me with near to 0 perl skills be part of
the game?

As I was in old time when I discovered e-smith... Only for this
question my response is definitively YES. Suggesting the opposite
doesn't seem simply real. I doubt anybody could be a reliable SME Web
UI coder without even understanding SME perl scripts.
But this discussion about a new Web UI is rewarding and meaningful...

Hi Jean-Paul, nice to see you :-)

I know.. the first release of smeserver-password contrib was mine, and I
did it in 2 days.. but it was trivial and a simple copy and paste helped
me a lot.

but even acknowledging that a poor man can do it, I think that if we
something done in a good (and why not? quite fast) manner, we have to
use a tool that can be used by many, many people.. perl, IMO, is not.
and starting "now" (well, now...) to write our own framework to use it
to design our own S-M would be a wonderfull idea if we were dozens,
while we are less then ten.

Hope to see you more here ;-)
Ciao
S.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at

[Daniel Berteaud]

Post by Marco Hess
If a 'server-manager' interface is to be developed with 'mojo' (or any
of these frameworks) it is essentially a new 'web app' development
project from scratch.
Similar to how the original server manger was developed on the basis
of the FormMagick 'framework'.
This smells to me that we end up on our own to develop this for SME.
In the end this is something unique to SME and a lot of effort would
have to go in with creating such an 'app' and develop the 'plugin'
capabilities and API's needed.
Not to mention the ongoing maintenance.
'cockpit' on the other hand, is already a 'server-manager' in its own
right and had 'plug-in' capabilities. 'All we need to do' (famous last
words) is to hook the SME template handling into 'cockpit'.
Just based on 'gut feel' 'cockpit' seems a better way forward to me as
it is already an app with plugin capability and would provide an
ability to also leverage a number of existing features to
monitor/manage an SME server that we don't have to develop as well as
leveraging ongoing development in server management outside of SME
like Docker.

There's no (or almost no) difference. With cockpit, all the logic have
to be written in JS and is running on the client instead of being
written in perl and running on the server. But it's the same amount of
work. There're also downsides going the cockpit way:

- We're limited by cockpit itself, and it'll be harder to adapt it to
our need if something doesn't fit us in the core (as a lot is writtent in C)
- We need good JS coders. I don't know if any of us here is
- Nearly everything we need for the server-manager need to be written.
As you can see here:
http://cockpit-project.org/guide/latest/features.html there's not a lot
of feature in the core
- I have no idea how to theme it. The documentation is a bit light on
this part
- It's limited to EL7, can't be installed on EL6

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone] <tel:[phone]>
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Stefano Zamboni]

Post by Daniel Berteaud
There's no (or almost no) difference. With cockpit, all the logic have
to be written in JS and is running on the client instead of being
written in perl and running on the server. But it's the same amount of
- We're limited by cockpit itself, and it'll be harder to adapt it to
our need if something doesn't fit us in the core (as a lot is writtent in C)

we have our core, we'd "just" use it.. we'd just forget about DBUS and
the features that come bundled..
the main features/funtions we'd use are
- http://cockpit-project.org/guide/latest/cockpit-file.html
- http://cockpit-project.org/guide/latest/cockpit-http.html
- http://cockpit-project.org/guide/latest/cockpit-spawn.html

to interact with our core

Post by Daniel Berteaud
- We need good JS coders. I don't know if any of us here is

I gues it would be easier to find js coders than perl ones :-)

Post by Daniel Berteaud
- Nearly everything we need for the server-manager need to be written.
http://cockpit-project.org/guide/latest/features.html there's not a lot
of feature in the core
- I have no idea how to theme it. The documentation is a bit light on
this part

this is a question I'll post on cockpit's ML.. AFAICT in the plugins you
can use your own css (and other jquery modules), the login page can be
branded (you saw.. :-) ) but the main page seems to have all the css inline

Post by Daniel Berteaud
- It's limited to EL7, can't be installed on EL6

this is not an issue.. SME10 will be C7 based and will be a new
product.. we don't need to backport the new S-M

S.

Post by Daniel Berteaud
++
_______________________________________________
Server Development Discussion
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Daniel Berteaud]

Post by Stefano Zamboni
we have our core, we'd "just" use it.. we'd just forget about DBUS and
the features that come bundled..
the main features/funtions we'd use are
- http://cockpit-project.org/guide/latest/cockpit-file.html
- http://cockpit-project.org/guide/latest/cockpit-http.html
- http://cockpit-project.org/guide/latest/cockpit-spawn.html
to interact with our core

Cockpit itself probably have limitations (unless it's already perfect,
which I doubt). Maybe everything would fit our need, maybe not. One
thing is sure: if it needs modifications, it'll be harder.

Post by Stefano Zamboni
I gues it would be easier to find js coders than perl ones :-)

Well, unless nobody here knows JS, in which case nothing will ever be
written, and new JS coders won't come.

Post by Stefano Zamboni
this is not an issue.. SME10 will be C7 based and will be a new
product.. we don't need to backport the new S-M

I don't agree. This is an issue. We have no idea when SME10 will see the
light. Looking at the amount of people involved in the past few months
(not saying the past few days, where more people have been active), I
wouldn't bet on it before 3 or 4 years from now. SME9 exists now, and is
our main product until SME10 is ready. We should focuse on it.

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[John Crisp]

Post by Daniel Berteaud

Post by Stefano Zamboni
this is not an issue.. SME10 will be C7 based and will be a new
product.. we don't need to backport the new S-M

I don't agree. This is an issue. We have no idea when SME10 will see the
light. Looking at the amount of people involved in the past few months
(not saying the past few days, where more people have been active), I
wouldn't bet on it before 3 or 4 years from now. SME9 exists now, and is
our main product until SME10 is ready. We should focuse on it.

We need to look forward if we can.

RHEL 6 is basically EOL 30 Nov 2020 (and most people will be clamouring
for new stuff way before then)

So by my reckoning 4 1/2 years max.

If it takes 3 to 4 years from now we can't afford to wait a minute
longer, can we ?

And if we keep saying no, staring at our navels and looking back through
misty eyes to bygone days we won't don't stand a chance or will get
anywhere.

If we work on a new base with new technologies, maybe, just maybe, that
might attract some new blood.

Worth a try, unless you have a better idea ?
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Daniel Berteaud]

Post by John Crisp
We need to look forward if we can.
RHEL 6 is basically EOL 30 Nov 2020 (and most people will be clamouring
for new stuff way before then)
So by my reckoning 4 1/2 years max.
If it takes 3 to 4 years from now we can't afford to wait a minute
longer, can we ?

I'm not saying we shouldn't work on SME10. I'm saying that I'd prefer a
new server manager which work on SME9

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone] <tel:[phone]>
Visio : http://vroom.im/dani
/www.firewall-services.com/

[John Crisp]

Post by John Crisp

Post by John Crisp
We need to look forward if we can.
RHEL 6 is basically EOL 30 Nov 2020 (and most people will be

clamouring

Post by John Crisp
for new stuff way before then)
So by my reckoning 4 1/2 years max.
If it takes 3 to 4 years from now we can't afford to wait a minute
longer, can we ?

I'm not saying we shouldn't work on SME10. I'm saying that I'd prefer a
new server manager which work on SME9
++

Quite simply it is just not worth the effort IMHO.

A koozali makeover (which I am doing) is fine. And that's it.

[Daniel Berteaud]

Post by John Crisp
Quite simply it is just not worth the effort IMHO.

If we choose a framework working on SME9 (like Mojo), the effort will be
the same. It'll also work on SME10.

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[John Crisp]

Post by Daniel Berteaud

Post by John Crisp
Quite simply it is just not worth the effort IMHO.

If we choose a framework working on SME9 (like Mojo), the effort will be
the same. It'll also work on SME10.

Yup - it's the 'IF' that we are debating.

The decision needs to be what is the best for the future, period.

Forget what was in the past.

What would you build and what tools would you use if you had a clean
sheet of paper today ?

_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Daniel Berteaud]

Post by John Crisp

Post by Daniel Berteaud
If we choose a framework working on SME9 (like Mojo), the effort will be
the same. It'll also work on SME10.

Yup - it's the 'IF' that we are debating.
The decision needs to be what is the best for the future, period.

SME9 is part of our future for the next years isn't it ? I agree it must
not be the only criteria, but it must not be ignored either.

++
--
Logo FWS

*Daniel Berteaud*

FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Tel : [phone]
Visio : http://vroom.im/dani
/www.firewall-services.com/

[Dan Brown]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Maybe I've missed this distinction being made in this discussion, but
it seems like the discussion is conflating at least three distinct
issues with respect to the server-manager:

1. We need a way to make the (or a) server-manager work under CentOS
7, and the way we're currently doing it won't work directly.

1a. The framework currently being used is orphaned.

1b. The version of Perl shipped in CentOS 7 won't allow scripts to run
as they currently do.

2. Many configuration options, even ones that are "official" (i.e.,
they're documented in the docs at contribs.org, rather than only as
contribs) are not exposed through the server-manager, and can only be
controlled through the command line.

3. The appearance of the server-manager is dated and less attractive
than competing software.

I'm sure it's the case that a single solution could address more than
one of these issues, but they remain distinct issues.

I'm not a coder, beyond occasionally cobbling together trivial things
in bash or PHP, so I doubt I can offer any useful suggestion on how to
solve any of these three issues--but it seems that maintaining the
distinction is nonetheless useful.

- --
Dan Brown, KE6MKS, ***@familybrown.org
"Since all the world is but a story, it were well for thee to buy the
more enduring story rather than the story that is less enduring."
-- The Judgment of St. Colum Cille
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWsiHJAAoJEEXarOh3yckd1sUQAIoRC3lwJIhNijU9Cr03JWBg
DP8v1i6/nCHh3/sOZ54+HctqXojoaRrK6BHaaKIORQabAQ0iAPEIzdNjIu3QGdQb
goWXmo2NRrVpSbXBmixIPRjJ5xYK2qV/TmkpW4A3at2m5ALoyTZijdlFsotP43FJ
k6+V6xsXfXHVIyAorF5v5g+mKut9+0SBoTafSccfXvC6hrYQL/kxMEDnByJGx86d
poKKG2ky01Mn4Vy2x8R1Tx4mhVLUEev62UuhySnOiFyRj+Jx28dJwuIiOCP68jBk
fnSZ6tZP8cUqpoo1kXrnZvxcM7o4xQ1t6sCpUyBU++JHZfNn2f6D6bZxhhdCWf6k
VU/qOVAP78fgYTsf2a+aeaYg3nnwGSNUD7NVdi1U+8h+Sxs3mXjy3REKHRYGddv7
69g0VokxzME7w7xl533nathqo+hh4Ro0qdz77yyVd01PKrPxJg8TY42D1y/SJ6U6
OvhjBA/VjNo4/EPMtCs+HmstGZF+MtdMy2WgFH0iLFUlHuEs9Cgm85XJKAN/Ai/g
cxwsyXmAFA7VX/DbhvYNGHW9oJhtjCFbXhl88ylJqSYD5vdrSCdYeo1hAP/J+nA1
rXcN2jwQlpT5pBbEn5babyd1qnUlyuJQBr2fKZUk9KIoxtwJlK8hja//98EgU3Yb
hJ/syAdm1WuOoQfEVhKc
=apHd
-----END PGP SIGNATURE-----
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[John Crisp]

Post by John Crisp
What would you build and what tools would you use if you had a clean
sheet of paper today ?

Difficult question. Probably something which runs on smartphones, and
sells by the million. A game? On-line gambling app? Green home controller
app?
:-)

ROFLMAO.......

Keep taking the pills mate - they are working well :-)
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Jean-Philippe Pialasse]

Envoyé de mon iPad

Post by Daniel Berteaud

Post by John Crisp
We need to look forward if we can.
RHEL 6 is basically EOL 30 Nov 2020 (and most people will be clamouring
for new stuff way before then)
So by my reckoning 4 1/2 years max.
If it takes 3 to 4 years from now we can't afford to wait a minute
longer, can we ?

I'm not saying we shouldn't work on SME10. I'm saying that I'd prefer a
new server manager which work on SME9

I am more and more thinking that SME 10 and new manager are two distinct projects and we need to see them clearly as it.

Maybe the manager will come first, maybe SME 10. But honestly, they need to come before 4 years.

As pointed Charlie, the main blocker for perl is the setuid, and there are workarounds possible. Which mean the current manager could fit on SME 10. Which mean we can start building package and work on this.

At this stage the thinking of keeping our current db or using json is not a blocker for this. ( as json might be a choice for newer frameworks. ) it will still be possible to write a connector esmith/json, which would reduce rewriting of all contribs and all core at once.

Finally, we could also think of a period of dual manager this way. Leaving time to write new panels for contribs or create hooks when appropriate.

Now this leave the second elephant which framework /application / project to choose.

I am neither a perl coder nor a C or JS one. I learnt with PHP. I am able to do stuff with bash and perl pretty easily from this.

Looking at cockpit, it make me think to another great fedora community project we relied on. Do you remember SMOLT?

One day they stopped the project. We stopped having any more stats on our installation because we relied on an external new innovative project. What will happen for SME if cockpit cease ? Are there any C coder around in the team to patch it?

Sure C coders are even more easier to find than JS coders ;)

There are a lot of panels around: cpanel, webmin, ispconfig, centos webpanel, plesk.... Why not using them? Because it would be far more work to adapt, and we would be dependant on them if they change too much their system or cease.

I am not sure that mojolicious is the choice to do. But a project that recent, far from our skills like cockpit seems to be risky.


Here we have a list of real frameworks, to make an informed choice.



_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at h

[Stefano Zamboni]

Hi all

as I promised, now I have a working POC of C7 + cockpit interacting with
SME's command (db commands ATM, but I could call any other CLI)

I used NS base and lib rpms, already available for C7: they are slightly
different from SME's one, but for my POC it's not relevant.

How can I show what I did?

here are the steps to reproduce my environment:
- install a minimal C7, setting it's IP address as fixed
- enable epel C7 repo
- install nethserver-base and nethserver-lib rpms available here:
http://packages.nethserver.org/nethserver/7.2.1511/base/x86_64/Packages/
(thank you Filippo for sharing)
to install them some other packages are needed; someone are available
from base/epel repo, other from the link above

wget
http://packages.nethserver.org/nethserver/7.2.1511/base/x86_64/Packages/nethserver-base-2.9.5-1.49.gc8de4ac.ns7.noarch.rpm
wget
http://packages.nethserver.org/nethserver/7.2.1511/base/x86_64/Packages/nethserver-lib-2.1.5-1.4.gb88ffcd.ns7.noarch.rpm
wget
http://packages.nethserver.org/nethserver/7.2.1511/base/x86_64/Packages/perl-Crypt-Cracklib-1.7-1.ns7.x86_64.rpm
wget
http://packages.nethserver.org/nethserver/7.2.1511/base/x86_64/Packages/perl-I18N-AcceptLanguage-1.04-1.ns7.noarch.rpm
wget
http://packages.nethserver.org/nethserver/7.2.1511/base/x86_64/Packages/perl-Mail-RFC822-Address-0.3-1.ns7.noarch.rpm

enabling epel repo I installed nethserver-lib without any issue

nethserver-base needs a nethserver-yum package, so I installed it using
rpm -Uvh --nodeps command

at the end of the proces, there are our usual commands in /sbin/e-smith
dir, while db are in /var/lib/nethserver/db dir

to call usual db commands the full paths are needed, so

/sbin/e-smith/db /var/lib/nethserver/db/configuration show

will work as usual

as you cans see, db has some new features:

[***@sme10 ~]# /sbin/e-smith/db
usage:
/sbin/e-smith/db dbfile keys
/sbin/e-smith/db dbfile print [key]
/sbin/e-smith/db dbfile printjson [key]
/sbin/e-smith/db dbfile show [key]
/sbin/e-smith/db dbfile showjson [key]
/sbin/e-smith/db dbfile get key
/sbin/e-smith/db dbfile getjson [key]
/sbin/e-smith/db dbfile set key type [prop1 val1] [prop2 val2] ...
/sbin/e-smith/db dbfile setdefault key type [prop1 val1] [prop2
val2] ...
/sbin/e-smith/db dbfile delete key
/sbin/e-smith/db dbfile printtype [key]
/sbin/e-smith/db dbfile gettype key
/sbin/e-smith/db dbfile settype key type
/sbin/e-smith/db dbfile printprop key [prop1] [prop2] [prop3] ...
/sbin/e-smith/db dbfile getprop key prop
/sbin/e-smith/db dbfile setprop key prop1 val1 [prop2 val2] [prop3
val3] ...
/sbin/e-smith/db dbfile delprop key prop1 [prop2] [prop3] ...

once done that, I created a simple plugin starting from the example
available here:
http://stef.thewalter.net/creating-plugins-for-the-cockpit-user-interface.html
my plugin is an item in the "Tools" section of the menu.. it gets the ip
address and netmask from the configuration db and can set those values

all (the plugin) was made in about 30 mins.. no data validation,
obviously, but it was out of the scope of my POC

the plugin is available to root user only, since it is in
/root/.local/share/cockpit/ dir

now, is there anyone interested in it? how/where can I share the code?

TIA

S.

_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[stephane de Labrusse]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Stefano Zamboni
all (the plugin) was made in about 30 mins.. no data validation,
obviously, but it was out of the scope of my POC
the plugin is available to root user only, since it is in
/root/.local/share/cockpit/ dir
now, is there anyone interested in it? how/where can I share the code?

open a bug please and show the code and the rpm to install in an
attachment way, we will show it in a comfortable way please

- --

Cordialement

Stéphane de Labrusse
Membre de l'Aru2L http://www.aru2L.org
Membre de l'ApriL http://www.apriL.org


PORTABLE : 06 29 19 12 99
DOMICILE : 05 65 78 90 72
WEB : http://geekeries.de-labrusse.fr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlay8d4ACgkQ1CTfJUQAIe7JBACcCyqyoWYI4nsAE+yLpnmA7Em2
vLcAni7xJX59Hh5W63oPhxNGYqk1DRCj
=YvD8
-----END PGP SIGNATURE-----
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

Post by stephane de Labrusse
open a bug please and show the code and the rpm to install in an
attachment way, we will show it in a comfortable way please

there's no rpm ATM

will open a bug and post there my code and some instructions..

Thanks

S.

_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Stefano Zamboni]

Post by Stefano Zamboni
will open a bug and post there my code and some instructions..

done: https://bugs.contribs.org/show_bug.cgi?id=9208

S.
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Mark Phillips]

Here are a couple of comments from an interested noob, in hopes that it helps in some way.

Post by Daniel Berteaud
- We need good JS coders. I don't know if any of us here is

I have built several projects involving javascript. It has is its pros and cons. I am happy to help if js is needed and I know a fellow with good js skills who may be willing to chip in some time “on the weekends”.

Post by Daniel Berteaud
I am more and more thinking that SME 10 and new manager are two distinct projects and we need to see them clearly as it.

I agree that a rewrite of server manager is a non-trivial project that needs to be managed separately from SME 10.

Regards,

- Mark

[Terry Fage]

Post by Mark Phillips
Here are a couple of comments from an interested noob, in hopes that it helps in some way.

Welcome Mark, a huge welcome :-)

I think you may have just made a couple of people very happy :-)

TerryF
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/

[Daniel Berteaud]

Thanks for the followup. it's interesting. But it doesn't tell me what you
mean by "RT" or "almost in RT".
Do you mean "round trip"? If so, what does "almost in round trip" mean?

I understand this as "almost in real time", aka validation as you type (either validating for each new char typed in a field, or validating when the field is unfocused, instead of waiting for the whole form to be submitted)

++
--
Daniel Berteaud
FIREWALL-SERVICES SAS.
Société de Services en Logiciels Libres
Tel : [phone]
Visio: https://vroom.im/dani
Web : http://www.firewall-services.com


_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinf