On 12/03/14 13:56, Les Mikesell wrote:
> On Wed, Mar 12, 2014 at 4:07 AM, Toralf Lund <toralf.lund@xxxxxxx> wrote:
>>>> In general, that might make sense, but please consider the fact that I'm
>>>> not talking about a "general" server system. It's a machine dedicated to
>>>> running a "server" component on one specific software package, and will
>>>> only ever be contacted by a handful of "display" machines running a GUI
>>>> component of the same piece of software.
>>> Then you need to look at the features of the specific GUI and its
>>> transport to the server to see what options it provides for popup
>>> messages.
>> I can easily add a check to software itself. But like I said, I want to
>> avoid re-inventing the wheel. So if there is something built into the
>> system that will do the job for me...
> I don't think you provided enough information for anyone to help.
> What kind of remote gui are you using?
I wouldn't actually call it a "remote gui" - there is just an
application that communicates with a server process on a remote host,
via a custom protocol. This application has a "local" GUI. The remote
host is headless, although the machine typically has X, so you could run
processes on it with remote display.
I actually thought most if this would be clear from how I described the
system initially.
> If it is a full remote X
> desktop session (freenx/x2go or native network) you could run anything
> you could run locally at the console because it is in fact running on
> the server side. If you are running X locally on the display machine,
> you can still run anything you want on the server machine with its
> window open on the display desktop.
Obviously. But like I said, I was wondering if there was a "more
automatic" way directly supported by the distro. Like, maybe you could
somehow configure "gdu-notification-daemon" so that it would
1. Start automatically independently of logins.
2. Redirect notifications to a different system.
>>> Personally, I'd still recommend something more general
>>> that would generate email or text message alerts to the right set of
>>> people. It is fairly rare for 'users' to be interested in fixing
>>> system problems and even if that happens to be the case now for this
>>> particular box it may not always be.
>> Trust me, this is a highly customised setup with very special users, and
>> this won't change just like that.
>>
>> A more general system is not an entirely bad idea, but I think it would
>> only make sense if implemented at a larger scale based on a system-wide
>> policy (there is much else going on in the same network.) Which I'm not
>> sure will happen right now...
> I think it makes sense because there are already frameworks that are
> relatively easy to install and set up even if you initially only
> target one host and test - and you can get things like CPU and network
> bandwidth tracking for free.
Maybe.
However, I should perhaps also add that anything based on notification
based on e-mail or similar services might lead to problems in that the
systems don't normally deliver or receive e-mails.
> Then if you want, you can expand the
> monitoring to other things you are likely to need, but even if you
> don't it is probably easier than building your own notification
> system. It's probably not the easiest thing to start with, but
> OpenNMS is pretty flexible. For example if you have an xmpp system
> with clients for instant messaging, it can send alerts to a group
> conference so the interested people see it without cluttering email.
Hmm... Not sure if xmpp would be any better than email...
- Toralf
>
This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
