Messaggio di errore “Target Principal Name is Incorrect” quando si replicano manualmente i dati tra controller di dominio

Capita a volte che quando si utilizza lo snap-in Siti e servizi di Active Directory per replicare manualmente i dati tra controller di dominio di Windows 2000, è possibile che venga visualizzato un messaggio di errore analogo a uno dei seguenti:

Target Principal Name is Incorrect

in Italiano Nome principale di destinazione non corretto

Oppure

Access Denied

È inoltre possibile che nel registro eventi di sistema vengano registrati messaggi di ID evento analoghi ai seguenti:

Event Source: Netlogon
Event Category: None Event ID: 3210
User: N/A Event Description:
Failed to authenticate with \\DOMAINDC, a Windows NT domain controller fordomain DOMAIN.

e

Event Source: Netlogon
Event ID: 5722
Event Category: None User: N/A Event Description:
The session setup from the computer 1 failed to authenticate. The name of the account referenced in the security database is 2. The following error occurred: n3

Per risolvere il problema, determinare innanzitutto quale controller di dominio è il detentore corrente del ruolo di master operazioni emulatore controller di dominio primario (PDC). A tale scopo, utilizzare uno dei seguenti metodi:

• Installare l’utilità Netdom.exe degli Strumenti di supporto di Windows 2000, quindi eseguire il seguente comando:
  netdom query fsmo
• Avviare lo snap-in Utenti e computer di Active Directory, fare clic con il pulsante destro del mouse sul dominio, quindi scegliere Master operazioni. Scegliere la scheda PDC. Il detentore corrente del ruolo è visualizzato nella finestra Master operazioni. In questa scheda è possibile impostare il ruolo di master operazioni sul computer corrente nella seconda finestra (se il computer non è il detentore corrente).
• Utilizzare l’utilità Ntdsutil.exe (inclusa in Windows 2000) e l’utilità della riga di comando del Resource Kit. Queste interfacce sono tuttavia consigliate per utenti esperti.

Per ulteriori informazioni, fare clic sul numero dell’articolo della Microsoft Knowledge Base riportato di seguito:

234790  (http://support.microsoft.com/kb/234790/ ) Individuazione dei detentori dei ruoli FSMO

Nei controller di dominio in cui si verifica questo problema disattivare il servizio centro distribuzione chiavi (KDC) Kerberos. Per effettuare questa operazione:

1. Fare clic sul pulsante Start, scegliere Programmi, Strumenti di amministrazione e quindi Servizi.
2. Fare doppio clic su KDC, impostare il tipo di avvio su Disattivato, quindi riavviare il computer.

Dopo il riavvio del computer, utilizzare l’utilità Netdom per reimpostare i canali protetti tra questi controller di dominio e il detentore del ruolo di master operazioni emulatore PDC. Per effettuare questa operazione, eseguire il seguente comando da controller di dominio diversi dal detentore del ruolo di master operazioni emulatore PDC:

netdom resetpwd /server:nome_server /userd:nome_dominio\administrator /passwordd:password_amministratore

dove nome_server è il nome del server detentore del ruolo di master operazioni emulatore PDC.

Per ulteriori informazioni, fare clic sul numero dell’articolo della Microsoft Knowledge Base riportato di seguito:

260575  (http://support.microsoft.com/kb/260575/ ) Utilizzo di Netdom.exe per la reimpostazione di password di account computer di un controller di dominio Windows 2000

Dopo aver reimpostato il canale protetto, riavviare i controller di dominio. Anche se si tenta di reimpostare il canale protetto utilizzando l’utilità Netdom e il comando non viene completato correttamente, procedere con il processo di riavvio.

Se è in esecuzione solo il detentore del ruolo di master operazioni emulatore PDC, il servizio KDC forza gli altri controller di dominio a risincronizzarsi con questo computer anziché emettere un nuovo ticket Kerberos.

Dopo il riavvio dei computer, avviare il programma Servizi, riavviare il servizio KDC, quindi tentare nuovamente di eseguire la replica.

Se il dominio contiene più controller di dominio, il messaggio di errore visualizzato quando si verifica questo problema varia a seconda della modalità con cui si tenta di eseguire la replica e se uno dei controller di dominio coinivolti è anche il detentore del ruolo di master operazioni emulatore PDC.

In alcuni casi, quando si utilizza il comando net view \\nomecomputer per tentare di connettersi al controller di dominio con il ruolo di master operazioni emulatore PDC da un altro controller di dominio, è possibile che venga visualizzato il messaggio di errore “Accesso negato”. Se tuttavia si utilizza l’indirizzo IP (Internet Protocol), è possibile che il comando venga eseguito correttamente.

Quando si verifica questo problema, nei registri eventi potrebbero essere riportati numerosi errori, che variano a seconda della presenza di una delle seguenti condizioni:

• Il livello di funzionalità del controller di dominio non era completo prima del verificarsi del problema.
• Il controller di dominio non ha completato correttamente il processo dell’Installazione guidata di Active Directory.
• La cartella Sysvol del controller di dominio non è stata condivisa.
• Il controller di dominio non aveva la struttura completa dei file nella cartella Nome_dominio e la cartella Policies situata in %SystemRoot%\Sysvol\Sysvol\Nome_dominio\Policies.

Di seguito è riportato un esempio di evento che potrebbe essere segnalato:

Event ID: 3034
Type: Warning
Source: MRxSmb
Description: The redirector was unable to initialize security context or query context attributes.

VMWare Data Recovery

Buondì a tutti.

forse non tutti sanno che ultimamente VMWare ha rilasciato qualche novità in termini di backup delle VM: già qualche tempo fa, prima del rilascio di vSphere, abbiamo apprezzato non poco l’hot add mode del suo VCB che permetteva di agganciare tramite una macchina virtuale che funzionava da vcb proxy lo snapshot e poi ne faceva il backup sul nostro sistema di archiviazione tradizionale. Il vantaggio enorme di questa soluzione era che in questa modalità non avevamo bisogno di quintalate di spazio disco per appoggiare i nostri snapshot…d’altro canto eravamo limitati al fatto che in pratica si faceva il backup di una vm alla volta.

Con il rilascio di vSphere abbiamo a disposizione un’altra possibilità che concettualmente è molto simile all’hot add mode e si tratta proprio di Data Recovery che si basa sulle nuove vStorage APIs for Data Protection alle quali anche il “buon” vecchio VCB si adatterà presto.

Il prodotto consta di un appliance CentOS che si integra con il vSphere client che funziona allo stesso modo dell’hot add mode, con l’unica differenza che possiamo gestire in maniera più efficiente i backup concorrenti di più vm (fino ad otto) e che non abbiamo bisogno di consumare un’altra licenza di windows per mettere in piedi un VCB. L’appliance può agganciare in RDM una lun, può montare uno share cifs o ancora un disco virtuale.

La grossa novità di questo plugin è che non abbiamo necessità di alcuna soluzione di backup di terze parti (e per VMWare di certificate ce ne sono veramente poche), che possiamo fare backup e restore non solo a livello di disco ma anche a livello di file tramite il file level restore client ancora in stato sperimentale.

Per le vm windows che supportano VSS sappiate che la garanzia della consistenza dello snapshot e l’esecuzione del backup è affidata a tale servizio, mentre per le vm microsoft non VSS compliant i vmware tools usano il driver LGTO SYNC, mentre per le vm non Microsoft i vmware tools usano quiescing crash-consistent.

Il contro di questa soluzione è la necessità di fare backup su disco (cosa che farà storcere il naso agli amici della cassettina), aspetto però alleviato dal fatto che si fa deduplica dei volumi che fungono da repository per i backup con conseguente risparmio di spazio.

Attenzione che ogni appliance è certificato per supportare la gestione dei backup di al più 100 vm.

Data Recovery è incluso in vSphere Enterprise Plus, Advanced e Essentials Plus Editions, mentre la versione Std permette di acquistarlo a parte.

Alla prox,

Lorenzo Di Palma

NetApp…Snap Technology e altro!

Da tempo ormai sentiamo parlare del valore aggiunto del software presente nello storage NetApp, ma per molti alcune denominazioni del software o delle feature del suddetto storage, rimangono criptiche.
Cercherò di spiegare le features in dettaglio, in modo da capire cosa si cela dietro ognuna di esse.

Cominciamo con le più comuni:

FlexVol:
dietro questo termine, come si può immaginare, risiede la flessibità della gestione dei volumi creati nello storage.
Con questa tecnica di virtualizzazione dello storage, sarà possibile espandere,ridurre e spostare i volumi creati indipendentemente dallo storage fisico,senza perdita di dati.
Lo spazio del volume, non sarà più relegato allo spazio fisico dei dischi presenti nell’array.

FlexClone:
Altra interessante prerogativa dello storage NetApp.
Con questa funzionalità infatti sarà possibile creare degli snapshot immediati di ambienti di produzione, senza richiedere spazio storage aggiuntivo,in modo trasparente, rendendoli scrivibili per eventuali test.
In parole povere, FlexClone aggiunge un layer di fronte allo snapshot, che consente di renderlo “utilizzabile”.

SnapRestore:
Consente di ripristinare gli snapshot creati,sia a livello di volumi, che di singoli file.

SnapMirror:
Copia sincrona o asincrona degli snapshot creati sia su IP che FC, che  prevede la possibilità di avere anche storage Nearstore sul sito di replica, senza dover per forza replicare lo stesso storage-hardware

SnapVault o OSSV (Open System Snap Vault):
Possibilità di creare backup disk-2-disk anche a cadenza oraria, verso non solo storage primario, ma anche Nearstore.
Permette di decidere quale files e con quale frequenza debbano essere replicati a distanza.
OSSV invece è un agent che può essere installato su sitemi Windows,Linux,Unix per abilitare snapshot Host-Based.

SnapDrive:
Altra funzione che risiede nell’Host Server in una SAN.E’ uno snap-in MMC che permette di gestire le LUN da sistemi Windows (FCP o iSCSI) (limitato anche per Unix).
Oltre a permettere di eseguire il map delle LUN dall’Host server in modo semplice.
Funziona sia in ambienti fisici che virtuali e consente di gestire gli snapshot in modo trasparente.

SnapManager:
E’ la famiglia di Management Software di NetApp.Integrato totalmente con le funzionalità di snapshot, combina l’ambiente applicativo con lo storage NetApp, semplificandone la gestione quotidiana (backup,restore).
Software dedicato ad HOC, per i più comuni ambienti applicativi.
SnapManager è presente per:

-Exchange
-SQL
-Oracle
-SAP
-Sharepoint
-Virtual Infrastructure

Con SnapManager, l’amministratore di sistema sarà in grado di gestire snapshot in modo grafico ed istantaneo, in più lasciando al software, tutte quelle impostazioni che sono necessarie prima di eseguire il backup diambienti di produzione, come ad esempio quello dei DataBase.

Spero di essere stato abbastanza esplicativo… 
A breve seguire la seconda parte di ciò che si cela dietro alcuni termini NetApp.

 Oscar

Licensing Microsoft: MAK e KMS

Chi lavora con Microsoft saprà che una chiave VL permette l’attivazione di più installazioni del software, tant’è che con XP e 2003 si immetteva il codice in fase di installazione senza dover attivare la copia del sw non appena conclusa l’installazione.

Con Windows 2008 e Vista la procedura di attivazione di questi codici è diventata un pizzico più articolata per via dell’introduzione di due tipologie di chiavi: MAK (Multiple Activation Key) e KMS (Key Management Service).

Il MAK in genere si sceglie per ambienti dove ci al più 25 postazioni client da attivare e si attiva in due modi: o inserendo su ogni postazione il codice di attivazione prima o dopo l’installazione, oppure remotamente connettendosi ai singoli host da attivare con il VAMT (Volume Activation Management Tool) che si scarica dal sito Microsoft. Il VAMT può tornare utile anche quando dobbiamo attivare più host (anche Windows 2008 ovviamente) che non sono connesse a internet ed in tal caso eseguiamo una MAK proxy activation: il VAMT permette di raccogliere gli installation ID salvandoli in un file XML e poi ci si connette a Microsoft per ottenere finalmente il Confirmation ID che inseriamo sempre nel file XML per poi attivare i client sempre tramite il VAMT.

Con il KMS abbiamo una postazione di attivazione che può essere Vista, 2008 o 2003 su cui abbiamo preventivamente installato e configurato il servizio di attivazione. A questo punto i pc/server che hanno un’edizione VL di vista o 2008 cercano di attivarsi connettendosi alla macchina KMS: cercano di contattarlo ogni 2 ore finchè non trovano disponibile il servizio e si attivano. Dopo il primo contatto, ogni 7 giorni provano a ricontattare il KMS finchè non lo trovano, dopodichè tentano di riattivarsi ogni 180 giorni. Se capita qualche volta che non lo contattano entrano nel grace period di 30 giorni, oltre il quale continuano ad operare in RFM (Reduced Functionality Mode).

Attenzione che il KMS non è per tutti: c’è una soglia minima di pc/server che contattano il KMS prima di poter attivarsi ed è nella fattispecie 25 per i client e 5 per windows 2008.

Ma come avviene il discovery del servizio KMS? Abbiamo due strade:

1) è quella automatica e consiste nel tentativo da parte del KMS server di creare un record sul DNS _vlmcs._TCP.<Nome_Dominio>…se però il DNS non supporta gli aggiornamenti automatici o non lo fa da solo allora lo si aggiunge a manina;

2) su ogni host da attivare si lancia il comando
cscript %systemroot%\system32\slmgr.vbs -skms <KMS-host DNS or IP>

NB: ricordatevi che in ambo i casi la porta tcp 1688 sul server la dobbiamo raggiungere!

Per configurare l’host KMS:

cscript %systemroot%\system32\slmgr.vbs -ipk <product key>

cscript %systemroot%\system32\slmgr.vbs -ato

Se poi vogliamo attivare telefonicamente il prodotto c’è slui.exe

I parametri come porta tcp, intervallo di riattivazione degli host o registrazione su DNS di diversi domini richiedono l’intervento via registro oppure con altri parametri nell’esecuzione di slmgr.vbs.

Spero di avervi chiarito un po’ le idee.

Alla prossima,

Lorenzo Di Palma

 

 

Disponibili al download i nuovi prodotti sophos

Sono ufficialmente disponibili da qualche giorno i nuovi prodotti sophos giunti alla versione 4.0. Tra le novità troviamo il nuovo client (versione 9) e una politica sempre più vicina alla protezione dell’endpoint a 360° con l’introduzione di private crypto (per la versione SBE) che permette la cifratura di singoli file e del prodotto data protection lite incluso nella versione enterprise security and data protection, viene inoltre migliorata la gestione dei criteri relativi ai dispositivi mobili come chiavi USB e cd rom.

Davide

Virtualizzazione + Storage in Datacenter Dinamici

AGENDA XENergy Tour Roma 22 Ottobre 2009

 

9.30        Welcome e Registrazione

10.00      Introduzione Keynote – Massimiliano Caviglia

10.10       Presente e Trends emergenti nel mercato della Virtualizzazione -  Alessandro Perilli

 Alessandro Perilli di Virtualization.info, analista indipendente di riferimento mondiale, esperto del mercato della virtualizzazione, fornirà la sua visione sulla situazione attuale, offrendo la sua disanima sui trend emergenti. La sessione consentirà ai partecipanti di costruirsi un proprio orientamento verso le decisioni che conducono innovazione efficace all’interno della loro organizzazione.

11.00     Coffee Break

11.15      Citrix Delivery Center : La Virtualizzazione End To End –                 Ivan Riservato

 Con il termine “Delivery Center” si intende la dinamicità dei Data Center di fornire servizi agli utenti in maniera flessibile e personalizzabile mantenendo gli standard di sicurezza necessari. Un Delivery Center trasforma quindi il Data Center da statico a dinamico e permette di gestire un progetto globale di virtualizzazione end-to-end, partendo dal Data Center fino ad arrivare al Desktop dell’utente. Per Citrix il Delivery Center è l’approccio tecnologico che abilita al Cloud Computing attraverso un set completo di servizi fruibili dall’utenza tramite un’infrastruttura a blocchi, integrante in sé l’hosting, il delivery e la gestione dal Data Center.

  12.05      Sistemi Netapp – I Vantaggi di un’architettura virtualizzata : come concretizzare la visione – Roberto Patano

 Sistemi Storage di NetApp in grado di gestire intelligentemente un’infrastruttura virtuale. Oggi lo Storage rappresenta di fatto il cuore di un progetto di virtualizzazione e server consolidation. Gartner posiziona NetApp come leader nel mercato dello Storage per la sua completezza di soluzioni e la visione a 360° delle reali necessità di chi deve mettere in sicurezza i propri dati, vale a dire quindi il patrimonio della propria organizzazione.

 12.50      Il Datacenter Dinamico nellà realtà Pt1 - Francesco Ciurlia e Adriano Criscuolo

 L’Istituto Nazionale di Assistenza Sociale (INAS-CISL) fornirà la propria testimonianza di un progetto di Citrix Delivery Center integrato a sistemi di Storage NetApp: un esempio reale di cosa significa e cosa comporta scegliere un’architettura XEN a 360°.

  13.30      Buffet Lunch

  14.15      Il Datacenter Dinamico nellà realtà Pt2 - Salvatore Fiorellino e Lorenzo Di Palma

 Sarà presentato un altro caso di successo storico per Citrix: il World Food Programme, agenzia delle Nazioni Unite, interviene per illustrare la propria esperienza di implementazione di XenApp dal lontano 1999, a cui ha fatto seguito un’evoluzione tecnologica che oggi contempla l’utilizzo di XenDesktop e XenApp Platinum edition per il delivery di applicazioni e dei desktop.

14.40      NetApp : Presente e Futuro (tech update, novità e tech preview) - Francesco Tripodi

 L’intervento fornisce un’overview sulle ultime novità dei sistemi di Storage NetApp, con dimostrazione dei benefici apportati dalla tecnologia di deduplica basati su casi reali.

 15.30      Coffee Break

 15.45      Citrix : Presente e Futuro – Citrix XenDesktop 4 Tech Preview - Roberto Luongo con Lorenzo Di Palma e Adriano Criscuolo

 WINDOWS 7 è arrivato! Vieni a vedere come XenDesktop 4 può aiutarti in questo processo di rinnovamento, rivoluzionare la tua gestione dell’IT ed offrire ai tuoi utenti performance mai viste.

  16.50      Conclusioni e Premiazione – Massimiliano Caviglia

 “Il 2010 sarà un anno importantissimo per la virtualizzazione desktop che inaugurerà una nuova era destinata a rivoluzionare il modo in cui lavoriamo, viviamo e giochiamo. Venticinque anni fa il personal computer ha ribaltato il mondo di allora migliorando radicalmente la produttività e la comunicazione degli individui. Quel mondo sta per cambiare un’altra volta. Le persone oggi hanno bisogno di lavorare secondo modalità del tutto nuove con la potenza della connettività di Internet, l’esplosione di nuovi dispositivi e le promesse illimitate del Web. E tutto questo senza essere confinate nei soliti desktop vincolati a un ufficio, un dispositivo o una rete. La virtualizzazione desktop ha la capacità di rendere possibile tutto questo. La rivoluzione inizia qui, oggi – e inizia con il nuovo XenDesktop.”

     Mark Templeton, Presidente e CEO di Citrix Systems

Sanbolic MelioFS: un VCB su Virtuozzo for Windows

Buona sera a tutti,

forse non tutti conoscono Virtuozzo, hosted based solution di virtualizzazione per sistemi operativi windows prodotto da Parallels che sicuramente conoscerete in quanto adottato dalla maggior parte dei provider per fare web hosting.

Le caratteristiche peculiari di Virtuozzo sono l’alta densità di macchine virtuali che si riescono ad avere su ogni singolo host fisico, la totale dinamicità dell’allocazione delle risorse cpu, ram, disco e rete sui singoli container (questo è il nome delle vm su virtuozzo). I contro della soluzione sono la mancanza allo stato attuale della live migration nella versione per windows (su linux c’è già da tempo….qualcuno che ancora ha da obiettare su quanto linux sia meglio di windows??) ed il fatto che non puoi avere macchine virtuali con sistemi eterogenei rispetto al sistema operativo di base dell’host fisico (se ho windows 2003 posso solo creare container windows 2003 tanto per capirci).

Ma non è di come funziona Virtuozzo che volevo parlare (mi serviva solo darvi un0infarinatura generale della soluzione), bensì di come crearsi un VCB alla stessa stregua di VMware usando Sanbolic MelioFS, prodotto che crea un clustered file system sotto windows (quindi accessibile in r/w da più di un host alla volta).

L’idea è molto semplice e serve ad evitare di generare eccessivo traffico LAN (anche se su rete dedicata) e ridurre notevolmente i tempi di backup dei containers.

Ipotizzando di avere i nostri nodi Virtuozzo ed un server di backup con il nostro prodotto per il salvataggio dati installato sopra, dobbiamo unicamente installare l’agent di MelioFS su ognuno di questi host e collegare fisicamente tutti e tre gli host ad una LUN FC o iSCSI che sia (OpenFiler…che ne dite?) su cui gli host Virtuozzo vanno a fare i backup dei container e da cui la macchina di backup preleva i container salvati spedendoli direttamente sulla nostra tape library o VTL che sia.

Perchè fare una cosa del genere? Velocità del backup, decongestionamento della rete e poter usufruire dei vantaggi di qualunque soluzione di backup abbiamo in casa, anche quelli che non sono VSS compliant, ed ultimo, ma non meno importante, la garanzia del backup effettuato perchè il container viene backuppato a caldo direttamente sul nodo Virtuozzo. Questo è il modo più sicuro di garantirne la consistenza dato che ci sono prodotti che hanno l’agent per il prodotto di Parallels, ma spesso danno problemi proprio per la complessità che c’è dietro all’esecuzione di un container che condivide la maggior parte delle componenti del sistema operativo di base.

Alla prox,

L.

Per la prima volta ho scoperto la piattaforma vyatta, alternativa opensource a cisco. Vyatta è disponibile sia come macchina virtuale (Xen e VMware) sia come ISO oltre ai due appliance. Devo ammettere che il non essere user friendly e il prediligere una programmazione CLI a primo impatto mi ha spaventato, tuttavia dopo averci preso la mano (in brevissimo tempo) vyatta si rivela una piattaforma estremamente performante e versatile.  Vediamo ora un paio di cenni generali su questi prodotti, ricordo che è possibile trovare una documentazione molto esaudiente sul sito ufficiale.

Per prima cosa la configurazione della piattaforma vyatta è basata sui file conf, quindi per ogni comando si deve dare un commit ed infine un save per scrivere la nostra configurazione nel file e renderla operativa anche dopo il riavvio della piattaforma stessa. Vediamo ora la configurazione di un router vyatta nel classico scenario dove c’è una LAN e il router deve svolgere la funzione di default gateway, all’interno c’è un server terminal da pubblicare sulla wan. vedremo quindi le seguenti tematiche:

• Modello di routing della piattaforma vyatta
• Customizzazione del router e primo avvio
• Configurazione IP delle interfacce sotto la piattaforma vyatta
• Configurazione del NAT

Note di lettura: Nomi specifici di componenti, tecnologie e credenziali saranno indicate in grassetto mentre i comandi saranno indicati in grassetto corsivo il simbolo << indica “dare invio”

Modello di routing della piattaforma vyatta

Vyatta gestisce i pacchetti in base al tipo di NAT configurato, il routing di un pacchetto soggetto a dnat (mascheramento dell’indirizzo di destinazione) sarà diverso da quello di un pacchetto soggetto a snat (mascheramento dell’indirizzo di provenienza). Per la precisione è la catena vyatta che deve essere considerata in maniera diversa a seconda del tipo di nat. La catena vyatta prevede 4 blocchi di “lavorazione del pacchetto, essi sono: DNAT, Routing, Firewall e SNAT. Un pacchetto soggetto a DNAT subisce il mascheramento dell’indirizzo di destinazione all’inizio della catena, quindi il processo dirouting ed il firewall valutano l’indirizzo di destinazione già mascherato (ad esempio un pacchetto con destinazione 85.37.17.16 subisce un dnat e viene mascherato con l’indirizzo 10.10.10.4. il processo di routing e il firewall avranno come destination address del pacchetto il 10.10.10.4) mentre i pacchetti sogetti a snat subiscono il mascheramento a termine della catena, quindi routing e firewall analizzeranno l’indirizzo sorgente “originale”. L’importanza di questi concetti si rileva vitale durante lo sviluppo delle regole di firewalling.

Customizzazione del router e primo avvio

La piattaforma vyatta è dotata di una CLI molto comoda, al primo avvio ci troveremo dinnanzi alla richiesta di login, si può entrare sia con lo username root sia con l’utente vyatta ovviamente per entrambi è settata una password di default che è vyatta. Di solito per ragioni di sicurezza si predilige lavorare con l’utente vyatta, quindi eseguiamo il login ed entriamo subito in configurazione digitando configure<< ora passiamo alla configurazione.

Impostazione dell’host name: set system host-name nomedaassegnarealrouter <<

Impostazione dominio di appartenenza: set system domain nomedominio <<

Impostazione server DNS: set system name-server ipserverdns <<

Da notare la possybilità di completare i comandi e di mostrare le opzioni con il tasto tab, se sinfatti digitiamo set sy e premiamo tab automaticamente la stringa diviene set system e premendo il tab due volte (una per aggiungere uno spazio dopo la stringa system) visualizzeremo tutti i comandi accettati relativi alla voce system.

Diamo ora un commit per scrivere la configurazione appena modificata e un save per salvarla e renderla definitiva, quindi commit<< save<<.

Uno degli errori più grandi è lasciare le password di default, modifichiamo quindi le password per gli account root e vyatta.

set system login user root authentication plaintext-password nuovapassword<<

set system login user vyatta authentication plaintext-password nuovapassowrd<<

commit<<

save<<

Configurazione IP delle interfacce sotto la piattaforma vyatta

Impostiamo ora gli indirizzi delle interfacce, ricordiamo che solitamente la eth0 è l’interfaccia esposta ad internet, diamo quindi

set interfaces ethernet eth0 address dhcp<<

set interfaces ethernet eth1 address 192.168.1.254/24<<

set system gateway-address 10.10.1.254<<

commit<<

save<<

Ovviamente i volori sono relativi all’esempio quindi se nella nostra interfaccia esterna abbiamo bisogno di inserire un ip fisso non c’è problema, basta utilizzare la notazione usata nella eth1 dell’esempio. Il comando set system gateway address serve a fornire al sistema quale gateway utilizzare per instradare le richieste esterne alla LAN.

Configurazione del NAT

in vyatta la configurazione del nat avviene per regole, abbiamo quindi la possibilità di creare n regole (32) con priorità decrescente, quindi la regola 1 ha più priorità della 2. Per rendere il nostro router un gateway bisogna configurarlo in modo che effettui un operazione di snat dei pacchetti provenienti dalla lan con l’indirizzo dell’interfaccia eth0, questa operazione è detta maquerading. Impostiamo quindi la nat specificando per prima cosa regola e tipo di operazione:

set service nat rule 1 type masquerading<<

ora specifichiamo cosa deve mascherare indicando la nostra rete interna

set service nat rule 1 source address 192.168.1.0/24<<

indichiamo ora l’interfaccia il cui indirizzo IP andrà a sotituire l’IP sorgente dei pacchetti

set service nat rule 1 outbound-interface eth0

infine

commit<<

save<<

Ora riavviamo l’applaiance eseguendo il login come root (prima bisogna uscire dalla configurazione con exit<<) e digitando reboot<<

impostiamo infine il nat per il server terminal.

definiamo come tipologia il dnat: set service nat rule 2 type destination<<

impostiamo l’interfaccia di provenienza: set service nat rule 2 inbound-interface eth0<<

ora impostiamo l’ip pubblico che deve essere nattato set service nat rule 2 destination address ippubblico<<

impostiamo la porta alla quale risponde il servizio lato internet set service nat rule 2 destination port 3389<<

ora impostiamo il tipo di protocollo set service nat rule 2 protocol tcp

passiamo al lato interno indicando l’ip di lan del server terminal set service nat rule 2 inside-address address ipTS<<

terminiamo con l’indicazione della porta sul server terminal set service nat rule 2 inside-address port 3389<<

in ultimo

commit<<

save<<

Bene, spero di essere stato d’aiuto, non dimenticate di consultare la documentazione ufficiale disponibile sul sito vyatta.

Davide Pala

Vyatta 5 comunity edition VMware appliance keyboard layout

La macchina VMware di vyatta 5.0 comunity edition è configurata con il layout della tastiera in inglese, per cambiarlo procedere come segue:

1. Impostare i parametri base per la navigazione
2. effettuare il login come root
3. eseguire i seguenti comandi

configure
set system package repository lenny components main
set system package repository lenny url http://packages.vyatta.com/debian/
set system package repository lenny distribution lenny
commit
exit
apt-get update
apt-get install console-data

Durante l’installazione di console-data selezionare la lingua appropriata.

Davide Pala

XenServer Pool Master Failure

 

Fortunatamente non è un evento che capita spesso, ma cosa accadrebbe se nell’ambito di un Resource Pool di XenServer la macchina con il ruolo di Master dovesse avere dei problemi?

 

 

Ovviamente ogni server Slave membro del Pool contiene al proprio interno la replica del DB con tutta la configurazione necessaria per prendere possesso del ruolo di Master nel caso gli venga richiesto.

 Quando il nodo Master fallisce avviene questo:

1. I membri si accorgono che la connessione con il master è stata persa e ritentano per 60 secondi di ristabilirla;

2. A questo punto se la connessione non viene ristabilita ogni server Slave entra in Emergency Mode, da questo momento non sarà possibile modificare nessun tipo di configurazione all’interno del Pool e delle singole macchine. Gli unici comandi che i server accetteranno sono quelli relativi alla modalità di emergenza (pool-emergency commands). XenCenter ovviamente non funziona.

Se il master dovesse tornare operativo in questo momento tutti i server membri del Pool lascerebbero la modalità di emergenza e tutto tornerebbe alla normalità.

Se invece il server con il ruolo di Master continua ad avere problemi si deve procedere con la procedura indicata di seguito.

E’ necessario nominare un nuovo Master per il Resource Pool. Scegliere uno dei server slave, raggiungerlo in console oppure tramite ssh, scrivere il seguente comando per farlo diventare il nuovo master:

           xe pool-emergency-transition-to-master

A questo punto sarà possibile contattare il nuovo Master anche con XenCenter. Se necessario bisognerà mandare un segnale a tutti gli altri slave comunicando che il Master è cambiato, il comando è il seguente:

            xe pool-recover-slaves

Avvisa tutti gli slave che il nuovo master è operativo.

Se uno o più slave non dovessero contattare il master, posizionarsi sulla macchina in questione ed eseguire il seguente comando:

 xe pool-emergency-reset-master master-address=<ip del nuovo master>

 Per approfondimenti è disponibile il seguente documento: XenServer System Recovery Guide

Adriano Criscuolo