I know, it's a lot simpler to put it right quietly with a cron, or even part of the update process, and I have considered this, but as always, it's political. The client wants it this way.

With their previous installation of Xymon, I had it working, so I know it's possible. However, it was all lost in a catastrophic system failure (with no backups). I rebuilt Xymon on a new server for them, but and I can't a hell remember how I configured the directory monitoring.

Regards Vernon

On 2 December 2014 at 22:26, Steve Coile <scoile at mcclatchyinteractive.com> wrote:

What's the point of monitoring for it? To let you know you need to correct them? If that, why not just put a cron job in place that sets them properly?

--

*Steve Coile*Senior Network and Systems Engineer, McClatchy Interactive <http://www.mcclatchyinteractive.com/> Office: 919-861-1247 | Mobile: 919-622-5369 | Fax: 919-861-1300

On Tue, Dec 2, 2014 at 2:28 AM, Vernon Everett <everett.vernon at gmail.com> wrote:

...

Hi guys

I have a *directory *on a client system, and it needs to have permission of 777 From time to time, automated software updates sets it to 770. I am looking for a way to check this, and alert when permissions are not as they should be. Any advice appreciated.

Regards Vernon

-- "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

Hi Tim,Bill

Thanks for that. That's exactly how I thought I had it, and how I have it configured now. But it doesn't seem to work. Also, on the files status page, I see the directory, but clicking on it, I get nothing. Blank page. In the client data page, it gives me ERROR: No such file or directory

The directory does exist. I would have the world breathing down my neck right now if it didn't. I have tried to ls the directory as Xymon to ensure I have read permissions in the parent directory, and it works there.

But good to know I am on the right track. Something else must be wrong. I will investigate further.

And yes, I am expecting this to end with a face-palm moment. Most of the problems I face in IT get resolved that way. :-)

Regards Vernon

On 3 December 2014 at 07:25, Tim McCloskey <tm at freedom.com> wrote:

I just tested this using file instead of dir. It works for UNIX (everything is a file), can't speak for windows. I'm not sure that it is designed or intended to work this way and I doubt you can mix DIR and FILE for the same O/S directory.

analysis.cfg

DIR /foo SIZE<8192 SIZE>4096 COLOR=yellow

FILE /foo MODE=0644 COLOR=RED TRACK FILE /foo OWNERID=johndoe COLOR=yellow

client-local.cfg file:/foo:md5

Good Luck.

---

From: Xymon [xymon-bounces at xymon.com] on behalf of Vernon Everett [ everett.vernon at gmail.com] Sent: Tuesday, December 2, 2014 2:08 PM To: Xymon mailinglist Subject: Re: [Xymon] Monitoring Directory Permissions

I know, it's a lot simpler to put it right quietly with a cron, or even part of the update process, and I have considered this, but as always, it's political. The client wants it this way.

With their previous installation of Xymon, I had it working, so I know it's possible. However, it was all lost in a catastrophic system failure (with no backups). I rebuilt Xymon on a new server for them, but and I can't a hell remember how I configured the directory monitoring.

Regards Vernon

On 2 December 2014 at 22:26, Steve Coile <scoile at mcclatchyinteractive.com <mailto:scoile at mcclatchyinteractive.com>> wrote: What's the point of monitoring for it? To let you know you need to correct them? If that, why not just put a cron job in place that sets them properly?

-- Steve Coile Senior Network and Systems Engineer, McClatchy Interactive< http://www.mcclatchyinteractive.com/> Office: 919-861-1247<tel:919-861-1247> | Mobile: 919-622-5369<tel: 919-622-5369> | Fax: 919-861-1300<tel:919-861-1300>

On Tue, Dec 2, 2014 at 2:28 AM, Vernon Everett <everett.vernon at gmail.com <mailto:everett.vernon at gmail.com>> wrote: Hi guys

I have a directory on a client system, and it needs to have permission of 777 From time to time, automated software updates sets it to 770. I am looking for a way to check this, and alert when permissions are not as they should be. Any advice appreciated.

Regards Vernon

-- "Accept the challenges so that you can feel the exhilaration of victory"

• General George Patton

---

Xymon mailing list Xymon at xymon.com<mailto: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

-- "Accept the challenges so that you can feel the exhilaration of victory"

• General George Patton

OK, now I am completely confused.

Let's assume directory to be monitored is /foo/bar Here's what I had. [client1] log:/var/adm/messages file:/foo/bar

[client2] log:/var/adm/messages file:/foo/bar

In desperation, I tried [client1] log:/var/adm/messages file:/foo/bar

[client2] log:/var/adm/messages file:/foo/bar log:/foo/bar

Not actually expecting much. But it started working - on both client systems?!?!?!

I removed log:/foo/bar And it's still working?!?!?!

WTF?

Don't get me wrong, I love the fact that it's working again, but I just don't understand how this has happened. Remember, both the clients were reporting "No such file or directory" The change made to the server config, would have only gone down to one client. But both started working.

On 3 December 2014 at 08:36, Bill Arlofski <waa-hobbitml at revpol.com> wrote:

On 12/02/2014 07:25 PM, Vernon Everett wrote:

...

Hi Tim,Bill

Thanks for that. That's exactly how I thought I had it, and how I have it configured now. But it doesn't seem to work. Also, on the files status page, I see the directory, but clicking on it, I get nothing. Blank page. In the client data page, it gives me ERROR: No such file or directory

The directory does exist. I would have the world breathing down my neck right now if it didn't. I have tried to ls the directory as Xymon to ensure I have read permissions in the parent directory, and it works there.

But good to know I am on the right track. Something else must be wrong. I will investigate further.

Hi Vernon

Before I sent my response, I actually did set up a full test of a dir as described using version 4.3.12 client and 4.3.17 server and can verify that it does work, so if it is not a Xymon version issue, it may just be a perms issue on the remote host..

Obvious, I know, but check the paths all the way down to the directory. Make sure that Xymon can get there. just a thought.

...

And yes, I am expecting this to end with a face-palm moment. Most of the problems I face in IT get resolved that way. :-)

heh, right? Good to hear I am not alone.

Bill

-- Bill Arlofski Reverse Polarity, LLC http://www.revpol.com/ -- Not responsible for anything below this line --

---

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

Actually it is read every so often, not just at start. I don’t know what the intervals are however. Ten minutes maybe?

From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Root, Paul T Sent: Wednesday, December 03, 2014 9:55 AM To: 'Vernon Everett'; 'Bill Arlofski' Cc: 'Xymon mailinglist' Subject: Re: [Xymon] Monitoring Directory Permissions

Did you restart xymon when you made your change before.

Client-local.cfg is not re-read unless xymon is restarted.

From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Vernon Everett Sent: Tuesday, December 02, 2014 9:28 PM To: Bill Arlofski Cc: Xymon mailinglist Subject: Re: [Xymon] Monitoring Directory Permissions

OK, now I am completely confused.

Let's assume directory to be monitored is /foo/bar Here's what I had. [client1] log:/var/adm/messages file:/foo/bar

[client2] log:/var/adm/messages file:/foo/bar

In desperation, I tried [client1] log:/var/adm/messages file:/foo/bar

[client2] log:/var/adm/messages file:/foo/bar log:/foo/bar

Not actually expecting much. But it started working - on both client systems?!?!?!

I removed log:/foo/bar And it's still working?!?!?!

WTF?

Don't get me wrong, I love the fact that it's working again, but I just don't understand how this has happened. Remember, both the clients were reporting "No such file or directory" The change made to the server config, would have only gone down to one client. But both started working.

On 3 December 2014 at 08:36, Bill Arlofski <waa-hobbitml at revpol.com<mailto:waa-hobbitml at revpol.com>> wrote: On 12/02/2014 07:25 PM, Vernon Everett wrote:

Hi Tim,Bill

Thanks for that. That's exactly how I thought I had it, and how I have it configured now. But it doesn't seem to work. Also, on the files status page, I see the directory, but clicking on it, I get nothing. Blank page. In the client data page, it gives me ERROR: No such file or directory

The directory does exist. I would have the world breathing down my neck right now if it didn't. I have tried to ls the directory as Xymon to ensure I have read permissions in the parent directory, and it works there.

But good to know I am on the right track. Something else must be wrong. I will investigate further.

Hi Vernon

Before I sent my response, I actually did set up a full test of a dir as described using version 4.3.12 client and 4.3.17 server and can verify that it does work, so if it is not a Xymon version issue, it may just be a perms issue on the remote host..

Obvious, I know, but check the paths all the way down to the directory. Make sure that Xymon can get there. just a thought.

And yes, I am expecting this to end with a face-palm moment. Most of the problems I face in IT get resolved that way. :-)

heh, right? Good to hear I am not alone.

Bill

-- Bill Arlofski Reverse Polarity, LLC http://www.revpol.com/ -- Not responsible for anything below this line --

Xymon mailing list Xymon at xymon.com<mailto: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 This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, please note that you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.

On 12/02/2014 06:25 PM, Tim McCloskey wrote:

I just tested this using file instead of dir. It works for UNIX (everything is a file), can't speak for windows. I'm not sure that it is designed or intended to work this way and I doubt you can mix DIR and FILE for the same O/S directory.

analysis.cfg

DIR /foo SIZE<8192 SIZE>4096 COLOR=yellow

FILE /foo MODE=0644 COLOR=RED TRACK FILE /foo OWNERID=johndoe COLOR=yellow

Hi Tim,

just thought I would respond to your doubts:

"I doubt you can mix DIR and FILE for the same O/S directory."

It turns out, that was actual the test I did.

I was already monitoring a dir for size on a host and just added:

file:/foo (client-local.cfg)

and

FILE /foo MODE=777 yellow (analysis.cfg)

and it worked fine.

Only thing is, on the "files" test page for that host, there are two lines for /foo:

/foo /foo /other/file/name

With no indication as to which one is for which test... but when one goes nongreen, the reason stated below it makes it clear.

Hope that helps!

Bill

-- Bill Arlofski Reverse Polarity, LLC http://www.revpol.com/ -- Not responsible for anything below this line --