[Logcheck-commits] CVS logcheck/docs

[CVS User maks-guest]

Update of /cvsroot/logcheck/logcheck/docs
In directory haydn:/tmp/cvs-serv28507/docs

Modified Files:
	README.logcheck-database 
Log Message:

remove accidental trailing whitespace


--- /cvsroot/logcheck/logcheck/docs/README.logcheck-database	2005/07/18 21:39:02	1.11
+++ /cvsroot/logcheck/logcheck/docs/README.logcheck-database	2005/07/18 21:50:37	1.12
@@ -33,7 +33,7 @@
 	at one layer are not carried over to lower layers.
 
 2. the "SECURITY EVENTS" layer, designed to detect less critical
-	events still considered worthy of special attention. 
+	events still considered worthy of special attention.
 
    Patterns raising the alarm go in "/etc/logcheck/violations.d";
 	matches with these result in a "Security Events" alert,
@@ -71,63 +71,63 @@
 
 ./<packagename>
 
-Contains filters relevant to only one Debian package - for example 
+Contains filters relevant to only one Debian package - for example
 if "fooserver" logs suspicious events like this:
 "$DATE $HOSTNAME fooserver[$PID]: $USER is up to no good"
-then a line in "/etc/logcheck/violations.d/fooserver" with an 
-appropriate pattern will promote it from a mere "System Event" 
-to a full "Security Event" in a subsection of the mailing headed 
-"fooserver".  Or then again if that kind of log message is more 
-trivial than it looks (maybe "foo" is a networked game of 
-spy-and-counterspy) then a line in 
-"/etc/logcheck/ignore.d.server/fooserver" will turn it into a 
+then a line in "/etc/logcheck/violations.d/fooserver" with an
+appropriate pattern will promote it from a mere "System Event"
+to a full "Security Event" in a subsection of the mailing headed
+"fooserver".  Or then again if that kind of log message is more
+trivial than it looks (maybe "foo" is a networked game of
+spy-and-counterspy) then a line in
+"/etc/logcheck/ignore.d.server/fooserver" will turn it into a
 nonevent for all but the most assiduous of administrators.
 
 Sometimes a package will have not only special alarm calls which
 _do_ need to be "Security Events" triggers but also exceptional
-variants which _don't_ - maybe it logs either 
-    "$DATE $HOSTNAME fooserver[$PID]: $USER barred" 
+variants which _don't_ - maybe it logs either
+    "$DATE $HOSTNAME fooserver[$PID]: $USER barred"
 or
-    "$DATE $HOSTNAME fooserver[$PID]: none barred".  
-In this situation the alarm can be overruled by a 
-violations.ignore rulefile named "fooserver" which filters 
+    "$DATE $HOSTNAME fooserver[$PID]: none barred". 
+In this situation the alarm can be overruled by a
+violations.ignore rulefile named "fooserver" which filters
 "none barred".  This will _not_ affect other "Security Events"
 featuring the words "none barred" (that might allow crackers to

[92 lines skipped]