On Mon, 2015-06-15 at 11:54 +1000, Steven Haigh wrote:
> On 15/06/2015 3:05 AM, David Sommerseth wrote:
> > On 14 June 2015 16:01:44 CEST, Steven Haigh <[log in to unmask]> 
> > wrote:
> > > On Sun, 14 Jun 2015 09:11:38 AM Steven Miano wrote:
> > > > In FC22 there is cockpit though, which does have a very nice 
> > > > WUI (Web
> > > User
> > > > Interface) for systemctl:
> > > > 
> > > > Here are a couple of screenshots for those features (cockpit 
> > > > has a
> > > > multitude of other great functionality as well though, 
> > > > including
> > > being able
> > > > to add additional hosts to any cockpit-ws).
> > > > 
> > > > Services (Target): http://i.imgur.com/TGkHHYf.png
> > > > 
> > > > Services (Target (abrt-ccpp.service): 
> > > > http://i.imgur.com/WhQaFPS.png
> > > 
> > > Its times like this that I question what the hell we are doing in
> > > computing. 
> > > We have a init system that is that complex, it has a web 
> > > interface (!)
> > > written 
> > > around it. What. The. Hell.
> > > 
> > > That is a complete web server, with toolstack, to help configure 
> > > simply
> > > 
> > > starting a computer.
> > > 
> > > Have we lost the plot with regards to OS concepts these days?
> > 
> > 
> > Okay, I'll bite.
> > 
> > That's also an angle to see this. I rather choose to see cockpit as 
> > a completely different project solving issues this project have 
> > considered worth solving. And it is possible through systemd's dbus 
> > API.  Cockpit is basically just an web interface for dbus.  It 
> > doesn't do anything else than to do dbus calls.
> > 
> > And I consider that impressive. Why?  Because if you don't like 
> > systemctl or Cockpit, you can write your own tools using the same 
> > dbus API. And the bonus is that it (in theory at least) should work 
> > out of the box on any systemd based distribution without any 
> > changes.  You can write your own management tools simplifying 
> > processes unique to your environment.
> > 
> > Cockpit is a pretty good demonstration of the powers of systemd, 
> > which also through the dbus API ensures operations a user requests 
> > are authorized properly.  A user lacking privileges will not be 
> > able to perform the requested operations.
> > 
> > So feel free to rant about the complexity of systemd. After having 
> > played around with systemd in a few of Fedora releases, SL7 and 
> > RHEL7, I cannot agree that systemd is such a complex beast, not in 
> > any way.  It is not worse than than upstart nor the older sysv init 
> > scripts. I honestly think that these anti-systemd rants are pure 
> > trash from people who have no interest in seeing that there are 
> > parts of the Linux universe which are in desperate need for 
> > improvements: System Management.  And if systemd+cockpit can in a 
> > longer run make Linux systems more understandable for old school 
> > Windows-admins, then just that is a big win in my opinion.
> > 
> > Another point of view: Ditching sysv init isn't a new thing. 
> > Upstart is another approach which is in SL6 and RHEL6.  In other 
> > OSes, Solaris went for SMF, Mac OSX chose launchd.  Sysv init 
> > worked wonderfully in the 70s, 80s and most of 90s, because the 
> > server needs where quite different back then. Nowadays systems live 
> > in a far more dynamic environments than earlier. And new challenges 
> > needs solutions appropriate to these new demands.  Otherwise we 
> > would still on a daily basis drive around in T-Fords.
> 
> I think you're moving the goal posts with the reply.
> 
> We have a web interface that configures the boot process. 

I'll start out by saying that, if you think that Cockpit is the same as
Webmin, you would be right to not want it near your server.

Saying that Cockpit is an interface that configures the boot process is
a limited (and maybe even incorrect) view of the project, though.

Here are the principles that they've used in designing Cockpit:

http://stef.thewalter.net/ideals-of-cockpit.html

They are worth a good look.

> We have
> projects like cups that have web interfaces to configure printers.
> Complexity and security wise, we're dumbing things down that much 
> that
> the trend is to have a web server + god knows what else running to
> configure fairly simple things.
> 
> Would you agree that webmin is a great system administration tool? If
> so, then you don't see the problem.
> There are tons of EL users that care more about security and audit
> ability of systems in place - and for some, that's a legal 
> requirement.
> 
> So, now we have to either:
> 1) Not change; or
> 2) Be able to audit each projects back end - including its own
> implementation of a web server, its tools and other bundled cruft.
> 
> This doesn't make life any easier for high-security systems - and 
> indeed
> adds more vectors for attack - which I'll admit - are mostly 
> theoretical
> until they are not.

The main person working on Cockpit is the same person who, for several
years, was the maintainer of GNOME Passwords and Keys (aka Seahorse)
and GNOME Keyring. GNOME Keyring is what manages SSH and PGP keys on
GNOME systems. I would think that someone who has that experience would
have good ideas as to what is important with regards to security.

Even if it is a secure, well-designed application, I think Cockpit is
designed so that you won't use it if you know what you're doing with a
server. So, it might not be right for your particular environment /
usage scenario. I don't think it deserves derision if it's not right
for your situation, though.

Jim