How To Extend Datastore Capacity in the vSphere Client When your Datastore require more space, you can dynamically increase the capacity

Use one of the following methods to increase a VMFS datastore:

  • Add a new extent. An extent is a partition on a storage device. You can add up to 32 extents of the same storage type to an existing VMFS datastore. The spanned VMFS datastore can use any or all of its extents at any time. It does not need to fill up a particular extent before using the next one.
  • Grow an extent in an existing VMFS datastore, so that it fills the available adjacent capacity. Only extents with free space immediately after them are expandable.

Note
If a shared datastore has powered on virtual machines and becomes 100% full, you can increase the datastore’s capacity only from the host with which the powered on virtual machines are registered.

Prerequisites

Required privilege: Host.Configuration. Storage Partition Configuration

Procedure

Log in to the vSphere Client and select a host from the Inventory panel.

Click the Configuration tab and click Storage.

From the Datastores view, select the datastore to increase and click Properties.

Extend Datastore ESXi
Extend Datastore ESXi
Click Increase.

Select a device from the list of storage devices and click Next.

Extend Datastore ESXi
Extend Datastore ESXi
Extend Datastore ESXi
Extend Datastore ESXi

Option

To add a new extent – Select the device for which the Expandable column reads NO.

To expand an existing extent – Select the device for which the Expandable column reads YES

Review the Current Disk Layout to see the available configurations and click Next.

Select a configuration option from the bottom panel.

Depending on the current layout of the disk and on your previous selections, the options you see might vary.

Option

Use free space to add new extent – Adds the free space on this disk as a new extent.

Use free space to expand existing extent – Expands an existing extent to a required capacity.

Use free space – Deploys an extent in the remaining free space of the disk. This option is available only when you are adding an extent.

Use all available partitions – Dedicates the entire disk to a single extent. This option is available only when you are adding an extent and when the disk you are formatting is not blank. The disk is reformatted, and the datastores and any data that it contains are erased.

Extend Datastore ESXi
Extend Datastore ESXi

Set the capacity for the extent.

The minimum extent size is 1.3GB. By default, the entire free space on the storage device is available.

Click Next.

Extend Datastore ESXi
Extend Datastore ESXi

Review the proposed layout and the new configuration of your datastore, and click Finish.

Extend Datastore ESXi
Extend Datastore ESXi

What to do next

After you grow an extent in a shared VMFS datastore, refresh the datastore on each host that can access this datastore, so that the vSphere Client can display the correct datastore capacity for all hosts.

Related Article: Increase VMFS Datastore Capacity in the vSphere Client

Initial Network Setup with UBUNTU Server Main steps to configure newtwork services on Linux Ubuntu Server

How do I change the hostname without a restart?

sudo hostname your-new-name

Assigning a static IP to Ubuntu Server

vi /etc/network/interfaces

Example:

auto eth0
 iface eth0 inet static

address 192.168.1.128
 netmask 255.255.255.0
 network 192.168.1.0
 broadcast 192.168.1.255
 gateway 192.168.1.1

How to disable IPv6 in Ubuntu?

vi /etc/sysctl.conf

insert the following lines at the end:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Linux Proxy Server Settings – Set Proxy For Command Line

env | grep -i proxy

check the file :

cat /etc/apt/apt.conf
cat /etc/environment

To Modify contents of file (remove everything from apt.conf for no proxy and only proxy sentences from environment)!

sudo nano /etc/apt/apt.conf
sudo nano /etc/environment
Acquire::http::Proxy "http://proxy.site.com:8080";

Manually edit DNS in Ubuntu

sudo nano /etc/resolvconf/resolv.conf.d/base

Add your DNS to the file :

nameserver 8.8.8.8
nameserver 8.8.4.4

Update resolv configuration:

sudo resolvconf -u

Setting up NTP on Ubuntu

sudo apt-get install ntp ntpdate

sudo nano /etc/ntp.conf

server myserverdnsname1 or IP
server myserverdnsname2 or IP
server myserverdnsname3 or IP

sudo service ntp start

sudo ntpd -gq

watch ntpq -cpe -cas

Grab you Ubuntu server HERE

Come ottenere con PowerCLI il provision dei datastore Datastore provisioning con PowerCLI

Ecco un semplice comando da lanciare con PowerCLI (o Powershell)  per ottenere la lista dei Datastore e dei GB di provisioning per ognuno di essi:

Get-Datastore | Select Name, Datacenter,CapacityGB,FreeSpaceGB, @{N=”Provisioned (GB)”; E={[math]::round(($_.ExtensionData.Summary.Capacity – $_.ExtensionData.Summary.FreeSpace + $_.ExtensionData.Summary.Uncommitted)/1GB,2) }}| Sort-Object -Property Name  | Export-Csv C:\report.csv -NoTypeInformation -UseCulture

Il comando nello specifico esporta la lista che si genera in un file CSV. Per ottenere una schermata con solo la lista, bisogna togliere il ‘| Export-Csv C:\report.csv -NoTypeInformation -UseCulture’, quindi così:

Get-Datastore | Select Name, Datacenter,CapacityGB,FreeSpaceGB, @{N=”Provisioned (GB)”; E={[math]::round(($_.ExtensionData.Summary.Capacity – $_.ExtensionData.Summary.FreeSpace + $_.ExtensionData.Summary.Uncommitted)/1GB,2) }}| Sort-Object -Property Name

Fortinet: la rete wireless aziendale è poco sicura

Link Articolo Originale

Secondo una nuova ricerca di Fortinet, il 90% dei CIO è preoccupato dell’insufficiente protezione wireless e un terzo delle aziende manca delle misure minime di sicurezza wireless.

Secondo quanto emerge da una nuova indagine globale commissionata da Fortinet all’istituto di ricerca indipendente Lightspeed GMI, i decision maker IT (ITDM) sono convinti che le reti wireless rappresentino l’elemento più vulnerabile dell’intera infrastruttura IT. La ricerca ha rivelato infatti che quasi la metà degli intervistati (49%) ha classificato le reti wireless come le più esposte dal punto di vista della sicurezza, in contrasto con un 29% che lo pensa riferendosi alla rete principale.

L’indagine, condotta su circa 1.490 decision maker di aziende con più di 250 dipendenti, ha svelato inoltre che la scarsa sicurezza del wireless è fonte di preoccupazione per il 92% dei CIO intervistati, il che sorprende poco, visto che oltre un terzo delle reti wireless aziendali implementate per i dipendenti non sono in possesso delle funzionalità di autenticazione minime.

Solo il 29% considera l’infrastruttura di rete principale la più vulnerabile, con database (25%), applicazioni (17%) e infrastrutture storage (11%) distanziate e considerate poco suscettibili dal punto di vista della sicurezza. Il 37% degli intervistati ha inoltre dichiarato di non avere predisposto misure di autenticazione per la sicurezza wireless.

Un significativo 29% e 39% delle aziende sottovaluta rispettivamente le funzionalità di sicurezza firewall e antivirus quando si parla di strategie wireless. Altre misure di sicurezza ritenute fondamentali nella protezione dell’infrastruttura principale, quali IPS (implementata dal 41%), application control (37%) e URL filtering (29%), sono ancora più trascurate nelle implementazioni wireless.

QUASI LA METÀ DEGLI ITDM INTERVISTATI (43%) METTE A DISPOSIZIONE DEI PROPRI OSPITI UN ACCESSO ALLE PROPRIE RETI WIRELESS AZIENDALI

L’83% dei decision maker IT è preoccupato del fatto che la sicurezza delle proprie reti wireless non sia sufficiente. Nonostante abbiano implementato i più elevati livelli di sicurezza tra le varie regioni, gli ITDM dell’area APAC sono i più preoccupati, con il 44% che dichiara di essere “estremamente preoccupato”, in contrasto con il 30% nelle Americhe e il 20% in EMEA.

Alla domanda sui rischi principali derivanti da una rete wireless non sicura, il 48% degli ITDM ha considerato la perdita di dati sensibili aziendali o dei clienti come il pericolo maggiore, mentre al secondo posto troviamo lo spionaggio industriale (22%), seguito dalla mancata conformità alle normative del settore (13%), dall’interruzione dei servizi e dal danno alla reputazione aziendale (entrambi al 9%).

Quasi la metà degli ITDM intervistati (43%) mette a disposizione dei propri ospiti un accesso alle proprie reti wireless aziendali, con il 13% che lo fa senza alcuna forma di controllo. La modalità più diffusa è rappresentata da username e password temporanei (46%), che precedono un portale controllato che richiede le credenziali (36%).

“I risultati dell’indagine indicano come, a dispetto della crescita delle strategie legate alla mobility, la sicurezza wireless non sia al momento una priorità per le aziende. Poichè gli advanced persistent attack prendono sempre più di mira molteplici punti di accesso e il cloud sta diffondendosi notevolmente, le aziende non possono più permettersi di rischiare così tanto” ha dichiarato John Maddison, vice president of marketing products di Fortinet.

Shellshock, una nuova vulnerabilità. Forse ancora più grave di Heartbleed

Articolo Originale

Il bug della shell Bash

Nel corso della giornata di ieri è stata portata all’attenzione del pubblico la scoperta di un bug molto pericoloso per tutti i sistemi operativi Unix-based: si tratta di Shellshock o Bash-bug, una vulnerabilità presente in realtà da lungo tempo e che permette, se opportunamente sfruttata da un attaccante, di eseguire codice arbitrario non appena la shell viene invocata, lasciando così aperta la possibilità di portare un’ampia varietà di attacchi. I sistemi Windows non sono toccati dal problema.

Abbiamo già avuto modo di osservare come la vulnerabilità sia molto semplice da sfruttare, appoggiandosi ad esempio a software e programmi già presenti sul sistema bersaglio e che fanno normalmente uso della shell per compiere le proprie operazioni. Tra il pomeriggio e la notte la situazione si è evoluta, e purtroppo le notizie attualmente in circolazione non sono per nulla buone, indicando come la vulnerabilità sia attivamente sfruttata da malintenzionati e come molte patch della prima ora si stiano rivelando inefficaci.

E’ fortemente probabile che i principali bersagli saranno server web e dispositivi di rete, con le applicazioni web PHP-based che saranno particolarmente vulnerabili. Ma il problema non è limitato solamente a computer, server o dispositivi di rete: i nuovi “smart devices” e più in generale tutto ciò che si può ascrivere all’universo “Internet of Things” possono rivelarsi vulnerabili specie sul lungo periodo, dal momento che spesso il rilascio di patch per questo genere di dispositivi avviene lentamente. Insomma, i sistemi suscettibili agli attacchi che possono sfruttare Shellshock sono veramente numerosi e come David Jacoby di Kaspersky Lab ha spiegato, la “reale portata del problema ancora non è chiara”.

Il ricercatore di sicurezza Robert David Graham di Errata Security ha già provato ad eseguire un IP scan di portata limitata, individuando circa 3000 sistemi vulnerabili prima che lo scan andasse in crash. Graham ha sottolineato come fossero particolarmente a rischio i webserver embedded su porte non convenzionali.

Il problema, però, è che lo script realizzato da Graham a scopi di test è stato utilizzato da anonimi malintenzionati come base per realizzare un worm per scaricare malware. Il worm è già stato ribattezzato “Thanks, Rob” per rendere credito, in modo canzonatorio, al ricercatore di Errata Security. Usando la stessa tecnica, quindi, è già stato possibile innescare un meccanismo per il quale un sistema bersaglio viene attaccato sfruttando Shellshock, infettato ed indotto ad effettuare a sua volta uno scan per ricercare nuovi bersagli che a loro volta ripeteranno l’operazione. E’ facile comprendere, come la cosa possa velocemente sfuggire di mano.

Dati questi presupposti, il rischio è che si verifichi una situazione simile a quanto causato nel 2003 da SQL Slammer, un worm che, propagandosi ad effetto domino in 12 minuti, ha portato ad un pesante rallentamento del traffico su Internet. La differenza sostanziale, però, risiede nel fatto che SQL Slammer faceva uso solo di alcune porte specifiche, mente la vulnerabilità Shellshock può essere sfruttata con qualsiasi porta (il test eseguito da Graham ha usato, per esempio, la porta 80). Il worm SQL Slammer fu inoltre rilasciato dall’autore nel corso di un venerdì, per altro con un qualche genere di avvertimento. Un worm come “Thanks, Rob”, invece, può essere creato da chiunque abbia un minimo di dimestichezza ed essere diffuso quindi senza alcun avvertimento.

Intanto alcuni provider di servizi Internet confermano che la vulnerabilità Shellshock è attivamente sfruttata. CloudFlare, un network di distribuzione di contenuti, ha già disposto una serie di regole per il firewall web-app allo scopo di proteggere i sistemi, ma alcuni hacker hanno già tentato numerosi attacchi utilizzando il worm. “Abbiamo visto attaccanti tentare di sottrarre file di password, scaricare malware nelle macchine, ottenere accesso remoto e via dicendo. Un attacco ha anche portato all’apertura/chiusura di un drive CD/DVD di un server” ha dichiarato John Graham-Cumming di Cloudflare.

Anche i dispositivi di rete di più alto livello potrebbero essere vulnerabili. Il ricercatore e giornalista Ashkan Soltani afferma infatti di aver già riscontrato un vettore di attacco molto pericoloso: una vulnerabilità Bash sul servizio Big IP di F5 Security, che funge da smart gatweay collocandosi tra le web app e gli utenti. La vulnerabilità ora è comunque limitata – dal momento che è necessario essere un utente F5 autenticato per poter rendere operativo l’attacco – ma indica la possibilità di portare attacchi molto più pericolosi, estendendo la portata del problema. Molti dei sistemi di rete di fascia alta sono costruiti su piattaforma Linux/Unix: una vulnerabilità in un apparato di rete chiave è molto più critica rispetto al computer di un singolo utente dal momento che permette di architettare operazioni di reindirizzamento e attacchi man-in-the-middle su scala massiva.

Come abbiamo osservato ieri, la pericolosità di Shellshock è ben superiore rispetto a quella di Heartbleed, un’altra vulnerabilità di ampia portata che è stata scoperta nel corso della primavera, per via della enorme facilità con cui può essere sfruttata a scopi dannosi.

Al momento in cui scriviamo sono già state distribuite patch per i sistemi operativi CentOS, Debian, Redhat e Ubuntu. Apple ha riconosciuto il problema, comunicando ufficialmente di essere al lavoro per realizzare una patch correttiva. La Mela ha inoltre indicato che “gli utenti Mac OS X non sono esposti allo sfruttamento remoto di Bash a meno che non abbiano configurato servizi Unix avanzati”, sebbene non precisi quali siano questi sistemi. Le varie community hanno però sollevato qualche dubbio sull’efficacia delle patch già rilasciate, che sembrano essere più un tentativo di prendere tempo prima di trovare una soluzione definitiva.

Quello che accadrà nel breve termine è una corsa tra staff IT e amministratori di sistemi/rete contro gli attaccanti che operano per diffondere malware. L’unico consiglio che si può dare ora è quello, per tutti gli utenti di sistemi Linux/Unix-based di aggiornare tutti i software all’ultima versione disponibile ed in particolare quei programmi che fanno uso di FTP o Telnet, in attesa che venga resa disponibile una soluzione definitiva al problema. Nel lungo termine, invece, è tutt’altro discorso: ripetiamo che non solo sistemi PC/server ma qualunque dispositivo connesso ad una rete e che operi una versione di Unix e che faccia uso di script shell (una scorciatoia molto comune) è vulnerabile. Si tratta di un numero sterminato di dispositivi, molti dei quali probabilmente abbandonati a loro stessi già da molto tempo o impossibili da aggiornare. Non è nemmeno da escludere, anzi è fortemente probabile, che nei prossimi giorni/settimane possano verificarsi vari problemi/attacchi causati da questa vulnerabilità.

Ulteriori dettagli tecnici su Shellshock sono disponibili in questo blog.