Il blog di DiRete
Sessione remota terminal e console
Oggi son diventato matto con un cliente che non riusciva a collegarsi in console via terminal service su un server 2003. Il client di connessione RDP gli dice che il parametro /console è sconosciuto.
Ho ipotizzato si trattasse di un problema di aggiornamento del client, poiché la versione 5.x non supportava le connessioni console (c.d. session 0) mentre la versione 6.0 le supporta
Tentando di installare l’update, però, windows dichiara che la versione di service pack installata è già più recente … mumble mumble mumble … svelato l’arcano: la nuova versione (6.1) ha cambiato le opzioni !!! Ora è necessario utilizzare il parametro /admin come meglio spiegato in questo documento che, tra l’altro, vi chiarirà per benino la differenza tra una sessione console ed una non console:
http://blogs.sysadmin.it/ermannog/archive/2008/07/28/3032.aspx
Accedere a una rubrica condivisa di Kerio Mail Server
Tutte le volte cerco l’articolo di knoledgebase … e allora mi son detto: x’ nn metterlo nel blog?
Scenario: Kerio Mail Server con rubrica condivisa
Obiettivo: accedere alla rubrica dal client di posta
Windows XP, Outlook 2003/2007
ecco la soluzione: http://support.kerio.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=207 (attenzione al ctrl k per far cercare il contatto quando si digita nel campo a: … altrimenti nn funziona 😉
Windows XP, Thunderbird
ecco la soluzione: http://www.csita.unige.it/manuali/thunderbird/rubrica-ldap.html
Mac OSX, Mail e Address Book
ecco la soluzione: http://support.kerio.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=136
😉
Attiva la BTS Monte Colmo
E’ attiva la BTS Monte Colmo per la copertura della Valle Sabbia.
Chi ha avuto un KO da altre BTS ed è in quella zona forse ha una nuova speranza … e chi sperava che arrivasse EOLO … è ora accontentato!
Ecco un’anteprima della copertura:
EOLO Voce, parte la fase di test!
Se volete avanzare la vostra candidatura per entrare a far parte dei 30 beta tester di EOLO VOCE, compilate il modulo, indicando come login e password quelle di connessione ad EOLO:
http://www.eolo.it/voceBeta/
p.s.: cos’è EOLO VOCE? Easy! La soluzione voip specifica per EOLO, per la quale ci sono maggiori garanzie di buon funzionamento grazie al quality of service attivo, possibile solo grazie al fatto che l’apparato (port adapter) andrà montato subito a valle della radio, prima del pc o del router e comunicherà con il centralino voip di NGI su una VLAN diversa da quella standard. Per i più tecnici … l’infrastruttura di EOLO è LAYER2, quindi, senza un “barbatrucco” come quello delle VLAN non c’è modo di fare quality of service (o … traffic shaping, per vederla dall’altro lato): ecco svelato il motivo unico e reale che testimonia perché su EOLO NON ci sono filtri per il p2p: filtrare da Settimo Milanese verso il mondo non ha senso per chi, come EOLO ha banda limitata sulle radio, non certo sulle fibre in datacenter 😉
Recuperare i product key di un prodotto Microsoft installato
Segnalo questa ottima utility: serve per trovare il product key dei prodotti MS installati su una macchina: da quello di Windows a quello di Office.
Problemi su EOLO
Questa notte si sono verificati problemi di discontinuità del servizio EOLO.
I tecnici hanno lavorato a lungo ed ora le linee sembrano stabili. Se avremo ulteriori aggiornamenti aggiorneremo questo post.
Skyluke, il CEO di NGI bloccato in alta quota!
Quando si dice “customer care”: una BTS non va e lui pronto corre, anzi, letteralmente vola (in elicottero) a riparla …
ma poi …
Leggete qui !!!
Emule ed EOLO
Da più parti in questi giorni ci vien fatta la stessa domanda: il download DA EOLO con EMULE è limitato?
Premesso che bisognerebbe chiederlo a NGI, e che DiRete non ha mezzi per guardar fisicamente i router del provider, la risposta è, secondo Luca Spada (CEO di NGI, il provider): NO!
A ben vedere ci sono anche ragioni tecniche che, conoscendo l’infrastruttura, mi farebbero deporre per il NO … ma esporle servirebbe a poco, vista l’insistenza delle domande. Quindi … ecco l’idea: abbiamo 2 linee … facciamo un bel test!
La prima prova, da EOLO a EOLO dà i risultati che immaginavamo: banda PIENA al 100%. Qualcuno potrebbe dire: “bella scoperta” ma (e accenno brevemente alle ragioni tecniche di cui parlavo poc’anzi) sapendo che la parte critica di distribuzione della banda sono le celle radio, e non certo le fibre ottiche di interconnessione del datacenter di NGI/EOLO con Internet, ci si poteva aspettare che la strettoia fosse a livello radio del cliente (qui, xò … chi sa che significa avere un’infrastruttura layer2 si metterà a ridere …)
Passiamo quindi alla seconda prova, da EOLO download di file che si trova su ADSL TISCALI:
Come prima cosa facciamo in modo che entrambe le installazioni del Mulo partano con ID ALTO (easy, direi), quindi …
facciamo un test di velocità.
<ADSL>
Ultimo risultato:
Velocità in download: 4120 Kbps (515 KB/sec)
Velocità in upload: 162 Kbps (20.3 KB/sec)
Test eseguito alle: 15:2 del: 3/11/2008
</ADSL>
<EOLO>
Ultimo risultato:
Velocità in download: 3943 Kbps (492.9 KB/sec)
Velocità in upload: 527 Kbps (65.9 KB/sec)
Test eseguito alle: 15:6 del: 3/11/2008
</EOLO>
Mettiamo quindi una share sul mulo che sta sull’ADSL e proviamo a sfruttare la sua banda in UP, senza limitazioni. Il valore teorico (da test) è di poco più di 20 Kbps
Facciamo partire il Mulo sulla macchina che sta su EOLO, cerchiamo il file e mettiamolo in download.
Ecco il risultato:
Ancor più di quanto ipotizzato dal test.
Considerate che è una 4M/256, quindi, di fatto, stiamo facendo upload a qcosa più di 200 Kbps …
Che dire? Certo, se avessi una linea più prestazionale potrei fare altri test, ma il primo mi sembra già parlar chiaro …
La sicurezza delle reti wireless …
Spesso ci siamo sentiti chiedere “quanto sono sicure le reti wireless?”
Non esiste una risposta valida per tutte le stagioni, poiché, evidentemente, tutto dipende da come vengono configurate. Gli apparati radio che fanno la diffusione (c.d. “access point”), infatti, tipicamente escono dalle fabbriche con una configurazione standard volta al c.d. “zero configuration” o, per così dire, al “plug & play”. Infatti, se ci pensate, si apre la scatola, si attaccano alla rete e si comincia a navigare senza fili. Di default, quindi, l’apparato esce dalla scatola SENZA alcun tipo di sicurezza attivo:
- la rete wireless è impostata come “visibile”, mentre potrebbe essere disattivato l’invio del SSID (ovvero il nome della rete come è vista dai client)
- la crittografia è spenta, mentre potrebbe essere configurato il WEP o, meglio ancora, il più sicuro WPA (con chiave di autenticazione fissa e chiavi di crittografia variabili)
- il controllo dei mac address non è attivo, mentre si potrebbe abilitare la white list di device autorizzati bloccando, in automatico tutti gli altri
Quindi, nella sua configurazione “di default”, un access point ha tipicamente un livello di sicurezza persino inferiore rispetto a quello che otterreste prendendo una manciata di cavi piuttosto lunghi, attaccandoli al vostro switch e buttando l’estremità opposta fuori dalla finestra fino a giungere in strada.
Quando configurate un Access Point, quindi, dedicate 5 minuti (cinque !!!) alle impostazioni di sicurezza, è veramente importante e ne va della vostra sicurezza! Nel 2008 Vi sembra banale? Beh … non lo è affatto: provate ad accendere la scheda di rete wifi del vostro portatile o del vostro palmare nel nuovo centro commerciale “freccia rossa” di Brescia, nell’area dedicata al ristoro. Scoprirete un’ottima copertura realizzata da un apparato con SSID Netgear, senza crittografia o autenticazione di qualsivoglia natura, con tanto di DHCP che vi assegna un indirizzo valido e un po’ più di 2 Megabit di banda a disposizione su connessione adsl Telecom Italia. Che dire … c’è ancora molto da fare!
Condivisioni windows 2003 non visibili da mac osx?
Avete configurato tutto correttamente. Il client mac vede il server sulla rete (risolve il nome correttamente e raggiunge la macchina via tcp/ip). L’utente ha i permessi giusti. Fate Mela+K e scrivete cifs://xxx.xxx.xxx.xxx … arriva la richiesta di nome utente e password. Li digitate, sono corretti ma … vi dice “accesso negato”. Negli eventi di Windows 2003, invece, appare il log dell’avvenuta (corretta) connessione. Che fare?
Beh, è una fesseria, ma se nn lo sapete non ci arriverete mai! Windows 2003 server è impostato per cifrare SERMPRE le connessioni client-server e questo, nella comunicazione Windows <-> Mac non è possibile.
Quindi, come risolvere? Semplice! Sul server andate in Strumenti di amministrazione -> Criterio di protezione del controller di dominio -> Impostazioni protezione -> Criteri Locali -> Opzione di protezione -> Server di rete Microsoft: aggiungi firma digitale alle comunicazioni (sempre) (okkio che c’è anche la versione “se autorizzato …”) -> disattivatelo!
quindi, da linea di comando (sempre sul server) gpudate e … il gioco è fatto 😉