Monitoring Directory Permissions
list Vernon Everett
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
list James Louis
inotifywait comes to mind but there are other alternatives like scripting something to watch the audit log. Jim On Tue, Dec 2, 2014 at 1:28 AM, Vernon Everett <user-b3f8dacb72c8@xymon.invalid>
▸
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
--
* Jim Louis \\\\||//// \ ~ ~ / | @ @ |*
*--oOo---(_)---oOo--*
'If a Neanderthal came and sat next to you on a bus, you'd probably get up
and change seats. But if a *Homo erectus* came and sat next to you on a
bus, you'd probably get off the bus.' ~ unknown
list Steve Coile
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: XXX-XXX-XXXX | Mobile: XXX-XXX-XXXX | Fax: XXX-XXX-XXXX On Tue, Dec 2, 2014 at 2:28 AM, Vernon Everett <user-b3f8dacb72c8@xymon.invalid>
▸
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
list Galen Johnson
I thought directories supported the same monitors as files so you could check for mode=777, for example. However, the man page seems to contradict this. =G=
▸
From: Xymon <xymon-bounces at xymon.com> on behalf of Steve Coile <user-a2e2f9aff0d1@xymon.invalid>
Sent: Tuesday, December 2, 2014 9:26 AM
To: Vernon Everett
Cc: Xymon mailinglist
Subject: Re: [Xymon] Monitoring Directory Permissions
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: XXX-XXX-XXXX | Mobile: XXX-XXX-XXXX | Fax: XXX-XXX-XXXX
On Tue, Dec 2, 2014 at 2:28 AM, Vernon Everett <user-b3f8dacb72c8@xymon.invalid<mailto:user-b3f8dacb72c8@xymon.invalid>> 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
list Vernon Everett
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 <user-a2e2f9aff0d1@xymon.invalid>
▸
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: XXX-XXX-XXXX | Mobile: XXX-XXX-XXXX | Fax: XXX-XXX-XXXX On Tue, Dec 2, 2014 at 2:28 AM, Vernon Everett <user-b3f8dacb72c8@xymon.invalid> 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
-- "Accept the challenges so that you can feel the exhilaration of victory" - General George Patton
list Tim McCloskey
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 [user-b3f8dacb72c8@xymon.invalid] 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 <user-a2e2f9aff0d1@xymon.invalid<mailto:user-a2e2f9aff0d1@xymon.invalid>> 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: XXX-XXX-XXXX<tel:XXX-XXX-XXXX> | Mobile: XXX-XXX-XXXX<tel:XXX-XXX-XXXX> | Fax: XXX-XXX-XXXX<tel:XXX-XXX-XXXX>
▸
On Tue, Dec 2, 2014 at 2:28 AM, Vernon Everett <user-b3f8dacb72c8@xymon.invalid<mailto:user-b3f8dacb72c8@xymon.invalid>> 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
--
"Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton
list Bill Arlofski
▸
On 12/02/2014 02:28 AM, Vernon Everett 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
Hi Vernon! You are going to <facepalm> for sure, but here goes. This thread intrigued me, so I set up a test. All you need to do is set up the directory test just like you would a file test. :) So, client-local.cfg: [remote.host.name] file:/path/of/DIRECTORY_To_Monitor then, in analisys.cfg: HOST=remote.host.name FILE /path/of/DIRECTORY_To_Monitor MODE=777 yellow Now, if the perms on the _directory_ are incorrect the "files" test page will show: *File* is mode 770 - should be 777 instead of: Directory is mode.... But that should not be an issue, because it is just the wrong word for a directory, and the actual Xymon test that you would set up for alerting on is the "files" test anyway, right ? Sorry to be the bringer of obvious tidings. heh :) Bill -- Bill Arlofski Reverse Polarity, LLC http://www.revpol.com/ -- Not responsible for anything below this line --
list Vernon Everett
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 <user-440820cc07d6@xymon.invalid> 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 [ user-b3f8dacb72c8@xymon.invalid] 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 <user-a2e2f9aff0d1@xymon.invalid <mailto:user-a2e2f9aff0d1@xymon.invalid>> 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: XXX-XXX-XXXX<tel:XXX-XXX-XXXX> | Mobile: XXX-XXX-XXXX<tel:
XXX-XXX-XXXX> | Fax: XXX-XXX-XXXX<tel:XXX-XXX-XXXX>
▸
On Tue, Dec 2, 2014 at 2:28 AM, Vernon Everett <user-b3f8dacb72c8@xymon.invalid
<mailto:user-b3f8dacb72c8@xymon.invalid>> 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
--
"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
list Bill Arlofski
▸
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 --
list Bill Arlofski
▸
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 --
list Tim McCloskey
Thanks Bill! I was curious about Vernon's original request and had poked at using FILE params for DIR. Quickly discovered that wasn't going to work so just commented out DIR and gave FILE a go, by itself. FILE worked and I didn't look back. Deciphering which of the foo's flips to red should not be troublesome for most. Thanks for the clarification. Also, I test this on 4.3.17 - on the server, with the server as a client. Aside from the usual /full/path/to/foo perms/ownership, if Vernon has a RedHat variant system selinux might need a tweak. Regards, Tim
▸
From: Xymon [xymon-bounces at xymon.com] on behalf of Bill Arlofski [user-0b8af203a56e@xymon.invalid]
Sent: Tuesday, December 2, 2014 5:08 PM
To: xymon at xymon.com
Subject: Re: [Xymon] Monitoring Directory Permissions
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 --
list Vernon Everett
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 <user-0b8af203a56e@xymon.invalid> 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 getnothing. 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 willinvestigate 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 --
-- "Accept the challenges so that you can feel the exhilaration of victory" - General George Patton
list Paul Root
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 <user-0b8af203a56e@xymon.invalid<mailto:user-0b8af203a56e@xymon.invalid>> 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 -- -- "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.
list Scot Kreienkamp
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 <user-0b8af203a56e@xymon.invalid<mailto:user-0b8af203a56e@xymon.invalid>> 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 -- -- "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.
list Bill Arlofski
▸
On 12/03/2014 09:55 AM, Root, Paul T wrote:
Did you restart xymon when you made your change before. Client-local.cfg is not re-read unless xymon is restarted.
Hi Paul Actually, as I understand it, when a client checks in, it requests its settings from the Xymon server which reads that file and sends the correct block based on the client's OS, or CLASS etc. Then, on a client's next report in, the client uses the new settings. You can watch this happen by making a change to the client-local.cfg on the server and then running this on a client: watch cat ~xymon/client/tmp/logfetch.*.cfg Within a few minutes (once the client checks in), this file will contain the new settings. So, when changes are made to client-local.cfg the changes may take up to ten minutes to propagate - assuming default 5 minute report cycle.
▸
Bill -- Bill Arlofski Reverse Polarity, LLC http://www.revpol.com/ -- Not responsible for anything below this line --