mercoledì 8 settembre 2010   
  Cerca   
 
Registrazione  Accedi  
Blog  
 Cerca nel Blog...    
   
  
 Categorie    
   
  
 ZyRix 1st Blog    
Autore: ZyRix1st Data: 27/10/2008 8.29
HowTo, Guide, Considerazioni su quello che ho realizzato o sul quale ho sbattuto la testa...

Con il vostro fido editor di registro, potete andare a far visualizzare nell'elemento "Data" della schermata "Oggi", anche l'ora!
Il tutto collassato in un'unica, poco invasiva, riga del plugin!

  • Navigate il registro fino a:
    HKLM/Software/Microsoft/Today
  • Create un nuovo valore DWORD
    • Nome della chiave: "AutoSingleLineDatePlugin"
    • Valore: 1 (Dec)
  • Attendere una trentina di secondi e verificare che il nome si è aggiornato
    Oppure effettuate un soft-reset per essere sicuri di refreshare il registro

(fonte dell'articolo: http://eten-users.eu/index.php?showtopic=9596)

Capita quando si aggiornano i dispositivi Windows Mobile-based con Rom "non ufficiali" di trovarsi senza il nome dell'operatore visualizzato (ad esempio perchè come me avete un Glofiish X800 e H3G come operatore)

con una piccola modifica al registro del dispositivo, si possono inserire i nomi personalizzati a partire dai codici operatore:

  • Navigate il registro fino a:
    HKLM/Software/Microsoft/RIL/OperatorNames
  • Create un nuovo valore Stringa:
  • Attendere una trentina di secondi e verificare che il nome si è aggiornato
    Oppure effettuate un soft-reset per essere sicuri di refreshare il registro

( fonte dell'articolo: http://www.etenblog.com/2008/01/03/change-newtwork-operator-name/ )

mi sono imbattuto in questo errore per puro caso, mentre tentavo di riconfigurare exim sulla VM che si autobackupperà  (prossimo articolo...)

Sintomo: qualsiasi operazione di apt-get fallisce, generando errori che riguardano "libxml-sax-perl" oppure "libxml-libxml-perl".
Questo è dannatamente irritante, perchè l'errore è causato da 2 versioni differenti dell'interprete perl e delle sue librerie che cozzano tra loro e soprattutto perchè blocca completamente il sistema del gestore pacchetti.

Per risolverlo, semplicemente:

  • lanciate, come root:
    find /usr/local -name *SAX* -exec rm -fR '{}' \;
  • rimuovete i pacchetti "libxml-sax-perl","libxml-libxml-perl" e "libxml-simple-perl" con apt:
    apt-get remove libxml-sax-perl libxml-libxml-perl libxml-simple-perl
  • re-installata i pacchetti appena tolti:
    apt-get install libxml-sax-perl libxml-libxml-perl libxml-simple-perl

La reinstallazione recupererà i pacchetti ormai corretti dai repository; la parte più difficile è riuscire a disinstallarli...

(fonte dell'articolo: https://bugs.launchpad.net/ubuntu/+source/libxml-sax-perl/+bug/222726)

Quando si procede manipolare una VM basata su Debian (soprattutto se prendete un appliance pre-configurato), è facile che la VM che mandiamo in esecuzione abbia un UUID diverso dall'originale.

VMWare Workstation chiede se volete crearne uno nuovo o mantenere l'esistente quando avviate per la prima volta una VM spostata/copiata; questo invece non accade quando caricare una VM su un ESX/ESXi: in questo caso l'UUID viene sempre ricreato.

Il problema subdolo che sorge è nella gestione delle schede di rete di Debian, che tiene memoria di tutti i MAC Address di tutte le schede di rete che sono state montate nel sistema.
Questo ha come effetto collaterale quello di "rinominare" la eth che di volta in volta, ad ogni cambio di UUID e quindi di MAC Address dei NIC virtuali, è quella "giusta".
Per risolvere il problema all'origine, seguite questi piccoli step:

  • Fermate il servizio networking:
    /etc/inid.d/networking stop
  • Andate a modificare il file di udev dove vengono salvati i vari MAC Address incriminati:
    vi /etc/udev/rules.d/z25_persistent-net.rules
  • Cancellate tutte le righe sotto quelle di commento iniziali (vedrete per l'appunto la "memoria" dell'associazione NIC-MAC)
  • Salvate e chiudete il file
  • Riavviate la VM

Al riavvio udev rileverà nuovamente la scheda di rete attiva ed il sistema tornerà operativo usando la classica eth0.
Nel caso aveste già provveduto alla modifica del file /etc/network/interfaces, la vostra eth0 verrà messa online già con le impostazioni giuste.

(fonte dell'articolo: http://fileformat.wordpress.com/2007/05/11/network-interfaces-for-a-debian-etch-guest-under-vmware/)

A volte si ha la necessità di avere due porte diverse in ascolto per il servizio di Desktop Remoto (RDP) di Windows.
Oppure si ha la necessità di cambiare la porta di default, che è la 3389, con un'altra, per rendere meno ovvia la pubblicazione al pubblico della porta stessa.

Una piccola modifica al registro di sistema, et voilà!

  • Modifica della porta standard (3389)
    • Lanciate un bel regedit
    • Navigare fino a "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp"
    • Modificate l'attributo "PortNumber": attenzione che il valore di default è espresso in esadecimale (HEX)
    • Verificate con un "netstat -na | find "LISTENING"" se tra i risultati c'è un "0.0.0.0:nuova_porta"
      Se c'è, il servizio è in ascolto sulla nuova porta. Potete quindi passare a provare a collegarvi all'RDP su quella porta.
  • Aggiunta di una seconda porta di ascolto
    • Lanciate regedit
    • Navigare fino a "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp"
    • Esportare la chiave in un file
    • Aprite il file appena esportato e modificate il nome "RDP-Tcp" in qualcosa di alternativo ed univoco: ad esempio in "RDP-TcpALT"
    • Modificate l'attributo "PortNumber": attenzione che il valore qui DEVE essere espresso in esadecimale (HEX)
    • Reimportate la chiave così modificata
    • Verificate con un "netstat -na | find "LISTENING"" se tra i risultati c'è un "0.0.0.0:porta_alternativa"
      Se c'è, il servizio è in ascolto sulla nuova porta. Potete quindi passare a provare a collegarvi all'RDP su quella porta.

A volte per applicare le modifiche è necessario riavviare il sistema.
Ricordatevi poi che per connettersi tramite l'RDP Client ad una porta diversa dalla standard dovrete inserire l'IP remoto nel formato IP:porta

(fonte dell'articolo: http://www.networkplumbing.org/2007/09/adding-rdp-port-to-windows-2003.html )

   
  
 Calendario    
   
  
DotNetNuke® is copyright 2002-2010 by DotNetNuke Corporation