Home

Expanding GNS3VM Disk Space

So you’ve been labing things up like a mad man on your GNS3 server and you’ve finally ran out of room on your GNS3VM. Be not dismayed, follow the guidance below and you’ll be up and running in no time.

From within your hypervisor management interface, power off the GNS3VM and expand the disk as needed (I expanded mine from 100GB > 300GB). Save and power your GNS3VM back up. Now console or ssh into the GNS3VM and launch the ‘Shell’ from within the GNS3VM console menu. Once at the shell execute the following commands to get the underlying Ubuntu OS to recognize the newly added disk space:

# Switch to root
sudo su

# Run 'parted' on the appropriate disk (most likely sdb)
parted /dev/sdb

# Once inside the parted utility CLI expand the disk
(parted) resizepart 1
Warning: Partition /dev/sdb1 is being used. Are you sure you want to continue?
Yes/No? yes                                                               
End?  [322GB]? 100%
(parted) quit

# Run the resize2fs utility to expand the filesystem to consume the newly added disk space

resize2fs /dev/sdb1

# Reboot
reboot

# Verify the new disk space has been added
df -h

Filesystem      Size  Used Avail Use% Mounted on
udev             32G     0   32G   0% /dev
tmpfs           6.3G  8.9M  6.3G   1% /run
/dev/sda1        20G  5.3G   13G  29% /
tmpfs            32G     0   32G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            32G     0   32G   0% /sys/fs/cgroup
>>/dev/sdb1       295G   93G  190G  33% /opt
tmpfs           6.3G     0  6.3G   0% /run/user/1000

Backing Up Free ESXi Server

Need to backup the vm’s running on your freely licensed VMware ESXi server? Look no further than Veeam!

Traditionally speaking, when it  comes to VMware based hypervisors,  Veeam only caters to vSphere managed environments. With that said, Veeam has released some client side tools to backup physical Windows or Linux based servers, creating the familiar Veeam vbk and vim backup files we see in traditional Veeam virtual backups. As a long user of ghettoVCB, I had grown weary of the VIB package maintenance that comes with administering ghettoVCB. As such, I have migrated to installing Veeam backup agent inside all my Windows and Linux virtual machines and now enjoy the mostly maintenance free backups. It’s important to note that this solution isnt a virtualized backup solution (as in backing up the files that comprise a vm or leveraging native virtualization backup API’s) but a file-system level backup with agents installed and running within the operating system itself.

Veeam backup for Windows can be found here and Veeam backup for Linux can be found here. Enjoy

ASA Firewall Behavior and Logging

I had a very interesting experience today with my Check ASA 5506X. I have been working on migrating about 15 virtual severs I run to a new sever VLAN to include my Graylog logging sever which actively collected all my syslogs across the network. I had chosen a new IP address and updated the server with new IP address. Soon after doing so I noticed that I had lost Internet connectivity.

I had checked DNS and my routing and everything checked out. After some hair-pulling I jumped into my ASA and began poking around. I knew I hadn’t changed anything on the fw but decided to run a packet-tracer check to see what the results of a normal flow out of my ASA into the Internet would result in. It failed. Correlating my recent activities to my current issue the only common denominator was the syslog server in which my ASA was configured to use. I decided to remove the logging configuration and low and behold my Internet returned. I consulted Cisco’s latest guidance and found that this is expected behavior be default if a connection to a logging source becomes broken.

The recommended approach going forward would be to remove the logging config before change IP addresses on yoru log server OR to add the configuration the would prevent this action on the ASA. This is a natural security concern as any malicious intruder would look to erase any tracks of his/her misgivings and in doing so would kill their intrusion into your organizations fw. I opted to disable this security mechanism and contend with the fail-open regarding logging.

Environment:

Cisco ASA 5506X running 9.8(1)

Steps:

(config)# logging permit-hostdown

Graylog IP Address Changes

If your running Graylog and looking to update it’s IP address you need to modify the server.conf file located in /etc/graylog/server/. Update the rest_listen_uri and web_listen_uri sections of the config and restart graylog service

Synopsis:

Updating the IP address to your Graylog server requires taking a few additional steps beyond modifying the server’s IP.

Environment:

Ubuntu Server 16.04 LTS running Graylog v2.3

Steps:

sudo nano /etc/graylog/server/server.conf

Edit the following sections within the server.conf file:

rest_listen_uri = <new_ip>
web_listen_uri = <new_ip>

Lastly you need to update your inputs and change the binding address to reflect the new IP: