Cockpit 121

[Stef Walter]

http://cockpit-project.org/blog/cockpit-121.html


Cockpit is the modern Linux admin interface. We release regularly. Here
are the release notes from version 121.


Network Configuration Rollback
------------------------------

NetworkManager now has support in its API for detecting whether a
network configuration change broke connectivity to the system. Marius
did work so that Cockpit can detect this and have NetworkManager
rollback the changes that would have caused a remote admin to be
disconnected from the system.

This is similar to how a Linux desktop asks you to click in a dialog
if you accept the new display configuration. Except in the networking
case we can test the connectivity automatically.

Demo: https://youtu.be/fNIaDl5UR4Q

Change: https://github.com/cockpit-project/cockpit/pull/5069


Debugging info for Javascript and CSS
-------------------------------------

Cockpit now ships proper Javascript and CSS debugging "map" files in its
cockpit-debuginfo packages. These make it easier to troubleshoot issues
and develop code that runs in Cockpit.

Change: https://github.com/cockpit-project/cockpit/pull/5191


Debian Branding
---------------

Cockpit now shows proper branding when running on Debian, and uses the
logo installed on the system on its login screen.

Screenshot: http://cockpit-project.org/blog/images/debian-branding.png

Change: https://github.com/cockpit-project/cockpit/pull/5240


Fix Kerberos single sign on Debian and Ubuntu
---------------------------------------------

Stef fixed Kerberos single sign on Debian and Ubuntu. More changes are
coming in the next release including support for use with gssproxy and
expanding support for non-Kerberos GSSAPI authentication mechanisms.

Change: https://github.com/cockpit-project/cockpit/pull/5227


Get it
------

You can get Cockpit here:

http://cockpit-project.org/running.html

Cockpit 121 is available in Fedora 25:

https://bodhi.fedoraproject.org/updates/cockpit-121-1.fc25

Or download the tarball here:

https://github.com/cockpit-project/cockpit/releases/tag/121


Take care,

Stef

[Simo Sorce]

On Fri, 2016-10-28 at 20:02 +0200, Stef Walter wrote:
>  This is similar to how a Linux desktop asks you to click in a dialog
>  if you accept the new display configuration. Except in the networking
>  case we can test the connectivity automatically. 
Although in many cases this is the case, it is not always the case, is
this under the control of the admin ?
(I just configured my new openwrt on my new router, my net config was
perfectly right, but the box was not connected to anything beyond my
administering client, which also switched between 2 networks at my
request).

Simo.
 
-- 
Simo Sorce * Red Hat, Inc * New York

[Stef Walter]

On 31.10.2016 13:27, Simo Sorce wrote:
>  On Fri, 2016-10-28 at 20:02 +0200, Stef Walter wrote:
> > This is similar to how a Linux desktop asks you to click in a dialog
> > if you accept the new display configuration. Except in the networking
> > case we can test the connectivity automatically.
>  
>  Although in many cases this is the case, it is not always the case, is
>  this under the control of the admin ? 
Yup. Try it out [0] ... or see the linked video [1]. You are asked
whether to 'Keep the Connection' or 'Change the settings' anyway.

Stef

[0] Fedora 25 + yum install --enablerepo=updates-testing cockpit

[1] https://www.youtube.com/watch?v=fNIaDl5UR4Q

[Stephen Gallagher]

On 10/31/2016 08:27 AM, Simo Sorce wrote:
>  On Fri, 2016-10-28 at 20:02 +0200, Stef Walter wrote:
> > This is similar to how a Linux desktop asks you to click in a dialog
> > if you accept the new display configuration. Except in the networking
> > case we can test the connectivity automatically.
>  
>  Although in many cases this is the case, it is not always the case, is
>  this under the control of the admin ?
>  (I just configured my new openwrt on my new router, my net config was
>  perfectly right, but the box was not connected to anything beyond my
>  administering client, which also switched between 2 networks at my
>  request). 
Well, I don't think this is any worse than the previous state. If you made the
same modification in Cockpit 120, the system would have just gone ahead and done
it and you would be out of luck.

In 121, if you make a change and it detects that you're now unreachable, it can
roll that back and give you another try.

So it sounds like a net win, even if it's imperfect.

[Simo Sorce]

On Mon, 2016-10-31 at 08:38 -0400, Stephen Gallagher wrote:
>  On 10/31/2016 08:27 AM, Simo Sorce wrote:
>  > On Fri, 2016-10-28 at 20:02 +0200, Stef Walter wrote:
>  >> This is similar to how a Linux desktop asks you to click in a dialog
>  >> if you accept the new display configuration. Except in the networking
>  >> case we can test the connectivity automatically.
>  > 
>  > Although in many cases this is the case, it is not always the case, is
>  > this under the control of the admin ?
>  > (I just configured my new openwrt on my new router, my net config was
>  > perfectly right, but the box was not connected to anything beyond my
>  > administering client, which also switched between 2 networks at my
>  > request).
>  
>  Well, I don't think this is any worse than the previous state. If you made the
>  same modification in Cockpit 120, the system would have just gone ahead and done
>  it and you would be out of luck. 
Well I think you misunderstand my concern.
My concern is for when I want the system to get the new configuration
*even if I lose connection/ the system can't verify the connection
works*

>  In 121, if you make a change and it detects that you're now
> unreachable, it can
>  roll that back and give you another try. 
This is the problem, as I was changing config I knew the final state,
but there had to be a time where the configuration would be "wrong"
until I could go and switch the cables around.

I can do the config change only before I switch around the cables, and
here will be a period of time when the conf will not work.

>  So it sounds like a net win, even if it's imperfect. 
I was only asking if I can force a change w/o additional confirmation.

Do I understand correctly, from the video, that cockpit will try to make
the change, if it fails to connect will restore back the initial
configuration and ask for confirmation, and if confirmed it will once
more apply the new config for good ?

That works for me, even though you end up switching back and forth twice
under the hood :)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Marius Vollmer]

Simo Sorce <simo(a)redhat.com&gt; writes:

>  Do I understand correctly, from the video, that cockpit will try to
>  make the change, if it fails to connect will restore back the initial
>  configuration and ask for confirmation, and if confirmed it will once
>  more apply the new config for good ? 
Yes, exactly.

>  That works for me, even though you end up switching back and forth
> twice
>  under the hood :) 
Yeah.  Can you see a way to avoid that?  Our assumption was that it's
pointless to try to predict upfront what changes will disconnect you.

[Simo Sorce]

On Mon, 2016-10-31 at 16:00 +0200, Marius Vollmer wrote:
>  Simo Sorce <simo(a)redhat.com&gt; writes:
>  
>  > Do I understand correctly, from the video, that cockpit will try to
>  > make the change, if it fails to connect will restore back the initial
>  > configuration and ask for confirmation, and if confirmed it will once
>  > more apply the new config for good ?
>  
>  Yes, exactly.
>  
>  > That works for me, even though you end up switching back and forth twice
>  > under the hood :)
>  
>  Yeah.  Can you see a way to avoid that?  Our assumption was that it's
>  pointless to try to predict upfront what changes will disconnect you. 
No way around, this is the only reasonable way.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York