doc/developer-guidelines.sgml

   1 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
   2 <book>
   3   <title>Nagios Plug-in Developer Guidelines</title>
   4
   5   <bookinfo>
   6     <authorgroup>
   7       <author>
   8         <firstname>Karl</firstname>
   9         <surname>DeBisschop</surname>
  10         <affiliation>
  11           <address><email>karl@debisschop.net</email></address>
  12         </affiliation>
  13       </author>
  14
  15       <author>
  16         <firstname>Ethan</firstname>
  17         <surname>Galstad</surname>
  18         <authorblurb>
  19           <para>Author of Nagios</para>
  20           <para><ulink url="http://www.nagios.org"></ulink></para>
  21         </authorblurb>
  22         <affiliation>
  23           <address><email>netsaint@linuxbox.com</email></address>
  24         </affiliation>
  25       </author>
  26
  27       <author>
  28         <firstname>Hugo</firstname>
  29         <surname>Gayosso</surname>
  30         <affiliation>
  31           <address><email>hgayosso@gnu.org</email></address>
  32         </affiliation>
  33       </author>
  34
  35
  36         <author>
  37         <firstname>Subhendu</firstname>
  38         <surname>Ghosh</surname>
  39         <affiliation>
  40                 <address><email>sghosh@sourceforge.net</email></address>
  41         </affiliation>
  42         </author>
  43
  44         <author>
  45         <firstname>Stanley</firstname>
  46         <surname>Hopcroft</surname>
  47         <affiliation>
  48                 <address><email>stanleyhopcroft@sourceforge.net</email></address>
  49         </affiliation>
  50         </author>
  51
  52     </authorgroup>
  53
  54     <pubdate>2002</pubdate>
  55     <title>Nagios plug-in development guidelines</title>
  56
  57     <revhistory>
  58        <revision>
  59           <revnumber>0.4</revnumber>
  60           <date>2 May 2002</date>
  61        </revision>
  62     </revhistory>
  63
  64         <copyright>
  65                 <year>2000 2001 2002</year>
  66                 <holder>Karl DeBisschop, Ethan Galstad,
  67                 Hugo Gayosso, Stanley Hopcroft, Subhendu Ghosh</holder>
  68         </copyright>
  69
  70 </bookinfo>
  71
  72
  73 <preface id="preface"><title>Preface</title>
  74     <para>The purpose of this guidelines is to provide a reference for
  75     the plug-in developers and encourage the standarization of the
  76     different kind of plug-ins: C, shell, perl, python, etc.</para>
  77
  78         <para>Nagios Plug-in Development Guidelines Copyright (C) 2000 2001
  79                 2002
  80         Karl DeBisschop, Ethan Galstad, Hugo Gayosso, Stanley Hopcroft,
  81                 Subhendu Ghosh</para>
  82
  83         <para>Permission is granted to make and distribute verbatim
  84         copies of this manual provided the copyright notice and this
  85         permission notice are preserved on all copies.</para>
  86
  87         <para>The plugins themselves are copyrighted by their respective
  88         authors.</para>
  89 </preface>
  90
  91 <article>
  92 <section id="DevRequirements"><title>Development platform requirements</title>
  93         <para>
  94         Nagios plugins are developed to the GNU standard, so any OS which is supported by GNU
  95         should run the plugins. While the requirements for compiling the Nagios plugins release
  96         is very small, to develop from CVS needs additional software to be installed. These are the
  97         minimum levels of software required:
  98
  99         <literallayout>
 100         gnu make 3.79
 101         automake 1.6
 102         autoconf 2.52
 103         gettext 0.11.5
 104         </literallayout>
 105
 106         To compile from CVS, after you have checked out the code, run:
 107         <literallayout>
 108         tools/setup
 109         ./configure
 110         make
 111         make install
 112         </literallayout>
 113         </para>
 114 </section>
 115
 116 <section id="PlugOutput"><title>Plugin Output for Nagios</title>
 117
 118                 <para>You should always print something to STDOUT that tells if the
 119                 service is working or why its failing. Try to keep the output short -
 120                 probably less that 80 characters. Remember that you ideally would like
 121                 the entire output to appear in a pager message, which will get chopped
 122                 off after a certain length.</para>
 123
 124                 <section><title>Print only one line of text</title>
 125                 <para>Nagios will only grab the first line of text from STDOUT
 126                 when it notifies contacts about potential problems. If you print
 127                 multiple lines, you're out of luck. Remember, keep it short and
 128                 to the point.</para>
 129                 </section>
 130
 131                 <section><title>Verbose output</title>
 132                 <para>Use the -v flag for verbose output. You should allow multiple
 133                 -v options for additional verbosity, up to a maximum of 3. The standard
 134                 type of output should be:</para>
 135
 136                 <table id="verbose_levels"><title>Verbose output levels</title>
 137                         <tgroup cols="2">
 138                                 <thead>
 139                                         <row>
 140                                                 <entry><para>Verbosity level</para></entry>
 141                                                 <entry><para>Type of output</para></entry>
 142                                         </row>
 143                                 </thead>
 144                                 <tbody>
 145                                         <row>
 146                                                 <entry align=center><para>0</para></entry>
 147                                                 <entry><para>Single line, minimal output. Summary</para></entry>
 148                                         </row>
 149                                         <row>
 150                                                 <entry align=center><para>1</para></entry>
 151                                                 <entry><para>Single line, additional information (eg list processes that fail)</para></entry>
 152                                         </row>
 153                                         <row>
 154                                                 <entry align=center><para>2</para></entry>
 155                                                 <entry><para>Multi line, configuration debug output (eg ps command used)</para></entry>
 156                                         </row>
 157                                         <row>
 158                                                 <entry align=center><para>3</para></entry>
 159                                                 <entry><para>Lots of detail for plugin problem diagnosis</para></entry>
 160                                         </row>
 161                                 </tbody>
 162                         </tgroup>
 163                 </table>
 164                 </section>
 165
 166                 <section><title>Screen Output</title>
 167                 <para>The plug-in should print the diagnostic and just the
 168                 synopsis part of the help message.  A well written plugin would
 169                 then have --help as a way to get the verbose help.</para>
 170                 <para>Code and output should try to respect the 80x25 size of a
 171                 crt (remember when fixing stuff in the server room!)</para>
 172                 </section>
 173
 174             <section><title>Return the proper status code</title>
 175                 <para>See <xref linkend="ReturnCodes"> below
 176                 for the numeric values of status codes and their
 177                 description. Remember to return an UNKNOWN state if bogus or
 178                 invalid command line arguments are supplied or it you are unable
 179                 to check the service.</para>
 180                 </section>
 181
 182                 <section><title>Plugin Return Codes</title>
 183                 <para>The return codes below are based on the POSIX spec of returning
 184                 a positive value.  Netsaint prior to v0.0.7 supported non-POSIX
 185                 compliant return code of "-1" for unknown.  Nagios supports POSIX return
 186                 codes by default.</para>
 187
 188                 <para>Note: Some plugins will on occasion print on STDOUT that an error
 189                 occurred and error code is 138 or 255 or some such number.  These
 190                 are usually caused by plugins using system commands and having not
 191                 enough checks to catch unexpected output.  Developers should include a
 192                 default catch-all for system command output that returns an UNKNOWN
 193                 return code.</para>
 194
 195                 <table id="ReturnCodes"><title>Plugin Return Codes</title>
 196                         <tgroup cols="3">
 197                                 <thead>
 198                                         <row>
 199                                                 <entry><para>Numeric Value</para></entry>
 200                                                 <entry><para>Service Status</para></entry>
 201                                                 <entry><para>Status Description</para></entry>
 202                                         </row>
 203                                 </thead>
 204                                 <tbody>
 205                                         <row>
 206                                                 <entry align=center><para>0</para></entry>
 207                                                 <entry valign=middle><para>OK</para></entry>
 208                                                 <entry><para>The plugin was able to check the service and it
 209                                                 appeared to be functioning properly</para></entry>
 210                                         </row>
 211                                         <row>
 212                                                 <entry align=center><para>1</para></entry>
 213                                                 <entry valign=middle><para>Warning</para></entry>
 214                                                 <entry><para>The plugin was able to check the service, but it
 215                                                 appeared to be above some "warning" threshold or did not appear
 216                                                 to be working properly</para></entry>
 217                                         </row>
 218                                         <row>
 219                                                 <entry align=center><para>2</para></entry>
 220                                                 <entry valign=middle><para>Critical</para></entry>
 221                                                 <entry><para>The plugin detected that either the service was not
 222                                                 running or it was above some "critical" threshold</para></entry>
 223                                         </row>
 224                                         <row>
 225                                                 <entry align=center><para>3</para></entry>
 226                                                 <entry valign=middle><para>Unknown</para></entry>
 227                                                 <entry><para>Invalid command line arguments were supplied to the
 228                                                 plugin or the plugin was unable to check the status of the given
 229                                                 hosts/service</para></entry>
 230                                         </row>
 231                                 </tbody>
 232                         </tgroup>
 233                 </table>
 234
 235
 236                 </section>
 237
 238                 <section><title>Performance data</title>
 239                 <para>Performance data is defined by Nagios as "everything after the | of the plugin output" -
 240                 please refer to Nagios documentation for information on capturing this data to logfiles.
 241                 However, it is the responsibility of the plugin writer to ensure the
 242                 performance data is in a "Nagios plugins" format.
 243                 This is the expected format:</para>
 244
 245                 <literallayout>
 246                 'label'=value[UOM];[warn];[crit];[min];[max]
 247                 </literallayout>
 248
 249                 <para>Notes:</para>
 250                 <orderedlist>
 251                 <listitem><para>space separated list of label/value pairs</para>
 252                         </listitem>
 253                 <listitem><para>label can contain any characters</para>
 254                         </listitem>
 255                 <listitem><para>the single quotes for the label are optional. Required if
 256                         spaces, = or ' are in the label</para>
 257                         </listitem>
 258                 <listitem><para>label length is arbitrary, but ideally the first 19 characters
 259                         are unique (due to a limitation in RRD). Be aware of a limitation in the
 260                         amount of data that NRPE returns to Nagios</para>
 261                         </listitem>
 262                 <listitem><para>to specify a quote character, use two single quotes</para>
 263                         </listitem>
 264                 <listitem><para>warn, crit, min or max may be null (for example, if the threshold is
 265                         not defined or min and max do not apply). Trailing unfilled semicolons can be
 266                         dropped</para>
 267                         </listitem>
 268                 <listitem><para>min and max are not required if UOM=%</para>
 269                         </listitem>
 270                 <listitem><para>value, crit, warn, max and min in class [-0-9.]. Must all be the
 271                         same UOM</para>
 272                         </listitem>
 273                 <listitem><para>UOM (unit of measurement) is one of:</para>
 274                         <orderedlist>
 275                         <listitem><para>no unit specified - assume a number (int or float)
 276                                 of things (eg, users, processes, load averages)</para>
 277                                 </listitem>
 278                         <listitem><para>s - seconds (also us, ms)</para></listitem>
 279                         <listitem><para>% - percentage</para></listitem>
 280                         <listitem><para>B - bytes (also KB, MB, TB)</para></listitem>
 281                         <listitem><para>c - a continous counter (such as bytes
 282                                 transmitted on an interface)</para></listitem>
 283                         </orderedlist>
 284                         </listitem>
 285                 </orderedlist>
 286
 287                 <para>It is up to third party programs to convert the Nagios plugins
 288                 performance data into graphs.</para>
 289                 </section>
 290 </section>
 291
 292 <section id="SysCmdAuxFiles"><title>System Commands and Auxiliary Files</title>
 293
 294                 <section><title>Don't execute system commands without specifying their
 295                 full path</title>
 296                 <para>Don't use exec(), popen(), etc. to execute external
 297                 commands without explicity using the full path of the external
 298                 program.</para>
 299
 300                 <para>Doing otherwise makes the plugin vulnerable to hijacking
 301                 by a trojan horse earlier in the search path. See the main
 302                 plugin distribution for examples on how this is done.</para>
 303                 </section>
 304
 305                 <section><title>Use spopen() if external commands must be executed</title>
 306
 307             <para>If you have to execute external commands from within your
 308         plugin and you're writing it in C, use the spopen() function
 309                 that Karl DeBisschop has written.</para>
 310
 311                 <para>The code for spopen() and spclose() is included with the
 312                 core plugin distribution.</para>
 313                 </section>
 314
 315                 <section><title>Don't make temp files unless absolutely required</title>
 316
 317                 <para>If temp files are needed, make sure that the plugin will
 318                 fail cleanly if the file can't be written (e.g., too few file
 319                 handles, out of disk space, incorrect permissions, etc.) and
 320                 delete the temp file when processing is complete.</para>
 321                 </section>
 322
 323         <section><title>Don't be tricked into following symlinks</title>
 324
 325                 <para>If your plugin opens any files, take steps to ensure that
 326                 you are not following a symlink to another location on the
 327                 system.</para>
 328                 </section>
 329
 330                 <section><title>Validate all input</title>
 331
 332                 <para>use routines in utils.c or utils.pm and write more as needed</para>
 333                 </section>
 334
 335 </section>
 336
 337
 338
 339
 340 <section id="PerlPlugin"><title>Perl Plugins</title>
 341
 342                 <para>Perl plugins are coded a little more defensively than other
 343                 plugins because of embedded Perl.  When configured as such, embedded
 344                 Perl Nagios (ePN) requires stricter use of the some of Perl's features.
 345                 This section outlines some of the steps needed to use ePN
 346                 effectively.</para>
 347
 348                 <orderedlist>
 349
 350                         <listitem><para> Do not use BEGIN and END blocks since they will be called
 351                         the first time and when Nagios shuts down with Embedded Perl (ePN).  In
 352                         particular, do not use BEGIN blocks to initialize variables.</para>
 353                         </listitem>
 354
 355                         <listitem><para>To use utils.pm, you need to provide a full path to the
 356                         module in order for it to work with ePN.</para>
 357
 358           <literallayout>
 359           e.g.
 360                 use lib "/usr/local/nagios/libexec";
 361                 use utils qw(...);
 362           </literallayout>
 363                         </listitem>
 364
 365                         <listitem><para>Perl scripts should be called with "-w"</para>
 366                         </listitem>
 367
 368                         <listitem><para>All Perl plugins must compile cleanly under "use strict" - i.e. at
 369                         least explicitly package names as in "$main::x" or predeclare every
 370                         variable. </para>
 371
 372
 373                         <para>Explicitly initialize each varialable in use.  Otherwise with
 374                         caching enabled, the plugin will not be recompilied each time, and
 375                         therefore Perl will not reinitialize all the variables.  All old
 376                         variable values will still be in effect.</para>
 377                         </listitem>
 378
 379                         <listitem><para>Do not use < DATA > (these simply do not compile under ePN).</para>
 380                         </listitem>
 381
 382                         <listitem><para>Do not use named subroutines</para>
 383                         </listitem>
 384
 385                         <listitem><para>If writing to a file (perhaps recording
 386                         performance data) explicitly close close it.  The plugin never
 387                         calls <emphasis role=strong>exit</emphasis>; that is caught by
 388                         p1.pl, so output streams are never closed.</para>
 389                         </listitem>
 390
 391                         <listitem><para>As in <xref linkend="runtime"> all plugins need
 392                         to monitor their runtime, specially if they are using network
 393                         resources.  Use of the <emphasis>alarm</emphasis> is recommended.
 394                         Plugins may import a default time out ($TIMEOUT) from utils.pm.
 395                         </para>
 396                         </listitem>
 397
 398                         <listitem><para>Perl plugins should import %ERRORS from utils.pm
 399                         and then "exit $ERRORS{'OK'}" rather than "exit 0"
 400                         </para>
 401                         </listitem>
 402
 403                 </orderedlist>
 404
 405 </section>
 406
 407 <section id="runtime"><title>Runtime Timeouts</title>
 408
 409                 <para>Plugins have a very limited runtime - typically 10 sec.
 410                 As a result, it is very important for plugins to maintain internal
 411                 code to exit if runtime exceeds a threshold. </para>
 412
 413                 <para>All plugins should timeout gracefully, not just networking
 414                 plugins. For instance, df may lock if you have automounted
 415                 drives and your network fails - but on first glance, who'd think
 416                 df could lock up like that.  Plus, it should just be more error
 417                 resistant to be able to time out rather than consume
 418                 resources.</para>
 419
 420                 <section><title>Use DEFAULT_SOCKET_TIMEOUT</title>
 421
 422                 <para>All network plugins should use DEFAULT_SOCKET_TIMEOUT to timeout</para>
 423
 424                 </section>
 425
 426
 427                 <section><title>Add alarms to network plugins</title>
 428
 429                 <para>If you write a plugin which communicates with another
 430                 networked host, you should make sure to set an alarm() in your
 431                 code that prevents the plugin from hanging due to abnormal
 432                 socket closures, etc. Nagios takes steps to protect itself
 433                 against unruly plugins that timeout, but any plugins you create
 434                 should be well behaved on their own.</para>
 435
 436                 </section>
 437
 438
 439
 440 </section>
 441
 442 <section id="PlugOptions"><title>Plugin Options</title>
 443
 444                 <para>A well written plugin should have --help as a way to get
 445                 verbose help. Code and output should try to respect the 80x25 size of a
 446                 crt (remember when fixing stuff in the server room!)</para>
 447
 448                 <section><title>Option Processing</title>
 449
 450                 <para>For plugins written in C, we recommend the C standard
 451                 getopt library for short options. Getopt_long is always available.
 452                 </para>
 453
 454                 <para>For plugins written in Perl, we recommend Getopt::Long module.</para>
 455
 456                 <para>Positional arguments are strongly discouraged.</para>
 457
 458                 <para>There are a few reserved options that should not be used
 459                 for other purposes:</para>
 460
 461                 <literallayout>
 462           -V version (--version)
 463           -h help (--help)
 464           -t timeout (--timeout)
 465           -w warning threshold (--warning)
 466           -c critical threshold (--critical)
 467           -H hostname (--hostname)
 468           -v verbose (--verbose)
 469                 </literallayout>
 470
 471                 <para>In addition to the reserved options above, some other standard options are:</para>
 472
 473                 <literallayout>
 474           -C SNMP community (--community)
 475           -a authentication password (--authentication)
 476           -l login name (--logname)
 477           -p port or password (--port or --passwd/--password)monitors operational
 478           -u url or username (--url or --username)
 479                 </literallayout>
 480
 481                 <para>Look at check_pgsql and check_procs to see how I currently
 482                 think this can work.  Standard options are:</para>
 483
 484
 485                 <para>The option -V or --version should be present in all
 486                 plugins. For C plugins it should result in a call to print_revision, a
 487                 function in utils.c which takes two character arguments, the
 488                 command name and the plugin revision.</para>
 489
 490                 <para>The -? option, or any other unparsable set of options,
 491                 should print out a short usage statement. Character width should
 492                 be 80 and less and no more that 23 lines should be printed (it
 493                 should display cleanly on a dumb terminal in a server
 494                 room).</para>
 495
 496                 <para>The option -h or --help should be present in all plugins.
 497                 In C plugins, it should result in a call to print_help (or
 498                 equivalent).  The function print_help should call print_revision,
 499                 then print_usage, then should provide detailed
 500                 help. Help text should fit on an 80-character width display, but
 501                 may run as many lines as needed.</para>
 502
 503                 <para>The option -v or --verbose should be present in all plugins.
 504                 The user should be allowed to specify -v multiple times to increase
 505                 the verbosity level, as described in <xref linkend="verbose_levels">.</para>
 506     </section>
 507
 508     <section>
 509       <title>Plugins with more than one type of threshold, or with
 510       threshold ranges</title>
 511
 512       <para>Old style was to do things like -ct for critical time and
 513       -cv for critical value. That goes out the window with POSIX
 514       getopt. The allowable alternatives are:</para>
 515
 516       <orderedlist>
 517         <listitem>
 518           <para>long options like -critical-time (or -ct and -cv, I
 519           suppose).</para>
 520         </listitem>
 521
 522         <listitem>
 523           <para>repeated options like `check_load -w 10 -w 6 -w 4 -c
 524           16 -c 10 -c 10`</para>
 525         </listitem>
 526
 527         <listitem>
 528           <para>for brevity, the above can be expressed as `check_load
 529           -w 10,6,4 -c 16,10,10`</para>
 530         </listitem>
 531
 532         <listitem>
 533           <para>ranges are expressed with colons as in `check_procs -C
 534           httpd -w 1:20 -c 1:30` which will warn above 20 instances,
 535           and critical at 0 and above 30</para>
 536         </listitem>
 537
 538         <listitem>
 539           <para>lists are expressed with commas, so Jacob's check_nmap
 540           uses constructs like '-p 1000,1010,1050:1060,2000'</para>
 541         </listitem>
 542
 543         <listitem>
 544           <para>If possible when writing lists, use tokens to make the
 545           list easy to remember and non-order dependent - so
 546           check_disk uses '-c 10000,10%' so that it is clear which is
 547           the precentage and which is the KB values (note that due to
 548           my own lack of foresight, that used to be '-c 10000:10%' but
 549           such constructs should all be changed for consistency,
 550           though providing reverse compatibility is fairly
 551           easy).</para>
 552         </listitem>
 553
 554       </orderedlist>
 555
 556       <para>As always, comments are welcome - making this consistent
 557       without a host of long options was quite a hassle, and I would
 558       suspect that there are flaws in this strategy.
 559       </para>
 560     </section>
 561 </section>
 562
 563 <section id="CodingGuidelines"><title>Coding guidelines</title>
 564         <para>See <ulink url="http://www.gnu.org/prep/standards_toc.html">GNU
 565         Coding standards</ulink> for general guidelines.</para>
 566         <section><title>Comments</title>
 567         <para>You should use /* */ for comments and not // as some compilers
 568         do not handle the latter form.</para>
 569         </section>
 570
 571         <section><title>CVS comments</title>
 572         <para>When adding CVS comments at commit time, you can use the following prefixes:
 573         <variablelist>
 574           <varlistentry><term>- comment</term>
 575           <listitem>
 576             <para>for a comment that can be removed from the Changelog</para>
 577           </listitem>
 578           </varlistentry>
 579           <varlistentry><term>* comment</term>
 580           <listitem>
 581             <para>for an important amendment to be included into a features list</para>
 582           </listitem>
 583           </varlistentry>
 584         </variablelist>
 585         </para>
 586         </section>
 587 </section>
 588
 589 <section id="SubmittingChanges"><title>Submission of new plugins and patches</title>
 590
 591         <section id="Patches"><title>Patches</title>
 592         <para>If you have a bug patch, please supply a unified or context diff against the
 593         version you are using. For new features, please supply a diff against
 594         the CVS HEAD version.</para>
 595
 596         <para>Patches should be submitted via
 597         <ulink url="http://sourceforge.net/tracker/?group_id=29880&amp;atid=397599">SourceForge's
 598         tracker system for Nagiosplug patches</ulink>
 599         and be announced to the nagiosplug-devel mailing list.</para>
 600         </section>
 601
 602         <section id="New_plugins"><title>New plugins</title>
 603         <para>If you would like others to use your plugins and have it included in
 604         the standard distribution, please include patches for the relevant
 605         configuration files, in particular "configure.in". Otherwise submitted
 606         plugins will be included in the contrib directory.</para>
 607
 608         <para>Plugins in the contrib directory are going to be migrated to the
 609         standard plugins/plugin-scripts directory as time permits and per user
 610         requests. The minimum requirements are:</para>
 611
 612       <orderedlist>
 613         <listitem>
 614           <para>The standard command options are supported (--help, --version,
 615           --timeout, --warning, --critical)</para>
 616         </listitem>
 617         <listitem>
 618           <para>It is determined to be not redundant (for instance, we would not
 619                 add a new version of check_disk just because someone had provide
 620                 a plugin that had perf checking - we would incorporate the features
 621                 into an exisiting plugin)</para>
 622         </listitem>
 623         <listitem>
 624           <para>One of the developers has had the time to audit the code and declare
 625                 it ready for core</para>
 626         </listitem>
 627         <listitem>
 628           <para>It should also follow code format guidelines, and use functions from
 629 utils (perl or c or sh) rather than cooking it's own</para>
 630         </listitem>
 631       </orderedlist>
 632
 633         <para>New plugins should be submitted via
 634         <ulink url="http://sourceforge.net/tracker/?group_id=29880&amp;atid=541465">SourceForge's
 635         tracker system for Nagiosplug new plugins</ulink>
 636         and be announced to the nagiosplug-devel mailing list.</para>
 637
 638         <para>For new plugins, provide a diff to add to the EXTRAS list (configure.in)
 639         unless you are fairly sure that the plugin will work for all platforms with
 640         no non-standard software added.</para>
 641
 642         <para>If possible please submit a test harness. Documentation on sample
 643         tests coming soon.</para>
 644         </section>
 645
 646 </section>
 647
 648 </article>
 649
 650 </book>