[Openvas-commits] r3367 - trunk/doc/website

scm-commit@wald.intevation.org scm-commit at wald.intevation.org
Thu May 14 11:06:46 CEST 2009


Author: lmwangi
Date: 2009-05-14 11:06:46 +0200 (Thu, 14 May 2009)
New Revision: 3367

Modified:
   trunk/doc/website/openvas-cr-29.htm4
Log:
CR-29 Update - Cleanup and adding sample log_domains 

Modified: trunk/doc/website/openvas-cr-29.htm4
===================================================================
--- trunk/doc/website/openvas-cr-29.htm4	2009-05-14 08:57:05 UTC (rev 3366)
+++ trunk/doc/website/openvas-cr-29.htm4	2009-05-14 09:06:46 UTC (rev 3367)
@@ -33,15 +33,20 @@
 <h3>Purpose</h3>
 
 <p>
-Improve error reporting across all subsystem from the current 
-output redirection
-of printf statement
+Improve error reporting across all subsystems from the current 
+output redirection of printf statement
 </p>
 
 <h3>References</h3>
 
 <p>
-(None)
+Related Mail threads:<br />
+<ul>
+ <li><a href="http://lists.wald.intevation.org/pipermail/openvas-devel/2009-April/001477.html">Initial Patch</a> mail thread</li>
+ <li>Second <a href="http://lists.wald.intevation.org/pipermail/openvas-devel/2009-May/001500.html">Patch</a> mail thread</li>
+</ul>
+While using the latest patch, you may want to modify a library to call glib logging functions. 
+A sample is included in the first patch (nasl_grammar and nasl_socket) 
 </p>
 
 <h3>Rationale</h3>
@@ -64,19 +69,26 @@
 
 <p>
 The design goals should be to reuse the existing glib message output and
-debug functions to accomplish this.<br />
-Use of g_log for all logging within OpenVAS.<br />
+debug functions to accomplish this by using g_log for all logging within OpenVAS.<br />
 <ul>
 <li>Definition of various G_LOG_DOMAINs within the source files to identify library/subsystem/operation message sources. e.g. log_domain_ssl,</li>
+<li>Use of predefined log domains such as</li>
+<ul>
+	<li>log_domain_otp - protocol dump</li>
+	<li>log_domain_ssl - SSL debug messages</li>
+	<li>log_domain_scripts - Dependency failures, Script errors</li>
+	<li>log_domain_libnasl - Libnasl messages that can't be categorized by the above</li>
+	<li>log_domain_libopenvas - Libopenvas messages that can't be categorized by the above</li>
+	<li>log_domain_openvasd - openvasd messages that can't be categorized by the above</li>
+</ul>
 <li>We also have to add "if (!g_thread_supported ()) g_thread_init (NULL);" openvasd's main() to make logging thread safe. This means that we have to add gthread include and cflags to the autoconf scripts </li>
 <li>Use of g_log_set_handler () in openvasd's main() to dynamically route messages to different logfiles depending on the domain and log_level (severity) giving flexibility surpassing apache's access and error logfiles </li>
 <li>Using glib's IO Channels to handle log output to files</li>
 <li>Definition of a prepend string in a config file much like PHP's html error prepend string based on the following proposal:</li>
 	<ul>
 	<li>%P: PID</li>
-	<li>%{format}t: Format string to format glib's GTimeVal</li>
-	<li>%u: Remote user</li>
-	<li>Use of __LINE__ and __FILE__ in debug messages..?</li>
+	<li>%{format}t: strftime format string (resolution is down to the second level)</li>
+	<li>Use of __LINE__ and __FILE__ in debug messages - Left to the devloper's discretion </li>
 	</ul>
 <li>If we have time and manpower, use assert statements to catch bugs we wouldn't know about - Have a look at glib-Warnings-and-Assertions.html in glib's documentation</li>
 </ul>
@@ -111,10 +123,10 @@
 </pre>
 
 </p>
-
 <h3>History</h3>
 
 <ul>
+<li> 2009-05-14 Laban Mwangi &lt;lmwangi at penguinlabs.co.ke&gt;:<br/> Adding predefined log_domains.</li>
 <li> 2009-04-28 Laban Mwangi &lt;lmwangi at penguinlabs.co.ke&gt;:<br/> Adding a configuration example.</li>
 <li> 2009-04-25 Laban Mwangi &lt;lmwangi at penguinlabs.co.ke&gt;:<br/> Adding details based on testing.</li>
 <li> 2009-04-14 Laban Mwangi &lt;lmwangi at penguinlabs.co.ke&gt;:<br/> Integrating with glib logging.</li>



More information about the Openvas-commits mailing list