Postfix queue monitor - no graphs
I'm setting up this client-side monitor:
https://wiki.xymonton.org/doku.php/monitors:postfix
I ran into a number of issues, and I've fixed all but one of them. The graphs aren't working. I followed all the instructions on that page, except that the config files I edited did not have "hobbit" in the name because I'm running 4.3.14 on the server and 4.3.7 on the client.
What troubleshooting steps do I need to follow to figure out if I did something wrong with the graphing config and what to change?
The major problem I encountered and fixed was permission related. The xymon user cannot read postfix queues, and the postfix user cannot write to the xymon client tmp directory. I solved this with these changes to the client system:
In /etc/sudoers.d/xymon: xymon ALL=(postfix : xymon) SETENV:NOPASSWD: /usr/lib/xymon/client/ext/postfix.sh
In /etc/xymon/clientlaunch.d/xymon/postfix.cfg: CMD /usr/bin/sudo -E -u postfix -g xymon $XYMONCLIENTHOME/ext/postfix.sh
In /var/lib/xymon/tmp: chmod g+w -R .
Is that a reasonable permission fix, or should I have done it a different way?
Separate issue, more annoying than a real problem: Both xymonton and the download site for the postfix queue monitor script are using self-signed certificates. It is not difficult to obtain zero-cost publicly-signed certificates that work in all modern browsers, so I think this should be fixed.
Thanks, Shawn
On 11 March 2015 at 10:49, Shawn Heisey <hobbit at elyograg.org> wrote:
I ran into a number of issues, and I've fixed all but one of them. The graphs aren't working. I followed all the instructions on that page, except that the config files I edited did not have "hobbit" in the name because I'm running 4.3.14 on the server and 4.3.7 on the client.
What troubleshooting steps do I need to follow to figure out if I did something wrong with the graphing config and what to change?
Look for the RRD files.
I solved this with these changes to the client system:
In /etc/sudoers.d/xymon: xymon ALL=(postfix : xymon) SETENV:NOPASSWD: /usr/lib/xymon/client/ext/postfix.sh
In /etc/xymon/clientlaunch.d/xymon/postfix.cfg: CMD /usr/bin/sudo -E -u postfix -g xymon $XYMONCLIENTHOME/ext/postfix.sh
In /var/lib/xymon/tmp: chmod g+w -R .
Is that a reasonable permission fix, or should I have done it a different way?
That's a common solution to this problem. I'm not sure I like the idea of altering the perms on /var/lib/xymon/tmp/, but I can't see a particularly nasty exploit being made available by this.
A better option might be to add the "sudo" command into the script (before each "find" command) rather than running the whole script under sudo, and in this way, most of the script runs as the xymon user, meaning no permissions problems.
Three other options come to mind:
- add the xymon user to the postfix group
- have the postfix user periodically dump the "find" command output to temp files, and adjust the xymon script to use the files (essntially commenting out the lines that run "find" and update the ".old" files
- have the postfix user run the postfix.sh script (eg via her cron), such as making /etc/cron.d/xymon-postfix:
*/5 * * * * postfix ( /usr/lib/xymon/client/xymoncmd /bin/sh -c 'XYMONTMP=/tmp $XYMONCLIENTHOME/ext/postfix.sh' ) >/tmp/somelogfile 2>&1
I've used all of these to good effect. I think the last of these options is my preferred option. A variation on the last one is to change the script to use /tmp instead of $BBTMP, and then the crontab line is much simpler.
J
On 3/10/2015 6:41 PM, Jeremy Laidman wrote:
What troubleshooting steps do I need to follow to figure out if I did something wrong with the graphing config and what to change?Look for the RRD files.
Thanks for your reply.
I do not see any RRD files for postfix. I have added postfix to these lines in xymonserver.cfg:
TEST2RRD="cpu=la,disk,inode,qtree,memory,$PINGCOLUMN=tcp,http=tcp,dns=tcp,dig=tcp,time=ntpstat,vmstat,iostat,netstat,temperature,apache,bind,sendmail,mailq,nmailq=mailq,socks,bea,iishealth,citrix,bbgen,bbtest,bbproxy,hobbitd,files,procs=processes,ports,clock,lines,ops,stats,cifs,JVM,JMS,HitCache,Session,JDBCConn,ExecQueue,JTA,TblSpace,RollBack,MemReq,InvObj,snapmirr,snaplist,snapshot,if_load=devmon,temp=devmon,paging,mdc,mdchitpct,cics,dsa,getvis,maxuser,nparts,xymongen,xymonnet,xymonproxy,xymond,postfix"
GRAPHS="la,disk,inode,qtree,files,processes,memory,users,vmstat,iostat,tcp.http,tcp,ncv,netstat,ifstat,mrtg::1,ports,temperature,ntpstat,apache,bind,sendmail,mailq,socks,bea,iishealth,citrix,bbgen,bbtest,bbproxy,hobbitd,clock,lines,ops,stats,cifs,JVM,JMS,HitCache,Session,JDBCConn,ExecQueue,JTA,TblSpace,RollBack,MemReq,InvObj,snapmirr,snaplist,snapshot,devmon::1,if_load::1,temp,paging,mdc,mdchitpct,cics,dsa,getvis,maxuser,nparts,xymongen,xymonnet,xymonproxy,xymond,postfix"
I also added this as the last line in xymonserver.cfg:
SPLITNCV_postfix="*:GAUGE"
That's a common solution to this problem. I'm not sure I like the idea of altering the perms on /var/lib/xymon/tmp/, but I can't see a particularly nasty exploit being made available by this.
A better option might be to add the "sudo" command into the script (before each "find" command) rather than running the whole script under sudo, and in this way, most of the script runs as the xymon user, meaning no permissions problems.
Three other options come to mind:
- add the xymon user to the postfix group
- have the postfix user periodically dump the "find" command output to temp files, and adjust the xymon script to use the files (essntially commenting out the lines that run "find" and update the ".old" files
- have the postfix user run the postfix.sh script (eg via her cron), such as making /etc/cron.d/xymon-postfix:
Adding the xymon user to the postfix group won't work, because the postfix queue directories have permission 700. That was the first idea that occurred to me, and it wouldn't work.
I found another permissions solution that I like better. I added "BBTMP=/tmp" to the beginning of the CMD line in the clientlaunch config, removed "-g xymon" from the sudo options, and removed the group allowance from the sudoers config. That allowed me to reverse the permission changes I made to /var/lib/xymon/tmp, and everything still works. There's a small amount of cruft in /tmp now (owned by postfix:postfix), but there will be no problems if those files are removed.
Thanks, Shawn
On 12 March 2015 at 02:12, Shawn Heisey <hobbit at elyograg.org> wrote:
I do not see any RRD files for postfix.
OK, this rules out a number of areas where it might fail.
I have added postfix to these lines in xymonserver.cfg:
<snip>
That looks correct.
I also added this as the last line in xymonserver.cfg:
SPLITNCV_postfix="*:GAUGE"
yep
Perhaps you need to restart xymond_rrd? I think xymond_rrd reads the SPLITNCV_* and TEST2RRD parameters only when it starts, and so needs to be restarted. Actually, you only need to kill the two xymond_rrd processes, and Xymon will restart them automatically. So something like: "sudo pkill xymond_rrd".
Adding the xymon user to the postfix group won't work, because the postfix queue directories have permission 700. That was the first idea that occurred to me, and it wouldn't work.
Sorry, I should have said "and setting the dir permission to 750".
I found another permissions solution that I like better. I added "BBTMP=/tmp" to the beginning of the CMD line in the clientlaunch
Yup, that works.
On Wed, March 11, 2015 6:28 pm, Jeremy Laidman wrote:
On 12 March 2015 at 02:12, Shawn Heisey <hobbit at elyograg.org> wrote:
SPLITNCV_postfix="*:GAUGE"
yep
Perhaps you need to restart xymond_rrd? I think xymond_rrd reads the SPLITNCV_* and TEST2RRD parameters only when it starts, and so needs to be restarted. Actually, you only need to kill the two xymond_rrd processes, and Xymon will restart them automatically. So something like: "sudo pkill xymond_rrd".
Actually, I believe you'll need to kill the owning xymond_channel process as well. xymond_rrd's environment is inherited from xymond_channel, and xymond_channel won't notice any changes in xymonserver.cfg, since it's simply loaded in by xymonlaunch prior to fork+execution.
Or you can always restart xymon as a whole :)
Regards,
-jc
On 13 March 2015 at 12:38, J.C. Cleaver <cleaver at terabithia.org> wrote:
Actually, I believe you'll need to kill the owning xymond_channel process as well. xymond_rrd's environment is inherited from xymond_channel, and xymond_channel won't notice any changes in xymonserver.cfg, since it's simply loaded in by xymonlaunch prior to fork+execution.
Yeah, that's what I would have thought. But the man page for "How to setup custom graphs" (https://www.xymon.com/help/howtograph.html) in reference to setting SPLITNCV says,
"you must restart Xymon after making these changes ... or at least, kill the xymond_rrd process ... and they will pick up the new settings."
I think xymond_channel dies when xymond_rrd dies, and so it's actually xymonlaunch that restarts them both, and at that time, loads their environment from the "ENVFILE" setting in tasks.cfg.
Cheers Jeremy
participants (3)
-
cleaver＠terabithia.org
-
hobbit＠elyograg.org
-
jlaidman＠rebel-it.com.au