recent ETICS building system development promise a future possibility to
distribute the software in other distribution formats, e.g. DEB packages.
-In \LBold, the list of all LB packages was the following:
+In \LBver{1.x}, the list of all LB packages was the following:
\begin{tabularx}{\textwidth}{>{\tt}lX}
glite-lb-common & common files \\
glite-lb-client & client library and CLI tools\\
glite-lb-client-interface & client library interface (header files) \\
+glite-lb-harvester & enhanced \LB notification client (since \LBver{1.10}) \\
glite-lb-logger & local-logger and inter-logger \\
glite-lb-proxy & proxy (restricted server used by WMS)\\
glite-lb-server & server \\
glite-security-gsoap-plugin & GSS wrapper and GSS plugin for gSoap
\end{tabularx}
-In \LBnew, the code has been restructured quite a lot, especially the dependencies were lightened,
+In \LBver{2.0}, the code has been restructured quite a lot, especially the dependencies were lightened,
and the new list of packages is now the following:
\begin{tabularx}{\textwidth}{>{\tt}lX}
glite-lb-doc & documentation \\
glite-lb-common & common files \\
glite-lb-client & client library and CLI tools\\
+glite-lb-harvester & enhanced \LB notification client \\
glite-lb-logger & local-logger and inter-logger \\
glite-lb-server & server, including merged proxy functionality \\
glite-lb-state-machine & state machine and LB plugin for Job Provenance \\
\end{verbatim}
Some of the LB packages depend also on other gLite packages, different
-due to the restructuring of \LBnew.
-For \LBold they are:
+due to the restructuring since \LBver{2.0}.
+For \LBver{1.x} they are:
\begin{tabularx}{\textwidth}{>{\tt}lX}
\end{tabularx}
\noindent
-And for \LBnew:
+And for \LBver{2.x}:
\begin{tabularx}{\textwidth}{>{\tt}lX}
glite-jobid-api-c & gLite jobId C API library \\
Job Provenance (\JP).
\subsection{Common logging format}
-\LB service follows the \textbf{gLite common logging recommendations v1.1}:
+Since \LBver{2.1} \LB service follows the \textbf{gLite common logging recommendations v1.1}:
\begin{center}
\url{https://twiki.cern.ch/twiki/pub/EGEE/EGEEgLite/logging.html}.
\end{center}
uses \texttt{log4c} (\url{http://log4c.sourceforge.net})
and its configuration file \texttt{log4crc}.
-There is one configuration file \texttt{\$GLITE\_LOCATION/etc/glite-lb-log4crc}
+There is one configuration file \texttt{\$GLITE\_LOCATION/etc/glite-lb/log4crc}
that startup scripts use by setting the \texttt{LOG4C\_RCPATH} environment
variable.
A file \texttt{log4crc.example-debugging} may be useful to copy to
\texttt{\$HOME/.log4crc} (or by setting the \texttt{LOG4C\_RCPATH} environment variable
-to this file) to obtain detailed debugging output.
+to a directory containing the \texttt{log4crc} file) to obtain detailed debugging output.
One can debug only specific parts of the LB system, for example
by uncommenting \texttt{LB.SERVER.DB} cathegory in the \texttt{log4crc} file,
one gets only the debugging info related to the underlying database subsystem calls.
/opt/glite/etc/LB-super-users and uses it eventually.
\subsubsection{Authorization of event originators}
-\LBold allowed anyone possessing a trusted digital certificate to send an
+\LBver{1.x} allowed anyone possessing a trusted digital certificate to send an
arbitrary event to the \LB server. While enabling an easy setup, such an
arrangement does not comply with some contemporary requirements, \eg job
traceability, since the data could be distorted by a malicious user. In order
-to strengthen trustworthiness of data provided, the \LBnew server has
+to strengthen trustworthiness of data provided, the \LBver{2.0} server has
introduced an authorization mechanism to control the originators of events.
The authorization model presumes a set of trusted components that are only
allowed to send some types of events, while other types can be logged by any
All necessary configuration of \LB proxy is done by YAIM,
and described with gLite WMS installation elsewhere.
-Previous \LB server section applies to merged server+proxy setups (\LBnew only).
+Previous \LB server section applies to merged server+proxy setups (since \LBver{2.0}).
A~special care must be taken when an existing \LB proxy database
-is migrated to \LBnew.
-In general, this is not a~typical scenario -- \LBnew server in proxy mode
+is migrated to \LBver{2.x}.
+In general, this is not a~typical scenario -- \LBver{2.x} server in proxy mode
on WMS node is introduced with a~major WMS upgrade, and it is expeced
to be installed from scratch rather than migrated, preserving \LB proxy data.
If the migration is really needed, \verb'glite-lb-migrate_db2version20'
script should be run with~\verb'-p' (Sect~\ref{inst:migrate20}).
However, the \LB database name remains \verb'lbproxy' while
-the \LBnew binaries expect unified \verb'lbserver20' by default.
+the \LBver{2.x} binaries expect unified \verb'lbserver20' by default.
Because renaming a~MySQL database is a~non-trivial, error prone task,
the recommended workaround is to add the following variable setting
Send events via \LB proxy. Checks the proxy functionality.
-\req Running \LB proxy, in standalone package for \LBold, or
+\req Running \LB proxy, in standalone package for \LBver{1.x}, or
\LB server running with \verb'-P' (proxy only) or \verb'-B' (both server and proxy)
options.
WMS, expected load of upto 30--50 kjobs/day, and not very heavy user-generated
load.
-The functionality is available for \LBnew only.
+The functionality is available since \LBver{2.0}.
\begin{figure}[ht]
\centering
Beware that these can grow huge easily.
\end{sloppypar}
-\textbf{\LBold only:} not available for \LB proxy, \verb'-d' and output redirection
+\textbf{\LBver{1.x} only:} not available for \LB proxy, \verb'-d' and output redirection
have to be added manually if necessary.
\subsubsection{Changing index configuration}
However, frozen jobs which never reach such a~state may occur in an unstable environment,
and they may cumulate in \LB proxy database for ever.
Therefore occasional purging is recommended too.
-\LBnew supports \verb'-x' option of \verb'glite-lb-purge', allowing
+\LBver{2.x} supports \verb'-x' option of \verb'glite-lb-purge', allowing
to purge \LB proxy database too.
-With \LBold the emergency purge procedure described bellow is the only option.
+With \LBver{1.x} the emergency purge procedure described bellow is the only option.
\paragraph{Emergency purge}
% API
The data are available via statistics calls of the client API,
-see \verb'statistics.h' for details (coming with glite-lb-client in \LBnew,
-glite-lb-client-interface in \LBold).
+see \verb'statistics.h' for details (coming with glite-lb-client in \LBver{2.x},
+glite-lb-client-interface in \LBver{1.x}).
The call specifies the group and job state of interest, as well as queried
time interval.
The interval is fitted to the running counter series as accurately as possible,
and 10 slave processes.
Threads are not used.
-Master pid is stored in the file \verb'$HOME/edg-bkserverd.pid' (\LBold)
-or in the file \verb'$HOME/glite-lb-bkserverd.pid' (\LBnew) respectively.
+Master pid is stored in the file \verb'$HOME/edg-bkserverd.pid' (\LBver{1.x})
+or in the file \verb'$HOME/glite-lb-bkserverd.pid' (\LBver{2.x}) respectively.
Number of slaves can be set with \verb'-s, --slaves' option,
pid file location with~\verb'-i, --pidfile'.
\verb'/tmp/lb_proxy_server.sock' (queries) and
\verb'/tmp/lb_proxy_store.sock' (incoming events).
-\LBnew: as proxy and server are merged, the mode of operation determines
+\LBver{2.x}: as proxy and server are merged, the mode of operation determines
the actual server ports (network or UNIX).
Notifications are not delivered from proxy-only mode.
-\item[IPC.] \LBold only: mutual exclusion of server slaves is done
+\item[IPC.] \LBver{1.x} only: mutual exclusion of server slaves is done
via SYSV semaphores. The semset key is obtained by calling ftok(3) on
the pid file.
-\LBnew does not use semaphores anymore.
+\LBver{2.x} does not use semaphores anymore.
\item[Database.]
Server data are stored in MySQL database. Normal setup assumes ``server scenario'',
and \LB common library (\verb'glite-lb-common').
These bring in other gLite dependencies:
\begin{itemize}
-\item \verb'glite-lb-client-interface' (\LBold only)
-\item \verb'glite-security-gsoap-plugin' (\LBold only)
-\item \verb'glite-security-gss' (\LBnew only)
+\item \verb'glite-lb-client-interface' (\LBver{1.x} only)
+\item \verb'glite-security-gsoap-plugin' (\LBver{1.x} only)
+\item \verb'glite-security-gss' (\LBver{2.x} only)
\end{itemize}
and external dependencies:
\begin{itemize}
\end{figure}
\newpage
+\subsection{CREAM Job States Mapping}
+Support of CREAM jobs is available since \LBver{2.1}. This is the implemented
+mapping of job states between CREAM and \LB:
+\label{a:creammapping}
+
+\begin{tabularx}{\textwidth}{>{\bfseries}lX}
+CREAM state & \LB state \\
+Registered & Submited \\
+Pending & Waiting \\
+Idle & Scheduled \\
+Running & Running \\
+Really Running & Running \\
+% Held
+Done OK & Done \\
+Done Failed & Done \\
+Aborted & Aborted \\
+Cancelled & Cancelled \\
+\end{tabularx}
+
+\newpage
\section{Environment variables}
\label{a:environment}
For backward compatibility, all \verb'GLITE_WMS_*' variables can be prefixed by
\verb'EDG_WL_' instead, for example \verb'EDG_WL_LOG_DESTINATION'.
-\newpage
-\subsection{CREAM Job States Mapping}
-\label{a:creammapping}
-
-\begin{tabularx}{\textwidth}{>{\bfseries}lX}
-CREAM state & \LB state \\
-Registered & Submited \\
-Pending & Waiting \\
-Idle & Scheduled \\
-Running & Running \\
-Really Running & Running \\
-% Held
-Done OK & Done \\
-Done Failed & Done \\
-Aborted & Aborted \\
-Cancelled & Cancelled \\
-\end{tabularx}
command-line tools (see~\ref{e:change-acl}). Each entry of an ACL can
specify either a user subject name, a name of a VOMS group, or an attribute
specified in the Full qualified attribute name format (the FQAN support is
-only available in \LBnew). An ACL assigned to a job is returned as part of
+available since \LBver{2.0}). An ACL assigned to a job is returned as part of
job status information.
Besides of using the ACLs, the \LB administrator can also specify a~set of
User registers for notifications via notification client \verb'glite-lb-notify', described in Section
\ref{s:lb-notify}.
Conditions under which the notification is sent can be specified. For example - job XY reaches status
-DONE. In \LBold, one or more JOBID's are required in the condition and only a single occurence
-of a specific attribute is allowed among ANDed conditions. In \LBnew, more complex conditions are allowed.
+DONE. In \LBver{1.x}, one or more JOBID's are required in the condition and only a single occurence
+of a specific attribute is allowed among ANDed conditions. In \LBver{2.x}, more complex conditions are allowed.
The registration is then delivered to \LB server where it is stored.
At the same time, server generates a unique notification ID for the registration and returns it to the
In all cases it is necessary to have the user certificate installed in the browser.
-Since \LBnew, it is also possible to obtain the above results in a machine readable
+Since \LBver{2.0}, it is also possible to obtain the above results in a machine readable
\verb'key=value' form by adding a suffix \verb'text' to the above URLs. For example
\begin{verbatim}
curl -3 --key $X509_USER_KEY --cert $X509_USER_CERT \
\end{verbatim}
-Note that \LBold supported only using VOMS group names, not full FQANs,
-whose support has been introduced only in \LBnew. \LBold also did not
+Note that \LBver{1.x} supported only using VOMS group names, not full FQANs,
+whose support has been introduced in \LBver{2.0}. \LBver{1.x} also did not
allowed the users to use symbolic names for the values specifying ACL
setting and integers must be used instead. For example, to grant access
-right on a \LBold server one has to use following syntax:
+right on a \LBver{1.x} server one has to use following syntax:
\begin{verbatim}
glite-lb-logevent -e ChangeACL -s UserInterface -p -j <job_id> \
These APIs are provided as sets of C/C++ header files and shared libraries.
The library implements communication protocol with other \LB components
(logger and server), including encryption, authentication etc.
-\LBnew provides an experimental Java binding of the logging API.
+Since \LBver{2.0} an experimental Java binding of the logging API is available.
We do not describe the API here in detail; it is documented in~\LB Developer's
Guide\cite{lbdg},
Finally, certain frequent queries (all user's jobs, single job status, \dots)
are available as HTML pages (by pointing ordinary web browser to the \LB server
-endpoint), or as simple text queries (\LBnew only) intended for scripts.
+endpoint), or as simple text queries (since \LBver{2.0}) intended for scripts.
See~%
\ifx\insideUG\undefined
\cite{lbug}
\emph{\LB proxy} is the implementation of the concept of local view on job state (see
\ifx\insideUG\undefined{\cite{lbug}}\else{Sect.~\ref{local}}\fi). Since
-\LBnew, \LB proxy is intergrated into \LB server executable. When deployed (on
+\LBver{2.0}, \LB proxy is intergrated into \LB server executable. When deployed (on
the WMS node in the current gLite middleware) it takes over the role of the
local-logger daemon---it accepts the incoming events, stores them in files, and
forwards them to the inter-logger.
\lstinline'EDG_WLL_QUERY_OP_GREATER' & Attribute is less than the operand value. \\
\lstinline'EDG_WLL_QUERY_OP_WITHIN' & Attribute is in given interval. \\
\lstinline'EDG_WLL_QUERY_OP_UNEQUAL' & Attribute is not equal to the operand value. \\
-\lstinline'EDG_WLL_QUERY_OP_CHANGED' & Attribute has changed from last check (supported since \LBnew in notification matching). \\
+\lstinline'EDG_WLL_QUERY_OP_CHANGED' & Attribute has changed from last check (supported since \LBver{2.0} in notification matching). \\
\end{tabularx}
\caption{Query record specific operations.}
\label{t:cqueryop}
The simplest use case corresponds to the situation when an exact job ID
is known and the only information requested is the job status. The job ID
-format is described in~\cite{djra1.4}. In \LBnew, it is also possible to
+format is described in~\cite{djra1.4}. Since \LBver{2.0}, it is also possible to
query all jobs belonging to a specified user, VO or RB.
The following example shows how to retrieve the status information
% useful definitions
\def\LB{L\&B\xspace}
-\def\LBnew{\LB version 2.0\xspace}
-\def\LBold{\LB version 1.x\xspace}
+\newcommand\LBver[1]{\textbf{\LB version {#1}\xspace}}
\def\JP{JP\xspace}
%\def\eg{e.\,g.}
\def\eg{for example\xspace}
\LB server and port to contact must be specified with GLITE\_WMS\_NOTIF\_SERVER
environment variable.
-\verb'glite-lb-notify' is supported on in \LBnew. In \LBold, \verb'glite-lb-notify'
+\verb'glite-lb-notify' is supported on in \LBver{2.x}. In \LBver{1.x}, \verb'glite-lb-notify'
with very limited functionality can be found in \verb'examples' directory.
\verb'glite-lb-notify' support these actions:
\LB became an independent part of the
gLite\footnote{\url{http://www.glite.org}} middleware~\cite{glite}.
-\textbf{Two major versions of \LB service are covered by this document -- \LBold,
-which was included in gLite 3.1, and current \LBnew that is part of gLite 3.2.
-The older version of \LB that appeared in gLite 3.0 became obsolete and is not maintained anymore.}
-
The complete \LB Documentation consists of the following parts:
\begin{itemize}
\item \textbf{\LB User's Guide}
\input{LBTP-Abstract}
\end{itemize}
+\textbf{The following versions of \LB service are covered by these documents:}
+\begin{itemize}
+\item \LBver{2.2}: current development version, available through CVS only,
+\item \LBver{2.1}: currently in certification, to be released in April 2010,
+\item \LBver{2.0}: current stable version, in production as part of gLite 3.2,
+\item \LBver{1.x}: old stable version, in production as part of gLite 3.1.
+\end{itemize}
+\textbf{The older version of \LB that appeared in gLite 3.0 became obsolete and is not maintained anymore.}
+
+
Updated information about \LB service (including the \LB service roadmap) is available at the
\LB homepage:
\begin{center}
git://scientific.zcu.cz / jra1mw.git / commitdiff