| Entrambe le parti precedenti la revisioneRevisione precedenteProssima revisione | Revisione precedente |
| documentazione_3di_riservata:extraway_ee:index [2016/08/01 09:55] – [security.conf.xml] rtirabassi | documentazione_3di_riservata:extraway_ee:index [Data sconosciuta] (versione attuale) – eliminata - modifica esterna (Data sconosciuta) 127.0.0.1 |
|---|
| ====== eXtraWay Server Enterprise Edition ====== | |
| |
| ===== Getting Started ===== | |
| |
| Molteplici sono gli aspetti che differenziano il server eXtraWay nella sua Enterprise Edition rispetto alla precedente versione Legacy e Community. | |
| Di seguito, cercando di dare un po' d'ordine, le informazioni utili per una prima installazione. | |
| |
| * Installazione base eXtraWay Enterprise Edition. | |
| * Verificare le impostazioni del file xwee.ini e xwee.conf.xml | |
| * Insallare il Log Service come servizio. | |
| * Windows: xwls-0mq -install | |
| * Linux: da definire, va eseguito ./xwls-0mq & | |
| * Predisporre una cartella con copia di un archivio della version 25 del server eXtraWay Standard | |
| * Rimuovere il contenuto della cartella //<nomearchivio>.lazy// | |
| * Rimuovere il file //<nomearchivio>.profile.xml// | |
| * Aprire l'archivio con eXtraWay Enterprise Edition | |
| * A questo punto devono essere state create due nuove cartelle: //<nomearchivio>.refs// e //<nomearchivio>.title// | |
| * Rimuovere i file //<nomearchivio>.ref//, //<nomearchivio>.vcb//, //<nomearchivio>.tit// e //<nomearchivio>.tip// | |
| * Prendere visione del file //xw.log//. In esso si troveranno indicazioni inerenti le chiavi primarie e seriali non corrette. Nella fattispecie si avranno i seguenti messaggi | |
| * <color red>Primary key must be single: XML,//Identificativo della chiave//</color> | |
| * <color red>Invalid 'non single' serial key: XML,//Identificativo della chiave//</color> | |
| * Per tali campi si devono compiere interventi nel file //<nomearchivio>.conf.xml// al fine di porre il server eXtraWay Enterprise in condizione di operare nel migliore dei modi. | |
| * <color blue>Nota per DocWay: Gli interventi nei file xdocwaydoc.conf.xml e acl.conf.xml sono relativamente semplici ad eccezione del caso di ''/aoo/interoperabilita/@cod_aoo'' e ''@cod_amm'' per i quali si deve provvedere a rimuovere questi campi dal test di univocità, impostare le chiavi in modo che sia possibile effettuare una verifica per adiacenza o concatenazione ed effettuare tale test con un trigger autoritativo.</color> | |
| * Chiudere la connessione col server e riaprire l'archivio fino a quando non verranno più rilevati comportamenti non corretti nella configurazione. | |
| * **Reindicizzare l'archivio** | |
| * Rifare i Titoli. | |
| |
| ===== Setting up ===== | |
| |
| Per fare il setup di una postazione si deve. | |
| |
| * Scaricare da CVS xw.3rdp.core | |
| * . | |
| * . | |
| * . | |
| * . | |
| * Predisporre la cartella di installazione (c:\3di.it\extraway\xwee ovvero /opt/3di.it/extraway/xwee) | |
| * Creare in tale cartella altre cartelle quali: | |
| * bin | |
| * conf | |
| * db | |
| * lib | |
| * logs | |
| * script((Vedremo in seguito come viene popolata)) | |
| * tmp((in linux si è soliti collocare i temporanei qui, per Windows non è richiesta in quanto solitamente si utilizza la directory di sistema)) <sub>(Linux Only)</sub>. | |
| * wd | |
| * Configurare il server collocando nella cartella ''conf'' i file richiesti.\\ Essi sono: | |
| * ''<color red>xwee.ini</color>''((Anche vuoto ma presente, conterrà l'elenco degli archivi disponibili e le impostazioni di registrazione del server)) | |
| * ''<color red>xwee.conf.xml</color>'', la configurazione principale di eXtraWay Server Enterprise Edition. | |
| * ''<color magenta>xwwd.conf.xml</color>'', file di configurazione del processo di //Watch Doc// per mezzo del quale vengono compiute operazioni batch sugli archivi. Esse sono principalmente riferite ad importazioni di record, ma non solo e/o non necessariamente. Potremmo definirlo facoltativo, ma di fatto è una necessità. | |
| * ''<color magenta>log.conf.xml</color>'', configurazione di tutte le funzionalità di Logging del server.\\ Esiste un capitolo apposito che tratta di quest'argomento. Potremmo definirlo facoltativo, ma di fatto è una necessità. | |
| * ''jobs.conf.xml'', configurazione di batch jobs da eseguire a scadenze temporali ben precise. Facoltativo. | |
| |
| Oltre a questi file di configurazione trovano collocazione in questa cartella file con estensione ''.stp'', in particolare il file ''italian.stp'' che rappresenta la //stop list// di default per le ricerche nei campi testuali. | |
| ===== Variabili Ambientali ===== | |
| Il Server e gli altri moduli della Piattaforma percepiscono e reagiscono all'esistenza di alcune variabili ambientali. | |
| |
| ^ Variabile ^ Comportamento ^ | |
| ^ LD_LIBRARY_PATH | Utilizzata in Linux per dichiarare l'ordine di esecuzione e di ricerca delle librerie dinamiche da caricare.\\ Viene riportata in quest'elenco solo per completezza in quanto la sua popolazione corretta viene effettuata tramite le impostazioni del file ''xweectl.conf''. | | |
| ^ TEMP\\ TMP\\ TMPDIR | Directory dei file temporanei. Di fatto non è previsto che almeno TMP/TEMP non siano presenti. | | |
| ^ XW_IPC_PLG_DIR | Indica la cartella ove generare i file necessari al processi di //Process Life Guard//. Il processo consente di verificare se un altro processo sia attualmente in vita o meno.\\ La funzionalità è legata alle verifiche che si effettuano su diverse risorse per sapere se una //prenotazione// si una di esse sia stata effettuata da un processo non più esistente e quindi se la prenotazione può essere scartata.\\ Nella cartella indicata viene creata una ulteriore cartella ''xw_ipc_plg'' che contiene una coppia di file (main.lck e pids.lck).\\ \\ In assenza di questa dichiarazione i sistemi sfruttano, rispettivamente:\\ Windows: <//SystemDrive//>:\ProgramData\3di.it \\ Linux:/var/log3di.it | | |
| |
| ===== I file di configurazione ===== | |
| Come per le altre versioni del Server eXtraWay i file di configurazione dei moduli binari si trovano nella cartella ''conf'' parallela a quella degli eseguibili. | |
| |
| ==== xwee.ini & xwee.conf.xml ==== | |
| |
| Questi due file prendono le mosse da altri file esistenti nell'ambito standard. Si è cercato di fare "pulizia" delle voci di configurazione, unificare quanto poteva essere unificato e così via. | |
| L'obiettivo, a tendere, è quello di avere un solo file di configurazione. Per il momento il file xwee.ini rimane per la sola dichiarazione della registrazione del server e per l'elenco degli archivi a sua disposizione mentre al file xwee.conf.xml spetta il compito di fornire tutte le impostazioni. Di seguito un esempio del file. | |
| |
| <code xml> | |
| <?xml version="1.0" encoding="utf-8"?> | |
| <xwee> | |
| <conf_manager> | |
| <refresh_interval_ms>500</refresh_interval_ms> | |
| <changed_event_dispatch_kind>deepasync</changed_event_dispatch_kind> | |
| </conf_manager> | |
| <plugins> | |
| <plugin clp="libxwlua.clp" required="true"/> | |
| <plugin clp="replicactx.clp" required="false"/> | |
| </plugins> | |
| <master fork_wait_time_sec="30"/> | |
| <temporary_files dir="c:\temp" share="c:\temp"> | |
| <booster slots="60000" slot_size="4096"/> | |
| <cleaner test_interval_min="10" | |
| file_max_age_min="60" | |
| file_min_age_min="5" | |
| file_min_free_space_ave="2"/> | |
| </temporary_files> | |
| <disk min_space_left = "20000000000"/> | |
| <indexing maximum_parallel_instances="4"> | |
| <memory limit_mb="800"/> | |
| </indexing> | |
| <xreg allow_collision="true" allow_undeclared_ip="true"/> | |
| <debug benchmark="true"/> | |
| <scripting> | |
| <change check_time_sec="600"/> | |
| </scriptingxwee> | |
| </code> | |
| |
| Nel dettaglio abbiamo: | |
| ^ XPath ^ Valore ^ Default ^ | |
| |/xwee/conf_manager/|<color blue>Configurazione del //Configuration Manager//</color>|| | |
| |/xwee/conf_manager/refresh_interval_ms|Il sistema di configurazione introdotto con il Server Enterprise Edition prevede un unico manager che provvede a fornire la configurazione a tutte le componenti della piattaforma.\\ La configurazione viene mantenuta in una //cache// e si provvede ad aggiornarla solo se si rileva un cambiamento in uno dei file di configurazione.\\ Quello indicato in questo parametro è il tempo, in millisecondi, che intercorre tra un test ed il successivo, test teso a verificare se la configurazione sia cambiata.|''600000'' ad indicare un tempo di 10'| | |
| |/xwee/conf_manager/changed_event_dispatch_kind|Oltre al fatto che i dati di configurazione vengono aggiornati quando si rileva un cambiamento, gli //utilizzatori// della configurazione possono dirsi "interessati" a conoscere che questo cambiamento ha avuto luogo, per provvedere, ad esempio, ad una nuova inizializzazione.\\ Quando avviene un cambiamento in un file di configurazione il //Configuration Manager// informa tutti gli //utilizzatori// con una sorta di evento ed ha alcune modalità per compiere quest'azione:\\ - ''sync'': ogni notifica viene inviata all'utilizzatore e si attende che lo stesso abbia completato le azioni che ritiene necessarie. In questo modo le operazioni sono sostanzialmente serializzate.\\ - ''async'': viene generato un //thread// che compie le notifiche. Entro tale //thread// le notifiche sono sincrone, ma l'intera operazione non causa attesa anche se lo svolgimento è serializzato.\\ - ''deepasync'': Viene creato un //thread// che effettuerà le notifiche e per ciascuna di esse viene creato un ulteriore //thread//. In questo modo le azioni di notifica sono effettivamente parallele.|''deepasync''| | |
| |/xwee/plugins/|<color blue>Configurazione del //Plug In//</color>|| | |
| |/xwee/plugins/plugin|Dichiara il plug-in da caricare.| | | |
| |/xwee/plugins/plugin/@clp|Nome del //Classes Package// da caricare.\\ Il file viene ricercato nella cartella ''plug-in'' presente nella cartella dei binari.| | | |
| |/xwee/plugins/plugin/@required|Indica se il plug-in sia obbligatorio o meno.\\ Se il valore è ''true'' ed il plug-in manca o il suo caricamento fallisce, l'avvio del server non si completa.|''true''| | |
| |/xwee/master/|<color blue>Configurazione del //Server Master//</color>|| | |
| |/xwee/master/@fork_wait_time|Durante il processo di duplicazione del //Server Master// per la generazione di un processo figlio accade che il processo si avvii ma la notifica non pervenga al Master che l'ha generato.\\ Negli scenari in cui questo accade si può impostare questo valore che indica il numero massimo di secondo per i quali attendere la notifica della corretta nascita del processo figlio.\\ Dopo tale attesa il processo figlio, che comunque non ha dato errore in fase di creazione, si considera "teoricamente" avviato.|''-1'', ad indicare che il Server Master attende ad oltranza la notifica della nascita del processo figlio.| | |
| |/xwee/temporary_files/|<color blue>Configurazione del File Temporanei</color>|| | |
| |/xwee/temporary_files/@dir|Directory dei file temporanei.|Se non indicata si ha un comportamento differente a seconda della piattaforma.\\ Su //Windows// si usa la cartella dei temporanei rilevata investigando le variabili ambientali TEMP, TMP e TMPDIR, un quest'ordine.\\ Su //Linux// si assume per definizione la cartella ''tmp'' parallela a quella dei file binari.\\ In ambo i casi, in tale cartella viene generata un'ulteriore cartella denominata ''hwtemp'' e tutti i temporanei di eXtraWay vengono creati in essa.| | |
| |/xwee/temporary_files/@share|Directory dei file condivisi.\\ Diversi processi, primo tra tutti l'esportazione dei dati, si avvalgfono di un file collocato nella cartella dei file temporanei. In seguito, con modalità differenti, si procede all'acquisizione di tale file.\\ Indicando questo valore si dichiara una speciale cartella in cui troveranno collocazione questi file e la cartella potrà essere condivisa in altre maniere con i client così da semplificare l'accesso a tali contenuti, specie se di dimensioni importanti|Se non indicata tale cartella è la stessa dei temporanei.| | |
| |/xwee/temporary_files/booster|<color blue>Configurazione Avanata del File Temporanei</color>|| | |
| |/xwee/temporary_files/booster/@slots|Numero massimo di file di selezione contemporaneamente disponibili a tutto il parco utenti.|''60000''.| | |
| |/xwee/temporary_files/booster/@slot_size|Dimensione entro la quale una selezione viene mantenuta in memoria condivisa e non viene riversata su file per rendere più veloce il suo utilizzo.\\ Il server impegnerà un'area di memoria condivisa((Memory Mapped File)) pari al prodotto di questa dimensione ed il numero di slot di cui al parametro precedente.|''4096''.| | |
| |/xwee/temporary_files/cleaner|<color blue>Configurazione della Rimozione del File Temporanei</color>|| | |
| |/xwee/temporary_files/cleaner/@test_interval_min|Numero di minuti che intercorre tra un test ed il successivo.|''5''.| | |
| |/xwee/temporary_files/cleaner/@file_max_age_min|Età massima in minuti di ciascun file di selezione.\\ Se un file di selezione risulta più vecchio di tale tempo è candidato alla rimozione((La rimozione non avviene immediatamente per dare il tempo al server di confermare che un certo file di selezione è ancora utile senza dover compiere quest'azione ad ogni accesso al file.)).|''1440'', pari a 12 ore.| | |
| |/xwee/temporary_files/cleaner/@file_min_age_min|Quando il numero di file presenti supera il numero massimo ammesso, si procede alla rimozione degli stessi a dispetto della loro effettiva età, in sostanza si procede a rimuovere man mano o più vetusti per garantire comunque una certa quantità di "slot" disponibili.\\ La cancellazione, comunque sia, viene impedita per selezioni più giovani del tempo qui indicato, in minuti.|''10''.| | |
| |/xwee/temporary_files/cleaner/@file_min_free_space_ave|Un'altra delle ragioni per rimuovere un maggior numero di file temporanei va ricercata nell'occupazione del disco candidato a conservare i file temporanei.\\ Poiché la saturazione di tale disco significherebbe l'interruzione del servizio, si indica una percentuale di disco da mantenere comunque libera.\\ Tale percentuale concorre alla riduzione dell'età delle selezioni da rimuovere tra ''file_max_age_min'' e ''file_min_age_min''.|''5''.| | |
| |/xwee/disk|<color blue>Configurazione dell'utilizzo dei Dischi</color>|| | |
| |/xwee/disk/@min_space_left|Al fine di evitare la saturazione dei dischi ove sono collocati gli archivi il server verifica di quando in quando che sul disco ove si sta operando ci sia ancora un margine di spazio libero e quando tale margine viene superato inizia a produrre una condizione d'errore per inibire i comandi.\\ In questo modo l'applicazione evidenzia un problema che però non ha impatti sulla salute dell'archivio e da modo ai sistemisti di intervenire per garantire spazio sufficiente.|''1073741824'', ovvero 1 GB.\\ La misura va espressa in bytes.| | |
| |/xwee/indexing|<color blue>Configurazione dell'Indicizzazione (Off-Line)</color>|| | |
| |/xwee/indexing maximum_parallel_instances|Numero massimo di cpu da utilizzare per l'indicizzazione off-line degli archivi.\\ Il valore dei dafault è 1. Se si imposta un valore positivo si utilizzeranno il 75%((calcolato per difetto)) delle CPU disponibili sino ad un massimo di quelle indicate. Con un valore negativo si indica di usare il 75% delle CUP disponibili senza alcun limite massimo.|| | |
| |/xwee/indexing/memory limit_mb|Soglia massima della memoria, in MB, utilizzata dal processo per l'indicizzazione off-line di un archivio.|''512'', ovvero 1/2 GB.| | |
| |/xwee/xreg|<color blue>Configurazione del Registro (Audit Log)</color>|| | |
| |/xwee/xreg/@allow_collision|Se impostato ad un valore //vero// indica che lo stesso utente è autorizzato ad agire contemporaneamente da IP Address differenti.|''false'' ad indicare che l'accesso concorrente è vietato.| | |
| |/xwee/xreg/@allow_undeclared_ip|Se impostato ad un valore //vero// indica che l'accesso dell'utente viene concesso anche se esso nasconde il proprio IP address di provenienza.|''false'' ad indicare che l'accesso offuscato è vietato.| | |
| |/xwee/debug|<color blue>Configurazione di Debug</color>|| | |
| |/xwee/debug/@benchmark|Se impostato ad un valore //vero// attiva la registrazione di //log// di per la valutazione delle prestazioni dei singoli comandi.|''false'' ad indicare che la stesura del log di benchmark è disabilitata.| | |
| |/xwee/scripting|<color blue>Configurazione degli Script((Attualmente solo LUA))</color>|| | |
| |/xwee/scripting/change|<color blue>Configurazione dei processi di verifica del cambiamento degli script</color>|| | |
| |/xwee/scripting/change/@check_time_sec|Lunghezza in secondi dell'intervallo tra un controllo e l'altro dell'attuale cambiamento degli script.|''-1'' ad indicare che il controllo è disabilitato. Il valore ''0'' causa il controllo ad ogni esecuzione dello script, altri valori ''> 0'' indicano il tempo di latenza in secondi tra un test ed il successivo.| | |
| |
| |
| Il file xwee.ini somiglia molto a quello della precedente versione ma vengono cambiate alcune denominazioni. | |
| |
| <code ini> | |
| [eXtraWay EE] | |
| SerialNo=02602611200 | |
| Config=69920-540021024 175775858-807014914 | |
| User=Roberto Tirabassi | |
| Company=3D Informatica | |
| |
| [Archives] | |
| test=c:\xwee\db\test\test.stat | |
| acl=C:\xwee\db\dcw\acl\acl.stat | |
| xdocwaydoc=C:\xwee\db\dcw\xdocwaydoc\xdocwaydoc.stat | |
| </code> | |
| |
| La sezione ''eXtraWay EE'' viene utilizzata per salvare i parametri della registrazione, grazie alla quale il server è abilitato ad utilizzare archivi di grandi dimensioni e/o comunque a fare operazioni modificanti.\\ La sezione ''Archives'' elenca gli accoppiamenti tra ''nome logico'' e ''nome fisico'' dell'archivio.\\ Si ricorda in proposito che un archivio il cui nome logico non appaia in quest'elenco viene cercato automaticamente dal server componendo il seguente percorso...\\ | |
| \\ | |
| <directory di installazione>/db/<nome logico>/<nome logico>.stat\\ | |
| \\ | |
| ...dove la directory di installazione è quella in cui si trovano tutte le directory principali (bin, conf, logs, wd etc. etc.) | |
| |
| ==== jobs.conf.xml ==== | |
| ** La configurazione delle operazioni ripetibili ** | |
| |
| La configurazione delle operazioni ripetibili si effettua per mezzo del file ''jobs.conf.xml'' collocato nella cartella ''conf'' ove si trovano tutti i file di configurazione.\\ | |
| Di seguito un esempio del suo contenuto.\\ | |
| |
| <code xml> | |
| <?xml version="1.0" encoding="iso-8859-1"?> | |
| <!-- DOCTYPE xwwd_cfg SYSTEM "http://www.3di.it/extraway/jobs_20131015.dtd" --> | |
| <jobs_cfg> | |
| <!-- Jobs that are done once, on the server Master start --> | |
| <job arc="sestra" when="once" val="" label="The job that is done at start"> | |
| <cmd stored=".stored.doAgent"> | |
| <parm1>UNO</parm1> | |
| </cmd> | |
| </job> | |
| <!-- Jobs that are done every day at a specific time | |
| The 'val' value is "HHMM:xxxxxxx" or "HHMM:*" or "HHMM" | |
| Where HH is the hour of the day, MM is the minute in that hour | |
| The following part, if present, maps the day of the week where 0 is sunday, 1 is monday | |
| and so on up to 6 that is saturday. | |
| A value '1' means "in that day", while any other value menas "jump that day". | |
| Wild card '*' means every day of the week and not declared days are "on". | |
| Sample: Every day "1111111", "*", "111" (the last 4 days ar on since obmitted) | |
| Sample: "1000001" means during weekend, "0111110" means, during working week | |
| Sample: "0000011" and "00000" both means on friday and saturday | |
| The hour can be. | |
| Skipped, means midnight | |
| 1 single digit: at that hour, between 0 and 9, minutes 00. | |
| 2 digits: at that hour, between 0 and 23 | |
| 4 or more digits: at the hour (first 2 digits) and minutes (last 2 digits) | |
| Behaviour on 3 digit form is undefinded | |
| So "1:*" is everyday of the week ad 1am | |
| --> | |
| <job arc="niterfront" when="at" val="1200:*" label="every day at 12:00"> | |
| <cmd stored=".stored.doTimeJob"> | |
| <parm1>UNO</parm1> | |
| </cmd> | |
| </job> | |
| <!-- Jobs that are done repeatedly each time unit | |
| The 'val' value is a number that "can be" followed by a letter. | |
| For no letter or letter [m|M] the units are minutes. | |
| For letter [h|H] the units are hours | |
| For letter [d|D] the units are days | |
| For letter [w|W] the units are weeks | |
| --> | |
| <job arc="niterfront" when="every" val="10m" label="each 10 minutes"> | |
| <cmd stored=".stored.doCycleJob"> | |
| <parm1>UNO</parm1> | |
| </cmd> | |
| </job> | |
| </jobs_cfg> | |
| |
| </code> | |
| |
| Seppure l'esempio è autoesplicativo, elenchiamo i casi e la loro configurazione. | |
| |
| ^ Tipologia Azione ^ Descrizione ^^ | |
| ^ **once** | | Azione che viene svolta //una tanum// all'avvio del processo master.\\ Solitamente questa formula si sceglie per avviare processi che sono dei veri e propri ''agent'' che devono attendere il verificarsi di condizioni particolari per poi attivarsi e svolgere un qualche compito.| | |
| ^ ** at** | | Azioni da svolgersi ripetitivamente ad una certa ora del giorno in uno o più dei giorni della settimana.\\ Si presta per attività di controllo, verifica, attività propedeutiche ad esempio al backup o ancora per azioni quali ma rimozione di documenti obsoleti, il trasferimento ad altro //storage// di allegati non utilizzati e così via.| | |
| ^ | Parametro temporale | L'azione ''at'' si avvale di un parametro temporale (attributo ''val'') che indica quando l'azione debba aver luogo.\\ Esso si compone di una dichiarazione di ore e minuti, in 4 //digit//, seguita eventualmente dal carattere ':' e da una sequenza di valori (0 o 1) che indica in quale giorno della settimana, a partire da domenica, l'azione debba essere compiuta.\\ E' ammesso indicare l'ora con 1, 2 o 4 //digit//: nei primi due casi si assume l'ora pura e semplice assegnando '00' al valore dei minuti.\\ Per i giorni della settimana si può indicare un asterisco per comprenderli tutti, altrimenti uno o più valori (max 7) tra 0 e 1. Il primo giorno indicato è domenica e così via. I giorni non indicati si considerano attivi per definizione. | | |
| ^ **every** | | Azioni da svolgersi ripetitivamente ad intervalli regolari e non ad un orario specifico.\\ In questo modo si può svolgere, ad esempio ogni ora, una qualche attività di verifica o altro.| | |
| ^ | Parametro temporale | L'azione ''every'' si avvale di un parametro temporale (attributo ''val'') che indica quanto tempo intercorra tra un'esecuzione e la successiva.\\ Esso si compone di un valore numerico eventualmente seguito da un carattere atto ad indicare la natura dell'unità numerica.\\ Omettendo la lettera, ovvero indicando ''m'' o ''M'', il numero indica dei minuti.\\ L'uso di ''h'' o ''H'' indica ore, l'uso ''d'' o ''D'' indica giorni e l'uso di ''w'' o ''W'' indica settimane.\\ Non sono previsti intervalli più ampi. | | |
| |
| |
| Ogni attività viene correlata ad un archivio, eventualmente fittizio o non utilizzato dal procedimento e finalizzato esclusivamente a dare l'avvio all'attività. Può inoltre disporre di una ''label'' che verrà usata nei //logs// per dare evidenza dell'avvio delle operazioni richieste e pianificate.\\ | |
| |
| All'interno della configurazione dell'azione, poi, la richiesta da svolgere.\\ Attualmente è possibile evocare un //Plug-In// o una //Stored Procedure// con i parametri desiderati, in futuro si potranno svolgere anche altre tipologie di azioni. | |
| |
| ==== security.conf.xml ==== | |
| ** La configurazione delle autenticazioni ed autorizzazioni ** | |
| |
| L'autenticazione e quindi la facoltà di accedere al sistema eXtraWay sono processi normalmente regolati sul fronte applicativo. Nel tempo applicativa è stato anche l'amministrazione dei diritti di cui l'utente gode, ma queste due condizioni possono altresì essere regolate direttamente dal server.\\ | |
| Per quanto concerne l'autenticazione, si può far ricorso ad un apposito //provider// la cui configurazione è attualmente molto elemenare. | |
| |
| <code xml> | |
| <?xml version="1.0"?> | |
| <config> | |
| <auth_provider class="xw::secty::authProviderDummy"/> | |
| </config> | |
| </code> | |
| |
| In sostanza, il file di configurazione inerente l'autenticazione si limita ad indicare quale classe vada caricata da apposito plug-in del server per regolare tali accessi. In condizioni standard, l'accesso è sempre garantito a qualsiasi utente.\\ | |
| In seguito entra in gioco il processo di autorizzazione, vale a dire l'accoppiamento a ciascun utente di una batteria di diritti fruibili per ciascuna risorsa. Il concetto di risorsa è volutamente ampio e si estende potenzialmente un po' a qualsiasi aspetto della piattaforma eXtraWay. In prima istanza diremo che la principale tipologia di risorsa è l'archivio (o Data Base). | |
| |
| Ciascuna risorsa è responsabile delle impostazioni della propria autorizzazione, per le risorse archivio ecco un esempio di configurazione. | |
| |
| <code xml> | |
| <!-- DOCTYPE xway_cfg SYSTEM "http://www.3di.it/extraway/xway_20070219.dtd" --> | |
| <xway_cfg cfg_ver="001.000.001"> | |
| ... | |
| <acl_provider class="xw::secty::aclProviderLcps" url="http://www.foo.bar:8080/services/User"/> | |
| ... | |
| </xway_cfg> | |
| |
| In questo esempio il file di configurazione di un archivio è corredato dalle impostazioni necessarie per identificare un ''acl_provider'' che indica la casse del plug-in da utilizzare. La configurazione è poi corredata ad impostazioni proprie che variano da //provider// a //provider//. | |
| |
| In assenza di un specifico ACL provider, alla risorsa vengono garantiti i diritti standard. | |
| |
| ==== storage.conf.xml ==== | |
| ** La configurazione delle risorse di storage ** | |
| |
| Queste risorse sono utilizzate in primo luogo per effettuare cache di informazioni utili e condivise tra le diverse istanze di server eXtraWay EE.\\ Come gli altri, anche questo file si colloca nella cartella ''conf''.\\ | |
| Di seguito un esempio del suo contenuto.\\ | |
| |
| <code xml> | |
| <?xml version="1.0" encoding="iso-8859-1"?> | |
| <config> | |
| <caches> <!-- Configurazione di tutte le cache --> | |
| <cache id="usersData" persistor_class="xw::strg::persistor_lmdb" expiry_secs="1800" persistor_init="C:/ProgramData/3di.it/usersData"/> | |
| </caches> | |
| </config> | |
| </code> | |
| |
| Vediamo quali sono le principali voci di configurazione. | |
| |
| ^ XPath ^ Descrizione ^ | |
| | /config/caches/cache/@id | Identificativo univoco della cache.\\ Può esistere uno ed un solo elemento con un siffatto ''id''.\\ Ad esclusione di cache applicative per le quali c'è libertà espressiva, ci sono alcuni ''id'' riservati.\\ - ''userData'': cache dei dati utente, in particolare diritti ed affini. | | |
| | /config/caches/cache/@persistor_class | Classe da caricare da uno dei ''plug-in'' del server eXtraWay per assolvere al compito assegnato, ovvero fare ''storage'' dei dati conservati.| | |
| | /config/caches/cache/@persistor_init | Una stringa contenente informazioni di inizializzazione del //persistor// prescelto. IL suo contenuto è libero e dipende dal //persistor// anche se nell'esempio si indica esplicitamente una cartella.| | |
| | /config/caches/cache/@expiry_secs | Numero di secondi di vita utile di ciascun dato raccolto nella //cache//. In assenza di una specifica dichiarazione la cache dura 24 ore. | | |
| |
| A seconda del persistor sono inoltre possibili altri parametri di configurazione che dipendono direttamente da lui e verranno indicati separatamenteo.\\ | |
| |
| ==== replica.conf.xml ==== | |
| |
| Il Server Enterprise può essere configurato per replicare un archivio su una o più destinazioni. Questo può prestarsi a diversi scopi, dal //Disaster Recovery// alla pubblicazione di una porzione di archivio da un //Back Office// ad un //Front Office// e cose simili, dipendentemente dalle modalità con le quali viene effettuata la replica.\\ | |
| |
| === Condizioni per effettuare la replica === | |
| In quali condizioni il Server eXtraWay Enterprise decide di replicare un archivio?\\ L'operazione non viene effettuata su tutti gli archivi ma solo su quelli per i quali viene impostata una particolare configurazione: | |
| <code xml> | |
| ... | |
| <profile type="arc.replica" value="on"/> | |
| ... | |
| </code> | |
| |
| Una volta poste le basi perché la replica venga compiuta, essa in cosa consiste?\\ | |
| Quando un archivio è opportunamente configurato, il server tiene traccia di tutte le operazioni considerate "modificanti", quindi inserimenti, modifiche, cancellazioni ed applicazione di nuovi allegati. Ciascuna di tali operazioni contribuisce alla creazione di una sequenza di comandi che viene conservata perché possa essere consumata da un apposito servizio che, sulla base del file di configurazione di seguito descritto, decide verso quali destinazioni replicare i contenuti ed in che modo farlo. | |
| |
| === Il servizio di Replica - xweereplica === | |
| |
| Il servizio((Servizio in Windows, demone in Linux)) di replica utilizza il file di configurazione xweereplica.conf.xml, collocato come tutti gli altri file di configurazione nella cartella ''conf''. | |
| |
| <code xml> | |
| <?xml version="1.0"?> | |
| <config> | |
| <sinks> | |
| <!-- Spreaders Sinks --> | |
| <sink name="dcwsud-Sink" class="xw::replica::xwSink" destination="xw://hwadmin@10.17.61.65:5859/xequisud"/> | |
| <sink name="xdocwaydoc-Sink" class="xw::replica::xwSink" destination="xw://hwadmin@10.17.61.65:5859/dcwcopy"/> | |
| <sink name="acl-Sink" class="xw::replica::sinkDummy"/> | |
| <sink name="test-Sink" class="xw::replica::xwSink" destination="xw://hwadmin@10.17.61.65:5859/test"/> | |
| </sinks> | |
| |
| |
| <spreaders> | |
| <!-- Replica Spreaders --> | |
| <spreader name="xdocwaydoc"> | |
| <source name="c:\xwee\db\dcw\xdocwaydoc\xdocwaydoc"/> | |
| <sink name="xdocwaydoc-Sink"/> | |
| </spreader> | |
| <spreader name="dcwsud"> | |
| <source name="C:\xwee\db\dcw-equi\xdocwaydoc-equisud\xdocwaydoc"/> | |
| <sink name="dcwsud-Sink"/> | |
| </spreader> | |
| <spreader name="acl" > | |
| <source name="c:\xwee\db\dcw\acl\acl.stat"/> | |
| <sink name="acl-Sink"/> | |
| </spreader> | |
| <spreader name="test" > | |
| <source name="c:\xwee\db\test\test.stat"/> | |
| <sink name="test-Sink"/> | |
| </spreader> | |
| | |
| </spreaders> | |
| | |
| <replicas> | |
| <!-- | |
| <spreader name="xdocwaydoc"/> | |
| <spreader name="acl"/> | |
| --> | |
| <spreader name="test"/> | |
| <spreader name="dcwsud"/> | |
| </replicas> | |
| </config> | |
| </code> | |
| |
| Nel dettaglio abbiamo: | |
| ^ XPath ^ Valore ^ Default ^ | |
| |/config/replicas/|<color blue>Configurazione delle Repliche da effettuare.</color>|| | |
| |/config/replicas/spreader/@name|Con questa voce si dichiara un'ID per una delle repliche da compere, in sostanza un archivio che si desidera tenere d'occhio ed al quale applicare i processi di replica|Non esiste alcun valore di default.\\ Se un archivio non è opportunamente dichiarato non si compirà alcuna replica.| | |
| |/xwee/spreaders/|<color blue>Configurazione dei processi di Propagazione</color>|| | |
| |/xwee/spreaders/spreader|Dichiara il singolo Propagatore.| | | |
| |/xwee/spreaders/spreader/@name|Nome del Propagatore. Deve corrispondere a quello dichiarato nella sezione delle repliche di cui al paragrafo precedente.| | | |
| |/xwee/spreaders/spreader/source/@name|Nome completo dell'archivio che si intende propagare. E' la fonte dati e ne va dichiarata solo una| | | |
| |/xwee/spreaders/spreader/sink/@name|''ID'' della destinazione.\\ Per ciascuna fonte originaria (source) si possono indicare più destinazioni.| | | |
| |/xwee/sinks/|<color blue>Configurazione delle Destinazioni</color>|| | |
| |/xwee/sinks/sink/@name|''ID'' della destinazione| | | |
| |/xwee/sinks/sink/@class|Nome della classe che va caricata da un ''plug-in'' per effettuare la replica verso la destinazione desiderata.\\ Ciascuna classe applicherà le proprie logiche e stabilirà le modalità per mezzo delle quali effettuare la replica.| | | |
| |/xwee/sinks/sink/@destinatio|La vera URL che dichiara la destinazione.\\ La modalità con la quale si compone questa URL viene descritta in seguito.| | | |
| |
| === La composizione della URL === | |
| Il processo di replica distribuisce su una o più destinazioni le operazioni modificanti. Per identificare una destinazione si fa uso di una URL avente la seguente composizione: | |
| |
| <color red>**protocol**</color>**:%%//%%**[<color green>user</color>[:<color green>pwd</color>@]]<color red>**host**</color>[:<color green>port</color>]**/<color blue>extra data</color>** | |
| |
| * <color red>**Componenti obbligatorie**</color> | |
| * **protocol**: Protocollo di comunicazione. Di fatto identifica la tipologia di strumento con il quale dialogare.\\ Ne sono stati previsti diversi e l'elenco può crescere.\\ Attualmente sono implementati solo quelli verso altri server eXtraWay: | |
| * **xwee**: Comunicazione verso un altro Server eXtraWay Enterprise | |
| * **xw**((La distinzione tra Enterprise e Standard è stata concepita pensando che in sede di implementazione o in realizzazioni future possa essere opportuno agire in modi differenti nei due casi e/o che alcune operazioni possano non essere applicate ai server più datati. Attualmente l'implementazione è unica e la distinzione solo teorica.)): Comunicazione verso un Server eXtraWay Standard | |
| * <color grey>mysql, sqlite, oracle: valori previsti ma attualmente non implementati</color> | |
| * **host**: Dal punto di vista squisitamente teorico anche questo valore potrebbe essere omesso sottintendendo lo stesso host ove è collocato il servizio di replica, ma renderebbe incompleta la URL. | |
| * <color blue>**Componenti normalmente presenti**</color> | |
| * **extra data**: Informazioni supplementari sfruttate dal Propagatore applicato ad un determinato protocollo per potersi connettere alla destinazione richiesta. | |
| * <color green>Componenti facoltative</color> | |
| * port: Porta socket cui connettere il protocollo indicato qualora non fosse equivalente allo standard. | |
| * user: Utente con il quale effettuare la connessione qualora necessario o differente dal default. | |
| * pwd: Password((Attualmente questo dato viene conservato in chiaro)) utilizzata dall'utente di cui al punto precedente qualora necessaria per effettuare il collegamento. | |
| |
| |
| === Politica di distribuzione === | |
| |
| <color grey>Documentazione in allestimento</color> | |
