Hi, On Sun, Dec 20, 2020 at 07:06:57PM +0000, Greg Cox wrote: > So IMO, 1-2 are fundamental, 3-5 are > wishlist/consideration/extensions/ideas, use or ignore as you see fit: > * Make the ability for receiving messages on a client as described. > Enabled by default, maybe selectively disable-able because someone will > think it's spammy, but I'd almost suggest not allowing it. > * Make the ability to send a user a message via management. Enabled by > default, maybe selectively disable-able as a safety mechanism / make > someone "key the mic to speak."
These two can be done with the proposed "echo msg..." mechanism (and
suppressed with "pull-filter ignore echo" already today, and possibly
with buttons to-be-added in the GUIs).
> * Make the ability to 'wall' a message out to all connected users in one
> command, e.g. 'wall "server going down in 5 mins"' or something like that.
This is an interesting challenge. Parts of openvpn client might assume
that a PUSH_REPLY is only seen at initial or renegotion time, so sending
a message with the proposed mechanism ("PUSH_REPLY echo msg server shutdown")
might trigger surprising effects.
It might just work.
But it can not be triggered from the server via client-connect scripts/
files/plugins as those are gone. Maybe it can be triggered from the
servers-side management interface. Not sure.
> * Make the ability to 'post' a message for some amount of time, e.g.
> 'wallpost 60m "server going down at 1700"' Sending a message gets someone
> who is connected now, but misses the user who connects 2m after I go
> through the list of users and I stop looking. So, this would hang around
> and pop a message to everyone connected now, plus each new connection, for
> the next 60m.
This is something outside "openvpn core", more tied to your client-connect
scripts/plugins on the server. Put messages with an expire date "somewhere"
(database, filesystem, ...) and on connect, find everything that is still
valid and generate 'push "echo msg..."' messages accordingly.
> * Add an option ala --[no-]use-expired-certs. When true, proceed like you
> do today; when false, if certs are expired, have the client feed itself a
> message via this mechanism to popup that your certs are expired, so a user
> knows right away what's wrong. It'd be a spammy option if it tried to tell
> you what to do, so I'm keeping the idea simple and generic.
Interesting idea :-) - not sure what to do about this one. Since all
"major" GUIs already look at the log file, and present warnings in some
form to the user, maybe this is more a GUI task - if we warn about
"cert might be expired" AND then there is a AUTH_FAILED response,
change that warning (or even "all warnings logged") into a popup window?
Related but slightly different problem.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
