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
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.
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.
Cisco ASA 5506X running 9.8(1)
(config)# logging permit-hostdown
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
Updating the IP address to your Graylog server requires taking a few additional steps beyond modifying the server’s IP.
Ubuntu Server 16.04 LTS running Graylog v2.3
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: