DNS and Proxy Manager setup

Back

LBL®DNS & Proxy Manager è un prodotto destinato ad ambienti mission-critical pertanto solo personale che ha effettuato il corso ed ha superato l’esame è autorizzato a certificare l’installazione e manutenzione dei prodotti in esercizio. Tutte le persone certificate sono dotate di patentino di riconoscimento rilasciato da TCOGROUP.

LBL®DNS & Proxy Manager può essere installato in due modalità, assieme a LBL®ADC oppure da solo (alone). In entrambi i casi è necessaria la licenza specifica LBL®DNS & Proxy Manager per poterlo utilizzare. Entrambe le installazioni sono simili ad eccezione della posizione della licenza.

LBL®DNS & Proxy Manager è stato rilasciato per cooperare con il DNS Server BIND*** oppure con MS DNS*** che devono essere installati e funzionanti.

Questo documento non vuole essere un manuale per l’installazione e configurazione del DNS BIND*** o del MS DNS***, si limita a dare le nozioni necessarie per poter installare e configurare LBL®DNS & Proxy Manager con dei servizi di esempio. Per una completa trattazione dell’argomento DNS si rimanda alla documentazione dei prodotti o alle raccomandazioni W3C IETF.

LBL®Management Console

Prima di procedere all’installazione della componente server è consigliato eseguire l’installazione della componente LBL®Management Console per poter effettuare le operazioni di configurazione.

Per l’installazione della componente LBL®Management Console fare riferimento al manuale LBL_ManagementConsole_Installation.pdf disponibile nei supporti di memorizzazione forniti con il prodotto o attraverso download da area riservata.

Impostazione Data e Ora del sistema operativo

LBL®DNS & Proxy Manager non è sensibile a differenze di orario sui Nodi durante il funzionamento. Ciò nonostante se durante il funzionamento si dovessero cambiare la data e l’ora del sistema alcune considerazioni potrebbero venire falsate come ad esempio i calcoli di time-out, lease time o considerazioni sulle date di repository (es.: data della versione del repository di georeferenzazione).

Per quanto descritto è quindi consigliabile impostare la data e l’ora del sistema con valori il più vicino possibile alla data e all’ora correnti. L’utilizzo dell’allineamento tramite protocollo NTP è consigliato.

Start Monitor & Visual Configuration

Per eseguire lo start del servizio di management da linea di comando è ora sufficiente eseguire il batch go.sh o go.bat a seconda del tipo di sistema operativo:

Unix-Linux:

# ./go.sh

MS Windows:

C:\> go.bat

Questo comando esegue in modalità interattiva il server di management LBL®Monitor.

Dalla postazione dove è stato installata precedentemente LBL®Management Console, avviare il programma visuale di configurazione, effettuare il login con l’indirizzo impostato nel file di configurazione al parametro LBL_GLOBAL_ADDRESS_MANAGEMENT. Immediatamente

viene visualizzato lo stato dei processi associati al server LBL®Monitor:

A05_LBLGoDNSManager – inserimento licenza

Con il mouse selezionare il processo A05_LBLGoDNSManager e nel menu contestuale scegliere “Install license”



Verrà richiesto di indicare il file di licenza da caricare (N.B.: Deve chiamarsi license.xml”):

A05_LBLGoDNSManager – popup menu ‘Properties’


Per impostare i parametri di configurazione sarà ora sufficiente selezionare A05_LBLGoDNSManager e con il tasto destro del mouse scegliere Properties:


Selezionando i pannelli con i rispettivi nomi dei file parametri è possibile procedere alla configurazione.

‘accesso al processo base LBL Monitor è possibile anche attraverso Web Browser come nelle versioni precedenti.

Piano degli indirizzi

Per procedere all’installazione di LBL®DNS & Proxy Manager è necessario effettuare il piano degli indirizzi in maniera adeguata alle esigenze di progetto.

Per questa guida all’installazione prenderemo ad esempio la necessità di impostare in RoundRobin sul dominio www.tcoproject.dev due indirizzi ai quali rispondono i due nodi active-active LBL®ADC Enterprise HA

Per ognuna delle istanze LBL® LoadBalancer Enterprise HA verrà attribuito un proprio indirizzo gestito dal bilanciatore. Tra le diverse macchine che ospiteranno LBL®ADC è opportuno per semplicità riportare le stesse informazioni.

Il file hosts, /etc/hosts in ambiente Unix-Linux e C:\WINDOWS\system32\drivers\etc\hosts in ambiente MS Windows, dovrebbe assomigliare al seguente esempio:

127.0.0.1 localhost

192.168.43.3 papaia # papaia locale

192.168.44.4 papaiaprivate # papaia privato

192.168.45.101 papaiabackend # papaia backend

192.168.43.6 mango # mango pubblico

192.168.44.5 mangoproivate # mango privato

192.168.45.100 mangobackend # mango backend

192.168.43.136 grid000 # indirizzo grid NODO A

192.168.43.138 grid001 # indirizzo grid NODO B

I due indirizzi evidenziati in rosso sono afferenti rispettivamente al NODO A ed al NODO B e vengono completamente controllati dalle istanze di bilanciamento LBL® LoadBalancer Enterprise HA. Questi indirizzi verranno gestiti dal DNS in RoundRobin attraverso un unico dominio. Nel caso specifico verrà preso ad esempio il dominio www.tcoproject.dev.

Si assume negli esempi di seguito che i DNS rispondano nelle stesse macchine dove sono installate le istanze di bilanciamento agli indirizzi: 192.168.43.111 e 192.168.43.112.

BIND: Determinazione corretto funzionamento del DNS

Immediatamente dopo il piano degli indirizzi e la verifica del corretto funzionamento del

DNS è necessario determinare le posizioni delle directory del DNS e annotare scrupolosamente le directory su cui l’istanza BIND agisce per associare i nomi, gli indirizzi e i servizi associati ad essi.

Il corretto funzionamento del DNS BIND è facilmente determinabile attraverso il comando rndc. Di seguito il risultato di questo comando che in tutti i sistemi operativi risponde nella medesima maniera. Andare la prima volta sul NODO A.

Solaris, Linux, MS Windows (SO indipendent):

# rndc status

number of zones: 2

debug level: 0

xfers running: 0

xfers deferred: 0

soa queries in progress: 0

query logging is OFF

recursive clients: 0/1000

tcp clients: 0/100

server is up and running

In rosso è evidenziato lo stato del DNS che deve essere “up and running”.

Il comando rndc si trova solitamente nelle seguenti directory:

Solaris:

# which rndc

/usr/sbin/rndc

Linux:

# which rndc

/usr/sbin/rndc

MS Windows (in dipendenza della directory di installazione:

Nel nostro esempio:

C:\TCOProject\bin\BIND\bin\rndc.exe

BIND: Determinazione directory delle zone del DNS

Immediatamente dopo il piano degli indirizzi e la verifica del corretto funzionamento del DNS è necessario determinare le posizioni delle directory del DNS. BIND descrive le proprie caratteristiche in un file di profilo che normalmente prende il nome di named.conf. Quindi il primo passo è verificare nel proprio sistema operativo la posizione di questo file.

Su Solaris normalmente lo si può trovare in:

/etc/named.conf

Su Linux normalmente lo si può trovare in:

/etc/bind/named.conf

Su MS Windows è dipendente dalla directory di installazione richiesta dall’autoinstaller. Prenderemo in considerazione per questa ipotesi:

C:\TCOProject\bin\BIND\etc\named.conf

Una volta verificata la posizione del file named.conf all’interno si potranno trovare le directory in cui verranno cricate le zone con i namespace per ogni dominio gestito dal DNS. Per questo esempio prenderemo in considerazione una installazione effettuata su MS Windows. Le uniche differenze rispetto ad una installazione su Solaris o Linux sono le indicazioni dei percorsi (path) dove sono memorizzati i files delle zone con i relativi namespace.

named.conf

options {

directory “C:\TCOProject\bin\BIND\etc\zones”;

multiple-cnames yes;

};

key “rndc-key” {

algorithm hmac-md5;

secret “64WJDedFIw3vfJYFVYMTlQ==”;

};

controls {

inet 127.0.0.1 port 953

allow { 127.0.0.1; } keys { “rndc-key”; };

};

zone “.” {

type hint;

file “root.hints”;

};

zone “tcoproject.dev” {

type master;

file “local/tcoproject.dev.db”;

};

zone “43.168.192.in-addr.arpa” {

type master;

file “local/rev.43.168.192.in-addr.arpa”;

};

Evideanziati in verde e rosso rispettivamente i parametri ed il loro valore necessari per la determinazione delle directory e dei file zone.

In questo esempio nel parametro directory viene indicata come directory di default per i file di zona “C:\TCOProject\bin\BIND\etc\zones”.

Nell’esempio si possono trovare anche altri due parametri evidenziati. Questi parametri indicano la posizione dei file che contengono i namespace.

zone “tcoproject.dev” {

type master;

file “local/tcoproject.dev.db”;

};

zone “43.168.192.in-addr.arpa” {

type master;

file “local/rev.43.168.192.in-addr.arpa”;

};

Essendo nei parametri file indicato un percorso relativo entrambi sono da intendersi come percorso assoluto la somma del percorso assoluto indicato nel parametro directory più quanto indicato sul parametro file.

Quindi la posizione assoluta del file di zona tcoproject.dev sarà:

C:\TCOProject\bin\BIND\etc\zones\local\tcoproject.dev.db

Mentre la posizione assoluta del file di zona 43.168.192.in-addr.arpa sarà:

C:\TCOProject\bin\BIND\etc\zones\local\rev.43.168.192.in-addr.arpa

Questi elementi sono sufficienti per la determinazione dei percorsi e dei file interessati da LBL®DNSManager. Questi due ultimi file saranno infatti oggetto di modifica dinamica in dipendenza delle verifiche di disponibilità dei servizi.

BIND: Caricamento iniziale namespace nei zone file del DNS

Una volta determinate le posizioni dei file di zona la prima operazione è rendere operativo il DNS con i propri namespace in modo da verificarne la funzionalità. A questo scopo si predisporranno i due file:

C:\TCOProject\bin\BIND\etc\zones\local\tcoproject.dev.db

$TTL 3

@ IN SOA ns.tcoproject.dev. hostmaster.tcoproject.dev. (

2010010701 ; serial, todays date + todays serial #

8H ; refresh

30m ; retry

4W ; expire

10) ; minimum

NS ns ; Inet Address of name server

www IN A 192.168.43.136

www IN A 192.168.43.138


C:\TCOProject\bin\BIND\etc\zones\local\rev.43.168.192.in-addr.arpa

$TTL 3

@ IN SOA ns.tcoproject.dev. hostmaster.tcoproject.dev. (

2010010701 ; serial, todays date + todays serial #

8H ; refresh

30m ; retry

4W ; expire

10) ; minimum

NS ns.tcoproject.dev.

136 PTR www.tcoproject.dev.

138 PTR www.tcoproject.dev.

Una volta completato il popolamento dei file di zona è necessario farli recepire all’istanza DNS. Per questa operazione è sufficiente eseguire il comando rndc seguito dal parametro reload:

Solaris, Linux, MS Windows (OS Indipendent):

C:\ rndc reload

server reload successful

MS DNS: Determinazione corretto funzionamento del DNS

Per verificare il funzionamento del DNS di Microsoft eseguite :

Control Panel->Administrative Tools->

—> DNS

MS DNS: Componenti necessari

LBL®DNS & Proxy Manager in ambiente MS DNS utilizza il comado “dnscmd.exe” per modificare durante il runtime le associazioni nomi-dominio<>indirizzi. Questo comando, presente di default su Windows 2008 Server deve essere invece installato come pacchetto supplementare “Support Tools” per le versioni Windows 2003 Server.

Per Windows 2003 Server la directory di installazione del package determinerà la posizione del comando es.:

C:\Support Tools\

Si consiglia di utilizzare directory senza spazi in modo da non aver problemi durante il set delle directory.

Per Windows 2008:

C:\Windows\System32

MS DNS: Determinazione directory

MS DNS può essere impostato durante il runtime in due differenti modalità: Attraverso file di zona oppure attraverso comandi espliciti dichiarati nei parametri del programma di gestione a linea di comando dnscmd.exe.

Entrambe le modalità sono supportate da LBL®DNSManager. In questo esempio utilizzeremo la modalità con comandi espliciti dichiarati nei parametri del programma di gestione a linea di comando dnscmd.exe perché normalmente MS DNS viene configurato con il repository memorizzato su Active Directory e questa modalità copre questa caratteristica.

Le uniche directory da determinare in questo caso sono la posizione del comando dnscmd.exe (vista nel precedente paragrafo) e individuare una directory che ci permetta di contenere gli script che verranno dinamicamente generati da LBL®DNS & Proxy Manager per popolare MS DNS. Per quest’ultimo scopo consigliamo di utilizzare una directory prossima alla directory (LBL_HOME) o addirittura all’interno di (LBL_HOME). Nell’esempio utilizzeremo una directory opportunamente creata in:

(LBL_HOME)\lib\scriptDNSManager\

In questa directory verranno depositati gli script per la manipolazione delle associazioni nomi-dominio<>Indirizzi.

MS DNS: Caricamento iniziale namespace

Per il caricamento iniziale dei namespace ci avvarremo dell’interfaccia visuale che Microsoft ha predisposto a questo scopo.

Control Panel->Administrative Tools->DNS

In questa finestra si può vedere l’esistenza della zona tcoproject.dev, precedentemente creata, sulla quale andreamo ad agire in un primo momento manualmente e quindi poi in automatico con LBL®DNSManager.

Andremo ora a impostare i nomi host con i relativi indirizzi. Nome della zona più nome host formeranno il “domain”.



Creare il primo host con nome “www” facendo attenzione di creare anche l’associazione inversa attraverso il check button [ ] Create associated pointer (PTR) record.

L’associazione della risoluzione inversa indirizzi<>nome-dominio merita alcune considerazioni in base al tipo di installazione. Queste considerazioni sono approfondite attraverso il corso di certificazione. In questo manuale ci limiteremo a dare le informazioni relative alle impostazioni di base come aiuto all’installazione che deve essere preceduta come sempre dalla raccolta dei requisiti e definizione del piano indirizzi e nomi.

Il risultato che abbiamo ottenuto è un’associazione allo stesso dominio www.tcoproject.dev di due indirizzi 192.168.43.136 e 192.168.43.138. Questi indirizzi verranno ruotati ciclicamente dal DNS in automatico senza eseguire nessuna ulteriore azione di impostazione.

es.:

Se eseguissimo ora un ping l’effetto non sarebbe lo stesso a causa del TTL (Time To live). Per abbassare il TTL ci sono due modalità, o a livello di zona oppure a livello di singolo nome host. Negli esempi di seguito con LBL®DNS & Proxy Manager utilizzeremo il TTL associato al nome host in modo da non alterare eventuali altri politiche di TTL associati ad altri host presenti sulla zona che possono avere differenti necessità.

C:\Users\Administrator>nslookup www.tcoproject.dev

Server: localhost

Address: 127.0.0.1

Name: www.tcoproject.dev

Addresses: 192.168.43.136

192.168.43.138

C:\Users\Administrator>nslookup www.tcoproject.dev

Server: localhost

Address: 127.0.0.1

Name: www.tcoproject.dev

Addresses: 192.168.43.138

192.168.43.136

C:\Users\Administrator>

N.B.: La reverse zone deve già essere stata creata in precedena prima di questa operazione

Verifica della corretta impostazione RR del domain nel DNS

Per verificare il corretto funzionamento del DNS bisogna utilizzare in un client il comando nslookup. Di seguito lo stesso comando utilizzato su più sistemi operativi. In rosso sono evidenziati gli indirizzi. Il primo parametro di nslookup è il nome dominio che si vuole verificare il secondo è l’indirizzo al quale risponde il DNS in modo da essere sicuri di verificare la risposta dal DNS corretto.

MS Windows:

C:\>nslookup www.tcoproject.dev 192.168.43.111

*** Impossibile trovare nome server per l’indirizzo 192.168.43.111: Non-existent domain

Server: UnKnown

Address: 192.168.43.111

Nome: www.tcoproject.dev

Addresses: 192.168.43.136, 192.168.43.138

Solaris:

# nslookup www.tcoproject.dev 192.168.43.111

Server: 192.168.43.111

Address: 192.168.43.111

Name: www.tcoproject.dev

Address: 192.168.43.136

Name: www.tcoproject.dev

Address: 192.168.43.138

Linux:

# nslookup www.tcoproject.dev 192.168.43.111

Server: 192.168.43.111

Address: 192.168.43.111

Name: www.tcoproject.dev

Address: 192.168.43.136

Name: www.tcoproject.dev

Address: 192.168.43.138

Verifica corretta impostazione reverse-namespace sul DNS

Per completare la verifica della corretta impostazione è necessario verificare anche se la risoluzione inversa (reverse) è stata recepita e impostata correttamente. A tal fine eseguire di seguito i seguenti comandi:

MS Windows:

C:\>nslookup 192.168.43.136 192.168.43.111

*** Impossibile trovare nome server per l’indirizzo 192.168.43.111: Non-existent domain

Server: UnKnown

Address: 192.168.43.111

Nome: www.tcoproject.dev

Address: 192.168.43.136

C:\>nslookup 192.168.43.138 192.168.43.111

*** Impossibile trovare nome server per l’indirizzo 192.168.43.111: Non-existent domain

Server: UnKnown

Address: 192.168.43.111

Nome: www.tcoproject.dev

Address: 192.168.43.138

Solaris:

# nslookup 192.168.43.136 192.168.43.111

Server: 192.168.43.111

Address: 192.168.43.111

138.43.168.192.in-addr.arpa name = www.tcoproject.dev.

# nslookup 192.168.43.138 192.168.43.111

Server: 192.168.43.111

Address: 192.168.43.111

138.43.168.192.in-addr.arpa name = www.tcoproject.dev.

Linux:

# nslookup 192.168.43.136 192.168.43.111

Server: 192.168.43.111

Address: 192.168.43.111

138.43.168.192.in-addr.arpa name = www.tcoproject.dev.

# nslookup 192.168.43.138 192.168.43.111

Server: 192.168.43.111

Address: 192.168.43.111

138.43.168.192.in-addr.arpa name = www.tcoproject.dev.

Completamento configurazione DNS

A completamento della configurazione rieseguire le stesse operazioni dal capitolo 11 al capitolo 15 sul NODO B ottenendo la seguente situazione:

Nei due nodi (A e B) sono installati e configurati i DNS in modo che entrambi rispondano nella medesima maniera associando al nome www.tcoproject.dev gli indirizzi 192.168.43.136 e 192.168.43.138. In questa fase il DNS non andrà a verificare l’effettiva esistenza di questi indirizzi e l’operatività dei servizi ad essi associati, questa funzionalità infatti verrà implementata da LBL®DNSManager.

BIND: Verifica template in (LBL_HOME)/lib/templateDNSManager/

Nella directory (LBL_HOME)/lib/templateDNSManager/ sono contenuti i file per la costruzione dinamica delle zone. Nello specifico vengono distribuiti due file di esempio:

  • tcoproject.dev.db.template
  • rev.43.168.192.in-addr.arpa.template

Questi file contengono

(LBL_HOME)/lib/templateDNSManager/tcoproject.dev.db.template

%comment%

; LBL(tm) LoadBalancer

;

; This is a commercial software

;You shall not disclose such Confidential Information and shall use

; it only in accordance with the terms of the license agreement

;

; www.tcoproject.com

; www.lblloadbalancer.com

; mailto:info@tcoproject.com

;

; LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

;LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

; Template file LBL(r)DNSManager

$TTL 3

@ IN SOA ns.tcoproject.dev. hostmaster.tcoproject.dev. (

%serial% ; serial, todays date + todays serial #

8H ; refresh

30m ; retry

4W ; expire

10) ; minimum

NS ns ; Inet Address of name server

%namespaces%

(LBL_HOME)/lib/templateDNSManager/rev.43.168.192.in-addr.arpa.template

%comment%

; LBL(tm) LoadBalancer

;

; This is a commercial software

;You shall not disclose such Confidential Information and shall use

; it only in accordance with the terms of the license agreement

;

; www.tcoproject.com

; www.lblloadbalancer.com

; mailto:info@tcoproject.com

;

; LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

;LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

; Template file LBL(r)DNSManager

$TTL 3

@ IN SOA ns.tcoproject.dev. hostmaster.tcoproject.dev. (

%serial% ; serial, todays date + todays serial #

8H ; refresh

30m ; retry

4W ; expire

10) ; minimum

NS ns.tcoproject.dev.

%namespaces%

In entrambi i file distribuiti si possono notare delle similitudini con i file zone impostati sui DNS ad eccezione dei TAG evidenziati in rosso “%namespaces%” e “%serial%”. Questi TAG infatti verranno popolati dinamicamente in base alle regole impostate nel file (LBL_HOME)/lib/confDNSManager/dnsmanager.xml.

ATTENZIONE

I file di template presenti in questa directory sono continuamente verificati da LBL®DNS & Proxy Manager una volta avviato.

Ad ogni modifica di questi file verranno ricaricate automaticamente le zone del DNS. Si consiglia di tenerne una copia sorgente in altra directory e una volta ultimate le modifiche spostarle in questa zona di produzione.

BIND: Configurazione (LBL_HOME)/lib/confDNSManager/dnsmanager.xml

Il file di configurazione dnsmanager.xml contiene tutte le informazioni per popolare dinamicamente i file zone del DNS completando i template file.

Il file è formato da due paragrafi; il primo <params> descrive le variabili generali mentre il secondo ,<zone> che può essere ripetuto più volte, definisce le zone del dns. All’interno del secondo paragrafo <zone> vengono definiti gli spazi dei nomi e le relative condizioni di verifica (HealthCheck) della “vitalità dei servizi” <namespace>.

<serviceconf>

<copyright>

</copyright>

<dnsmanager>

<params>

</params>

<zone>

<namespace>

<condition>

</condition>

</namespace>

</zone>

</dnsmanager>

</serviceconf>

Per una completa trattazione dei singoli parametri si rimanda al documento LBL®A.A.I. Reference Guide.

Nel nostro caso andremo a popolare il file di esempio messo a disposizione della distribuzione e di seguito riportato.

File di configurazione dnsmanager.xml compreso nella distribuzione:

<?xml version=”1.0″ encoding=”windows-1252″?>

<serviceconf>

<copyright>

LBL(tm) LoadBalancer

This is a commercial software

You shall not disclose such Confidential Information and shall use

it only in accordance with the terms of the license agreement

www.tcoproject.com

www.lblloadbalancer.com

mailto:info@tcoproject.com

LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

</copyright>

<dnsmanager>

<params

frequency=”60000″

templateDir=”lib/templateDNSManager”

templateSerialWithDate=”true”

reloadCommand=”____reload_cmd_with_absolute_address____es.:C:/work1/bin/named/bin/rndc reload”

sysCommandRemoteURL=”http://localhost:5992/SysCommand”>

</params>

<zone enable=”true”

namespaceFile=”__________________es.:C:\work1\bin/named/etc/zones/local/tcoproject.dev.db”

namespaceTemplateFile=”__________es.:tcoproject.dev.db.template”

namespaceReverseFile=”___________es.:C:/work1/bin/named/etc/zones/local/rev.43.168.192.in-addr.arpa”

namespaceReverseTemplateFile=”___es.:rev.43.168.192.in-addr.arpa.template”>

<namespace enable=”true”

address=”_______________es.:192.168.43.136″ port=”80″ uriPath=”/HealthCheck” SSL=”false”

namespace=”_____________es.:www IN A 192.168.43.136″

namespaceReverse=”______es.:136 PTR www.tcoproject.dev.”/>

<namespace enable=”true”

address=”_______________es.:192.168.43.138″ port=”80″ uriPath=”/HealthCheck” SSL=”false”

namespace=”_____________es.:www IN A 192.168.43.138″

namespaceReverse=”______es.:138 PTR www.tcoproject.dev.”/>

</zone>

<sysobserver>

</sysobserver>

</dnsmanager>

</serviceconf>

In blue sono evidenziati i paragrafi, in verde i nomi dei parametri, in rosso i valori dei parametri che normalmente restano invariati mentre in nero sono rimasti i valori da completare con le informazioni del nostro progetto.

Nel paragrafo <params>

  • reloadCommand deve essere completato con il valore del comando da eseguire per ricaricare le zone nel DNS. Il comando deve essere lo stesso utilizzato per la prova manuale. E’ consigliabile indicare il path assoluto del comando in modo da essere esenti da problemi a seguito di modifiche all’environment successive all’installazione che ne potrebbero compromettere il funzionamento. Nel nostro esempio “C:/TCOProject/bin/BIND/bin/rndc reload

    Nel paragrafo <zone>

  • namespaceFile è il file zone del DNS. Questo valore deve essere completato con il path assoluto e il nome del file precedentemente impostato a mano nelle directory di zona del DNS. Nel nostro esempio:

    C:\TCOProject\bin\BIND\etc\zones\local\tcoproject.dev.db

  • namespaceTemplateFile è il template file che serve come traccia per la generazione dinamica delle associazioni nome<>indirizzi. Può essere completato sia con un path assoluto oppure con un path relativo al parametro templateDir=”lib/templateDNSManager” nel paragrafo <params>. Nel nostro esempio: “tcoproject.dev.db.template“. Il valore risultante sarà quindi:

    “(LBL_HOME)/lib/templateDNSManager/tcoproject.dev.db.template

    e cioè il template file visto precedentemente.

  • namespaceReverseFile è il file zone per la risoluzione inversa da indirizzo a nome dominio. Questo valore nel nostro caso deve essere completato con il path assoluto e il nome del file precedentemente impostato a mano (eseguirne prima una copia di sicurezza su altra directory). Nel nostro esempio:


C:\TCOProject\bin\BIND\etc\zones\local\rev.43.168.192.in-addr.arpa”.

  • namespaceReverseTemplateFile è il template file che serve come traccia per la generazione dinamica delle associazioni indirizzi<>nomi. Può essere completato sia con un path assoluto oppure con un path relativo al parametro templateDir=”lib/templateDNSManager”. Nel nostro esempio:

rev.43.168.192.in-addr.arpa“. Il valore risultante sarà quindi:

“(LBL_HOME)/lib/templateDNSManager/rev.43.168.192.in-addr.arpa

e cioè il template file visto precedentemente.

Nel 1° paragrafo <namespace>

  • address è l’indirizzo da sottoporre ad HealthCheck per determinare l’attività e quindi la disponibilità di questo name space. Gli altri parametri, port, uriPath e SSL sono intuitivi. Se questo indirizzo/port/uriPath risulterà attivo il namespace descritto nei parametri di seguito entrerà nel nuovo zone file. Nel nostro esempio verrà popolato con l’indirizzo a cui afferiscono i servizi del NODO A. “192.168.43.136
  • namespace è il frammento del namespace da inserire nel template file nel caso il test di HealthCheck vada a buon fine. Nel nostro esempio:

    www IN A 192.168.43.136

  • namespaceReverse è il frammento del namespace reverse da inserire nel template file nel caso il test di HealthCheck vada a buon fine. Nel nostro esempio:

136 PTR www.tcoproject.dev.

Nel 2° paragrafo <namespace>

  • address è l’indirizzo da sottoporre a HealthCheck per determinare l’attività e quindi la disponibilità di questo name space. Gli altri parametri, port, uriPath e SSL sono intuitivi. Se questo indirizzo/port/uriPath risulterà attivo il namespace descritto nei parametri di seguito entrerà nel nuovo zone file. Nel nostro esempio verrà popolato con l’indirizzo a cui afferiscono i servizi del NODO B. “192.168.43.138
  • namespace è il frammento del namespace da inserire nel template file nel caso il test di HealthCheck vada a buon fine. Nel nostro esempio:

    www IN A 192.168.43.138

  • namespaceReverse è il frammento del namespace reverse da inserire nel template file nel caso il test di HealthCheck vada a buon fine. Nel nostro esempio:

    138 PTR www.tcoproject.dev.


Il file di configurazione risultante deve assomigliare a quello di seguito:

File di configurazione dnsmanager.xml compltetato partendo dal file nella distribuzione:

<?xml version=”1.0″ encoding=”windows-1252″?>

<serviceconf>

<copyright>

LBL(tm) LoadBalancer

This is a commercial software

You shall not disclose such Confidential Information and shall use

it only in accordance with the terms of the license agreement

www.tcoproject.com

www.lblloadbalancer.com

mailto:info@tcoproject.com

LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

</copyright>

<dnsmanager>

Path assoluto contenente la zona del dns

<params

frequency=”60000″

templateDir=”lib/templateDNSManager”

templateSerialWithDate=”true”

reloadCommand=”C:/TCOProject/bin/BIND/bin/rndc reload”

sysCommandRemoteURL=”http://localhost:5992/SysCommand”>

</params>

<zone enable=”true”

namespaceFile=”C:/TCOProject/bin/BIND/etc/zones/local/tcoproject.dev.db”

namespaceTemplateFile=”tcoproject.dev.db.template”

namespaceReverseFile=”C:/TCOProject/bin/BIND/etc/zones/local/rev.43.168.192.in-addr.arpa”

namespaceReverseTemplateFile=”rev.43.168.192.in-addr.arpa.template”>

<namespace enable=”true”

address=”192.168.43.136″ port=”80″ uriPath=”/HealthCheck” SSL=”false”

namespace=”www IN A 192.168.43.136″

namespaceReverse=”136 PTR www.tcoproject.dev.”/>

<namespace enable=”true”

address=”192.168.43.138″ port=”80″ uriPath=”/HealthCheck” SSL=”false”

namespace=”www IN A 192.168.43.138″

namespaceReverse=”138 PTR www.tcoproject.dev.”/>

</zone>

<sysobserver>

</sysobserver>

</dnsmanager>

</serviceconf>

MS DNS: Verifica template in (LBL_HOME)/lib/templateDNSManager/

Nella directory (LBL_HOME)/lib/templateDNSManager/ sono contenuti i file per la costruzione dinamica delle zone o degli script di imnpostazione. Nello specifico vengono distribuiti due file di esempio in modalità di script template:

  • www.dev.db.template
  • empty.template

Questi file contengono

(LBL_HOME)/lib/templateDNSManager/twww.dev.db.template

@ECHO OFF

REM LBL(tm) LoadBalancer

REM

REM This is a commercial software

REM You shall not disclose such Confidential Information and shall use

REM it only in accordance with the terms of the license agreement

REM

REM www.tcoproject.com

REM www.lblloadbalancer.com

REM mailto:info@tcoproject.com

REM

REM LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

REM LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

REM Template file LBL(r)DNSManager

%namespaces%

exit 0

(LBL_HOME)/lib/templateDNSManager/empty.template

@ECHO OFF

REM LBL(tm) LoadBalancer

REM

REM This is a commercial software

REM You shall not disclose such Confidential Information and shall use

REM it only in accordance with the terms of the license agreement

REM

REM www.tcoproject.com

REM www.lblloadbalancer.com

REM mailto:info@tcoproject.com

REM

REM LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

REM LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

exit 0

Per il DNS di Microsoft le impostazioni dei due template distribuiti sono relativi a due batch file script che verranno popolati in relazione alle necessità di associazione nome-dominio<>indirizzi. Il file (LBL_HOME)/lib/templateDNSManager/twww.dev.db.template contiene al suo interno il TAG “%namespaces%” che verrà popolato con il comando relativo al namespace da gestire. Il secondo file (LBL_HOME)/lib/templateDNSManager/empty.template è invece un batch file di appoggio in questo caso (not operation). Anche questo secondo file è comunque necessario anche se in questo caso non produce nessuna operazione.

ATTENZIONE

I file di template presenti in questa directory sono continuamente verificati da LBL®DNS & Proxy Manager una volta avviato.

Ad ogni modifica di questi file verranno ricaricate automaticamente le zone del DNS. Si consiglia di tenerne una copia sorgente in altra directory e una volta ultimate le modifiche spostarle in questa zona di produzione.

MS DNS: Configurazione (LBL_HOME)/lib/confDNSManager/dnsmanager.xml

Il file di configurazione dnsmanager.xml contiene tutte le informazioni per popolare dinamicamente le zone del DNS completando i template file ed in questo caso producendo dei batch file di comando.

Il file è formato da due paragrafi; il primo <params> descrive le variabili generali mentre il secondo ,<zone> che può essere ripetuto più volte, definisce le zone del dns. All’interno del secondo paragrafo <zone> vengono definiti gli spazi dei nomi e le relative condizioni di verifica (HealthCheck) della “vitalità dei servizi” <namespace>.

<serviceconf>

<copyright>

</copyright>

<dnsmanager>

<params>

</params>

<zone>

<namespace>

<condition>

</condition>

</namespace>

</zone>

</dnsmanager>

</serviceconf>

Per una completa trattazione dei singoli parametri si rimanda al documento LBL®A.A.I. Reference Guide.

Nel nostro caso andremo a popolare il file di esempio messo a disposizione della distribuzione e di seguito riportato.

File di configurazione dnsmanager.xml compreso nella distribuzione:

<?xml version=”1.0″ encoding=”windows-1252″?>

<serviceconf>

<copyright>

LBL(tm) LoadBalancer

This is a commercial software

You shall not disclose such Confidential Information and shall use

it only in accordance with the terms of the license agreement

www.tcoproject.com

www.lblloadbalancer.com

mailto:info@tcoproject.com

LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

</copyright>

<dnsmanager>

<params

frequency=”60000″

templateDir=”lib/templateDNSManager”

templateSerialWithDate=”true”

reloadCommand=”____reload_cmd_with_absolute_address____es.:C:/work1/bin/named/bin/rndc reload”

sysCommandRemoteURL=”http://localhost:5992/SysCommand”>

</params>

<zone enable=”true”

namespaceFile=”__________________es.:C:\work1\bin/named/etc/zones/local/tcoproject.dev.db”

namespaceTemplateFile=”__________es.:tcoproject.dev.db.template”

namespaceReverseFile=”___________es.:C:/work1/bin/named/etc/zones/local/rev.43.168.192.in-addr.arpa”

namespaceReverseTemplateFile=”___es.:rev.43.168.192.in-addr.arpa.template”>

<namespace enable=”true”

address=”_______________es.:192.168.43.136″ port=”80″ uriPath=”/HealthCheck” SSL=”false”

namespace=”_____________es.:www IN A 192.168.43.136″

namespaceReverse=”______es.:136 PTR www.tcoproject.dev.”/>

<namespace enable=”true”

address=”_______________es.:192.168.43.138″ port=”80″ uriPath=”/HealthCheck” SSL=”false”

namespace=”_____________es.:www IN A 192.168.43.138″

namespaceReverse=”______es.:138 PTR www.tcoproject.dev.”/>

</zone>

<sysobserver>

</sysobserver>

</dnsmanager>

</serviceconf>

In blue sono evidenziati i paragrafi, in verde i nomi dei parametri, in rosso i valori dei parametri che normalmente restano invariati mentre in nero sono rimasti i valori da completare con le informazioni del nostro progetto. Nel caso del DNS di Microsoft le informazioni che andremo ad inserire sono relative ai comandi di inserimento e cancellazione dei nomi host attraverso il comando dnscmd.exe.

Nel paragrafo <params>

  • reloadCommand deve essere completato con il valore del comando da eseguire per ricaricare le zone nel DNS. Il comando deve essere lo stesso utilizzato per la prova manuale. E’ consigliabile indicare il path assoluto del comando in modo da essere esenti da problemi a seguito di modifiche all’environment successive all’installazione che ne potrebbero compromettere il funzionamento. Nel caso specifico, MS DNS, sarà il comando risultante dall’elaborazione Nel nostro esempio:

    C:\work1\bin\TCOProject\LBLLoadBalancer_monitor_007_000_000RC002\lib\scriptDNSManager\reloadMSDns.bat

    Nel paragrafo <zone>

  • namespaceFile è il file batch risultante dalla rilevazione dei servizi attivi e la loro mappatura a livello di “domain” nel DNS. Questo valore corrisponde in questo caso al reloadCommand visto in precedenza. Nel nostro esempio:

    C:\work1\bin\TCOProject\LBLLoadBalancer_monitor_007_000_000RC002\lib\scriptDNSManager\reloadMSDns.bat

  • namespaceTemplateFile è il template file che serve come traccia per la generazione dinamica delle associazioni nome<>indirizzi. Può essere completato sia con un path assoluto oppure con un path relativo al parametro templateDir=”lib/templateDNSManager” nel paragrafo <params>. Nel nostro esempio:

    www.dev.db.template

    Il valore risultante sommando il contenuto del parametro templateDir sarà quindi:

    “(LBL_HOME)/lib/templateDNSManager/www.dev.db.template

    e cioè il template file visto precedentemente.

  • namespaceReverseFile è il file batch per popolare le zone per la risoluzione inversa da indirizzo a nome dominio. Questo valore nel nostro caso deve essere completato con il path assoluto e il nome del file empty.bat. Questo file non viene in questo caso preso in considerazione. Nel nostro esempio:


C:\work1\bin\TCOProject\LBLLoadBalancer_monitor_007_000_000RC002\lib\scriptDNSManager\empty.bat”.

  • namespaceReverseTemplateFile è il template file che serve come traccia per la generazione dinamica delle associazioni indirizzi<>nomi. Può essere completato sia con un path assoluto oppure con un path relativo al parametro templateDir=”lib/templateDNSManager”. Nel nostro esempio:

empty.template“.

Il valore risultante sommando il contenuto del parametro templateDir sarà quindi:

“(LBL_HOME)/lib/templateDNSManager/empty.template

e cioè il template file visto precedentemente.

N.B.: In questo caso non viene preso in considerazione.

Nel 1° paragrafo <namespace>

  • address è l’indirizzo da sottoporre ad HealthCheck per determinare l’attività e quindi la disponibilità di questo name space. Gli altri parametri, port, uriPath e SSL sono intuitivi. Se questo indirizzo/port/uriPath risulterà attivo il namespace descritto nei parametri di seguito entrerà nel nuovo zone file. Nel nostro esempio verrà popolato con l’indirizzo a cui afferiscono i servizi del NODO A. “192.168.43.136
  • namespace è il frammento del file batch per il popolamento dei nomi host da inserire nel template file nel caso il test di HealthCheck vada a buon fine. Nel nostro esempio:

    dnscmd /recordadd tcoproject.dev www /CreatePTR 10 A 192.168.43.136

    NOTA: Il parametro /CreatePTR è accettato solo dalla release Windows 2008 Server. Nelle versioni precedenti deve essere tolto.

    NOTA1: Il valore 10 dopo il parametro /CreatePTR è il TTL per questo record. Si consiglia di non scendere sotto i 5 secondi.

  • namespaceInactive è il frammento del file batch per il popolamento dei nomi host da inserire nel template file nel caso il test di HealthCheck NON vada a buon fine. Nel nostro esempio:

    dnscmd /recorddelete tcoproject.dev www A 192.168.43.136 /F

  • namespaceReverse nel nostro esempio va eliminato da dnsmanager.xml in quanto o si è provveduto manualmente a inserire tutte le risoluzioni inverse oppure, da Windows 2008, il comando di popolamento delle associazioni mini-domini<>indirizzi genera automaticamente e toglie automaticamente le risoluzioni inverse.

    Nel 2° paragrafo <namespace>

  • address è l’indirizzo da sottoporre ad HealthCheck per determinare l’attività e quindi la disponibilità di questo name space. Gli altri parametri, port, uriPath e SSL sono intuitivi. Se questo indirizzo/port/uriPath risulterà attivo il namespace descritto nei parametri di seguito entrerà nel nuovo zone file. Nel nostro esempio verrà popolato con l’indirizzo a cui afferiscono i servizi del NODO B. “192.168.43.138
  • namespace è il frammento del file batch per il popolamento dei nomi host da inserire nel template file nel caso il test di HealthCheck vada a buon fine. Nel nostro esempio:

    dnscmd /recordadd tcoproject.dev www /CreatePTR 10 A 192.168.43.138

    NOTA: Il parametro /CreatePTR è accettato solo dalla release Windows 2008 Server. Nelle versioni precedenti deve essere tolto.

  • namespaceInactive è il frammento del file batch per il popolamento dei nomi host da inserire nel template file nel caso il test di HealthCheck NON vada a buon fine. Nel nostro esempio:

    dnscmd /recorddelete tcoproject.dev www A 192.168.43.138 /F

  • namespaceReverse nel nostro esempio va eliminato da dnsmanager.xml in quanto o si è provveduto manualmente a inserire tutte le risoluzioni inverse oppure, da Windows 2008, il comando di popolamento delle associazioni mini-domini<>indirizzi genera automaticamente e toglie automaticamente le risoluzioni inverse.


Il file di configurazione risultante deve assomigliare a quello di seguito riportato:

File di configurazione dnsmanager.xml compltetato partendo dal file nella distribuzione:

<?xml version=”1.0″ encoding=”windows-1252″?>

<serviceconf>

<copyright>

LBL(tm) LoadBalancer

This is a commercial software

You shall not disclose such Confidential Information and shall use

it only in accordance with the terms of the license agreement

www.tcoproject.com

www.lblloadbalancer.com

mailto:info@tcoproject.com

LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

</copyright>

<dnsmanager>

<params

frequency=”60000″

templateDir=”lib/templateDNSManager”

templateSerialWithDate=”true”

reloadCommand=”C:\work1\bin\TCOProject\LBLLoadBalancer_monitor_007_000_000RC002\lib\scriptDNSManager\reloadMSDns.bat”

sysCommandRemoteURL=”https://localhost:5992/SysCommand”>

</params>

<zone enable=”true”

namespaceFile=”C:\work1\bin\TCOProject\LBLLoadBalancer_monitor_007_000_000RC002\lib\scriptDNSManager\reloadMSDns.bat”

namespaceTemplateFile=”www.dev.db.template”

namespaceReverseFile=”C:\work1\bin\TCOProject\LBLLoadBalancer_monitor_007_000_000RC002\lib\scriptDNSManager\empty.bat”

namespaceReverseTemplateFile=”empty.template”>

<namespace enable=”true”

address=”192.168.43.136″ port=”8080″ uriPath=”/” SSL=”false”

namespace=”dnscmd /recordadd tcoproject.dev www /CreatePTR 10 A 192.168.43.136″

namespaceInactive=”dnscmd /recorddelete tcoproject.dev www A 192.168.43.136 /F”/>

<namespace enable=”true”

address=”192.168.43.138″ port=”8181″ uriPath=”/” SSL=”false”

namespace=”dnscmd /recordadd tcoproject.dev www /CreatePTR 10 A 192.168.43.138″

namespaceInactive=”dnscmd /recorddelete tcoproject.dev www A 192.168.43.138 /F”/>

</zone>

<sysobserver>

<service name=”syslog” id=”syslogdnsmanager”/>

</sysobserver>

</dnsmanager>

</serviceconf>

BIND: Start LBL®DNSManager


Lo start di LBL®DNS & Proxy Manager sarà simile allo start degli altri processi attraverso lo start automatico di LBL®Monitor oppure attraverso la sua WebConsole.

Start

All’avvio del servizio andare a verificare il log file per constatare l’avvenuta rigenerazione delle zone del DNS e l’effettivo reload ad opera del comando rndc.

Frammento del file di log con la registrazione dell’evento di rigenerazione e caricamento dinamico del DNS con la nuova situazione:

|WARNING|1.6.0_16|UserService.dnsmanager|msw2000Srv000mg|1269171902765|20100321-12:45:02|Namespaces zone files Regeneration…||

|WARNING|1.6.0_16|UserService.dnsmanager|msw2000Srv000mg|1269171902890|20100321-12:45:02|New Namespace: C:/TCOProject/bin/BIND/etc/zones/local/tcoproject.dev.db from template: C:\\TCOProject\\bin\\LBLLoadBalancer_monitor_007_000_000RC002/lib/templateDNSManager/tcoproject.dev.db.template

; LBL and TCOProject are trademarks of F.Pieretti

;

; THIS IS AN AUTOMATIC GENERATED FILE FROM LBL(r)DNSManager

; DO NOT MODIFY MANUALLY

; LBL(r)Rel.=7.0

; LastUpdate=20100321124502

; TemplateFile=C:\\TCOProject\\bin\\LBLLoadBalancer_monitor_007_000_000RC002/lib/templateDNSManager/tcoproject.dev.db.template

;

; LBL(tm) LoadBalancer

;

; This is a commercial software

;You shall not disclose such Confidential Information and shall use

; it only in accordance with the terms of the license agreement

;

; www.tcoproject.com

; www.lblloadbalancer.com

; mailto:info@tcoproject.com

;

; LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

;LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

; Template file LBL(r)DNSManager

$TTL 3

@ IN SOA ns.tcoproject.dev. hostmaster.tcoproject.dev. (

2010032101 ; serial, todays date + todays serial #

8H ; refresh

30m ; retry

4W ; expire

10) ; minimum

NS ns ; Inet Address of name server

www IN A 192.168.43.136

www IN A 192.168.43.138

New ReverseNamespace: C:/TCOProject/bin/BIND/etc/zones/local/tcoproject.dev.db from template: C:\\TCOProject\\bin\\LBLLoadBalancer_monitor_007_000_000RC002/lib/templateDNSManager/rev.43.168.192.in-addr.arpa.template

; LBL and TCOProject are trademarks of F.Pieretti

;

; THIS IS AN AUTOMATIC GENERATED FILE FROM LBL(r)DNSManager

; DO NOT MODIFY MANUALLY

; LBL(r)Rel.=7.0

; LastUpdate=20100321124502

; TemplateFile=C:\\TCOProject\\bin\\LBLLoadBalancer_monitor_007_000_000RC002/lib/templateDNSManager/rev.43.168.192.in-addr.arpa.template

;

; LBL(tm) LoadBalancer

;

; This is a commercial software

;You shall not disclose such Confidential Information and shall use

; it only in accordance with the terms of the license agreement

;

; www.tcoproject.com

; www.lblloadbalancer.com

; mailto:info@tcoproject.com

;

; LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

;LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

; Template file LBL(r)DNSManager

$TTL 3

@ IN SOA ns.tcoproject.dev. hostmaster.tcoproject.dev. (

2010032101 ; serial, todays date + todays serial #

8H ; refresh

30m ; retry

4W ; expire

10) ; minimum

NS ns.tcoproject.dev.

136 PTR www.tcoproject.dev.

138 PTR www.tcoproject.dev.

||

|WARNING|1.6.0_16|UserService.dnsmanager|msw2000Srv000mg|1269171903000|20100321-12:45:03|Namespaces zone files Regenerated!||

|WARNING|1.6.0_16|UserService.dnsmanager|msw2000Srv000mg|1269171903000|20100321-12:45:03|DNS namespaces zone files realoading…||

|WARNING|1.6.0_16|UserService.dnsmanager|msw2000Srv000mg|1269171904984|20100321-12:45:04|DNS namespaces zone files realoaded!||

In rosso sono evidenziati le indicazioni sia dell’inizio dell’operazione di rigenerazione sia l’avvenuto ricaricamento del DNS con la nuova situazione. Il processo da qui in poi sarà completamente automatico. Il file di log riporterà anche le nuove immagini generate in modo da poter verificare da subito l’effettiva correttezza della parametrizzazione.

BIND: Verifica effettiva modifica dei file di zona

Per verificare l’effettiva modifica dei file di zona a disposizione del DNS posizionarsi sulla directory del DNS contenente le zone. Nel nostro esempio verificare il contenuto dei file che dovrebbe essere stato modificato in:

C:\TCOProject\bin\BIND\etc\zones\local\tcoproject.dev.db

; LBL and TCOProject are trademarks of F.Pieretti

;

; THIS IS AN AUTOMATIC GENERATED FILE FROM LBL(r)DNSManager

; DO NOT MODIFY MANUALLY

; LBL(r)Rel.=6.1

; LastUpdate=20100108134223

; TemplateFile=C:\TCOProject\bin\LBLLoadBalancer_dnsmanager_006_001_000RC012/lib/templateDNSManager/tcoproject.dev.db.template

;

; LBL(tm) LoadBalancer

;

; This is a commercial software

;You shall not disclose such Confidential Information and shall use

; it only in accordance with the terms of the license agreement

;

; www.tcoproject.com

; www.lblloadbalancer.com

; mailto:info@tcoproject.com

;

; LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

;LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

; Template file LBL(r)DNSManager

$TTL 3

@ IN SOA ns.tcoproject.dev. hostmaster.tcoproject.dev. (

2010010803 ; serial, todays date + todays serial #

8H ; refresh

30m ; retry

4W ; expire

10) ; minimum

NS ns ; Inet Address of name server

www IN A 192.168.43.136

www IN A 192.168.43.138

C:\TCOProject\bin\BIND\etc\zones\local\rev.43.168.192.in-addr.arpa

; LBL and TCOProject are trademarks of F.Pieretti

;

; THIS IS AN AUTOMATIC GENERATED FILE FROM LBL(r)DNSManager

; DO NOT MODIFY MANUALLY

; LBL(r)Rel.=6.1

; LastUpdate=20100108134223

; TemplateFile=C:\TCOProject\bin\LBLLoadBalancer_dnsmanager_006_001_000RC012/lib/templateDNSManager/rev.43.168.192.in-addr.arpa.template

;

; LBL(tm) LoadBalancer

;

; This is a commercial software

;You shall not disclose such Confidential Information and shall use

; it only in accordance with the terms of the license agreement

;

; www.tcoproject.com

; www.lblloadbalancer.com

; mailto:info@tcoproject.com

;

; LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

;LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

; Template file LBL(r)DNSManager

$TTL 3

@ IN SOA ns.tcoproject.dev. hostmaster.tcoproject.dev. (

2010010803 ; serial, todays date + todays serial #

8H ; refresh

30m ; retry

4W ; expire

10) ; minimum

NS ns.tcoproject.dev.

136 PTR www.tcoproject.dev.

138 PTR www.tcoproject.dev.

MS DNS: Start LBL®DNSManager

Lo start di LBL®DNS & Proxy Manager sarà simile allo start degli altri processi attraverso lo start automatico di LBL®Monitor oppure attraverso la sua WebConsole.

All’avvio del servizio andare a verificare il log file per constatare l’avvenuta rigenerazione delle zone del DNS e l’effettivo reload ad opera del comando rndc.

Start

Frammento del file di log con la registrazione dell’evento di rigenerazione e caricamento dinamico del DNS con la nuova situazione:

|WARNING|1.6.0_11|UserService.dnsmanager|WIN-UF4APZRA30L|1269171351759|20100321-12:35:51|Namespaces zone files Regeneration…||

|WARNING|1.6.0_11|UserService.dnsmanager|WIN-UF4APZRA30L|1269171351779|20100321-12:35:51|New Namespace: C:\\work1\\bin\\TCOProject\\LBLLoadBalancer_monitor_007_000_000RC002\\lib\\scriptDNSManager\\reloadMSDns.bat from template: C:\\work1\\bin\\TCOProject\\LBLLoadBalancer_monitor_007_000_000RC002/lib/templateDNSManager/www.dev.db.template

@ECHO OFF

REM LBL(tm) LoadBalancer

REM

REM This is a commercial software

REM You shall not disclose such Confidential Information and shall use

REM it only in accordance with the terms of the license agreement

REM

REM www.tcoproject.com

REM www.lblloadbalancer.com

REM mailto:info@tcoproject.com

REM

REM LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

REM LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

REM Template file LBL(r)DNSManager

dnscmd /recordadd tcoproject.dev www /CreatePTR 10 A 192.168.43.136

dnscmd /recordadd tcoproject.dev www /CreatePTR 10 A 192.168.43.138

exit 0

New ReverseNamespace: C:\\work1\\bin\\TCOProject\\LBLLoadBalancer_monitor_007_000_000RC002\\lib\\scriptDNSManager\\reloadMSDns.bat from template: C:\\work1\\bin\\TCOProject\\LBLLoadBalancer_monitor_007_000_000RC002/lib/templateDNSManager/empty.template

@ECHO OFF

REM LBL(tm) LoadBalancer

REM

REM This is a commercial software

REM You shall not disclose such Confidential Information and shall use

REM it only in accordance with the terms of the license agreement

REM

REM www.tcoproject.com

REM www.lblloadbalancer.com

REM mailto:info@tcoproject.com

REM

REM LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

REM LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

exit 0

||

|WARNING|1.6.0_11|UserService.dnsmanager|WIN-UF4APZRA30L|1269171351779|20100321-12:35:51|Namespaces zone files Regenerated!||

|WARNING|1.6.0_11|UserService.dnsmanager|WIN-UF4APZRA30L|1269171351789|20100321-12:35:51|DNS namespaces zone files realoading…||

|WARNING|1.6.0_11|UserService.dnsmanager|WIN-UF4APZRA30L|1269171354366|20100321-12:35:54|DNS namespaces zone files realoaded!||

In rosso sono evidenziati le indicazioni sia dell’inizio dell’operazione di rigenerazione sia l’avvenuto ricaricamento del DNS con la nuova situazione. Il processo da qui in poi sarà completamente automatico. Il file di log riporterà anche le nuove immagini generate in modo da poter verificare da subito l’effettiva correttezza della parametrizzazione.

BIND: Verifica effettiva modifica dei file di zona

Per verificare l’effettiva modifica dei file di zona a disposizione del DNS posizionarsi sulla directory del DNS contenente le zone. Nel nostro esempio verificare il contenuto dei file che dovrebbe essere stato modificato in:

C:\TCOProject\bin\BIND\etc\zones\local\tcoproject.dev.db

; LBL and TCOProject are trademarks of F.Pieretti

;

; THIS IS AN AUTOMATIC GENERATED FILE FROM LBL(r)DNSManager

; DO NOT MODIFY MANUALLY

; LBL(r)Rel.=6.1

; LastUpdate=20100108134223

; TemplateFile=C:\TCOProject\bin\LBLLoadBalancer_dnsmanager_006_001_000RC012/lib/templateDNSManager/tcoproject.dev.db.template

;

; LBL(tm) LoadBalancer

;

; This is a commercial software

;You shall not disclose such Confidential Information and shall use

; it only in accordance with the terms of the license agreement

;

; www.tcoproject.com

; www.lblloadbalancer.com

; mailto:info@tcoproject.com

;

; LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

;LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

; Template file LBL(r)DNSManager

$TTL 3

@ IN SOA ns.tcoproject.dev. hostmaster.tcoproject.dev. (

2010010803 ; serial, todays date + todays serial #

8H ; refresh

30m ; retry

4W ; expire

10) ; minimum

NS ns ; Inet Address of name server

www IN A 192.168.43.136

www IN A 192.168.43.138

C:\TCOProject\bin\BIND\etc\zones\local\rev.43.168.192.in-addr.arpa

; LBL and TCOProject are trademarks of F.Pieretti

;

; THIS IS AN AUTOMATIC GENERATED FILE FROM LBL(r)DNSManager

; DO NOT MODIFY MANUALLY

; LBL(r)Rel.=6.1

; LastUpdate=20100108134223

; TemplateFile=C:\TCOProject\bin\LBLLoadBalancer_dnsmanager_006_001_000RC012/lib/templateDNSManager/rev.43.168.192.in-addr.arpa.template

;

; LBL(tm) LoadBalancer

;

; This is a commercial software

;You shall not disclose such Confidential Information and shall use

; it only in accordance with the terms of the license agreement

;

; www.tcoproject.com

; www.lblloadbalancer.com

; mailto:info@tcoproject.com

;

; LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

;LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

; Template file LBL(r)DNSManager

$TTL 3

@ IN SOA ns.tcoproject.dev. hostmaster.tcoproject.dev. (

2010010803 ; serial, todays date + todays serial #

8H ; refresh

30m ; retry

4W ; expire

10) ; minimum

NS ns.tcoproject.dev.

136 PTR www.tcoproject.dev.

138 PTR www.tcoproject.dev.

Configurazione (LBL_HOME)/lib/confMonitor/A05_LBLGoDNSManager.xml

Questo file è già configurato per intero, l’unica avvertenza è quella di modificare il parametro di start da manual in automatic per fare in modo che all’avvio di LBL®Monitor questi venga automaticamente avviato. Se il processo era già stato avviato questi verrà fermato e quindi riavviato.

Frammento del file (LBL_HOME)/lib/confMonitor/A05_LBLGoDNSManager.xml

</copyright>

<A05_LBLGoDNSManager>

<!–

start: automatic (default), manual

–>

<process enable=”true”

description=”LBL(r)LoadBalancer DNSManager”

start=”automatic

numberTryStartOnFailure=”-1″

waitBeforeKill=”115000″

sysCommand=”tr…

BIND: Modifica manuale del Serial Number

Il serial number è un elemento importante perché permette ad eventuali DNS secondari di verificare l’allineamento delle modifiche. LBL®DNS & Proxy Manager gestisce automaticamente il suo incremento. L’incremento può essere rappresentato da un progressivo relativo alla data espressa in YYYYMMDDss (dove ss è un numero compreso tra 01 e 99) oppure con un progressivo compreso tra +1 e +2^32. Da raccomandazione (RFC) entrambi questi comportamenti sono validi anche se il più diffuso è sicuramente YYYYMMDDss. IN LBL®DNS & Proxy Manager questo comportamento è influenzato dal parametro templateSerialWithDate nel file dnsmanager.xml al paragrafo <params>. Per default questo parametro è impostato a templateSerialWithDate=”true”.

In alcune circostanze può nascere la necessità di dover impostare un determinato Serial Number. Per effettuare questa operazione è sufficiente eseguire le seguenti operazioni.

Per ogni template il progressivo del Serial Number viene mantenuto su un file nella stessa directory dei template e prende il nome dal template al quale viene aggiunta una estensione “_Serial”. Nel nostro esempio i file risultanti saranno quindi:

  • (LBL_HOME)/lib/templateDNSManager/tcoproject.dev.db.template_Serial
  • (LBL_HOME)/lib/templateDNSManager/rev.43.168.192.in-addr.arpa.template_Serial

Questi file contengono l’ultimo progressivo e quindi nel nostro caso entrambi conterranno il valore: 2010010803 dove 03 è il progressivo.

Per modificare il progressivo è sufficiente cambiare questo valore con un editor .

da 2010010803

a 2010010809

LBL®DNS & Proxy Manager controllando periodicamente lo stato dei file si accorgerà della modifica e ricaricherà i nuovi zone file nel DNS con il nuovo Serial Number 2010010810.

Scenari diversi: Business Continuity, Disaster Recovery

LBL®DNS & Proxy Manager può essere impiegato efficacemente per attività che comprendono processi di Business Continuity e Disaster Recovery. E’ infatti possibile condizionare l’attribuzione di un namespace in dipendenza dell’esistenza di altri servizi. In altre parole se il servizio principale è attivo non verrà popolato il file zone con l’indirizzo del secondario. Questa funzionalità permette di costruire rapidamente un’infrastruttura di BC o DR lasciando a LBL®DNS & Proxy Manager il compito di attribuire l’operatività di un sito e quindi facendo concentrare il personale impegnato nello switch sulle attività relative all’attivazione applicativa. Una volta che l’operatività sarà ripristinata in uno dei due siti LBL®DNS & Proxy Manager effettuerà l’attribuzione nome<>indirizzo e indirizzo<>nome automaticamente.

Per impostare le condizioni è molto semplice ed è sufficiente indicare sul paragrafo <namespace> le condizioni di up di un indirizzo. Di seguito un frammento del file dnsmanager.xml che condiziona l’up dell’indirizzo 192.168.43.136 alla presenza di attività presenti agli indirizzi 192.168.43.138 e 192.168.43.144. Se anche solo uno degli indirizzi parametrizzati su condition sono attivi l’indirizzo 192.168.43.136 non verrà popolato nella zona del DNS.

<zone enable=”true”

namespaceFile=”C:/work1/bin/named/etc/zones/local/tcoproject.dev.db”

namespaceTemplateFile=”tcoproject.dev.db.template”

namespaceReverseFile=”C:/work1/bin/named/etc/zones/local/rev.43.168.192.in-addr.arpa”

namespaceReverseTemplateFile=”rev.43.168.192.in-addr.arpa.template”>

<namespace enable=”true”

address=”192.168.43.136″ port=”80″ uriPath=”/HealthCheck” SSL=”false”

namespace=”www IN A 192.168.43.136″

namespaceReverse=”136 PTR www.tcoproject.dev.”>

<condition enable=”true” address=”192.168.43.138″ port=”80″ uriPath=”/HealthCheck” SSL=”false”/>

<condition enable=”true” address=”192.168.43.144″ port=”80″ uriPath=”/HealthCheck” SSL=”false”/>

</namespace>

<namespace enable=”true”

address=”192.168.43.138″ port=”80″ uriPath=”/HealthCheck” SSL=”false”

namespace=”www IN A 192.168.43.138″

namespaceReverse=”138 PTR www.tcoproject.dev.”>

<condition enable=”true” address=”192.168.43.136″ port=”80″ uriPath=”/HealthCheck” SSL=”false”/>

<condition enable=”true” address=”192.168.43.144″ port=”80″ uriPath=”/HealthCheck” SSL=”false”/>

</namespace>

BIND: Negative cache prevention

LBL®DNS & Proxy Manager per evitare Negative-cache nei client è stato studiato per non impostare mai un’attribuzione vuota nome<>indirizzo o indirizzo<>nome. Nel caso nessuno dei siti/nodi siano attivi LBL®DNS & Proxy Manager attribuisce in automatico il primo namespace relativo al paragrafo <zone> cui appartiene.

In questo caso ad esempio se tutti i servizi fossero non in attività comunque il zone file verrebbe popolato con il primo namespace: www IN A 192.168.43.136 ed il primo namespace-reverse: 136 PTR www.tcoproject.dev.

<zone enable=”true”

namespaceFile=”C:/work1/bin/named/etc/zones/local/tcoproject.dev.db”

namespaceTemplateFile=”tcoproject.dev.db.template”

namespaceReverseFile=”C:/work1/bin/named/etc/zones/local/rev.43.168.192.in-addr.arpa”

namespaceReverseTemplateFile=”rev.43.168.192.in-addr.arpa.template”>

<namespace enable=”true”

address=”192.168.43.136″ port=”80″ uriPath=”/HealthCheck” SSL=”false”

namespace=”www IN A 192.168.43.136″

namespaceReverse=”136 PTR www.tcoproject.dev.”>

<condition enable=”true” address=”192.168.43.138″ port=”80″ uriPath=”/HealthCheck” SSL=”false”/>

<condition enable=”true” address=”192.168.43.144″ port=”80″ uriPath=”/HealthCheck” SSL=”false”/>

</namespace>

<namespace enable=”true”

address=”192.168.43.138″ port=”80″ uriPath=”/HealthCheck” SSL=”false”

namespace=”www IN A 192.168.43.138″

namespaceReverse=”138 PTR www.tcoproject.dev.”>

<condition enable=”true” address=”192.168.43.136″ port=”80″ uriPath=”/HealthCheck” SSL=”false”/>

<condition enable=”true” address=”192.168.43.144″ port=”80″ uriPath=”/HealthCheck” SSL=”false”/>

</namespace>

E’ possibile anche indicare un ulteriore indirizzo nel caso entrambi i siti non siano disponibili. In questo caso potrà essere predisposta una pagina di cortesia per gli utenti. Questo indirizzo non è sottoposto ad ulteriore HealthCheck e quindi verrà comuque proposto come valido anche se inesistente evitando negative-cache. Per impostare questi valori è sufficiente nel paragrafo <zone> valorizzare i parametri namespaceNegativeCachePrevention e namespaceReverseNegativeCachePrevention come nel frammento di dnsmanager.xml di seguito:

<zone enable=”true”

namespaceFile=”C:/work1/bin/named/etc/zones/local/tcoproject.dev.db”

namespaceTemplateFile=”tcoproject.dev.db.template”

namespaceReverseFile=”C:/work1/bin/named/etc/zones/local/rev.43.168.192.in-addr.arpa”

namespaceReverseTemplateFile=”rev.43.168.192.in-addr.arpa.template”

namespaceNegativeCachePrevention=”www IN A 192.168.43.144″

namespaceReverseNegativeCachePrevention=”144 PTR www.tcoproject.dev.”>

<namespace enable=”true”

address=”192.168.43.136″ port=”80″ uriPath=”/HealthCheck” SSL=”false”

namespace=”www IN A 192.168.43.136″

namespaceReverse=”136 PTR www.tcoproject.dev.”>

<condition enable=”true” address=”192.168.43.138″ port=”80″ uriPath=”/HealthCheck” SSL=”false”/>

<condition enable=”true” address=”192.168.43.144″ port=”80″ uriPath=”/HealthCheck” SSL=”false”/>

</namespace>

<namespace enable=”true”

address=”192.168.43.138″ port=”80″ uriPath=”/HealthCheck” SSL=”false”

namespace=”www IN A 192.168.43.138″

namespaceReverse=”138 PTR www.tcoproject.dev.”>

<condition enable=”true” address=”192.168.43.136″ port=”80″ uriPath=”/HealthCheck” SSL=”false”/>

<condition enable=”true” address=”192.168.43.144″ port=”80″ uriPath=”/HealthCheck” SSL=”false”/>

</namespace>

In questo caso la mancanza di attività sui siti indirizzati con 192.168.43.136 e 192.168.43.138 il DNS alla richiesta del nome www.tcoproject.dev risponderà con l’indirizzo 192.168.43.144. Anche ad un successivo riavvio di uno dei due siti fino a che l’HealtCheck sull’indirizzo 192.168.43.144 risulterà attivo non verranno caricate le zone sul DNS con gli indirizzi 192.168.43.136 o 138.

E’ bene ricordare che i client sono fortemente influenzati dalla loro cache e che una volta ripristinato un sito è consigliato togliere completamente la disponibilità dell’indirizzo inserito in namespaceNegativeCachePrevention e namespaceReverseNegativeCachePrevention. Questo risultato si può ottenere facilmente attraverso le funzionalità di LBL®ADC oppure attraverso il servizio LBL®IP Network Card Redundancy presente in ogni distribuzione LBL®. In altre configurazioni dove non sono previsti LBL®ADC o il servizio LBL®IP Network Card Redundancy è consigliata l’integrazione alle procedure esistenti.

MS DNS: Negative cache prevention

LBL®DNS & Proxy Manager per evitare Negative-cache nei client è stato studiato per non impostare mai un’attribuzione vuota nome<>indirizzo o indirizzo<>nome. Nel caso nessuno dei siti/nodi siano attivi LBL®DNS & Proxy Manager attribuisce in automatico il primo namespace relativo al paragrafo <zone> cui appartiene.

In questo caso ad esempio se tutti i servizi fossero non in attività comunque il zone file verrebbe popolato con il primo namespace: dnscmd /recordadd tcoproject.dev www /CreatePTR 10 A 192.168.43.136.

templateSerialWithDate=”true”

reloadCommand=”C:\work1\bin\TCOProject\LBLLoadBalancer_monitor_007_000_000RC002\lib\scriptDNSManager\reloadMSDns.bat”

sysCommandRemoteURL=”https://localhost:5992/SysCommand”>

</params>

<zone enable=”true”

namespaceFile=”C:\work1\bin\TCOProject\LBLLoadBalancer_monitor_007_000_000RC002\lib\scriptDNSManager\reloadMSDns.bat”

namespaceTemplateFile=”www.dev.db.template”

namespaceReverseFile=”C:\work1\bin\TCOProject\LBLLoadBalancer_monitor_007_000_000RC002\lib\scriptDNSManager\empty.bat”

namespaceReverseTemplateFile=”empty.template”>

<namespace enable=”true”

address=”192.168.43.136″ port=”8080″ uriPath=”/” SSL=”false”

namespace=”dnscmd /recordadd tcoproject.dev www /CreatePTR 10 A 192.168.43.136″

namespaceInactive=”dnscmd /recorddelete tcoproject.dev www A 192.168.43.136 /F”/>

<namespace enable=”true”

address=”192.168.43.138″ port=”8181″ uriPath=”/” SSL=”false”

namespace=”dnscmd /recordadd tcoproject.dev www /CreatePTR 10 A 192.168.43.138″

namespaceInactive=”dnscmd /recorddelete tcoproject.dev www A 192.168.43.138 /F”/>

</zone>

<sysobserver>

E’ possibile anche indicare un ulteriore indirizzo nel caso entrambi i siti non siano disponibili. In questo caso potrà essere predisposta una pagina di cortesia per gli utenti. Questo indirizzo non è sottoposto ad ulteriore HealthCheck e quindi verrà comuque proposto come valido anche se inesistente evitando negative-cache. Per impostare questi valori è sufficiente nel paragrafo <zone> valorizzare i parametri namespaceNegativeCachePrevention e namespaceReverseNegativeCachePrevention come nel frammento di dnsmanager.xml di seguito:

templateSerialWithDate=”true”

reloadCommand=”C:\work1\bin\TCOProject\LBLLoadBalancer_monitor_007_000_000RC002\lib\scriptDNSManager\reloadMSDns.bat”

sysCommandRemoteURL=”https://localhost:5992/SysCommand”>

</params>

<zone enable=”true”

namespaceFile=”C:\work1\bin\TCOProject\LBLLoadBalancer_monitor_007_000_000RC002\lib\scriptDNSManager\reloadMSDns.bat”

namespaceTemplateFile=”www.dev.db.template”

namespaceReverseFile=”C:\work1\bin\TCOProject\LBLLoadBalancer_monitor_007_000_000RC002\lib\scriptDNSManager\empty.bat”

namespaceReverseTemplateFile=”empty.template”

namespaceNegativeCachePrevention=”dnscmd /recordadd tcoproject.dev www /CreatePTR 10 A 192.168.43.144″>

<namespace enable=”true”

address=”192.168.43.136″ port=”8080″ uriPath=”/” SSL=”false”

namespace=”dnscmd /recordadd tcoproject.dev www /CreatePTR 10 A 192.168.43.136″

namespaceInactive=”dnscmd /recorddelete tcoproject.dev www A 192.168.43.136 /F”/>

<namespace enable=”true”

address=”192.168.43.138″ port=”8181″ uriPath=”/” SSL=”false”

namespace=”dnscmd /recordadd tcoproject.dev www /CreatePTR 10 A 192.168.43.138″

namespaceInactive=”dnscmd /recorddelete tcoproject.dev www A 192.168.43.138 /F”/>

</zone>

<sysobserver>

In questo caso la mancanza di attività sui siti indirizzati con 192.168.43.136 e 192.168.43.138 il DNS alla richiesta del nome www.tcoproject.dev risponderà con l’indirizzo 192.168.43.144. Anche ad un successivo riavvio di uno dei due siti fino a che l’HealtCheck sull’indirizzo 192.168.43.144 risulterà attivo non verranno caricate le zone sul DNS con gli indirizzi 192.168.43.136 o 138.

E’ bene ricordare che i client sono fortemente influenzati dalla loro cache e che una volta ripristinato un sito è consigliato togliere completamente la disponibilità dell’indirizzo inserito in namespaceNegativeCachePrevention e namespaceReverseNegativeCachePrevention. Questo risultato si può ottenere facilmente attraverso le funzionalità di LBL®ADC oppure attraverso il servizio LBL®IP Network Card Redundancy presente in ogni distribuzione LBL®. In altre configurazioni dove non sono previsti LBL®ADC o il servizio LBL®IP Network Card Redundancy è consigliata l’integrazione alle procedure esistenti.

Check release and updates

Allo start dei processi LBL®A.A.I. verifica la release nel sito www.tcoproject.com. I dati spediti verso il sito non contengono dati sensibili ma riportano solamente:

rel=99.99.99; license:127123163*****; IP=99999999; RL=9

rel: E’ la release e la versione del prodotto

license: è la parte distintiva della licenza in utilizzo

IP: è un digest di controllo

RL: è il Run Level LBL®

Il controllo di release è disattivabile attraverso il parametro “-ncu” allo startup dei processi come evidenziato di seguito nel profilo di lancio. Nel caso venga disattivato o tale messaggio non possa pervenire a www.tcoproject.com TCOGROUP SRL non potrà fornire indicazioni proattive di patch o segnalazioni urgenti relative alla sicurezza.

es.:

<process enable=”true”

description=”LBL(r)LoadBalancer Standard Edition”

start=”automatic”

numberTryStartOnFailure=”-1″

waitBeforeKill=”80000″

waitBeforeKillOnFailure=”10000″

managementPort=”5900″

confDir=”lib/conf”

runLevel=”2″>

<start osName=”Windows”>

<env>CLASSPATH=lib;lib\LBLLoadBalancer.jar</env>

<workingDir></workingDir>

<exec>java -Xrs -server -XX:-UseGCOverheadLimit -Xss256k

-XX:+AggressiveHeap

%LBL_EXEC_DEFINES%

-DLBL_INTERACTIVE_CMD=true

loadbalancer.starter.LBLServerStarterApp -ncu </exec>

<logDirFiles>lib\logs</logDirFiles>

</start>

Per disattivare la verifica della release anche allo start di LBL Monitor impostare il parametro -ncu (NoCheckUpdate), anche allo start iniziale (bacth o service).

es. go.bat:

PATH=”%LBL_JAVA_HOME%\bin”;%PATH%

cd /d “%LBL_HOME%”

set WHAT=loadbalancer.starter.LBLServerStarterApp

set CLASSPATH=lib;lib\LBLLoadBalancer.jar;lib\extLib\mail.jar

java -server -XX:-UseGCOverheadLimit -Xms256m -Xmx256m -DLBL_RUNLEVEL=0 -DLBL_MONITOR=true -DLBL_INTERACTIVE_CMD=true %WHAT% -nc

Sei interessato alle nostre soluzioni?