[Xymon] Potential bug in FILE analysis

[Vernon Everett]

That will work for sure, but it just sounds like reinventing the wheel so I
can take the long way round.
:-(


On 23 May 2014 09:31, Ralph Mitchell <ralphmitchell at gmail.com> wrote:

> Maybe a cron job running as root to do the stat and drop the results into
> a file in Xymon's tmp directory, where an ext script can read and report?
>  The root script could read the list of files from the Xymon client's
> local.cfg.
>
> Ralph Mitchell
>
>
>
> On Thu, May 22, 2014 at 9:21 PM, Vernon Everett <everett.vernon at gmail.com>wrote:
>
>> ...the same as if you just hardcoded /var/crash/bounds and
>> /var/crash/vmdump.0....
>>
>> As soon as I read this, I had my "D'oh!" moment.
>> Of course, the "sudo find" only generates the list of files to check.
>> So not a bug. A permissions error.
>>
>> Anybody know of a way to give Xymon elevated access permissions when it
>> stats files it's checking?
>> I would prefer not to change the directory permissions if I can avoid it.
>>
>> Thanks
>> Vernon
>>
>>
>>
>>
>>
>> On 23 May 2014 07:18, Adam Goryachev <mailinglists at websitemanagers.com.au
>> > wrote:
>>
>>>  OK, so you are using sudo to generate a list of filenames, so xymon
>>> can read the list of filenames you want to monitor (the same as if you just
>>> hardcoded /var/crash/bounds and /var/crash/vmdump.0 into the
>>> clientlocal.cfg file.
>>>
>>> However, when xymon tries to look at the details for the file you have
>>> asked it to check, it can't determine *any* information about the file, not
>>> even whether it exists or not, because it doesn't have sufficient
>>> privileges. You would need xymon to have sudo power to check the file as
>>> well, (not sure if that would be feasible) or else to add at least rx
>>> permissions for xymon to be able to provide information:
>>>
>>> ls -ld test
>>> drwx------ 2 root root 4096 May 23 09:10 test
>>> agoryachev at it-desktop:/tmp$ ls -l test
>>> ls: cannot open directory test: Permission denied
>>> agoryachev at it-desktop:/tmp$ sudo chmod +r test
>>> root at it-desktop:/tmp# exit
>>> agoryachev at it-desktop:/tmp$ ls -l test
>>> ls: cannot access test/two: Permission denied
>>> ls: cannot access test/one: Permission denied
>>> total 0
>>> -????????? ? ? ? ?            ? one
>>> -????????? ? ? ? ?            ? two
>>> agoryachev at it-desktop:/tmp$ ls -l test/one
>>> ls: cannot access test/one: Permission denied
>>> agoryachev at it-desktop:/tmp$ sudo chmod +x test
>>> root at it-desktop:/tmp# exit
>>> agoryachev at it-desktop:/tmp$ ls -l test
>>> total 0
>>> -rw-r--r-- 1 root root 0 May 23 09:10 one
>>> -rw-r--r-- 1 root root 0 May 23 09:10 two
>>>
>>> So you can read the directory contents with +r, but you need +x to be
>>> able to stat those directory entries. At least, that applies on my Linux
>>> workstation, it may depend on your OS/etc.
>>>
>>> Regards,
>>> Adam
>>>
>>>
>>> On 22/05/14 15:40, Vernon Everett wrote:
>>>
>>>         Hi all
>>>
>>>  Not sure if this really classifies as a bug or not.
>>>  I am inclined to think it is.
>>>
>>>  In clientlocal.cfg, I have
>>>  [sunos]
>>> file:`/usr/bin/sudo /usr/bin/find /var/crash/ -type f 2> /dev/null`
>>>
>>>  And this finds 2 files.
>>>  /var/crash/bounds
>>>  /var/crash/vmdump.0
>>>  So far so good.
>>>
>>>  However, /var/crash/ is a symlink to /var/share/crash/
>>>  And /var/share/crash has permissions or 700
>>>  So Xymon can determine there is a file, but cannot collect any metadata
>>> on the file, since it cannot stat the files in /var/share/crash/
>>>
>>>  In analysis.cfg I have this line (with appropriate HOST= value, of
>>> course)
>>>  FILE    %^/var/cores/.*         NOEXIST         red
>>> When I go to the "files" page, I see the file names there.
>>> Clicking on the file names, I get this info.
>>> [file:/var/crash/vmdump.0]
>>> ERROR: Permission denied
>>>
>>>  But no red status appears on the test.
>>>  Testing, using a similar directory structure, where Xymon can stat the
>>> files, does give a red status.
>>>
>>>  I can understand that Xymon can't give any info on the file because of
>>> permissions, but in this case, all I care about is that the file exists,
>>> which Xymon has determined.
>>> That should trigger a red status.
>>>
>>>  Using Xymon 4.3.10
>>>
>>>  Regards
>>> Vernon
>>>
>>>
>>>
>>>
>>>
>>> --
>>> "Accept the challenges so that you can feel the exhilaration of victory"
>>> - General George Patton
>>>
>>>
>>> _______________________________________________
>>> Xymon mailing listXymon at xymon.comhttp://lists.xymon.com/mailman/listinfo/xymon
>>>
>>>
>>>
>>> --
>>> Adam Goryachev Website Managers www.websitemanagers.com.au
>>>
>>> _______________________________________________
>>> Xymon mailing list
>>> Xymon at xymon.com
>>> http://lists.xymon.com/mailman/listinfo/xymon
>>>
>>>
>>
>>
>> --
>> "Accept the challenges so that you can feel the exhilaration of victory"
>> - General George Patton
>>
>> _______________________________________________
>> Xymon mailing list
>> Xymon at xymon.com
>> http://lists.xymon.com/mailman/listinfo/xymon
>>
>>
>


-- 
"Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20140523/27ab0a4b/attachment.html>