Se il tuo nome utente non compare nella riga restituita, significa che non sei nel gruppo e devi aggiungerti al gruppo kvm:

Quindi effettua il logout e il login affinché la modifica abbia effetto.

Build dall'host

Se esegui la build direttamente dalla tua macchina, usando build.sh, dovrai installare debos:

Quindi usa lo script build.sh per generare un'immagine VM direttamente sulla tua macchina.

Build dall'interno di un container

Se preferisci eseguire la build dall'interno di un container, dovrai installare e configurare docker o podman sulla tua macchina. Quindi usa lo script build-in-container.sh per generare un'immagine.

build-in-container.sh è semplicemente un wrapper sopra build.sh. Rileva quale motore container conforme a OCI usare, si occupa di creare la container image se mancante e infine avvia il container per eseguire la build dall'interno.

docker richiede che l'utente venga aggiunto al gruppo Docker, come sopra con KVM, oppure l'uso dell'account root (ad es. $ sudo ./build-in-container.sh). podman è stato testato sia in modalità rootful (ad es. $ sudo ./build-in-container.sh) che rootless (ad es. $ ./build-in-container.sh).

Generazione di un'immagine

Usa build.sh o build-in-container.sh, a tua scelta. Da questo punto useremo build.sh per brevità.

Esempi

Il miglior punto di partenza, come sempre, è il messaggio di utilizzo:

Le opzioni predefinite generano un'immagine Kali rolling, con desktop predefinito e toolset predefinito per architettura AMD64.

Questa è un'immagine disco raw, cioè un'immagine binaria semplice del disco (che può essere avviata con QEMU).

Esempio:

Per generare un'immagine Kali Linux personalizzata per VMware. Significa che include gli Open VM Tools preinstallati e che l'immagine prodotta è pronta per essere importata "così com'è" in VMware.

Inoltre, la genereremo dalla ultima versione stabile di Kali e useremo GNOME come ambiente desktop, invece del solito Xfce predefinito:

Per generare un'immagine Kali Linux progettata per VirtualBox. Include le utility guest di VirtualBox preinstallate e l'immagine può essere importata "così com'è" in VirtualBox.

Inoltre, vogliamo un disco virtuale da 150 GB e installeremo la selezione di strumenti "everything":

Per generare un'immagine Kali leggera, senza ambiente desktop e senza toolset predefinito. Questa è un'immagine generica, include il supporto per la maggior parte dei motori VM disponibili. La esporteremo nel formato OVA, adatto sia a VMware che a VirtualBox.

Puoi installare pacchetti aggiuntivi con l'opzione -P. Puoi usare l'opzione più volte (ad es. -P pkg1 -P pkg2 ...), oppure fornire un valore separato da virgole/spazi (ad es. -P "pkg1,pkg2, pkg3 pkg4"), oppure un mix di entrambi. Installiamo anche il pacchetto metasploit-framework:

Quando si genera una serie di immagini, potrebbe essere più comodo (e più veloce) suddividere la build in due parti: prima si crea un rootfs, poi si generano le immagini riutilizzando questo rootfs come punto di partenza.

Nell'esempio seguente, abbiamo prima creato un rootfs kali-rolling e poi generato una serie di immagini Vagrant:

Per impostare keyboard settings, usa l'opzione -K. L'impostazione ha la forma <layouts>/<models>/<variants>/<options>. Ogni impostazione può essere omessa (in tal caso viene usato il valore predefinito) oppure può avere più valori separati da virgole. Nel caso più semplice, potresti voler cambiare solo la disposizione della tastiera, quindi imposteresti us per una disposizione US, de per una disposizione tedesca, e così via. Spiegazioni più lunghe ed esempi si trovano nella pagina di manuale keyboard(5). Per l'elenco dei valori supportati, puoi fare riferimento al file /usr/share/X11/xkb/rules/xorg.lst (fornito dal pacchetto xkb-data su Debian e sistemi simili). Questo file ha diverse sezioni (! layout, ! model, !variant e !option) che elencano i possibili valori per ciascuna impostazione. Puoi anche verificare cosa è configurato sul tuo sistema con cat /etc/default/keyboard. Esiste anche una scorciatoia -K same per replicare il sistema host (cioè ciò che è impostato nel file /etc/default/keyboard).

Per impostare locale, usa l'opzione -L. Scegli un valore nella prima colonna di /usr/share/i18n/SUPPORTED, oppure controlla cosa è configurato sul tuo sistema con grep -v ^# /etc/locale.gen, o semplicemente echo $LANG. Esiste anche una scorciatoia -L same per replicare il sistema host.

Per impostare timezone, usa l'opzione -Z. Guarda in /usr/share/zoneinfo e scegli una directory e una sottodirectory. In caso di dubbi, esegui tzselect per farti guidare, oppure osserva cosa è configurato sul tuo sistema con realpath /etc/localtime. Esiste anche una scorciatoia -Z same per replicare il sistema host.

Per impostare nome utente e password per l'utente non privilegiato, usa l'opzione -U. Il valore è una singola stringa e : viene usato per separare il nome utente dalla password.

Qui genereremo un'immagine Kali e la configureremo per imitare il sistema host: stessa locale, stesso fuso orario e stesso nome utente (con password password):

Varianti e formati

È possibile generare diverse varianti di immagine, a seconda del motore VM in cui vuoi eseguire l'immagine Kali. La VARIANT definisce principalmente quale pacchetto aggiuntivo viene installato nell'immagine per aggiungere il supporto a un particolare motore VM. Il FORMAT definisce invece il formato del disco virtuale e quali file di metadati aggiuntivi produrre.

Se non impostato, il formato (opzione -f) viene impostato automaticamente in base alla variante (opzione -v). Non tutte le combinazioni di variante e formato hanno senso, quindi la tabella seguente riassume le combinazioni più comuni.

Le immagini generic includono pacchetti di supporto alla virtualizzazione preinstallati per QEMU, VirtualBox e VMware, da qui il nome "generic". Le altre immagini, che hanno come target un motore VM specifico, includono solo il supporto per quel particolare motore di virtualizzazione.

Solo il formato ova definisce un contenitore: il risultato della build è un file .ova, che è semplicemente un archivio tar. Per gli altri formati, la build produce file separati. Possono essere raggruppati in un archivio 7z con l'opzione -z.

Esiste anche un tipo rootfs: non è un'immagine. È semplicemente un albero del filesystem root Kali Linux, senza kernel e bootloader, impacchettato in un archivio .tar.gz. Il caso d'uso principale è riutilizzarlo come input per generare un'immagine di un sistema operativo, e non è pensato per essere usato al di fuori del sistema di build.

Configurazione del proxy di cache

Quando si generano immagini di sistemi operativi, è utile avere un meccanismo di cache per evitare di scaricare tutti i pacchetti da Internet, ancora e ancora. A questo scopo, lo script di build tenta di rilevare i proxy di cache noti che potrebbero essere in esecuzione sull'host locale. Prima fa riferimento alla configurazione APT locale Acquire::http::Proxy. Se non è impostata, tenta quindi di rilevare apt-cacher-ng e squid-deb-proxy controllando se un servizio è in ascolto sulla loro porta predefinita. Questo meccanismo non funziona per approx (un noto proxy di cache APT), poiché viene avviato automaticamente on demand.

Per sovrascrivere questo rilevamento, puoi esportare tu stesso la variabile d'ambiente http_proxy. Tuttavia, ricorda che la build avviene all'interno di una macchina virtuale QEMU, quindi localhost nell'ambiente di build si riferisce alla VM, non all'host. Se vuoi raggiungere l'host dalla VM, probabilmente vorrai usare http://10.0.2.2.

Ad esempio, se vuoi usare un proxy in esecuzione sulla tua macchina sulla porta 9876, usa: export http_proxy=http://10.0.2.2:9876. Se vuoi assicurarti che non venga usato alcun proxy, usa: export http_proxy=.

Vedi anche https://github.com/go-debos/debos#environment-variables per maggiori dettagli.

In alternativa, puoi configurare un mirror locale.

Generare e riutilizzare un rootfs

È possibile suddividere la build in due passaggi. Puoi prima generare un rootfs con ./build.sh -v rootfs, e poi generare un'immagine basata su questo rootfs con ./build.sh -r ROOTFS_NAME.tar.gz. Ha senso, ad esempio, se prevedi di generare più tipi di immagine.

Risoluzione dei problemi della build

Memoria insufficiente

Quando l'area scratch si riempie (cioè il valore di --scratchsize è troppo basso), la build potrebbe fallire con questo tipo di messaggi di errore:

Soluzione: aumenta il valore di --scratchsize. Puoi passare argomenti a debos dopo il carattere speciale --; quindi, se ti servono ad esempio 50G, puoi eseguire ./build.sh [...] -- --scratchsize=50G.

Ottenere una shell nella VM quando la build fallisce

Quando si esegue il debug di errori di build, è comodo essere portati in una shell all'interno della VM in cui avviene la build. Questo è possibile fornendo l'opzione --debug-shell a debos: ./build.sh [...] -- --debug-shell.

Risoluzione dei problemi in fase di esecuzione

ovf non compatibile con VMware ESXI

Questo è un problema noto; fai riferimento a https://gitlab.com/kalilinux/build-scripts/kali-vm/-/work_items/25#note_1301070132 per una soluzione alternativa.