Differenze tra ODBC e OLE DB in Windows

Trattiamo oggi le differenze principali che ci sono tra le 2 API: ODBC e OLE DB. Innanzitutto entrambe sono delle interfacce standard che permettono di accedere a database e/o dati di varia natura in ambiente Microsoft Windows (ODBC non è specifico solo per Windows).

Open Database Connectivity (ODBC) è uno standard open, supportato dalla maggior parte dei vendor. Fornisce un accesso ai database relazionali aggirando le limitazioni dell’applicazione nativa, che potrebbe non essere in grado di accedere a tali database. ODBC costituisce pertanto un’interfaccia per accedere a qualunque RDBMS che supporti le API ODBC, come ad esempio Oracle, MS SQL Server, o MySQL. […]

Trattiamo oggi le differenze principali che ci sono tra le 2 API: ODBC e OLE DB. Innanzitutto entrambe sono delle interfacce standard che permettono di accedere a database e/o dati di varia natura in ambiente Microsoft Windows (ODBC non è specifico solo per Windows).

Open Database Connectivity (ODBC) è uno standard open, supportato dalla maggior parte dei vendor. Fornisce un accesso ai database relazionali aggirando le limitazioni dell’applicazione nativa, che potrebbe non essere in grado di accedere a tali database. ODBC costituisce pertanto un’interfaccia per accedere a qualunque RDBMS che supporti le API ODBC, come ad esempio Oracle, MS SQL Server, o MySQL.

Object Linking and Embedding Database (OLE DB) è invece una standard API specifica di Microsoft, sviluppata con l’obiettivo di maggiori prestazioni e in grado di accedere ad una maggior quantità di dati differenti. Difatti la sua particolarità è di permettere l’accesso sia a database relazionali che non, nel primo caso facendo uso di ODBC. Ad esempio è possibile accedere a MS SQL Server, Oracle, Excel, file raw e di altra natura in genere.

Riepilogando, le principali differenze tra i due sono:

  • ODBC:
    • fornisce accesso solo ai database relazionali;
    • è meno efficiente;
    • è uno standard open;
  • OLE DB:
    • fonisce accesso ai dati indipendentemente dalla loro posizione e formato;
    • fornisce accesso alle sorgenti e ai driver ODBC (dunque database relazionali);
    • è più efficiente.

Di seguito l’immagine mostra chiaramente il rapporto tra OLE DB e ODBC, e a quali dati riescono ad accedere.

OLE DB and ODBC differences
Architettura funzionale di OLE DB e ODBC.

Alcuni approfondimenti sono:

roghan

Visualizzare file nascosti in Win XP con bug

Potrebbe succedere che in Windows XP non vengano visualizzati file e directory nascoste, anche spuntando la relativa opzione nel menù “Opzioni cartella”. Il problema probabilmente è dovuto a qualche programma o virus che ha corrotto le relative chiavi all’interno del registro di sistema. In particolare il problema può essere notato nel momento in cui viene spuntata l’opzione “visualizza file e cartelle nascosti”, e ricontrollando successivamente la spunta torna su “non visualizzare cartelle e file nascosti”.
Come risolvere il problema? Vediamone i passi da seguire. […]

Potrebbe succedere che in Windows XP non vengano visualizzati file e directory nascoste, anche spuntando la relativa opzione nel menù “Opzioni cartella”. Il problema probabilmente è dovuto a qualche programma o virus che ha corrotto le relative chiavi all’interno del registro di sistema. In particolare il problema può essere notato nel momento in cui viene spuntata l’opzione “visualizza file e cartelle nascosti”, e ricontrollando successivamente la spunta torna su “non visualizzare cartelle e file nascosti”.
Come risolvere il problema? Vediamone i passi da seguire.

Aprire il registro di sistema:

Start -> Esegui -> regedit

Dunque cercare:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced

Nel frame di destra dobbiamo assicurarci che il valore Reg_Dword "Hidden" sia impostato a “1”, sapendo che le opzioni possibili sono:

  1. Visualizza file e cartelle nascoste;
  2. Non visualizzare file e cartelle nascoste.

Inoltre se è presente un valore reg_sz "Hidden", questo deve essere cancellato.

Fatto questo andiamo a cercare:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Hidden\SHOWALL

Dunque, nel frame di destra deve essere creato il valore Reg_Dword "CheckedValue" e impostato su 1. Se dovesse essere presente il valore reg_sz "CheckedValue", questo andrebbe eliminato.

Riavviate il sistema per sicurezza… et voilà i file nascosti!!

roghan

Privilegi root per bind di porte 1-1023 in Java

Se dobbiamo creare un server in Java per accettare comunicazioni su TCP, è necessario usare la classe ServerSocket, mentre quella Socket è specifica per il lato client. Durante la creazione della componente client, bisogna fare particolare attenzione a quali porte indichiamo se ci troviamo su sistemi Linux/Unix. […]

Se dobbiamo creare un server in Java per accettare comunicazioni su TCP, è necessario usare la classe ServerSocket, mentre quella Socket è specifica per il lato client. Durante la creazione della componente client, bisogna fare particolare attenzione a quali porte indichiamo se ci troviamo su sistemi Linux/Unix. Ad esempio, il codice per mettere in ascolto un server sulla porta 80 è il seguente:

try
{
     ServerSocket server= new ServerSocket(80);
}catch (IOException iex)
{
     System.err.println(ex);
}

Il codice è corretto, ma potrebbe essere sollevata un’eccezione su sistemi Unix/Linux o anche Windows, in quanto sono necessari i privilegi di root/administrator per poter usare le porte nel range 1-1023.

roghan

Come risolvere i problemi di connessione – parte 1

Spesso capita che la rete non funzioni, e ci chiediamo quale e dove possa essere il problema. E’ il nostro sistema che non va? E’ il server che non risponde? E’ la trasmissione che non funziona? Insomma ci sono sempre tante domande e non sempre è immediato trovare la risposta, e finiamo per cambiare parametri e impostazioni nel tentativo di ripristinare la connessione! Gli utenti più inesperti poi finisco per installare svariati tipi di software che promettono di ripristinare la connessione e di sistemare tutto, come questo Connectivity fixer. Non ci sono programmi più inutili e magari dannosi (chi ha detto spyware?! Io no ;-)…). […]

Spesso capita che la rete non funzioni, e ci chiediamo quale e dove possa essere il problema. E’ il nostro sistema che non va? E’ il server che non risponde? E’ la trasmissione che non funziona? Insomma ci sono sempre tante domande e non sempre è immediato trovare la risposta, e finiamo per cambiare parametri e impostazioni nel tentativo di ripristinare la connessione! Gli utenti più inesperti poi finisco per installare svariati tipi di software che promettono di ripristinare la connessione e di sistemare tutto, come questo Connectivity fixer. Non ci sono programmi più inutili e magari dannosi (chi ha detto spyware?! Io no ;-)…).

Questo post rappresenta invece la prima parte di un altro post che avevo scritto qualche tempo fa, in cui spiegavo come fare troubleshooting della rete e verificare il collegamento ad Internet. In questo articolo invece esaminiamo il problema partendo dalla connessione alla rete locale, e senza far uso di risoluzioni DNS.

 

Prendiamo come esempio l’architettura di rete visibile in figura, e supponiamo di essere il sistema Bob con indirizzo IP 172.17.10.3 e di voler contattare la macchina Server con indirizzo 172.17.30.2. Nell’immagine non ho specificato le subnet per semplificare il tutto e renderlo fruibile anche a chi può avere meno conoscenze informatiche, comunque possiamo assumere che la subnet sia /24, uguale per ogni indirizzo.

diagramma_rete
Diagramma di rete

Come è visibile dal grafico si tratta di una piccola rete, tuttavia il problema può facilmente essere esteso ad una rete molto più grande come anche ad Internet (semplicemente non ci sarà un solo router tra sorgente e destinazione ma una serie di N dispositivi, come backbone, …). Vediamo i passi da fare per controllare il funzionamento della rete dal punto di vista di Bob:

  1. Test del loopback. Apriamo un terminale (prompt cmd in Windows, shell in Linux e MacOS) e facciamo ping verso 127.0.0.1.
    $ ping 127.0.0.1
    PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
    64 bytes from 127.0.0.1: icmp_req=1 ttl=64 time=0.773 ms
    64 bytes from 127.0.0.1: icmp_req=2 ttl=64 time=0.125 ms
    64 bytes from 127.0.0.1: icmp_req=3 ttl=64 time=0.080 ms
    64 bytes from 127.0.0.1: icmp_req=4 ttl=64 time=0.083 ms
    --- 127.0.0.1 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3001ms
    rtt min/avg/max/mdev = 0.080/0.265/0.773/0.293 ms

    Questo è l’indirizzo di loopback e se il risultato è positivo significa che lo stack TCP/IP è stato inizializzato correttamente. In caso invece di fallimento il servizio che gestisce lo stack TCP/IP deve essere ripristinato all’interno del sistema operativo. Per effettuare il ripristino dello stack in Windows è possibile consultare questo link, mentre per Linux quest’altro.

  2. Test della scheda di rete. Adesso facciamo ping verso l’indirizzo IP del sistema locale, nell’esempio 172.17.10.3.
    $ ping 172.17.10.3
    PING 172.17.10.3 (172.17.10.3) 56(84) bytes of data.
    64 bytes from 127.0.0.1: icmp_req=1 ttl=64 time=0.111 ms
    64 bytes from 127.0.0.1: icmp_req=2 ttl=64 time=0.079 ms
    64 bytes from 127.0.0.1: icmp_req=3 ttl=64 time=0.080 ms
    64 bytes from 127.0.0.1: icmp_req=4 ttl=64 time=0.078 ms
    --- 127.0.0.1 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3001ms
    rtt min/avg/max/mdev = 0.078/0.087/0.111/0.013 ms

    Se con il ping vengono ricevute le risposte significa che la NIC funziona correttamente così come i driver/moduli di sistema, ma ciò non indica che la rete è esente da problemi quali cavi rotti o collegamenti interrotti. Un esito invece negativo potrebbe essere indice di scheda di rete guasta o di driver/moduli non installati correttamente. Provate a riavviare il sistema e, su Windows, a reinstallare i driver, mentre su Linux ad aggiornare il kernel e riavviare moduli e servizi secondo le istruzioni a questo link.

  3. Test del gateway. Ora è in turno del gateway/router. Effettuate il ping verso il default gateway per testare la comunicazione nella rete locale, nell’esempio 172.17.10.1.
    $ ping 172.17.10.1
    PING 172.17.10.1 (172.17.10.1) 56(84) bytes of data.
    64 bytes from 192.168.139.2: icmp_req=1 ttl=128 time=0.255 ms
    64 bytes from 192.168.139.2: icmp_req=2 ttl=128 time=0.237 ms
    64 bytes from 192.168.139.2: icmp_req=3 ttl=128 time=0.241 ms
    64 bytes from 192.168.139.2: icmp_req=4 ttl=128 time=0.219 ms
    --- 192.168.139.2 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3004ms
    rtt min/avg/max/mdev = 0.219/0.238/0.255/0.012 ms

    Un esito negativo significa che c’è un problema o nella trasmissione dei dati (cavo rotto/scollegato), o nel default gateway che non è in grado di elaborare le richieste, oppure un blocco delle richieste da parte di un firewall o altro dispositivo interconnesso tra Bob e il default gateway (switch, hub, AP, …).

  4. Test del server remoto. Infine, se tutti i 3 punti precedenti hanno avuto esito positivo, testiamo la connessione verso il server remoto, nel nostro esempio  172.17.30.2.
    $ ping 172.17.30.2
    PING 172.17.30.2 (172.17.30.2) 56(84) bytes of data.
    64 bytes from 172.20.0.1: icmp_req=1 ttl=128 time=1.46 ms
    64 bytes from 172.20.0.1: icmp_req=2 ttl=128 time=0.913 ms
    64 bytes from 172.20.0.1: icmp_req=3 ttl=128 time=2.40 ms
    64 bytes from 172.20.0.1: icmp_req=4 ttl=128 time=0.714 ms
    --- 172.20.0.1 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3005ms
    rtt min/avg/max/mdev = 0.714/1.375/2.407/0.657 ms

    Se l’esito è negativo significa che il problema è da ricercarsi nella rete remota. Inoltre, nel caso in cui sia possibile raggiungere la rete remota con il ping, sarebbe ideale poter replicare i test partendo dal server remoto verso il sistema sorgente.

Nel caso di connessione a Internet (e non locale) anche se tutti e 4 i punti hanno avuto esito positivo la comunicazione potrebbe non funzionare. In questo caso il problema potrebbe essere il servizio DNS, e rimando alla seconda parte dell’articolo.

roghan

Come risolvere i problemi di connessione, il DNS – parte 2

Se la connessione ad Internet o la navigazione sul web non funzionano i motivi potrebbero essere molti, ed uno di questi potrebbe essere legato al server DNS utilizzato. Ad esempio non vengono più caricate le pagine web ma la connessione sembra stabilita? Come risolviamo il problema? Spesso quando la rete non va si pensa a tutto meno che a verificare il funzionamento del server DNS. Questo post rappresenta la seconda parte di un altro in cui spiegavo come risolvere i problemi in una rete locale senza l’uso del DNS. In questo articolo invece ci spostiamo ai problemi di connessione anche verso la grande Rete. […]

Se la connessione ad Internet o la navigazione sul web non funzionano i motivi potrebbero essere molti, ed uno di questi potrebbe essere legato al server DNS utilizzato. Ad esempio non vengono più caricate le pagine web ma la connessione sembra stabilita? Come risolviamo il problema? Spesso quando la rete non va si pensa a tutto meno che a verificare il funzionamento del server DNS. Questo post rappresenta la seconda parte di un altro POST in cui spiegavo come risolvere i problemi in una rete locale senza l’uso del DNS. In questo articolo invece ci spostiamo ai problemi di connessione anche verso la grande Rete.

Prima di affrontare la problematica ricordiamo che il DNS, acronimo di Domain Name System, è un protocollo di comunicazione che traduce i nomi delle macchine in indirizzi IP, ed è quindi fondamentale per la navigazione sul web. Infatti, durante la navigazione su Internet vengono solitamente digitati sul browser i nomi dei siti che vogliamo visitare, i quali vengono poi tradotti dal protocollo DNS in indirizzi IP. Ciò avviene in modo del tutto automatico e trasparente per l’utente, difatti è il sistema operativo stesso che si occupa di interrogare uno dei server DNS impostati e di ottenere come risposta l’indirizzo IP del sito da visitare. Per conoscere i server DNS configurati è sufficiente digitare da terminale: ipconfig /all in ambiente Windows, e ifconfig in Linux.

Vediamo adesso gli step da fare.

  1. ping verso Internet. L’operazione “classica” è di effettuare un ping verso un sito Internet. Importante è effettuare due prove con il comando ping, una utilizzando come destinazione il nome completo di un sito Internet (FQDN), l’altra utilizzando l’indirizzo IP diretto del sito. Nel caso in cui entrambi i ping non ricevano risposta, il problema è da ricercarsi nella connessione stessa e non c’entra niente il DNS. I problemi potrebbero essere dovuti al proprio fornitore di connettività, al router mal configurato, ai driver/moduli della scheda di rete, al sistema operativo, … Nel caso in cui invece il ping con il nome completo di un sito non funzioni, mentre viene restituita la risposta utilizzando l’indirizzo IP, il problema è da ricercarsi nel DNS (passare al punto successivo). Ecco un esempio esplicativo, in cui il server DNS configurato è errato oppure non è funzionante.

    ping_senza_dns
    Esempio con DNS errato o non impostato
  2. verifica del server DNS. Verificato che la connessione a Internet non risponde (e il ping di un sito utilizzando il nome completo), nonostante il comando ping abbia ricevuto almeno una risposta, controlliamo le impostazioni del DNS. Apriamo un terminale, digitiamo il comando nslookup e osserviamo l’output. Se viene segnalato un errore allora abbiamo trovato il problema: l’indirizzo IP del server DNS è errato oppure non funziona il server stesso! Attenzione, perché nel caso in cui non venga restituito errore ma solo “server unknown” il server DNS impostato è corretto, ma non è semplicemente abilitato il reverse lookup, una funzionalità dei server che può essere abilitata o meno. Qualora ci sia un errore nel server DNS impostato, è opportuno verificare manualmente la configurazione del sistema e provare a cambiare i server DNS utilizzati, ad esempio con quelli di OpenDNS: 208.67.222.222 e 208.67.220.220. Se viene invece visualizzato un output simile al seguente allora il DNS funziona perfettamente e ancora non abbiamo trovato il problema:

    nslookup
    Server DNS impostato correttamente
  3. Risoluzione FQDN locale. Dunque, facciamo il punto della situazione: il ping verso Internet funziona, i server DNS sono correttamente impostati e rispondono al comando nslookup. Nel caso in cui il server DNS utilizzato si trovi nella rete interna a cui siamo collegati, effettuiamo un local FQDN, ossia interroghiamo il server DNS chiedendo di risolvere il nome completo di una macchina locale. Se la richiesta ha esito negativo, ossia viene generato un errore, il problema è del server DNS. Contattare l’amministratore del server DNS (ad esempio in una rete aziendale) oppure cambiarlo nel caso in cui sia un indirizzo pubblico. Vediamo un esempio:
    local_fqdn
    Risoluzione FQDN locale con nslookup

    Nell’esempio è stata effettuata una richiesta al server DNS utilizzando il nome completo di un host, ed è stata ricevuta correttamente la risposta. Ricordo che il nome completo di un host, FQDN, è il nome intero che identifica la risorsa in rete, ad esempio hostname.dominio.it.

  4. Risoluzione hostname locale (se il server DNS è nella rete interna). Provare a risolvere un hostname senza suffisso (ad esempio pc1 è l’hostname di pc1.esempio.it), sempre utilizzando il comando nslookup. Nel caso in cui venga restituito un errore il problema non è del server DNS ma della componente client del proprio sistema operativo. Ecco un esempio, in cui nslookuprestituisce correttamente la risposta:

    query_local_hostname
    Risoluzione hostname locale con nslookup
  5. Risoluzione FQDN esterno. Proviamo a risolvere sempre tramite il comando nslookup un nome completo, FQDN, della rete esterna (ad esempio un sito Internet). Se viene restituito un errore il problema è nel server DNS utilizzato, quindi provare a cambiarlo o contattare l’amministratore del server/ISP. Se invece la risoluzione del nome restituisce esito positivo, ma comunque la navigazione non funziona, il problema è della macchina client.

Nei punti 4 e 5, se il test ha esito negativo, il problema è il servizio DNS del sistema che non funziona correttamente. Per risolvere il problema in Windows ci sono 3 step:

  1. aprire il terminale dei comandi e digitare ipconfig /flushdns;
  2. digitare net stop dnscache;
  3. digitare infine net start dnscache.

Il comando ipconfig /displaydns visualizza la cache del client DNS.

Nel caso di Linux invece la soluzione è più semplice perché basta riavviare il servizio nscd.

roghan

Cluster VMware vs cluster Microsoft

In questo post verranno trattati i vantaggi di implementare un cluster Microsoft e quelli invece di un cluster VMware vSphere. Un cluster Microsoft ha il vantaggio che sono monitorate le applicazioni all’interno del sistema operativo, ad esempio SQL Server: se l’applicazione su uno dei nodi del cluster ha un crash, subentra immediatamente l’istanza sull’altro nodo in modo da garantire continuità di servizio. Nel caso di VMware invece può essere configurato un cluster con la Fault Tolerance (FT), la funzionalità che meglio si avvicina a MSCS. […]

In questo post verranno trattati i vantaggi di implementare un cluster Microsoft e quelli invece di un cluster VMware vSphere.

cluster

Un cluster Microsoft ha il vantaggio che sono monitorate le applicazioni all’interno del sistema operativo, ad esempio SQL Server: se l’applicazione su uno dei nodi del cluster ha un crash, subentra immediatamente l’istanza sull’altro nodo in modo da garantire continuità di servizio. Nel caso di VMware invece può essere configurato un cluster con la Fault Tolerance (FT), la funzionalità che meglio si avvicina a MSCS. Con la FT attiva VMware garantisce la continuità di esecuzione di una VM, ma non delle singole applicazioni all’intero della VM:

  1. se il nodo che ospita la VM ha un malfunzionamento, una VM identica già attiva e avviata entrerà in funzione, garantendo zero disservizio;
  2. se il nodo che ospita la VM funziona correttamente ma ha un crash un’applicazione interna alla VM (un database, un server web, …), la FT non è in grado di effettuare alcun azione e il servizio non verrà più erogato.

Dunque nella scelta tra MSCS e VMware deve essere tenuto in considerazione il livello di protezione garantito, che è maggiore con MSCS ma con lo svantaggio di costi maggiori e di un maggior livello di complessità. Con MSCS infatti devono essere configurati singolarmente i nodi del cluster, così come devono essere configurati disco di quorum e RDM. In VMware invece la configurazione del cluster è molto più semplice ed intuitiva, e viene fatta interamente attraverso vCenter Server, il quale si occuperà sia di monitorare le VM sia di eseguire le azioni opportune in caso di crash. In definitiva, MSCS è da preferire per applicazioni mission-critical, come un database, in cui un disservizio anche minimo può causare notevoli problemi, mentre per altri tipi di servizi, come server DHCP, DNS, o anche server web, un cluster con VMware FT (o eventualmente HA se può essere tollerato un disservizio di alcuni minuti) offre una protezione più che adeguata.

L’alternativa è quella di ricorrere ad un cluster Microsoft direttamente all’interno di un cluster VMware, in modo da unire i benefici della virtualizzazione ad una continuità di servizio 24h/24 per le applicazioni più critiche. Inoltre, si ha un ulteriore vantaggio, che consiste nella possibilità di “spostare” un’applicazione da una VM ad un’altra senza alcun disservizio, ad esempio se si deve effettuare qualche operazione di manutenzione. E’ da notare però che in questo caso sono supportati cluster solo di alcune versioni di Windows. Per maggiori dettagli consultare i collegamenti seguenti:

roghan

L’importanza dell’ora corretta in un sistema

In un sistema è importantissimo configurare correttamente l’ora. Per tanti motivi. Primo su tutti per l’utilizzo e il controllo dei file di log. Immaginate uno scenario in cui viene portato un attacco ad un server X, ad una determinata ora e giorno, ad esempio il 28 aprile 2010 alle 12.31, ma nel sistema attaccato l’ora impostata è errata e segna il 25 marzo 2009 ore 11.05. Certo questo è un caso limite, ma molto spesso l’ora e la data del sistema differiscono da quella esatta anche pochi minuti. Sono questi pochi minuti che fanno la differenza nel caso di un attacco informatico, o nel caso comunque di un evento da tenere sotto controllo tra più dispositivi di rete. In questi casi, quando l’amministratore andrà a controllare i file di log generati dal sistema potrà avere notevoli problemi a ricostruire i fatti se l’ora è errata, e nel caso di un attacco la differenza nell’ora anche di pochi minuti può causare non pochi problemi. La soluzione è tenere costantemente aggiornata l’ora del sistema. Per quanto riguarda Linux, è possibile configurare manualmente l’ora come spiegato a questo link, ossia:

1. bisogna impostare l’ora con il comando date
date –set 22:20
2. quindi configurare l’ora hardware del sistema con il comando hwclock, perché il comando date automaticamente non aggiorna anche l’ora hardware
hwclock –systohc –utc
[…]

In un sistema è importantissimo configurare correttamente l’ora. Per tanti motivi. Primo su tutti per l’utilizzo e il controllo dei file di log. Immaginate uno scenario in cui viene portato un attacco ad un server X, ad una determinata ora e giorno, ad esempio il 28 aprile 2010 alle 12.31, ma nel sistema attaccato l’ora impostata è errata e segna il 25 marzo 2009 ore 11.05. Certo questo è un caso limite, ma molto spesso l’ora e la data del sistema differiscono da quella esatta anche pochi minuti. Sono questi pochi minuti che fanno la differenza nel caso di un attacco informatico, o nel caso comunque di un evento da tenere sotto controllo tra più dispositivi di rete. In questi casi, quando l’amministratore andrà a controllare i file di log generati dal sistema potrà avere notevoli problemi a ricostruire i fatti se l’ora è errata, e nel caso di un attacco la differenza nell’ora anche di pochi minuti può causare non pochi problemi. La soluzione è tenere costantemente aggiornata l’ora del sistema. Per quanto riguarda Linux, è possibile configurare manualmente l’ora come spiegato a questo link, ossia:

  1. bisogna impostare l’ora con il comando date
    $ date --set 22:20
  2. quindi configurare l’ora hardware del sistema con il comando hwclock, perché il comando date automaticamente non aggiorna anche l’ora hardware
    $ hwclock --systohc --utc

Una soluzione alternativa a questa (e da preferire) è quella di utilizzare il protocollo NTP (Network Time Protocol), con il quale è possibile tenere aggiornata automaticamente l’ora e la data di un sistema (sia su Windows che su Linux), anziché dover impostare i dati corretti manualmente o comunque tramite script. NTP è un protocollo di tipo client/server (con una gerarchia a strati), in cui sul server è configurata l’ora esatta, e il client si collega al server per determinare l’ora e aggiornare così quella del proprio sistema. In figura è visibile l’architettura creata da NTP.

Architettura di NTP

Solitamente nelle LAN di una certa dimensione si preferisce creare un server NTP dedicato, in modo tale che tutti i vari dispositivi si sincronizzino con questo, e questo a sua volta con un server di strato 2. Per reti locali piccole invece (con 2-5 postazioni), o nel caso di utenti singoli che vogliono tenere aggiornata l’ora del proprio pc, è necessario solamente configurare i giusti file su ogni sistema affinché ogni postazione si colleghi autonomamente ad un server di strato 2.

Un importante punto di partenza per configurare NTP in ambiente Linux è questo sito, in cui ci sono anche accenni sulla sicurezza del protocollo (quando possibile si consiglia sempre l’utilizzo della versione 3 e di un server che richiede l’autenticazione). Nel sito ci sono anche riferimenti e descrizioni su come impostare un router Cisco (o altri prodotti) affinché utilizzi un server NTP. Per quanto riguarda la controparte Windows invece, il servizio che si occupa di sincronizzare l’ora è noto come W32Time (Windows Time Service), i seguenti siti contengono tutte le informazioni per configurare correttamente tutti i paramentri:

  • questo sito contiene numerosa documentazione su come sincronizzare una rete Windows con un server NTP
  • sito per la configurazione lato client su Windows XP
  • sito per l’aggiunta di server NTP su Windows XP
  • sito per la configurazione di un server NTP su Windows XP
  • sito per configurare in modo avanzato un server NTP su Windows Server 2003/2008

roghan

%d blogger hanno fatto clic su Mi Piace per questo: