Uso dei file di configurazione

Classi dei file di configurazione

I file di configurazione usati da Ignite-UX durante la procedura di installazione raggruppano logicamente in classi le informazioni simili secondo sistema operativo e funzionalità. La Figura 10-1 mostra le classi dei file di configurazione e la loro posizione.

Figura 10-1 Uso e posizione dei file di configurazione

Ignite-UX elabora i file config nell’ordine mostrato oltre. La seguente descrizione di ogni classe illustra come i vari parametri d’installazione possono essere progressivamente sostituiti:

	NOTA: I file di configurazione sono spesso definiti file config per via dell’abbreviazione della parola configurazione nei nomi di file e directory. Ad esempio, il file di configurazione locale di un client è config.local.

È possibile creare i propri file di configurazione che specificano i vari parametri di installazione a cui si è interessati, quindi combinarli liberamente in altre varie configurazioni personalizzate con il file /var/opt/ignite/INDEX. Collocare questi file di configurazione personalizzati in una delle directory specifiche della release del sistema operativo HP-UX:

/var/opt/ignite/data/Rel_id_release/*

La sezione successiva descrive come combinare più file di configurazione (predefiniti o personalizzati) per definire una singola configurazione.

Unione di file di configurazione tramite le definizioni di INDEX

Il raggruppamento dei file di configurazione in configurazioni utili è ottenuta con /var/opt/ignite/INDEX. Questo file contiene un elenco di configurazioni in definizioni separate; ognuna comprendente uno o più file di configurazione che definiscono un’installazione. Ogni definizione di configurazione inizia con cfg ed il nome della configurazione.

È possibile visualizzare i nomi di queste configurazioni utilizzando il comando instl_adm. Quando si installa un nuovo client con interfaccia utente di Ignite-UX, sarà possibile visualizzare queste configurazioni facendo clic sul pulsante accanto a Configurations..., nella scheda Basic, come mostrato dalla Figura 10-2.

Figura 10-2 Finestra della scelta delle configurazioni

Un file /var/opt/ignite/INDEX tipico contiene definizioni simili al seguente estratto:

.
.
.
cfg "HP-UX B.11.23 Default" {
       description "Default B.11.23 release configuration."
        "/opt/ignite/data/Rel_B.11.11/config"
        "/opt/ignite/data/Rel_B.11.23/core_cfg"
        "/opt/ignite/data/Rel_B.11.23/hw_patches_cfg"
        "/var/opt/ignite/config.local"
} = TRUE
.
.
.
cfg "Sistema CAD-11.23" {
        description "Configurazione di un sistema CAD."
        "/opt/ignite/data/Rel_B.11.23/CAD_config"
        "/opt/ignite/data/Rel_B.11.23/CAD_core_cfg"
        "/opt/ignite/data/Rel_B.11.23/hw_patches_cfg"
        "/opt/ignite/data/Rel_B.11.23/CAD_sw_sels_cfg"
        "/var/opt/ignite/config.local"
}
.
.
.

Con questo file /var/opt/ignite/INDEX, l’interfaccia utente Ignite-UX presenterebbe due configurazioni: HP-UX B.11.23 Default e Sistema CAD-11.23. La configurazione HP-UX B.11.23 Default è quella predefinita perché la definizione cfg è impostata come TRUE. Dopo avere scelto la configurazione, sarà possibile personalizzarla ulteriormente con l’interfaccia utente, oppure accettare quella predefinita ed iniziare immediatamente l’installazione.

L'ordine dei file di configurazione all'interno di una definizione cfg è significativo; gli attributi specificati nei file di configurazione successivi possono avere la priorità su quelli specificati nei file precedenti. Ogni volta, saranno usati implicitamente due file di configurazione:

Come parte di Ignite-UX, è fornita una definizione cfg per ogni release. Altre definizioni cfg saranno aggiunte quando:

Inoltre, è possibile specificare come Ignite-UX deve gestire il software d'installazione con i seguenti tre costrutti:

Per degli esempi di utilizzo dei costrutti precedenti, vedere le definizioni contenute in Definizione di un depot d’installazione. Per ulteriori informazioni, vedere instl_adm(1M).

Assicurarsi di passare al seguente comando tutti i file di configurazione generati dall’utente, per controllare eventuali errori sintassi:

instl_adm -T -f file_cfg

Esempi di file di configurazione

Questa sezione mostra alcuni esempi di file di configurazione per dare un’idea del loro aspetto e caratteristiche. Per la descrizione completa dei file di configurazione di Ignite-UX, consultare instl_adm(4).

Per ulteriori esempi di file di configurazione, consultare il documento Ignite-UX Custom Configuration Files, disponibile presso la pagina "Information Library" del sito Web del prodotto Ignite-UX:

http://www.docs.hp.com/en/IUX/infolib.html

Definizione dei dischi

Questo esempio mostra come è possibile definire un disco. In questo caso, il disco si trova all’indirizzo hardware 2/0/1.6.0 e non utilizza Logical Volume Manager (LVM) o Veritas Volume Manager di Symantec (VxVM). Il disco contiene il filesystem di root (/) e l’area di scambio. L’area di scambio occupa fino a 512 MB ed il filesystem di root il rimanente:

partitioned_disk
{
    physical_volume disk[2/0/1.6.0]
    fs_partition {
        usage = HFS
        size = remaining
        mount_point = "/"
    }
    swap_partition {
        usage = SWAP
        mount_point = "primary"
        size = 512
    }
}

Unione di dischi per formare un singolo gruppo di volumi

È possibile unire due dischi per formare un singolo gruppo di volumi. Sono definiti due filesystem; saranno ripartiti in entrambi i dischi. L’esempio seguente illustra questo concetto:

volume_group "appsvol" {
    usage=LVM
    physical_volume disk[2/0/1.5.0] {
    }    

    physical_volume disk[2/0/1.4.0] {
    }
    logical_volume "apps1" {
        mount_point = "/apps1"
        usage = VxFS
        size=30% free
        minfree = 5
        stripes = 2
    }
    logical_volume "apps2" {
        mount_point = "/apps2"
        usage = VxFS
        size = remaining
        minfree = 5
        stripes = 2
    }
}

L’esempio precedente utilizza LVM come gestore di volumi. Tuttavia, sarà anche applicabile a VxVM modificando usage=LVM in usage=VxVM

Il primo filesystem, /apps1, è dimensionato calcolando lo spazio necessario per il software da installare, ed aggiungendo quindi un 30% di spazio libero. Il secondo filesystem, /apps2, occupa lo spazio rimanente nel disco.

	NOTA: Quando si installa l’immagine di ripristino, in essa è possibile modificare le dimensioni dei volumi del filesystem. Per impostazione predefinita, Ignite-UX garantisce che in ogni volume ci sia il 10% di spazio libero, modificando di conseguenza la dimensione del volume del filesystem. Se non si desidera che Ignite-UX modifichi automaticamente le dimensioni del volume del filesystem, aggiungere init _hp_ignore_sw_impact=1 al file /var/opt/ignite/recovery/latest/system_cfg, oppure a quello /var/opt/ignite/clients/nome_client/recovery/latest/system_cfg.

Definizione dei parametri di rete

Le righe dell’esempio seguente definiscono alcuni dei parametri di rete assegnati al sistema dopo l’installazione:

final system_name = "acorn1"
final ip_addr["lan0"] = "10.99.45.123"
final netmask["lan0"] = "255.255.255.0"
final nis_domain = "nis1"
final route_gateway[0] = "10.99.45.1"

Definizione di un depot d’installazione

L’esempio seguente definisce un singolo depot di SD dal quale sarà possibile installare il software. Nel depot di SD sono definiti due diversi software. Ognuno potrà essere selezionato indipendentemente per l’installazione. Le righe impacts indicano ad Ignite-UX lo spazio necessario a questo software in una data directory. Questa informazione è utilizzata per dimensionare correttamente il filesystem. Il costrutto sw_category consente di raggruppare il software in modo che l’interfaccia utente sia in grado di presentarlo in gruppi che abbiano senso per l’utente. Dato che questo esempio fa riferimento ad un depot di SD, potrebbe essere stato creato con make_config:

sw_source "ee_apps_depot" {   
   description = "Electrical Engineering Application Depot"
   source_format = SD
   source_type = "NET"
   sd_server = "10.23.45.6"
   sd_depot_dir = "/var/opt/ignite/depots/Rel_B.11.11/ee_apps"
}
sw_category "Applications" {
   description = "User Applications"
}
sw_sel "EE CAD Package" {
   sw_source = "ee_apps_depot"
   sw_category = "Applications"
   sd_software_list = "EECad,r=1.2,a=HP-UX_B.11.11"
   impacts = "/var" 90524Kb
   impacts = "/sbin" 1248Kb
}
sw_sel "EE Routing Package" {
   sw_source = "ee_apps_depot"
   sw_category = "Applications"
   sd_software_list = "EERoute,r=2.4,a=HP-UX_B.11.11"
   impacts = "/usr" 12568Kb
   impacts = "/var" 26788Kb
}

Personalizzazioni in base all’hardware del client

La sintassi del file di configurazione offre un gran numero di parole chiave per gli attributi di sistema per la descrizione del client. Alcuni esempi sono:

Usando le espressioni logiche offerte da instl_adm(4), è possibile utilizzare le parole chiave degli attributi di sistema per formulare espressioni nei file di configurazione, in modo che una data definizione sia adottata in alcune situazioni specifiche del client. Il formato basilare di queste definizioni è:

(x){y}

che si può tradurre approssimativamente in: “se l’espressione x è vera, allora esegui y”.

Ad esempio, questa definizione imposta la dimensione di due parametri sintonizzabili del kernel se il client ha più di 4096 MB di memoria:

(memory > 4096MB) {
    mod_kernel += "nproc (20+100*MAXUSERS)"
mod_kernel += "maxuprc 1000"
}

Come altro esempio, nel caso si desideri eseguire uno script per compiere alcune personalizzazione di carattere grafico, ma solamente se il client dispone dell’hardware corretto, usare:

(graphics[0].planes > 0) {
    post_config_script += 
        "/var/opt/ignite/scripts/multi_plane_graphics"
}

È inoltre possibile specificare condizioni multiple. L’esempio seguente installa una data parte di un software applicativo definito in precedenza se il client è un server o una workstation supportata, PA-RISC o su base Itanium, con almeno due dischi. Un messaggio avvisa di ciò che sta accadendo:

( (HARDWARE_MODEL ~ "9000/7.*" | MODEL ~ "ia64 .* workstation .*") & (num_disks >= 2) ) { 
    note += "Installed application software contained in apps1."
    init sw_sel "apps1" = TRUE

È necessario usare sia HARDWARE_MODEL sia MODEL per via del differente funzionamento dei comandi uname e model nei sistemi su base Itanium. Ad esempio, in un client su base Itanium, per reperire questa informazione è possibile utilizzare i seguenti comandi:

uname -m

# ia64

model

# ia64 hp workstation zx2000

La risposta del comando uname è troncata, non è possibile perciò stabilire se il client è un server o una workstation, mentre in un client PA-RISC, il medesimo comando restituisce:

uname -m

# 9000/785

model

# 9000/785/J6000

Inoltre, è possibile aggiungere la definizione else, in modo da poter eseguire automaticamente una scelta. L’esempio seguente utilizza una variabile generica ed espressioni matematiche per impostare la dimensione primaria dello scambio, in base alla quantità di memoria del client:

(memory > 512Mb) {
    init _hp_pri_swap = 512Mb 
} 
else {
    init _hp_pri_swap = memory * 2 
}

Gli esempi precedenti rappresentano alcuni dei numerosi modi di utilizzo delle parole chiave degli attributi di sistema nella configurazione dei client e non devono essere considerati un elenco esaustivo.

Personalizzazioni in base alla selezione utente

Uno dei modi per sfruttare Ignite-UX a proprio vantaggio è di creare una configurazione personalizzata indipendente dalla configurazione hardware del client, che può essere selezionata ripetutamente per l’utilizzo. Ad esempio, si potrebbe avere dei client che si prevede di utilizzare come server di file NFS e si vorrebbe installare rapidamente questi client, selezionando nell’interfaccia utente la medesima configurazione.

Si supponga che alcuni server i file NFS siano più efficienti modificando due parametri del kernel. I server di file NFS richiedono inoltre alcune modifiche al file /etc/rc.config.d/nfsconf, utilizzando il comando ch_rc.

Una alternativa all’esecuzione manuale di queste modifiche è specificare una selezione software personalizzata in /var/opt/ignite/config.local con una definizione sw_sel, che, quando si configurerà la nuova installazione del client, nella scheda Software diventerà quindi una selezione. Ad esempio, la seguente definizione configurerebbe automaticamente i server di file NFS:

sw_source "special configs" {
    source_format = cmd 
}    
sw_sel "NFS Server" {
    sw_category = "Machine Uses"
    sw_source = "special configs"
    mod_kernel += "dbc_min_pct 35" 
    mod_kernel += "dbc_max_pct 65" 
post_config_cmd += "
        /usr/sbin/ch_rc -a -p NFS_SERVER=1
        /usr/sbin/ch_rc -a -p NFS_CLIENT=1 
        /usr/sbin/ch_rc -a -p NUM_NFSD=8" 
}

La Figura 10-3 mostra la scheda Software dove è utilizzata la configurazione del server NFS. Come mostrato, la categoria selezionata è Machine Uses, così com'è stata definita nel file di configurazione dell'esempio precedente, con la definizione sw_category. Questa selezione provocherà durante l’installazione l’applicazione delle modifiche al kernel e del comando ch_rc, oltre alle altre categorie software selezionate.

Figura 10-3 Scheda Software

L’uso delle schede per la configurazione dell’installazione del client è spiegato nel Capitolo 8: “Avvio ed installazione di HP-UX nei client usando il server”.