On Sun, Dec 30, 2018 at 12:33 PM Patrick Mansfield <patmans@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.