When monitoring a file using SEC, it normally tails on that file and
any new changes can be matched against some pattern.
If someone edits that file using any editor SEC recognizes that the
file has been recreated and shows the below message
Input file ./testdir/p has been recreated
Shuffled ./tes
File-system wise, on save, the file is created from 0 bytes and repopulated,
so SEC might not know that it was a user-edit.
This could happen with nano (pico), try a more powerful editor like vim (or
emacs).
--
Justin J. Novack
Official Disturber of the Peace
On Wed, Oct 19, 2011 at 6:55 AM, Su
Yes it is happening with vim.
Is there any way to tell SEC not to repopulate?
On Wed, Oct 19, 2011 at 5:01 PM, Justin J. Novack wrote:
> File-system wise, on save, the file is created from 0 bytes and repopulated,
> so SEC might not know that it was a user-edit.
> This could happen with nano (pi
Again, the main thing here is that SEC doesn't care, it is the OS at fault
(for doing it correctly). Your editor recreates the file from 0 bytes, so
how is SEC to know it's not a new file?
Try other methods of editing the file, like sed or diff if you are crafty.
If you are just adding content to
Even if it were possible to delete say 100 bytes from the front of the
file, how would SEC know that it needed to skip back 100 bytes to keep
it's concept of the current location in the file? Imagine a scenario
with multiple write to the end of the file, some of which SEC has
processed, but some it
On 10/19/2011 01:55 PM, Supratik Goswami wrote:
> When monitoring a file using SEC, it normally tails on that file and
> any new changes can be matched against some pattern.
> If someone edits that file using any editor SEC recognizes that the
> file has been recreated and shows the below message
>
Excellent points, all. I've decided to combine the two approaches.
However, I'm stuck.
As you can see below, I'm loading the hashes on startup, and the second rule
doesn't run. :( If I remove the context from the second rule, it runs fine.
I don't think context =($perl_hash{$2}) is a valid con
Sorry for the double post, I wanted to post an intermediate solution:
The correct context line for the second rule would be:
context= =(if (exists $hash{"GigabitEthernet1/37"}) { return 1;} )
This should be the last stumbling block...
--
Justin J. Novack
Official Disturber of the Peace
On
In message
,
"Justin J. Novack" writes:
>Excellent points, all. I've decided to combine the two approaches.
>However, I'm stuck.
>
>As you can see below, I'm loading the hashes on startup, and the second rule
>doesn't run. :( If I remove the context from the second rule, it runs fine.
>I don't
Again, thank you John, David, et. al.
My full solution is posted for reference. Please feel free to include in
documentation.
/etc/sec/friendlynames.txt
GigabitEthernet1/37=TEST SERVER
GigabitEthernet3/39=IMPORTANT SERVER
/etc/sec/testing.sec
===
type=Single
des
On Wed, 19 Oct 2011, Justin J. Novack wrote:
Again, thank you John, David, et. al.
My full solution is posted for reference. Please feel free to include in
documentation.
/etc/sec/friendlynames.txt
GigabitEthernet1/37=TEST SERVER
GigabitEthernet3/39=IMPORTANT SERVER
/etc
11 matches
Mail list logo