 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introduzione
Nelle edizioni commerciali è possibile utilizzare l'API bakery per scrivere i cosiddetti plug-in dell'agente, che includono funzioni nei pacchetti dell'agent bakery. Nella maggior parte dei casi, queste funzioni sono plug-in dell'agente, cioè script aggiuntivi che devono essere eseguiti dall'agente Checkmk, e i file di configurazione dei plug-in. Tuttavia, possono anche influenzare le funzioni del gestore di pacchetti se possono essere mappati includendo file, eseguendo scriptlet di pacchetti (per i formati di pacchetti RPM, DEB e Solaris PKG) o se definiscono voci di configurazione specifiche per l'agente Windows (in YAML). Tutti questi "artefatti" possono essere descritti nell'API bakery utilizzando una sintassi uniforme.
Ad esempio, uno scenario applicativo del mondo reale è il seguente: hai letto l'introduzione allo sviluppo di estensioni di Checkmk e, ispirandoti ad essa, hai scritto il tuo plug-in di controllo basato sull'agente e il plug-in dell'agente ad esso associato, che hai poi combinato in un unico pacchetto di estensione di Checkmk (MKP).
Ora vuoi rendere il plug-in dell'agente configurabile (ad esempio, consentirgli di essere eseguito solo da determinati utenti o su determinati host) e inoltre eseguire azioni durante l'installazione o la disinstallazione del pacchetto dell'agente. Per farlo, puoi utilizzare l'API bakery - come ausilio per il confezionamento e la distribuzione, come ti mostreremo in questo articolo con uno scenario di esempio. In questo modo crei due nuovi file, che possono essere confezionati insieme ai file del plug-in dell'agente esistente per creare un nuovo MKP. Puoi anche trovare un esempio accuratamente commentato di questa procedura nel Checkmk Exchange: l'Hello world! MKP(scompattato su GitHub), che è strettamente basato sullo scenario di esempio presentato in questo articolo.
Nota: l'API bakery non fornisce funzioni per la configurazione del plug-in bakery, cioè per la creazione del set di regole associato, né per il contenuto dei file forniti con il plug-in, es. i plug-in dell'agente.
 |
Anche se l'agent bakery è incluso solo nelle edizioni commerciali, l'API bakery è presente in tutte le edizioni a partire da Checkmk 2.3.0. Questo permette agli utenti di Checkmk Raw di creare pacchetti di estensione che possono essere installati su tutte le edizioni. Se i pacchetti creati con l'API bakery vengono installati su un Checkmk Raw, la funzionalità aggiuntiva viene semplicemente ignorata. |
2. La documentazione dell'API
2.1. Versione
Il software e la documentazione dell'API bakery provengono dalla stessa fonte, pertanto la documentazione dell'API corrisponde sempre al software e descrive esattamente ciò che l'API è in grado di fare; non è quindi necessario descrivere la parte di riferimento delle funzioni, delle classi, dei parametri, ecc. disponibili nella Guida dell'utente Checkmk, ma è possibile trovare la documentazione dell'API al di fuori di questa Guida dell'utente, direttamente nell'istanza Checkmk.
L'API e la sua documentazione sono numerate a due livelli secondo lo standard Semantic Versioning 2.x nel formato X.Y, dove X indica una versione maggiore e Y una versione minore. Una nuova versione minore contiene nuove funzionalità compatibili con il passato. Una nuova versione maggiore, invece, può contenere modifiche che rendono l'API incompatibile con la versione maggiore precedente.
La versione 1 è la versione attuale dell'API bakery descritta in questo articolo. Ogni plug-in dichiara esplicitamente la versione dell'API su cui si basa al momento dell'accesso all'API.
L'API segue uno schema di versioning diverso da quello del software Checkmk. Tuttavia, la mappatura delle versioni della documentazione dell'API e del software Checkmk è molto semplice, come imparerai nel prossimo capitolo.
2.2. Accesso alla documentazione dell'API
La documentazione dell'API bakery è disponibile in formato HTML per la visualizzazione in un browser web e può essere aperta dalla GUI web di Checkmk: dalla barra di navigazione del menu Help > Developer resources > Plug-in API references:
La documentazione API del plug-in viene visualizzata in una nuova finestra (o scheda) del browser:
In questa finestra viene visualizzata la documentazione API relativa allo sviluppo dei plug-in di controllo, ad esempio qui troverai la documentazione dell'API Check oltre a quella dell'API bakery. La documentazione API viene generata e visualizzata con Sphinx.
Puoi trovare la documentazione dell'API bakery nelle versioni supportate dalla versione di Checkmk installata nel tuo sito.
3. Utilizzo dell'API
3.1. Uno scenario di esempio
Dimostreremo l'uso dell'API con il seguente scenario di esempio:
Viene fornito un plug-in con il nome
hello_worldper l'agente Checkmk.Il plug-in dell'agente esiste in tre varianti - per Linux, Solaris e Windows - e deve essere incluso nei pacchetti dell'agente anche per questi tre operatori. I file corrispondenti sono disponibili e si chiamano
hello_world(per Linux),hello_world.solaris.ksh(per Solaris) ehello_world.cmd(per Windows).
Gli script Python, shell e CMD sono solo esempi. Un plug-in dell'agente può essere qualsiasi file eseguibile sul file system di destinazione.
In questo contesto non siamo interessati al contenuto effettivo dei file. La funzione dei plug-in dell'agente non è oggetto dell'API bakery. Puoi trovare maggiori informazioni nell'introduzione allo sviluppo dei tuoi plug-in di controllo agent-based.Dovrebbe essere configurabile se l'output del plug-in debba essere cache, cioè in questo caso il plug-in verrà eseguito nuovamente dall'agente solo una volta trascorso l'intervallo di tempo configurato (intervallo di esecuzione).
Il plug-in deve essere configurato nel menu di configurazione tramite le impostazioni dell'agent bakery con le variabili
userecontent. Il plug-in Linux legge la configurazione dal file di configurazionehello_world.json, mentre il plug-in Solaris la legge dal filehello_world.cfg. Il plug-in Windows legge le vocihello_world.userehello_world.contentdal file di configurazione YAML dell'agente Windows.
In ogni caso, l'accesso a queste risorse deve essere implementato nel plug-in dell'agente e non è gestito dall'API bakery.Per Linux e Solaris c'è un programma aggiuntivo
some_binary, che dovrebbe essere fornito ad es. come un piccolo script di shell, per poter avviare il plug-in dell'agente Checkmk con un comando indipendente.In Linux e Solaris, dopo l'installazione dell'agente, dovrebbe essere scritto sul syslog, tramite una routine del gestore di pacchetti, che
hello_worldè stato installato. Dopo la disinstallazione dell'agente, analogamente, dovrebbe essere scritto sul syslog chehello_worldè stato disinstallato.
In Linux sono comuni gli scriptpostinsteprerm: nello scriptpostinstcrei, ad esempio, una cache e avvii un daemon, mentre nello scriptprermpuoi fermare nuovamente il daemon e cancellare la cache. Per maggiori informazioni sull'uso dimaintainer scripts, consulta la documentazione di Debian.
3.2. Creare un set di regole
Per un plug-in di Bakery deve esistere un insieme di regole per il Setup, con le quali il plug-in può essere configurato tramite la GUI. Nel caso più semplice, l'insieme di regole si limita ad attivare un plug-in assegnandolo a determinati host. La creazione di un insieme di regole non fa parte dell'API bakery. Puoi trovare un'introduzione a questo tema nell'articolo Sviluppare i propri plug-in di controllo agent-based. Lì vengono spiegate anche le convenzioni di percorso per la memorizzazione dei set di regole.
Set di regole minimali
Un esempio di set di regole minimale, che si limita ad attivare la distribuzione di un plug-in, potrebbe essere il seguente. Le classi importate sono più estese del necessario per coprire anche l'esempio esteso. La differenza più evidente rispetto al set di regole per i plug-in dell'agente è l'utilizzo della classe AgentConfig al posto di CheckParameters.
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# Shebang only needed for editor!
from cmk.rulesets.v1 import Label, Title, Help
from cmk.rulesets.v1.form_specs import (
BooleanChoice,
DefaultValue,
DictElement,
Dictionary,
String,
TimeSpan,
TimeMagnitude
)
from cmk.rulesets.v1.rule_specs import AgentConfig, HostCondition, Topic
def _parameter_form_bakery():
return Dictionary(
elements = {}
)
rule_spec_hello_world_bakery = AgentConfig(
name = "hello_world",
title = Title("Hello bakery!"),
topic = Topic.GENERAL,
parameter_form = _parameter_form_bakery,
)Set di regole esteso
Tuttavia, nello scenario di esempio, abbiamo specificato che deve essere scelto un intervallo di esecuzione e che devono essere impostate le due variabili user e content. Queste variabili sono definite come chiavi nel file Dictionary, che viene restituito dalla funzione specificata come parameter_form.
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# Shebang only needed for editor!
from cmk.rulesets.v1 import Label, Title, Help
from cmk.rulesets.v1.form_specs import (
BooleanChoice,
DefaultValue,
DictElement,
Dictionary,
String,
TimeSpan,
TimeMagnitude
)
from cmk.rulesets.v1.rule_specs import AgentConfig, HostCondition, Topic
def _parameter_form_bakery():
return Dictionary(
elements = {
"user": DictElement(
parameter_form = String(
title = Title("User for example plugin"),
)
),
"content": DictElement(
parameter_form = String(
title = Title("The actual content"),
)
),
"interval": DictElement(
parameter_form = TimeSpan(
title = Title("Run asynchronously"),
label = Label("Interval for collecting data"),
displayed_magnitudes = [TimeMagnitude.SECOND, TimeMagnitude.MINUTE],
prefill = DefaultValue(300.0),
)
)
}
)
rule_spec_hello_world_bakery = AgentConfig(
name = "hello_world",
title = Title("Hello bakery!"),
topic = Topic.GENERAL,
parameter_form = _parameter_form_bakery,
)Il GUI risultante da questo set di regole è mostrato nella seguente schermata:
3.3. Creazione di un file plug-in
Il file plug-in di hello_world.py è memorizzato nella parte locale della struttura della directory del sito, all'indirizzo local/lib/check_mk/base/cee/plugins/bakery/.
Un plug-in di Bakery viene creato sotto forma di un file che viene importato come modulo di Python 3. Pertanto, seguendo la convenzione di Checkmk, anche i file plug-in iniziano con le seguenti righe:
#!/usr/bin/env python3
# -*- coding: utf-8 -*-Trattandosi di un modulo, tutte le classi e le funzioni necessarie devono essere importate all'inizio.
3.4. Accedere all'API
Tutti gli oggetti dell'API bakery sono disponibili sotto cmk.base.cee.plugins.bakery.bakery_api.vX, dove X indica il numero di versione dell'API, nell'esempio 1. Poiché il file del plug-in si trova nel namespace cmk.base.cee.plugins.bakery, funzionerà anche un'importazione relativa da .bakery_api.v1:
from .bakery_api.v1 import (
OS,
DebStep,
RpmStep,
SolStep,
Plugin,
PluginConfig,
SystemBinary,
Scriptlet,
WindowsConfigEntry,
register,
FileGenerator,
ScriptletGenerator,
WindowsConfigGenerator,
quote_shell_string,
)Nell'esempio precedente, vengono importati solo i nomi necessari per lo scenario di esempio.
3.5. Gli oggetti disponibili nell'API
I nomi disponibili nell'API bakery sono descritti in dettaglio nella documentazione dell'API. In questo capitolo, tuttavia, gli oggetti sono introdotti brevemente, in quanto ciò è utile per comprendere l'implementazione dello scenario di esempio.
Identificatori / Enumerazioni
Per specificare i singoli artefatti del plug-in, sono disponibili delle enumerazioni (Enum) che possono essere utilizzate per specificare varie proprietà, solitamente sotto forma di argomento:
OS- Il sistema operativo nel contesto dell'API bakery.DebStep- Una fase di transazione per uno script DEB "mantenitore".RpmStep- Una fase di transazione per uno "scriptlet" RPM.SolStep- Un passo di transazione per uno "script di installazione" Solaris PKG.
Artefatti
I file e i contenuti dei file che costituiscono i componenti effettivi di un plug-in sono chiamati artefatti e vengono descritti utilizzando classi appropriate, che possono essere suddivise nelle seguenti categorie:
File (
Plugin,SystemBinary,PluginConfig,SystemConfig) - Ogni file da fornire all'agente Checkmk è descritto con un oggetto. Il tipo di file è descritto dalla classe. È necessario definire un oggetto separato per ogni sistema operativo su cui il file deve essere distribuito.Scriptlets (
Scriptlet) - Un "maintainer script" DEB, uno "scriptlet" RPM o uno "script di installazione" PKG Solaris da eseguire durante l'installazione, la disinstallazione o l'aggiornamento dell'agente nella fase di transazione specificata (es.preinstall,postremove).Voci di configurazione di Windows (
WindowsConfigEntry,WindowsConfigItems,WindowsGlobalConfigEntry,WindowsSystemConfigEntry) - Anche le voci del file di configurazione YAML per l'agente Windows sono descritte utilizzando classi appropriate.
Questi artefatti sono descritti in funzioni di callback corrispondenti alla loro categoria. Le singole funzioni vengono passate alla funzione register con gli argomenti files_function, scriptlets_function, windows_config_function. Si tratta di funzioni generatrici che restituiscono i singoli artefatti specificati. La valutazione viene effettuata dall'agent bakery.
Le funzioni ricevono vari parametri come argomenti che possono essere valutati per costruire e determinare gli artefatti restituiti. I parametri sono, da un lato, la configurazione GUI del rispettivo agent da cuocere (conf) e, dall'altro, l'hash dei file di configurazione e plug-in dell'agente corrente (aghash).
La funzione di registrazione
La registrazione viene eseguita con la funzione register, che viene richiamata quando si importa il plug-in Bakery come modulo.
La funzione riceve come argomenti i singoli componenti del plug-in Bakery: il nome del plug-in (name) e le sue funzioni (files_function, scriptlets_function, windows_config_function), ognuna delle quali restituisce una categoria di artefatto.
Annotazioni di tipo
I nomi delle annotazioni di tipo (FileGenerator, ScriptletGenerator, WindowsConfigGenerator, WindowsConfigContent) possono essere utilizzati facoltativamente per identificare il tipo di funzione specificata, es:
def get_files(conf: dict) -> FileGenerator:
yield Plugin(...)
yield PluginConfig(...)
def get_scriptlets(conf: dict) -> ScriptletGenerator:
yield Scriptlet(...)
def get_windows_config(conf: dict) -> WindowsConfigGenerator:
content: WindowsConfigContent = conf["some_entry"]
yield WindowsGlobalConfigEntry(name="some_name",content=content)Funzioni helper
È possibile utilizzare le seguenti funzioni helper:
quote_shell_string- Questa funzione può essere utilizzata per convertire un'espressione stringa in modo che venga correttamente riconosciuta come espressione dalla shell nel file risultante, senza dover mascherare manualmente le virgolette nel codice Python.password_store- Questo modulo permette di accedere alle password memorizzate nell'archivio password di Checkmk.
3.6. Registrazione
La registrazione del plug-in con Checkmk con il nome del plug-in e le sue funzioni si ottiene con la funzione register.bakery_plugin:
register.bakery_plugin(
name = "hello_world",
files_function = get_hello_world_plugin_files,
scriptlets_function = get_hello_world_scriptlets,
windows_config_function = get_hello_world_windows_config,
)Le funzioni get_hello_world_windows_config, get_hello_world_scriptlets e get_hello_world_plugin_files qui specificate sono spiegate in dettaglio nei capitoli successivi.
3.7. Configurazione dell'agente Windows
Nel nostro esempio, è necessario definire l'intervallo di esecuzione e la configurazione del plug-in deve poter essere effettuata tramite due variabili. Assicurati di definire le chiavi e i tipi di dati come definiti nel set di regole creato in precedenza.
class HelloWorldConfig(TypedDict, total=False):
interval: float
user: str
content: str
def get_hello_world_windows_config(conf: HelloWorldConfig) -> WindowsConfigGenerator:
yield WindowsConfigEntry(path=["hello_world", "user"], content=conf["user"])
yield WindowsConfigEntry(path=["hello_world", "content"], content=conf["content"])Nella funzione get_hello_world_windows_config, utilizziamo l'argomento conf per accedere alla configurazione impostata tramite il set di regole nella GUI: l'intervallo di tempo per la riesecuzione sull'output cache (interval) e le due variabili che possono essere utilizzate per configurare il plug-in (user, content). In questo caso assumiamo che la configurazione del set di regole sia fornita come dict. Utilizzando TypedDict della classe HelloWorldConfig possiamo impostare un accesso standardizzato ad essa.
Quindi WindowsConfigEntry viene utilizzato per specificare le voci delfile di configurazione dell'agente YAML-Windows da cui leggere i valori di user e content.
3.8. Script d'installazione per Linux
Su Linux e Solaris, i messaggi syslog devono essere scritti durante l'installazione e la disinstallazione dell'agente. Qui mostriamo solo un'implementazione della distribuzione Linux Debian:
def get_hello_world_scriptlets(conf: Any) -> ScriptletGenerator:
installed_lines = ['logger "Installed hello_world"']
uninstalled_lines = ['logger "Uninstalled hello_world"']
yield Scriptlet(step=DebStep.POSTINST, lines=installed_lines)
yield Scriptlet(step=DebStep.POSTRM, lines=uninstalled_lines)
# yield Scriptlet(step=RpmStep.POST, lines=installed_lines)
# yield Scriptlet(step=RpmStep.POSTUN, lines=uninstalled_lines)
# yield Scriptlet(step=SolStep.POSTINSTALL, lines=installed_lines)
# yield Scriptlet(step=SolStep.POSTREMOVE, lines=uninstalled_lines)Vengono prima definiti i comandi per i messaggi syslog e poi gli script di installazione per Debian (DebStep) che devono essere eseguiti dopo l'installazione (POSTINST) e dopo la disinstallazione (POSTRM). Nei commenti sottostanti troverai anche le linee corrispondenti per le distribuzioni che utilizzano RPM e per Solaris.
Nota: dopo le righe di comando che hai inserito, gli script di installazione vengono caricati con ulteriori comandi da Checkmk. Pertanto, per assicurarti che tutti i comandi degli script vengano eseguiti, non terminare il tuo set di comandi con exit 0.
3.9. Il plug-in dell'agente per Linux
La configurazione del plug-in dell'agente per Linux è la seguente. Assicurati di convertire l'intervallo passato in Integer poiché il set di regole e la bakery utilizzano tipi di dati diversi.
def get_hello_world_plugin_files(conf: HelloWorldConfig) -> FileGenerator:
interval = conf.get('interval')
yield Plugin(
base_os = OS.LINUX,
source = Path('hello_world'),
target = Path('hello_world'),
interval = int(interval),
)
yield PluginConfig(
base_os = OS.LINUX,
lines = _get_linux_cfg_lines(conf['user'], conf['content']),
target = Path('hello_world.json'),
include_header = False)
for base_os in [OS.LINUX]:
yield SystemBinary(
base_os = base_os,
source = Path('some_binary'),
)
def _get_linux_cfg_lines(user: str, content: str) -> List[str]:
config = json.dumps({'user': user, 'content': content})
return config.split('\n')Nella funzione get_hello_world_plugin_files, per prima cosa il file Python hello_world viene definito come plugin, cioè come un file eseguibile che deve essere eseguito dall'agente Checkmk come plug-in dell'agente. Poi PluginConfig viene utilizzato per specificare il file di configurazione hello_world.json che deve essere generato per il plug-in dell'agente Linux con le voci user e content.
Con la seconda funzione _get_linux_cfg_lines queste righe vengono scritte in formato JSON. Qui, il dizionario Python conf contiene i valori impostati con il set di regole della GUI, che vengono poi inseriti in un file JSON attraverso una piccola deviazione.
Infine, lo shell script aggiuntivo some_binary da consegnare deve essere collocato come SystemBinary sul sistema di destinazione nella directory dei programmi utente (per impostazione predefinita /usr/bin).
3.10. Il file plug-in per il nostro scenario di esempio
Mettendo insieme tutte le parti presentate finora e completandole, un plug-in per il nostro scenario di esempio potrebbe avere il seguente aspetto:
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# Shebang only needed for editor!
import json
from pathlib import Path
from typing import Iterable, TypedDict, List
from .bakery_api.v1 import (
OS,
DebStep,
RpmStep,
SolStep,
Plugin,
PluginConfig,
SystemBinary,
Scriptlet,
WindowsConfigEntry,
register,
FileGenerator,
ScriptletGenerator,
WindowsConfigGenerator,
quote_shell_string,
)
class HelloWorldConfig(TypedDict, total=False):
interval: float
user: str
content: str
def get_hello_world_plugin_files(conf: HelloWorldConfig) -> FileGenerator:
interval = conf.get('interval')
yield Plugin(
base_os = OS.LINUX,
source = Path('hello_world'),
target = Path('hello_world'),
interval = int(interval),
)
yield Plugin(
base_os =OS.SOLARIS,
source = Path('hello_world.solaris.ksh'),
target = Path('hello_world'),
interval = int(interval),
)
yield Plugin(
base_os = OS.WINDOWS,
source = Path('hello_world.cmd'),
target = Path('hello_world.bat'),
interval = int(interval),
)
yield PluginConfig(
base_os = OS.LINUX,
lines = _get_linux_cfg_lines(conf['user'], conf['content']),
target = Path('hello_world.json'),
include_header = False
)
yield PluginConfig(
base_os = OS.SOLARIS,
lines = _get_solaris_cfg_lines(conf['user'], conf['content']),
target = Path('hello_world.cfg'),
include_header = True
)
for base_os in [OS.LINUX, OS.SOLARIS]:
yield SystemBinary(
base_os = base_os,
source = Path('some_binary'),
)
def _get_linux_cfg_lines(user: str, content: str) -> List[str]:
config = json.dumps({'user': user, 'content': content})
return config.split('\n')
def _get_solaris_cfg_lines(user: str, content: str) -> List[str]:
# To be loaded with 'source' in Solaris shell script
return [
f'USER={quote_shell_string(user)}',
f'CONTENT={quote_shell_string(user)}',
]
def get_hello_world_scriptlets(conf: HelloWorldConfig) -> ScriptletGenerator:
installed_lines = ['logger -p local3.info "Installed hello_world"']
uninstalled_lines = ['logger -p local3.info "Uninstalled hello_world"']
yield Scriptlet(step=DebStep.POSTINST, lines=installed_lines)
yield Scriptlet(step=DebStep.POSTRM, lines=uninstalled_lines)
yield Scriptlet(step=RpmStep.POST, lines=installed_lines)
yield Scriptlet(step=RpmStep.POSTUN, lines=uninstalled_lines)
yield Scriptlet(step=SolStep.POSTINSTALL, lines=installed_lines)
yield Scriptlet(step=SolStep.POSTREMOVE, lines=uninstalled_lines)
def get_hello_world_windows_config(conf: HelloWorldConfig) -> WindowsConfigGenerator:
yield WindowsConfigEntry(path=["hello_world", "user"], content=conf["user"])
yield WindowsConfigEntry(path=["hello_world", "content"], content=conf["content"])
register.bakery_plugin(
name = "hello_world",
files_function = get_hello_world_plugin_files,
scriptlets_function = get_hello_world_scriptlets,
windows_config_function = get_hello_world_windows_config,
)3.11. Rendere disponibili i file
Affinché un plug-in di Bakery funzioni correttamente, tutti i file coinvolti devono essere collocati o scritti nella posizione corretta della struttura locale della directory del sito.
Si tratta, da un lato, del file del plug-in stesso e, dall'altro, degli oggetti restituiti da files_function. Questi oggetti descrivono file di configurazione creati direttamente dal plug-in dell'agente oppure fanno riferimento a file che devono essere memorizzati correttamente in modo da poter essere trovati quando si confezionano i pacchetti dell'agente.
Gli oggetti delle classi Plugin e SystemBinary indicano file esistenti che devono essere memorizzati. I file descritti come PluginConfig e SystemConfig devono ancora essere generati in base all'argomento lines, quindi non è necessario memorizzarli.
Infine, l'insieme dei file include anche il set di regole per il plug-in.
Nel prossimo e ultimo capitolo troverai la compilazione di tutte le directory.
4. File e directory
I file per il deployment di un plug-in Bakery devono essere inseriti nelle seguenti directory. Come sempre, tutte le specifiche qui riportate sono relative alla directory del sito (es. /omd/sites/mysite).
| Percorso del file | Descrizione |
|---|---|
|
Directory per il plug-in di Bakery (nel nostro esempio |
|
Directory per la memorizzazione dei plug-in dell'agente per Unix. |
|
Directory per la memorizzazione dei plug-in dell'agente per Windows. |
|
Directory per i programmi o gli shell script inclusi per gli operatori Unix (nell'esempio |
|
Directory per i programmi o gli script di shell forniti per Windows. |
|
Directory per i set di regole per la configurazione del plug-in dell'agente (nell'esempio |