Cockpit/Composer hackfest on Devconf.cz
by Martin Pitt
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-...
*shameless plug*
4 years, 8 months
cockpit.spawn() - how to wait for finish?
by .
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
4 years, 8 months
Login access for users without password, without password - maybe a breach?
by Daniel.
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
4 years, 8 months
Track github issue cleanup progress
by Martin Pitt
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
4 years, 8 months
Re: Cockpit motd support
by Stephen Gallagher
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.
4 years, 9 months