



Dopo diversi mesi mi sono ritrovato a fae una migrazione da NT4 a Windows Server 2003e quindi Active Directory:
Come scrissi appunto nel mio blog, per fare questo mi ero affidato a Virtual Server 2005 R2 perchè una volta avviato l’upgrade, al reboot mi veniva restituita una bella schermata blu, con VMware Server 1.0.
Pensando che fosse un problema di tale prodotto, usai appunto VS, ma stavolta avendo a disposizione ESX 3.5 ho pensato “no, deve andare!!!!”
Ed infatti ho scoperto che il problema è che Windows Server 2003 non vede i dischi BusLogic SCSI, quindi è necessario passargli il driver via floppy (virtuale) prendo F6 al primo reboot.
I driver sono disponibili qui, buon upgrade!




Allora qui il fatto è il più complesso, infatti io nel mio dns aziendale utilizzo 3 view, una per la lan, una per l’esterno e una per le vpn:
Quadno veniva fatto lo zone transfer, però passava solo una zona, o meglio sul server secondario venivano si passati 3 file, ma idendici! (la zona internal).
La soluzione è avere un indirizzo ip sul secondario per ogni zona da trasferire, si lo so è un pò vago ma una soluzione dettagliata la trovate qui, ora non ho tanta voglia di scrivere (sono impegnato da facebook!
)




Oramai qualsiasi server che faccio è “made Ubuntu”, però questa cosa mi ha dato del filo da torcere!
Praticamente quando effettuavo il classico zone transfer, mi veniva restituito un errore del tipo dumping master file: tmp-5L67ipnxc9: open: permission denied però mi è parso subito strano, perchè la cartella sotto /etc/bind/slave era di proprietà di Bind e con i giusti permessi! Doh!
Pare leggendo sui forum che sia dovuto a qualche non meglio precisato errore sull’assegnazione dei permessi…mha… non ho indagato più di tanto.
Fa sta che ho settato come directory per ospitare i file la dir /var/cache/bind ed il trasferimento di zona è bello e servito!




Qualche giorno è capitato che un server di Exchange sia stato vittima di un Directory Harvest e quindi che la coda si sia pienata di schifezze (si lo so, mea culpa era attivo l’invio del NDR).
Comunque sia di default non c’è possibilità di pulire in un sol colpo la coda, se non con il solito “clikka sul primo, clikka sull’ultimo elemento, prmi il tasto destro ed elimina senza inviare NDR – qui -”…decisamente pessimo!!!
In nostro soccorso viene AQADMCLI che con queste semplici tre righe permette di “spurgare” la nostra coda!
setserver nomeserver
delmsg flags=all
quit
E questo pulisce tutto.




Stavo migrando alcuni dei miei server Ubuntu 8.04 da VMware Server 1.0.6 ad ESX 3.5 con l’apposito VMware converter, fino a qua tutto ok, finita la migrazione faccio la ripartire la macchina, aggiorno i tools e…argh!!!
Dove sono le schede di rete?? Ripartendo le macchine, anche con i drivers vmxnet corretti non vogliono sapere di andare su…poi mi sono ricordato di lui…udev!
Infatti per evitare che ad ogni riavvio il nome delle schede di rete sia scelto a caso, udev si annota i mac address delle schede di rete, assegnando i rispettivi MAC a eth0, eth1 e così via.
Ovviamente nel nuovo ESX server ci saranno mac diversi, quindi dovremmo cancellare questa info, per fare questo cancellate qui
sudo rm /etc/udev/rules.d/70-persistent-net.rules
Dopo un restart dovreste trovarvi con le interfacce attive.




Non sono sparito eh!
Ma in questo periodo sto lavorando anche la sera alla ristrutturazione interna della nostra azienda, con il rifacimento dei server, della rete….insomma una cosa radicale!
Abbiamo anche studiato soluzioni nuove (almeno per noi!), ecco un piccolo elenco:
Quindi con tutto questo mi rimane poco tempo!


More Options ...
Categorie
Tag Cloud
Blog RSS
Comments RSS

Void « Default
Life
Earth
Wind
Water
Fire
Light 