Questo capitolo descrive le funzioni opzionali disponibili per creare altri tool di installazione basati sul metodo JumpStart personalizzato.
Le istruzioni di questo capitolo si riferiscono ai server SPARC o x86 usati come server di profili, cioè usati per fornire i file personalizzati richiesti dal programma JumpStart. Un server di profili può contenere i file richiesti da JumpStart per diversi tipi di piattaforma. Ad esempio, un server SPARC può contenere i file JumpStart personalizzati richiesti sia per la piattaforma SPARC che per la piattaforma x86.
Uno script iniziale è uno script per la Bourne shell definito dall'utente che viene specificato nel file rules. Lo script iniziale viene creato per eseguire una serie di operazioni prima dell'installazione di Solaris sul sistema. Gli script iniziali possono essere usati solo con il metodo di installazione JumpStart personalizzato.
Uno script iniziale può essere usato per eseguire le seguenti operazioni:
Creare profili derivati
Eseguire un backup dei file prima di un aggiornamento
Durante un'installazione iniziale o un aggiornamento, evitare di specificare nello script istruzioni che impediscano l'attivazione dei file system su /a. Se il programma JumpStart non può attivare i file system su /a, si verifica un errore e l'installazione non riesce.
Durante l'installazione, l'output dello script iniziale viene memorizzato in /tmp/begin.log. Al termine dell'installazione, il file di log viene rediretto in /var/sadm/system/logs/begin.log.
Verificare che il proprietario dello script iniziale sia root e che le autorizzazioni siano impostate su 644.
Negli script iniziali è possibile usare le variabili d'ambiente accettate dal metodo JumpStart personalizzato. Per un elenco delle variabili d'ambiente disponibili, vedere Variabili d'ambiente per l'installazione JumpStart personalizzata.
Salvare gli script iniziali nella directory JumpStart.
In Solaris 10, sul supporto era presente uno script di JumpStart, set_nfs4_domain, per evitare la richiesta durante l'installazione. Usando questo script il nome di dominio NFSv4 non veniva richiesto durante l'installazione. Questo script non è più necessario. A partire da Solaris 10 8/07, usare la parola chiave nfs4_domain di sysidcfg per impedire che il nome di dominio venga richiesto durante l'installazione. Lo script set_nfs4_domain non è più supportato.
Se sono presenti zone non globali e nel file sysidcfg è inclusa la nuova parola chiave nfs4_domain, il dominio viene impostato al primo avvio di una zona non globale. Diversamente, viene avviato il programma di installazione interattivo di Solaris e viene richiesto di indicare il nome del dominio prima di completare il processo di avvio.
Vedere Parola chiave nfs4_domain in Guida all’installazione di Solaris 10 5/08: installazioni di rete
Si dice derivato un profilo che viene creato dinamicamente da uno script iniziale durante un'installazione JumpStart personalizzata. I profili derivati sono utili quando non è possibile configurare il file rules in modo da abbinare sistemi specifici a un profilo. Ad esempio, può essere necessario usare profili derivati per sistemi dello stesso modello che contengano componenti hardware differenti, ad esempio frame buffer diversi.
Per creare una regola che preveda l'uso di un profilo derivato, procedere come segue:
Inserire nel campo del profilo un segno di uguale (=) al posto del nome di un profilo.
Nel campo dello script iniziale, inserire il nome di uno script che crei un profilo derivato in base al sistema su cui si desidera installare Solaris.
Quando un sistema soddisfa la regola con il campo del profilo impostato sul segno di uguale (=), lo script iniziale crea il profilo derivato che verrà usato per l'installazione di Solaris.
L'esempio seguente mostra uno script iniziale che crea ogni volta lo stesso profilo derivato. È possibile, tuttavia, creare uno script iniziale che crei profili derivati differenti in base alla valutazione delle regole.
#!/bin/sh echo "install_type initial_install" > ${SI_PROFILE} echo "system_type standalone" >> ${SI_PROFILE} echo "partitioning default" >> ${SI_PROFILE} echo "cluster SUNWCprog" >> ${SI_PROFILE} echo "package SUNWman delete" >> ${SI_PROFILE} echo "package SUNWolman delete" >> ${SI_PROFILE} echo "package SUNWxwman delete" >> ${SI_PROFILE} |
In questo esempio, lo script iniziale deve usare la variabile d'ambiente SI_PROFILE per il nome del profilo derivato, che nell'impostazione predefinita è /tmp/install.input.
Se si utilizza uno script iniziale per creare un profilo derivato, verificare che lo script non contenga errori. I profili derivati non vengono verificati dallo script check perché vengono creati solo dopo l'esecuzione dello script iniziale.
Uno script finale è uno script per la Bourne shell definito dall'utente che viene specificato nel file rules. Le operazioni specificate nello script finale vengono eseguite dopo l'installazione di Solaris ma prima del riavvio del sistema. Gli script finali possono essere usati solo con il metodo di installazione JumpStart personalizzato.
Le operazioni che è possibile eseguire con uno script sono le seguenti:
Aggiungere file
Aggiungere singoli pacchetti o patch oltre a quelli installati da un determinato gruppo software
Personalizzare l'ambiente di root
Impostare la password di root per il sistema
Installare prodotti software aggiuntivi
Il programma di installazione di Solaris attiva i file system del sistema su /a. I file system rimangono attivati su /a fino al reboot successivo. Lo script può essere usato per aggiungere, modificare o rimuovere uno o più file dalla gerarchia di file system della nuova installazione modificando i file system relativi ad /a.
Durante l'installazione, l'output dello script finale viene memorizzato in /tmp/finish.log. Al termine dell'installazione, il file di log viene rediretto in /var/sadm/system/logs/finish.log.
Verificare che il proprietario dello script finale sia root e che le autorizzazioni siano impostate su 644.
Negli script finali è possibile usare le variabili d'ambiente accettate dal metodo JumpStart personalizzato. Per un elenco delle variabili d'ambiente disponibili, vedere Variabili d'ambiente per l'installazione JumpStart personalizzata.
Salvare gli script finali nella directory JumpStart.
Mediante uno script finale, è possibile aggiungere uno o più file della directory JumpStart a un sistema già installato. Questa operazione è possibile perché la directory JumpStart è attivata sulla directory specificata dalla variabile SI_CONFIG_DIR. Nell'impostazione predefinita, questa directory è /tmp/install_config.
È anche possibile sostituire i file già presenti sul sistema installato con i file della directory JumpStart.
Copiare tutti i file da aggiungere al sistema installato nella directory JumpStart.
Nello script finale, inserire la riga seguente per ogni file che si desidera copiare nella gerarchia di file system del sistema installato:
cp ${SI_CONFIG_DIR}/nome_file /a/percorso |
Ad esempio, si ipotizzi di avere sviluppato un'applicazione speciale di nome prog_sito per tutti gli utenti del sito. Collocando una copia di prog_sito nella directory JumpStart e la riga seguente nello script finale, il file prog_sito verrà copiato dalla directory JumpStart nella directory /usr/bin dei sistemi installati:
cp ${SI_CONFIG_DIR}/prog_sito /a/usr/bin |
Uno script finale può essere usato per aggiungere automaticamente pacchetti o patch al sistema dopo l'installazione di Solaris. Usando uno script finale, si riducono i tempi delle procedure e si ha la certezza di installare gli stessi pacchetti e le stesse patch su tutti i sistemi del sito.
Quando si utilizzano i comandi pkgadd(1M) o patchadd(1M) in uno script finale, è consigliabile usare l'opzione -R per specificare /a come percorso radice.
L'Esempio 4–3 mostra uno script finale che aggiunge una serie di pacchetti.
L'Esempio 4–4 mostra uno script finale che aggiunge una serie di patch.
#!/bin/sh BASE=/a MNT=/a/mnt ADMIN_FILE=/a/tmp/admin mkdir ${MNT} mount -f nfs sherlock:/export/package ${MNT} cat >${ADMIN_FILE} <<DONT_ASK mail=root instance=overwrite partial=nocheck runlevel=nocheck idepend=nocheck rdepend=nocheck space=ask setuid=nocheck conflict=nocheck action=nocheck basedir=default DONT_ASK /usr/sbin/pkgadd -a ${ADMIN_FILE} -d ${MNT} -R ${BASE} SUNWxyz umount ${MNT} rmdir ${MNT} |
A seguire sono descritti alcuni comandi dell'esempio.
Il comando seguente attiva una directory sul server contenente il pacchetto da installare.
mount -f nfs sherlock:/export/package ${MNT} |
Il comando seguente crea un file temporaneo per l'amministrazione dei pacchetti, di nome admin, per forzare il comando pkgadd(1M) a non eseguire controlli e a non formulare domande durante l'installazione dei pacchetti. Il file di amministrazione temporaneo permette di automatizzare la procedura di installazione dei pacchetti.
cat >${ADMIN_FILE} <<DONT_ASK |
Il seguente comando pkgadd aggiunge il pacchetto utilizzando l'opzione -a, che specifica il file di amministrazione dei pacchetti e l'opzione -R, che specifica il percorso di root.
/usr/sbin/pkgadd -a ${ADMIN_FILE} -d ${MNT} -R ${BASE} SUNWxyz |
#!/bin/sh ######## # # USER-CONFIGURABLE OPTIONS # ######## # La posizione delle patch da aggiungere al sistema dopo l'installazione. # La versione (5.x) e l'architettura (`mach`) saranno aggiunte alla radice. Ad esempio, /foo su un sistema SPARC 8 diventa /foo/5.8/sparc LUPATCHHOST=ins3525-svr LUPATCHPATHROOT=/export/solaris/patchdb ######### # # NESSUNA PARTE SU CUI È POSSIBILE ESEGUIRE # LA MANUTENZIONE OLTRE QUESTO PUNTO # ######### BASEDIR=/a # Determina le versioni del SO di origine e destinazione echo Determining OS revisions... SRCREV=`uname -r` echo Source $SRCREV LUPATCHPATH=$LUPATCHPATHROOT/$SRCREV/`mach` # # Aggiunge le patch necessarie # echo Adding OS patches mount $LUPATCHHOST:$LUPATCHPATH /mnt >/dev/null 2>&1 if [ $? = 0 ] ; then for patch in `cat /mnt/*Recommended/patch_order` ; do (cd /mnt/*Recommended/$patch ; echo yes | patchadd -u -d -R $BASEDIR .) done cd /tmp umount /mnt else echo "No patches found" if |
In passato, nell'ambiente degli script finali, insieme ai comandi pkgadd e patchadd veniva usato il comando chroot(1M). In rari casi, alcuni pacchetti o patch non funzionano con l'opzione -R. In questi casi è necessario creare un file /etc/mnttab fittizio nel percorso radice /a prima di eseguire il comando chroot.
Per creare un file /etc/mnttab fittizio, aggiungere la riga seguente allo script finale:
cp /etc/mnttab /a/etc/mnttab
Gli script finali possono anche essere usati per personalizzare i file già installati su un sistema. Ad esempio, lo script finale illustrato nell'Esempio 4–5 personalizza l'ambiente radice aggiungendo una serie di informazioni al file .cshrc della directory radice (/).
#!/bin/sh # # Personalizza l'ambiente radice # echo "***aggiunta delle personalizzazioni in /.cshrc" test -f a/.cshrc || { cat >> a/.cshrc <<EOF set history=100 savehist=200 filec ignoreeof prompt="\$user@`uname -n`> " alias cp cp -i alias mv mv -i alias rm rm -i alias ls ls -FC alias h history alias c clear unset autologout EOF } |
Al termine del processo di installazione di Solaris, il sistema si riavvia. Prima che il processo di boot sia completato, il sistema richiede la password di root. La procedura di boot non prosegue finché la password non viene inserita.
Nella directory auto_install_sample viene salvato uno script finale di nome set_root_pw. Questo script mostra come impostare la password di root automaticamente, senza che il sistema la richieda. Lo script set_root_pw è riportato nell'Esempio 4–6.
Se si imposta la password di root del sistema con uno script finale, c'è il rischio che gli utenti cerchino di scoprirla accedendo alla password cifrata inclusa nello script finale. Occorre perciò adottare le misure di sicurezza appropriate per proteggere lo script.
#!/bin/sh # # @(#)set_root_pw 1.4 93/12/23 SMI # # Esempio di script della shell Bourne da eseguire dopo l'installazione. # Imposta la password di root sul valore definito in PASSWD. # La password cifrata è derivata da una password di root esistente # in /etc/shadow su un sistema installato. echo "impostazione della password per root" # imposta la password di root PASSWD=dKO5IBkSF42lw # crea un file di input temporaneo cp /a/etc/shadow /a/etc/shadow.orig mv /a/etc/shadow /a/etc/shadow.orig nawk -F: '{ if ( $1 == "root" ) printf"%s:%s:%s:%s:%s:%s:%s:%s:%s\n",$1,passwd,$3,$4,$5,$6,$7,$8,$9 else printf"%s:%s:%s:%s:%s:%s:%s:%s:%s\n",$1,$2,$3,$4,$5,$6,$7,$8,$9 }' passwd="$PASSWD" /a/etc/shadow.orig > /a/etc/shadow # rimuove il file temporaneo rm -f /a/etc/shadow.orig # imposta il flag, sysidroot non richiederà la password di root sed -e 's/0 # root/1 # root/' ${SI_SYS_STATE} > /tmp/state.$$ mv /tmp/state.$$ ${SI_SYS_STATE} |
A seguire sono descritti alcuni comandi dell'esempio.
Il comando seguente imposta la variabile PASSWD su una password di root cifrata ricavata da una voce esistente nel file /etc/shadow del sistema.
# crea un file di input temporaneo |
Il comando seguente crea un file di input temporaneo di /a/etc/shadow.
cp /a/etc/shadow /a/etc/shadow.orig |
Il comando seguente cambia la password di root nel file /etc/shadow per il sistema installato usando $PASSWD come campo per la password.
if ( $1 == "root" ) |
Il comando seguente rimuove il file di input temporaneo di /a/etc/shadow.
rm -f /a/etc/shadow.orig |
Il comando seguente cambia l'istruzione da 0 a 1 nel file di stato, in modo che la password di root non venga richiesta all'utente. L'accesso al file di stato avviene tramite la variabile SI_SYS_STATE, il cui valore corrente è /a/etc/.sysIDtool.state. Per evitare problemi con lo script in caso di cambiamento di questo valore, fare sempre riferimento a questo file usando $SI_SYS_STATE. Il comando sed di questo esempio contiene un carattere di tabulazione dopo lo 0 e dopo l'1.
sed -e 's/0 # root/1 # root/' ${SI_SYS_STATE} > /tmp/state.$$ |
Gli script finali permettono di installare prodotti software aggiuntivi dopo l'installazione del sistema operativo Solaris. Il programma di installazione di Solaris richiede l'immissione di alcune informazioni durante l'installazione. Per automatizzare questa procedura, è possibile eseguire il programma di installazione di Solaris con le opzioni -nodisplay o -noconsole.
Tabella 4–1 Opzioni di installazione di Solaris
Opzione |
Descrizione |
---|---|
-nodisplay |
Esegue il programma di installazione senza l'interfaccia grafica utente. L'installazione viene eseguita nel modo predefinito, salvo le modifiche eventualmente apportate con l'opzione -locales. |
-noconsole |
Esegue il programma di installazione senza una console interattiva. Questa opzione è utile, insieme a -nodisplay, per l'uso degli script UNIX. |
Per maggiori informazioni, vedere la pagina man installer(1M).
Anziché usare il comando add_install_client per specificare la posizione dei file di configurazione JumpStart personalizzati, tale posizione può essere specificata durante l'avvio del sistema. Tuttavia, è possibile specificare solo un singolo nome di file. Per questa ragione, occorre comprimere i file di configurazione JumpStart personalizzati in un singolo file.
Per i sistemi SPARC, la posizione deve essere specificata nel comando boot
Per i sistemi x86, è possibile specificare la posizione dei file modificando la voce appropriata del menu di GRUB.
Il file di configurazione compresso può essere dei seguenti tipi:
tar
tar compresso
zip
bzip tar
Spostarsi nella directory JumpStart sul server dei profili.
# cd directory_JS |
Usare un programma di compressione per racchiudere i file di configurazione JumpStart in un singolo file.
Il file di configurazione compresso non può contenere percorsi relativi. I file di configurazione JumpStart devono trovarsi nella stessa directory del file compresso.
Il file di configurazione compresso deve contenere i seguenti file:
Profilo
rules
rules.ok
Il file di configurazione compresso può anche contenere il file sysidcfg.
Salvare il file di configurazione compresso su un server NFS, su un server HTTP o su un disco rigido locale.
L'esempio seguente mostra come usare il comando tar per creare un file di configurazione compresso di nome config.tar. I file di configurazione JumpStart personalizzati si trovano nella directory /jumpstart.
# cd /jumpstart # tar -cvf config.tar * a profile 1K a rules 1K a rules.ok 1K a sysidcfg 1K |
Questa sezione spiega come creare i file di configurazione per uno o più dischi. Questi file di configurazione permettono di usare pfinstall(1M) su un singolo sistema per provare più profili con diverse configurazioni dei dischi.
Individuare un sistema SPARC di cui si desidera provare un disco.
Diventare superutente o assumere un ruolo equivalente.
I ruoli comportano determinate autorizzazioni e consentono di eseguire comandi che richiedono privilegi. Per maggiori informazioni sui ruoli, vedere Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Creare un file di configurazione reindirizzando l'output del comando prtvtoc(1M) su un file.
# prtvtoc /dev/rdsk/nome_dispositivo >file_config_dischi |
Nome di dispositivo del disco del sistema. Il nome_dispositivo deve avere la forma cwtxdys2 o cxdys2.
Nome del file di configurazione dei dischi
Determinare se occorre provare l'installazione di Solaris su più dischi.
In caso negativo, la procedura è terminata. Non occorre eseguire altre operazioni.
In caso affermativo, concatenare i file di configurazione dei singoli dischi e salvare l'output in un nuovo file.
# catfile_disco1 file_disco2 >file_multi_disco |
Il nuovo file racchiude la configurazione di più dischi, come nell'esempio seguente:
# cat 104_disco2 104_disco3 104_disco5>prova_multi_disco |
Determinare se i numeri di target nei nomi di dispositivo dei dischi siano unici all'interno del file di configurazione multidisco creato al punto precedente.
In caso affermativo, la procedura è terminata. Non occorre eseguire altre operazioni.
In caso negativo, aprire il file con un editor di testo e differenziare i numeri di target nei nomi di dispositivo dei dischi.
Ad esempio, se nel file viene usato lo stesso numero di target t0 per più dischi, come nel caso seguente:
* /dev/rdsk/c0t0d0s2 partition map ... * /dev/rdsk/c0t0d0s2 partition map |
Cambiare il secondo numero di target in t2, come indicato qui sotto:
* /dev/rdsk/c0t0d0s2 partition map ... * /dev/rdsk/c0t2d0s2 partition map |
L'esempio seguente mostra come creare un file di configurazione per un singolo disco, 104_prova, su un sistema SPARC con un disco da 104 Mbyte.
L'output del comando prtvtoc viene rediretto a un file di configurazione di un singolo disco di nome 104_prova:
# prtvtoc /dev/rdsk/c0t3d0s2 >104_prova |
Il contenuto del file 104_prova si presenta come segue:
* /dev/rdsk/c0t3d0s2 partition map * * Dimensions: * 512 bytes/sector * 72 sectors/track * 14 tracks/cylinder * 1008 sectors/cylinder * 2038 cylinders* 2036 accessible cylinders * Flags: * 1: unmountable * 10: read-only * * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 1 2 00 0 164304 164303 / 2 5 00 0 2052288 2052287 3 0 00 164304 823536 987839 /disk2/b298 5 0 00 987840 614880 1602719 /install/298/sparc/work 7 0 00 1602720 449568 2052287 /space |
Sono stati creati i file di configurazione dei dischi per un sistema SPARC. Per informazioni sull'uso di questi file di configurazione per la prova dei profili, vedere Prova di un profilo.
Individuare un sistema x86 di cui si desidera provare un disco.
Diventare superutente o assumere un ruolo equivalente.
I ruoli comportano determinate autorizzazioni e consentono di eseguire comandi che richiedono privilegi. Per maggiori informazioni sui ruoli, vedere Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Creare una parte del file di configurazione del disco salvando l'output del comando fdisk(1M) in un file.
# fdisk -R -W file_config_dischi-h /dev/rdsk/nome_dispositivo |
Nome del file di configurazione dei dischi.
Nome di dispositivo del layout fdisk dell'intero disco. Il nome_dispositivo deve avere la forma cwtxdys0 o cxdys0.
Aggiungere l'output del comando prtvtoc(1M) al file di configurazione dei dischi:
# prtvtoc /dev/rdsk/nome_dispositivo >>file_config_dischi |
Nome di dispositivo del disco del sistema. Il nome_dispositivo deve avere la forma cwtxdys2 o cxdys2.
Nome del file di configurazione dei dischi
Determinare se occorre provare l'installazione di Solaris su più dischi.
In caso negativo, la procedura è terminata. Non occorre eseguire altre operazioni.
In caso affermativo, concatenare i file di configurazione dei singoli dischi e salvare l'output in un nuovo file.
# catfile_disco1 file_disco2 >file_multi_disco |
Il nuovo file racchiude la configurazione di più dischi, come nell'esempio seguente:
# cat 104_disco2 104_disco3 104_disco5>prova_multi_disco |
Determinare se i numeri di target nei nomi di dispositivo dei dischi siano unici all'interno del file di configurazione multidisco creato al punto precedente.
In caso affermativo, la procedura è terminata. Non occorre eseguire altre operazioni.
In caso negativo, aprire il file con un editor di testo e differenziare i numeri di target.
Ad esempio, il file può contenere lo stesso numero di target t0 per più dischi, come nel caso seguente:
* /dev/rdsk/c0t0d0s2 partition map ... * /dev/rdsk/c0t0d0s2 partition map |
Cambiare il secondo numero di target in t2, come indicato qui sotto:
* /dev/rdsk/c0t0d0s2 partition map ... * /dev/rdsk/c0t2d0s2 partition map |
L'esempio seguente mostra come creare un file di configurazione per un singolo disco, 500_prova, su un sistema x86 con un disco da 500 Mbyte.
Per prima cosa, salvare l'output del comando fdisk in un file di nome 500_prova:
# fdisk -R -W 500_prova -h /dev/rdsk/c0t0d0p0 |
Il file 500_prova si presenta come segue:
* /dev/rdsk/c0t0d0p0 default fdisk table * Dimensions: * 512 bytes/sector * 94 sectors/track * 15 tracks/cylinder * 1455 cylinders * * HBA Dimensions: * 512 bytes/sector * 94 sectors/track * 15 tracks/cylinder * 1455 cylinders * * systid: * 1: DOSOS12 * 2: PCIXOS * 4: DOSOS16 * 5: EXTDOS * 6: DOSBIG * 86: DOSDATA * 98: OTHEROS * 99: UNIXOS * 130: SUNIXOS * * Id Act Bhead Bsect Bcyl Ehead Esect Ecyl Rsect Numsect 130 128 44 3 0 46 30 1001 1410 2050140 |
Quindi, aggiungere l'output del comando prtvtoc al file 500_prova:
# prtvtoc /dev/rdsk/c0t0d0s2 >>500_prova |
Il file di configurazione dei dischi 500_prova è ora completo:
* /dev/rdsk/c0t0d0p0 default fdisk table * Dimensions: * 512 bytes/sector * 94 sectors/track * 15 tracks/cylinder * 1455 cylinders * * HBA Dimensions: * 512 bytes/sector * 94 sectors/track * 15 tracks/cylinder * 1455 cylinders * * systid: * 1: DOSOS12 * 2: PCIXOS * 4: DOSOS16 * 5: EXTDOS * 6: DOSBIG * 86: DOSDATA * 98: OTHEROS * 99: UNIXOS * 130: SUNIXOS * * Id Act Bhead Bsect Bcyl Ehead Esec Ecyl Rsect Numsect 130 128 44 3 0 46 30 1001 1410 2050140 * /dev/rdsk/c0t0d0s2 partition map * * Dimensions: * 512 bytes/sector * 94 sectors/track * 15 tracks/cylinder * 1110 sectors/cylinder * 1454 cylinders * 1452 accessible cylinders * * Flags: * 1: unmountable * 10: read-only * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 2 5 01 1410 2045910 2047319 7 6 00 4230 2043090 2047319 /space 8 1 01 0 1410 1409 9 9 01 1410 2820 422987 |
Sono stati creati i file di configurazione dei dischi per un sistema x86. Per informazioni sull'uso di questi file di configurazione per la prova dei profili, vedere Prova di un profilo.
Creando script iniziali e finali basati sulle specifiche caratteristiche di un sito, è possibile creare un programma di installazione personalizzato per l'installazione di Solaris.
Quando si specifica un segno meno (-) nel campo del profilo, le modalità di installazione di Solaris sul sistema vengono controllate dagli script iniziali e finali anziché dal profilo e dal programma di installazione di Solaris.
Ad esempio, in base alla regola seguente, Solaris viene installato sul sistema di nome pongo: dallo script iniziale install_x.inizio e dallo script finale install_x.fine.
hostname pongo install_x.inizio - install_x.fine |