On Wed, Mar 12, 2014 at 9:07 AM, Toralf Lund toralf.lund@pgs.com 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 Xdesktop 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
- Start automatically independently of logins.
- 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.