Categoria: Tecnica

Pubblicato il

Vmware Vcsa8 – Password di root scaduta

Se hai installato un vcsa8 piu’ o meno di default, la sacdenza delle password e’ impostata a 90 giorni. Siccome di solito le cose vanno nel verso giusto (almeno nei primi 90 giorni) potrebbe capitare che un giorno entri nel vcenter e vedi un paio di errori del tipo “la password di root e’ in scadenza” in giallo e un’altro in rosso “La password di root e’ scaduta”. In realta’ non c’e’ nulla che non funzioni, ma se provi ad entrare nella console del vcsa, quella su porta 5480 per capirci, ti da un errore del genere “Exception in invoking authentication handler user password expired”.

Meno male che risolvere e’ una minchiata: entri in ssh sull’ip del vcsa con la vecchia password.. ci pensa un po’ e poi lui stesso si rende conto che sta dicendo una minchiata e ti dice che la passeword di root e’ scaduta, ti chiede la vecchia password e ti fa inserire la nuova, due vole come al solito. A questo punto puoi entrare nella parte web e correre e cambiare la scadenza da “90 giorni” a “mai”.

Pubblicato il

Vmware – Blank screen editando una VM – Solved

Potrebbe succedere che, mentre provi ad editare una VM ti si presenti una schermata cosi’:

..esatto non si vede nulla. Il problema facilmente risolvibile è dipeso dall’aggiornamento del virtual hardware della VM. Semplicemente, schedula oppure spegni e aggiorna il virtual hardware al livello della tua installazione Vmware

Riavvia la vm e potrai editare i settings della vm.

Pubblicato il

Sessioni telnet che si sconnettono

Se una sessione telnet sta in idle per un pò di tempo, è normale che qualche dispositivo di rete tagli la connessione di rete. Normalmente questo accade quando un client si connette ad un server AS400 e l’operatore si assenta per qualche tempo, quando prova a lavorare sul PC dopo il primo enter viene forzato da rifare il login. Questo ovviamente stressa l’operatore. Per ovviare a questo problema si allunga il timeout tcp delle sessioni del firewall, che nel caso Sonicwall sono a 15 minuti e si modificano a 60 minuti. Però puo’ accadere che la sessione venga interrotta da qualche device che non è sotto il nostro diretto controllo. A questo punto si può ricorrere al tcp-keepalive sul server stesso. La soluzione è stata risolta su una macchina linux. Occorre soltanto modificare tre parametri del kenel:

net.ipv4.tcp_keepalive_time=60 # Quanti secondi passano prima di inviare una probe
net.ipv4.tcp_keepalive_intvl=30 # Quanti secondi passano prima di inviare una probe se non ottengo risposta
net.ipv4.tcp_keepalive_probes=6 # Dopo quanti tentativi senza risposta avvisa l’application layer che la sessione è stata interrotta.

I valori scelti sono stati decisi dopo alcuni test. Potresti volerli modificare.

Pubblicato il

Make sure that any services that have a space in their path are enclosed in quotes

Con Windows 11 il wmic non funziona dunque apri una powershell con diritti amministrativi e incolla questo script:

Get-CimInstance Win32_Service | ForEach-Object {
$path = $_.PathName
if ($path -match ‘ ‘ -and $path -notmatch ‘^”.*”$’) {
[PSCustomObject]@{
Name = $_.Name
PathName = $path
}
}
} | Format-Table -AutoSize

Dovresti vedere un output di questo tipo: si vede bene chi ha spazi nella path senza avere le ‘virgolette’

ProfSvc C:\Windows\system32\svchost.exe -k UserProfileService -p
PushToInstall C:\Windows\System32\svchost.exe -k netsvcs -p
QNAPQVPNConnectionService C:\Program Files (x86)\QNAP\QVPN\QVPNConnectionTool.exe
QWAVE C:\Windows\system32\svchost.exe -k LocalServiceAndNoImpersonation -p
RasAuto C:\Windows\System32\svchost.exe -k netsvcs -p
RasMan C:\Windows\System32\svchost.exe -k netsvcs

Pubblicato il

Vmware :: NFS Storage :: inaccessibile dopo power failure

In questo caso si deve procedere in questo modo.

  1. De-registra tutte le VM che sono sopra NFS. Se non ce ne sono meglio cosi’.
  2. Prendi nota di come si chiama il datastore, l’ip del server NFS, il tipo di NFS, l’export della directory del server NFS
  3. Smonta il datastore
  4. Crea un nuovo datastore con lo stesso nome, dovresti riuscirci con le info che ti sei annotato prima.
  5. Eventualmente ri-registra le VM che trovi sul datastore.

Pubblicato il

Vmware – spostare management da una rete ad un’altra

  1. Mettere l’host in maintenance mode
  2. Sconnettere l’host da Vcenter
  3. Rimuovere l’host dall’inventario
  4. Attraverso ILO oppure da console del vsphere cambiare l’ip di management/vlan
  5. Connettere l’host al Vcenter con il nuovo IP oppure con il nuovo nome
  6. Restart dell’host (a volte non vede NFS senza alcun motivo)
  7. Uscire dal maintenance mode
  8. Controllare di avere accesso ai vari NFS o iScsi (potrebbero essere sulla stessa net)
  9. Controllare eventuali policy firewall che coinvolgono la nuova rete
  10. Riavviare il server, meglio fare un ‘cold start’.
  11. Cambiare l’ip nel DNS
  12. Facendo questa procedura cambia l’UUID del nodo e Config.HostAgent.plugins.solo.enableMod si disabilita.

Per vedere l’UUID di un nodo vmware, abilitare SSH e inputare questo comando:

[root@localhost:~] esxcli system uuid get

Pubblicato il

Centos Rocky – Aumentare spazio disco su una VM senza LVM (non disco principale)

Potresti aver bisogno di aumentare lo spazio di una partizione normale ovvero non LVM. Elenco i passi da seguire per effettuare questa modifica:

  1. Individua il disco che devi aumentare la capacità, nel mio caso è un disco montato su /opt con file system EXT4 che era 70GB e dovrei espanderlo a 100GB
  2. Spegni la VM in maniera corretta con shutdown/poweroff
  3. Sulla parte Vmware (Settings della VM) espandi il disco da 70GB a 100GB
  4. Fai uno snapshot della VM ora, da spenta e con il disco gia’ esteso dal punto precedente
  5. Ora fai ripartire la VM, in realta’ non succede nulla, solo se fai un “fdisk -l” vedi che il tuo disco ha 30GB di spazio libero.
  6. Smonta il disco, tieni presente che il mio era un disco aggiuntivo e non quello di ‘root’ ovvero “/” – Nel mio casoil comando era ‘umount /opt’ – Sfortunatamente la risposta del sistema era ‘target busy’ in quanto parecchi servizi attivi utilizzavano quel disco. Occorre armarsi di pazienza e attraverso ‘lsof /opt’ annotasi i processi che utilizzano /opt e fermarli in un modo corretto oppure con un ‘killall process_name’
  7. Ora evi solamente spostare i puntatori di ‘fine partizione’ di 30GB più avanti. Per questo ti viene in aiuto ‘parted’ che fa questo lavoro. Nel mio caso il disco era sdc quindi il comando nel mio caso era ‘parted /dev/sdc’ . Ora dei dentro all’applicazione fai ‘print free’ e vedi lo spazio libero e occupato del disco sdc. Ora puoi fare “resizepart 1 107GB” che effettuerà il resize della partizione 1 del disco /dev/sdc con un size di 107GB totali. Attenzione a non dare un numero di GB inferiore a quello che è la partizione originale.
  8. Ora fai ripartire la VM perche’ il kernel deve aggiornare i suoi registri al nuovo spazio del disco.
  9. Ora devi effettuare il resize della partizione ext4 con il comando “resize2fs /dev/sdc1” che aumenta lo spazio del file system ext4. Se ora fai “df -h’ vedrai che il tuo disco è aumentato dei GB che gli hai dato.

Pubblicato il

Sonicwall – Alta affidabilità – Sostituzione dell’unità primaria

Hai una coppia di Sonicwall ad alta affidabilità e un giorno trovi che l’unità secondaria è attiva mentre la primaria è deceduta. Qui elenco gli step da seguire per sostituire l’unità primaria. E’ da capire bene che le unità sono primaria e secondaria e mai si scambieranno questi ‘ruoli’. Quello che invece cambia è l’unità attiva e l’unità in standby. Questo occorre che te lo metti bene in testa. La secondaria nasce secondaria e muore secondaria anche se resta attiva per 6 anni, uguale la primaria, nasce e muore primaria.

Il problema principale è che non si può ‘promuovere’ a primaria una unitò secondaria. Il secondo problema è che l’unità secondaria non ha la possibilità di cambiare il serial number della primaria; se ti logghi sulla tua unità secondaria che ora è attiva noterai che non puoi cambiare il serial number della primaria. Se segui questi passi avrai un minimo disservizio ma pianificato da te e quindi di poco impatto sulla tua struttura.

Ora hai la nuova unità che diventerà la tua unità primaria, nuova appena arrivata dal supporto Sonicwall. Segnati tutti i cavi esattamente su che interfaccia devono essere connessi, delle bandierine fatte con il nastro di carta con sopra scritte le interfaccie aiutano molto.

  1. Fai partire la tua nuova unità e registrala su mysonicwall.
  2. Aggiorna il firmware della nuova unità, dovresti aver l’ultimo firmware sulla tua unità secondaria attiva, fai in modo che il firmware della nuova unità sia di versione uguale o più aggiornata della tua unità secondaria.
  3. Esporta i settings della secondaria attiva e importali sulla primaria senza collegarla alla tua rete di produzione, questo lo puoi fare attraverso l’interfaccia di management con ip 192.168.1.254 oppure attraverso la X0 che se l’unità è in default settings ha ip 192.168.168.168
  4. Dovresti controllare che le interfacce ora hanno gli ip come hai sull’unità secondaria attiva e magari le VPN, se tutto ok come dovrebbe, significa che l’import dei settings è andato a buon fine.
  5. Ora vai nella gestione dell’alta affidabilita settings e metti ‘none’ anzichè ‘active/passive’ questo significa che la tua unità opera in modalità stand-alone e non è più un primario.
  6. E’ arrivato il momento che dovrai dare del disservizio alla tua rete, ma come vedi, è pianificato da te quindi lo potrai fare quando più ti aggrada, non aver fretta, la tua unità primaria è andata avanti per anni, lo stesso molto probabilmente potrebbe fare la secondaria: non c’e’ fretta. Ora connetti tutti i cavi che erano connessi alla tua vecchia unità primaria alla tua nuova unità primaria mantenendola spenta. I cavi erano stati segnati con delle bandierine con scritto X0 X1 X2 non puoi sbagliarti. Prenditi il tuo tempo.
  7. Ora spegni la tua unità secondaria attiva, la tua rete subirà un disservizio ora.
  8. Accendi la tua nuova unità primaria, che dovrà effettuare il bootstrap questo tempo è importante, in quanto tutti i tuoi switch devono ‘dimenticare’ il mac address della tua unità secondaria. Lascia che la tua rete stia down per il tempo necessario al bootstrap della tua nuova unità primaria, è importante questo tempo.
  9. Dopo circa 5 minuti la tua nuova unità deve essere raggiungibile e puoi fare il login al portale di management SoniOS della tua nuova unità primaria. Ora la tua nuova unità sta operando come unità stand-alone.
  10. Controlla che tutto stia funzionando correttamente con la nuova unità e quando sei sicuro vai al prossimo step. Ovviamente se qualcosa non dovesse andare puoi spegnere la macchina nuova e riaccendere la vecchia e in altri 5 minuti tutto è nuovamente attivi sulla macchina secondaria.
  11. Da qui in poi non c’e’ più la possibilità di tornare indietro, devi essere sicuro che la tua nuova unità funzioni perfettamente.
  12. Ora è il momento di ripristinare il cluster ad alta affidabilità. Per far questo sconnetti la il firewall secondario dalla rete di produzione. Collegalo al tuo pc accendilo esegui il login e fallo ripartire in factory default. Deve essere pulito della configurazione esattamente come se fosse nuovo e quindi occorre inserirgli il ‘registration code che trovi in mysonicwall.
  13. Ora collega solo interfaccia che hai destinato alla alta affidabilità e accendi il firewall che tra poco diventerà nuovamente secondario del tuo nuovo firewall primario. Prendi nota del seriale del firewall secondario che dovrai inserirlo nel settings di alta affidabilità del primario.
  14. Fai login sul primario e imposta nel settings dell’alta affidabilità, l’interfaccia dedicata e il seriale. Sul firewall secondario deve esserci solo l’interfaccia HA connessa all’altro firewall. Dovresti vedere che lo stato del HA ora ha un primario in active e un secondario che subito dovrebbe essere in ‘none’ ma dopo qualche decina di minuti, dovrebbe andare in ‘standby’. Noterai che l’unità secondaria effettua alcuni reboot, non preoccuparti è normale.
  15. Quando lo stato del HA mostra primario ‘active’ e secondario ‘standby’ puoi collegare tutti i cavi a secondario. Abbiamo terminato la configurazione del nuovo primario.
  16. Ora dovresti testare il cluster, prova a fare un “Forse Active/Standby failover” da settings HA – Devi resettare il flag “Enable Preempt Mode” se fosse attivo.
  17. Non dimenticare aggiornare la registrazione su mysonicwall del nuovo primario che dovrà avere un secondario con il seriale del tuo vecchio secondario.