On Wed, Mar 12, 2014 at 9:07 AM, Toralf Lund <toralf.lund@xxxxxxx> wrote:
>
>> 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.
No, to me a 'remote gui' would mean a remote X session, either a full
desktop or a window from an app running remotely. And either of those
approaches would let you run other things.
>> 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.
The usual approach for things like that is to start your own instance
as part of your desktop startup or login script. That way it has a
way to attach to 'your' session/display.
>> 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.
Mail is sort of server-centric. That is, sending/receiving are pretty
lightweight with any number of easily available tools, and you
probably already have (or have access to) a central or public mail
service.
>> 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...
It's the same server-centric concept, just a different approach to
connecting. If you start from scratch you could run OpenFire which
will archive as much as you want of the group conference so when you
connect you'd see any recent issues - and like email, you can probably
find a client that will run minimized and pop up a notification when a
new message appears. The group-chat - or email to a group list have
the feature that the person who is going to work on the problem has an
easy way to tell the others with a simple reply.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
