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())
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
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. ..."
as discussed in yesterday's meeting, we want to do a collective effort in
cleaning up our issues .
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.
* 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?
On Sun, Dec 30, 2018 at 12:33 PM Patrick Mansfield <patmans(a)comcast.net>
> > 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
> > 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
> 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
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
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.