rec 1.3.4 → 1.3.5
Sign up to get free protection for your applications and to get access to all the features.
- data/EXAMPLES +2 -2
- data/README +4 -4
- metadata +9 -5
data/EXAMPLES
CHANGED
@@ -24,7 +24,7 @@ If we see that happen 3 times (+threshold+) within a minute (+lifespan+), alert
|
|
24
24
|
}
|
25
25
|
|
26
26
|
When we see the first event, a state is created with title "Failed sudo password for user richard".
|
27
|
-
The second event has
|
27
|
+
The second event has no effect, beyond automatically incrementing the count.
|
28
28
|
When we see the third event, an output message is generated and logged, and then the generated
|
29
29
|
message is also sent via IM to the administrator. Alternatively:
|
30
30
|
|
@@ -59,7 +59,7 @@ for a fixed 5 minutes.
|
|
59
59
|
== Adding a final block
|
60
60
|
If we want to see one message when the user first has trouble, then another message
|
61
61
|
after he has decided to stop trying, the format is a little different. The block
|
62
|
-
given
|
62
|
+
given in previous examples is stored in the +params+ as +action+.
|
63
63
|
|
64
64
|
Instead, the +action+ block may be specified directly as a member of the params hash,
|
65
65
|
and the +final+ must be specified in this way if it is to be used.
|
data/README
CHANGED
@@ -55,7 +55,7 @@ There are several alternatives to REC which may suit your needs better:
|
|
55
55
|
* scalextreme.com[www.scalextreme.com]
|
56
56
|
|
57
57
|
While I like these options, I find they take a lot of configuring.
|
58
|
-
They also
|
58
|
+
They also have some dependencies that make them a bit heavier than you may want.
|
59
59
|
If you just want to keep track of a few kinds of events, want a lot of flexibility
|
60
60
|
and control without too much effort, then REC may be of some value.
|
61
61
|
|
@@ -85,7 +85,7 @@ We can also 'swallow' all of the rest of the "host terra is down" events because
|
|
85
85
|
This <em>event compression</em> means the administrator gets one important message, and not 27
|
86
86
|
distracting alerts.
|
87
87
|
|
88
|
-
A
|
88
|
+
A notification can be sent by email or instant message, depending on your preferences and working hours.
|
89
89
|
The destinations and credentials are supplied to your ruleset:
|
90
90
|
# For better security, move the next few lines into a file readable only by
|
91
91
|
# the user running this script eg. /home/rec/alert.conf
|
@@ -154,7 +154,7 @@ The sequence of captures is as specified for ruby Regexps.
|
|
154
154
|
:pattern => /\w+ sudo\: (\w+) \: (\d) incorrect password attempts/,
|
155
155
|
:details => ["userid", "failures"],
|
156
156
|
The names chosen for captured values are used as keys to store the values in the same
|
157
|
-
hash that stores the parameters, so do *not* choose
|
157
|
+
hash that stores the parameters, so do *not* choose the following keywords: +pattern+, +details+,
|
158
158
|
+message+, +threshold+, +lifespan+, +alert+, +capture+, +continue+, or +action+.
|
159
159
|
|
160
160
|
=== message
|
@@ -179,7 +179,7 @@ minutes longer at each request.
|
|
179
179
|
This is a string template used to generate an output log message (the timestamp will be
|
180
180
|
prefixed automatically to complete the log entry).
|
181
181
|
:alert => "'Too much sudo activity' userid=%userid$s attempts=%count$d dur=%dur$0.3fs ",
|
182
|
-
By convention, we make
|
182
|
+
By convention, we make our log messages very easy to parse by creating name=value pairs,
|
183
183
|
and single-quoting strings containing spaces, in case the output will be processed further.
|
184
184
|
|
185
185
|
If no +alert+ is provided, it will default to +message+.
|
metadata
CHANGED
@@ -1,13 +1,13 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: rec
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
hash:
|
4
|
+
hash: 17
|
5
5
|
prerelease:
|
6
6
|
segments:
|
7
7
|
- 1
|
8
8
|
- 3
|
9
|
-
-
|
10
|
-
version: 1.3.
|
9
|
+
- 5
|
10
|
+
version: 1.3.5
|
11
11
|
platform: ruby
|
12
12
|
authors:
|
13
13
|
- Richard Kernahan
|
@@ -15,7 +15,7 @@ autorequire:
|
|
15
15
|
bindir: bin
|
16
16
|
cert_chain: []
|
17
17
|
|
18
|
-
date: 2013-
|
18
|
+
date: 2013-10-10 00:00:00 Z
|
19
19
|
dependencies:
|
20
20
|
- !ruby/object:Gem::Dependency
|
21
21
|
name: xmpp4r
|
@@ -32,7 +32,11 @@ dependencies:
|
|
32
32
|
version: "0.5"
|
33
33
|
type: :runtime
|
34
34
|
version_requirements: *id001
|
35
|
-
description: "\t\
|
35
|
+
description: "\t\tDeprecated. \n\
|
36
|
+
\t\tI'm planning to discontinue this gem. Although it has enormous flexibility and power, \n\
|
37
|
+
\t\tit is in my view too complex. 80% of requirements can be met through custom shell scripts\n\
|
38
|
+
\t\twhich are much simpler to write and maintain. \n\n\
|
39
|
+
\t\tSifts through your log files in real time, using stateful intelligence to determine\n\
|
36
40
|
\t\twhat is really important. REC can alert you (by email or IM) or it can simply condense\n\
|
37
41
|
\t\ta large log file into a much shorter and more meaningful log.\n\
|
38
42
|
\t\tREC is inspired by Risto Vaarandi's brilliant *sec* (simple-evcorr.sourceforge.net)\n\
|