Slamd null

If you want to start the client manager, then run start-client-manager. If you do run the client manager, you may need to go to the SLAMD Server Status page in the web interface and request that it create the desired number of client instances. Then, edit the slamd-monitor-client. From there, you can choose the type of job you want to schedule, and then you'll see the parameters that are available for that job. Some parameters are common to all types of jobs, including:.

Place in Folder -- The name of the folder in which the job should be organized. A job can only exist in a single "real" folder, but you can also use virtual folders to have the job appear elsewhere as well if you'd like. Description -- A brief, one-line description for the job.

If you want to provide more detailed information, you can use the "Job Comments" section at the bottom of the page. Stop Time -- The time that you want the job to stop running, if you want to specify an absolute stop time. In many cases, you'll probably want to specify a duration rather than a stop time. Duration -- The maximum length of time that you want the job to run.

You can provide this as just an integer value, which will be interpreted as the number of seconds that the job should run, but you can also include units if you want to make it a more human-readable value for example, "5 minutes" or "2 hours". Number of Clients -- The number of clients that should be used to run the job concurrently.

If you indicate that multiple clients should be used, then the SLAMD server will do its best to start the job as close to the same time on all the client systems. By default, the SLAMD server will pick any clients that are available although it will try to pick clients from different systems if possible and not operating in restricted mode. If you want to explicitly specify which clients should be used, then you can use the "Use Specific Clients" field in the advanced scheduling options.

Threads Per Client -- The number of concurrent threads that should be used to run the job on each client system. This should be an integer value that is greater than or equal to one. Statistics Collection Interval -- This indicates the time period over which the client should aggregate its statistics. The smaller the value, the more data points that you'll have, but also the more space that will be required to hold the job results. The minimum you can specify is 1 second, and that's a good choice for jobs that run for a very short period of time.

If you're running jobs for longer, then you'll probably want to have a higher collection interval. If you've configured the job with a maximum duration, you can leave this blank, and the server will automatically try to choose an appropriate value. Job Comments -- Arbitrary additional comments that you want to make available for the job. There will also be additional parameters that you can specify based on the type of job that you're running. Diaries, Triumphs, Failures, and Rants.

Discussion and deep-dive articles about LDAP. There will probably not be any "how to connect your latest gadget to LDAP" articles, unless that gadget is broken from an LDAP client perspective, in which case it might get special treatment.

The Archives section on the left has link to monthly collections. Skip to content. Like this: Like Loading About Terry Gardner Terry Gardner was a leading directory services architect with experience with many large scale directory services installations and messaging server installations, and was a Subject Matter Expert in the field of Directory Services and Solaris operating system performance.

Gardner also participated in the open-source software community. Gardner passed away in December, Bookmark the permalink.

Fill in your details below or click an icon to log in:. Email required Address never made public. Name required. Search This Blog Search for:. Blog at WordPress. Follow Following. Diaries, Triumphs, Failures, and Rants Join 1, other followers. Sign me up. The kinds of information that can be provided to a job to control the way in which it operates is also configurable. This section provides information about installing and running the components of the SLAMD environment.

Additional topics, like developing custom jobs for execution in the SLAMD environment, are not covered in this book. All components have been developed using the Java 1. Version 1. Some aspects of job execution are time sensitive, and differences in system clocks can cause inaccuracies in the results that they can obtain.

Therefore, time synchronization should be used on all systems in the SLAMD environment to ensure that such clock differences do not occur. The communication that occurs between clients and the SLAMD server requires that the host name of those systems be available. The entries that store information about scheduled jobs may be quite large.

It is therefore necessary to ensure that the configuration directory is properly tuned so it can properly handle these entries. A servlet engine is required to provide this capability. By default, SLAMD is provided with the Apache Tomcat servlet engine and this engine is quite capable of providing the administrative interface.

However, it should be possible to use any compliant servlet engine to host that interface. A Web browser must be installed on all systems that access the administration interface. Even text-based browsers are quite capable of performing all administrative tasks.

If SLAMD is to be used in a purely text-based environment, it is recommended that the Links browser be installed on systems that need to access the administration interface. The following procedure assumes that you have acquired the slamd It is available as a downloadable file for this book see "Obtaining the Downloadable Files for This Book" on page xxvii. Copy the slamd Uncompress the slamd If the gunzip command is not available on the system, the -d option with the gzip command:.

Extract the files from the slamd If you wish to use a name other than slamd for the base directory, simply rename that directory immediately after extracting the installation archive. However, once the SLAMD server has been started, the path in which it is installed should not be changed. Change to the newly created slamd directory. This shell script is used to start the SLAMD server and the administrative interface, but it must first be edited so that the settings are correct for your system.

Comment out, or remove the two lines at the top of the file that provide the warning message indicating that the startup file has not been configured. A page is displayed indicating that the SLAMD server is unavailable because it has not yet been configured. Click on the Initialization Parameters link to a page on which it is possible to specify the configuration directory settings. The configuration directory is the LDAP directory server that is used to store much of the configuration and all of the job data for jobs that have been scheduled.

Click on the Config Directory Address link. You are presented with a form that allows you to specify the address to use for the configuration directory server. The address must be entered as either an IP address or a host name, as long as the SLAMD server machine can contact the configuration directory machine using the provided address.

Repeat this process for the remaining configuration directory settings. TABLE describes the kind of values that should be used by each:. The DN of the user that should be used to bind to the configuration directory server. This DN must have full read and write permissions including the ability to add and remove entries for the portion of the directory that is to hold the SLAMD configuration data.

If this entry does not exist, the SLAMD server can create it provided that the DN specified is under an existing suffix in the configuration directory. It is recommended that the initial configuration be completed without SSL.

This communicates with the configuration directory server, finds the schema subentry, and adds the custom SLAMD schema definitions over LDAP while the server is online. This schema information must be added to the configuration directory before SLAMD can use it to store configuration and job information. If you prefer, you can add the schema information to the directory manually rather than over LDAP. This automatically adds all required entries to allow that directory instance to be used as the configuration directory for SLAMD.

All information added to the directory is at or below the configuration base DN. At least one entry in the hierarchy of the configuration base DN must already exist in the directory server before the configuration may be added to it. Click the Test Connection button at the bottom of the Initialization Settings page.

This establishes a connection to the configuration directory server, verifies that the bind DN and password provided are correct, and verifies that the SLAMD schema and configuration entries have been added to that directory. If all tests succeed, a message is displayed indicating that it is suitable for use as the SLAMD configuration directory.

If any failure occurs, details about that failure are displayed so that the problem may be corrected. This page normally displays a significant amount of information about the SLAMD server, including the number and types of jobs defined, the number of clients connected, and statistics about the Java environment in which SLAMD is running.

Rather, the actual execution is performed by SLAMD clients, and the server merely coordinates the activity of those clients. Therefore, before any jobs can be executed, it is necessary to have clients connected to the server to run those jobs.

Therefore, it is possible to install clients on different machines than the one on which the SLAMD server is installed.

In fact, this is recommended so the client and server do not compete for the same system resources, which could interfere with the ability of the client to obtain accurate results. Further, it is possible to connect to the SLAMD server with a large number of clients to process multiple jobs concurrently. In such cases, it is best to have those clients distributed across as many machines as possible to avoid problems in which the clients are competing with each other for system resources.

This file is available for download in two ways:. Copy the slamd-client Uncompress the slamd-client As in the server installation, the directory in which the client files are placed may be modified. However, unlike the server, the client does not store any path information.

Therefore, it is possible to move or rename the directory containing the SLAMD client files even after the client has been used. This script may be used to start the SLAMD client application, but it must first be edited so that the settings are correct for your system. Finally, comment out or remove the two lines at the top of the file that provide the warning message indicating that the file has not been configured.

This starts the client application, connects to the SLAMD server, and indicates that it is ready to accept new job requests. If a problem occurs, an error message is printed that indicates the cause of the problem so that it may be corrected. While it is not necessary to provide any arguments to this script, there are a couple of options that are supported.

One such option is the -a argument. This argument indicates that the client should aggregate all the data collected by each thread into a single set of statistics before sending those results to the SLAMD server. This can significantly reduce the volume of data that the client needs to send to the server and that the server needs to manage, but it does prevent the end user from being able to view performance information about each individual thread on the client it is still possible to view aggregate data for each client.

It is also possible to use the -v option when starting the client application. This starts the client in verbose mode, which means that it prints additional information that may be useful for debugging problems, including detailed information about the communication between the client and the server.

However, using verbose mode might incur a performance penalty in some cases and therefore it is recommended that its use be reserved for troubleshooting problems that cannot be solved with the standard output provided by the client. This interface provides a number of capabilities, including the ability to:. This section provides a brief overview of the administrative interface to describe how it can be used.

Any browser that supports the HTML 4. Provided that the SLAMD server is running, the left side of the page contains a navigation bar with links to the various tasks that can be performed. This navigation bar is divided into four major sections:. If access control is enabled in the administration interface, some sections or options may not be displayed if the current user does not have permission to use those features. Configuring the administrative interface to use access control is documented in a later section.

The Manage Jobs section provides options to schedule new jobs for execution, view results of jobs that have already been completed, view information about jobs that are currently running or awaiting execution, and view the kinds of jobs that may be executed in the SLAMD environment. These settings include specifying the settings used for communicating with the configuration directory and the settings used for access control.

These settings include options to configure the various components of the SLAMD server, and to customize the appearance of the administrative interface. This section also provides administrators with the ability to start and stop the SLAMD server, and a means of interacting with the cache used for storing access control information. One of the most important capabilities of the SLAMD server is the ability to schedule jobs for execution. You can schedule them to execute immediately or at some point in the future, on one or more client systems, using one or more threads per client system, and with a number of other options.

You can develop your own job classes and add them to the SLAMD server so that they are executed by clients. The process for defining new job classes is discussed later, but the SLAMD server is provided with a number of default job classes that can be used to interact with an LDAP directory server.

To schedule a job for execution, you must first follow the Schedule a Job link in the Manage Jobs section of the navigation sidebar. This displays a page containing a list of all job classes that have been defined to the server. To choose the type of job to execute, follow the link for that job class, and a new page is displayed containing a form in which the user may specify how the job is to be executed. Some of the parameters that can be specified are specific to the type of job that was chosen.

The parameters specific to the default job classes are documented in a later section. However, some options are the same for every type of job.

Description This field allows you to provide a brief description of the job that allows it to be distinguished in a list of completed jobs. This is an optional field. If no description is desired, leave this field blank. Start Time This field allows you to specify the time at which the job should start running.

If no value is provided, the job starts running as soon as possible. Stop Time This field allows you to specify the time at which the job should stop running, provided that it has not already stopped for some other reason. If no value is provided, the job is not stopped because of the stop time. Duration This field allows you to specify the maximum length of time in seconds that the job should be allowed to run.

This is different from the stop time because it is calculated from the time that the job actually starts running, regardless of the scheduled start time. If no value is provided, there is no maximum duration. Number of Clients This field allows you to specify the number of clients on which the job runs. When the time comes for the job to run, it is sent to the specified number of clients to do the processing. This is a required parameter, and it must be a positive integer.

Wait for Available Clients This checkbox allows you to specify what should happen if the time comes for the job to start but there is not an appropriate set of clients available to perform that processing. If this box is not checked, the job is cancelled. If this box is checked, the job is delayed until an appropriate set of clients is available. Threads per Client This field allows you to specify the number of threads that should be created on each client to run the job. Each thread executes the instructions associated with the job at the same time, which allows a single client to perform more work and generate a higher load against the target server.

However, specifying too many threads may cause a scenario in which the client system or the target server is overloaded, which could produce inaccurate results. Statistics Collection Interval This field allows you to specify the minimum interval over which statistics are collected while a job is being executed. Statistics are collected for the entire duration of the job, but they are also collected for each interval of the specified duration while that job is active.

This is helpful for graphing or otherwise analyzing the results of the job over time. Job Comments This text area allows you to add free-form text that describes additional aspects of the job that cannot be reflected through the other parameters associated with the job. Unlike the other parameters common to all jobs, the job comments field appears at the bottom of the schedule job form.

In addition, these comments can be edited after the job has started running or even after the job has completed. This makes it possible to provide comments on the job based on observations gathered during job execution. In addition to the above parameters, there are a number of other options that are available by clicking on the Show Advanced Scheduling Options button.

These options are more specialized than the above parameters, and therefore are not commonly used. However, they are available for use if necessary. These advanced options include:. Job Is Disabled This checkbox allows you to specify whether the job should be disabled when it is scheduled. When a job is disabled, it is not considered eligible for execution until it is enabled.

This can be beneficial for cases in which it is necessary to make changes to the job after it has been scheduled for example, if a number of jobs are scheduled at the same time and then individual changes need to be made to each of them. Number of Copies This field allows you to specify the number of copies that are made of the current job when it is scheduled. By default, only a single copy is made, but it is possible to specify any number of copies. This is useful for cases in which a number of jobs of the same type are to be executed with only minor differences between them, since each job can be edited after it is scheduled to make those minor changes.

Time Between Copy Startups This field allows you to specify the length of time in seconds that should be left between each job's start time when multiple jobs are scheduled. Note that this is the interval between start times for the jobs, not the time between the end of one job and the beginning of the next.