Inability to set static IP or utlize a DHCP reservation for IP address assignment can lead to access issues and network conflict

• The lack of a reservation was what caused another server to be given our server's IP address and resulted in our ability to use our server right before Milestone 3 began. Josh Garske was able to resolve this and explain what caused it.​

Backups shoud occur daily and immediately before and after configuration changes. It would be preferable that we have access to initiate and restore from snapshots/backups.

• Since daily backups could not be accomodated by KSU, we had to rely on making changes on Fridays so that those changes would be included in the snapshot that occurred every Friday at midnight.​

• Restoration from backup should be tested, and more importantly the time to complete a restoration should be known. In our case, we had to restore from backups twice. The first was completed within 2 days of making the request, while the second restoration took almost 4 business days due to a lack of communication from KSU IT support.

Planning for worst-case scenarios for setup and installation of new software, as well as configuration changes and updates.

Hypervisor access would facilitate troubleshooting as to why certain changes affect remote access through SSH or other means

• Updates to MariaDB and the RedHat operating system resulted in our server being remotely accessible via SSH or Cockpit. We were not able to troubleshoot why those updates failed due to not being able to access the virtual machine through its hypervisor, so we had to leave both of these unpatched in order to keep our website online and functional. We experienced similar issues with trying to update Apache.​

Adding whitelisted IP address ranges for critical services and software.

• We experienced issues activating WordFence and Sucuri that ended up being resolved by whitelisting the appropriate public IP address ranges for each.​