cockpit-devel January 2019

cockpit-devel@lists.fedorahosted.org

7 participants
7 discussions

Cockpit 186
by Katerina Koukiou 24 Jan '19

24 Jan '19

Cockpit is the modern Linux admin interface. We release regularly. Here are the release notes from version 186: http://cockpit-project.org/blog/cockpit-186.html Summary: - Redesign the Service page - Make System Overview page mobile friendly You can get Cockpit here: http://cockpit-project.org/running.html Cockpit 186 is available in Fedora 29: https://bodhi.fedoraproject.org/updates/cockpit-186-1.fc29 Or download the tarball here: https://github.com/cockpit-project/cockpit/releases/tag/186 Regards, Katerina

1 0

Cockpit/Composer hackfest on Devconf.cz
by Martin Pitt 15 Jan '19

15 Jan '19

Hello all, like in the last years, we will have a hackfest for Cockpit and Composer at Devconf.cz again: https://devconfcz2019.sched.com/event/K8p1/cockpit-hackfest Sunday, January 27 14:30 - 15:15 It's rather short this time, so more like a meet & greet.. If you want some help with your own Cockpit UI, set up your own project [1], discuss some Cockpit or Composer improvement or your pet bug, or just say hello, please stop by! See you next week, The Cockpit team Martin Pitt [1] in that case, you may also be interested in "Your turn-key Cockpit UI in a CI/CD ecosystem" https://devconfcz2019.sched.com/event/Jccr/your-turn-key-cockpit-ui-in-a-ci… *shameless plug*

1 0

cockpit.spawn() - how to wait for finish?
by . 12 Jan '19

12 Jan '19

Hello, First of all: thank you very much for maintaining this great project! I'm C programmer learning now Cockpit. My problem is as follows: for some of the operation I must use external helper and I must wait for it output. The cockpit.spawn() function returns the promise, which is non-blocking operation (as expected). How can I make it work as blocking one? Which mean: the rest of the code in the function should be done after receiving full output of the cockpit.spawn (done() or fail()) best regards, Magik

3 12

11 Jan '19

Hi everybody I just installed cockpit in a server that I have access exclusively with ssh keys, my surprise is that the user hasn't a password and installing cockpit make possible to login without password opening a breach. Having users without password is a problem but if you have ssh set up to enforce key authentication this problem can happen silently, once you install cockpit anyone with access to the servers 9090 port and the user name will gain access to the server. Again i still think that the cause is the user without password, but would be nice if cockpit enforce password authentication to avoid this, what you guys think? Regards, PS: I tested with cockpit 176 from centos 7.6 repos -- “If you're going to try, go all the way. Otherwise, don't even start. ..." Charles Bukowski

2 3

Track github issue cleanup progress
by Martin Pitt 10 Jan '19

10 Jan '19

Hello all, as discussed in yesterday's meeting, we want to do a collective effort in cleaning up our issues [1]. I just did a few, but this bears the question how we track which issues have been looked at and which still need to be re-triaged? A lot of issues will still be current, after all. My idea: * With a script, add a "triage-201901" label to all issues which didn't get any comment in more than one month. * Then we can look at that list in our "daily morning issue gymnastics", and drive it to zero. * Once it is at zero, delete the label. Or does someone have a better/easier idea? Thanks, Martin [1] https://github.com/cockpit-project/cockpit/issues

1 2

Cockpit 185
by Sanne Raymaekers 09 Jan '19

09 Jan '19

Cockpit is the modern Linux admin interface. We release regularly. Here are the release notes from version 185: https://cockpit-project.org/blog/cockpit-185.html Summary: - Responsive dialogs on network, kdump and accounts page - Kubernetes containers included in docker graphs You can get Cockpit here: https://cockpit-project.org/running Cockpit 185 is available in Fedora 29: https://bodhi.fedoraproject.org/updates/cockpit-185-1.fc29 Or download the tarball here: https://github.com/cockpit-project/cockpit/releases/tag/185 Kind regards, Sanne Raymaekers

1 0

Re: Cockpit motd support
by Stephen Gallagher 01 Jan '19

01 Jan '19

On Sun, Dec 30, 2018 at 12:33 PM Patrick Mansfield <patmans(a)comcast.net> wrote: > > > Default off would be completely meaningless, then we wouldn't need to > show it > > at all. People who know about cockpit.socket don't need to be told that > it > > exists. > > > > > > No, you just need to remove /etc/motd.d/cockpit, that's sufficient and > > persistent. > > I just spent about 1/2 hour trying to figure out the proper way to disable > this motd, I found no documentation other than the above comment. > > It's unusual to modify a configuration by deleting installed files. > > It's annoying to have administration information on how to use the system > in a motd, by this logic we could have just about every software package > that has some sort of API add a note to the motd on how to access it. > > Where's the httpd motd to "Connet to http://somewhere.com to access your > web page." :-( > > Or the ssh motd "Login using ssh on port 22 to host somewhere.com" ;-) > > Static information - a message that will not change - should not be in the > motd. > > Please get rid of this motd. > First of all, this is not exactly static information. The same mechanism that informs the user of how to start Cockpit also provides specific information about how to access it (including system-specific hostname and IP) once it has been started. It appears static if you never run the service, though. I had an idea this morning, however. Once Cockpit is started, the MOTD provides useful information to all users logging in, so that needs to stay. The “how to start” message could probably be restricted to showing only to those users who are known to be capable of starting it (generally, root and members of the “wheel” group). I need to test an idea (I’m on holiday today, back in the office tomorrow), but I think what we could do is set the ownership of the static MOTD to root:wheel and mode 0640. As long as pam_motd handles permission errors gracefully, it would only display that message to someone who met that criteria. Yes, there could be non-wheel members who have sudo privilege to start services, but I think that falls safely into the edge-case of “people who already know what they’re doing”. The point of this is to help out the people experimenting with Linux. (Such as those looking to convert from other popular server OSes.) We want to make sure that the “front door” is welcoming; providing people with a blinking cursor and no clear idea how to get anything done is a good way to lose potential converts. So I definitely think we need to retain these cues. But as I mentioned above l, I think we can target it a bit better.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

cockpit-devel January 2019