//Hi,/
/I need to implement a system of disk space checks and warnings for a client-server setup running CentOS 6. Simply put, I just want a warning popup rather like the ones given by gdu-notification-daemon when server file system is full or nearly full, but they should appear on the client display(s) rather than locally, and must also work when nobody is logged directly in to the (server) system.
What do you reckon is the best way of achieving this? I can think of ways to get what I want via scripts/custom programs/cron jobs, but perhaps there are "standard" solutions already? I'd like to avoid re-inventing the wheel... I also know that there are various advanced solutions for system resource monitoring out there - I've used Nagios in the past - but it may seem like setting up something like that will be an overkill in this case.
So what's everyone's thoughts on this?
- 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.
On Tue, Mar 11, 2014 at 8:38 AM, Toralf Lund toralf.lund@pgs.com wrote:
//Hi,/
/I need to implement a system of disk space checks and warnings for a client-server setup running CentOS 6. Simply put, I just want a warning popup rather like the ones given by gdu-notification-daemon when server file system is full or nearly full, but they should appear on the client display(s) rather than locally, and must also work when nobody is logged directly in to the (server) system.
it sounds like you think you want to send popup windows across from one system to many remote machines. this seems like a path of madness to me; full of potential problems like x windows security, or if you write your own little daemon to accept messages and display a box, misuse/abuse from playful users. I think you should build a monitoring system (nagios, xymon, opennms, several others or perhaps your own if you're feeling far too adventurous) instead. right now all you care about is disk space, but eventually someone will want to also check for certain processes, open ports, logfile entries, something and you could spend the time now to put in the hooks for more advanced things and get people in the habit of checking a monitoring system on a regular basis.
What do you reckon is the best way of achieving this? I can think of ways to get what I want via scripts/custom programs/cron jobs, but perhaps there are "standard" solutions already? I'd like to avoid re-inventing the wheel... I also know that there are various advanced solutions for system resource monitoring out there - I've used Nagios in the past - but it may seem like setting up something like that will be an overkill in this case.
So what's everyone's thoughts on this?
I would go with nagios, but I'm a bit biased that way. if you decide to go that route and want more input, send me an offlist email (unless others feel this is on topic for the list? it seems like it wanders out of scope to me, but I'm not trying to exclude people); I've got a nagios plugin script that I use for monitoring disk space use you can have if you'd like. or at least you can have it once I bring my machine back back online.
On 11/03/14 14:17, zGreenfelder wrote:
On Tue, Mar 11, 2014 at 8:38 AM, Toralf Lund toralf.lund@pgs.com wrote:
//Hi,/
/I need to implement a system of disk space checks and warnings for a client-server setup running CentOS 6. Simply put, I just want a warning popup rather like the ones given by gdu-notification-daemon when server file system is full or nearly full, but they should appear on the client display(s) rather than locally, and must also work when nobody is logged directly in to the (server) system.
it sounds like you think you want to send popup windows across from one system to many remote machines. this seems like a path of madness to me; full of potential problems like x windows security, or if you write your own little daemon to accept messages and display a box, misuse/abuse from playful users.
Not really worried by those things in this context.
The setup is only physically accessible to a very limited group of trusted users, and access to or from the outside world is restricted by all sorts of firewalls etc, and also only available via a very slow and unreliable link...
I think you should build amonitoring system (nagios, xymon, opennms, several others or perhaps your own if you're feeling far too adventurous) instead. right now all you care about is disk space, but eventually someone will want to also check for certain processes, open ports, logfile entries, something and you could spend the time now to put in the hooks for more advanced things and get people in the habit of checking a monitoring system on a regular basis.
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.
- Toralf
What do you reckon is the best way of achieving this? I can think of ways to get what I want via scripts/custom programs/cron jobs, but perhaps there are "standard" solutions already? I'd like to avoid re-inventing the wheel... I also know that there are various advanced solutions for system resource monitoring out there - I've used Nagios in the past - but it may seem like setting up something like that will be an overkill in this case.
So what's everyone's thoughts on this?
I would go with nagios, but I'm a bit biased that way. if you decide to go that route and want more input, send me an offlist email (unless others feel this is on topic for the list? it seems like it wanders out of scope to me, but I'm not trying to exclude people); I've got a nagios plugin script that I use for monitoring disk space use you can have if you'd like. or at least you can have it once I bring my machine back back online.
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.
Toralf Lund wrote:
On 11/03/14 14:17, zGreenfelder wrote:
On Tue, Mar 11, 2014 at 8:38 AM, Toralf Lund toralf.lund@pgs.com wrote:
/I need to implement a system of disk space checks and warnings for a client-server setup running CentOS 6. Simply put, I just want a warning popup rather like the ones given by gdu-notification-daemon when server file system is full or nearly full, but they should appear on the client display(s) rather than locally, and must also work when nobody is logged directly in to the (server) system.
it sounds like you think you want to send popup windows across from one system to many remote machines. this seems like a path of madness to me; full of potential problems like x windows security, or if you write your own little daemon to accept messages and display a box, misuse/abuse from playful users.
Not really worried by those things in this context.
The setup is only physically accessible to a very limited group of trusted users, and access to or from the outside world is restricted by all sorts of firewalls etc, and also only available via a very slow and unreliable link...
I think you should build amonitoring system (nagios, xymon, opennms, several others or perhaps your own if you're feeling far too adventurous) instead. right now all you care about is disk space, but eventually someone will want to also check for certain processes, open ports, logfile entries, something and you could spend the time now to put in the hooks for more advanced things and get people in the habit of checking a monitoring system on a regular basis.
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.
<snip> In general, I agree with the other posters. What may only have very limited accessibility *now* doesn't say anything about next week, or the next manager who comes in's intent.
But to directly answer your question, here's a thought: does the software you're running have the ability to do pop-ups? If so, can you get a message to it - a d/b entry, or a file that it can read? If so, have it do the alert.
mark
On Tue, Mar 11, 2014 at 9:49 AM, Toralf Lund toralf.lund@pgs.com wrote:
I think you should build amonitoring system (nagios, xymon, opennms, several others or perhaps your own if you're feeling far too adventurous) instead. right now all you care about is disk space, but eventually someone will want to also check for certain processes, open ports, logfile entries, something and you could spend the time now to put in the hooks for more advanced things and get people in the habit of checking a monitoring system on a regular basis.
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. 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.
On 11/03/14 16:16, Les Mikesell wrote:
On Tue, Mar 11, 2014 at 9:49 AM, Toralf Lund toralf.lund@pgs.com wrote:
I think you should build amonitoring system (nagios, xymon, opennms, several others or perhaps your own if you're feeling far too adventurous) instead. right now all you care about is disk space, but eventually someone will want to also check for certain processes, open ports, logfile entries, something and you could spend the time now to put in the hooks for more advanced things and get people in the habit of checking a monitoring system on a regular basis.
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...
Personally, I'd still recommend something more generalthat 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...
- 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.
On 12/03/2014 09:07, Toralf Lund wrote:
On 11/03/14 16:16, Les Mikesell wrote:
On Tue, Mar 11, 2014 at 9:49 AM, Toralf Lund toralf.lund@pgs.com wrote:
I think you should build amonitoring system (nagios, xymon, opennms, several others or perhaps your own if you're feeling far too adventurous) instead. right now all you care about is disk space, but eventually someone will want to also check for certain processes, open ports, logfile entries, something and you could spend the time now to put in the hooks for more advanced things and get people in the habit of checking a monitoring system on a regular basis.
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...
Personally, I'd still recommend something more generalthat 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...
- Toralf
You could use the Nagios check_disk plugin to monitor the disk usage. This gives easy to use response codes and could be wrapped in a script that sends an email if if runs low on space. put in cron to run every 10 minutes or something like that and it will do what you are looking for. You can get the plugin from epel and it is trivial to install and use.
Tris
************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster@bgfl.org
The views expressed within this email are those of the individual, and not necessarily those of the organisation *************************************************************
On Wed, Mar 12, 2014 at 4:07 AM, Toralf Lund toralf.lund@pgs.com 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? 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.
Personally, I'd still recommend something more generalthat 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. 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.
On 12/03/14 13:56, Les Mikesell wrote:
On Wed, Mar 12, 2014 at 4:07 AM, Toralf Lund toralf.lund@pgs.com 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 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
1. Start automatically independently of logins. 2. Redirect notifications to a different system.
Personally, I'd still recommend something more generalthat 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.
Toralf Lund wrote: <snip>
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.
<snip> Perhaps a milter to forward a logwatch email (which goes to root) if there's a line that has on it "Warning. Disk Filling up"?
mark
On Wed, Mar 12, 2014 at 9:46 AM, m.roth@5-cent.us wrote:
Toralf Lund wrote:
<snip> > 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. > <snip> Perhaps a milter to forward a logwatch email (which goes to root) if there's a line that has on it "Warning. Disk Filling up"?
I think logwatch only runs once a day. If something is being logged you can catch it immediately with swatch. And you can send a pop-up to an X session with 'send-notify' - with the usual assortment of ways to connect to remote sessions (along with the usual issues of having permission to connect to sessions that aren't yours.).
Les Mikesell wrote:
On Wed, Mar 12, 2014 at 9:46 AM, m.roth@5-cent.us wrote:
Toralf Lund wrote:
<snip> > 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. > <snip> Perhaps a milter to forward a logwatch email (which goes to root) if there's a line that has on it "Warning. Disk Filling up"?
I think logwatch only runs once a day. If something is being logged you can catch it immediately with swatch. And you can send a pop-up to an X session with 'send-notify' - with the usual assortment of ways to connect to remote sessions (along with the usual issues of having permission to connect to sessions that aren't yours.).
It does only run once a day. I wasn't sure just how frequently a user fills the filesystem, or how much might happen in one day. I am, please note, strongly prefer fire prevention to fire-fighting.....
mark
On 12/03/14 18:41, m.roth@5-cent.us wrote:
Les Mikesell wrote:
On Wed, Mar 12, 2014 at 9:46 AM, m.roth@5-cent.us wrote:
Toralf Lund wrote:
<snip> > 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. > <snip> Perhaps a milter to forward a logwatch email (which goes to root) if there's a line that has on it "Warning. Disk Filling up"?
I think logwatch only runs once a day. If something is being logged you can catch it immediately with swatch. And you can send a pop-up to an X session with 'send-notify' - with the usual assortment of ways to connect to remote sessions (along with the usual issues of having permission to connect to sessions that aren't yours.).
That's something that we may be able to sort out, so, yes, perhaps this is an option that might work...
It does only run once a day. I wasn't sure just how frequently a user fills the filesystem, or how much might happen in one day. I am, please note, strongly prefer fire prevention to fire-fighting.....
A lot of data may be written every day, but a daily check should still find the disk close to being full, relatively speaking, if there is a risk of filling up the disk. As in, one issue on the system in question is that it has log files that can grow by a few gigabytes every day, but that's still not a lot compared to the total disk space. (The logs are subject to rotation, but problems may occur because new logs file are larger than the ones "rotated out". And we want to keep log data for as log as we can.)
So, yeah, maybe we can work with logwatch. Looking at an old root mailbox file, I don't see any "direct" warnings related to disk space, but I do find a number of lines like
Warning: Audit daemon is low on disk space for logging: 1 times
Do you expect something in the "Disk Space Begin" ... "Disk Space End" section, too?
- Toralf
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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.
On Wed, 2014-03-12 at 10:46 -0400, m.roth@5-cent.us wrote:
Perhaps a milter to forward a logwatch email (which goes to root) if there's a line that has on it "Warning. Disk Filling up"?
Logwatch is usually once a day, just pass midnight here. Besides disk usage is standard (no configuration required) on the Logwatches we get for C5 and C6. Its at the end.
On 12/03/14 22:24, Always Learning wrote:
On Wed, 2014-03-12 at 10:46 -0400, m.roth@5-cent.us wrote:
Perhaps a milter to forward a logwatch email (which goes to root) if there's a line that has on it "Warning. Disk Filling up"?
Logwatch is usually once a day, just pass midnight here. Besides disk usage is standard (no configuration required) on the Logwatches we get for C5 and C6. Its at the end.
Yes, I see a "df" output section in existing mails. Like I said elsewhere, there appear to be no explicit warnings on low disk space, though.
- 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.
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.
On 12/03/14 15:55, Les Mikesell wrote:
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.
Not necessarily. The system is running on a separate network segment that has no "general purpose" computers. It is physically connected to the outside world, but most IP ports are closed for security reasons and/or to limit bandwidth.
Then if you want, you can expand themonitoring 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.
See above.
- T
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.
-
Always Learning -
Les Mikesell -
m.roth＠5-cent.us -
Toralf Lund -
Tris Hoar -
zGreenfelder