Informazioni di riferimento › Guida di riferimento al catalogo delle appliance › Catalogo di sistema › Gateway › INSSLR: gateway di input HTTP ridondante con supporto SSL

INSSLR: gateway di input HTTP ridondante con supporto SSL

Visualizza il video

Ultima versione: 3.1.2-1

Panoramica funzionale

L'appliance di INSSLR è un gateway a 7 layer per le richieste HTTP sicure. Converte le richieste in richieste HTTP non codificate. Può essere usato quando è necessario supportare HTTP sicuro sul lato client, ma l'infrastruttura di elaborazione di backend non supporta o non può supportare SSL, incluso:

• mediante un server HTTP leggero che non ha supporto SSL
• mediante server di back-end multipli, per prestazioni o per ridondanza, connessi attraverso uno switch di bilanciamento del carico
• mediante server di backend multipli per funzionalità non correlate connesse attraverso uno switch URL
• scaricando la crittografia/decrittazione SSL a un server separato per migliorare la velocità effettiva

Se configurato, INSSLR supporta anche l'autenticazione di certificato di client. In caso di autenticazione mutua di SSL, sia il client che il server scambiano i loro certificati e i loro codici pubblici corrispondenti. Il client può contattare l'autorità di certificazione che ha emesso il certificato del server e confermare che il certificato è autentico prima di continuare. Il server può fare altrettanto.

Nella sua configurazione predefinita INSSLR opera come gateway di layer 7 per richieste HTTP sicure, fornendo anche un punto di ingresso con firewall per il traffico di rete in un'applicazione di CA AppLogic® che è possibile configurare con un indirizzo IP statico accessibile da Internet.

Quando configurato, è possibile utilizzare due appliance di INSSLR in modalità di failover per consentire un servizio ridondante. In questo caso, l'indirizzo IP di INSSLR (configurato mediante ip_addr) viene eseguito soltanto su uno dei nodi ed è trasferito automaticamente all'altra appliance di INSSLR in caso di guasto. In qualsiasi momento, soltanto un'appliance di INSSLR è attiva. Durante l'esecuzione in modalità di failover è possibile configurare INSSLR per l'esecuzione in diverse modalità:

• Asimmetrica: una delle appliance è primaria e quando è in linea assume il controllo dell'indirizzo IP e diventa attiva. L'appliance di backup diventa attiva soltanto in caso di guasto (o arresto) del nodo primario. Quando l'appliance primaria diventa nuovamente disponibile, assume il controllo dell'indirizzo IP e diventa attiva. L'appliance primaria è quella con l'indirizzo IP più basso (confronto di stringa) come impostato nella proprietà di fover_local_ip.
• Simmetrico - le due appliance sono primarie e la prima che viene avviata assume il controllo dell'indirizzo IP e diventa attiva. L'altra appliance diventa attiva soltanto in caso di guasto della prima appliance (o se viene interrotta). Quando la prima appliance diventa nuovamente disponibile, non assume automaticamente il controllo dell'indirizzo IP.

Durante l'esecuzione in modalità ridondante, INSSLR offre un'interfaccia sul terminale CTL per:

• forzare INSSLR a diventare primario
• forzare INSSLR a diventare backup
• controllare lo stato di INSSLR (primario/backup)

INSSLR monitora costantemente lo stato dell'appliance di backend connessa al suo terminale di HTTP. I controlli di stato condotti da INSSLR possono includere una semplice connessione TCP o una richiesta HTTP più complessa (specificata sul limite di INSSLR). In caso di errore dell'appliance connessa, INSSLR segnala un errore al dashboard di griglia oppure, se è in modalità ridondante e configurato per farlo, esegue un failover all'appliance di backup di INSSLR.

Per supportare le applicazioni che devono apparire in un indirizzo IP singolo per più di un servizio, INSSLR può essere configurato per dirigere il traffico non HTTP direttamente a un terminale di output distinto. Per tali connessioni, l'appliance funge da firewall a 3 layer/router NAT.

Limite

Risorse

La memoria predefinita per la versione di CA AppLogic® 2.7 è stata modificata a 128 MB. La memoria minima rimane 64 MB.

note

• Quando si utilizza INSSLR in modalità di failover (fover_mode non è none), la memoria minima è di 100 M.
• La quantità di memoria assegnata a INSSLR non influisce sulla sua velocità effettiva. Usare più memoria soltanto per supportare più richieste concorrenti in cui i server di backend possono mantenere le richieste per periodi di tempo eccessivamente lunghi.

Terminali

Proprietà

Proprietà di healthcheck

Proprietà avanzate (usate negli scenari di failover)

Volumi

Messaggi di errore

I seguenti messaggi possono apparire nei file di log e nel log di sistema del controller di griglia quando l'appliance non riesce ad avviarsi:

• impossibile montare il volume di dati
• impossibile impostare le autorizzazioni sulla condivisione di dati
• impossibile avviare Samba
• impossibile avviare NFS
• impossibile avviare Apache

Prestazioni

Failover di applicazione

INSSLR rileva l'altro INSSLR in circa 10 secondi. Servono altri 10 secondi per eseguire il failover all'altra applicazione. Il tempo totale da quando si produce l'errore di applicazione a quando l'altra applicazione interviene è di circa 20 secondi.

Tasso di richiesta

INSSLR dirige non meno d 3000 transazioni (coppia richiesta/risposta) al secondo, in base alla dimensione del documento e alla larghezza di banda di rete disponibile.

Velocità effettiva di dati

INSSLR dirige non meno d 7 transazioni (coppia richiesta/risposta) al secondo, in base alla dimensione del documento e alla larghezza di banda di rete disponibile.

Connessioni concorrenti

Con la sua memoria predefinita, INSSLR supporta non meno d 500 richieste in sospeso in concorrenza. (Una richiesta pendente è una connessione TCP aperta dal client, su cui è presente una o più richieste HTTP non completate). Il valore massimo di connessioni concorrenti dipendono dalla memoria libera disponibile. Ciascuna memoria aggiuntiva di 16 MB aumenta il numero di transazioni http concorrenti di 500. Ad esempio, se viene eseguita la modalità ridondante e si vogliono servire 2000 connessioni concorrenti, servono 100 M + 3*= 148 M (la memoria minima quando viene eseguita una modalità ridondante è 100 M).

Notifiche

Quando viene eseguito in modalità ridondante (fover_mode non è none), INSSLR attiva le notifiche quando diventa attivo/passivo. Questo è fatto all'avvio del nodo attivo o quando si verifica un failover (ogni nodo invia una notifica che informa se è attivo/passivo).

INSSLR inviano due notifiche:

• una notifica al dashboard della griglia: risorsa di APP_NAME:COMP_NAME <acquired|gave up> dell'appliance di INSSLR ip_addr
• una richiesta HTTP mediante il terminale NFY. Spetta al terminale di ricezione prendere delle azioni in base alla notifica. L'URL richiesto è:

  http://nfy/fover_nfy_prefixfover_mode=fover_mode&state=<start|stop>&ip_addr=ip_addr&fover_local_ip=fover_local_ip&fover_remote_ip=fover_remote_ip&fover_netmask=fover_netmask

  fover_nfy_prefix può essere usato per modificare la posizione dello script remoto chiamato o/e per aggiungere altri parametri. Esempi di valori di fover_nfy_prefix: /path/to/script.php?, /path/to/script.php?username=user&password=pass&.

Importante:

• Quando si usa fover_nfy_prefix diverso dal predefinito, accertarsi che termini con ? se fover_nfy_prefix è soltanto il percorso lo script oppure & se fover_nfy_prefix include parametri aggiuntivi.
• Se un nodo diventa non disponibile, potrebbe non essere in grado di inviare una notifica sul suo stato passivo e soltanto il nodo che diventava invia la notifica.
• Il timeout per la richiesta HTTP è di 5 secondi per non rallentare il failover.

Healthcheck

INSSLR esegue un cronjob ogni minuto controllando quanto segue:

• Lo spazio libero sul volume di dati è inferiore al 20%
• Il daemon di rsync è in esecuzione (solo se configurato come slave)
• Il processo di replica è in esecuzione (solo se configurato come master). Altrimenti, il processo di replica viene riavviato.

Se si verifica una delle occorrenze di sopra, viene inviato un messaggio di errore al dashboard della griglia. Se più di un test non riesce, viene visualizzato un messaggio di sintesi di tutti gli errori sul dashboard della griglia. Gli errori sono inviati soltanto una volta all'ora al dashboard della griglia. Nei primi 5 minuti dall'avvio dell'appliance, gli errori non sono segnalati (per evitare falsi allarmi quando l'altro nodo nella replica non è avviato).

Certificati di server

Per utilizzare SSL, occorre il certificato firmato e il codice privato con cui è stato codificato. Il tasto e il certificato dovrebbero essere in formato PEM e inclusi in un file singolo specificato dalla proprietà cert_file.

In questa sezione verranno presentati i seguenti argomenti:

Generazione dei certificati di server

Uso dei certificati di server

Uso dei certificati di server apache+mod_ssl esistenti

Generazione dei certificati di server

CA AppLogic® permette di generare certificati di server.

Per generare i certificati di server

1. Generare un codice privato usando il seguente comando:

   openssl genrsa -out privkey.pem 2048 
   

   Per generare un codice protetto di trasmissione, usare il seguente. (Per utilizzare il codice con INSSLR è necessario un codice senza password, se si crea un codice protetto di trasmissione, occorre eliminare la password prima di usarla in INSSLR)

   openssl genrsa -des3 -out privkey.pem 2048 
   

2. Dopodiché è necessario un certificato. Sono disponibili due opzioni: creare una richiesta di certificato e farla firmare da un'autorità di certificazione attendibile (a un costo), oppure creare un certificato auto-firmato per scopi di test (in questo caso i browser che richiedono il sito emettono degli avvisi sul fatto che il certificato non è firmato da un'autorità di certificazione attendibile).

   Per generare una richiesta di certificato, procedere come segue:

   openssl req -new -key privkey.pem -out server.csr 
   

   Dopo aver inviato il file .csr all'autorità di certificazione attendibile, verrà inviato un certificato firmato (file .crt) che è possibile utilizzare.

3. Per generare un certificato auto-firmato, procedere come segue:

   openssl req -new -x509 -key privkey.pem -out server.crt -days 1095
   

Uso dei certificati di server

A questo punto, è possibile mettere il certificato e il codice in un file e usarlo in INSSLR:

cat privkey.pem  server.crt > server.pem 

Se il codice è protetto da password, è possibile eliminare la password procedendo come segue:

openssl rsa -in key_with_pass.pem -out privkey.pem

Uso dei certificati di server apache+mod_ssl esistenti

Se si ha un certificato esistente che vie eseguito in Apache, è possibile usarlo anche in INSSLR. Accertarsi che il codice non è protetto da password (vedere sopra) e mettere il codice privato e il certificato in un file, in quell'ordine.

Esempio:

cat privkey.pem  server.csr > server.pem 

Se si usa un certificato a catena, occorre includere il certificato intermedio fornito dal mittente. Introdurre il codice privato, il certificato e il certificato intermedio in un file in quell'ordine.

Esempio:

cat privkey.pem server.csr sf_issuing.crt > server.pem 

Importante: Il codice di firma del server è la prova d'identità del tuo sito Web. È anche vulnerabile, perché non è codificato da una password (quindi l'appliance può leggerlo senza assistenza). Adottare le misure necessarie per proteggere il file di codice quando viene installato sul volume di dati. Non usare lo stesso volume di dati per altri scopi e non renderlo visibile a un server Web, ad esempio, per ospitare dati accessibili dal Web (pagine HTML, script e simili).

Certificati di client

L'esempio seguente indica come creare la propria autorità di certificazione e utilizzarla per firmare i propri certificati tramite OpenSSL. Questo è stato testato usando OpenSSL 0.9.8b, la stessa versione installata in INSSLR.

In questa sezione verranno presentati i seguenti argomenti:

Creazione di un'Autorità di certificazione

Creazione di certificati di client firmati dall'autorità di certificazione

Creare i file di elenco di CA usati da INSSLR

Intestazioni di certificato di client

Creazione di un'Autorità di certificazione

Se si dispone già di un'autorità di certificazione che serve per creare il certificato del server autofirmato, ignorare questa fase e usare quell'autorità di certificazione. Quando si creano gli strumenti dell'autorità certificata per l'applicazione in uso, è importante che l'ambiente sia sicuro.

Per creare un'autorità di certificazione

1. Su un sistema host sicuro, creare una directory di processo e una directory privata nella directory di processo usando i seguenti comandi:

   mkdir CA 
   mkdir $CA/privato 
   

2. Creare un tasto di RSA protetto da password per l'autorità di certificazione che ha una lunghezza di codice di 2048 bit:

   openssl genrsa -des3 -out CA/private/CA_key.pem 2048 
   

• Usando il codice privato, creare il certificato di codice pubblico per l'autorità di certificazione:

  openssl req -new -key CA/private/CA_key.pem -x509 -days 365 -out CA/CA_cert.pem 
  

Importante: Il codice privato per l'autorità di certificazione è la base di fiducia per l'applicazione, quindi + importante non perderla o fornirla ad altre parti.

Creazione di certificati di client firmati dall'autorità di certificazione

CA AppLogic® lascia creare certificati di client che sono firmati dall'autorità di certificazione.

Per creare certificati di client firmati dall'autorità di certificazione

1. Generare un codice privato RSA (per creare un codice protetto da password, usare lo switch -des3):

   openssl genrsa -out clientA_privkey.pem 2048 
   

2. Generare una richiesta di sottoscrizione di certificato (CSR) dal codice privato:

   openssl req -new -key clientA_privkey.pem -out clientA_request.csr 
   

3. Firmare il certificato contenuto nel CSR usando il certificato generato per CA:

   openssl x509 -req -days 365 -in clientA_request.csr -CA CA/CA_cert.pem -CAkey CA/private/CA_key.pem -CAcreateserial -out clientA.cer 
   

Si ricorda che:

• lo switch -CAcreateserial abilita l'assegnazione dei numeri di serie unici per i certificati pubblicati. Dal momento che questo è il primo certificato pubblicato dall'autorità di certificazione, viene creato il file CA/CA_cert.srl per tenere traccia delle assegnazioni dei numeri di serie. Quando si creano i certificati di client successivi, lo switch -CAserial è usato al posto dello switch -CAcreateserial. Ad esempio:

  openssl genrsa -out clientB_privkey.pem 2048 
  openssl req -new -key clientB_privkey.pem -out clientB_request.csr 
  openssl x509 -req -days 365 -in clientB_request.csr -CA CA/CA_cert.pem -CAkey CA/private/CA_key.pem -CAserial CA/CA_cert.srl -out clientB.cer 
  

• Per creare un singolo file formattato PEM che include sia il certificato di client che il codice:

  cat clientA_privkey.pem clientA.cer > clientA.pem 
  

• Per creare il file equivalente in formato pkcs12 (compatibile con la maggior parte dei browser):

  openssl pkcs12 -export -in clientA.cer -inkey clientA_privkey.pem -out clientA.p12
  

Creare i file di elenco di CA usati da INSSLR

Revoca dei certificati di client firmati da CA

Per revocare un certificato di client pubblicato da CA:

• openssl ca -config openssl.conf -revoke clientB.cer -crl_reason keyCompromise

Dove un esempio "openssl.conf" è mostrato di seguito e il parametro "crl_reason" è uno fra: unspecified, keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold o removeFromCRL. L'abbinamento della ragione è sensibile alle maiuscole e minuscole.

Per ri-generare l'elenco di revoca di certificato (CRL):

• openssl ca -config openssl.conf -gencrl -out CA/crl.pem

In questo esempio "crl.pem" è il file che dovrebbe essere fornito a INSSLR come proprietà di "cert_revocation_list".

Un esempio di file di configurazione campione usato per gli esempi di sopra è:

      ####################################################################
      [ ca ]
      default_ca      = CA_default            # La sezione ca predefinita

      ####################################################################
      [ CA_default ]

      dir             = ./CA                  # Dove viene tenuto tutto
      certs           = $dir/certs            # Dove sono mantenuti i certificati pubblicati
      crl_dir         = $dir/crl              # Dove i crl sono pubblicati
      database        = $dir/index.txt        # file di indice del database.
      #unique_subject = no                    # Impostato su 'no' per consentire la creazione di
                                        # diversi ctificates con lo stesso oggetto.
      new_certs_dir   = $dir/newcerts         # posto predefinito per i nuovi certificati.

      certificate     = $dir/cacert.pem       # Il certificato di CA
      serial          = $dir/serial           # Il numero di serie corrente
      crlnumber       = $dir/crlnumber        # il numero crl corrente
                                        # deve essere commentato per lasciare un V1 CRL
      crl             = $dir/crl.pem          # Il CRL corrente
      private_key     = $dir/private/cakey.pem# Il codice privato
      RANDFILE        = $dir/private/.rand    # file di numero privato casuale

      default_days    = 365                   # tempo per certificare
      default_crl_days= 30                    # tempo prima del CRL successivo
      default_md      = sha1                  # quale md usare.
      preserve        = no                    # mantieni ordine DN trasmesso

      policy          = policy_anything

      [ policy_anything ]
      countryName             = facoltativo
      stateOrProvinceName     = facoltativo
      localityName            = facoltativo
      organizationName        = facoltativo
      organizationalUnitName  = facoltativo
      commonName              = fornito
      emailAddress            = fornito

Creare i file di elenco dell'autorità di certificazione usato da INSSLR

CA AppLogic® permette di creare i file di elenco dell'autorità di certificazione che sono usati da INSSLR.

Per creare il file identificato dalla proprietà ca_list_client

1. Accedere al seguente file:

   cat CA/private/CA_key.pem CA/CA_cert.pem > ca_list_client.pem 
   

2. Mettere questo file sul volume del codice o nel volume che è montato su nfs mediante il terminale di fs.
3. Se desiderato, il certificato di server di INSSLR (ad esempio, server.pem) può essere creato allo stesso modo dei certificati client e firmato dall'autorità di certificazione creata. Non utilizzare una password per questo certificato.
4. Dopo aver adottato server.pem e ca_list_client.pem, l'autenticazione del certificato client può essere testata come segue:
   • Per eseguire il test da un browser, importare un certificato di client formattato pkcs12 in Firefox da Strumenti, Opzioni, Visualizza certificati, Certificati personali, Importa. Puntare il browser all'indirizzo IP di INSSLR.
   • Per testare l'handshake SSL da un host remoto:

     openssl s_client -host IP-address -port 443 -showcerts -ssl3 -cert clientA.cer -key clientA_privkey.pem -state 
     

Intestazioni di certificato di client

Se un client si connette a INSSLR mediante HTTPS, e se presenta un certificato di client, INSSLR aggiunge le seguenti intestazioni alla richiesta che emette al server di backend:

• dettagli di X-SSL-Subject sul titolare di certificato.
• dettagli di X-SSL-Issuer sull'autorità di certificazione (autorità del certificato).
• numero di serie di certificato di X-SSL-serial (decimale).
• X-SSL-cipher la crittografia attualmente in uso.
• X-SSL-certificate il certificato di client completo (Multi line di formato di PEM).

È responsabilità dell'applicazione fare uso di queste intestazioni o non. INSSLR trasmette semplicemente le informazioni senza verificarle (se non la correttezza della firma e della codifica).

Applicazioni Web

Per consentire l'accesso di http(s) alla sua applicazione, connettere il terminale di HTTP direttamente all'appliance WEB.

Un'applicazione Web scalabile con il terminale di HTTP connesso a un'appliance HALB

Configurazione per applicazioni Web

Gli esempi di configurazione mostrano soltanto le proprietà impostate su valori non predefiniti e non mostrano la configurazione di rete (ip_addr, maschera di rete, gateway).

Applicazioni Web con servizi aggiuntivi

Se si hanno più servizi nell'applicazione, oltre a HTTP, è possibile usare INSSLR per trasmettere il traffico HTTP al rispettivo terminale e utilizzare il terminale di AUX per altri servizi.

Applicazioni Web con più di un servizio aggiuntivo

Se si hanno più servizi tcp/udp oltre all'HTTP, è possibile utilizzare INSSLR per trasmettere il traffico HTTP al rispettivo terminale di HTTP e usare AUX per alimentare il traffico restante a PS8, che alimenta il traffico desiderato ai server di backend.

Applicazioni Web ridondanti

Per fornire un'applicazione Web ridondante, è possibile copiare l'applicazione e usare INSSLR per fornire le funzionalità di failover per l'indirizzo IP esterno.

Applicazione Web di backup

Se si desidera soltanto un'applicazione di backup che notifica gli utenti dei tempi di inattività, si può usare INSSLR per creare un'applicazione di backup che richiede risorse minime.

Appliance in uso:

• utente - gateway di input delle richieste degli utenti
• web - server Web che visualizza il messaggio di mantenimento

INSSLR sull'applicazione primaria:

INSSLR sull'applicazione di backup:

Applicazione Web ridondante (applicazione singola)

Per fare in modo che l'applicazione operi in modalità ridondante senza creare una nuova applicazione, è sufficiente raddoppiare le appliance ed eseguirle in modalità ridondante. Dato che ciò implica l'utilizzo (almeno) di due server Web e di due appliance di database, nella modalità normale sono usati tutti (e forniscono la scalabilità), ma ciascuno di loro è in grado di servire l'applicazione da solo se l'altra appliance non funzionasse. Per aumentare la scalabilità, è possibile aggiungere più appliance di Web e database. In questo esempio, metà delle appliance (in1, sw1, web1, db1) sono eseguite in un gruppo di failover e le altre (in2, sw2, web2, db2) sono eseguite in un altro gruppo di failover in modo che l'applicazione possa continuare a funzionare in caso di crash del server. Questa applicazione consente ridondanza a un costo molto basso come tutte le appliance (tranne un INSSLR e una appliance di HALB che richiedono risorse molto basse) sono in stato attivo e nessuna risorsa viene spesa per un'appliance di backup che corre solamente quando il fondamento non riesce.

in1

in2

db1

DB2

Applicazione Web ridondante (due applicazioni identiche)

È possibile eseguire due applicazioni identiche sulla stessa griglia (ma su server distinti in modo che il guasto di un server influisce soltanto su una delle applicazioni), o su griglie differenti, purché l'indirizzo IP usato sia accessibile dalle due griglie. L'esempio di seguito mostra un'applicazione che usa un'appliance di database che è ance eseguita in modalità ridondante in modo che, in caso di guasto di un'applicazione, l'altra può intervenire senza perdita di dati.

Appliance in uso:

• in1 - gateway di input ridondante per richieste dell'utente
• admin - gateway di input per l'accesso dei file log
• sw - reindirizza la porta 8080 da admin a ui su db
• repl_in - input per l'applicazione remota per eseguire la connessione all'appliance di db e replicare il database
• web_lb - utilità di bilanciamento di Web per le richieste utente
• web1, web2 - server Web con contenuto attivo (per esempio, script di CGI)
• db - MYSQLR64 configurato sul master e lo slave allo stesso tempo
• contenuto - archiviazione dei file log degli errori del database, contenuto Web e log Web
• logs - archiviazione dei file log degli errori Web
• repl_out - gateway di output per l'appliance di db che si connette all'applicazione remota per replicare il database
• mon - appliance MON

La richiesta del client arriva sul gateway in1. Il gateway inoltra le richieste all'utilità di bilanciamento del carico Web, che indirizza la richiesta a uno dei server Web (web1 o web2). I server Web accedono al database di db. L'appliance di db si connette all'applicazione remota (che è una copia identica, l'unica differenza è il server_id del db e l'installazione di rete) per replicare il database. L'applicazione remota si connette all'appliance di db mediante repl_in gateway che è configurato per permettere la connessione soltanto da repl_out gateway dell'applicazione remota. Le appliance di db nelle due applicazioni sono eseguite nella configurazione master-master in modo che abbiamo sempre dati identici.

Esempio di configurazione di proprietà (le proprietà che non sono elencate dovrebbero essere lasciate ai loro valori predefiniti):

L'accesso Web a db è disponibile mediante il gateway di admin sulla porta 8080.

in1

db

Importante: Soltanto una delle applicazioni è attiva in qualsiasi momento, l'altra è eseguita per il failover ed è usata quando l'applicazione attiva non riesce.

note

INSSLR supporta HTTP 1.0 e HTTP 1.1, ma se il client si identifica come MSIE, il supporto di HTTP 1.1 viene disattivato per quella connessione (per evitare i bug in alcune versioni di MSIE).

Se il client non è MSIE, INSSLR supporta HTTP 1.1 per il client (incluse le richieste multiple per capacità di sessione TCP), anche se il server di back-end supporta soltanto HTTP 1.0.

INSSLR supporta un IP esterno singolo e pertanto è possibile usare un unico certificato SSL.

Software open source e di terze parti utilizzato all'interno dell'appliance

INSSLR utilizza i seguenti pacchetti open source di terze parti oltre ai pacchetti open source di terze parti utilizzati dalla loro classe di base LUX6.