]> git.sur5r.net Git - bacula/docs/commitdiff
Update developers doc
authorKern Sibbald <kern@sibbald.com>
Fri, 28 Oct 2005 09:54:21 +0000 (09:54 +0000)
committerKern Sibbald <kern@sibbald.com>
Fri, 28 Oct 2005 09:54:21 +0000 (09:54 +0000)
docs/developers/generaldevel.tex
docs/developers/mediaformat.tex
docs/developers/mempool.tex
docs/developers/netprotocol.tex
docs/developers/porting.tex
docs/developers/storage.tex
docs/developers/tls-techdoc.tex

index 998d7698461c94350a9e9e60334d055f63860b68..3d2b4e8f33b77f0825c5095628889ea02d6e4bae 100644 (file)
@@ -158,6 +158,8 @@ The Bacula CVS is divided into the following CVS "projects" or "modules".
 
   bacula              (Bacula source code)
   docs                (Bacula documentation)
+  gui                 (Some of the GUI programs that do not use
+                       the Bacula core code)
   rescue              (Bacula CDROM rescue code)
   regress             (Bacula regression scripts)
   ryol                (Roll your own Linux -- incomplete project)
index 20a4683bc1a6defaa384723a327ec77e8d74cb58..e498502b1b597acf20ac09dcc8ee78f621140900 100644 (file)
@@ -3,12 +3,12 @@
 
 \section*{Storage Media Output Format}
 \label{_ChapterStart9}
-\index{Format!Storage Media Output }
-\index{Storage Media Output Format }
+\index{Format!Storage Media Output}
+\index{Storage Media Output Format}
 \addcontentsline{toc}{section}{Storage Media Output Format}
 
 \subsection*{General}
-\index{General }
+\index{General}
 \addcontentsline{toc}{subsection}{General}
 
 This document describes the media format written by the Storage daemon. The
@@ -22,13 +22,13 @@ administrators that want or need to know more of the working details of {\bf
 Bacula}. 
 
 \subsection*{Definitions}
-\index{Definitions }
+\index{Definitions}
 \addcontentsline{toc}{subsection}{Definitions}
 
 \begin{description}
 
 \item [Block]
-   \index{Block }
+   \index{Block}
    A block represents the primitive unit of information  that the Storage daemon
 reads and writes to a physical  device. Normally, for a tape device, it will
 be the same as a  tape block. The Storage daemon always reads and writes 
@@ -49,14 +49,14 @@ all the records. 2. because there is on the average  more than one record per
 block, less data is written to the  Volume for each job.  
 
 \item [Record]
-   \index{Record }
+   \index{Record}
    A record consists of a Record Header, which is managed  by the Storage daemon
 and Record Data, which is the data  received from the Client. A record is the
 primitive unit  of information sent to and from the Storage daemon by the 
 Client (File daemon) programs. The details are described below.  
 
 \item [JobId]
-   \index{JobId }
+   \index{JobId}
    A number assigned by the Director daemon for a  particular job. This number
 will be unique for  that particular Director (Catalog). The daemons use this 
 number to keep track of individual jobs. Within the Storage  daemon, the JobId
@@ -64,19 +64,19 @@ may not be unique if several Directors are  accessing the Storage daemon
 simultaneously.  
 
 \item [Session]
-   \index{Session }
+   \index{Session}
    A Session is a concept used in the Storage daemon  corresponds one to one to a
 Job with the exception that  each session is uniquely identified within the
 Storage  daemon by a unique SessionId/SessionTime pair (see below).  
 
 \item [VolSessionId]
-   \index{VolSessionId }
+   \index{VolSessionId}
    A unique number assigned by the Storage daemon  to a particular session (Job)
 it is having with a File  daemon. This number by itself is not unique to the 
 given Volume, but with the VolSessionTime, it is unique.  
 
 \item [VolSessionTime]
-   \index{VolSessionTime }
+   \index{VolSessionTime}
    A unique number assigned by the Storage daemon  to a particular Storage daemon
 execution. It is actually  the Unix time\_t value of when the Storage daemon
 began  execution cast to a 32 bit unsigned integer. The combination  of the
@@ -84,7 +84,7 @@ began  execution cast to a 32 bit unsigned integer. The combination  of the
 guaranteed to be unique for each  Job (or session). 
 
 \item [FileIndex]
-   \index{FileIndex }
+   \index{FileIndex}
    A sequential number beginning at one assigned by the File  daemon to the files
 within a job that are sent to the Storage daemon  for backup. The Storage
 daemon ensures that this number  is greater than zero and sequential. Note,
@@ -94,7 +94,7 @@ VolSessionId, VolSessionTime, and FileIndex  uniquely identifies the records
 for a single file written  to a Volume.  
 
 \item [Stream]
-   \index{Stream }
+   \index{Stream}
    While writing the information for any particular  file to the Volume, there
 can be any number of distinct  pieces of information about that file, e.g. the
 attributes,  the file data, ... The Stream indicates what piece of data  it
@@ -106,7 +106,7 @@ data for a given stream may be  passed to the Storage daemon in single record,
 or in multiple  records.  
 
 \item [Block Header]
-   \index{Block Header }
+   \index{Block Header}
    A block header consists of a block identification  (``BB02''), a block length
 in bytes (typically  64,512) a checksum, and sequential block number.  Each
 block starts with a Block Header and is followed  by Records. Current block
@@ -114,7 +114,7 @@ headers also contain the VolSessionId  and VolSessionTime for the records
 written to that block.  
 
 \item [Record Header]
-   \index{Record Header }
+   \index{Record Header}
    A record header contains the Volume Session Id, the  Volume Session Time, the
 FileIndex, the Stream, and the size of the  data record which follows. The
 Record Header is always immediately  followed by a Data Record if the size
@@ -125,21 +125,21 @@ fields are stored in the BB02 Block header. The in-memory record  header does
 have those fields for convenience. 
 
 \item [Data Record]
-   \index{Data Record }
+   \index{Data Record}
    A data record consists of a binary stream of bytes  and is always preceded by
 a Record Header. The details of the  meaning of the binary stream of bytes are
 unknown to the Storage  daemon, but the Client programs (File daemon) defines
 and thus  knows the details of each record type.  
 
 \item [Volume Label]
-   \index{Volume Label }
+   \index{Volume Label}
    A label placed by the Storage daemon at the beginning  of each storage volume.
 It contains general information about  the volume. It is written in Record
 format. The Storage daemon  manages Volume Labels, and if the client wants, he
 may also  read them.  
 
 \item [Begin Session Label]
-   \index{Begin Session Label }
+   \index{Begin Session Label}
    The Begin Session Label is a special record  placed by the Storage daemon on
 the storage medium as the first  record of an append session job with a File
 daemon. This record  is useful for finding the beginning of a particular
@@ -149,7 +149,7 @@ Storage daemon. The Begin Session Label is similar  to the Volume Label except
 that it contains additional information  pertaining to the Session.  
 
 \item [End Session Label]
-   \index{End Session Label }
+   \index{End Session Label}
    The End Session Label is a special record  placed by the Storage daemon on the
 storage medium as the last  record of an append session job with a File
 daemon. The End  Session Record is distinguished by a FileIndex with a value
@@ -162,8 +162,8 @@ Session.
 \end{description}
 
 \subsection*{Storage Daemon File Output Format}
-\index{Format!Storage Daemon File Output }
-\index{Storage Daemon File Output Format }
+\index{Format!Storage Daemon File Output}
+\index{Storage Daemon File Output Format}
 \addcontentsline{toc}{subsection}{Storage Daemon File Output Format}
 
 The file storage and tape storage formats are identical except that tape
@@ -176,8 +176,8 @@ tape is terminated with an End of File mark (this will be removed later).
 Sessions written to file are simply appended to the end of the file. 
 
 \subsection*{Overall Format}
-\index{Format!Overall }
-\index{Overall Format }
+\index{Format!Overall}
+\index{Overall Format}
 \addcontentsline{toc}{subsection}{Overall Format}
 
 A Bacula output file consists of Blocks of data. Each block contains a block
@@ -209,7 +209,7 @@ since Bacula blocks are sequentially numbered within a Job, it is easy to
 ensure that no block is missing or duplicated. 
 
 \subsection*{Serialization}
-\index{Serialization }
+\index{Serialization}
 \addcontentsline{toc}{subsection}{Serialization}
 
 All Block Headers, Record Headers, and Label Records are written using
@@ -217,8 +217,8 @@ Bacula's serialization routines. These routines guarantee that the data is
 written to the output volume in a machine independent format. 
 
 \subsection*{Block Header}
-\index{Header!Block }
-\index{Block Header }
+\index{Header!Block}
+\index{Block Header}
 \addcontentsline{toc}{subsection}{Block Header}
 
 The format of the Block Header (version 1.27 and later) is: 
@@ -245,8 +245,8 @@ be in machine independent format. See below for version 2 of the block header.
 
 
 \subsection*{Record Header}
-\index{Header!Record }
-\index{Record Header }
+\index{Header!Record}
+\index{Record Header}
 \addcontentsline{toc}{subsection}{Record Header}
 
 Each binary data record is preceded by a Record Header. The Record Header is
@@ -273,20 +273,20 @@ Additional notes on the above:
 \begin{description}
 
 \item [The {\bf VolSessionId} ]
-   \index{VolSessionId }
+   \index{VolSessionId}
    is a unique sequential number that is  assigned by the Storage Daemon to a
 particular Job. This number  is sequential since the start of execution of the
 daemon. 
 
 \item [The {\bf VolSessionTime} ]
-   \index{VolSessionTime }
+   \index{VolSessionTime}
    is the time/date that the current execution  of the Storage Daemon started. It
 assures that the combination of  VolSessionId and VolSessionTime is unique for
 every jobs written  to the tape, even if there was a machine crash between two
 writes. 
 
 \item [The {\bf FileIndex} ]
-   \index{FileIndex }
+   \index{FileIndex}
    is a sequential file number within a job.  The Storage daemon requires this
 index to be greater than zero and  sequential. Note, however, that the File
 daemon may send multiple  Streams for the same FileIndex. In addition, the
@@ -294,7 +294,7 @@ Storage daemon uses  negative FileIndices to hold the Begin Session Label, the
 End Session  Label, and the End of Volume Label. 
 
 \item [The {\bf Stream} ]
-   \index{Stream }
+   \index{Stream}
    is defined by the File daemon and is  used to identify separate parts of the
 data saved for each file  (Unix attributes, Win32 attributes, file data,
 compressed file data,  sparse file data, ...). The Storage Daemon has no idea 
@@ -309,24 +309,28 @@ stream definitions are:
 
 \footnotesize
 \begin{verbatim}
-STREAM_UNIX_ATTRIBUTES   1    /* Generic Unix attributes */
-STREAM_FILE_DATA         2    /* Standard uncompressed data */
-STREAM_MD5_SIGNATURE     3    /* MD5 signature for the file */
-STREAM_GZIP_DATA         4    /* GZip compressed file data */
-STREAM_WIN32_ATTRIBUTES  5    /* Windows attributes (superset of Unix) */
-STREAM_SPARSE_DATA       6    /* Sparse data stream */
-STREAM_SPARSE_GZIP_DATA  7    /* Sparse data stream compressed by GZIP */
-STREAM_PROGRAM_NAMES     8    /* program names for program data */
-STREAM_PROGRAM_DATA      9    /* Data needing program */
-STREAM_SHA1_SIGNATURE   10    /* SHA1 signature for the file */
-STREAM_WIN32_DATA       11    /* Win32 BackupRead data */
-STREAM_WIN32_GZIP_DATA  12    /* Gzipped Win32 BackupRead data */
-   
+#define STREAM_UNIX_ATTRIBUTES    1    /* Generic Unix attributes */
+#define STREAM_FILE_DATA          2    /* Standard uncompressed data */
+#define STREAM_MD5_SIGNATURE      3    /* MD5 signature for the file */
+#define STREAM_GZIP_DATA          4    /* GZip compressed file data */
+/* Extended Unix attributes with Win32 Extended data.  Deprecated. */
+#define STREAM_UNIX_ATTRIBUTES_EX 5    /* Extended Unix attr for Win32 EX */
+#define STREAM_SPARSE_DATA        6    /* Sparse data stream */
+#define STREAM_SPARSE_GZIP_DATA   7
+#define STREAM_PROGRAM_NAMES      8    /* program names for program data */
+#define STREAM_PROGRAM_DATA       9    /* Data needing program */
+#define STREAM_SHA1_SIGNATURE    10    /* SHA1 signature for the file */
+#define STREAM_WIN32_DATA        11    /* Win32 BackupRead data */
+#define STREAM_WIN32_GZIP_DATA   12    /* Gzipped Win32 BackupRead data */
+#define STREAM_MACOS_FORK_DATA   13    /* Mac resource fork */
+#define STREAM_HFSPLUS_ATTRIBUTES 14   /* Mac OS extra attributes */
+#define STREAM_UNIX_ATTRIBUTES_ACCESS_ACL 15 /* Standard ACL attributes on UNIX */
+#define STREAM_UNIX_ATTRIBUTES_DEFAULT_ACL 16 /* Default ACL attributes on UNIX */
 \end{verbatim}
 \normalsize
 
 \item [The {\bf DataSize} ]
-   \index{DataSize }
+   \index{DataSize}
    is the size in bytes of the binary data  record that follows the Session
 Record header. The Storage Daemon  has no idea of the actual contents of the
 binary data record. For  standard Unix files, the data record typically
@@ -346,8 +350,8 @@ read the next record and concatenate the data record to form a full data
 record. 
 
 \subsection*{Version BB02 Block Header}
-\index{Version BB02 Block Header }
-\index{Header!Version BB02 Block }
+\index{Version BB02 Block Header}
+\index{Header!Version BB02 Block}
 \addcontentsline{toc}{subsection}{Version BB02 Block Header}
 
 Each session or Job has its own private block. As a consequence, the SessionId
@@ -375,8 +379,8 @@ which are valid. The Block header is written using the Bacula serialization
 routines and thus is guaranteed to be in machine independent format. 
 
 \subsection*{Version 2 Record Header}
-\index{Version 2 Record Header }
-\index{Header!Version 2 Record }
+\index{Version 2 Record Header}
+\index{Header!Version 2 Record}
 \addcontentsline{toc}{subsection}{Version 2 Record Header}
 
 Version 2 Record Header is written to the medium when using Version BB02 Block
@@ -390,8 +394,8 @@ VolSessionId and VolSessionTime is filled in the Record Header from the Block
 Header. 
 
 \subsection*{Volume Label Format}
-\index{Volume Label Format }
-\index{Format!Volume Label }
+\index{Volume Label Format}
+\index{Format!Volume Label}
 \addcontentsline{toc}{subsection}{Volume Label Format}
 
 Tape volume labels are created by the Storage daemon in response to a {\bf
@@ -429,8 +433,8 @@ is stored in the record FileIndex field of the Record Header and does not
 appear in the data part of the record. 
 
 \subsection*{Session Label}
-\index{Label!Session }
-\index{Session Label }
+\index{Label!Session}
+\index{Session Label}
 \addcontentsline{toc}{subsection}{Session Label}
 
 The Session Label is written at the beginning and end of each session as well
@@ -492,8 +496,8 @@ JobId. This permits quick filtering without actually reading all the session
 data in many cases. 
 
 \subsection*{Overall Storage Format}
-\index{Format!Overall Storage }
-\index{Overall Storage Format }
+\index{Format!Overall Storage}
+\index{Overall Storage Format}
 \addcontentsline{toc}{subsection}{Overall Storage Format}
 
 \footnotesize
@@ -726,8 +730,8 @@ data in many cases.
 \normalsize
 
 \subsection*{Unix File Attributes}
-\index{Unix File Attributes }
-\index{Attributes!Unix File }
+\index{Unix File Attributes}
+\index{Attributes!Unix File}
 \addcontentsline{toc}{subsection}{Unix File Attributes}
 
 The Unix File Attributes packet consists of the following: 
@@ -742,11 +746,11 @@ The Unix File Attributes packet consists of the following:
    represents a byte containing a binary zero.  
 
 \item [FileIndex]
-   \index{FileIndex }
+   \index{FileIndex}
    is the sequential file index starting from one assigned  by the File daemon.  
 
 \item [Type]
-   \index{Type }
+   \index{Type}
    is one of the following: 
 
 \footnotesize
@@ -772,24 +776,24 @@ The Unix File Attributes packet consists of the following:
 \normalsize
 
 \item [Filename]
-   \index{Filename }
+   \index{Filename}
    is the fully qualified filename.  
 
 \item [File-Attributes]
-   \index{File-Attributes }
+   \index{File-Attributes}
    consists of the 13 fields of the stat() buffer in  ASCII base64 format
 separated by spaces. These fields  and their meanings are shown below. This
 stat() packet is in Unix  format, and MUST be provided (constructed) for ALL
 systems.  
 
 \item [Link]
-   \index{Link }
+   \index{Link}
    when the FT code is FT\_LNK or FT\_LNKSAVED, the item in  question is a Unix
 link, and this field contains the fully  qualified link name. When the FT code
 is not FT\_LNK or  FT\_LNKSAVED, this field is null.  
 
 \item [Extended-Attributes]
-   \index{Extended-Attributes }
+   \index{Extended-Attributes}
    The exact format of this field is  operating system dependent. It contains
 additional or extended  attributes of a system dependent nature. Currently,
 this field is  used only on WIN32 systems where it contains a ASCII base64 
@@ -803,55 +807,55 @@ The File-attributes consist of the following:
 \addcontentsline{lot}{table}{File Attributes}
 \begin{longtable}{|p{0.6in}|p{0.7in}|p{1in}|p{1in}|p{1.4in}|}
  \hline 
-\multicolumn{1}{|c| }{\bf Field No.  } & \multicolumn{1}{c| }{\bf Stat Name  }
-& \multicolumn{1}{c| }{\bf Unix  } & \multicolumn{1}{c| }{\bf Win98/NT  } &
-\multicolumn{1}{c| }{\bf MacOS  } \\
+\multicolumn{1}{|c|}{\bf Field No. } & \multicolumn{1}{c|}{\bf Stat Name }
+& \multicolumn{1}{c|}{\bf Unix } & \multicolumn{1}{c|}{\bf Win98/NT } &
+\multicolumn{1}{c|}{\bf MacOS } \\
  \hline 
-\multicolumn{1}{|c| }{1  } & {st\_dev  } & {Device number of filesystem  } &
-{Drive number  } & {vRefNum  } \\
+\multicolumn{1}{|c|}{1 } & {st\_dev } & {Device number of filesystem } &
+{Drive number } & {vRefNum } \\
  \hline 
-\multicolumn{1}{|c| }{2  } & {st\_ino  } & {Inode number  } & {Always 0  } &
-{fileID/dirID  } \\
+\multicolumn{1}{|c|}{2 } & {st\_ino } & {Inode number } & {Always 0 } &
+{fileID/dirID } \\
  \hline 
-\multicolumn{1}{|c| }{3  } & {st\_mode  } & {File mode  } & {File mode  } &
-{777 dirs/apps; 666 docs; 444 locked docs  } \\
+\multicolumn{1}{|c|}{3 } & {st\_mode } & {File mode } & {File mode } &
+{777 dirs/apps; 666 docs; 444 locked docs } \\
  \hline 
-\multicolumn{1}{|c| }{4  } & {st\_nlink  } & {Number of links to the file  } &
-{Number of link (only on NTFS)  } & {Always 1  } \\
+\multicolumn{1}{|c|}{4 } & {st\_nlink } & {Number of links to the file } &
+{Number of link (only on NTFS) } & {Always 1 } \\
  \hline 
-\multicolumn{1}{|c| }{5  } & {st\_uid  } & {Owner ID  } & {Always 0  } &
-{Always 0  } \\
+\multicolumn{1}{|c|}{5 } & {st\_uid } & {Owner ID } & {Always 0 } &
+{Always 0 } \\
  \hline 
-\multicolumn{1}{|c| }{6  } & {st\_gid  } & {Group ID  } & {Always 0  } &
-{Always 0  } \\
+\multicolumn{1}{|c|}{6 } & {st\_gid } & {Group ID } & {Always 0 } &
+{Always 0 } \\
  \hline 
-\multicolumn{1}{|c| }{7  } & {st\_rdev  } & {Device ID for special files  } &
-{Drive No.  } & {Always 0  } \\
+\multicolumn{1}{|c|}{7 } & {st\_rdev } & {Device ID for special files } &
+{Drive No. } & {Always 0 } \\
  \hline 
-\multicolumn{1}{|c| }{8  } & {st\_size  } & {File size in bytes  } & {File
-size in bytes  } & {Data fork file size in bytes  } \\
+\multicolumn{1}{|c|}{8 } & {st\_size } & {File size in bytes } & {File
+size in bytes } & {Data fork file size in bytes } \\
  \hline 
-\multicolumn{1}{|c| }{9  } & {st\_blksize  } & {Preferred block size  } &
-{Always 0  } & {Preferred block size  } \\
+\multicolumn{1}{|c|}{9 } & {st\_blksize } & {Preferred block size } &
+{Always 0 } & {Preferred block size } \\
  \hline 
-\multicolumn{1}{|c| }{10  } & {st\_blocks  } & {Number of blocks allocated  }
-& {Always 0  } & {Number of blocks allocated  } \\
+\multicolumn{1}{|c|}{10 } & {st\_blocks } & {Number of blocks allocated }
+& {Always 0 } & {Number of blocks allocated } \\
  \hline 
-\multicolumn{1}{|c| }{11  } & {st\_atime  } & {Last access time since epoch  }
-& {Last access time since epoch  } & {Last access time -66 years  } \\
+\multicolumn{1}{|c|}{11 } & {st\_atime } & {Last access time since epoch }
+& {Last access time since epoch } & {Last access time -66 years } \\
  \hline 
-\multicolumn{1}{|c| }{12  } & {st\_mtime  } & {Last modify time since epoch  }
-& {Last modify time since epoch  } & {Last access time -66 years  } \\
+\multicolumn{1}{|c|}{12 } & {st\_mtime } & {Last modify time since epoch }
+& {Last modify time since epoch } & {Last access time -66 years } \\
  \hline 
-\multicolumn{1}{|c| }{13  } & {st\_ctime  } & {Inode change time since epoch 
-} & {File create time since epoch  } & {File create time -66 years }
+\multicolumn{1}{|c|}{13 } & {st\_ctime } & {Inode change time since epoch 
+} & {File create time since epoch } & {File create time -66 years}
 \\ \hline 
 
 \end{longtable}
 
 \subsection*{Old Depreciated Tape Format}
-\index{Old Depreciated Tape Format }
-\index{Format!Old Depreciated Tape }
+\index{Old Depreciated Tape Format}
+\index{Format!Old Depreciated Tape}
 \addcontentsline{toc}{subsection}{Old Depreciated Tape Format}
 
 The format of the Block Header (version 1.26 and earlier) is: 
index 8810fbe71872f979faef84a6cf3c36a4ffd1e1d4..84c7273d4555b801e5de18db3bfff07617672176 100644 (file)
@@ -3,12 +3,12 @@
 
 \section*{Bacula Memory Management}
 \label{_ChapterStart7}
-\index{Management!Bacula Memory }
-\index{Bacula Memory Management }
+\index{Management!Bacula Memory}
+\index{Bacula Memory Management}
 \addcontentsline{toc}{section}{Bacula Memory Management}
 
 \subsection*{General}
-\index{General }
+\index{General}
 \addcontentsline{toc}{subsection}{General}
 
 This document describes the memory management routines that are used in Bacula
@@ -29,8 +29,8 @@ turn. They are:
    \end{itemize}
 
 \subsubsection*{Statically Allocated Memory}
-\index{Statically Allocated Memory }
-\index{Memory!Statically Allocated }
+\index{Statically Allocated Memory}
+\index{Memory!Statically Allocated}
 \addcontentsline{toc}{subsubsection}{Statically Allocated Memory}
 
 Statically allocated memory is of the form: 
@@ -49,8 +49,8 @@ change, particularly to accommodate Unicode, it will remain a relatively small
 value. 
 
 \subsubsection*{Dynamically Allocated Memory}
-\index{Dynamically Allocated Memory }
-\index{Memory!Dynamically Allocated }
+\index{Dynamically Allocated Memory}
+\index{Memory!Dynamically Allocated}
 \addcontentsline{toc}{subsubsection}{Dynamically Allocated Memory}
 
 Dynamically allocated memory is obtained using the standard malloc() routines.
@@ -81,8 +81,8 @@ the free() call, and all malloc'ed memory that is not released prior to
 termination of the program will be reported as Orphaned memory. 
 
 \subsubsection*{Pooled and Non-pooled Memory}
-\index{Memory!Pooled and Non-pooled }
-\index{Pooled and Non-pooled Memory }
+\index{Memory!Pooled and Non-pooled}
+\index{Pooled and Non-pooled Memory}
 \addcontentsline{toc}{subsubsection}{Pooled and Non-pooled Memory}
 
 In order to facility the handling of arbitrary length filenames and to
index 24434d6cc3e0c4bacd4d5c56119545d2481d3bb1..34b325e9a3c1b86046d3fdc43e0ecb554f7f9afe 100644 (file)
@@ -3,12 +3,12 @@
 
 \section*{TCP/IP Network Protocol}
 \label{_ChapterStart5}
-\index{TCP/IP Network Protocol }
-\index{Protocol!TCP/IP Network }
+\index{TCP/IP Network Protocol}
+\index{Protocol!TCP/IP Network}
 \addcontentsline{toc}{section}{TCP/IP Network Protocol}
 
 \subsection*{General}
-\index{General }
+\index{General}
 \addcontentsline{toc}{subsection}{General}
 
 This document describes the TCP/IP protocol used by Bacula to communicate
@@ -29,8 +29,8 @@ low level write() and read() calls are needed. All data transferred are
 considered to be binary data. 
 
 \subsection*{bnet and Threads}
-\index{Threads!bnet and }
-\index{Bnet and Threads }
+\index{Threads!bnet and}
+\index{Bnet and Threads}
 \addcontentsline{toc}{subsection}{bnet and Threads}
 
 These bnet routines work fine in a threaded environment. However, they assume
@@ -45,7 +45,7 @@ must implement some locking mechanism. However, it probably would not be
 appropriate to put locks inside the bnet subroutines for efficiency reasons. 
 
 \subsection*{bnet\_open}
-\index{Bnet\_open }
+\index{Bnet\_open}
 \addcontentsline{toc}{subsection}{bnet\_open}
 
 To establish a connection to a server, use the subroutine: 
@@ -58,7 +58,7 @@ error occurred and that you should not repeatedly call bnet\_open(). Any error
 message will generally be sent to the JCR. 
 
 \subsection*{bnet\_send}
-\index{Bnet\_send }
+\index{Bnet\_send}
 \addcontentsline{toc}{subsection}{bnet\_send}
 
 To send a packet, one uses the subroutine: 
@@ -80,7 +80,7 @@ In the case of a failure, an error message will be sent to the JCR contained
 within the bsock packet. 
 
 \subsection*{bnet\_fsend}
-\index{Bnet\_fsend }
+\index{Bnet\_fsend}
 \addcontentsline{toc}{subsection}{bnet\_fsend}
 
 This form uses: 
@@ -90,8 +90,8 @@ formatted messages somewhat like fprintf(). The return status is the same as
 bnet\_send. 
 
 \subsection*{Additional Error information}
-\index{Information!Additional Error }
-\index{Additional Error information }
+\index{Information!Additional Error}
+\index{Additional Error information}
 \addcontentsline{toc}{subsection}{Additional Error information}
 
 Fro additional error information, you can call {\bf is\_bnet\_error(BSOCK
@@ -102,7 +102,7 @@ will return non-zero if there are errors or the line is closed (no more
 transmissions should be sent). 
 
 \subsection*{bnet\_recv}
-\index{Bnet\_recv }
+\index{Bnet\_recv}
 \addcontentsline{toc}{subsection}{bnet\_recv}
 
 To read a packet, one uses the subroutine: 
@@ -126,7 +126,7 @@ maxbytes is less than the record size sent. It returns:
 It should be noted that bnet\_recv() is a blocking read. 
 
 \subsection*{bnet\_sig}
-\index{Bnet\_sig }
+\index{Bnet\_sig}
 \addcontentsline{toc}{subsection}{bnet\_sig}
 
 To send a ``signal'' from one daemon to another, one uses the subroutine: 
@@ -146,13 +146,13 @@ int bnet\_sig(BSOCK *sock, SIGNAL) where SIGNAL is one of the following:
    \end{enumerate}
 
 \subsection*{bnet\_strerror}
-\index{Bnet\_strerror }
+\index{Bnet\_strerror}
 \addcontentsline{toc}{subsection}{bnet\_strerror}
 
 Returns a formated string corresponding to the last error that occurred. 
 
 \subsection*{bnet\_close}
-\index{Bnet\_close }
+\index{Bnet\_close}
 \addcontentsline{toc}{subsection}{bnet\_close}
 
 The connection with the server remains open until closed by the subroutine: 
@@ -160,8 +160,8 @@ The connection with the server remains open until closed by the subroutine:
 void bnet\_close(BSOCK *sock) 
 
 \subsection*{Becoming a Server}
-\index{Server!Becoming a }
-\index{Becoming a Server }
+\index{Server!Becoming a}
+\index{Becoming a Server}
 \addcontentsline{toc}{subsection}{Becoming a Server}
 
 The bnet\_open() and bnet\_close() routines described above are used on the
@@ -172,8 +172,8 @@ please refer to the code in bnet\_server.c and the code at the beginning of
 each daemon as examples of how to call it. 
 
 \subsection*{Higher Level Conventions}
-\index{Conventions!Higher Level }
-\index{Higher Level Conventions }
+\index{Conventions!Higher Level}
+\index{Higher Level Conventions}
 \addcontentsline{toc}{subsection}{Higher Level Conventions}
 
 Within Bacula, we have established the convention that any time a single
index 11e2569003325fb27b24a0c21a075cf1b0c174f1..7411d4c5f87ba82d3b82561a803374079c864030 100644 (file)
@@ -3,8 +3,8 @@
 
 \section*{Bacula Porting Notes}
 \label{_ChapterStart1}
-\index{Notes!Bacula Porting }
-\index{Bacula Porting Notes }
+\index{Notes!Bacula Porting}
+\index{Bacula Porting Notes}
 \addcontentsline{toc}{section}{Bacula Porting Notes}
 
 This document is intended mostly for developers who wish to port Bacula to a
@@ -16,8 +16,8 @@ Directory and Storage daemons will run on every system capable of supporting
 them. 
 
 \subsection*{Porting Requirements}
-\index{Requirements!Porting }
-\index{Porting Requirements }
+\index{Requirements!Porting}
+\index{Porting Requirements}
 \addcontentsline{toc}{subsection}{Porting Requirements}
 
 In General, the following holds true: 
@@ -49,8 +49,8 @@ you will  be on your own.
 \end{itemize}
 
 \subsection*{Steps to Take for Porting}
-\index{Porting!Steps to Take for }
-\index{Steps to Take for Porting }
+\index{Porting!Steps to Take for}
+\index{Steps to Take for Porting}
 \addcontentsline{toc}{subsection}{Steps to Take for Porting}
 
 \begin{itemize}
index 1418b2a426809f634bc3291eb167d4c39b646c86..4d3fdd49e42a8d022af8104fcf362fecd4bc5ad1 100644 (file)
@@ -12,6 +12,8 @@ services and as such is not targeted at end users but rather at developers and
 system administrators that want or need to know more of the working details of
 {\bf Bacula}. 
 
+This document is somewhat out of date.
+
 \subsection*{SD Design Introduction}
 \index{Introduction!SD Design }
 \index{SD Design Introduction }
index c6015f6c25aaa225a18ea2f656687a59c7b6206d..3b9c8145cd30c5f2f77fafe8bf478247eb2d84c6 100644 (file)
@@ -17,10 +17,11 @@ Written by Landon Fuller
 \addcontentsline{toc}{subsection}{TLS Introduction}
 
 This patch includes all the back-end code necessary to add complete TLS
-support to Bacula.  In addition, support for TLS in Console/Director
-communications has been added as a proof of concept.  Adding support for
-the remaining daemons will be straight-forward.  Supported features of this
-patchset include: 
+data encryption support to Bacula.  In addition, support for TLS in
+Console/Director communications has been added as a proof of concept.
+Adding support for the remaining daemons will be straight-forward.
+Supported features of this patchset include:
+
 \begin{itemize} 
 \item Client/Server TLS Requirement Negotiation 
 \item TLSv1 Connections with Server and Client Certificate
@@ -44,10 +45,6 @@ additional preprocessor defines have been added: \emph{HAVE\_TLS} and
 \emph{src/lib/tls.c} to facilitate the support of alternative TLS
 implementations.
 
-I have submitted the code in \emph{src/lib/tls.c} under the 3 clause BSD
-license.  I prefer the stronger warranty disclaimer of an actual license,
-but I'm also willing to provide access to the code under the public domain.
-
 \subsection{New Configuration Directives}
 \index{TLS Configuration Directives}
 \index{Directives!TLS Configuration}