Postfix queue monitor - no graphs 🔗 link

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 <user-5d0d01dba542@xymon.invalid> wrote:

Look for the RRD files.

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:

1) add the xymon user to the postfix group
2) 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
3) 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:

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"

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 <user-5d0d01dba542@xymon.invalid> 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".

Sorry, I should have said "and setting the dir permission to 750".

Yup, that works.

On Wed, March 11, 2015 6:28 pm, Jeremy Laidman 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.

Or you can always restart xymon as a whole :)


Regards,

-jc

On 13 March 2015 at 12:38, J.C. Cleaver <user-87556346d4af@xymon.invalid> wrote:

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