SCIENTIFIC-LINUX-USERS Archives

February 2015

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
David Sommerseth <[log in to unmask]>
Reply To:
David Sommerseth <[log in to unmask]>
Date:
Sun, 15 Feb 2015 13:11:52 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (105 lines)
> From: "Keith Lofstrom" <[log in to unmask]>
> To: "scientific-linux-users" <[log in to unmask]>
> Sent: 14. februar 2015 08:06:02
> Subject: Re: systemd (again)
>
> 3) Will systemd require Gnome 3/4/5/..N to manage properly?
> 4) Can systemd /var/log files (or equivalent) be logrotated?
>
> Systemd is Red Hat's brainfart.  Their user base is institutions,
> not consumer tablets.  If systemd cripples Red Hat customers,
> Red Hat will either fix the behavior, or go bankrupt and stop
> pushing it.  I will count on the last two correctives to keep
> systemd from becoming a worst-case nightmare. 

Before I got to know systemd better, I'd call it a brainfart too.
But I've learnt to know better over the last year.  Systemd is so
much more than a initd process and I've gotten to know it as a
tool which fills a gap which has been open too long in the Linux
world. Systemd can really fill the gap related to system
/management/.

Systemd does not depend on GNOME at all.  But systemd does make
massive use of dbus and PolicyKit.  Which may sound odd, but when
starting looking at projects like Cockpit [1], it demonstrates
the power of the dbus integration.

I was recently at devconf.cz where Cockpit was presented.  That
provides a really neat way of system management via a
web-browser and makes use of several systemd features.  It is
now shipped by default in Fedora 21, but I'd be surprised if it
won't run on EL7.  (I haven't had time to do some test builds yet)

Cockpit is not running by default, but if you go to
https://$IPADDRESS_OF_SERVER:9090/ systemd starts it
on-the-fly (through socket activation).  In the moment it's been
lingering idle for approx. 10 minutes, it is shut down again.
So there's basically zero-footprint when it is not being used.
This is one of the nice things about systemd.

The next thing is that all the authentication is done properly
against system accounts (even Kerberos authentication with
GSSAPI/SPNEGO will work out-of-the-box, even though they're
ironing out an improved IPA integration).  If you log into
Cockpit as a non-sysadmin, you can look around but not change
much at all.  If you log in as a sysadmin, you can change
hostname, join IPA domains, start/stop services, tackle Docker
containers, inspect the journal, etc. In the git version of
Cockpit there's even a web based terminal And all this is
possible only because of the dbus interface. In fact, it can
only interact with dbus and nothing else.

During the demonstration we got at devconf.cz, a very simple
add-on was added.  They realized they had forgotten to add a
"Change time zone" feature.  This was very little of HTML code
(approx one screen page, 20-30 lines of code or so).  Once
Cockpit was refreshed, it was available and changing the time
zone from the command line, instantly updated the web-interface.
Changing it in the web-interface was again happening instantly
on the system.  In fact, the web interface was a live view of
what was really happening on the system (looking at the journal
from Cockpit demonstrated that very nicely).

I recognise that a web-admin isn't what everyone wants or
need.  But it lowers the management barrier for those used to
a more graphical environment.  And even though I do consider
myself as a power user (I've used Linux since mid-90s) and
really like the command line, I can also see myself using
Cockpit to get a quick overview over what is going on on a
system.  And especially since you can from one Cockpit
interface manage other systemd systems with Cockpit too
(Cockpit uses SSH for remote controlling systems).

Regardless of if you want or need Cockpit, it is a good
demonstration of what is possible to do on an systemd enabled
system. The Cockpit maintainer said loud and clear that
Cockpit doesn't do any rocket science.  It builds on what is
already present on the system (dbus, PolicyKit, systemd) and
presents and interacts with that information in an easy-to-use
web interface.  So I believe systemd can open up for better
system management tools in the future; how they will be only
depends on the imagination of developers and users.

If in doubt, I recommend you to try it out on a Fedora 21
test box.  And once that is running, try to pull down the
latest Cockpit version from git and compile it. And you'll see
some nice enhancements.

And one last comment.  Systemd is probably one of the few
projects which will be able to unite system management across
Linux distributions.  Something I have felt has been needed
a long time.  And thus with projects like Cockpit, it will be
possible to build one tool which can manage several
distributions basically out-of-the-box.  Combine easy-of-use
with powerful tools, and suddenly pure Windows-admins might
not be that afraid of to start getting familiar with Linux
systems.

[1] <http://cockpit-project.org/>


--
kind regards,

David Sommerseth

ATOM RSS1 RSS2