Modalità di controllo delle versioni delle personalizzazioni di sistema sui server di CA SDM

Il controllo versioni di CA SDM consente di gestire le personalizzazioni di sistema su tutti i server di CA SDM (client e server). In base alla configurazione di CA SDM, vengono utilizzati i client e i server seguenti:
casm173
Il controllo versioni di CA SDM consente di gestire le personalizzazioni di sistema su tutti i server di CA SDM (client e server). In base alla configurazione di CA SDM, vengono utilizzati i client e i server seguenti:
  • Configurazione convenzionale
    • Client: server secondario
    • Server: server primario
  • Configurazione con disponibilità avanzata
    • Client: server applicazioni e server di standby
    • Server: server in background
Esempio: In qualità di amministratori di sistema, si è aggiunto un campo nella pagina detail_usp_server.htmpl di CA SDM. Ora si desidera sincronizzare questa modifica sui vari client e server. Questo esempio viene utilizzato nello scenario per spiegare le modalità con cui la personalizzazione viene sincronizzata.
Il diagramma seguente mostra la procedura per il controllo versioni delle personalizzazioni di sistema sui server di CA SDM:
Schema raffigurante la Modalità di controllo delle versioni delle personalizzazioni di sistema sui server di CA SDM
Attenersi alla procedura seguente:
  1. Apportare le modifiche in CA SDM. In questo esempio, aggiungere il nuovo campo nella pagina HTMPL di CA SDM.
Verificare i prerequisiti
Verificare i seguenti prerequisiti:
  • Controllare che l'opzione ver_ctl sia impostata sul valore di
    aggiornamento
    . Quando si rileva una differenza di versione, sul client si tenta l'aggiornamento dei componenti interessati. Se l'aggiornamento riesce, la connessione client con il server continua, altrimenti la connessione viene chiusa. Per ulteriori informazioni sull'opzione ver_ctl, consultare la
    Guida in linea
    .
  • Controllare che il file server_secondary_custom.ver sia creato nella directory $NX_ROOT\site\mods del server primario o del server in background, a seconda della configurazione di CA SDM. Tutte le personalizzazioni di un componente di controllo versioni devono essere eseguite in questo file. Se il file non esiste, crearlo nella stessa posizione.
Modifica del file di controllo versioni del server
Dopo aver completato la personalizzazione (ad esempio, è stato aggiunto un campo nella pagina HTMPL), aggiungere o aggiornare i componenti del controllo versioni sul file di controllo versioni del server. Un componente del controllo versioni può rappresentare un file, una directory o il file delle variabili di ambiente client_nx.env.
Attenersi alla seguente procedura:
  1. Accedere al server seguente, a seconda della configurazione di CA SDM:
    • Convenzionale: server primario
    • Disponibilità avanzata: server in background
  2. Accedere alla seguente directory:
    $NX_ROOT\site\mods
  3. Aprire il file server_secondary_custom.ver.
  4. Aggiungere i componenti seguenti:
    [ MY_USP_SERVERS_HTMPL ] directory="$NX_ROOT/site/mods/www/htmpl/web/analyst/Analyst" filename="detail_usp_servers.htmpl" version="2.0 , 20121119" o_mode="RW" g_mode="RW" w_mode="RW" file_ctl
    Per ulteriori informazioni sull'aggiunta o sull'aggiornamento dei componenti di controllo delle versioni, consultare l'argomento Componenti di controllo versioni.
  5. Salvare il file server_secondary_custom.ver.
    Il componente di controllo versioni è stato aggiunto al file di controllo versioni.
Componenti di controllo versioni
Per definire un nuovo componente,
  • utilizzare la seguente sintassi. Le voci
    in corsivo
    rappresentano i dati specificati dall'utente. I parametri
    nome-componente
    e versione sono obbligatori. Altri parametri potrebbero essere obbligatori, in base al valore
    tipo-controllo
    . Tutti gli altri elementi rappresentano parole chiave che è necessario immettere esattamente come nel seguente esempio:
    [ component-name ] version = "x.x, yyyymmdd" control-type filename = "filename" directory = "directory" link = "link-directory" source = "source-directory" effectivity = "effect-spec" checksum min_release = "release" max_release = "release" component_type = "file-type" o_mode = "owner-mode" g_mode = "group-mode" w_mode = "world-mode"
    Per ulteriori informazioni sui parametri, consultare l'argomento Parametri del servizio Controllo versione. Per ulteriori informazioni sulla struttura e sulla sintassi dei file di controllo versioni, consultare i file .ver installati nella directory $NX_ROOT\site. Questi file contengono commenti e impostazioni di esempio che possono risultare utili.
Per aggiornare una voce di componente esistente,
  • Modificare il parametro. Ad esempio, modificare il numero di versione.
Per rimuovere un controllo da un componente,
  • Modificare il componente secondo la procedura descritta:
    ! uncontrol component-name
Parametri del servizio Controllo versione
I parametri seguenti sono validi per il servizio Controllo versione:
  • [ nome componente ]
    Specifica il nome di un elemento nel servizio Controllo versione. Il nome deve essere univoco e racchiuso tra parentesi quadre.
    il nome del componente
    non distingue tra maiuscole e minuscole. Questo parametro è necessario per iniziare la definizione di un componente.
  • Version = "x.x. dmmyyy"
    Specifica un numero di versione (
    x.x
    ) e una data (
    ddmmyyyy
    ) che definiscono la versione del componente. Questo parametro è obbligatorio e deve essere racchiuso tra virgolette. Il servizio Controllo versione verifica la versione di un componente confrontando il numero di versione e la data sul server con il numero di versione e la data sul client. I numeri di versione e le date devono corrispondere affinché il componente possa essere considerato sincronizzato tra il client e il server. Opzionalmente, se la proprietà checksum è abilitata, prima di essere aggiornato, il file viene verificato in base a tale proprietà.
  • tipo-controllo
    Specifica il tipo di versione del componente. Per tipo-controllo sono valide le seguenti impostazioni:
Impostazione
Descrizione
dir_ctl
Specifica che il componente rappresenta una directory. È necessario fornire il parametro directory per specificare il percorso alla directory. È possibile fornire anche il parametro di nome del file per filtrare un insieme di file nella directory. Le sottodirectory non vengono aggiornate in UNIX o in Windows.
file_ctl
Specifica che il componente rappresenta un file. È necessario fornire il parametro filename per specificare il percorso al file.
Nxenv_ctl
Specifica che il componente rappresenta il file client_nx.env, utilizzato per memorizzare le variabili di ambiente interne di CA SDM. Il controllo versioni e Gestione Opzioni di CA SDM gestiscono automaticamente questo file. È presente un solo componente nxenv_ctl e il suo nome deve essere CLIENT_NXENV.
ver_ctl
Si tratta del tipo di controllo predefinito. Specifica che il componente è generico, ovvero, non è associato a nessun oggetto esterno specifico. È possibile utilizzare un componente generico per eseguire il controllo della versione del client oppure di un file o di una directory le cui dimensioni sono eccessive per un aggiornamento automatico. I componenti con un tipo di controllo ver_ctl non possono essere aggiornati; in caso di mancata corrispondenza di versione in un componente ver_ctl quando il server è in modalità AGGIORNAMENTO, si verifica un errore di connessione del client.
  • filename="nomefile"
    Specifica il nome di un file in Controllo versione. Non contiene specifiche di directory. Questo parametro è obbligatorio per i componenti file_ctl ma è opzionale per i componenti di controllo directory (dir_ctl). Quando utilizzato con i componenti directory, il parametro filename agisce come un filtro file per limitare i file associati al componente dir_ctl. Ad esempio, se il parametro filename per un componente dir_ctl è *.README, un aggiornamento da tale directory include solo i file il cui nome termina con “.README.”.
  • directory="directory"
    Specifica il percorso alla directory dei componenti dir_ctl oppure alla directory contenente il file dei componenti file_ctl. Questo parametro viene ignorato per i componenti ver_ctl e nxenv_ctl. Il percorso alla directory deve essere racchiuso tra virgolette e può contenere i riferimenti alle variabili di ambiente preceduti dal simbolo $.
    Per separare le sottodirectory, nel percorso utilizzare sempre le barre (/) e non le barre rovesciate (\), questa indicazione è valida anche per il server Windows.
  • link="directory-collegamento"
    Specifica una directory di collegamento sul client nello stesso formato precedentemente descritto per il parametro directory. Questo parametro è opzionale per i componenti file_ctl e dir_ctl e viene ignorato per i componenti ver_ctl e nxenv_ctl. Se specificato, l'aggiornamento a un client Linux causa il posizionamento nella directory di collegamento di un collegamento simbolico che punta al file effettivo copiato nell'ubicazione specificata dal parametro directory. Se si aggiorna un client Windows, il file effettivo viene copiato nella posizione del parametro link e nella posizione del parametro directory.
  • source="directory-origine"
    (Opzionale) Specifica una directory differente sul server in cui il server può recuperare i file per la distribuzione. Questo parametro ha lo stesso formato precedentemente descritto per il parametro directory. È utile se i file da consegnare al client sono differenti rispetto agli stessi file presenti nella directory del server. Questo parametro viene utilizzato per indicare al server di recuperare il file dalla
    directory-fonte
    e distribuirlo nella posizione del client specificata dal parametro directory. Il parametro directory è obbligatorio se si specifica il parametro source.
  • effectivity="spec-efficacia"
    (Opzionale) Specifica se il client deve acquisire il componente. Consente di escludere il download in determinati client. Se un client è escluso dalla specifica del parametro effectivity, non può acquisire il componente. Se questo parametro viene omesso, tutti i client ricevono il componente. Per questo parametro vengono utilizzati i simboli seguenti:
    • + (segno più)
      Indica di aggiungere un gruppo di client.
    • - (segno meno)
      Indica di escludere un gruppo di client.
Sono validi i seguenti gruppi di client:
  • SUN4SOL
  • AIX
  • LINUX
  • LINUX390
  • HP
  • WINDOWS_CLIENTS
  • UNIX_CLIENTS
Ad esempio, la specifica seguente indica che solo i client UNIX acquisiscono i file:
effectivity = "+ UNIX_CLIENTS"
  • checksum
    Indica al componente di eseguire l'aggiornamento se il checksum del componente sul client non corrisponde al relativo checksum sul server. Se applicato a una directory, il checksum viene applicato a ogni file.
  • min_release=“release” e max_release="release"
    Specifica il client meno recente e quello più recente a cui dovrebbe essere distribuito il componente. Le istruzioni nel file server_default.ver definiscono le release. Questi parametri sono nel formato illustrato di seguito, dove Ga
    xx
    indica la release e i valori successivi sono i livelli generali associati alla release.
    ! Release GA50 50MVV000900 50W7T000900 ! Release GA45 45MW000900 50WTT000900
    L'ordine indica che GA50 è più recente di GA45.
  • component_type
    Specifica il tipo di componente utilizzato. Vengono utilizzati i seguenti tipi di componenti:
Impostazione
Descrizione
file
Si tratta del tipo di componente predefinito. Specifica che i file copiati sul client sono ottenuti direttamente dall'ubicazione del server indicata dal parametro directory.
exe_file
Specifica che i file copiati sul client sono ottenuti da una posizione del server dipendente dal sistema operativo del client, come mostrato di seguito:
windows (Windows)
sun4Sol (Solaris)
hp (HP-UX)
aix (AIX)
linux (Linux)
linux390 (Linux390)
Le posizioni di queste sottodirectory dipendono dall'impostazione del parametro directory. Se questo parametro è impostato, le sottodirectory si trovano nella
directory
indicata. In caso contrario, si trovano nella directory bin del percorso di installazione principale di CA SDM.
  • o_mode="modalità-proprietario"
    Specifica le autorizzazioni di accesso al file per il proprietario del file.
  • g_mode="modalità-gruppo"
    Specifica le autorizzazioni di accesso file per gli utenti presenti nel gruppo del proprietario del file (solo per i client UNIX).
  • w_mode="modalità-globale"
    Specifica le autorizzazioni di accesso file per gli utenti non compresi nel gruppo del proprietario del file (solo per i client UNIX).
    I tre parametri mode consentono la gestione sul server di versioni differenti dello stesso file eseguibile. Specificano i controlli per l'accesso al file quando viene copiato sul client. Questi parametri vengono utilizzati solo durante un'operazione di aggiornamento. Sono costituiti da uno a tre caratteri, con il significato seguente:
Impostazione
Descrizione
R
Lettura
W
Scrittura
X
Esegui
I client PC ignorano le autorizzazioni di tipo Scrittura ed Esecuzione.
È possibile specificare una combinazione qualsiasi composta da una o più modalità di accesso file. Sui client UNIX, al file viene assegnata la modalità di accesso specificata. Sui client PC, il file è in modalità di scrittura o sola lettura, in base a come è stato specificato il parametro w_mode.
Riavvio di CA SDM sul client
CA SDM viene riavviato sui server client per aggiornare i file di controllo versioni del client con le personalizzazioni.
Selezionare
Start
,
Impostazioni
,
Pannello di controllo
,
Strumenti di amministrazione
,
Servizi
. Fare clic con il pulsante destro del mouse sul
server di CA SDM
e selezionare
Inizio
per riavviare o avviare un server.
Attenersi alla seguente procedura:
  1. Per la configurazione convenzionale, riavviare il server secondario.
  2. Per la configurazione con disponibilità avanzata, completare i passaggi seguenti:
    1. Riavviare tutti i server di standby.
    2. Riavviare il server applicazioni meno attivo.
    3. Avviare il server applicazioni.
    4. Eseguire i passaggi d ed e per più server applicazioni.
    Il client si connette al server per inviare un elenco dei componenti controllati. Il server confronta l'elenco con il proprio elenco principale. I componenti interessati sul client sono stati aggiornati.
Selezione del server applicazioni meno attivo
Scegliere un server applicazioni con l'attività utente più bassa. Eseguire il comando seguente su ciascun server applicazioni per scegliere quello con il numero più basso di sessioni attive o con nessuna sessione attiva.
pdm_webstat
: Questo comando non acquisisce le sessioni SOAP o del servizio Web REST.
Arresto dell'altro server applicazioni
Tutti gli utenti attivi su un server applicazioni vengono informati di spostarsi sul server applicazioni meno attivo prima di arrestarlo. Assicurarsi di avere riavviato il server applicazioni meno attivo prima di spostare tutti gli utenti su di esso.
Attenersi alla procedura seguente:
  1. (Consigliato) Informare tutti gli analisti di Support Automation attivi sul server applicazioni che si desidera arrestare di creare un ticket in CA SDM con le informazioni sulla sessione. Questo processo assicura che le informazioni sulla sessione non vengano perse. Ad esempio, l'analista di Support Automation si trova in una sessione con un cliente per risolvere un problema di hardware. In tale caso, l'analista di Support Automation può creare una issue in CA SDM con le informazioni sulla sessione prima che il server applicazioni venga arrestato.
  2. Inviare una notifica (ad esempio, una notifica di posta elettronica) a tutti gli utenti attivi sul server applicazioni perché si spostino sul server applicazioni meno attivo che è stato appena riavviato. Questa notifica può includere i dettagli del server applicazioni aggiornato.
  3. Eseguire il comando seguente sul server applicazioni:
    pdm_server_control [-h] -q interval -s server_name
    • -h
      Visualizza la pagina della Guida.
    • -q interval -s server_name
      Notifica a un server applicazioni locale o remoto di rimanere inattivo in un intervallo di tempo specificato. Questo intervallo è il numero di secondi che trascorrono prima che il server diventi non in linea. Utilizzando questa opzione senza un server_name, il server locale riceve una notifica di disattivazione. Non è possibile utilizzare questa opzione per un server in background o di standby.
    Tutti gli utenti attivi sul server applicazioni visualizzano un messaggio popup che li informa dell'arresto del server e del tempo rimasto prima dell'arresto. Gli utenti devono salvare il proprio lavoro e uscire entro il tempo indicato. Il server applicazioni si arresta dopo il tempo specificato. Gli utenti accedono all'altro server applicazioni per riprendere il lavoro. L'analista di Support Automation può fare riferimento al ticket e riprendere il lavoro.
    L'arresto del server applicazioni è riuscito.
Verifica delle personalizzazioni sul client
Il file di controllo versioni viene verificato sul client per controllare se tutte le personalizzazioni sono state sincronizzate.
Attenersi alla seguente procedura:
  1. Accedere al client seguente, a seconda della configurazione di CA SDM:
    • Convenzionale: server secondario
    • Disponibilità avanzata: server di standby e server applicazioni
  2. Aprire il file stdlog dalla posizione seguente:
    $NX_ROOT\log
  3. Controllare se tutte le personalizzazioni effettuate sul server siano applicate sul client.