Struttura…

Introduzione

Per rappresentare un modulo installabile del sistema Zender è necessario riuscire a progettare una entità in grado di rappresentare in maniera autonoma le operazioni necessarie per installazione, configurazione e disinstallazione.

I pacchetti ZPKG hanno lo scopo di fondere in un archivio compresso questa informazioni con i file propri del modulo.

E’ davvero necessario?

Definire una standard per il pacchetto è necessario in quanto i moduli di configurazione e installazione devono essere realizzati tenendo presente un set generico di pacchetti non definiti, ma conformi a questo standard.

Altrettanto necessario è l’uso di pacchetti con uno standard definito perché non è possibile altrimenti distinguere in un semplice archivio compresso, quali dati rappresentano le informazioni per la configurazione e quali invece sono le componenti del modulo

Struttura pacchetto

Lo scopo del pacchetto è quello di distinguere le informazioni di installazione e configurazione dai file del modulo. Per questo viene introdotta una prima suddivisione della struttura in due porzioni:

Root/
  |--- metadata/
  |--- module/

Questa prima suddivisione è inoltre necessaria per la gestione di moduli di grosse dimensioni. Potrebbe infatti essere conveniente realizzare una prima scansione del file e leggere solo il contenuto della directory dei metadati.

Metadati

La directory dei metadati contiene le informazioni relative alle procedure necessarie per installazione, aggiornamento e disinstallazione.

Ogni operazione eseguibile con il pacchetto deve prevedere la presenza di almeno uno script per eseguirla. Il contenuto della cartella metadata quindi è indicativo delle operazioni eseguibili con il pacchetto. Inoltre per ogni operazione può essere presente uno script di pre-execution e uno di post-execution. Sono anche presenti file contenenti il changelog della versione corrente, il numero di versione e la licenza di utilizzo, ma la loro presenza è del tutto opzionale. La struttura della directory metadata di base è la seguente

Root/
  |--- metadata/
          |--- pre-install.php
          |--- install.php
          |--- post-install.php
          |--- pre-update.php
          |--- update.php
          |--- post-update.php
          |--- uninstall.php
          |--- VERSION
          |--- CHANGELOG
          |--- LICENSE

Script

Tutti gli script devono essere eseguiti in un contesto asettico. Le uniche informazioni reperibili allo script devono essere solo accessibili tramite un registro non alterabile.

Gli script della fase di installazione sono:

• pre-install.php -> eseguito prima della fase di estrazione del pacchetto. Serve per il controllo delle dipendenze e per il controllo dell’integrità dei pacchetti
• install.php -> eseguito dopo la fare di estrazione, a condizione che pre-install.php abbia concluso positivamente l’esecuzione. Serve per copiare componenti in posizioni specifiche non calcolabili precedentemente (in caso di personalizzazione dei percorsi o simili), per eseguire modifiche alla struttura o ai dati sul database, configurare il sistema per il nuovo modulo o per eseguire operazioni di manipolazione dei file
• post-install.php -> eseguito dopo la fare di installazione per controllare l’esito reale dell’operazione e per eseguire eventuali ripristini o recuperi o per eseguire la cancellazione dei file temporanei. Inoltre in caso di installazione riuscita, viene inserito lo script di disinstallazione nella cartella apposita del sistema. Questa fase viene avviata anche se pre-install.php fallisce.

Fase di aggiornamento:

• pre-update.php -> esegue i controlli prima dell’aggiornamento, controllando le dipendenze e selezionando le modalità corrette di aggiornamento in baso alla versione installata
• update.php -> eseguita solo se la fase di pre-update ha avuto esito positivo. Esegue le operazioni di aggiornamento e configurazione di sistema, altera la struttura o i dati del database e esegue manipolazioni su file
• post-update.php -> eseguito dopo la fase di aggiornamento per controllarne l’esito e per eseguire recuperi o ripristini o per eseguire la cancellazione dei file temporanei. Inoltre in caso di aggiornamento riuscito, viene inserito lo script di disinstallazione nella cartella apposita del sistema. Questa fase viene eseguita anche se pre-update ha avuto esito negativo.

Fase di disinstallazione:

• uninstall.php -> lo script permette la completa disinstallazione del modulo e il ripristino della situazione precedente all’installazione. Questo comprende l’eliminazione delle modifiche apportate ai file e al database e la cancellazione delle configurazioni aggiunte dal modulo. Il file viene salvato in una specifica posizione del server in seguito ad una corretta installazione

Altri file: gli altri file o cartelle contenute in metadata verranno ignorati e potranno essere utilizzati da eventuali varianti del modulo di installazione base o per fornire informazioni aggiuntive o dagli script stessi per eseguire compiti specifici. Non viene imposta alcuna limitazione su questo.

Cartella MODULE

I file in questa cartella costituiscono il corpo del modulo e sono organizzati in modo da rispecchiare la struttura directory standard di un sistema Zender. I file verranno copiati nelle posizioni corrispondenti a come disposti all’interno della cartella module tenendo presente una corrispondenza della cartella con la root dir del sistema Zender (Non quella del webspace).

Eventuali file non direttamente copiabili, in quanto la directory di destinazione non è nota al momento della pacchettizzazione, verranno inseriti in una cartella temporanea propria del pacchetto in modo da evitare collisioni.

La directory temporanea verrà eliminata al termine delle operazioni sul pacchetto e la cancellazione verrà eseguita dallo script di post-execution

Assumendo che la disposizione standard delle cartelle di un sistema Zender sia la seguente

Root/
   |--- applications/
   |         |--- default/
   |                   |--- controllers/
   |                   |--- views/
   |                   |--- models/
   |--- configs/
   |         |--- dbs/
   |         |--- includes/
   |         |--- ini/
   |--- tmp/
   |         |--- unistall/
   |--- lib/
   |      |--- Zend/
   |      |--- Zender/
   |--- public/
   |         |--- javascripts/
   |         |--- styles/
   |         |--- images/
   |--- .htaccess
   |--- index.php

una possibile struttura di un modulo Generico inserito in un ZPKG potrebbe essere la seguente

Generico_0.5.zpkg/
   |--- metadata/
   |         |--- pre-install.php
   |         |--- install.php
   |         |--- post-install.php
   |         |--- update/
   |         |          |--- 0_1-to-0.5.php
   |         |          |--- 0_2-to-0.5.php
   |         |          |--- 0_3-to-0.5.php
   |         |          |--- 0_4-to-0.5.php
   |         |--- pre-update.php
   |         |--- update.php
   |         |--- post-update.php
   |         |--- uninstall.php
   |         |--- VERSION
   |         |--- CHANGELOG
   |         |--- LICENSE
   |--- module/
             |--- applications/
             |         |--- generico/
             |                   |--- controllers/
             |                   |            |--- defaultController.php
             |                   |            |--- genericoController.php
             |                   |--- views/
             |                   |            |--- main.tpl
             |                   |--- models/
             |                                |--- domainClass.php
             |--- tmp/
             |         |--- generico/
             |                    |--- file_non_copiabile.php
             |                    |--- file_non_copiabile_2.php
             |--- public/
                       |--- javascripts/
                       |          |--- clientLogic.js
                       |--- styles/
                                  |--- main.css
                                  |--- accessible.css

Pro di questa soluzione

Ovviamente è lampante quanto questa soluzione sia comoda per la distribuzione dei moduli, al pari dei package JAR per Java.

Inoltre la possibilità di tenere sotto controllo le modalità di installazione, upgrade e disinstallazione evitano anche molti problemi per gli utenti alle prime armi, ben più abituati a lavorare installando .exe in ambiente windows, piuttosto che a cercare linee di codice in listati php per eseguire operazioni di integrazione o eseguire script SQL nei pannelli di gestione di MySql e simili.

Ultima, ma non per questo meno importante, la possibilità di distribuire i pacchetti tramite server repository affidabili, al pari di come realizzato dal sistema APT di Debian o da soluzioni simili

Contro di questa soluzione

Ovviamente tutto questo ha anche i suoi svantaggi. Iniziando dalla impossibilità reale di poter realizzare un contesto completamente sterile per l’esecuzione, per poi proseguire verso l’impossibilità di gestire i comportamenti interni degli script.

Per ovviare a questi problemi potrebbe essere presa in considerazione la possibilità di scrivere gli script di installazione in un sottoinsieme del linguaggio PHP interpretato dal modulo di installazione in modo da limitare l’utilizzo di istruzioni potenzialmente pericolose (unlink ad esempio) o in modo da poter filtrare parametri non corretti (ad esempio una richiesta di scrittura in una area non concessa).

Un altro problema figlio di questa soluzione è la gestione delle dipendenze. Integrando un sistema di dipendenze la complessità di implementazione del modulo di installazione aumenta e le performance delle operazioni aggiunta e rimozione dei moduli si riduce.