Hi Evy,

It turned out that we have a slight modification to the running of the
plugin scripts, so that they are preprended with sudo.  We do that so we
don't have to run the check_mk agent as root, which we find to be a
security hole (and the product should account for IMO).  Of course, since
it runs as sudo it doesn't keep the REMOTE_HOST variable (which is being
passed by xinetd to its processes) by default, so we had to add an env_keep
to our sudoers config.

After that, the check_mk_agent script inherits it, and when it runs the
mk_logwatch process, the latter works correctly.

Matt

On Tue, Sep 20, 2016 at 3:51 PM, Evy Bongers <lists+check...@evybongers.nl>
wrote:

> Hi Mathieu,
>
> I quickly checked the source of the agent script for linux.
> This is the code I found relevant to the REMOTE variable:
>
> if [ "$REMOTE_HOST" ] ; then
>     export REMOTE=$REMOTE_HOST
> elif [ "$SSH_CLIENT" ] ; then
>     export REMOTE=${SSH_CLIENT%% *}
> fi
>
> If the REMOTE variable isn't set, then maybe your inetd is somehow
> configured to not pass along the REMOTE_HOST variable. I'm not that
> familiar with (x)inetd, so unfortunately I can't help you with this.
>
> Regards,
>
> Evy
>
> On 20/09/16 20:56, Mathieu Levi wrote:
> > Thanks, Evy.  Well, I'm using the stock xinetd mechanism for the agent
> > connectivity, nothing fancy (no SSH).  Looks like REMOTE isn't being
> > set, or passed along to the client at all.
> >
> > On Tue, Sep 20, 2016 at 12:12 PM, Evy Bongers
> > <lists+check...@evybongers.nl <mailto:lists+check...@evybongers.nl>>
> wrote:
> >
> >     Hi Mathieu,
> >
> >     I'm not sure about this, but I'm guessing that the $REMOTE variable
> >     should be provided to the environment by xinetd. If you're using a
> >     different way of executing your agent script (e.g. SSH), then you'll
> >     have to modify the script to set the $REMOTE variable based on the
> >     variables available (for example, $SSH_CLIENT could be used when
> >     using SSH).
> >
> >     Regards,
> >
> >     Evy
> >
> >     On 20/09/16 17:05, Mathieu Levi wrote:
> >     > Hello,
> >     >
> >     > I'm currently using the mk_logwatch plugin in order to monitor a
> few
> >     > logfiles.
> >     >
> >     > I have a scenario where, in certain cirumstances in our
> environment,
> >     > multiple Check_MK servers monitor the same hosts.  In that
> >     instance, the
> >     > logwatch.state file, which contains an offset of the monitored
> logs so
> >     > it can keep tabs on where it has last read the files, needs to be
> >     > Check_MK server specific.  Otherwise two different instances will
> be
> >     > updating the same logwatch.state and creating a race condition.
> >     >
> >     > I was about to modify the mk_logwatch script myself when I
> discovered
> >     > the functionality is built-in.  Here's a snippet w/ line numbers of
> >     > mk_logwatch:
> >     >
> >     >  66 # Determine the name of the state file
> >     >  67 # $REMOTE set                   -> logwatch.state.$REMOTE
> >     >  68 # $REMOTE not set and a tty     -> logwatch.state.local
> >     >  69 # $REMOTE not set and not a tty -> logwatch.state
> >     >
> >     >
> >     > All this to ask, how do I set REMOTE?  (1.2.8p9)  Where is this, or
> >     > should this be, inherited from?
> >     >
> >     > Thanks
> >     >
> >     >
> >     > _______________________________________________
> >     > checkmk-en mailing list
> >     > checkmk-en@lists.mathias-kettner.de
> >     <mailto:checkmk-en@lists.mathias-kettner.de>
> >     > http://lists.mathias-kettner.de/mailman/listinfo/checkmk-en
> >     <http://lists.mathias-kettner.de/mailman/listinfo/checkmk-en>
> >     >
> >
> >
>
_______________________________________________
checkmk-en mailing list
checkmk-en@lists.mathias-kettner.de
http://lists.mathias-kettner.de/mailman/listinfo/checkmk-en

Reply via email to