commit 335fae968928110755ec02422b6463e5676fec93 Author: W. David Ashley w.david.ashley@gmail.com Date: Wed Jul 8 10:54:35 2015 -0500
General - removed Event Loop Integration from the Connections Chapter and created a new chapter for it - removed Debugging section from the Connections chapter and created a new chapter for it - removed Security Model section from the Connections chapter and created a new chapter for it - added the index
en-US/Connections.xml | 137 -------------------- en-US/Debugging.xml | 122 +++++++++++++++++ en-US/Event_Loop_Integration.xml | 15 ++ ..._Application_Development_Guide_Using_Python.xml | 4 + en-US/Security_Model.xml | 15 ++ 5 files changed, 156 insertions(+), 137 deletions(-) --- diff --git a/en-US/Connections.xml b/en-US/Connections.xml index f46cfcb..b08c64c 100644 --- a/en-US/Connections.xml +++ b/en-US/Connections.xml @@ -1195,141 +1195,4 @@ command -p port [-l username] hostname netcat -U socket
</section>
- <section id="libvirt_application_development_guide_using_python-Connections-Event_Loop"> - <title>Event loop integration</title> - <indexterm><primary>Event loop integration</primary></indexterm> - <para> - Unlike the libvirt C interface, the Python libvirt module does not provide a - mechanism for event loop integration. This is a known problem and may be addressed - in a future version of the libvirt module. - </para> - </section> - - <section id="libvirt_application_development_guide_using_python-Connections-Security"> - <title>Security model</title> - <indexterm><primary>Security model</primary></indexterm> - <para> - Unlike the libvirt C interface, the Python libvirt module does not provide a - mechanism for accessing the security model. This is a known problem and may be addressed - in a future version of the libvirt module. - </para> - </section> - - <section id="libvirt_application_development_guide_using_python-Connections-Debug"> - <title>Debugging / logging</title> - <indexterm><primary>Debugging</primary></indexterm> - <indexterm><primary>Logging</primary></indexterm> - <para> - Libvirt includes logging facilities to facilitate the tracing of library - execution. These logs will frequently be requested when trying to - obtain support for libvirt, so familiarity with them is essential. - </para> - <para> - The logging facilities in libvirt are based on 3 key concepts: - </para> - <orderedlist> - <listitem> - <para> - Log messages - generated at runtime by the libvirt code, they include - a timestamp, a priority level (DEBUG = 1, INFO = 2, WARNING = 3, ERROR = 4), - a category, function name and line number indicating where the - message originated from, and a formatted message. - </para> - </listitem> - <listitem> - <para> - Log filters - patterns and priorities which control whether or - not a particular message is displayed. The format for a filter is: - </para> - <para><screen>x:name</screen></para> - <para> - where "x" is the minimal priority level where the match should apply, and - "name" is a string to match against. The priority levels are: - </para> - <itemizedlist> - <listitem><para>1 (or debug) - log all messages</para></listitem> - <listitem><para>2 (or info) - log all non-debugging information</para></listitem> - <listitem><para>3 (or warn) - log only warnings and errors - this is the default</para></listitem> - <listitem><para>4 (or error) - log only errors</para></listitem> - </itemizedlist> - <para> - For instance, to log all debug messages to the qemu driver, the - following filter can be used: - </para> - <para><screen>1:qemu</screen></para> - <para> - Multiple filters can be specified together by space separating them; - the following example logs all debug messages from qemu, and logs - all error messages from the remote driver: - </para> - <para><screen>1:qemu 4:remote</screen></para> - </listitem> - <listitem> - <para> - Log outputs - where to send the message once it has passed - through filters. The format for a log output is one of the forms: - </para> - <para> -<screen>x:stderr - log to stderr -x:syslog:name - log to syslog with a prefix of "name" -x:file:file_path - log to a file specified by "file_path"</screen> - </para> - <para> - where "x" is the minimal priority level. For instance, to log all - warnings and errors to syslog with a prefix of "libvirtd", the - following output can be used: - </para> - <para><screen>3:syslog:libvirtd</screen></para> - <para> - Multiple outputs can be specified by space separating them; the - following example logs all error and warning messages to syslog, and - logs all debug, information, warning, and error messages to - <filename>/tmp/libvirt.log</filename>: - </para> - <para><screen>3:syslog:libvirtd 1:file:/tmp/libvirt.log</screen></para> - </listitem> - </orderedlist> - - <section> - <title>Environment Variables</title> - <para> - The desired log priority level, filters, and outputs are specified to - the libvirt library through the use of environment variables: - </para> - <orderedlist> - <listitem> - <para> - <literal>LIBVIRT_DEBUG</literal> specifies the minimum priority level messages that - will be logged. This can be thought of as a "global" priority level; - if a particular log message does not match a specific filter in - <literal>LIBVIRT_LOG_FILTERS</literal>, it will be compared to this global priority and - logged as appropriate. - </para> - </listitem> - <listitem> - <para> - <literal>LIBVIRT_LOG_FILTERS</literal> specifies the filters to apply. - </para> - </listitem> - <listitem> - <para> - <literal>LIBVIRT_LOG_OUTPUTS</literal> specifies the outputs to send the message to. - </para> - </listitem> - </orderedlist> - <example> - <title>Running virsh with environment variables</title> - <para> - To see more detailed information about what is going on with virsh, - we may run it like the following: - </para> -<screen><command>LIBVIRT_DEBUG=error LIBVIRT_LOG_FILTERS="1:remote" virsh list</command></screen> - <para> - This example will only print error messages from virsh, <emphasis>except</emphasis> that - the remote driver will print all debug, information, warning, and - error messages. - </para> - </example> - </section> - </section> </chapter> diff --git a/en-US/Debugging.xml b/en-US/Debugging.xml new file mode 100644 index 0000000..e118249 --- /dev/null +++ b/en-US/Debugging.xml @@ -0,0 +1,122 @@ +<?xml version='1.0' encoding='utf-8' ?> +<!DOCTYPE bookinfo PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +<!ENTITY % BOOK_ENTITIES SYSTEM "Libvirt_Application_Development_Guide_Using_Python.ent"> +%BOOK_ENTITIES; +]> +<chapter id="libvirt_application_development_guide_using_python-Debug"> + <title>Debugging / Logging</title> + <indexterm><primary>Debugging</primary></indexterm> + <indexterm><primary>Logging</primary></indexterm> + <para> + Libvirt includes logging facilities to facilitate the tracing of library + execution. These logs will frequently be requested when trying to + obtain support for libvirt, so familiarity with them is essential. + </para> + <para> + The logging facilities in libvirt are based on 3 key concepts: + </para> + <orderedlist> + <listitem> + <para> + Log messages - generated at runtime by the libvirt code, they include + a timestamp, a priority level (DEBUG = 1, INFO = 2, WARNING = 3, ERROR = 4), + a category, function name and line number indicating where the + message originated from, and a formatted message. + </para> + </listitem> + <listitem> + <para> + Log filters - patterns and priorities which control whether or + not a particular message is displayed. The format for a filter is: + </para> + <para><screen>x:name</screen></para> + <para> + where "x" is the minimal priority level where the match should apply, and + "name" is a string to match against. The priority levels are: + </para> + <itemizedlist> + <listitem><para>1 (or debug) - log all messages</para></listitem> + <listitem><para>2 (or info) - log all non-debugging information</para></listitem> + <listitem><para>3 (or warn) - log only warnings and errors - this is the default</para></listitem> + <listitem><para>4 (or error) - log only errors</para></listitem> + </itemizedlist> + <para> + For instance, to log all debug messages to the qemu driver, the + following filter can be used: + </para> + <para><screen>1:qemu</screen></para> + <para> + Multiple filters can be specified together by space separating them; + the following example logs all debug messages from qemu, and logs + all error messages from the remote driver: + </para> + <para><screen>1:qemu 4:remote</screen></para> + </listitem> + <listitem> + <para> + Log outputs - where to send the message once it has passed + through filters. The format for a log output is one of the forms: + </para> + <para> +<screen>x:stderr - log to stderr +x:syslog:name - log to syslog with a prefix of "name" +x:file:file_path - log to a file specified by "file_path"</screen> + </para> + <para> + where "x" is the minimal priority level. For instance, to log all + warnings and errors to syslog with a prefix of "libvirtd", the + following output can be used: + </para> + <para><screen>3:syslog:libvirtd</screen></para> + <para> + Multiple outputs can be specified by space separating them; the + following example logs all error and warning messages to syslog, and + logs all debug, information, warning, and error messages to + <filename>/tmp/libvirt.log</filename>: + </para> + <para><screen>3:syslog:libvirtd 1:file:/tmp/libvirt.log</screen></para> + </listitem> + </orderedlist> + + <section> + <title>Environment Variables</title> + <para> + The desired log priority level, filters, and outputs are specified to + the libvirt library through the use of environment variables: + </para> + <orderedlist> + <listitem> + <para> + <literal>LIBVIRT_DEBUG</literal> specifies the minimum priority level messages that + will be logged. This can be thought of as a "global" priority level; + if a particular log message does not match a specific filter in + <literal>LIBVIRT_LOG_FILTERS</literal>, it will be compared to this global priority and + logged as appropriate. + </para> + </listitem> + <listitem> + <para> + <literal>LIBVIRT_LOG_FILTERS</literal> specifies the filters to apply. + </para> + </listitem> + <listitem> + <para> + <literal>LIBVIRT_LOG_OUTPUTS</literal> specifies the outputs to send the message to. + </para> + </listitem> + </orderedlist> + <example> + <title>Running virsh with environment variables</title> + <para> + To see more detailed information about what is going on with virsh, + we may run it like the following: + </para> +<screen><command>LIBVIRT_DEBUG=error LIBVIRT_LOG_FILTERS="1:remote" virsh list</command></screen> + <para> + This example will only print error messages from virsh, <emphasis>except</emphasis> that + the remote driver will print all debug, information, warning, and + error messages. + </para> + </example> + </section> +</chapter> diff --git a/en-US/Event_Loop_Integration.xml b/en-US/Event_Loop_Integration.xml new file mode 100644 index 0000000..22977f8 --- /dev/null +++ b/en-US/Event_Loop_Integration.xml @@ -0,0 +1,15 @@ +<?xml version='1.0' encoding='utf-8' ?> +<!DOCTYPE bookinfo PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +<!ENTITY % BOOK_ENTITIES SYSTEM "Libvirt_Application_Development_Guide_Using_Python.ent"> +%BOOK_ENTITIES; +]> +<chapter id="libvirt_application_development_guide_using_python-Event_Loop"> + <title>Event Loop Integration</title> + <indexterm><primary>Event loop integration</primary></indexterm> + <para> + Unlike the libvirt C interface, the Python libvirt module does not provide a + mechanism for event loop integration. This is a known problem and may be addressed + in a future version of the libvirt module. + </para> + +</chapter> diff --git a/en-US/Libvirt_Application_Development_Guide_Using_Python.xml b/en-US/Libvirt_Application_Development_Guide_Using_Python.xml index 39d4cbb..efe3256 100644 --- a/en-US/Libvirt_Application_Development_Guide_Using_Python.xml +++ b/en-US/Libvirt_Application_Development_Guide_Using_Python.xml @@ -16,5 +16,9 @@ <xi:include href="Host_Devices.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="Error_Handling.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="Event_Handling.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Event_Loop_Integration.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Security_Model.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <xi:include href="Debugging.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> <xi:include href="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> + <index></index> </book> diff --git a/en-US/Security_Model.xml b/en-US/Security_Model.xml new file mode 100644 index 0000000..b5d2da7 --- /dev/null +++ b/en-US/Security_Model.xml @@ -0,0 +1,15 @@ +<?xml version='1.0' encoding='utf-8' ?> +<!DOCTYPE bookinfo PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ +<!ENTITY % BOOK_ENTITIES SYSTEM "Libvirt_Application_Development_Guide_Using_Python.ent"> +%BOOK_ENTITIES; +]> + +<chapter id="libvirt_application_development_guide_using_python-Security"> + <title>Security Model</title> + <indexterm><primary>Security model</primary></indexterm> + <para> + Unlike the libvirt C interface, the Python libvirt module does not provide a + mechanism for accessing the security model. This is a known problem and may be addressed + in a future version of the libvirt module. + </para> +</chapter>
docs-commits@lists.fedoraproject.org